Subject: FW: I-D submission (draft-cruickshank-ipdvb-sec-req-02.txt)

From: <[email-masked]>
Date: Mon, 19 Jun 2006 15:58:19 +0100

Dear ipdvb WG,

Many thanks to Gorry for submitting the above draft
(draft-cruickshank-ipdvb-sec-req-02.txt) on our behalf.  We would like
the ipdvb WG to adopt this work as WG work item, please.

First many thanks to Prashant for all his comments and his name is added
to the new draft. 

I will try to summarise the comments from ipdvb WG and our responses
that added to the new draft:  There were several questions related ULE
source authentication  and protection against replays attacks are they
mandatory or optional. In order to clarify the security requirement,
three scenarios are added to section 2.1:
o	Scenario 1: Monitoring (passive threat).  Here the intruder
monitors the ULE broadcasts in order to gain information about ULE data
and/or tracking the communicating parties.
o	Scenario 2: Local high jacking of the MPEG-TS multiplex (active
threat). Here we assume an intruder is sophisticated and able to block
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
o	Scenario 3: Global high jacking of the MPEG-TS multiplex (active
threat). Here we assume an intruder is very sophisticated and able to
high jack the whole MPEG transmission multiplex.

In addition, Section 3 analysis these scenarios further and extract the
security requirements:
o	Scenario 1: Data confidentiality MUST be provided to prevent
monitoring of the ULE data (such as IP packet and user information).
Also ULE MAC address hiding MUST be provided to prevent access to
communicating parties' identity and tracking their communications.
These requirements are mandatory for a ULE security system.  Identity
hiding is used mobile phone networks such as GSM and UMTS.
o	Scenario 2:  In addition to scenario 1 requirements, new
measures are needed to be implemented such as source authentication and
using sequence numbers to prevent replay attacks. However, scenario 2
threats can happen only in specific service cases and therefore source
authentication and sequence numbers SHOULD be optional for the ULE
security system because of the extra overheads it incurs.
o	Scenario 3:  ULE security system can not protect against such
attacks.  This scenario is out of scope for this document.

Finally and regarding ULE security implementation plans: We are in
process of submitting a related draft that describes the actual ULE
security format with extension headers.  We intend and plan to have an
implementation ready by the end of the year.  Would any other people
also be interested in collaborating or developing their own
implementations?

Haitham (& all co-authors)
----

Dr. Haitham S. Cruickshank

Lecturer 
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK 

Tel: +44 1483 686007 (indirect 689844) 
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: 19 June 2006 10:05
To: Internet-Drafts Administrator
Cc: Gorry Fairhurst; Cruickshank HS Dr (CCSR)
Subject: I-D submission (draft-cruickshank-ipdvb-sec-req-02.txt)

I'm submitting this on behalf of the authors,

