IPDVB Working Group                                   H. Cruickshank
Internet-Draft                                            S. Iyengar
Intended status: Informational              University of Surrey, UK
                                                           P. Pillai
Expires: April 12, October 4, 2008                  University of Bradford, UK
                                                November 18, 2007
                                                       April 4, 2008

       Security requirements for the Unidirectional Lightweight
                     Encapsulation (ULE) protocol
                 draft-ietf-ipdvb-sec-req-05.txt
                    draft-ietf-ipdvb-sec-req-06.txt

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

   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
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on May 12, October 4, 2008.

Abstract

   The MPEG-2 standard defined by ISO 13818-1 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) defined in RFC4326. The document also provides the
   motivation for link-layer 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.

Table of Contents

   1. Introduction................................................2
   2. Requirements notation.......................................4 notation.......................................3
   3. Threat Analysis.............................................6
      3.1. System Components......................................6
      3.2. Threats................................................9
      3.3. Threat Scenarios......................................10
   4. Security Requirements for IP over MPEG-2 TS................11
   5. Motivation for ULE link-layer security.....................13
   5.1. Security at the IP layer (using IPSEC)................13
   5.2. Link security below the Encapsulation layer...........14
   5.3. Link security as a part of the encapsulation layer....15
6. Design recommendations for ULE Security Header Extension...16
7. Extension...13
   6. Compatibility with Generic Stream Encapsulation............17 Encapsulation............14
   7. Summary....................................................14
   8. Summary....................................................17
9. Security Considerations....................................18
10. Considerations....................................15
   9. IANA Considerations.......................................18 Considerations........................................16
   10. Acknowledgments...........................................16
   11. Acknowledgments...........................................18
12. References................................................19
   12.1. References................................................16
      11.1. Normative References.................................19
   12.2. References.................................16
      11.2. Informative References...............................19
13. References...............................16
   12. Author's Addresses........................................21
14. Addresses........................................18
   13. IPR Notices...............................................21
   14.1. Notices...............................................18
      13.1. Intellectual Property Statement......................21
   14.2. Intellectual Property................................22
15. Statement......................19
   14. Copyright Statement.......................................22 Statement.......................................19
   Appendix A: ULE Security Framework............................22 Framework............................20
   Appendix B: Motivation for ULE link-layer security............24
   Document History..............................................28 History..............................................27

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
   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 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
   specification of the security functions from the encapsulation
   functions.

   This document extends the above analysis and derives a detailed
   the security requirements for ULE in MPEG-2 transmission
   networks.

   A security framework for deployment of secure ULE networks
   describing the different building blocks and the interface
   definitions is presented in Appendix A.

2. Requirements notation
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "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
   Channel.

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

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

   ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
   encapsulated PDUs. ULE Streams may be identified by definition of
   a stream_type in SI/PSI [ISO-MPEG2].

3. Threat Analysis

  3.1. System Components

     +------------+                                  +------------+
     |  IP        |                                  |  IP        |
     |  End Host  |                                  |  End Host  |
     +-----+------+                                  +------------+
           |                                                ^
           +------------>+---------------+                  |
                         +  IP  ULE          |                  |
           +-------------+  Encapsulator |                  |
   SI-Data |             +------+--------+                  |
   +-------+-------+            |MPEG-2 TS Logical Channel  |
   |  MPEG-2       |            |                           |
   |  SI Tables    |            |                           |
   +-------+-------+   ->+------+--------+                  |
           |          -->|  MPEG-2       |                . . .
           +------------>+  Multiplexer  |                  |
   MPEG-2 TS             +------+--------+                  |
   Logical Channel              |MPEG-2 TS Mux              |
                                |                           |
              Other    ->+------+--------+                  |
              MPEG-2  -->+  MPEG-2       |                  |
              TS     --->+  Multiplexer  |                  |
                    ---->+------+--------+                  |
                                |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]. (adapted from [RFC4259]).

   As shown in Figure 1 above (from section 3.3 of [RFC4259]), there
   are several entities within the MPEG-2 transmission network
   architecture. These include:

   o  ULE Encapsulation Gateways (the Encapsulator or ULE source) Encapsulator)

   o  SI-Table signalling generator (input to the multiplexer)
   o  Receivers (the end points for ULE streams)

   o  TS multiplexers (including re-multiplexers)

   o  Modulators

   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.

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

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

   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 network, i.e. supporting its
   security objectives in the area of availability, in addition to
   confidentiality and integrity. One method recently proposed [ID-
   EXT] 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) Encapsulator) and the Receiver. In
   many deployment scenarios the user of a ULE Stream has to secure
   communications beyond the link since other network links are
   utilised in addition to the ULE link. Therefore, if
   authentication of the end-point i.e. the IP Sources is required,
   or users are concerned about loss of confidentiality, integrity
   or authenticity of their communication data, they will have to
   employ end-to-end network security mechanisms like IPSec or
   Transport Layer Security (TLS). Governmental users may be forced
   by regulations to employ specific, approved implementations of
   those mechanisms. Hence for such cases the confidentiality and
   integrity of the user data will already be taken care of by the
   end-to-end security mechanism and the ULE security measures would
   focus on either providing traffic flow confidentiality for user
   data that has already been encrypted or for users who choose not
   to implement end-to-end security mechanisms.

   ULE links may also be used for communications where the two end-
   points are not under central control (e.g., when browsing a
   public web site). In these cases, it may be impossible to enforce
   any end-to-end security mechanisms. Yet, a common objective is
   that users can rely on security assumptions as of wired links.
   ULE security could achieve this by protecting the vulnerable (in
   terms of passive attacks) ULE link.

   In contrast to the above, if a ULE Stream is used to directly
   join networks which are considered physically secure, for example
   branch offices to a central office, ULE link Security 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
   manufacturer of ULE Link Security equipment obtains governmental
   approval for their implementation.

  3.2. Threats

   The simplest type of network threat is a passive threat. This
   includes eavesdropping or monitoring of transmissions, with a
   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.

   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]. Masquerading and
   modification of IP packets are comparatively easy in an Internet
   environment whereas such attacks are in fact much harder for
   MPEG-2 broadcast links. This could for instance motivate the
   mandatory use of sequence numbers in IPsec, but not for
   synchronous links. This is further reflected in the security
   requirements for Case 2 and 3 in section 4 below.

   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.

  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 payload data 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-2
      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
      and able to over-ride the whole MPEG-2 transmission multiplex.
      The requirements here are similar to scenario 2. The MPEG-2
      transmission network operator can usually identify such
      attacks and may resort to some means to restore the original
      transmission.

   For both cases 2 and 3, there can be two sub cases:

