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

["H.Cruickshank" <H.Cruickshank@surrey.ac.uk>]

Hi IPDVB members,

Few weeks ago, Gorry raise some interesting issues in his email
regarding the draft above.

I certainly agree with points 1 and 2 are good and should be included in
the draft (in Gorry email below).

Regarding points 3 (threats and relationship with IPDVB architecture
scenarios, packet authentications etc..) and 4 (signalling security) are
interesting and I really hope that people with practical and operational
experience should try to comment on these issues.  So that the IP-DVB
security requirement draft can capture these issues correctly.

Many thanks

--

Dr. Haitham S. Cruickshank 

Lecturer

Communications Centre for Communication Systems Research (CCSR) 

School of Electronics, Computing and Mathematics 

University of Surrey, Guildford, Surrey GU2 7XH, UK 

Tel: +44 1483 686007 (indirect 689844) 

Fax: +44 1483 686011 

e-mail: H.Cruickshank@surrey.ac.uk 

http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 



-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Gorry Fairhurst
Sent: 20 September 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