Gorry Fairhurst
(ipdvb WG Chair)
     Internet Engineering Task Force                       H.Cruickshank 
     Internet Draft                                           S. Iyengar 
     draft-cruickshank-ipdvb-sec-req-02.txt     University of Surrey, UK 
                                                            L. Duquerroy 
                                            Alcatel Alenia Space, France 
     Expires: December 2006                                    P. Pillai 
                                              University of Bradford, UK 
                                       
     Category: Internet Draft                              June 16, 2006 

            Security requirements for the Unidirectional Lightweight 
                         Encapsulation (ULE) protocol 
                     draft-cruickshank-ipdvb-sec-req-02.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 December 16, 2006. 

    Abstract 

       This document provides a threat analysis and derives security 
       requirements for MPEG-2 transmission links using the 
       Unidirectional Lightweight Encapsulation (ULE). It also provides 

    Cruickshank           Expires December 15, 2006          [Page 1] 
     
    Internet-Draft         Security Requirements for ULE      June 2006 

       the motivation for ULE link-level security. This work is intended 
       as a work item of the ipdvb WG, and contributions are sought from 
       the IETF on this topic.  

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

    Table of Contents 

       1. Introduction                                                2 
          1.1. System Components                                      4 
       2. Threat Analysis                                             4 
          2.1. Threat Scenarios                                       5 
             2.1.1. Scenario 1: Monitoring (passive threat)           5 
             2.1.2. Scenario 2: Local highjacking of the MPEG-TS 
             multiplex (active threat)                                6 
             2.1.3. Scenario 3: Global high jacking of the MPEG-TS 
             multiplex (active threat)                                6 
       3. Security Requirements for IP over MPEG-2 TS                 6 
       4. IPsec and MPEG-2 Transmission Networks                      8 
          4.1. Tunnel mode use of IPsec for multicast                 9 
          4.2. IPsec and L2 security                                  9 
       5. Motivation for ULE link-layer security                     10 
          5.1. Link security below the Encapsulation layer           11 
          5.2. Link security as a part of the Encapsulation layer    11 
       6. Summary                                                    12 
       7. Security Considerations                                    13 
       8. IANA Considerations                                        13 
       9. Acknowledgments                                            13 
       10. References                                                14 
          10.1. Normative References                                 14 
          10.2. Informative References                               14 
       Author's Addresses                                            15 
       Intellectual Property Statement                               16 
       Disclaimer of Validity                                        16 
       Copyright Statement                                           16 
        
    1. Introduction 

       In the security considerations section of RFC 4259[2], there is 
       an initial analysis of the security requirements in MPEG-2 
       transmission networks. For example, when the MPEG-2 transmission 

    Cruickshank           Expires December 15, 2006           [Page 2] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       network is not using a wireline network, the normal security 
       issues relating to the use of wireless links for transport of 
       Internet traffic should be considered [16]. RFC 4259 recommends 
       that any new encapsulation defined by the IETF allows Transport 
       Stream encryption and also supports optional link level 
       encryption/authentication of the SNDU payload. In ULE [3], this 
       may be provided in a flexible way using Extension Headers. This 
       requires definition of a mandatory header extension, but has the 
       advantage that it decouples specification of the security 
       functions from the encapsulation functions. This method also 
       supports hiding of the NPA/MAC addresses. 

       This document extends the above analysis and derives the security 
       requirements for ULE. 

       The main objective of this document is to specify the 
       requirements for securing the link between the Encapsulation 
       Gateways (ULE source) and Receivers only. In addition, this 
       document provides an overview of the threat analysis for an IP 
       network that utilises ULE over an underlying MPEG-2 transmission 
       network. 

       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. The Unidirectional 
       Lightweight Encapsulation (ULE) mechanism described in [3] can be 
       used for the transport of IPv4 and IPv6 Datagrams, bridged 
       Ethernet frames 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. 

       Important characteristics of MPEG-2 transmission networks are 
       that they may provide link-level broadcast capability, and that 
       many support applications that require access to a very large 
       number of subnetwork nodes [2]. In addition, the majority of 
       MPEG-2 transmission networks are bandwidth-limited, encapsulation 
       protocols must therefore add minimal overhead to ensure good link 
       efficiency while providing adequate network services. They also 
       need to be simple to minimize processing, robust to errors and 
       security threats, and extensible to a wide range of services. 

       In MPEG-2 transmission network there are several signalling 
       messages that are broadcast by the Encapsulator or Multiplexor
       in the form of tables. Examples of these signalling messages or 
       (SI tables) are PAT - Program Association Table, PMT - Program 

    Cruickshank           Expires December 15, 2006           [Page 3] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       Map Table and NIT - Network Information Table.  In existing MPEG-
       2 transmission networks, these messages are broadcast in clear 
       (no encryption or integrity checks). The integrity of these 
       messages is important for the correct working of the ULE network. 
       However, securing these messages is out of scope for ULE 
       security. 

    1.1. System Components  

       There are several entities in within the MPEG-2 transmission 
       network architecture, as defined in [2]). These include (ULE) 
       Encapsulation Gateways, TS multiplexers (including re-
       multiplexers), modulators and Receivers. 

       The ULE link security focuses on security between the 
       Encapsulation Gateways (ULE source) and Receivers only. 

    2. Threat Analysis 

       The simplest type of network threat is a passive threat. Passive 
       attacks include 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 
       being able to extract traffic communicated between IP hosts. 
       Another example an intruder trying to gain information about the 
       communication parties by monitoring their Layer 2 MAC/NPA 
       addresses; an intruder can gain some information by just knowing 
       the 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 problematic in the case of broadcast networks 
       such as MPEG-2 transmission 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. Examples of active attacks are:  

       o Masquerading: where 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. 

     
    Cruickshank           Expires December 15, 2006           [Page 4] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       o Repudiation: Repudiation of origin occurs when a party denies 
          being the originator of a message and repudiation of 
          destination occurs when a party denies the reception of a 
          message. 

       o Replay attacks: When an intruder sends some old (authentic) 
          messages to the Receiver. 

       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. 

       Active threats such as masquerading, replay, modification of 
       messages and injecting IP packet attacks are major security 
       concerns for the Internet community and several of these attacks 
       have been described [5]. The defence against such attacks is data 
       integrity using cryptographic techniques and sequence numbers. 

       In the context of active threats in MPEG-2 transmission networks, 
       ULE source authentication (i.e. verification that packets are 
       being sent by the expected Encapsulation Gateway) is required by 
       the ULE Receivers, although attacks such as masquerading, 
       modification of messages and injecting IP packets are more 
       difficult. However such attacks on individual ULE Receivers are 
       possible and can pass unnoticed by the ULE network operators or 
       ISPs. Therefore ULE authentication and integrity checks are 
       required. IPsec can be used to provide source authentication but 
       has some disadvantages; further analysis on IPsec is presented in 
       section 4. 

    2.1. Threat Scenarios 

       In normal MPEG transmission networks packets are transmitted by 
       the ULE Encapsulation Gateway to the ULE Receivers. This is 
       sometimes called a star topology which is the main focus of this 
       document. Mesh topologies where ULE Receivers are ULE sources as 
       well are out of scope of this document. 

       In the star topology, three threat scenarios can be envisaged: 

    2.1.1. Scenario 1: Monitoring (passive threat) 

       Here the intruder monitors the ULE broadcasts in order to gain 
       information about ULE data and/or tracking the communicating 
       parties. In this scenario, measures should be taken to hide the 
       ULE data and the ULE Receivers identity. 

    Cruickshank           Expires December 15, 2006           [Page 5] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

    2.1.2. Scenario 2: Local high jacking of the MPEG-TS multiplex 
       (active threat) 

       Here we assume an intruder is sophisticated and able to block the 
       original transmission from the ULE Encapsulation Gateway and 
       deliver a modified version of the MPEG-TS transmission to a 
       single ULE Receiver or a small group of Receivers (e.g. in a 
       single company site). The MPEG transmission network might not be 
       aware of such attacks. In addition to the security requirements 
       for scenario 1, here extra measures should be taken to ensure ULE 
       source authentication and preventing replay of old messages. 

    2.1.3. Scenario 3: Global high jacking of the MPEG-TS multiplex 
       (active threat)  

       Here we assume an intruder is very sophisticated and able to high 
       jack the whole MPEG transmission multiplex. The requirements here 
       are similar to scenario 2. The MPEG transmission network can 
       quickly identify such attacks. This type of attack cannot be 
       protected against with a ULE security system. The MPEG 
       transmission network must resort to other means to restore the 
       original transmissions. 

       In terms of priority, scenario 1 is considered the major threat 
       in MPEG transmission systems. Scenario 2 is likely to a smaller 
       degree in certain cases and hence the extra protections should be 
       optional and used only when such threat is a possibility to some 
       MPEG transmission services. Scenario 3 is not envisaged to be a 
       practical because it will be very difficult to pass unnoticed by 
       the MPEG transmission operator. Therefore scenario 3 is out of 
       scope for this document. 

    3. Security Requirements for IP over MPEG-2 TS 

       From the above analysis, the following security requirements can 
       be derived: 

       o Data confidentiality is the major requirement against passive 
          threats (using encryption). L2 encryption or L3 (IPsec) 
          encryption can satisfy this requirement. 

       o Hiding of Layer 2 MAC/NPA address. This is needed particularly 
          in the MPEG-2 broadcast networks to stop an intruder gaining 
          information by observing the identity of the communicating 
          parties and the volume of their traffic. 

       o For active threats: ULE source authentication and data 

    Cruickshank           Expires December 15, 2006           [Page 6] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

          integrity are required, using techniques such as message 
          authentication code and digital signatures. Sequence numbers 
          are required to stop replay attacks.  Therefore, L2 data 
          integrity/authentication is optional, but still important in 
          environments in which several independent networks share a 
          single transmission resource. In addition, functions to 
          determine the integrity of control and management messages in 
          MPEG-2 transmission networks such as SI tables are another 
          optional requirement, but are outside the scope of ULE 
          security. 

       o Layer L2 endpoint authentication: This will be part of the key 
          management. It will be performed during the initial key 
          exchange and authentication phase. 

       o End-to-end security (such as IPsec and TLS [13]) and ULE link 
          security should work in parallel without obstructing each 
          other. 

       o Decoupling of ULE key management functions from ULE 
          encryption. This will allow the independent definition of 
          these systems such as the re-use of existing security 
          management systems (e.g. GSAKMP [9] and GDOI [10]), plus other 
          systems such as DVB-RCS [6] and/or the development of new 
          systems, as required. 

       o Other general requirements are: 

            o Protection of the management system and the infrastructure 
              from unauthorized people. ULE encryption will provide 
              partial protection through the key management procedures 
              and data encryption. 

            o Operational issues: Because of the possible large coverage 
              of a broadcast transmission network, it may be required to 
              deliver data to many different countries that may have 
              different security legislation (related to authorized 
              encryption algorithms and the length of keys). Therefore 
              the ULE security system should allow a wide range of 
              security parameters during the negotiation phase in order 
              to offer flexibility to operators. In ULE security, the 
              choice of such algorithms will be decided by the key 
              management system in use. 

            o Compatibility with other networking functions: Other 
              networking functions such as NAT (Network Address 
              Translation) [12] or TCP acceleration can be used in a 

    Cruickshank           Expires December 15, 2006           [Page 7] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

              wireless DVB networks (see RFC3135). The ULE security 
              solution should be compatible with functions such as 
              NAT/NAPT, IPsec, TLS, etc. 

            o Traceability (such as using intrusion detection systems): 
              To monitor transmission network (e.g. using log files to 
              record the activities on the network). This is out of 
              scope for ULE security. 

       Examining scenarios 1 and 2 in section 2.1., the requirements for 
       each scenario can be summarised as: 

       Scenario 1: Data confidentiality MUST be provided to prevent 
       monitoring of the ULE data (such as IP packet and user 
       information). Also ULE MAC address hiding should be provided to 
       prevent access to communicating parties' identity and tracking 
       their communications. These requirements are mandatory for a ULE 
       security system. 

       Scenario 2: In addition to scenario 1 requirements, additional 
       measures need to be implemented such as source authentication and 
       using sequence numbers to prevent replay attacks. This will stop 
       intruders from injecting their own data into the MPEG-TS stream. 
       However, scenario 2 threats can happen only in specific service 
       cases and therefore source authentication and sequence numbers 
       SHOULD be optional for the ULE security system because of the 
       extra overheads it incurs. 

       Scenario 3: ULE security system can not protect against such 
       attacks. 

    4. IPsec and MPEG-2 Transmission Networks  

       IPsec supports two modes of use: transport mode and tunnel mode. 
       In transport mode, AH and ESP provide protection primarily for 
       next layer protocols; in tunnel mode, AH and ESP are applied to 
       tunnelled IP packets. In both modes, data integrity is provided 
       and in addition, ESP provides the data privacy service as well. 

       It is possible to use IPsec to secure ULE links. The major 
       advantage of IPsec is its wide implementation in IP routers and 
       hosts. The security architecture for the Internet Protocol [15] 
       describes security services for traffic at the IP layer. That 
       architecture primarily defines services for Internet Protocol 
       (IP) unicast packets, as well as manually configured IP multicast 
       packets. 

    Cruickshank           Expires December 15, 2006           [Page 8] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       However IPsec is not well-suited to protect the identity of the 
       ULE encapsulator/Receivers to provide this. The interfaces of 
       these devices also do not necessarily have IP addresses (they can 
       be L2 devices). 

       In addition, IP Multicast is considered as a major service over 
       MPEG-2 Transmission Networks. A document produced by the IETF 
       Multicast Security (msec) [8] Working Group on IPsec extensions 
       for multicast [11] describes extensions to [15] that further 
       define the IPsec security architecture for packets that carry a 
       multicast address in the IP destination field, allowing these to 
       remain IP multicast packets.  

    4.1. Tunnel mode use of IPsec for multicast  

       In the context of MPEG-2 transmission links, if IPsec is used to 
       secure a ULE link, then the ULE Encapsulators and Receivers are 
       equivalent to the security gateways in IPsec terminology. A 
       security gateway implementation of IPsec using the multicast 
       extensions MUST use tunnel mode. In particular, the security 
       gateway must use the tunnel mode to encapsulate incoming 
       fragments. 

       With IPsec tunnel mode, there are two challenges: First, if the 
       destination of an IP multicast packet is changed it will no 
       longer be properly routed. Secondly, IP multicast routing 
       protocols also typically create multicast distribution trees 
       based on the source address. An IPsec security gateway that 
       changes the source address of an IP multicast packet, again this 
       will cause multicast routing problems. The document referenced in 
       [11] defines a way for retaining both the IP source and 
       destination addresses of the inner IP header to allow IP 
       multicast routing protocols to route the packet irrespective of 
       the packet being IPsec protected. This interpretation of tunnel 
       mode is known as tunnel mode with address preservation. 

    4.2. IPsec and L2 security  

       IPsec in transport mode can be used for end-to-end security 
       transparently of MPEG-2 transmission links with no impact. 

       However, if IPsec is used to secure ULE links, then it must be 
       used in tunnel mode. Such usage has the following disadvantages: 

       o There is a need to protect the identity of ULE encapsulator / 
          receivers over the ULE broadcast medium; IPsec is not suitable 
          for providing this service. 

    Cruickshank           Expires December 15, 2006           [Page 9] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       o There is an extra overheads associated with using IPsec in 
          tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 

       o Multicast is considered as a major service over ULE links. The 
          current IPsec specifications [15] only define a pairwise 
          tunnel between two IPsec devices with manual keying. Work in 
          progress [11] is defining the extra detail needed for 
          multicast and to use the tunnel mode with address preservation 
          as described in section 4.1. 

       In the ULE link context, in addition to the IPsec tunnelling 
       overhead, the source and destination address preservation means 
       that these IP addresses are broadcast in the clear. This provides 
       an opportunity to intercept the traffic information (weakening 
       the ability to provide the identity hiding). However [11] 
       mentions the possibility that multicast data is sent through a 
       service provider network, and is encapsulated under a different 
       IP multicast address while in the provider network. The source 
       address of the encapsulating (outside) IP header could be changed 
       to that of the ULE gateway. 

    5. Motivation for ULE link-layer security 

       Examination of the threat analysis and security requirements in 
       sections 2 and 3 has shown that there is a need to provide link-
       layer (L2) security in MPEG-2 transmission networks employing 
       ULE, particularly when network-layer and transport-layer security 
       (e.g. IPsec, TLS ) are insufficient. 

       ULE link security is therefore considered an additional security 
       mechanism to IP, transport, and application layer security, not a 
       replacement. It should provide similar functions to that of IPsec 
       [7], but in addition provides link confidentiality and Receiver 
       identity hiding. 

       End-to-end security, IPsec and ULE link security (between ULE 
       Encapsulation Gateway to the ULE Receivers) can work in parallel: 
       IPsec providing the end-to-end security between hosts and ULE 
       providing the security over the MPEG-2 transmission link. 
       However, no direct interaction between the IPsec and the ULE 
       security system is envisaged. 

       A modular design to ULE Security may allow it to use and benefit 
       from IETF key management protocols, such as the MSEC [9] and GDOI 
       [10]. This does not preclude the use of other key management 
       methods in scenarios that benefit from this. 

    Cruickshank           Expires December 15, 2006           [Page 10] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

    5.1. Link security below the Encapsulation layer 

       Link layer security can be provided in the MPEG-TS level (below 
       ULE). MPEG-TS encryption encrypts all TS Packets sent with a 
       specific PID value. However MPEG-TS may multiplex several IP 
       streams using a common PID. Therefore all multiplexed traffic 
       will share the same security keys. 

       This has the following advantages: 

       o The bit stream sent on the broadcast network does not expose 
          any L2 or L3 headers, specifically all addresses, type fields, 
          and length fields are encrypted prior to transmission. 

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

       However it has the following disadvantages: 

       o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with 
          a matching PID, possibly including those that are not required 
          to be forwarded. Therefore it does not have the flexibility to 
          secure every individual IP connection separately. 

       o ULE Receivers will be able to see the private traffic destined 
          to other ULE Receivers, since they share a common key. 

       o If the key is compromised, then this will impact several ULE 
          Receivers. Existing access control mechanisms have limited 
          flexibility in terms of controlling the use of key and 
          rekeying. IETF based key management are not used in existing 
          systems. 

       In practice there are not many L2 security systems for MPEG 
       transmission networks. Conditional access for digital TV 
       broadcasting is one example that exists today. This system is 
       optimised for TV services and will be suitable to IP packet 
       transmissions. Some other systems are specified in standards such 
       the MPE [4] system. However, there are no known implementations 
       of such systems. 

    5.2. Link security as a part of the Encapsulation layer 

       Therefore major advantages for ULE link security are: 

       o The protection of the complete ULE Protocol Data Unit (PDU) 
          including IP addresses. 

    Cruickshank           Expires December 15, 2006           [Page 11] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       o Ability to protect the identity of the Receiver within the 
          MPEG-2 transmission network. 

       o Efficient protection of IP multicast over ULE links. 

       o Transparency to the use of Network Address Translation (NATs) 
          [12] and TCP Performance Enhancing Proxies (PEP) [14], which 
          require the ability to inspect and modify the packets sent 
          over the ULE link. 

       o This method does not preclude the use of IPsec. IPsec also 
          provides 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 mechanisms and 
          algorithms.  

       In some current encapsulation methods, e.g. MPE [4], encryption 
       of the MAC address requires each Receiver to decrypt all 
       encrypted data sent using a TS Logical Channel (PID), before it 
       can then filter the PDUs that match the set of MAC/NPA addresses 
       that the Receiver wishes to receive, therefore encryption of the 
       MPE MAC address is not permitted in such systems. For ULE 
       security, support for Layer 2 MAC/NPA address hiding should be 
       provided. 

       Examining the threat analysis in section 2, has shown that 
       protection of ULE link from eavesdropping and ULE Receiver 
       identity hiding are major requirements. Such requirements can be 
       met using ULE link encryption. 

       In the context of active threats in MPEG-2 transmission networks, 
       ULE source authentication is required by the ULE Receivers. 
       Attacks such as masquerading, modification of messages and 
       injecting IP packets are more difficult. However, such attacks on 
       individual ULE Receivers are possible, and can pass unnoticed by 
       the ULE network operators or ISPs. Therefore using HMACs is one 
       possibility which an associated overheads per ULE packets. 
       Another possibility is to use lightweight data integrity methods 
       or procedures can be provided by the ULE security system. In 
       addition sequence numbers can provide protection against replay 
       attacks. 

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

    Cruickshank           Expires December 15, 2006           [Page 12] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       Encapsulation layer. In summary, there is a strong need for L2 
       encryption and ULE Receiver identity hiding. 

       There is an addition need (optional) for L2 source authentication 
       and protection against insertion of other data into the ULE 
       stream (i.e. data integrity). This is optional because of the 
       associated overheads for the extra features and they are only 
       required for specific service cases. 

    7. Security Considerations 

       Link-level (L2) encryption of IP traffic is commonly used in 
       broadcast/radio links to supplement End-to-End security (e.g. 
       provided by TLS, SSH, Open PGP, S/MIME, IPsec). A common 
       objective is to provide the same level of privacy as wired links. 
       An ISP or User may also wish to provide end-to-end security 
       services to the end-users (based on the well known mechanisms 
       such as IPsec). 

       This document provides a threat analysis and derives the security 
       requirements to provide optional link encryption and link-level 
       integrity / authentication of the SNDU payload. 

    8. IANA Considerations 

       This document does not define any protocol and does not require 
       any IANA assignments. 

    9. Acknowledgments 

       The authors acknowledge the help and advice from Gorry Fairhurst 
       (University of Aberdeen), Stephane Coombes (ESA) and Y.F. Hu 
       (University of Bradford) in the preparation of this draft. 

     
    Cruickshank           Expires December 15, 2006           [Page 13] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

    10. References 

    10.1. Normative References 

       [1]  Bradner, S., "Key Words for Use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

       [2]  Montpetit, M.-J., 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.

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

       [4]  EN 301 192, "Digital Video Broadcasting (DVB); DVB 
             Specifications for Data Broadcasting", European 
             Telecommunications Standards Institute (ETSI). 

    10.2. Informative References 

       [5]  Bellovin, S., "Problem Area for the IP Security protocols", 
             Computer Communications Review 2:19, pp. 32-48, April 989. 
             http://www.cs.columbia.edu/~smb/  

       [6]  "Digital Video Broadcasting (DVB) -- interaction channel 
             for satellite distribution systems", ETSI EN 301 790 V1.4.1 
             (2005-04)   

       [7]  http://www.ietf.org/html.charters/wg-
             dir.html#Security%20Area. RFCs 2401, 2402 and 2406   

       [8]  http://www.ietf.org/html.charters/msec-charter.html   

       [9]  H Harney (SPARTA), et al, "GSAKMP: Group Secure Association 
             Group Management Protocol", <draft-ietf-msec-gsakmp-sec-
             10.txt>, IETF Work in Progress.   

       [10] M. Baugher, et al, "GDOI: The Group Domain of 
             Interpretation", RFC 3547.   

       [11] Weis B., et al, "Multicast Extensions to the Security 
             Architecture for the Internet", <draft-ietf-msec-ipsec-
             extensions-01.txt>, IETF Work in Progress.   

    Cruickshank           Expires December 15, 2006           [Page 14] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

       [12] B. Aboba and W Dixson, "IPsec-Network Address Translation 
             (NAT) Compatibility Requirements"   

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

       [14] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 
             Shelby, "Performance Enhancing Proxies Intended to Mitigate 
             Link-Related Degradations", RFC 3135, June 2001.   

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

       [16] 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, RFC 
             3819, July 2004. 

    Author's Addresses 

       Haitham Cruickshank    
       Centre for Communications System Research (CCSR)    
       University of Surrey   
       Guildford, Surrey, GU2 7XH    
       UK    
       Email: [email-masked]    
         
       Sunil Iyengar    
       Centre for Communications System Research (CCSR)    
       University of Surrey   
       Guildford, Surrey, GU2 7XH    
       UK    
       Email: [email-masked]    
         
       Laurence Duquerroy    
       Research Department/Advanced Telecom Satellite Systems   
       Alcatel Space, Toulouse   
       France   
       E-Mail: [email-masked] 
        
       Prashant Pillai    
       Mobile and Satellite Communications Research Centre 
       School of Engineering, Design and Technology 
       University of Bradford   
       Richmond Road, Bradford BD7 1DP    
       UK    
       Email: [email-masked] 

    Cruickshank           Expires December 15, 2006           [Page 15] 
        
    Internet-Draft         Security Requirements for ULE      June 2006 

    Intellectual Property Statement 

       The IETF takes no position regarding the validity or scope of any 
       Intellectual Property Rights or other rights that might be 
       claimed to pertain to the implementation or use of the technology 
       described in this document or the extent to which any license 
       under such rights might or might not be available; nor does it 
       represent that it has made any independent effort to identify any 
       such rights.  Information on the procedures with respect to 
       rights in RFC documents can be found in BCP 78 and BCP 79. 

       Copies of IPR disclosures made to the IETF Secretariat and any 
       assurances of licenses to be made available, or the result of an 
       attempt made to obtain a general license or permission for the 
       use of such proprietary rights by implementers or users of this 
       specification can be obtained from the IETF on-line IPR 
       repository at http://www.ietf.org/ipr. 

       The IETF invites any interested party to bring to its attention 
       any copyrights, patents or patent applications, or other 
       proprietary rights that may cover technology that may be required 
       to implement this standard.  Please address the information to 
       the IETF at [email-masked]. 

    Disclaimer of Validity 

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

    Copyright Statement 

       Copyright (C) The Internet Society (2006). 

       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. 

     
    Cruickshank           Expires December 15, 2006           [Page 16]