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

From: "S.Iyengar" <[email-masked]>
Date: Fri, 21 Oct 2005 16:17:58 +0100

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: [email-masked] on behalf of Gorry Fairhurst
Sent: Tue 20/09/2005 10:18
To: [email-masked]
Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); [email-masked]; [email-masked]
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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Oct 2005 16:41:07 +0100

Here are some thoughts... Comments welcome!

Gorry

---

Some of the L2 signalling security properties include:

- No authentication of the signalling source. The layer-2 signalling
entity is often not be the encapsulation gateway itself.
- No encryption (but sometimes this is needed to bootstrap terminals).
- Integrity check is a CRC-32. This is relatively weak compared to a
cryptographic hash. (Should the forging of table contents needs to be
considered?)
- (re)multiplexors do modify (or insert new SI tables), but there is no
security association with these devices within an MPEG-2 Transmission
network.
- Modification/Denial of the SI information could result in association of a
different stream with the service, or an inability to identify the TS
Logical Channel (PID) that is used for a service.

Threats from interception of Forward link signalling.

In current MPEG-TS networks, the forward link signalling is not encrypted.
Eavesdropping of the signalling information does not reveal any information
which is not available to all receivers.

In the case of two-way networks, forward link signalling can reveal traffic
parameters of the return links from specific users. This information can
also reveal the status of specific terminals (logon/logoff, etc) and the
timing and transmission parameters used by these terminals.

Some of these threats could be reduced by using IP-based signalling [ref]
and appropriate IP-level security mechanisms (e.g. IPsec).

Replay/Jamming

- SI information is required to associate PID values with Streams and
therefore to demultiplex the data at the Receiver.
- In  two-way systems, denial of forward signalling may also prevent link
transmission in the return direction.
- Jamming/interception may also occur in the return link direction. In this
case, forged return link signalling could acquire return link bandwidth, or
modify the state of a terminal as perceived at the network control centre.
These threats can be exploited as a DoS attack.

- SI information may be sent periodically. If the time of transmission is
predictable, this could be "jammed" resulting in loss of signalling at the
receiver, which is a DoS vulnerability. It requires access to the stream -
either on the air interface (e.g. A different transmitter injecting a signal
that is Received (e.g. On an antenna side-lobe).
- Modification of SI can also be a DoS attack, this requires access to the
network components (multiplexors, etc) and/or connecting physical media - a
man-in-the-middle attack.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Oct 2005 16:36:43 +0100

I think it would be good to understand these issues, and if you can draw any 
wisdom, then I encourage you to distill this into the draft - even if the end 
result is that we are unable to change anything in the signalliung plane, it 
seems wise to document that vulnerabilities as seen from the IP viewpoint.

I'll send some thoughts to the list...

Gorry

S.Iyengar wrote:

> 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,
> ------------------------------------------------------------------------
> Cc: Haitham Cruickshank; Iyengar S Mr (CCSR); 
> [email-masked]; [email-masked]