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
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 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
>
aallison@nab.org
>
> 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:
owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk]
On
> Behalf Of Gorry Fairhurst
> Sent: Wednesday, August 30, 2006
12:57 PM
> To: ipdvb@erg.abdn.ac.uk; P.Pillai@Bradford.ac.uk;
mnoist@cosy.sbg.ac.at
> 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.
>
>
---
>