Cruickshank et.al.         Expires April 12, 2008           [Page
10]

   o  Insider attacks i.e. active attacks from adversaries in within
   the
known network with knowledge of the 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-2 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-2 transmission operator.
   It will require restoration of the original transmission. The
   assumption being here is that physical access to the network
   components (multiplexers, etc) and/or connecting physical media
   is secure. Therefore case 3 is not considered further in this
   document.

4. Security Requirements for IP over MPEG-2 TS

   From the threat analysis in section 3, the following security
   requirements can be derived:

o

   Req 1. Data confidentiality is the major requirement MUST be considered in order to
     mitigate passive and active threats in MPEG-2 broadcast
     networks.

o

   Req 2. Protection of Layer 2 NPA address. address MAY be provided. 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

   Req 3. Integrity protection and authentication of the ULE source is
   required against
     MAY be provided to prevent active attacks described in section
     3.2.

o

   Req 4. Protection against replay attacks. attacks MAY be provided. This is
     required for the active attacks described in section 3.2.

o

   Req 5. Layer L2 ULE Source and Receiver authentication: authentication MAY be
     provided. This is normally performed during the initial key
     exchange and 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 unidirectional or bidirectional authentication based
     on the underlying key management protocol.

   Other general requirements are:

Cruickshank et.al.         Expires April 12, 2008           [Page
11]

o  Decoupling of

   GReq (a) ULE key management functions SHALL be decoupled from ULE
    security services such as encryption and source authentication.
    This allows the independent development of both systems.

o

   GReq (b) Support SHOULD be provided for automated as well as
    manual insertion of keys and policy into the relevant
    databases.

o

   GReq (c) Algorithm agility is needed. MUST be supported. Changes in crypto
    algorithms, hashes as they become obsolete should be updated
    without affecting the overall security of the system.

o  Traceability: To

   GReq (d) Traceability SHOULD be supported to monitor the
    transmission network using log files to record the activities
    in the network and detect any intrusion.

o

   GReq (e) Protection against loss of service (availability)
    through malicious reconfiguration of system components (see
    Figure 1).

o  Compatibility 1) MUST be present.

   GReq (f) The security system MUST be compatible 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

   GReq (g) The security extension header MUST be compatible with
    other ULE extension headers i.e.
   allow encryption of a compressed SNDU payload.

o

   GReq (h) 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 MAY
    therefore be required, at least permitting control of data
    confidentiality/authorisation at the level of a single MAC/NPA
    address.

   Examining the threat cases in section 3.3, the security
   requirements for each case can be summarised as:

   o  Case 1: Data confidentiality (Req 1) MUST be provided to
      prevent monitoring of the ULE data (such as user information
      and IP addresses). Protection of NPA addresses (Req 2) MAY be
      provided to prevent tracking ULE Receivers and their
      communications.

   o  Case 2: In addition to case 1 requirements, new measures need
   to MAY
      be  implemented such as authentication schemes using Message
      Authentication Codes, digital signatures or TESLA [RFC4082] in
      order to provide integrity protection and source

