[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 draft-ietf-ipdvb-sec-req

Internet Engineering Task Force                          H. Cruickshank
Internet Draft                                               S. Iyengar
Document: draft-cruickshank-ipdvb-sec-req-00.txt   University of Surrey
                                                              S. Combes
                                                           L. Duquerroy
                                                          Alcatel Space




Category: Internet Draft                              13 September 2005


        Security requirements for the Unidirectional Lightweight
        Encapsulation (ULE) protocol


Status of this Draft

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   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/1id-abstracts.html.

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


   Abstract

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

   Table of Contents

           < to be completed >






Expires March 2006                                            [page 1]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


           1. Introduction

   A security analysis was provided in the RFC defining the ULE method
   [ULE] and the ipdvb architecture [ipdvb-arch].  This document
   extends that analysis and derives the security requirements. The
   document provides an overview of threats that are important to 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 [ULE] 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.

   Key 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 [ipdvb-arch]. 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.


1.1 System Components

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

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













Expires Feb. 2005                                             [page 2]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005



2. Threat Analysis

   In the security considerations section of [ipdvb-arch], there is an
   initial analysis of the security requirements in MPEG-2 transmission
   networks. For example, when the MPEG-2 transmission 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 [RFC3819].  As such, it recommends that any new
   encapsulation defined by the IETF should allow Transport Stream
   encryption and also supports optional link level encryption /
   authentication of the SNDU payload. In this document, we extend the
   [ipdvb-arch] threats analysis and derive a more detailed the
   security requirements.

   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 is
   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:

   - Masquerading: where an entity pretends to be a different entity.
     This includes masquerading other users and subnetwork control
     plane messages
   - Modification of messages in an unauthorised manner.
   - 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.  However,
     this is an application layer issue and does not apply to link or
     network layer communications.
   - Replay attacks: When an intruder sends some old (authentic)
     messages to the Receiver.
   - 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.



Expires Feb. 2005                                             [page 3]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


   Active threats such as replay masquerading, modification of messages
   and injecting IP packet attacks are major security concerns for the
   Internet community and several of these attacks have been described
   [Bellovin].  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.

   However, Active threats need a careful consideration in the context
   of MPEG-2 transmission links, where the ULE method is a lightweight
   protocol and we need to be careful not to turn it into a heavyweight
   protocol by adding such security features.  A typical integrity
   check such as MD5 is 20 bytes and a typical sequence numbering
   requires 4 bytes.  Therefore new lightweight data integrity methods
   or procedures are needed.
































Expires Feb. 2005                                             [page 4]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005



3. Security Requirements for IP over MPEG-2 TS

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

   - Data confidentiality is the major requirement against passive
     threats (using encryption).  L2 encryption or L3 (IPsec)
     encryption can satisfy this requirement.  However IPsec must be
     used in tunnel mode between ULE senders and receivers, which has
     more overhead.

   - Optional protection 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.  IPsec can not provide
     this service, however this is possible with L2 security systems.

   - Layer L2 terminal authentication.  This will be part of the key
     management.  It will be performed during the initial key exchange
     and authentication phase.

   - For active threats: ULE source authentication and data 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 are another
     optional requirement.

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

   - 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
     [msec-gsakmp] and GDOI [msec-gdoi]), plus other systems such as
     DVB-RCS [ETSI-DVBRCS] and/or the development of new systems, as
     required.

   - There is a need to take into account the two cases described in
     [ipdvb-arch] for unidirectional and bi-directional transfers.

   - Other general requirements are:


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

Expires Feb. 2005                                             [page 5]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005



     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.

     Compatibility with other networking functions: Other networking
     functions such as NAT (Network Address Translation) [RFC 3715] or
     TCP acceleration can be used in a wireless DVB networks. The ULE
     security solution should be compatible with functions such as
     NAT/NAPT, IPsec, TLS, etc.  This requirement is met by ULE
     security.

     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.


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

   However, IP Multicast is considered as a major service over MPEG-2
   Transmission Networks. A document produced by the IETF msece Working
   Group on IPsec extensions for multicast [msec-ipsec-ext] describes
   extensions to [RFC2401BIS] 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 gateways and Receivers are

Expires Feb. 2005                                             [page 6]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


   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 [msec-ipsec-ext] document 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:

   - There is a need to protect the identity of ULE
     encapsulator/Receivers over the ULE broadcast medium; IPsec can
     not provide this service.

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

   - Multicast is considered as a major service over ULE links.  The
     current IPsec specifications [RFC 2401] only define a pairwise
     tunnel between two IPsec devices with manual keying. Work in
     progress [msec-ipsec-ext] is defining the extra detail needed for
     multicast and to use the tunnel mode with address preservation.
     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 [msec-ipsec-ext]
     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.




Expires Feb. 2005                                             [page 7]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


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
   [IPsec], but in addition provides link confidentiality and Receiver
   identity hiding. End-to-end security, IPsec and ULE link security
   should 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 invisaged.

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


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 an 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:

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

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

   This had the following disadvantages:

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

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



Expires Feb. 2005                                             [page 8]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


   - If the key is compromised, then this will impact several ULE
     Receivers.


5.2 Link security as a part of the Encapsulation layer

   Therefore major advantages for ULE link security are:

   - The protection of the complete ULE Protocol Data Unit (PDU)
     including IP addresses [RFC 3819].

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

   - Efficient protection of IP multicast over ULE links.

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

   - This method does not preclude the use of IPsec. 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 [DVB-DAT],
   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, an
   optional 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 new lightweight data integrity methods
   or procedures can be provided by the ULE security system

   The ULE security system should be incremental and provide ULE link
   encryption as a basic service.  Additional services such as data


Expires Feb. 2005                                             [page 9]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


   integrity and sequence number should be only provided where it is
   needed.


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 Encapsulation layer.
   In summary, there is a need for L2 encryption, ULE Receiver identity
   hiding, L2 source authentications and protection against insertion
   of other data into the ULE stream.


7. Acknowledgments

   The authors acknowledge the help and advice from Gorry Fairhurst
   (University of Aberdeen) in the preparation of this draft.


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


9. References

9.1 Normative References

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

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

   [ULE] Fairhurst, G., Collini-Nocker, "Ultra Lightweight
   Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2
   Transport Stream", <draft-ietf-ule-06.txt>, IETF Work in Progress.

   [ipdvb-arch] M.J. Montpetit ed., et al, "Framework for transmission
   of IP datagrams over MPEG-2 Networks", <draft-ietf-ipdvb-arch-
   04.txt>, IETF Work in Progress.

Expires Feb. 2005                                            [page 10]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005



9.2 Informative References

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

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

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

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

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

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

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

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

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

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

   [RFC2401] Kent, S., et al, "Security Architecture for the Internet
   Protocol", RFC 2401, November 1998.

   [RFC2401BIS] Kent, S. and Seo K., "Security Architecture for the
   Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt, March, 2005.

   [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
   Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
   "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July
   2004.







Expires Feb. 2005                                            [page 11]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


10.Authors' Addresses

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

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

Stephane Combes
Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse
France
E-Mail: stephane.combes@space.alcatel.fr

Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse
France
E-Mail: Laurence.Duquerroy@space.alcatel.fr


11. IPR Notices

11.1 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

Expires Feb. 2005                                            [page 12]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB         Sept. 2005


   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


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


12. Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.


13. IANA Considerations

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

























Expires Feb. 2005                                            [page 13]


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