Subject: Trying to find words to describe how PIDs are used.....

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 30 Aug 2006 17:56:31 +0100

Repost: My last posting to the list seemed to have gone astray, so I 
shall try an updated repost.

I was trying to use some of the email from others to propose some text 
that answered the second set of questions.

 > 2) Can  we determine precisely what we man by a "Stream".
 > Does a Stream always only have ONE originating source?
 > That is, does the PID imply a specific intended source?

Here is some draft text, that could perhaps be placed at the end of 
section 3.2. I'd be very pleased to receive comments/corrections so we 
converge on some good description of this, since I think this relates 
directly to the need for authentication.

THOUGHTS??? Comments and corrections please...

Best wishes,

Gorry

----

In a MPEG-2 Transmission network, the originating source of MPEG-2 TS 
Packets is either a L2 interface device (media encoder, encapsulation 
gateway, etc) or a L2 network device (TS multiplexor, etc). These 
devices may, but do not necessarily, have an associated IP address. In 
the case of an encapsulation gateway (e.g. ULE sender), the device may 
operate at L2 or L3, and is not normally the originator of an IP traffic 
flow, and usually the IP source address of the packets that it forwards 
do not correspond to an IP address associated with the device. When 
authentication of the IP source is required this must be provided by 
IPsec, TLS, etc. operating at a higher layer.

The TS Packets are carried to the Receiver over a physical layer that 
usually includes Forward Error Correction and synchronisation processing 
that makes injection of single TS Packets very difficult. Replacement of 
a sequence of packets is difficult, but possible.

Each Receiver needs to identify a TS Logical Channel (or MPEG-2 Stream) 
to reassemble the fragments of PDUs sent by a L2 source [RFC4259]. In an 
MPEG-2 TS, this association is made via the Packet Identifier, PID 
[ISO-MPEG]. At the sender, each source associates a locally unique set 
of PID values with each stream it originates. However, there is no 
required relationship between the PID value used at the sender and that 
received at the Receiver.  Network devices may re-number the PID values 
associated with one or more TS Logical Channels (Streams) to prevent 
clashes at a multiplexor between input Streams with the same PID carried 
on different input multiplexes.  A device may also modify and/or insert 
new SI data into the control plane (also sent as TS Packets identified 
by PID value).

The Stream of TS Packets carried in a multiplex are usually received by 
many Receivers. One method is to secure the entire Stream at teh MPEG-2 
TS level. This approach is well-suited to TV-transmission, data-push, 
etc, where the PID carries one or a set of flows with similar security 
requirements. Where the Stream carries a set of IP traffic flows to 
different destinations with a range of properties (multicast, unicast, 
etc) this it is often not appropriate to provide IP confidentiality 
services for the entire Stream. A finer-grain control is required that 
at least allows control to the level of a single MAC/NPA address. 
However, there is only one valid source of data for each MPEG-2 Stream 
(i.e. PID). Although an attacker that is able to modify the content of 
the received multiplex (e.g. replay data) could inject data locally with 
an arbitrary PID value.

---

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 31 Aug 2006 08:28:56 -0400

Much better.. Good even.
Art 

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Thursday, August 31, 2006 5:00 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; Allison, Art
Subject: Re: Trying to find words to describe how PIDs are used.....

Thanks Art,

I think the only way to make sure people understand is to get the
language correct. While I was trying to be precise on the security
aspects, my language got a little loose again, sorry.

I agree with all you say, we should remember the context of an IP over
ULE Stream which serves a (large) community of Receivers... and the
document should be clear on this from the start. I've incorporated your
corrections, and a few more to tighten this up, do people think this is
  better?

Gorry

----

Perhaps it may better to preface the introduction with something better
text, e.g. replacing it with?:

OLD:
Abstract

        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. This work is
intended
        as a work item of the ipdvb WG, and contributions are sought
from
        the IETF on this topic.

SUGGESTION?

Abstract

The MPEG-2 standard defined by ISO 13818-1 [ref] supports a range of
transmission methods for a range of services. This document examines the
provides a threat analysis and derives security requirements when using
the Transport Stream, TS, to support an Internet network-layer using
Unidirectional Lightweight Encapsulation (ULE), RFC 4326. The document
also provides the motivation for link-level security for a ULE Stream. A
ULE Stream may be used to send IPv4 packets, IPv6 packets, and other
Protocol Data Units (PDUs) to an arbitrarily large number of Receivers
supporting unicast and/or multicast transmission.

---