Cruickshank et.al.         Expires April 12, 2008           [Page
12]
   authentication,
      authentication (Req 2, Req 3 and using Req 5). In addition sequence
      numbers (Req 4) MAY be used to protect against replay attacks.
      In terms of outsider attacks, group authentication using
      Message Authentication Codes should provide the same level of security.
      security (Req 3 and 5). This will significantly reduce the
      ability of intruders to successfully inject their own data
      into the MPEG-TS stream. However, scenario 2 threats apply
      only in specific service cases, and therefore authentication
      and protection against replay attacks are OPTIONAL. Such
      measures incur additional transmission as well as processing
      overheads. Moreover, intrusion detection systems may also be
      needed by the MPEG-2 network operator. These should best be
      coupled with perimeter security policy to monitor most denial-of-service denial-
      of-service attacks.

   o  Case 3: As stated in section 3.3. The 3.3, the requirements here are
      similar to Case 2 but since the MPEG-2 transmission network
      operator can usually identify such attacks the constraints on
      intrusion detections are less than in case 2.

   The general requirements GReq(a) to GReq(h) are good security
   practices and apply to all the scenarios above, where
   appropriate.

5. Motivation Design recommendations for ULE link-layer security

Examination of Security Header Extension

   Table 1 below shows the threat analysis and security requirements in
sections 3 and 4 has shown threats that there is a need are applicable to provide
security in MPEG-2 transmission ULE
   networks employing ULE. This
section compares and the disadvantages when relevant security functionalities
are present mechanism to mitigate those
   threats. This would help in different layers.

5.1. the design of the ULE Security at
   extension header. For example this could help in the IP layer (using IPSEC)

The selection of
   security architecture for fields in the Internet Protocol [RFC4301]
describes security services for traffic at ULE Security extension Header design.
   Moreover the IP layer. This
architecture primarily defines security services for could also be grouped into
   profiles based on different security requirements. One example is
   to have a base profile which does payload encryption and identity
   protection. The second profile could do the Internet Protocol
(IP) unicast packets, above as well as manually configured IP multicast
packets.

It is possible to use IPsec
   source authentication.

   A modular design to secure ULE links. The major
advantage 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 IPsec is its wide implementation other key
   management methods in IP routers and
hosts. scenarios where this is more appropriate.

   IPsec in transport mode can be used for end-to-end or TLS also provide a proven security transparently over MPEG-2 transmission links with little
impact.

In architecture defining
   key exchange mechanisms and the context of MPEG-2 transmission links, if IPsec is used ability to
secure use a range of
   cryptographic algorithms. ULE link, then the ULE Encapsulator and Receivers are
equivalent to the security gateways in IPsec terminology. A security gateway implementation can make use of IPsec uses tunnel mode. Such
usage has the following disadvantages:

Cruickshank et.al.         Expires April 12, 2008           [Page
13]

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

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

5.2. Link security below the Encapsulation layer

Link layer security can be provided at the MPEG-2 TS layer (below
ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
specific PID value. However, an MPEG-2 TS may typically multiplex
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, TLS, or any
   other form of higher-layer security.

However it has the following disadvantages:

o  When a PID is shared between several users, 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  When a PID is shared between several users, the ULE Receivers
   will have access to private traffic destined to other ULE
   Receivers, since they share a common PID and key.

Cruickshank et.al.         Expires April 12, 2008           [Page
14]

o  IETF-based key management is 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
   Receivers.

Currently there are few deployed L2 security systems for MPEG-2
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.

5.3. 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
security:

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.

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.

Cruickshank et.al.         Expires April 12, 2008           [Page
15]

End-to-end security (IPsec, TLS, etc.) may be used independently
to 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 parties, whereas Layer 2 methods cannot provide this
guarantee.

6. Design recommendations for ULE Security Header Extension

Table 1 below shows the threats that are applicable to ULE
networks and the relevant security mechanism to mitigate those
threats. This would help in the design of the ULE Security
extension header. For example this could help in the selection of
security fields in the ULE Security extension Header design.
Moreover the security services could also be grouped into
profiles based on different security requirements. One example is
to have a base profile which does payload encryption these
   established mechanisms and identity
protection. The second profile could do the above as well as
source authentication. algorithms.

                                        Mitigation of Threat
                    -----------------------------------------------
                   | Data   | Data  |Source |Data   |Intru  |Iden  |
                   |Privacy | fresh |Authent|Integ  |sion   |tity  |
                   |        | ness  |ication|rity   |Dete   |Prote |
                   |        |       |       |       |ction  |ction |
     Attack        |        |       |       |       |       |      |
    ---------------|--------|-------|-------|-------|-------|------|
   | Monitoring    |   X    |   -   |   -   |   -   |   -   |  X   |
   |---------------------------------------------------------------|
   | Masquerading  |   X    |   -   |   X   |   X   |   -   |  X   |
   |---------------------------------------------------------------|
   | Replay Attacks|   -    |   X   |   X   |   X   |   X   |  -   |
   |---------------------------------------------------------------|
   | Dos Attacks   |   -    |   X   |   X   |   X   |   X   |  -   |
   |---------------------------------------------------------------|
   | Modification  |   -    |   -   |   X   |   X   |   X   |  -   |
   | of Messages   |        |       |       |       |       |      |
    ---------------------------------------------------------------
            Table 1: Security techniques to mitigate network threats
                            in ULE Networks.
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.

Cruickshank et.al.         Expires April 12, 2008           [Page
16]

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

7.

6. Compatibility with Generic Stream Encapsulation

   The [ID-EXT] document 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-EXT].

   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 MPEG-2 transmission
   network.

