[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
IPDVB Working Group                                      M. Noisternig
Internet Draft                                  University of Salzburg
Intended status: Standards Track                             P. Pillai
Expires: January 2010                           University of Bradford
                                                        H. Cruickshank
                                                  University of Surrey
                                                         July 13, 2009




     Security Extension for Unidirectional Lightweight Encapsulation
                                Protocol
                   draft-noisternig-ipdvb-sec-ext-01.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 13, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).




Noisternig et al.     Expires January 13, 2010                [Page 1]


Internet-Draft       Security Extension for ULE              July 2009


   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Unidirectional Lightweight Encapsulation (ULE) protocol provides
   an efficient mechanism for transporting IP and other network layer
   protocol data over MPEG-2 networks. Such networks, widely used
   especially for providing digital TV services, often use broadcast
   wireless transmission media, and are hence vulnerable to various
   types of security attacks.

   This document describes a new mandatory ULE extension to protect ULE
   traffic using security features such as data confidentiality, data
   integrity, data origin authentication, and prevention against replay
   attacks. Additionally, destination addresses may be hidden from
   unauthorized receiver devices using the identity protection feature.

   The format of the security extension header as well as the processing
   at receivers and transmitters are described in detail. The extension
   aims to be lightweight and flexible such that it may be implemented
   in low-cost, resource-scarce transceivers, and different levels of
   security may be selected.

   The security extension may be easily adapted to the Generic Stream
   Encapsulation (GSE) protocol, which uses a similar extension header
   mechanism.

Table of Contents

   1. Introduction ................................................. 3
   2. Requirements Notation ........................................ 4
   3. Abbreviations used in this document .......................... 4
   4. Security Services ............................................ 5
   5. Secure ULE SNDU Format ....................................... 7
      5.1. Type Field .............................................. 9
      5.2. Receiver Destination Address Field ...................... 9
      5.3. ULE-SID Field ........................................... 9
      5.4. Encrypted Destination Address Field ..................... 9
      5.5. SA-Dependant Data Field ................................ 10
      5.6. Encrypted Next-Type Field .............................. 10
      5.7. Encrypted Payload ...................................... 10
      5.8. Message Authentication Code (MAC) Field ................ 10
   6. Transmitter and Receiver Processing ......................... 11
      6.1. Security Policy Database (SPD) ......................... 12
      6.2. Security Association Database (SAD) .................... 13
      6.3. Transmitter Processing ................................. 14


Noisternig et al.     Expires January 13, 2010                [Page 2]


Internet-Draft       Security Extension for ULE              July 2009


      6.4. Receiver Processing .................................... 16
   7. Key Management Considerations ............................... 18
      7.1. MSEC/IPsec Key Management Protocols .................... 19
      7.2. Existing L2 Key Management Infrastructure .............. 19
      7.3. Other Considerations ................................... 19
   8. Security Considerations ..................................... 19
   9. IANA Considerations ......................................... 21
   10. Acknowledgments ............................................ 21
   11. References ................................................. 22
      11.1. Normative References .................................. 22
      11.2. Informative References ................................ 22

1. Introduction

   The Unidirectional Lightweight Encapsulation (ULE) protocol [3]
   provides an efficient mechanism for transporting IP and other network
   layer protocol data over ISO MPEG-2 Transport Streams (TS) [1]. This
   document describes a new ULE mandatory extension header for providing
   link layer security for ULE.

   In MPEG-2 transmission networks employing ULE there is a need to
   provide link layer security, particularly where network layer and
   transport layer security may not be present or may not be sufficient.
   The security requirements are presented and discussed in detail in
   [4]. The set of security services that the security extension for ULE
   can provide includes data confidentiality, data integrity, data
   origin authentication and rejection of replayed packets. While
   providing suitable link encryption is mandatory, link layer data
   integrity and data origin authentication is provided as an optional
   security service. These are especially desirable for systems where
   there are several ULE transmitters (e.g., satellite mesh systems).

   The extension also supports what is called 'identity protection' in
   this specification. This allows hiding destination addresses from
   unauthorized receiver devices, thus enabling a form of traffic flow
   confidentiality.

   The method described in this document provides security for ULE SNDUs
   at the link layer, in contrast to higher-layer mechanisms, such as
   IPsec [7] and TLS [10]. This allows protecting any network layer
   protocol (even with Ethernet bridging), while higher-layer security
   may be used independently and in parallel. Link-layer signalling
   information may be protected as well.

   The processing specification follows the IPsec approach of defining a
   Security Policy Database (SPD) and a Security Association Database
   (SAD). A Security Identifier (SID), similar to the Security Parameter


Noisternig et al.     Expires January 13, 2010                [Page 3]