Suggestion to add text to 3.2 (although on re-reading, perhaps adding
something like this in 3.1 befor the final paragraph of the section, is
a better place??):

In a MPEG-2 TS transmission network, the originating source of TS

The TS Packets are carried to the Receiver over a physical layer that
usually includes Forward Error Correction coding that interleaves the
bytes of several consecutive, but unrelated, TS Packets. FEC coding and
synchronisation processing makes injection of single TS Packets very
difficult. Replacement of a sequence of packets is also difficult, but
possible (see section 3.2).

A Receiver in a MPEG-2 TS transmission network needs to identify a TS
Logical Channel (or MPEG-2 Elementary Stream) to reassemble the
fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 TS, this
association is made via the Packet Identifier, PID [ISO-MPEG]. At the
sender, each source associates a locally unique set of PID values with
each stream it originates. However, there is no required relationship
between the PID value used at the sender and that received at the
Receiver.  Network devices may re-number the PID values associated with
one or more TS Logical Channels (e.g. ULE Streams) to prevent clashes at
a multiplexor between input streams with the same PID carried on
different input multiplexes (updating entries in the PMT [ISO-MPEG], and
other SI tables that reference the PID value).  A device may also modify
and/or insert new SI data into the control plane (also sent as TS
Packets identified by their PID value).

The PID associated with an Elementary Stream can be modified (e.g. in
some systems by reception of an updated SI table, or in other systems
until the next annuncement/discovery data is received).  An attacker
that is able to modify the content of the received multiplex (e.g. 
replay data and/or control information) could inject data locally into
the received stream with an arbitrary PID value.

One method to provide security is to secure the entire Stream at the
MPEG-2 TS level. This stream of TS Packets carried in a multiplex are
usually received by many Receivers. The approach is well-suited to
TV-transmission, data-push, etc, where the PID carries one or a set of
flows (e.g. video/audio Packetized Elementary Stream (PES) Packets) with
similar security requirements.

Where a ULE Stream carries a set of IP traffic flows to different
destinations with a range of properties (multicast, unicast, etc), it is
often not appropriate to provide IP confidentiality services for the
entire ULE Stream. For many expected applications of ULE, a finer-grain
control is therefore required, at least permitting control of data
confidentiality/authorisation at the level of a single MAC/NPA address. 
However there is only one valid source of data for each MPEG-2
Elementary Stream, bound to a  PID value. This observation could
simplify the requirement for authentication of the source of a ULE
Stream.

---

Allison, Art wrote:

> Well, indeed it is important to define terms.
> At the top level; per 13818-1, there are Program Streams and Transport

> Streams.
> First, put aside Program Streams. (From 13818-1:"The Program Stream is

> designed for use in relatively error-free environments and is suitable

> for applications which may involve software processing of system 
> information such as interactive multi-media applications. Program 
> Stream packets may be of variable and relatively great length.") 
> Continuing from 13818-1:
> "The Transport Stream combines one or more programs with one or more 
> independent time bases into a single stream. PES packets made up of 
> elementary streams that form a program share a common timebase. The 
> Transport Stream is designed for use in environments where errors are 
> likely, such as storage or transmission in lossy or noisy media.
> Transport Stream packets are 188 bytes in length."
> 
> A Packetized Elementary stream can be constructed from a continuous 
> sequence of PES packets of one elementary stream with one stream ID.
> 
> So 'MPEG-2 Stream' is indeed ambiguous in meaning. 
> Notwithstanding the mental discord, I attempted modifications in 
> <yourspeak> below demarked by //
> 
> 
> 
> _____________
> Art Allison
> Director, Advanced Engineering
> Science & Technology
> National Association of Broadcasters
> 1771 N Street, NW
> Washington, D.C. 20036
> Phone: 202.429.5418
> Fax: 202.777.4981
> [email-masked]
> 
> The National Association of Broadcasters is a trade association that 
> advocates on behalf of more than 8,300 free, local radio and 
> television stations and also broadcast networks before Congress, the 
> Federal Communications Commission and the Courts.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Gorry Fairhurst
> Sent: Wednesday, August 30, 2006 12:57 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: S.Iyengar
> Subject: Trying to find words to describe how PIDs are used.....
> 
> 

> //AA>I think a modifier should always be used as this word is 
> overloaded and usage here does not directly map to MPEG-2 systems.//  
>  //AA>I think that is so... if not then the meaning is lost on me.//  
> //AA>No, because as you cover below, these PIDs are ephemeral and 
> changeable by any multiplexer.
> If the PID is anounced in a PMT, it can change with each PMT section, 
> although typically it does not.// Here is some draft text, that could 
> perhaps be placed at the end of section 3.2. I'd be very pleased to 
> receive comments/corrections so we converge on some good description 
> of this, since I think this relates directly to the need for 
> authentication.
> 

> operate at L2 or L3, and is not normally the originator of an IP 
> traffic flow, and usually the IP source address of the packets that it

> forwards do not correspond to an IP address associated with the 
> device. When authentication of the IP source is required this must be 
> provided by IPsec, TLS, etc. operating at a higher layer.
> 
> usually includes Forward Error Correction //(which can time shift data

> by interleaving data from multiple unrelated TS packets)// and 
> synchronisation processing that makes injection of single TS Packets 
> very difficult. Replacement of a sequence of packets is difficult, but