8.

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.

   ULE link security (between a ULE Encapsulation Gateway to
   Receivers) is considered as an additional security mechanism to
   IPsec, TLS, and application layer end-to-end security, and not as
   a replacement. It allows a network operator to provide similar
   functions to that of IPsec, but in addition provides MPEG-2
   transmission link confidentiality and protection of ULE Receiver
   identity (NPA). End-to-end security mechanism may then be used
   additionally and independently for providing strong
   authentication of the end-points in the communication.

   Annexe 1 describes a set of building blocks that may be used to

Cruickshank et.al.         Expires April 12, 2008           [Page
17]
   realise a framework that provides ULE security functions.

9.

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. It is recommended that an ISP or user provide end-
   to-end security services based on well known mechanisms such as
   IPsec or TLS.

   This document provides a threat analysis and derives the security
   requirements to provide link encryption and optional 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
      Receiver.

   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.

10.

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

   There are no IANA involvement.

11. actions defined in this document.

10. Acknowledgments

   The authors acknowledge the help and advice from Gorry Fairhurst
   (University of Aberdeen). The authors also acknowledge
   contributions from Laurence Duquerroy and Stephane Coombes (ESA),

Cruickshank et.al.         Expires April 12, 2008           [Page
18]
   Yim Fun Hu (University of Bradford) and Michael Noisternig from
   University of Salzburg.

12.

11. References

12.1.

  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.