Internet-Draft       Security Extension for ULE              July 2009


   Index (SPI) in the IPsec protocols, assists receiver devices in
   looking up security states. The design of the databases for ULE
   security is similar but simpler because unlike in IPsec a receiver
   only needs the SID along with the NPA address and possibly the PID to
   retrieve the data from these databases.

   Key management protocols assuming similar processing functionality,
   such as the MSEC Group Domain of Interpretation (GDOI) [8] and the
   Group Secure Association Key Management Protocol (GSAKMP) [6], may be
   adapted for the ULE scenario. Simple configurations are supported
   using manual keying (i.e., pre-shared keys).

   Security transforms such as encryption algorithms may be modelled
   after existing MSEC and IPsec security algorithms, but will be
   defined in separate documents in order to proceed/update them
   independently of this specification.

   The ULE security extension is designed for both bi-directional and
   unidirectional links, as well as unicast and multicast settings [9].

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

3. Abbreviations used in this document

   AES - Advanced Encryption Standard

   DES - Data Encryption Standard

   DVB - Digital Video Broadcasting

   GDOI - Group Domain of Interpretation

   GSKAMP - Group Secure Association Key Management Protocol

   GSE - Generic Stream Encapsulation

   IPsec - Internet Protocol Security

   MPE - Multi-Protocol Encapsulation

   MAC - Message Authentication Code

   NAT - Network Address Translation


Noisternig et al.     Expires January 13, 2010                [Page 4]


Internet-Draft       Security Extension for ULE              July 2009


   NCC - Network Control Centre

   NPA - Network Point of Attachment

   PEP - Protocol Enhancing Proxy

   PID - Packet Identifier

   PDU - Protocol Data Unit

   SAD - Security Association Database

   SID - Security Identifier

   SHA - Standard Hash Algorithm

   SNDU - Subnetwork Data Unit

   SPD - Security Policy Database

   SPI - Security Parameter Index

   TLS - Transport Layer Security

   ULE - Unidirectional Lightweight Encapsulation Protocol

   VPN - Virtual Private Network

4. Security Services

   MPEG-2 based networks are susceptible to several security attacks,
   both passive and active [4]. Some of the main security services
   (mandatory or optional) that the security extension for ULE provides:

   o Data confidentiality (mandatory): Data confidentiality is
      achieved by encrypting the higher layer PDU (and other ULE
      extensions headers that may be present and require security)
      before encapsulation in the ULE SNDU, so that only authorised
      receivers can decrypt the transmitted information while an
      adversary would not be able to recover the important information
      even if it got access to the transmitted data.








Noisternig et al.     Expires January 13, 2010                [Page 5]


Internet-Draft       Security Extension for ULE              July 2009


   o Receiver address hiding (optional): Hiding an SNDU's real
      destination NPA address from an adversary is an important step in
      providing identity protection. While one solution for this is to
      use temporary addresses, this is susceptible to various practical
      issues. More importantly, from a security point of view, temporary
      addresses do not provide adequate identity protection, as a
      passive adversary may easily link different SNDUs to the same
      connection. Also, a procedure to allocate temporary addresses is
      required such that they are unique in the system. Hence it is
      proposed to encrypt the destination address. By encrypting the
      destination address within the SNDU, an attacker is effectively
      denied from gaining information by monitoring addresses.

   o Data origin authentication (optional): Data origin (source)
      authentication allows a ULE receiver to verify data as sent by a
      legitimate ULE sender. A Message Authentication Code (MAC) using a
      shared secret key may be used to authenticate the sender in
      unicast settings, or to guarantee an SNDU originating from a group
      member in secure group communication. For the latter, other source
      authentication schemes, such as digital signatures, may be used to
      assure source authenticity.

   o Data integrity (optional): Data integrity provides a way for the
      receiver of the data message to know if the data has been tampered
      with in transit by an attacker. This is provided for by the data
      origin authentication algorithm. A change in the message will
      alter the authentication value, and an adversary will unlikely be
      able to derive a correct one.




















Noisternig et al.     Expires January 13, 2010                [Page 6]


Internet-Draft       Security Extension for ULE              July 2009


   o Replay attacks countermeasures (optional): Methods against replay
      attacks need to ensure that an adversary has not replayed old
      authentic messages at a later time. A monotonically increasing
      sequence number may be part of the SA-dependent data field of the
      security extension header, allowing messages with old sequence
      number values to be rejected. As with other security services, the
      choice of using sequence numbers is dictated by policy, usually
      effected by the key management system.

      Note that sequence numbers resemble unkeyed connection states that
      an adversary may track to link packets to different connections.
      Therefore, use of sequence numbers is not mandated. One solution
      is encrypting sequence numbers using standard Electronic Code Book
      (ECB) mode (i.e., encrypt as one block of data). A receiver first
      decrypts the encrypted value within the protocol to check for a
      replay, and then may use either the encrypted value as an
      initialization vector for the Cipher Block Chaining (CBC) mode of
      operation, or the decoded sequence number for the Counter (CTR)
      mode (with the internal counter incremented by one). The
      disadvantage is a slightly higher protocol overhead compared to
      unencoded sequence numbers. Another solution is to use connection-
      independent timestamp values. Depending on the resolution,
      timestamps may or may not provide perfect replay protection. The
      drawback is a higher protocol overhead, including the need for
      synchronized clocks.

