Internet Engineering Task Force H. Cruickshank Internet Draft S. Iyengar Document: University of Surrey draft-cruickshank-ipdvb-sec-00.txt S. Combes L. Duquerroy Alcatel Space Category: Internet Draft 24 June 2005 A Secure Extension 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 proposes a security framework for the Unidirectional- Lightweight Encapsulation (ULE) protocol. It provides threat analysis and defines the requirements for ULE security. It also proposes an extension format for the Unidirectional-Lightweight Encapsulation (ULE) protocol. This work is intended as a work item of the ipdvb WG, and contributions are sought from the IETF on this topic. Expires December 2005 [page 1] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 Table of Contents 1. Introduction 1.1 Security requirements for IP over MPEG-2 TS 1.2 Defintions used in this document 2. Link Security Protocol 2.1 Encryption of the SNDU payload 2.2 Encryption Extension Header format 3. Key Exchange Procedure 3.1 IPsec Key Management for L2 3.2 Alternative Key Management 4. Summary 5. Acknowledgments 6. Security Considerations 7. References 7.1 Normative References 7.2 Informative References 8. Authors' Addresses 9. IPR Notices 10.1 Intellectual Property Statement 10.2 Disclaimer of Validity 11. Copyright Statement 12. IANA Considerations Annexe A. Examples of use Expires December 2005 [page 2] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 1. Introduction This document describes an extension header for providing link-layer security for the ULE [ULE] encapsulation which supports transport of IP datagrams or other network layer packets over ISO MPEG-2 Transport Streams [ISO-MPEG]. In MPEG-2 transmission networks employing ULE, there is a need to provide link-layer (L2) security, particularly where network-layer and transport-layer security (e.g. IPsec, TLS) may not be sufficient. There are pros and cons for both IPsec and ULE security. The major advantage of IPsec is its wide implementation in IP routers and hosts. The decision to use IPsec in transport mode is a decision made by a specific pair of end-hosts. The use in tunnel mode is a choice for the user/network operator. Tunnel mode may (and sometimes is) used to provide security over particular types of link (including MPEG-2 transmission links). However, there are overheads associated with using IPsec in tunnel mode as a method to protect such links. IPsec tunnel mode also does not provide security services for other network protocols that may be used with ULE (e.g. MPLS, Ethernet Bridging), requiring several methods to be implemented. Another issue, that is important in some deployment scenarios, is the need to protect the identity of end users/Receivers over a broadcast medium; IPsec can not provide this service. ULE link security is therefore considered an additional security mechanism to IP, transport, and application layer security, not a replacement. It provides similar functions to that of IPsec [IPsec], but in addition provides link confidentiality. End-to-end security, IPsec and ULE link security can work in parallel: IPSsec providing end-to-end security between hosts and ULE providing security over the MPEG-2 transmission link. However, there is no direct interaction between the IPsec [RFC2401,RFC2402, RFC2406] and the ULE security system. ULE may use and benefit from IETF key management protocols, such as the MSEC GDOI [RFC3547, RFC 3547] and GSAKMP [msec-gsakmp]. This does not preclude the use of other key management methods in scenarios which benefit from this. A security analysis is provided in the RFC describing the ipdvb architecture [ipdvb-arch]. 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 matches 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. This document specifies a mode that provides optional support for Layer 2 MAC/NPA address encryption. Expires December 2005 [page 3] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 To support optional link level encryption, an encryption extension header is defined, and included in the SNDU payload. This approach is generic and decouples the encapsulation from the evolution of future security methods. The proposed approach suggests a new ULE Mandatory Extension header for a security association id (similar to the IPsec SPI [IPsec]). Encryption algorithms, key lengths, etc. will be defined making use of the standard IPsec suites [msec]. The focus is on providing suitable link encryption. Link layer data integrity is not considered critical for ULE, because ULE provides a checksum function, which covers several aspects of data integrity. However, Link layer data integrity should be provided as an optional security service, especially for systems where there are several ULE transmitters (e.g. satellite meshed systems with On-Board Processing) The major advantages for ULE security are: - The 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. In some environments, the use of specialist cryptos is seen as a positive advantage. - The protection of the complete PDU including IP addresses and user identity hiding [RFC 3819]. - Ability to protect the identity of the Receiver within the MPEG-2 transmission newtwork. This includes hiding the IPsec tunnel end- point and optionally the receiver L2 identity (MAC/NPA addresses). - For packets that are not covered by IPsec, implementing security at the ULE level provides transparency to the use of TCP Performance Enhancing Proxies (PEP) [RFC3135], which require the ability to inspect and modify the packets sent over the ULE link. TCP PEPs are important to many currently deployed networks. The use of transport IPsec or client-controlled tunnel IPsec are not compatible with the use of TCP PEPs. - For packets that are not covered by IPsec, transparency to the use of Network Address Translation (NATs), which require the ability to inspect and modify the packets sent over the ULE link. - Lower CPU processing (Receiver decryption is performed at each destination L2 Receiver, instead of for each destination IP address, where destination L2 Receiver may receive many IP streams. 1.1 Security requirements for IP over MPEG-2 TS This subsection provides a brief overview of the threats to networks that employ ULE and then derives the security requirements. The simplest type of network threats are passive threats. Passive attackers are involved in eavesdropping on, or monitoring of, Expires December 2005 [page 4] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 transmissions, with a goal to obtain information that is being transmitted. In broadcast networks (utilising widely available physical layer interfaces, such as DVB) passive threats are considered the major threats. 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. - 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. From the above analysis, the following security requirements can be derived: - End-to-end security (such as IPsec) and ULE link security should work in parallel without obstructing each other. - Data confidentiality is the major requirement against passive threats (using encryption). - Optional protection of Layer 2 MAC/NPA address. - 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: Source authentication and data integrity are required, using techniques such as message authentication code and digital signatures. Active threats can be considered as minor threats in MPEG-02 transmission networks. Therefore, L2 data integrity/authentication is optional, but still important in environments in which several independent networks share a single transmission resource. - 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. GDOI [RFC3547] and GSAKMP [msec-gsakmp]), plus other systems such as DVB-RCS [ETSI-DVBRCS] and/or the development of new systems, as required. - 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. . Traceability (such as using intrusion detection systems) to monitor transmisison network (e.g. using log files to record the activities on the network). This is out of scope for ULE security. Expires December 2005 [page 5] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 . Operational issues: Because of the possible large coverage of 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) [RFC3715] 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. 1.2 Defintions used in this document AES Advanced Encryption Standard [msec-gsakmp] D-bit Destination Address Omitted field [ULE] DVB Digital Video Broadcast GDOI Group Domain of Interpretation [RFC3547] GSKAMP Group Secure Association Key Management Protocol [msec- gsakmp] IPsec Internet Protocol Security suite [ipsec, RFCs 2401, 2402 and 2406] L2 Link Layer MPE Multi-Protocol Encapsulation [DVB-DAT] NAT Network Address Translation [RFC3715] NCC Network Control Centre PEP Protocol Enhancing Proxy [RFC3135] PID Packet Identifier [ISO_MPEG] PDU Protocol Data Unit (IP packey, MPLS farme, etc) SHA-1 Standard Hash Algorithm 1 [msec-gsakmp] SID Security Identifier SNDU Subnetwork Data Unit [ULE] TLS Transport Layer Security [TLS] TS MPEG-2 Transport Stream [ipdvb-arch] ULE Unidirectional-Lightweight Encapsulation Expires December 2005 [page 6] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 2. Link Security Protocol This section describes the link security protocol for the ULE protocol. 2.1 Encryption of the SNDU payload The security suite of algorithms for data encryption and data integrity specified in IPsec/MSEC will be used for ULE security. The SNDU padding must be used in order to make the SNDU length as multiples of 8 or 16 byes depending on the type of encryption algorithm used. Another issue is key space there is a need for two databases for the correct processing on security in ULE Transmitters and Receivers: Ñ Security Policy Database (SPD): This database contains the policies that determine the processing of all ULE inbound/outbound traffic (such as encrypting all outbound ULE traffic destined to a certain terminal). Ñ Security Association Database (SAD): Each entry defines the parameters associated with one ULE-SID such as encryption keys. Each ULE-SID has an entry in the SAD. The main aim of this document is to re-use existing techniques in IPsec architecture and therefore the SDP and SAD will follow the format of these databases as defined in RFC 2401 [RFC2401]. 2.2 Encryption Extension Header format A ULE [ULE] encryption header extension is defined for use with any ULE payload. This extension header MAY directly follow the ULE base header (as illustrated in figures 1 and 2). It MAY also follow another specified extension header. The Encryption Extension is a Mandatory ULE Extension Header. This means that a Receiver MUST either process this header, before it processes the next header (or the enclosed PDU), otherwise the entire SNDU is to be discarded. The first two bytes of the encrypted data block contain a ULE Type field, defined by [ULE] that specifies the type/extension header that follows. This document defines one code-point for encryption headers. SNDUs that are not encrypted, do NOT include this header. [XXX IANA ACTION REQUIRED XXX] IANA action is required to assign one code point from ULE Mandatory Next-Layer-Header Registry. 00YY Secure ULE [XXX END of IANA ACTION XXX] Expires December 2005 [page 7] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 The ULE Security IDentifier (ULE-SID) is a 32 bit value. The ULE-SID can be used by a Receiver to filter PDUs in conjunction with the set of MAC/NPA addresses that it wishes to receive. The format of the ULE-SID will be specified in this document. One option for ULE-SID is to have a similar format to the Security Parameter Index (SPI) used in IPSEC and MSEC protocols. A second option is that it may contain two subfields: . KeyID: This tells the Receiver which key to use to decrypt the current ULE packet. . 23 bits MAC/NPA address (encrypted or open) The combined value of both fields in the ULE-SID MUST be used to filter ULE packets in the Receivers. The extension MAY be used with PDUs that carry a NPA/MAC address (D=0) or with PDUs that omit this field (D=0). In the latter case, a Receiver of an encrypted ULE PDU will not carry a NPA/MAC. If the MAC/NPA address is encrypted, then the key management system is responsible for generating this temporary MAC/NPA address. Temporary MAC/NPA address will change from time to time depending on the security policy and it is not directly related to each ULE session. It can change periodically (for example after a specified period of time and/or after a specified volume of traffic has been sent to that terminal). The impact of such a design is that each Receiver and the Network Control Centre (NCC) will use two MAC/NPA addresses when filtering: one for unencrypted traffic and the second Temporary value for secure traffic. This rule will apply to both unicast and multicast connections. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |0 | Length (2B) | Type = Secure ULE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Receiver Destination NPA Address (6B) | + +--+--+--+--+--+--+--+--+ | | ULE SID (part 1) | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | ULE SID (part 2) | | | Encrypted +--+--+--+--+--+--+--+--+ + | = = | | Data Block | | | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + ULE CRC-32 (4B) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 1: SNDU Format for the Encryption Header (D=0). Expires December 2005 [page 8] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |1 | Length (2B) | Type = Secure ULE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ULE SID (4B) | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | = = | Encrypted | Data Block | | | | > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | + ULE CRC-32 (4B) + | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: SNDU Format for the Encryption Header (D=1). This encryption header has a type value with one of two IANA- assigned 16-bit next-layer-header values. Expires December 2005 [page 9] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 3 Key Exchange Procedure This section describes the key exchange procedure, used to install and manage the keys at Receivers. There is a need to take into account the two cases described in [ipdvb-arch], both: unidirectional and bi-directional transfers. The key management procedures are independent from the ULE operations. During the key exchange procedure, the ULE-SID will be defined. The ULE-SID is one link between ULE and the security systems. The other link is the temporary MAC/NPA address. The exact data encryption and data integrity choices are linked to the key management systems in use. One example is the security suite 1 (defined in GSAKMP [msec-gsakmp]). This uses AES (CBC mode, Key Length: 128 bits) for data encryption and DSS-ASN1-DER for digital signature and SHA-1 as the Hash algorithm. Other suites will be added in future versions. A detailed key management system is not presented in this document, but two approaches are outlined in this section. 3.1 IPsec Key Management for L2 Existing key management systems can be used such as the MSEC key exchange protocols, GDOI and GSAKMP [RFC3547 and msec-gsakmp]. The format of the ULE-SID will be identical in format to the security association as defined in GDOI or GSAKMP. The initial key exchange between the security server (which may reside with NCC) and the ULE Receiver can be transported either within the ULE network or may be performed by some other means. This is a matter of policy and an architecture decision. For example, for bi-directional transfers the whole key exchange procedures could be carried within the ULE network, while for unidirectional transfers, some other bidirectional connection should be used. 3.2 Alternative Key Management The method described is a general method for link encryption and could be used with alternative key management systems when used as a part of a system that already implements a key management infrastructure (e.g. the DVB-RCS security system [ETSI-DVBRCS]). The format of the ULE-SID will be the same format as defined in DVB-RCS security procedures. Expires December 2005 [page 10] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 4. Summary This document proposes a security framework for a layer 2 security method designed for the Unidirectional-Lightweight Encapsulation (ULE) protocol. It provides threat analysis and defines the requirements for ULE security. It also proposes an extension format for the Unidirectional-Lightweight Encapsulation (ULE) protocol. The key management for this protocol may be performed using IPsec methods such as the msec gsakmp and gdoi protocols, or using other methods not defined in this document. Expires December 2005 [page 11] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 5. Acknowledgments The authors acknowledge the help and advice from Gorry Fairhurst (University of Aberdeen) in the preparation of this draft. 5. 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 terrestrial 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 defines a method to provide optional link encryption. The method may also support optional link level integrity / authentication of the SNDU payload. This is provided in a flexible way using a ULE Mandatory Extension Header. This decouples specification of the security functions from the encapsulation functions. This method also supports encryption of the NPA/MAC addresses. The encryption and integrity algorithms are similar to the ones used in IPSEC/MSEC protocols. 6. References 6.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, "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", , IETF Work in Progress. 6.2 Informative References [ETSI-DVBRCS] "Digital Video Broadcasting (DVB): interaction channel for satellite distribution systems", ETSI EN 301 790 V1.4.1 (2005- 04) [msec-gsakmp] H Harney (SPARTA ), et al, "GSAKMP: Group Secure Association Group Management Protocol", , IETF Work in Progress. Expires December 2005 [page 12] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 [ipdvb-arch] M.J. Montpetit ed., et al, "Framework for transmission of IP datagrams over MPEG-2 Networks", , IETF Work in Progress. (RFC Ed Queue)_ [msec] http://www.ietf.org/html.charters/msec-charter.html [IPsec] http://www.ietf.org/html.charters/wg- dir.html#Security%20Area. [TLS] http://www.ietf.org/html.charters/tls-charter.html [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. {RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [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. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [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 . 8.Authors' Addresses Expires December 2005 [page 13] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 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 9. IPR Notices Expires December 2005 [page 14] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 9.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 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9.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. 10. 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. 12. IANA Considerations Expires December 2005 [page 15] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 This document will require IANA involvement. A Mandatory Header Extension value is required to be assigned from the ULE Registry. The length of the Extension Header is 4B plus the encrypted block of data. Expires December 2005 [page 16] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 Annexe A. Examples of use No examples of use are provided in this revision of the I-D. Expires December 2005 [page 17] INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB June 2005 RFC EDITOR NOTE This section must be deleted prior to publication DOCUMENT HISTORY This draft is intended as a study item for the IETF ipdvb WG. Comments relating to this document will be gratefully received by the author(s) and the ipdvb mailing list at: ipdvb@erg.abdn.ac.uk Draft -00 [END of RFC EDITOR NOTE] Expires December 2005 [page 18]