Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

This draft raises several issues, and seems to me to be a good start, at a 
document that would be useful to this WG. I'd like to get more opinions on 
what the document does say, and what it does not, so that we can understand 
whether this fits the needs of this WG. Can I encourage people to read thsi 
and send comments to the list?

I have some comments below, to start this process:

Section 1.1:
-----
1) In 1.1 it is may also be worth stating that the service to be protected is 
the stream (TS Logical Channel) that is between the Encapsulation Gateway and 
Receiver. This stream is identified at the Gateway and Receiver by a unique 
PID value associated with the stream (although at the two ends of the link may 
have differing values, since this can be and is modified in the MPEG2
Transmission Network).
-----
2) It also could perhaps be staring that although a number of components 
operate within the network. For the IP network service, they do not modify the 
packet payload.
-----


Section 2: Threats
-----
3) I wonder if there are any thoughts on the different "Access to the Channel" 
related to the set of scenarios in section 3.1 of draft-ietf-ipdvb-arch-xx.txt.

- Specifically do people see different threats being important in TV-oriented 
networks that are contribution/broadcast carrying IP data and networks that 
are more IP-oriented (with smaller transmit hubs/power)? - I do.

- In broadcast networks, it is probably hard to access the ground network at
the transmitter (or the contribution feed, in a digital TV scenario). It is
therefore hard to modify the traffic sent on the broadcast up-link (from the
modulator to the headend/satellite/mast) which would impact all receivers -
this typically requires access to facilities and/or a large transmit power
(as in Captain Midnight [Ref]).

- In contrast, access to the air-interface of specific receivers is much
easier. The signal at a Receiver is often much weaker (due to path
propagation loss). This could potentially be jammed/replayed/over-loaded
with another signal (e.g. A transmitter injecting a signal into the
side-lobe of a satellite receive antenna).

- DoS, traffic analysis, and other networking threats are more significant
for IP-data than TV services, where the potential damage from malicous
manipulation is greater. ETC....

-----
4) I would like to have seen some discussion of the impact of 
modified/corrupted/forged signalling information on the Receiver.

It is usually hard to inject different traffic or modify existing TS Packets
within a stream, but through configuration of the (re)multiplexor, access to
the physical media (e.g. connections between components), etc it is possible
to replace a Stream with a different stream.

This could also arise on the broadcast physical link (e.g. An unauthorised
high-power transmitter overriding the intended transmission). However, note
that the transmissions are normally continuous (rather than the discrete
bursts, e.g. Used in 802.11, WiMAX). To successfully inject new/replacement
traffic requires the physical layer FEC/modulation to be acquired by the
Receiver. L2 signalling (MPEG2 SI) also needs to be consistent with the TS
packets being sent.  However, the current specifications for MPEG-2 [....]
do not specify a method for authentication (or encryption) of the L2
signalling information.

- Could we try to define some security properties of the signalling plane (I'd 
be happy to contribute some starting text)?

- Perhaps this should also be identified as an assumption/issue in the 
Security Considerations section?
-----


Hope that helps,

Gorry