> possible.
> 
> Each Receiver needs to identify a TS Logical Channel (or MPEG-2 
> //Elementary// Stream) to reassemble the fragments of PDUs sent by a 
> L2 source [RFC4259]. In an

> required relationship between the PID value used at the sender and 
> that received at the Receiver.  Network devices may re-number the PID 
> values associated with one or more TS Logical Channels (Streams) to 
> prevent clashes at a multiplexor between input Streams with the same 
> PID carried on different input multiplexes //(updating the 
> PMT[ISO-MPEG] if the data is reference in such)//.  A device may also 
> modify and/or insert new SI data into the control plane (also sent as 
> TS Packets identified by PID value).
> 
> The Stream of TS Packets carried in a multiplex are usually received 
> by many Receivers. One method is to secure the entire Stream at the 
> MPEG-2 TS level. This approach is well-suited to TV-transmission, 
> data-push, etc, where the PID carries one or a set of flows with 
> similar security requirements. Where the Stream carries a set of IP 
> traffic flows to different destinations with a range of properties 
> (multicast, unicast,

> However, there is only one valid source of data for each MPEG-2 
> //Elementary// Stream (i.e. PID) //for some duration//. //The duration

> may be only until the next PMT arrives in some systems. It may be 
> until the next annuncement/discovery data is received in other 
> systems.// Although an attacker that is able to modify the content of 
> the received multiplex (e.g. replay data) could inject data locally 
> with an arbitrary PID value.
> 
> ---
>

---

From: <[email-masked]>
Date: Thu, 31 Aug 2006 16:10:33 +0100

Hi Gorry and Art,
Thank you for the comments and valuable input. I agree with the fact that the abstract should be reworded as mentioned below and that the remaining text should come at the start of section 3 before 3.1 system components.
 
Regards
Sunny
 
***********************************************************
Sunil Iyengar,
Research Fellow, Networks Group,
Centre For Communication And Systems Research(CCSR),
School of Electronics, Computing & Mathematics,
University Of Surrey, Guildford GU2 7XH,
Surrey, England, United Kingdom.
Office: +44 (0)1483 686008
***********************************************************

________________________________

From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Thu 31/08/2006 10:00
To: [email-masked]; [email-masked]; [email-masked]; Iyengar S Mr (CCSR); [email-masked]
Subject: Re: Trying to find words to describe how PIDs are used.....

Thanks Art,

Gorry

----

OLD:
Abstract

        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. This work is intended
        as a work item of the ipdvb WG, and contributions are sought from
        the IETF on this topic.

SUGGESTION?

Abstract

---

A Receiver in a MPEG-2 TS transmission network needs to identify a
TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the

simplify the requirement for authentication of the source of a ULE Stream.

---

Allison, Art wrote:

> information such as interactive multi-media applications. Program Stream
> packets may be of variable and relatively great length.")
> Continuing from 13818-1:
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gorry Fairhurst
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: S.Iyengar
> //AA>I think a modifier should always be used as this word is overloaded
> and usage here does not directly map to MPEG-2 systems.//
> although typically it does not.//
> //Elementary// Stream) to reassemble the fragments of PDUs sent by a L2
> source [RFC4259]. In an
> on different input multiplexes //(updating the PMT[ISO-MPEG] if the data
> is reference in such)//.  A device may also modify and/or insert new SI
> data into the control plane (also sent as TS Packets identified by PID
> value).
>
> many Receivers. One method is to secure the entire Stream at the MPEG-2
> may be only until the next PMT arrives in some systems. It may be until
> the next annuncement/discovery data is received in other systems.//
> Although an attacker that is able to modify the content of the received
> multiplex (e.g. replay data) could inject data locally with an arbitrary
> PID value.
>
> ---
>