12.2.

  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.

   [ID-EXT]    G. Fairhurst and B. Collini-Nocker, "Extension
               Formats for Unidirectional Lightweight Encapsulation
               (ULE) and the Generic Stream Encapsulation (GSE)",
               Work in Progress, draft-ietf-ipdvb-ule-ext-06.txt,
            August 2007. draft-ietf-ipdvb-ule-ext-07.txt,
               January 2008.

   [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),
               1998.

   [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

Cruickshank et.al.         Expires April 12, 2008           [Page
19]
            Lightweight Encapsulation (ULE) for Transmission of
            IP Datagrams over an MPEG-2 Transport Stream (TS)", 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).

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

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

   [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 4326, December 2005.

[ETSI-DAT]  EN 301 192, "Digital Video Broadcasting (DVB); DVB
            Specifications 4251, January 2006.

12. Author's Addresses

   Haitham Cruickshank
   Centre for Data Broadcasting", European
            Telecommunications Standards Institute (ETSI).

[BELLOVIN]  S.Bellovin, "Problem Area Communications System Research (CCSR)
   University of Surrey
   Guildford, Surrey, GU2 7XH
   UK
   Email: h.cruickshank@surrey.ac.uk

   Sunil Iyengar
   Centre 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", System Research (CCSR)
   University of Surrey
   Guildford, Surrey, GU2 7XH
   UK
   Email: S.Iyengar@surrey.ac.uk

   Prashant Pillai
   Mobile and Satellite Communications Research Centre (MSCRC)
   School of Engineering, Design and Technology
   University of Bradford
   Richmond Road, Bradford BD7 1DP
   UK
   Email: p.pillai@bradford.ac.uk

13. IPR Notices

   Copyright (c) The IETF RFc 4535, June 2006.

[RFC3547]   M. Baugher, et al, "GDOI: Trust (2007).

  13.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
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.

   Intellectual Property Statement

   The Group Domain of
            Interpretation", IETF RFC 3547.

[WEIS06]    Weis B., et al, "Multicast Extensions takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be
   claimed to pertain to the Security
            Architecture for implementation or use of the Internet", <draft-ietf-msec-
            ipsec-extensions-02.txt>, June 2006, IETF Work technology
   described in
            Progress.

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

[RFC3135]   J. Border, M. Kojo, eyt. al., "Performance Enhancing
            Proxies Intended this document or the extent to Mitigate Link-Related
            Degradations", IETF RFC 3135, June 2001.

[RFC4301]   Kent, S. and Seo K., "Security Architecture for 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
            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

Cruickshank et.al.         Expires April 12, 2008           [Page
20]
            Designers", BCP 89, IETF RFC 3819, July 2004.

[RFC4251]   T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH)
            Protocol Architecture", IETF procedures with respect to
   rights in RFC 4251, January 2006.

13. Author's Addresses

Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: h.cruickshank@surrey.ac.uk

Sunil Iyengar
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: S.Iyengar@surrey.ac.uk

Prashant Pillai
Mobile documents can be found in BCP 78 and Satellite Communications Research Centre (MSCRC)
School BCP 79.

   Copies of Engineering, Design IPR disclosures made to the IETF Secretariat and Technology
University any
   assurances of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: p.pillai@bradford.ac.uk

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

Copyright (c)
   repository at http://www.ietf.org/ipr.

   The IETF Trust (2007).

14.1. Intellectual Property Statement

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

14. Copyright Statement

   Copyright (C) The IETF Trust (2007).

This document is subject IETF Trust (2008).

Appendix A: ULE Security Framework

   This section defines a security framework for the deployment of
   secure ULE networks.

A.1 Building Blocks

   This ULE Security framework defines the following building blocks
   as shown in figure 2 below:

   o  The Key Management Block

   o  The ULE Security Extension Header Block

   o  The ULE Databases Block

   Within the Key Management block the communication between the
   Group Member entity and the Group Server entity happens in the
   control plane. The ULE Security header block applies security to
   the rights, licenses ULE SNDU and restrictions
contained this happens in BCP 78, and except the ULE data plane. The ULE
   Security databases block acts as set forth therein, the authors
retain all their rights.

Cruickshank et.al.         Expires April 12, 2008           [Page
21]

This document and interface between the information contained herein are provided on an
"AS IS" basis Key
   management block (control plane) and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR the ULE Security Header
   block (ULE data plane) as shown in figure 2.

                                                             ------
     +------+----------+           +----------------+           / \
     | Key Management  |/---------\| Key Management |            |
     |     Block       |\---------/|     Block      |            |
     |  Group Member   |           |  Group Server  |        Control
     +------+----------+           +----------------+          Plane
            | |                                                  |
            | |                                                  |
            | |                                                 \ /
     ----------- Key management <-> ULE Security databases     -----
            | |
            \ /
     +------+----------+
     |      ULE        |
     |   SAD / SPD     |
     |    Databases    |
     |      Block      |
     +------+-+--------+
            / \
            | |
    ----------- ULE Security databases <-> ULE Security Header ----
            | |                                                 / \
            | |                                                  |
            | |                                                  |
     +------+-+--------+                                    ULE Data
     |   ULE Security  |                                       Plane
     | Extension Header|                                         |
     |     Block       |                                         |
     +-----------------+                                        \ /
                                                               -----

                Figure 2: Secure ULE Framework Building Blocks

   A.1.1 Key Management Block

   A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding key management framework is required to provide security at the validity or scope
   ULE level using extension headers. This key management framework
   is responsible for user authentication, access control, and
   Security Association negotiation (which include the negotiations
   of any
Intellectual Property Rights or other rights that might be claimed to
pertain the security algorithms to be used and the implementation or use generation of the technology described in
this document
   different session keys as well as policy material). The Key
   management framework can be either automated or manual. Hence
   this key management client entity (shown as the extent to which any license under such rights
might or might not Key Management
   Group Member block in figure 2) will 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 present in RFC documents can all ULE
   receivers as well as at the ULE Encapsulators. The ULE
   Encapsulator could also be
found the Key Management Group Server Entity
   (shown as the Key Management Group Server block in BCP 78 and BCP 79.

Copies figure 2. This
   happens when the ULE Encapsulator also acts as the Key Management
   Group Server. Deployment may use either automated key management
   protocols (e.g. GSAKMP [RFC4535]) or manual insertion of IPR disclosures made keying
   material.

   A.1.2 ULE Extension Header Block

   A new security extension header for the ULE protocol is required
   to provide the IETF Secretariat security features of data confidentiality, data
   integrity, data authentication and any
assurances of licenses mechanisms to prevent replay
   attacks. Security keying material will be made available, or used for the result of an
attempt made different
   security algorithms (for encryption/decryption, MAC generation,
   etc.), which are used to obtain a general license or permission for meet the use of
such proprietary rights by implementers or users security requirements,
   described in detail in Section 4 of this
specification can be obtained document.

   This block will use the keying material and policy information
   from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring ULE security database block on the ULE payload to its attention any
copyrights, patents or patent applications,
   generate the secure ULE Extension Header or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address decipher the information
   secure ULE extension header to get the IETF at
ietf-ipr@ietf.org.

Appendix A: ULE Security Framework

This section defines a security framework for the deployment payload. An example
   overview of
secure ULE networks.

A.1 Building Blocks

This the ULE Security framework defines extension header format along with
   the following building blocks

Cruickshank et.al.         Expires April 12, 2008           [Page
22]

as ULE header and payload is shown in figure 2 below:

o  The Key Management Block

o  The ULE Security Extension Header Block

o  The ULE Databases Block

Within 3 below. There
   could be other extension headers (either mandatory or optional).
   It is RECOMMENDED that these are placed after the Key Management block security
   extension header. This permits full protection for all headers.
   It avoids situations where the communication between SNDU has to be discarded on
   processing the
Group Member entity and security extension header, while preceding headers
   have already have been evaluated. One exception is the Group Server entity happens in Timestamp
   extension which SHOULD precede the
control plane. The ULE Security security extension header block applies [ID-
   EXT]. When applying the security services for example
   confidentiality, input to the ULE SNDU and this happens in cipher algorithm will cover the ULE data plane. The ULE
Security databases block acts as
   fields from the interface between end of the Key
management block (control plane) and security extension header to the ULE Security Header
block (ULE data plane) as shown in figure 2.

                                                          ------
  +------+----------+           +----------------+           / \
  | Key Management  |/---------\| Key Management |            |
  |     Block       |\---------/|     Block      |            |
  |  Group Member   |           |  Group Server  |        Control
  +------+----------+           +----------------+          Plane
         | |                                                  |
         | |                                                  |
         | |                                                 \ /
  ----------- Key management <-> ULE Security databases     -----
         | |
         \ /
  +------+----------+
  |      ULE        |
  |   SAD / SPD     |
  |    Databases    |
  |      Block      |
  +------+-+--------+
         / \
         | end
   of the PDU.

        +-------+------+-------------------------------+------+
        |
 ----------- ULE Security databases <-> ULE Security Header ----
         | |                                                 / \
         | |                                                  |
         | |   |SEC   |
  +------+-+--------+                                    ULE     Protocol Data
  |   ULE Security  |                                       Plane
  | Extension Header|                                         |
  |     Block Unit        |      |
  +-----------------+                                        \ /
                                                            -----

Cruickshank et.al.         Expires April 12, 2008           [Page
23]
        |Header |Header|                               |CRC-32|
        +-------+------+-------------------------------+------+
               Figure 2: Secure ULE Framework Building Blocks

A.1.1 Key Management Block

A key management framework is required to provide security at the 3: ULE level using extension headers. This key management framework
is responsible for user authentication, access control, and Security Association negotiation (which include the negotiations
of the security algorithms Header Extension Placement

   A.1.3 ULE Security Databases Block

   There needs to be used and two databases i.e. similar to the generation of IPSec
   databases.

   o  ULE-SAD: ULE Secure Association Database contains all the
      Security Associations that are currently established with
      different session keys as well ULE peers.

   o  ULE-SPD: ULE Secure Policy Database contains the policies as policy material).
      defined by the system manager. These policies describe the
      security services that must be enforced

   The Key
management framework can design of these two databases will be either automated or manual. Hence
this key management client entity (shown based on IPSec
   databases as the Key Management
Group Member block defined in figure 2) RFC4301 [RFC4301].

   The exact details of the header patterns that the SPD and SAD
   will have to support for all use cases will be present defined in all ULE
receivers as well as at a
   separate document. This document only highlights the need for
   such interfaces between the ULE sources (encapsulation gateways).
The ULE source could also be data plane and the Key Management Group Server
Entity (shown as
   control plane.

A.2 Interface definition

   Two new interfaces have to be defined between the blocks as shown
   in Figure 2 above. These interfaces are:

   o  Key Management Group Server block in figure
2. This happens when the <-> ULE source also acts as Security databases block
   o  ULE Security databases block  <-> ULE Security Header block

   While the first interface is used by the Key Management Group Server. Deployment may use either automated key
management protocols (e.g. GSAKMP [RFC4535]) or manual insertion
of keying material.

A.1.2 ULE Extension Header Block

A new to
   insert keys, security extension header for associations and policies into the ULE
   Database Block, the second interface is used by the ULE protocol is required Security
   Extension Header Block to provide get the security features of data confidentiality, data
integrity, data authentication keys and mechanisms to prevent replay
attacks. Security keying policy material will be used for the different
security algorithms (for encryption/decryption, MAC generation,
etc.), which are used to meet
   generation of the security requirements,
described in detail in Section 4 of this document. extension header.

   A.2.1 Key Management <-> ULE Security databases

   This interface is between the Key Management group member block
   (GM client) and the ULE Security Database block (shown in figure
   2). The Key Management GM entity will use 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 policy information from insert this data into the ULE security
   Security database block on block. 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 *
     Unique_ID);
  . Update_record_database (char * Database, char * record, char *
     Unique_ID);
  . Delete_record_database (char * Database, char * Unique_ID);

   The definitions of the ULE payload variables are as follows:

     . Database - This is a pointer to generate the
secure ULE Extension Header or to decipher Security databases
     . record - This is the secure ULE extension
header rows of security attributes to get be
        entered or modified in the ULE payload. An example overview above databases
     . Unique_ID - This is the primary key to lookup records (rows
        of security attributes) in the above databases

   A.2.2 ULE Security Databases <-> ULE Security extension header format along with Header

   This interface is between the ULE header Security Database and
payload is the ULE
   Security Extension Header block as shown in figure 3 below. There could be other extension
headers (either mandatory or optional). It is RECOMMENDED that these
are placed after 2. To send
   traffic, firstly the security extension header. This permits full
protection for all headers. It avoids situations where ULE encapsulator using the SNDU has
to be discarded on processing ULE_Security_ID,
   Destination Address and possibly the PID, searches the ULE
   Security Database for the relevant security extension header, while
preceding headers have already have been evaluated. One exception is record. It then uses
   the Timestamp extension which SHOULD precede data in the record to create the ULE security extension

Cruickshank et.al.         Expires April 12, 2008           [Page
24]

header [ID-EXT].. When applying
   header. For received traffic, the security services for example
confidentiality, input to ULE decapsulator on receiving
   the cipher algorithm ULE SNDU will cover first get the fields record from the end of Security Database
   using the security extension header to ULE_Security_ID, the end of Destination Address and possibly
   the PDU.

Cruickshank et.al.         Expires April 12, 2008           [Page
25]
     +-------+------+-------------------------------+------+
     | ULE   |SEC   |     Protocol Data Unit        |      |
     |Header |Header|                               |CRC-32|
     +-------+------+-------------------------------+------+
            Figure 3: ULE Security Header Extension Placement

A.1.3 ULE Security Databases Block

There needs to be two databases i.e. similar PID. It then uses this information to decrypt the IPSec
databases.

o  ULE-SAD: ULE Secure Association Database contains all
   extension header. For both cases (either send or receive traffic)
   only one interface is needed since the
   Security Associations that are currently established with
   different ULE peers.

o  ULE-SPD: ULE Secure Policy Database contains only difference between
   the policies as
   defined by sender and receiver is the system manager. These policies describe direction of the
   security services that must be enforced

The design flow of these two databases will be based on IPSec
databases as defined in RFC4301 [RFC4301].

The exact details traffic:

  . Get_record_database (char * Database, char * record, char *
     Unique_ID);

Appendix B: Motivation for ULE link-layer security

   Examination of the header patterns that the SPD threat analysis and SAD
will have to support for all use cases will be defined security requirements in
   sections 3 and 4 has shown that there is a
separate document. need to provide
   security in MPEG-2 transmission networks employing ULE. This document only highlights
   section compares the need disadvantages when security functionalities
   are present in different layers.

B.1 Security at the IP layer (using IPsec)

   The security architecture for
such interfaces between the ULE data plane and Internet Protocol [RFC4301]
   describes security services for traffic at the Key Management
control plane.

A.2 Interface definition

Two new interfaces have to be defined between IP layer. This
   architecture primarily defines services for the blocks Internet Protocol
   (IP) unicast packets, as shown
in Figure 2 above. These interfaces are:

o  Key Management block <-> ULE Security databases block

o  ULE Security databases block  <-> well as manually configured IP multicast
   packets.

   It is possible to use IPsec to secure ULE Security Header block

While the first interface links. The major
   advantage of IPsec is its wide implementation in IP routers and
   hosts. IPsec in transport mode can be used by for end-to-end
   security transparently over MPEG-2 transmission links with little
   impact.

   In the Key Management Block context of MPEG-2 transmission links, if IPsec is used to
insert keys, security associations and policies into
   secure a ULE link, then the ULE
Database Block, Encapsulator and Receivers are
   equivalent to the second interface security gateways in IPsec terminology. A
   security gateway implementation of IPsec uses tunnel mode. Such
   usage has the following disadvantages:

   o  There is used by an extra transmission overhead associated with using
      IPsec in tunnel mode, i.e. the ULE Security
Extension Header Block extra IP header (IPv4 or IPv6).

   o  There is a need to get protect the keys and policy material for
generation identity (NPA) of ULE Receivers
      over the security extension header.

A.2.1 Key Management <-> ULE Security databases

This interface broadcast medium; IPsec is between the Key Management group member block

Cruickshank et.al.         Expires April 12, 2008           [Page
26]

(GM client) and not suitable for
      providing this service. In addition, the interfaces of these
      devices do not necessarily have IP addresses (they can be L2
      devices).

   o  Multicast is considered a major service over ULE Security Database block (shown in figure
2). links. The Key Management GM entity will communicate
      current IPsec specifications [RFC4301] only define a pairwise
      tunnel between two IPsec devices with manual keying. Work is
      in progress in defining the GCKS extra detail needed for multicast
      and then get to use the tunnel mode with address preservation to allow
      efficient multicasting. For further details refer to [WEIS06].

B.2 Link security below the encapsulation layer

   Link layer security can be provided at the MPEG-2 TS layer (below
   ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
   specific PID value. However, an MPEG-2 TS may typically multiplex
   several IP flows, belonging to different users, using a common
   PID. Therefore all multiplexed traffic will share the relevant security information (keys, cipher
mode, same
   security service, ULE_Security_ID and other relevant keying
material as well as policy) and insert this data into keys.

   This has the ULE
Security database block. 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 *
  Unique_ID);
. Update_record_database (char * Database, char * record, char *
  Unique_ID);
. Delete_record_database (char * Database, char * Unique_ID); advantages:

   o  The definitions of bit stream sent on the variables broadcast network does not expose
      any L2 or L3 headers, specifically all addresses, type fields,
      and length fields are as follows:

  . Database - encrypted prior to transmission.

   o  This method does not preclude the use of IPsec, TLS, or any
      other form of higher-layer security.

   However it has the following disadvantages:

   o  When a PID is shared between several users, each ULE Receiver
      needs to decrypt all MPEG-2 TS Packets with a pointer matching PID,
      possibly including those that are not required to be
      forwarded. Therefore it does not have the ULE Security databases
  . record - This flexibility to
      separately secure individual IP flows.

   o  When a PID is shared between several users, the rows of security attributes ULE Receivers
      will have access to be
     entered or modified private traffic destined to other ULE
      Receivers, since they share a common PID and key.

   o  IETF-based key management that is very flexible and secure is
      not used in existing MPEG-2 based systems. Existing access
      control mechanisms in such systems have limited flexibility in
      terms of controlling the above databases
  . Unique_ID - This is use of key and rekeying. Therefore if
      the primary key to lookup records (rows
     of is compromised, then this will impact several ULE
      Receivers.

   Currently there are few deployed L2 security attributes) systems for MPEG-2
   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.

B.3 Link security as a part of the above databases

A.2.2 ULE Security Databases <-> ULE Security Header

This interface is between encapsulation layer

   Examining the threat analysis in section 3 has shown that
   protection of ULE Security Database link from eavesdropping and the ULE
Security Extension Header block as shown Receiver
   identity are major requirements.

   There are several major advantages in figure 2. To send
traffic, firstly using ULE link layer
   security:

   o  The protection of the complete ULE encapsulator using 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 ULE_Security_ID,
Destination Address and possibly identity of the PID, searches Receiver within the ULE
Security Database for
      MPEG-2 transmission network at the relevant security record. It then uses IP layer and also at L2.

   o  Efficient protection of IP multicast over ULE links.

   o  Transparency to the data in use of Network Address Translation (NATs)
      [RFC3715] and TCP Performance Enhancing Proxies (PEP)
      [RFC3135], which require the record ability to create inspect and modify the ULE security extension
header. For received traffic,
      packets sent over the ULE decapsulator on receiving link.

   This method does not preclude the ULE SNDU will first get use of IPsec at L3 (or TLS
   [RFC4346] at L4). IPsec and TLS provide strong authentication of
   the record from end-points in the Security Database
using communication.

   L3 end-to-end security would partially deny the ULE_Security_ID, 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 Destination Address and possibly TCP packets of the PID. It then uses this information original
   applications, which in particular inhibits compression.

   End-to-end security (IPsec, TLS, etc.) may be used independently
   to decrypt the ULE
extension header. For both cases (either send or receive traffic)
only one interface is needed since provide strong authentication of the only difference between end-points in the sender and receiver
   communication. This authentication is desirable in many scenarios
   to ensure that the direction of correct information is being exchanged between
   the flow of traffic:

. Get_record_database (char * Database, char * record, char *
  Unique_ID);

Cruickshank et.al.         Expires April 12, 2008           [Page
27] trusted parties, whereas Layer 2 methods cannot provide this
   guarantee.

   >>> NOTE to RFC Editor: Please remove this appendix prior to
   publication]

Document History

   Working Group Draft 00

   o  Fixed editorial mistakes and ID style for WG adoption.

   Working Group Draft 01

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

   o  Added section 4.1 on GSE. Extended the security considerations
      section.

   o  Extended the appendix to show the extension header placement.

   o  The definition of the header patterns for the ULE Security
      databases will be defined in a separate draft.

   o  Need to include some words on key management transport over
      air interfaces, actually key management bootstrapping.

   Working Group Draft 03

   o  Fixed editorial mistakes and added some important changes as
      pointed out by Gorry Fairhurst.

   o  Table 1 added in Section 6.2 to list the different security
      techniques to mitigate the various possible network threats.

   o  Figure 2 modified to clearly explain the different interfaces
      present in the framework.

Cruickshank et.al.         Expires April 12, 2008           [Page
28]

   o  New Section 7 has been added.

   o  New Section 6 has been added.

   o  The previous sections 5 and 6 have been combined to section 5.

   o  Sections 3, 8 and 9 have been rearranged and updated with
      comments and suggestions from Michael Noisternig from
      University of Salzburg.

   o  The Authors and the Acknowledgments section have been updated.

   Working Group Draft 04

   o  Fixed editorial mistakes and added some important changes as
      pointed out by DVB-GBS group, Gorry Fairhurst and Laurence
      Duquerroy.

   o  Table 1 modified to have consistent use of Security Services.

   o  Text modified to be consistent with the draft-ietf-ipdvb-ule-
      ext-04.txt

Cruickshank et.al.         Expires April 12, 2008           [Page
29]

   Working Group Draft 06

   o  Fixed editorial mistakes and added some important changes as
      pointed out by Pat Cain and Gorry Fairhurst.

   o  Figure 1 modified to have consistent use of Security Services.

   o  Text modified in Section 4 to clearly state the requirements.

   o  Moved Section 5 to the Appendix B

   o  Updated IANA consideration section

   o  Numbered the different requirements and cross referenced them
      within the text.