5. Secure ULE SNDU Format

   Figure 1 below shows the format of an SNDU containing the security
   extension header. The extension header is designed as a framework for
   a set of security transforms, enabling high flexibility in selecting
   various security services (including common encryption algorithms
   such as DES [11], 3DES, AES [12], etc.). Security transforms are to
   be described in separate documents, and will be based on algorithms
   defined for the MSEC/IPsec protocols.

   The ULE security extension is a standard extension header as
   described in Section 5 of RFC 4326 [3], and does not affect the ULE
   base protocol. Furthermore, the extension is a Mandatory ULE
   Extension header, which means that a receiver MUST process this
   header before it processes the next extension header or the
   encapsulated PDU, otherwise the entire SNDU should be discarded.

   When configuring use of the security extension at encapsulation
   devices, it is RECOMMENDED to place the extension header directly
   after the base header. This permits full protection for all headers.



Noisternig et al.     Expires January 13, 2010                [Page 7]


Internet-Draft       Security Extension for ULE              July 2009


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+----------------------------+------------------------------+
   |D|          Length            |     Type = Secure-ULE        |
   +-+----------------------------+------------------------------+
   |           Receiver Destination NPA Address (D=0)            |
   |                              +------------------------------+
   |                              |           ULE-SID            |
   +------------------------------+------------------------------+
   |         Encrypted Destination NPA Address (optional)        |
   +------------------------------+------------------------------+
   |                                                             |
   =                  SA-Dependant Data (optional)               =
   |                                                             |
   |                              +------------------------------+
   |                              |    Encrypted Next-PDU Type   |
   +------------------------------+------------------------------+
   |                                                             |
   |                                                             |
   =                         Encrypted PDU                       =
   |                                                             |
   |                                                             |
   +------------------------------+------------------------------+
   |                                                             |
   =            Message Authentication Code (optional)           =
   |                                                             |
   +-------------------------------------------------------------+
   |                    Cyclic Redundancy Check                  |
   +-------------------------------------------------------------+
   Figure 1. General SNDU format with security extension header

   In Figure 1, the Type field in the base header denotes that a
   mandatory security extension header is present. The receiver
   destination NPA address is optional (dependent on the D bit). The
   security extension header follows the ULE base header. This header
   contains the ULE Security Identifier (SID), an optional Encrypted
   Destination Address, a variable-length field whose content is
   determined by a Security Association (SA), and an encrypted Type
   field denoting the type of the enclosed PDU (or a subsequent
   extension header if present). The security extension header has an
   associated trailer following the PDU data that contains an optional
   Message Authentication Code (MAC) field. Placing the MAC in the end
   of the SNDU is in similar spirit to the CRC, and allows computation
   in an on-line way, i.e., an encapsulator may derive the MAC of an
   SNDU during the process of transmitting it, and following the last
   bit of the PDU it can simply attach the MAC.




Noisternig et al.     Expires January 13, 2010                [Page 8]


Internet-Draft       Security Extension for ULE              July 2009


   The following subsections describe the fields that are part of or are
   directly relevant to the security extension header in more detail.
   All other fields are defined within the ULE standard [3].

5.1. Type Field

   The 16-bit Type field of the ULE base header (or some other extension
   header) indicates a security extension header following subsequently.

   [XXX IANA ACTION REQUIRED to allocate xxSecure-ULExx XXX]

   This Secure-ULE Type code is to be defined in the IANA maintained
   Next-Header Registry for ULE and has the value xxSecure-ULExx

   [XXX END of IANA ACTION XXX]

5.2. Receiver Destination Address Field

   This field, defined in the ULE standard, typically carries the
   destination NPA address of a receiver device, or the address of a
   multicast group. However, when the identity protection service is
   used, this address is moved into the security extension header (see
   section 5.4). The address field in the base header may still be
   present, though, to reduce processing constraints for other receiver
   devices and aid in the lookup of security states, for example by
   containing a multicast address designating a VPN of the destination.
   However, it MUST NOT contain the real destination NPA address that is
   hidden within the Encrypted Destination Address Field, and it MUST
   NOT carry any other unique identifier for the receiver device.

5.3. ULE-SID Field

   A 16-bit Security Identifier (SID), similar to the SPI in IPsec, is
   used to look up the security state for a connection. This SID
   represents the Security Association (SA) between the ULE transmitter
   and receiver for a particular session and indicates the keys and
   algorithms used for encrypting the data payload and calculating the
   MAC. The SID is used by a receiver to filter PDUs in combination with
   the NPA address when present.

