Subject: I-D ACTION:[email-masked]

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 15 Sep 2005 09:20:07 +0100

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : Security requirements for the Unidirectional
                           Lightweight Encapsulation (ULE) protocol
         Author(s)       : H. Cruickshank, et al.
         Filename        : draft-cruickshank-ipdvb-sec-req-00.txt
         Pages           :
         Date            : 2005-9-14

    This document provides a threat analysis and derives security
    requirements for MPEG-2 transmission links using the Unidirectional
    Lightweight Encapsulation (ULE).  It also provides the motivation
    for ULE link level security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-cruickshank-ipdvb-sec-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
         mailserv at ietf.org.
In the body type:
         "FILE /internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt".

NOTE:   The mail server at ietf.org can return the document in
         MIME-encoded form by using the "mpack" utility.  To use this
         feature, insert the command "ENCODING mime" before the "FILE"
         command.  To decode the response(s), you will need "munpack" or
         a MIME-compliant mail reader.  Different MIME-compliant mail readers
         exhibit different behavior, especially when dealing with
         "multipart" MIME messages (i.e. documents which have been split
         up into multiple messages), so check your local documentation on
         how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-00.txt>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 Sep 2005 10:18:06 +0100

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