Hi Gorry and all, Thanks for all the comments. Regarding section 4 here's some input: Concerning signalling, this is definitely a threat in order to mount active attacks. But as we understand SI signalling does not have any authentication /encryption and also it is considered a different plane. Moreover some SI tables are important to be initially in plaintext for the proper configuration of the terminals. This is definitely a threat. Maybe people involved with SI tables and so can provide more insight into the severity of this threat. Regards Sunil Iyengar, Centre For Communication And Systems Research(CCSR), School of Electronics, Computing & Mathematics, University Of Surrey, Guildford GU2 7XH, Surrey, England, United Kingdom. ________________________________ From: owner-ipdvb@erg.abdn.ac.uk on behalf of Gorry Fairhurst Sent: Tue 20/09/2005 10:18 To: ipdvb@erg.abdn.ac.uk Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); stephane.combes@space.alcatel.fr; Laurence.Duquerroy@space.alcatel.fr Subject: Thoughts on draft-cruickshank-ipdvb-sec-req-00.txt 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
<<winmail.dat>>