5.4. Encrypted Destination Address Field

   This field is only present if the identity protection service is
   selected. In that case, the 48-bit destination NPA address from the
   base header is omitted, and instead appears in the security extension
   header, where it is encrypted subsequently (along with the payload



Noisternig et al.     Expires January 13, 2010                [Page 9]


Internet-Draft       Security Extension for ULE              July 2009


   data). If no other label is inserted in the base header's address
   field (see section 5.2), the D bit is set to 1.

5.5. SA-Dependant Data Field

   This variable-length optional field may contain any auxiliary
   information that is specific to the particular SA. Typical content
   would be sequence numbers to provide replay protection, nonces for
   stream cipher encryption, or Initialisation Vectors (IVs) for
   randomized security algorithms. The length of this field, of the
   subentries, and their order is defined by the SA and mandated by
   policy.

5.6. Encrypted Next-Type Field

   This 16-bit value denotes the type of a subsequent extension header,
   respectively the content type of the payload data [3]. It is
   encrypted along with the payload. If another ULE extension header
   follows, then this type field indicates the type of this extension
   header.

5.7. Encrypted Payload

   All data transmitted between ULE sender and receiver is encrypted
   under the data confidentiality service. The coverage of this service
   includes the Payload Data Unit (PUD), the Encrypted Next-Type Field,
   and the Encrypted Destination NPA Address Field if present. The
   algorithms and keys used for this purpose are determined by the SA
   shared between the communicating points.

5.8. Message Authentication Code (MAC) Field

   This field, when present, carries the tag of a Message Authentication
   Code (MAC) to provide both data origin authentication and data
   integrity. The default scope of the MAC algorithm is the entire SNDU
   up to but not including the MAC and CRC fields.

   The MAC field may also contain a digital signature or suitable output
   of another multicast source authentication scheme if source
   authentication under group communication is desired.

   Reliable protection against modification of data and masquerading
   attacks requires both sender and receiver identifiers to be
   authenticated in addition to the payload. This is an issue for the
   ULE protocol because it does not exhibit a source identifier field,
   and the PID of an underlying MPEG-2 TS cell does not depict a unique
   and reliable identifier [9]. Without authenticating the source, an


Noisternig et al.     Expires January 13, 2010               [Page 10]


Internet-Draft       Security Extension for ULE              July 2009


   active attacker may re-write the PID to appear from a different
   transmitter under the same encryption key. This problem can only
   arise in configurations with multiple senders sharing a key. In
   networks that do not employ PID re-numbering, the PID may be part of
   a pseudo-header for authenticating the source. This may be configured
   via policy.

6. Transmitter and Receiver Processing

   The processing specification follows the IPsec [7] approach of
   defining a Security Policy Database (SPD) and a Security Association
   Database (SAD). The SPD contains an ordered list of Security Policies
   (SPs). These policies allow simple filtering of incoming or outgoing
   data based on address and other information, including assignment of
   different security services and keys to different connections and
   secure groups. The SAD refers to the set of security states, called
   Security Associations (SAs), which are referenced on the receiver
   side using the SID along with the address information of the received
   SNDU.

   In the IPsec protocols, a receiver normally uses the SPI it has
   chosen itself for looking up SAs within its SAD. In this
   specification the SPI is equivalent to the SID. However, under
   automated key management, this mechanism of using the SPI does not
   work for multicast settings, multi-sender shared SA scenarios, and
   unidirectional links, where the SPI value has to be centrally
   selected by a group controller. A multicast IPsec implementation
   partially solves these issues by taking into account the source and
   multicast destination of a packet, and following a longest-match
   approach in determining the appropriate SA in the following way:
   First, an SA is looked up using the triple (SPI, destination, source)
   (1); if not successful, a search is done for (SPI, destination) (2);
   finally, only the SPI is taken for the lookup (3). While (1) aims to
   support source-specific multicast groups, (2) is meant for any-source
   multicast groups. This document adapts that approach in the following
   way, using the Packet Identifier (PID) of the underlying MPEG-2 TS
   cell:

   For an SNDU with a multicast address present, a longest-match search
   on (SID, destination NPA, PID) is performed in the incoming SAD.
   Otherwise, a longest-match search is derived using (SID, PID) in the
   incoming SAD. This takes into account VPN-like settings with a single
   sender, as well as unidirectional links.

   Support for shared SAs with multiple senders requires a coordinated
   solution for determining a unique SID value. To support shared SAs
   permitting bi-directional communication and avoid the effort of


Noisternig et al.     Expires January 13, 2010               [Page 11]


Internet-Draft       Security Extension for ULE              July 2009


   duplicating SAs, an SAD may store references to SAs, and reference
   bi-directional SAs in both the incoming and outgoing SAD.

   Another difference to IPsec is the treatment of directionality for
   SPs and SAs. In a standard IPsec implementation, a match on an SP
   affects traffic in both directions, resulting in two separate
   unidirectional SAs being created. This document always requires
   separate SPs to be defined for incoming and outgoing data, and in
   turn allows SAs to be shared across several devices, supporting both
   unidirectional links and group communication.

   For the rest of this section, a Selector is defined as a pair of
   destination NPA address and PID.

