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