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

[P.Pillai@Bradford.ac.uk]

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


Quoting Gorry Fairhurst <gorry@erg.abdn.ac.uk>:

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

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



-- 
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: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------