6.1. Security Policy Database (SPD)

   An SPD contains an ordered list of SPs, similar to Access Control
   Lists (ACLs). Each transmitter and receiver device defines one SPD
   for outgoing data, and an independent one for incoming SNDUs. For
   both databases, an SP must provide the following information:

   o An SP Selector, together with an SP Selector mask. This provides a
      simple and basic way to filter based on address information. For a
      transmitter SP, the Selector may be extended to include additional
      filtering information, such as higher-layer addresses, and port
      numbers.

   o Information about the SA(s) to be instantiated by this SP, when a
      match is found based on filtering. This contains:

      o A Selector mask, denoted SA Selector mask, which specifies the
        set of SAs derived from the policy. This provides a simple way
        to instantiate secure unicast connections, as well as shared SAs
        for secure group communication. It is similar to the Populate-
        From-Packet (PFP) flags in the IPsec specification, but slightly
        more general.

      o An optional SID value. If not defined, Group Controller and Key
        Server (GCKS) data must be present for the SID to be selected
        dynamically.

      o Optional GCKS data. When a GCKS is configured, it MUST be
        contacted by a device which cannot find an SA for a matching SP,
        and when the SP does not define a static SID and default key
        data in its first set of Security Parameters.

      o An ordered list of Security Parameter sets used for


Noisternig et al.     Expires January 13, 2010               [Page 12]


Internet-Draft       Security Extension for ULE              July 2009


        instantiating an SA, sorted according to preference. On creating
        an SA, devices must default to the first entry in the list,
        unless a key management protocol permits negotiation (e.g., for
        unicast, bidirectional settings), and the device contacts the
        GCKS to request another set of Security Parameters from the
        list.

   Each set of Security Parameters contains:

   o The cryptographic algorithms used.

   o The cryptographic parameters required by these algorithms (e.g.,
      sequence number length, MAC length).

   o Optional key data for manual keying.

   A Security Parameter set may select no security services, by which it
   is to be interpreted requesting processing without the security
   extension header.

   Each SPD may be manually constructed by a device or network operator,
   but it may also be dynamically set up via a GCKS. This document does
   not describe how to create such databases, or how to store, manage,
   and look up SPs within the SPD; this is regarded as implementation
   specific detail.

6.2. Security Association Database (SAD)

   A Security Association (SA) is an instantiation of an SP. It
   describes the current state of a secure connection between two or
   more devices. Each SA within the SAD must contain the following
   information:

   o The SA Selector derived from the instantiating SP.

   o The SID defined by the SP or the GCKS.

   o Static security parameters defined by the SP (cryptographic
      algorithms, MAC length, Sequence Number length, etc.).

   o Dynamic security parameters (keys, sequence number, SA lifetime,
      etc.), initially defined by the SP or the GCKS, and updated during
      processing.

   o GCKS specific data defined by the SP or the GCKS, including GCKS
      contact information.



Noisternig et al.     Expires January 13, 2010               [Page 13]


Internet-Draft       Security Extension for ULE              July 2009


   As with the SPD, the description of the implementation-specific
   details of the SAD is out of scope of this document.

6.3. Transmitter Processing

   The following list describes in detail the processing steps required
   for a ULE encapsulator implementing the unified ULE security
   extension:

    1. Get SP: Upon constructing an SNDU for transmission over the ULE
      link, an encapsulator must scan its outgoing SPD for a matching
      policy. If no such policy can be found, the SNDU data MUST be
      discarded, and this event SHOULD be logged as an invalid
      transmission attempt.

    2. Get SA: Given a matching SP, an SA is searched within the outgoing
      SAD using the SNDU's Selector information and the policy's SA
      Selector masks, including the SP's SID value if defined. If no SA
      could be found, it must be set up as follows: If the SP's first
      Security Parameter set contains default key data, or defines data
      to be sent without protection, the SA is immediately created and
      initialized according to these settings. Otherwise, if the SP
      defines GCKS contact information, the GCKS MUST be queried for
      obtaining key material. During that attempt the device SHOULD
      postpone transmission, or discard the data. Any case of failure
      MUST result in the data being discarded, and this event SHOULD be
      logged (e.g., as a user authentication failure in the case of
      membership denial by the GCKS). If the SA allows passing data
      unprotected, processing continues as usual [3].

    3. Check SA: The SA may have a pre-defined lifetime (e.g., maximum
      number of encryptions, sequence number state, seconds since
      instantiation) after which it may no longer be used. To allow for
      a transient switch-over to a new SA, the SA must define a point
      prior to its lifetime end at which transmitters switch to the new
      SA. If that point is reached, a device MAY proactively request a
      new SA from a GCKS. In general, it is the responsibility of the
      operator or the GCKS to create new SAs, and distributing these to
      legitimate transmitter and receiver devices in time. If no new SA
      is available, a transmitter MAY still use the current SA during
      its full lifetime. After that, it MUST discard the data, and this
      event SHOULD be logged.

    4. Construct SNDU: A protected SNDU is built as follows:

      a. First, the ULE base header and any extension headers preceding
         the security extension header are written. If the SA requests


