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

From: "Allison, Art" <[email-masked]>
Date: Wed, 30 Aug 2006 14:30:51 -0400

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.....

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".
//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.//
 > Does a Stream always only have ONE originating source?
 //AA>I think that is so... if not then the meaning is lost on me.//
 > That is, does the PID imply a specific intended source?
//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.

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 //(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
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 //(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,
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
//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: Gorry Fairhurst <[email-masked]>
Date: Thu, 31 Aug 2006 10:00:04 +0100

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.

---

---

From: [email-masked]
Date: Thu, 31 Aug 2006 16:18:15 +0100

Hi Gorry,

Thanx a lot for this text. After chatting with you during the SATNEX summer
school I was also planning to write such a para. But this is perfect.

I think this is more suitable for Section 3.1, than Section 3.2.

Just a few minor changes/comments. See inline

Regards
Prashant

> supporting unicast and/or multicast transmission.
PP: We shall replace the old abstract with this one
PP: Line 2 - delete "examines the"
PP: Line 4 - replace "network-layer" with "network-layer protocol"

> each
//elementary//stream it originates. However, there is no required relationship

-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------