[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-cruickshank-ipdvb-sec-req) 00 01 02 03 04 05 06 07 08 09 RFC 5458

     Internet Engineering Task Force                       H.Cruickshank
     Internet Draft                                           S. Iyengar
     draft-ietf-ipdvb-sec-req-02.txt            University of Surrey, UK
                                                            L. Duquerroy
                                            Alcatel Alenia Space, France
     Expires: November 10, 2007                                P. Pillai
                                              University of Bradford, UK
     Category: WG Draft intended for INFORMATIONAL RFC      May 10, 2007
            Security requirements for the Unidirectional Lightweight
                         Encapsulation (ULE) protocol
    Status of this Draft
       By submitting this Internet-Draft, each author represents that
       any applicable patent or other IPR claims of which he or she is
       aware have been or will be disclosed, and any of which he or she
       becomes aware will be disclosed, in accordance with Section 6 of
       BCP 79.
       Internet-Drafts are working documents of the Internet Engineering
       Task Force (IETF), its areas, and its working groups.  Note that
       other groups may also distribute working documents as Internet-
       Internet-Drafts are draft documents valid for a maximum of six
       months and may be updated, replaced, or obsoleted by other
       documents at any time.  It is inappropriate to use Internet-
       Drafts as reference material or to cite them other than as "work
       in progress."
       The list of current Internet-Drafts can be accessed at
       The list of Internet-Draft Shadow Directories can be accessed at
       This Internet-Draft will expire on November 10, 2007.
       The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a
       range of transmission methods for a range of services. This
       document provides a threat analysis and derives the security
       requirements when using the Transport Stream, TS, to support an
       Internet network-layer using Unidirectional Lightweight
       Encapsulation (ULE) [RFC4326]. The document also provides the
       motivation for link-layer security for a ULE Stream. A ULE Stream
    Cruickshank           Expires November 10, 2007          [Page 1]

    Internet-Draft      Security Requirements for ULE     May 2007
       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.
    Table of Contents
       1. Introduction..............................................2
       2. Requirements notation......................................4
       3. Threat Analysis...........................................6
          3.1. System Components.....................................6
       Figure 1: An example configuration for a unidirectional........6
       Service for IP transport over MPEG-2 [RFC4259]................6
          3.2. Threats..............................................8
          3.3. Threat Scenarios.....................................10
       4. Security Requirements for IP over MPEG-2 TS...............11
          4.1. Compatibility with Generic Stream Encapsulation.......13
       5. IPsec and MPEG-2 Transmission Networks....................13
       6. Motivation for ULE link-layer security....................14
          6.1. Link security below the Encapsulation layer..........14
          6.2. Link security as a part of the encapsulation layer....15
       7. Summary..................................................16
       8. Security Considerations...................................17
       9. IANA Considerations......................................17
       10. Acknowledgments.........................................17
       11. References..............................................18
          11.1. Normative References................................18
          11.2. Informative References..............................18
       Author's Addresses..........................................20
       12. IPR Notices.............................................20
          12.1. Intellectual Property Statement.....................20
          12.2. Intellectual Property...............................21
       13. Copyright Statement......................................21
       Document History............................................21
       Appendix A: ULE Security Framework...........................22
    1. Introduction
       The MPEG-2 Transport Stream (TS) has been widely accepted not
       only for providing digital TV services, but also as a subnetwork
       technology for building IP networks. RFC 4326 [RFC4326] describes
       the Unidirectional Lightweight Encapsulation (ULE) mechanism for
       the transport of IPv4 and IPv6 Datagrams and other network
       protocol packets directly over the ISO MPEG-2 Transport Stream as
       TS Private Data.  ULE specifies a base encapsulation format and
       supports an extension format that allows it to carry additional
    Cruickshank           Expires November 10, 2007           [Page 2]

    Internet-Draft      Security Requirements for ULE     May 2007
       header information to assist in network/Receiver processing. The
       encapsulation satisfies the design and architectural requirement
       for a lightweight encapsulation defined in RFC 4259 [RFC4259].
       Section 3.1 of RFC 4259 presents several topological scenarios
       for MPEG-2 Transmission Networks. A summary of these scenarios
       are presented below (for full detail, please refer to RFC 4259):
       1. Broadcast TV and Radio Delivery.
       2. Broadcast Networks used as an ISP. This resembles to scenario
          1, but includes the provision of IP services providing access
          to the public Internet.
       3. Unidirectional Star IP Scenario. It utilizes a Hub station to
          provide a data network delivering a common bit stream to
          typically medium-sized groups of Receivers.
       4. Datacast Overlay. It employs MPEG-2 physical and link layers
          to provide additional connectivity such as unidirectional
          multicast to supplement an existing IP-based Internet service.
       5. Point-to-Point Links.
       6. Two-Way IP Networks. This can be typically satellite-based and
          star-based utilising a Hub station to deliver a common bit
          stream to medium- sized groups of receivers. A bidirectional
          service is provided over a common air-interface.
       RFC 4259 states that ULE must be robust to errors and security
       threats. Security must also consider both unidirectional as well
       as bidirectional links for the scenarios mentioned above.
       An initial analysis of the security requirements in MPEG-2
       transmission networks is presented in the security considerations
       section of RFC 4259. For example, when such networks are not
       using a wireline network, the normal security issues relating to
       the use of wireless links for transport of Internet traffic
       should be considered [RFC3819].
       The security considerations of RFC 4259 recommends that any new
       encapsulation defined by the IETF should allow Transport Stream
       encryption and should also support optional link-layer
       authentication of the SNDU payload. In ULE [RFC4326], it is
       suggested that this may be provided in a flexible way using
       Extension Headers. This requires the definition of a mandatory
       header extension, but has the advantage that it decouples
    Cruickshank           Expires November 10, 2007           [Page 3]

    Internet-Draft      Security Requirements for ULE     May 2007
       specification of the security functions from the encapsulation
       This document extends the above analysis and derives a detailed
       the security requirements for ULE in MPEG-2 transmission
    2. Requirements notation
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       "OPTIONAL" in this document are to be interpreted as described in
       RFC2119 [RFC2119].
       Other terms used in this document are defined below:
       ATSC: Advanced Television Systems Committee. A framework and a
       set of associated standards for the transmission of video, audio,
       and data using the ISO MPEG-2 standard.
       DVB: Digital Video Broadcast. A framework and set of associated
       standards published by the European Telecommunications Standards
       Institute (ETSI) for the transmission of video, audio, and data
       using the ISO MPEG-2 Standard [ISO-MPEG2].
       Encapsulator: A network device that receives PDUs and formats
       these into Payload Units (known here as SNDUs) for output as a
       stream of TS Packets.
       LLC: Logical Link Control [ISO-8802, IEEE-802].  A link-layer
       protocol defined by the IEEE 802 standard, which follows the
       Ethernet Medium Access Control Header.
       MAC: Message Authentication Code.
       MPE: Multiprotocol Encapsulation [ETSI-DAT].  A scheme that
       encapsulates PDUs, forming a DSM-CC Table Section.  Each Section
       is sent in a series of TS Packets using a single TS Logical
       MPEG-2: A set of standards specified by the Motion Picture
       Experts Group (MPEG) and standardized by the International
       Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T
       (in H.222 [ITU-H222]).
       NPA: Network Point of Attachment.  In this document, refers to a
       6-byte destination address (resembling an IEEE Medium Access
    Cruickshank           Expires November 10, 2007           [Page 4]

    Internet-Draft      Security Requirements for ULE     May 2007
       Control address) within the MPEG-2 transmission network that is
       used to identify individual Receivers or groups of Receivers.
       PDU: Protocol Data Unit.  Examples of a PDU include Ethernet
       frames, IPv4 or IPv6 datagrams, and other network packets.
       PID: Packet Identifier [ISO-MPEG2].  A 13-bit field carried in
       the header of TS Packets.  This is used to identify the TS
       Logical Channel to which a TS Packet belongs [ISO-MPEG2].  The TS
       Packets forming the parts of a Table Section, PES, or other
       Payload Unit must all carry the same PID value.  The all-zeros
       PID 0x0000 as well as other PID values is reserved for specific
       PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF
       indicates a Null TS Packet introduced to maintain a constant bit
       rate of a TS Multiplex.  There is no required relationship
       between the PID values used for TS Logical Channels transmitted
       using different TS Multiplexes.
       Receiver: Equipment that processes the signal from a TS Multiplex
       and performs filtering and forwarding of encapsulated PDUs to the
       network-layer service (or bridging module when operating at the
       link layer).
       SI Table: Service Information Table [ISO-MPEG2].  In this
       document, this term describes a table that is defined by another
       standards body to convey information about the services carried
       in a TS Multiplex. A Table may consist of one or more Table
       Sections; however, all sections of a particular SI Table must be
       carried over a single TS Logical Channel [ISO-MPEG2].
       SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
       Payload Unit.
       TS: Transport Stream [ISO-MPEG2], a method of transmission at the
       MPEG-2 layer using TS Packets; it represents layer 2 of the
       ISO/OSI reference model.  See also TS Logical Channel and TS
       TS Multiplex: In this document, this term defines a set of MPEG-2
       TS Logical Channels sent over a single lower-layer connection.
       This may be a common physical link (i.e., a transmission at a
       specified symbol rate, FEC setting, and transmission frequency)
       or an encapsulation provided by another protocol layer (e.g.,
       Ethernet, or RTP over IP). The same TS Logical Channel may be
       repeated over more than one TS Multiplex (possibly associated
       with a different PID value) [RFC4259]; for example, to
       redistribute the same multicast content to two terrestrial TV
    Cruickshank           Expires November 10, 2007           [Page 5]

    Internet-Draft      Security Requirements for ULE     May 2007
       transmission cells.
       TS Packet: A fixed-length 188B unit of data sent over a TS
       Multiplex [ISO-MPEG2].  Each TS Packet carries a 4B header, plus
       optional overhead including an Adaptation Field, encryption
       details, and time stamp information to synchronise a set of
       related TS Logical Channels.
    3. Threat Analysis
    3.1. System Components
         +------------+                                  +------------+
         |  IP        |                                  |  IP        |
         |  End Host  |                                  |  End Host  |
         +-----+------+                                  +------------+
               |                                                ^
               +------------>+---------------+                  |
                             +  IP           |                  |
               +-------------+  Encapsulator |                  |
       SI-Data |             +------+--------+                  |
       +-------+-------+            |MPEG-2 TS Logical Channel  |
       |  MPEG-2       |            |                           |
       |  SI Tables    |            |                           |
       +-------+-------+   ->+------+--------+                  |
               |          -->|  MPEG-2       |                . . .
               +------------>+  Multiplexor  |                  |
       MPEG-2 TS             +------+--------+                  |
       Logical Channel              |MPEG-2 TS Mux              |
                                    |                           |
                  Other    ->+------+--------+                  |
                  MPEG-2  -->+  MPEG-2       |                  |
                  TS     --->+  Multiplexor  |                  |
                        ---->+------+--------+                  |
                                    |MPEG-2 TS Mux              |
                                    |                           |
                             +------+--------+           +------+-----+
                             |Physical Layer |           |  MPEG-2    |
                             |Modulator      +---------->+  Receiver  |
                             +---------------+  MPEG-2   +------------+
                                                TS Mux
                 Figure 1: An example configuration for a unidirectional
                    Service for IP transport over MPEG-2 [RFC4259].
       As shown in Figure 1 above (from section 3.3 of [RFC4259]), there
       are several entities within the MPEG-2 transmission network
    Cruickshank           Expires November 10, 2007           [Page 6]

    Internet-Draft      Security Requirements for ULE     May 2007
       architecture. These include:
       o ULE Encapsulation Gateways (the Encapsulator or ULE source)
       o SI-Table signalling generator (input to the multiplexor)
       o Receivers (the end points for ULE security)
       o TS multiplexers (including re-multiplexers)
       o Modulators
       In an MPEG-2 network a set of signalling messages [ID-AR] may
       need to be broadcast (e.g. by an Encapsulation Gateway or other
       device) to form the Layer 2 (L2) control plane. Examples of
       signalling messages include the Program Association Table (PAT),
       Program Map Table (PMT) and Network Information Table (NIT). In
       existing MPEG-2 transmission networks, these messages are
       broadcast in the clear (no encryption or integrity checks). The
       integrity as well as authenticity of these messages is important
       for correct working of the ULE working of the ULE network, i.e.
       supporting its security objectives in the area of availability,
       in addition to confidentiality and integrity. One method recently
       proposed [ID-EF] encapsulates these messages using ULE. In such
       cases all the security requirements of this document apply in
       securing these signalling messages.
       ULE link security focuses only on the security between the ULE
       Encapsulation Gateway (ULE source) and the Receiver. Often times,
       the user of satellite communication link have to secure their
       communications beyond that satellite link, because terrestrial
       public network links are utilized in addition to the satellite
       link. Therefore, if users are concerned about loss of
       confidentiality and loss of integrity of their communication
       data, they will employ end-to-end network security mechanisms
       like IPSec or TLS. Governmental users may be forced by
       regulations to employ specific, approved implementations of those
       In contrast to the above, if a satellite link is used to directly
       join networks which are considered physically secure, for example
       branch offices to a central office, ULE Sec could be the sole
       provider of confidentiality and integrity. In this scenario,
       governmental users could still have to employ approved
       cryptographic equipment at the network layer or above, unless a
       ULE Sec equipment manufacturer would obtain governmental approval
       for his implementation.
    Cruickshank           Expires November 10, 2007           [Page 7]

    Internet-Draft      Security Requirements for ULE     May 2007
       All of this means that in many cases the confidentiality and
       integrity of the user data will already be taken care of. So ULE
       security measures would focus on either providing traffic flow
       confidentiality for user data that has already been encrypted or
       user data encryption for users who choose not to implement end-
       to-end security mechanisms.
       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
       multiplexer, 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 Layer
       3 (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 (FEC) 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 below).
       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-
       MPEG2]. 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 multiplexer
       between input streams with the same PID carried on different
       input multiplexes (updating entries in the PMT [ISO-MPEG2], 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).
    3.2. Threats
       The simplest type of network threat is a passive threat. This
       includes eavesdropping or monitoring of transmissions, with a
    Cruickshank           Expires November 10, 2007           [Page 8]

    Internet-Draft      Security Requirements for ULE     May 2007
       goal to obtain information that is being transmitted. In
       broadcast networks (especially those utilising widely available
       low-cost physical layer interfaces, such as DVB) passive threats
       are considered the major threats. An example of such a threat is
       an intruder monitoring the MPEG-2 transmission broadcast and then
       extracting traffic information concerning the communication
       between IP hosts using a link. Another example is of an intruder
       trying to gain information about the communication parties by
       monitoring their ULE Receiver NPA addresses; an intruder can gain
       information by determining the layer 2 identity of the
       communicating parties and the volume of their traffic. This is a
       well-known issue in the security field; however it is more of a
       problem in the case of broadcast networks such as MPEG-2
       transmission networks because of the easy availability of
       receiver hardware and the wide geographical span of the networks.
       As explained in section 3.1, 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 announcement/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.
       Active threats (or attacks) are, in general, more difficult to
       implement successfully than passive threats, and usually require
       more sophisticated resources and may require access to the
       transmitter. Within the context of MPEG-2 transmission networks,
       examples of active attacks are:
       o Masquerading: An entity pretends to be a different entity.
          This includes masquerading other users and subnetwork control
          plane messages.
       o Modification of messages in an unauthorised manner.
       o Replay attacks: When an intruder sends some old (authentic)
          messages to the Receiver. In the case of a broadcast link,
          access to previous broadcast data is easy.
       o Denial of Service attacks: When an entity fails to perform its
          proper function or acts in a way that prevents other entities
          from performing their proper functions.
       The active threats mentioned above are major security concerns
       for the Internet community [BELLOVIN]. The defense against
       majority of these active attacks is data integrity using
    Cruickshank           Expires November 10, 2007           [Page 9]

    Internet-Draft      Security Requirements for ULE     May 2007
       cryptographic techniques and sequence numbers. Also intrusion
       detection systems coupled with perimeter security policy are
       needed to monitor most denial of service attacks.
       Masquerading and modification of IP packets are comparatively
       easy in an Internet environment whereas such attacks are in fact
       much harder for broadcast links. This could for instance motivate
       the use of sequence numbers in IPsec, but not the mandatory use
       of them on synchronous links and this is further reflected in the
       security requirements for Case 2 and 3 in section 4 below.
       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.
    3.3. Threat Scenarios
       Analysing the topological scenarios for MPEG-2 Transmission
       Networks in section 1, the security threat cases can be
       abstracted into three cases:
       o Case 1: Monitoring (passive threat). Here the intruder
          monitors the ULE broadcasts to gain information about the ULE
          data and/or tracking the communicating parties identities (by
          monitoring the destination NPA). In this scenario, measures
          must be taken to protect the ULE data flow and the identity of
          ULE Receivers.
       o Case 2: Locally conduct active attacks on the MPEG-TS
          multiplex. Here an intruder is assumed to be sufficiently
          sophisticated to over-ride the original transmission from the
          ULE Encapsulation Gateway and deliver a modified version of
          the MPEG-TS transmission to a single ULE Receiver or a small
          group of Receivers (e.g. in a single company site). The MPEG
          transmission network operator might not be aware of such
          attacks. Measures must be taken to ensure ULE source
          authentication and preventing replay of old messages.
       o Case 3: Globally conduct active attacks on the MPEG-TS
          multiplex. Here we assume an intruder is very sophisticated
    Cruickshank           Expires November 10, 2007           [Page 10]

    Internet-Draft      Security Requirements for ULE     May 2007
          and able to over-ride the whole MPEG transmission multiplex.
          The requirements here are similar to scenario 2. The MPEG
          transmission network operator can usually identify such
          attacks and may resort to some means to restore the original
       For both cases 2 and 3, there can be two sub cases:
       o Insider attacks i.e. active attacks from adversaries in the
       known of secret material.
       o Outsider attacks i.e. active attacks from outside of a virtual
       private network.
       In terms of priority, case 1 is considered the major threat in
       MPEG transmission systems. Case 2 is likely to a lesser degree
       within certain network configurations, especially when there are
       insider attacks. Hence, protection against such active attacks
       should be used only when such a threat is a real possibility.
       Case 3 is envisaged to be less practical, because it will be very
       difficult to pass unnoticed by the MPEG transmission operator. It
       will require restoration of the original transmission. The
       assumption being here is that physical access to the network
       components (multiplexors, etc) and/or connecting physical media
       is secure. Therefore case 3 is not considered further in this
    4. Security Requirements for IP over MPEG-2 TS
       From the threat analysis in section 3, the following security
       requirements can be derived:
       o Data flow confidentiality is the major requirement to mitigate
          passive threats in MPEG-2 broadcast networks.
       o Protection of Layer 2 NPA address. In broadcast networks this
          protection can be used to prevent an intruder tracking the
          identity of ULE Receivers and the volume of their traffic.
       o Integrity protection and authentication of the ULE source is
          required against active attacks described in section 3.2.
       o Protection against replay attacks. This is required for the
          active attacks described in section 3.2.
       o Layer L2 ULE Source and Receiver authentication: This is
          normally performed during the initial key exchange and
    Cruickshank           Expires November 10, 2007           [Page 11]

    Internet-Draft      Security Requirements for ULE     May 2007
          authentication phase, before the ULE Receiver can join a
          secure session with the ULE Encapsulator (ULE source). This is
          normally receiver to hub authentication and it could be either
          one 0-drectional or bidirectional authentication based on the
          underlying key management protocol.
       Other general requirements are:
       o Decoupling of ULE key management functions from ULE security
          services such as encryption and source authentication. This
          allows the independent development of both systems.
       o Support for automated as well as manual insertion of keys and
          policy into the relevant databases.
       o Algorithm agility is needed. Changes in crypto algorithms,
          hashes as they become obsolete should be updated without
          affecting the overall security of the system.
       o Traceability: To monitor transmission network using log files
          to record the activities in the network and detect any
       o Protection against loss of service (availability) through
          malicious reconfiguration of system components (see Figure 1).
       o Secure Policy management
       o Compatibility with other networking functions such as NAT
          Network Address Translation (NAT) [RFC3715] or TCP
          acceleration can be used in a wireless broadcast networks.
       o Compatibility and operational with ULE extension headers i.e.
          allow encryption of a compressed SNDU payload.
       Examining the threat cases in section 3.3, the security
       requirements for each case can be summarised as:
       o Case 1: Data flow confidentiality MUST be provided to prevent
          monitoring of the ULE data (such as user information and IP
          addresses). Protection of NPA addresses MAY be provided to
          prevent tracking ULE Receivers and their communications.
       o Case 2: In addition to case 1 requirements, new measures need
          to be implemented such as authentication schemes using Message
          Authentication Codes, digital signatures or TESLA [RFC4082]
          and using sequence numbers to prevent replay attacks in terms
    Cruickshank           Expires November 10, 2007           [Page 12]

    Internet-Draft      Security Requirements for ULE     May 2007
          of insider attacks. In terms of outsider attacks group
          authentication using Message Authentication Codes should
          provide the same level of security. This will significantly
          reduce the ability of intruders to inject their own data into
          the MPEG-TS stream. However, scenario 2 threats apply only in
          specific service cases and therefore source authentication and
          protection against replay attacks are OPTIONAL. Such measures
          incur transmission of additional overhead and additional
          processing overheads. Moreover intrusion detection may also be
          needed by the MPEG-2 network operator.
       o Case 3: As stated in section 3.3. The requirements here are
          similar to Case 2 but since the MPEG transmission network
          operator can usually identify such attacks the constraints on
          intrusion detections are less than in case 2.
    4.1. Compatibility with Generic Stream Encapsulation
       The draft-ietf-ipdvb-ule-ext-01.txt document [ID-EF] describes
       two new Header Extensions that may be used with Unidirectional
       Link Encapsulation, ULE, [RFC4326] and the Generic Stream
       Encapsulation (GSE) that has been designed for the Generic Mode
       (also known as the Generic Stream (GS), offered by second-
       generation DVB physical layers, and specifically for DVB-S2 [ID-
       The security threats and requirement presented in this document
       are applicable to ULE and GSE encapsulations. It might be
       desirable to authenticate some/all of the headers; such decision
       can be part of the security policy for the MPEG2 transmission
    5. IPsec and MPEG-2 Transmission Networks
       The security architecture for the Internet Protocol [RFC4301]
       describes security services for traffic at the IP layer. This
       architecture primarily defines services for the Internet Protocol
       (IP) unicast packets, as well as manually configured IP multicast
       It is possible to use IPsec to secure ULE links. The major
       advantage of IPsec is its wide implementation in IP routers and
       hosts. IPsec in transport mode can be used for end-to-end
       security transparently over MPEG-2 transmission links with little
       In the context of MPEG-2 transmission links, if IPsec is used to
    Cruickshank           Expires November 10, 2007           [Page 13]

    Internet-Draft      Security Requirements for ULE     May 2007
       secure a ULE link, then the ULE Encapsulator and Receivers are
       equivalent to the security gateways in IPsec terminology. A
       security gateway implementation of IPsec uses tunnel mode. Such
       usage has the following disadvantages:
       o There is an extra transmission overhead associated with using
          IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6).
       o There is a need to protect the identity (NPA) of ULE Receivers
          over the ULE broadcast medium; IPsec is not suitable for
          providing this service. In addition, the interfaces of these
          devices do not necessarily have IP addresses (they can be L2
       o Multicast is considered a major service over ULE links. The
          current IPsec specifications [RFC4301] only define a pairwise
          tunnel between two IPsec devices with manual keying. Work is
          in progress in defining the extra detail needed for multicast
          and to use the tunnel mode with address preservation to allow
          efficient multicasting. For further details refer to [WEIS06].
    6. Motivation for ULE link-layer security
       Examination of the threat analysis and security requirements in
       sections 3 and 4 has shown that there is a need to provide link-
       layer (L2) security in MPEG-2 transmission networks employing
       ULE link security (between a ULE Encapsulation Gateway to
       Receivers) is therefore considered an additional security
       mechanism to IPsec, TLS, and application layer security, not a
       replacement. It allows a network operator to provide similar
       functions to that of IPsec [RFC4301], but in addition provides
       MPEG-2 transmission link confidentiality and protection of ULE
       Receiver identity (NPA).
       A modular design to ULE Security may allow it to use and benefit
       from IETF key management protocols, such as GSAKMP [RFC4535] and
       GDOI [RFC3547] protocols defined by the IETF Multicast Security
       (MSEC) working group. This does not preclude the use of other key
       management methods in scenarios where this is more appropriate.
    6.1. Link security below the Encapsulation layer
       Link layer security can be provided at the MPEG-TS layer (below
       ULE. MPEG-TS encryption encrypts all TS Packets sent with a
       specific PID value. However, an MPEG-TS may typically multiplex
    Cruickshank           Expires November 10, 2007           [Page 14]

    Internet-Draft      Security Requirements for ULE     May 2007
       several IP flows, belonging to different users, using a common
       PID. Therefore all multiplexed traffic will share the same
       security keys.
       This has the following advantages:
       o The bit stream sent on the broadcast network does not expose
          any L2 or L3 headers, specifically all addresses, type fields,
          and length fields are encrypted prior to transmission.
       o This method does not preclude the use of IPsec, or any other
          form of higher-layer security.
       However it has the following disadvantages:
       o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with
          a matching PID, possibly including those that are not required
          to be forwarded. Therefore it does not have the flexibility to
          separately secure individual IP flows.
       o ULE Receivers will have access to private traffic destined to
          other ULE Receivers, since they share a common PID and key.
       o Encryption of the MPE NPA address is not permitted in such
       o IETF-based key management are not used in existing systems.
          Existing access control mechanisms have limited flexibility in
          terms of controlling the use of key and rekeying. Therefore if
          the key is compromised, then this will impact several ULE
       Currently there are few deployed L2 security systems for MPEG
       transmission networks. Conditional access for digital TV
       broadcasting is one example. However, this approach is optimised
       for TV services and is not well-suited to IP packet transmission.
       Some other systems are specified in standards such as MPE [ETSI-
       DAT], but there are currently no known implementations.
    6.2. Link security as a part of the encapsulation layer
       Examining the threat analysis in section 3 has shown that
       protection of ULE link from eavesdropping and ULE Receiver
       identity are major requirements.
       There are several major advantages in using ULE link layer
    Cruickshank           Expires November 10, 2007           [Page 15]

    Internet-Draft      Security Requirements for ULE     May 2007
       o The protection of the complete ULE Protocol Data Unit (PDU)
          including IP addresses. The protection can be applied either
          per IP flow or per Receiver NPA address.
       o Ability to protect the identity of the Receiver within the
          MPEG-2 transmission network at the IP layer and also at L2.
       o Efficient protection of IP multicast over ULE links.
       o Transparency to the use of Network Address Translation (NATs)
          [RFC3715] and TCP Performance Enhancing Proxies (PEP)
          [RFC3135], which require the ability to inspect and modify the
          packets sent over the ULE link.
       This method does not preclude the use of IPsec at L3 (or TLS
       [RFC4346] at L4). IPsec and TLS provide strong authentication of
       the end-points in the communication. This authentication is
       desirable in many scenarios to ensure that the correct
       information is being exchanged between the trusted entities,
       whereas Layer 2 methods cannot provide this guarantee.
       L3 end-to-end security would partially deny the advantage listed
       just above (use of PEP, compression etc), since those techniques
       could only be applied to TCP packets bearing a TCP-encapsulated
       IPsec packet exchange, but not the TCP packets of the original
       applications, which in particular inhibits compression.
       IPsec /TLS also provide a proven security architecture defining
       key exchange mechanisms and the ability to use a range of
       cryptographic algorithms. ULE security can make use of these
       established mechanisms and algorithms but the advantages are
       distinct from those when using IPsec or TLS.
    7. Summary
       This document analyses a set of threats and security
       requirements. It also defines the requirements for ULE security
       and states the motivation for link security as a part of the
       Encapsulation layer.
       ULE security includes a need to provide link-layer encryption and
       ULE Receiver identity protection. There is an optional
       requirement for link-layer authentication and integrity assurance
       as well as protection against insertion of old (duplicated) data
       into the ULE stream (i.e. replay protection). This is optional
       because of the associated overheads for the extra features and
       they are only required for specific service cases.
    Cruickshank           Expires November 10, 2007           [Page 16]

    Internet-Draft      Security Requirements for ULE     May 2007
       Annexe 1 describes a set of building blocks that may be used to
       realise a framework that provides these security functions.
    8. Security Considerations
       Link-layer (L2) encryption of IP traffic is commonly used in
       broadcast/radio links to supplement End-to-End security (e.g.
       provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). A
       common objective is to provide the same level of privacy as wired
       links. An ISP or User may also wish to provide end-to-end
       security services to the end-users (based on well known
       mechanisms such as IPsec or TLS).
       This document provides a threat analysis and derives the security
       requirements to provide optional link encryption and link-layer
       integrity / authentication of the SNDU payload.
       There are some security issues that were raised in RFC 4326
       [RFC4326] that are not addressed in this document (out of scope)
       such as:
       o The security issue with un-initialised stuffing bytes.  In
          ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
       o Integrity issues related to the removal of the LAN FCS in a
          bridged networking environment.  The removal for bridged
          frames exposes the traffic to potentially undetected
          corruption while being processed by the Encapsulator and/or
       o There is a potential security issue when a Receiver receives a
          PDU with two Length fields:  The Receiver would need to
          validate the actual length and the Length field and ensure
          that inconsistent values are not propagated by the network.
    9. IANA Considerations
       This document does not define any protocol and does not require
       any IANA assignments but a subsequent document that defines a
       layer 2 security extension to ULE will require IANA involvement.
    10. Acknowledgments
       The authors acknowledge the help and advice from Gorry Fairhurst
       (University of Aberdeen). The authors also acknowledge
    Cruickshank           Expires November 10, 2007           [Page 17]

    Internet-Draft      Security Requirements for ULE     May 2007
       contributions from Stephane Coombes (ESA) and Yim Fun Hu
       (University of Bradford).
    11. References
    11.1. Normative References
       [ISO-MPEG2] "Information technology -- generic coding of moving
                   pictures and associated audio information systems,
                   Part I", ISO 13818-1, International Standards
                   Organisation (ISO), 2000.
       [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, 1997.
    11.2. Informative References
       [ID-AR]    G. Fairhurst, M-J Montpetit "Address Resolution
                   Mechanisms for IP Datagrams over MPEG-2 Networks",
                   Work in Progress <draft-ietf-ipdvb-ar-05.txt.
       [IEEE-802]  "Local and metropolitan area networks-Specific
                   requirements Part 2: Logical Link Control", IEEE
                   802.2, IEEE Computer Society, (also ISO/IEC 8802-2),
       [ISO-8802]  ISO/IEC 8802.2, "Logical Link Control", International
                   Standards Organisation (ISO), 1998.
       [ITU-H222] H.222.0, "Information technology, Generic coding of
                   moving pictures and associated audio information
                   Systems", International Telecommunication Union,
                   (ITU-T), 1995.
       [RFC4259]  Montpetit, M.-J., Fairhurst, G., Clausen, H.,
                   Collini-Nocker, B., and H. Linder, "A Framework for
                   Transmission of IP Datagrams over MPEG-2 Networks",
                   IETF RFC 4259, November 2005.
       [RFC4326]  Fairhurst, G. and B. Collini-Nocker, "Unidirectional
                   Lightweight Encapsulation (ULE) for Transmission of
                   IP Datagrams over an MPEG-2 Transport Stream (TS)",
                   IETF RFC 4326, December 2005.
       [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
                   Specifications for Data Broadcasting", European
                   Telecommunications Standards Institute (ETSI).
    Cruickshank           Expires November 10, 2007           [Page 18]

    Internet-Draft      Security Requirements for ULE     May 2007
       [BELLOVIN]  S.Bellovin, "Problem Area for the IP Security
                   protocols", Computer Communications Review 2:19, pp.
                   32-48, April 989. http://www.cs.columbia.edu/~smb/
       [RFC4082]  A. Perrig, D. Song, " Timed Efficient Stream Loss-
                   Tolerant Authentication (TESLA): Multicast Source
                   Authentication Transform Introduction", IETF RFC
                   4082, June 2005.
       [RFC4535]  H Harney, et al, "GSAKMP: Group Secure Association
                   Group Management Protocol", IETF RFc 4535, June 2006.
       [RFC3547]  M. Baugher, et al, "GDOI: The Group Domain of
                   Interpretation", IETF RFC 3547.
       [WEIS06]   Weis B., et al, "Multicast Extensions to the Security
                   Architecture for the Internet", <draft-ietf-msec-
                   ipsec-extensions-02.txt>, June 2006, IETF Work in
       [RFC3715]  B. Aboba and W Dixson, "IPsec-Network Address
                   Translation (NAT) Compatibility Requirements" IETF
                   RFC 3715, March 2004.
       [RFC4346]  T. Dierks, E. Rescorla, "The Transport Layer Security
                   (TLS) Protocol Version 1.1", IETF RFC 4346, April
       [RFC3135]  J. Border, M. Kojo, eyt. al., "Performance Enhancing
                   Proxies Intended to Mitigate Link-Related
                   Degradations", IETF RFC 3135, June 2001.
       [RFC4301]  Kent, S. and Seo K., "Security Architecture for the
                   Internet Protocol", IETF RFC 4301, December 2006.
       [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
                   Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
                   and L. Wood, "Advice for Internet Subnetwork
                   Designers", BCP 89, IETF RFC 3819, July 2004.
       [RFC4251]  T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH)
                   Protocol Architecture", IETF RFC 4251, January 2006.
       [ID-EF]    G. Fairhurst, "Extension Formats for the ULE
                   Encapsulation to support the Generic Stream
                   Encapsulation (GSE)", Work in Progress < draft-ietf-
    Cruickshank           Expires November 10, 2007           [Page 19]

    Internet-Draft      Security Requirements for ULE     May 2007
    Author's Addresses
       Haitham Cruickshank
       Centre for Communications System Research (CCSR)
       University of Surrey
       Guildford, Surrey, GU2 7XH
       Email: h.cruickshank@surrey.ac.uk
       Sunil Iyengar
       Centre for Communications System Research (CCSR)
       University of Surrey
       Guildford, Surrey, GU2 7XH
       Email: S.Iyengar@surrey.ac.uk
       Laurence Duquerroy
       Research Department/Advanced Telecom Satellite Systems
       Thales Alenia Space, Toulouse
       E-Mail: Laurence.Duquerroy@alcatelaleniaspace.com
       Prashant Pillai
       Mobile and Satellite Communications Research Centre
       School of Engineering, Design and Technology
       University of Bradford
       Richmond Road, Bradford BD7 1DP
       Email: P.Pillai@bradford.ac.uk
    12. IPR Notices
       Copyright (c) The IETF Trust (2007).
    12.1. Intellectual Property Statement
       Full Copyright Statement
       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.
       This document and the information contained herein are provided
    Cruickshank           Expires November 10, 2007           [Page 20]

    Internet-Draft      Security Requirements for ULE     May 2007
    12.2. Intellectual Property
       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be
       claimed to pertain to the implementation or use of the technology
       described in this document or the extent to which any license
       under such rights might or might not be available; nor does it
       represent that it has made any independent effort to identify any
       such rights.  Information on the procedures with respect to
       rights in RFC documents can be found in BCP 78 and BCP 79.
       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the
       use of such proprietary rights by implementers or users of this
       specification can be obtained from the IETF on-line IPR
       repository at http://www.ietf.org/ipr.
       The IETF invites any interested party to bring to its attention
       any copyrights, patents or patent applications, or other
       proprietary rights that may cover technology that may be required
       to implement this standard.  Please address the information to
       the IETF at ietf-ipr@ietf.org.
    13. Copyright Statement
       Copyright (C) The IETF Trust (2007).
       >>> NOTE to RFC Editor: Please remove this appendix prior to
    Document History
       Working Group Draft 00
       o Fixed editorial mistakes and ID style for WG adoption.
       Working Group Draft 01
    Cruickshank           Expires November 10, 2007           [Page 21]

    Internet-Draft      Security Requirements for ULE     May 2007
       o Fixed editorial mistakes and added an appendix which shows the
          preliminary framework for securing the ULE network.
       Working Group Draft 02
       o Fixed editorial mistakes and added some important changes as
          pointed out by Knut Eckstein (ESA), Gorry Fairhurst and
    Appendix A: ULE Security Framework
       This section aims to define a preliminary security framework for
       widespread deployment of secure ULE networks.
       Building Blocks
       This ULE Security framework defines the following building blocks
       as shown in figure 2 below:
       1. The Key Management Block
       2. The ULE Extension Header Block
       3. The ULE Databases Block
            +------+----------+              +----------------
            | Key Management  |/------------\| Key Management |
            |     Block       |\------------/|     Block      |
            | Group Member    |              |  Group Server  |
            +------+----------+              +----------------
                   | |
                   | |
                   | |
                   | |
                   | |
                   \ /
            |      ULE        |
            |   SAD / SPD     |
            | Interface Block |
                   / \
                   | |
                   | |
                   | |
                   | |
    Cruickshank           Expires November 10, 2007           [Page 22]

    Internet-Draft      Security Requirements for ULE     May 2007
                   | |
                   | |
           |   ULE Security  |
           | Extension Header|
           |     Block       |
       Figure 2: Secure ULE framework Building Blocks
            Key Management Block
       A key management framework is required to provide security at the
       ULE level using extension headers. In order to provide security
       at the ULE level using extension headers, a key management
       framework is required. This key management framework is
       responsible for user authentication, access control, and Security
       Association negotiation (which include the negotiations of the
       security algorithms to be used and the generation of the
       different session keys as well as policy material). This Key
       management framework can be either automated or manual. Hence
       this key management client entity will be present in all ULE
       receivers as well as at the ULE sources (encapsulation gateways).
       In some cases the ULE source could also be the Key Server Entity.
       Deployment may use either automated key management protocols
       (e.g. GSAKMP [RFC4535]) or manual insertion of keying material.
            ULE Extension Header Block
       A new security extension header for the ULE protocol is required
       to provide the security features of data confidentiality, data
       integrity, data authentication and mechanisms to prevent replay
       attacks. Security keying material will be used for the different
       security algorithms (for encryption/decryption, MAC generation,
       etc.), which are used to meet the security requirements,
       described in detail in Section 4 of this draft.
    This block will use the keying material and policy information from
    the ULE security database block on the ULE payload to generate the
    secure ULE Extension Header or to decipher the secure ULE extension
    header to get the ULE payload. An example overview of the ULE
    Security extension header format along with the ULE header and
    payload is shown in figure 3 below. There could be other extension
    headers (either mandatory or optional) but these will always be
    placed after the security extension header. In this way all
    extension headers (if any) follow the security extension header.
    When applying the security services for example confidentiality,
    input to the cipher algorithm will the cover the fields from the end
    Cruickshank           Expires November 10, 2007           [Page 23]

    Internet-Draft      Security Requirements for ULE     May 2007
    of the security extension header to the end of the PDU.
       | ULE   |SEC   |     Protocol Data Unit        |      |
       |Header |Header|                               |CRC-32|
       Figure 3: ULE Sec Header Extension Placement
            ULE Security Databases Block
       There needs to be two databases i.e. similar to the IPSec
       o ULE-SAD: ULE Secure Association Database contains all the
          Security Associations that are currently established with
          different ULE peers.
       o ULE-SPD: ULE Secure Policy Database contains the policies as
          defined by the system manager. Those policies describe the
          security services that must be enforced
       The design of these two databases will be based on IPSec
       databases as defined in RFC4301 [RFC4301].
       The exact details of the header patterns that the SPD and SAD
       will have to support for all use cases will be defined in a
       separate document. This document only highlights the need for
       such interfaces tot he ULE data plane and the Key Management
       control plane.
       Interface definition
       Two new interfaces have to be defined between the three blocks as
       shown in figure 2 above. These interfaces are:
       o Key management <-> ULE Security databases
       o ULE Security databases <-> ULE interfaces
       While the first interface is used by the Key Management Block to
       insert keys, security associations and policies into the ULE
       Database Block, the second interface is used by the ULE Extension
       Header Block to get the keys and policy material for the ULE
          Key management <-> ULE Security databases
    Cruickshank           Expires November 10, 2007           [Page 24]

    Internet-Draft      Security Requirements for ULE     May 2007
       This interface is between the Key Management client block (GM
       client) and the ULE Security Database block. The Key management
       client will communicate with the GCKS and then get the relevant
       security information (keys, cipher mode, security service,
       ULE_Security_ID and other relevant keying material as well as
       policy) and insert this data into the ULE Security database
       block. The ULE Security database block holds the records of all
       security associations currently used by an encapsulator (all
       channels) as well as information for security policy control. The
       Key management could be either automated (e.g. GSAKMP [RFC4535]
       or GDOI [RFC3547]) or manually inserted using this interface. The
       following three interface functions are defined:
       . Insert_record_database (char * Database, char * record, char *
       . Update_record_database (char * Database, char * record, char *
       . Delete_record_database (char * Database, char * Unique_ID);
       The definitions of the variables are as follows:
          . Database - This is a pointer to the ULE Security databases
          . record - This is the rows of security attributes to be
            entered or modified in the above databases
          . Unique_ID - This is the primary key to lookup records (rows
            of security attributes) in the above databases
          ULE Security Databases <-> ULE Interfaces
       This interface is between the ULE Security Database and the ULE
       Engine. To send traffic, firstly the ULE Engine using the
       Destination Address and the ULE_Security_ID searches the ULE
       Security Database for the relevant security record. It then uses
       the data in the record to create the ULE security extension
       header [this will be designed in a later draft]. For received
       traffic, the ULE engine on receiving the ULE packet will first
       get the record from the Security Database using the Destination
       Address and the ULE_Security_ID. It then uses this information to
       decrypt the ULE extension header.
       In both cases only one interface is needed since the only
       difference between the sender and receiver is the flow of
    Cruickshank           Expires November 10, 2007           [Page 25]

    Internet-Draft      Security Requirements for ULE     May 2007
       . Get_record_database (char * Database, char * record, char *
    Cruickshank           Expires November 10, 2007           [Page 26]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/