Noisternig et al.     Expires January 13, 2010               [Page 14]


Internet-Draft       Security Extension for ULE              July 2009


         identity protection, the destination NPA address is omitted
         from the base header, setting the base header's D bit to 1
         (though another label may be re-inserted, see section 5.2). The
         last next-header-type field within the extension header chain
         contains the type code for the security extension.

      b. The SID value is written as the first field of the security
         extension header.

      c. If identity protection is used, the SNDU's destination NPA
         address follows. It is encrypted along with the payload.

      d. Any SA-dependent data, such as sequence numbers and
         initialization vectors, are written subsequently.

      e. Then, the next-header-type field, any further extension
         headers, and the payload data are encoded as defined by the
         SA's data confidentiality algorithm (together with the
         encrypted destination NPA address).

      f. For authentication and integrity protection, a MAC of length as
         defined by the SA is appended. The MAC is computed over all the
         data encoded so far, i.e., from the start of the SNDU to the
         end of the payload data.

      g. Finally, the CRC is calculated and appended, and the SNDU
         further processed according to RFC 4326.

    5. Update SA: After transmission of the SNDU, the SA MUST be updated
      (e.g., the sequence number incremented by one).


















Noisternig et al.     Expires January 13, 2010               [Page 15]


Internet-Draft       Security Extension for ULE              July 2009


         +-----------------+
         |   receive PDU   |                    +-----------------+
   +---->|from upper layers|<-------------------|   discard PDU   |
   |     +-----------------+                    +-----------------+
   |              v                                      ^
   |     +-----------------+ not found?         +-----------------+
   |     |     get SP      |------------------->|    log event    |<-+
   |     +-----------------+                    +-----------------+  |
   |              v                                      ^ failure?  |
   |     +-----------------+ not found?         +-----------------+  |
   |  +--|     get SA      |------------------->|    create SA    |  |
   |  |  +-----------------+                    +-----------------+  |
   |  |w/o        |                                      | success?  |
   |  |sec.ext.   |                     +----------------+           |
   |  |           v                     |                            |
   |  |  +-----------------+ end of     |                            |
   |  |  |    check SA     |-----------------------------------------+
   |  |  +-----------------+ lifetime?  |
   |  |           |                     |       +-----------------+
   |  |           | expected            |       |   get new SA    |
   |  |           +---------------------------->|    from GCKS    |
   |  |           | lifetime end?       |       +-----------------+
   |  |           v                     |                v failure?
   |  |  +-----------------+            |       +-----------------+
   |  +->| construct SNDU  |<-----------+       |    log event    |
   |     |   & transmit    |                    +-----------------+
   |     +-----------------+
   |              v
   |     +-----------------+
   |     |    update SA    |
   |     +-----------------+
   |              |
   +--------------+

   Figure 2. Transmitter Processing Flow Chart

6.4.  Receiver Processing

   For a receiver device to process SNDUs containing the security
   extension, the following steps must be performed:

    1. Decode SNDU (1): First, the CRC of an SNDU received is verified,
      and the base header and extension headers preceding a security
      extension header or the payload are evaluated.

    2. Get SA: If a security extension header is found, a longest-match
      search within the incoming SAD is performed as described in


Noisternig et al.     Expires January 13, 2010               [Page 16]


Internet-Draft       Security Extension for ULE              July 2009


      section III. If it contains a matching SA, processing continues at
      step 4.

    3. Get SP: The SPD is scanned similar to step 1 in the transmitter
      processing specification. However, the destination NPA address may
      be hidden, and consequently the SP must define whether the address
      must be matched or not. When the SNDU is received without a
      security extension header but the SP does not permit data to pass
      unprotected, the SNDU MUST be discarded immediately, and this
      event SHOULD be logged. Likewise, if there is a security extension
      header, but the policy allows only for unprotected data, the SNDU
      MUST be discarded, and the event SHOULD be logged. When permitted,
      an unprotected SNDU is processed as usual [3]. Otherwise, an SA is
      created as described in step 2 of the transmitter processing
      specification.

    4. Check SA: If the SA's lifetime has expired, the SNDU MUST be
      discarded, and this SHOULD be logged. If the extension header
      contains an encrypted destination NPA address, it is first
      decrypted, using the SA-dependent data, and checked for a valid
      address for that SA. If the decoded address is not accepted by the
      receiver device and the SA, the SNDU MUST be silently discarded.

    5. Decode SNDU (2): This step includes verification of the MAC,
      protection against replay attacks, and decoding of the payload. In
      any case of failure, the SNDU MUST be discarded, and this event
      SHOULD be logged.

    6. Update SA: After successful reception of an SNDU, the SA MUST be
      updated (e.g., the sequence number set to the one found within the
      SNDU, incremented by one).

















Noisternig et al.     Expires January 13, 2010               [Page 17]


Internet-Draft       Security Extension for ULE              July 2009


         +-----------------+
         |   receive SNDU  |                 +-----------------+
   +---->| from MPEG layer |<----------------|   discard SNDU  |<----+
   |     +-----------------+                 +-----------------+     |
   |              v                                   ^              |
   |     +-----------------+ decoding error? +-----------------+     |
   |     |decode headers up|- - - - - - - - >|    log event    |<-+  |
   |     | to security ext.|        +------->|                 |  |  |
   |     +-----------------+        |        +-----------------+  |  |
   |              |                 |      not found/ ^           |  |
   |              v                 |  not permitted? |           |  |
   |     +-----------------+ not found?      +-----------------+  |  |
   |  +--|     get SA      |---------------->|      get SP     |  |  |
   |  |  +-----------------+        |        +-----------------+  |  |
   |  |w/o        |                 |        success? |           |  |
   |  |sec.ext.   v                 |                 v           |  |
   |  |  +-----------------+ end of |        +-----------------+  |  |
   |  |  |    check SA     |--------+        |    create SA    |->|  |
   |  |  +-----------------+ lifetime?       +----------------+   |  |
   |  |           |                          success? |           |  |
   |  |           |  +--------------------------------+           |  |
   |  |           |  |                                            |  |
   |  |           v  v                                            |  |
   |  |  +-----------------+  decoding error?                     |  |
   |  +->|   decode SNDU   |--------------------------------------+  |
   |     |  & pass to L3   |                                         |
   |     |                 |-----------------------------------------+
   |     +-----------------+  destination address mismatch?
   |              v
   |     +-----------------+
   |     |    update SA    |
   |     +-----------------+
   |              |
   +--------------+

   Figure 3. Receiver Processing Flow Chart

7. Key Management Considerations

   Small and rather static network configurations may be supported using
   manual keying. More elaborate settings, consisting of a higher number
   of devices, or when users need to be added or excluded more
   frequently, require some automated key management. This may be
   defined independently of the ULE security extension. This section
   presents some considerations on this issue.




Noisternig et al.     Expires January 13, 2010               [Page 18]


Internet-Draft       Security Extension for ULE              July 2009


7.1. MSEC/IPsec Key Management Protocols

   MSEC/IPsec key management protocols, such as the Group Domain of
   Interpretation (GDOI) and the Group Secure Association Key Management
   Protocol (GSAKMP) protocols, may be adapted for the ULE security
   extension. This has the advantage of sharing similar functionality in
   terms of SA lookup and database architectures.

   The protocol may be run entirely within the ULE network, or it may be
   performed by some other means.  This is a matter of policy and an
   architecture decision. For example, for bidirectional transfers the
   whole key exchange procedures could be carried within the ULE
   network, while for unidirectional links some other bidirectional
   connection could be used.

7.2. Existing L2 Key Management Infrastructure

   ULE security may re-use an already existing L2 key management
   infrastructure, such as the DVB-RCS security system [5]. The format
   of the ULE-Security-ID will be the same format as defined in DVB-RCS
   security procedures.

7.3. Other Considerations

   Key management protocols are traditionally assuming bidirectional
   links. GSAKMP provides some initial support for push operation.
   However, supporting unidirectional links within the ULE network may
   require defining a new protocol. Such a protocol should be designed
   flexibly to support bidirectional operation as well without a change
   in the header structures.

   Existing L2 unidirectional mechanism may be evaluated, such as DVB-
   Conditional Access (CA) and ATSC-CA.

8. Security Considerations

   Link-level security is commonly used in broadcast/radio links to
   supplement end-to-end security, and may not be treated as a
   substitute for end-to-end security. A common objective is to provide
   the same level of privacy as terrestrial links.

   A number of security considerations specific to the ULE security
   extension have been outlined throughout the document. The following
   paragraphs extend that analysis.

   Hiding destination addresses under the identity protection service is
   an effective mechanism against traffic flow analysis. However, there


Noisternig et al.     Expires January 13, 2010               [Page 19]


Internet-Draft       Security Extension for ULE              July 2009


   are other more subtle ways for a passive adversary to deduce the real
   destination address of an SNDU, even when precluded from decoding the
   destination NPA address field. For example, SNDUs with increasing
   sequence numbers may be linked to a single connection, providing a
   hint regarding the identities of the communicating parties based on
   packet sizes and distribution patterns. Alternatives to sequence
   numbers were outlined in section 5. When SID values are selected at
   random for bidirectional links using identity protection, they may
   resemble unique temporary addresses. This may be mitigated by always
   selecting the smallest free SID value on a receiver device, thereby
   increasing the chance of equal SID values among several devices.
   However, this also means increased processing requirements in the
   filtering step for these devices.

   Other problems arise with certain cryptographic algorithms. Stateful
   algorithms are problematic for manually keyed configurations when
   devices cannot retain their cryptographic states across device
   restarts (due to power or device failures, etc.). Reuse of sequence
   numbers for the Counter (CTR) mode renders all encryption insecure.
   Receiver devices may be vulnerable to replay attacks if they do not
   remember prior lower bounds for sequence numbers. If devices cannot
   store their cryptographic state in non-volatile memory, it is advised
   that they resort to non-stateful schemes, such as the randomized
   Cipher Block Chaining (CBC) mode for encryption, or the use of
   timestamps for replay protection (if replay protection is desired).

   Many stateful schemes, such as the CTR mode of operation, require
   nonces as part of their input. As mentioned before, nonces must never
   be re-used under the same key. To provide this guarantee,
   particularly under group communication where the encryption key is
   shared among several group members, some source identifier must be
   incorporated into the construction of the nonce.

   Within ULE networks, the PID may be used as a source identifier, but
   this is not reliable. A device may receive data from different MPEG-2
   multiplexes, which both may allocate PID values independently [9].
   Furthermore, multiplexors within the network may transparently re-
   number PID values. This is a problem for receivers as they require
   the originating PID value for reconstructing nonces.

   One solution to circumvent these issues is to assign a unique sender
   identifier to each legitimate transmitter under the same key [14]. To
   avoid the problem of associating an MPEG-2 TS with a sender
   identifier, the latter is included explicitly as part of the nonce in
   each SNDU. This means that the nonce field (e.g., sequence number)
   may get enlarged by the size necessary to support a predefined
   maximum number of different senders sharing a key. The other caveat


Noisternig et al.     Expires January 13, 2010               [Page 20]


Internet-Draft       Security Extension for ULE              July 2009


   of this approach is the problem of generating and distributing unique
   sender identifiers.

   The lack of a reliable source identifier entails also a potential
   authentication insecurity. However, this only applies for specific
   communication scenarios, as outlined in section 5.

9. IANA Considerations

   The Secure-ULE header is defined in the IANA maintained Next-Header
   Registry for ULE and has the value xxSecure-ULExx.

10. Acknowledgments

   The authors acknowledge the help and advice from Gorry Fairhurst
   (University of Aberdeen), L. Duquerroy (Alcatel Alenia Space)
   Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in the
   preparation of this document.






























Noisternig et al.     Expires January 13, 2010               [Page 21]


Internet-Draft       Security Extension for ULE              July 2009


11. References

11.1. Normative References

    [1] ISO/IEC DIS 13818-1, "Information technology - Generic coding
         of moving pictures and associated audio information - Part1:
         Systems", International Standards Organisation (ISO)

    [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

    [3] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
         Lightweight Encapsulation (ULE) for Transmission of IP
         Datagrams over an MPEG-2 Transport Streams", RFC 4326, December
         2005.

11.2. Informative References

    [4] H. Cruickshank, P. Pillai, M. Noisternig, and S. Iyengar,
         "Security requirements for the Unidirectional Lightweight
         Encapsulation (ULE) protocol", RFC 5458, March 2009.

    [5] "Digital Video Broadcasting (DVB): Interaction Channel for
         satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005.

    [6] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
         Group Secure Association Key Management Protocol", RFC 4535,
         June 2006.

    [7] S. Kent and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

    [8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
         Domain of Interpretation", RFC 3547, July 2003.

    [9] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B.,
         and H. Linder, "A Framework for Transmission of IP Datagrams
         over MPEG-2 Networks", RFC 4259, November 2005.

    [10] http://www.ietf.org/html.charters/tls-charter.html

    [11] National Institute of Standards and Technology, "Data
         Encryption Standard (DES)", Federal Information Processing
         Standard (FIPS) Publication, FIPS PUB 46-3, October 1999.

    [12] National Institute of Standards and Technology, "Advanced
         Encryption Standard (AES)", Federal Information Processing


Noisternig et al.     Expires January 13, 2010               [Page 22]


Internet-Draft       Security Extension for ULE              July 2009


         Standard (FIPS) Publication, FIPS PUB 197, November 2001.[14]                                                                          D.
         McGrew, B. Weis, "Using Counter Modes with Encapsulating
         Security Payload (ESP) and  Authentication Header (AH) to
         Protect Group Traffic", draft-ietf-msec-ipsec-group-counter-
         modes-03 (work in progress), 2009.

Author's Addresses

   Michael Noisternig
   University of Salzburg
   Jakob-Haringer-Str. 2
   5020 Salzburg
   Austria
   Email: mnoist@cosy.sbg.ac.at

   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

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



















Noisternig et al.     Expires January 13, 2010               [Page 23]