Network Working Group P. Pillai Internet-Draft Y. F. Hu Expires: October 28, 2006 University of Bradford April 26, 2006 Secure Unidirectional Lightweight Encapsulation Protocol draft-ppillai-ipdvb-SULE-00.txt Status of this Memo 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 October 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the Secure Unidirectional Encapsulation Protocol (S-ULE) that secures the IP traffic transported using ULE to provide data authentication, data confidentiality, data integrity and to mechanisms to prevent replay attacks. Pillai & F. Hu Expires October 28, 2006 [Page 1] Internet-Draft Secure ULE April 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 6 4. Secure ULE SNDU Format . . . . . . . . . . . . . . . . . . . . 7 4.1. Destination Address Absent (D) Field . . . . . . . . . . . 7 4.2. Length Field . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Type Field . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Destination NPA Address Field . . . . . . . . . . . . . . 8 4.5. ULE_Security_ID Field . . . . . . . . . . . . . . . . . . 8 4.6. Sequence Number Field . . . . . . . . . . . . . . . . . . 8 4.7. Type Field . . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Encrypted PDU . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Message Authentication Code (MAC) Field . . . . . . . . . 9 5. Receiver Procedure . . . . . . . . . . . . . . . . . . . . . . 10 6. Secure ULE SNDU example . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Pillai & F. Hu Expires October 28, 2006 [Page 2] Internet-Draft Secure ULE April 2006 1. 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]. Pillai & F. Hu Expires October 28, 2006 [Page 3] Internet-Draft Secure ULE April 2006 2. Introduction The Unidirectional Encapsulation Protocol [RFC4326] is used for the transportation of user traffic like IP datagrams, Ethernet frames,etc. over ISO MPEG-2 Transport Streams [RFC4259] . This document describes the Secure ULE protocol that can be used for securing these ULE SNDUs for providing all the different security requirements. The set of security services that Secure ULE can provide includes access control, data integrity, data origin authentication, rejection of replayed packets and also data confidentiality. On Securing the ULE SNDUs, security is provided at the link layer as opposed to other existing mechanisms like IPSEC that provides security at the network-layer or TLS that provides transport-layer security. Since these services are provided at the link layer any network layer protocol like IP, Ethernet, etc. may be used with Secure ULE. IPSEC [RFC2401] is one of the most widely deployed security protocols that addresses all the important security requirements. Though IPSEC in tunnel mode can be used to provide security over the MPEG-2 transmission networks, but it has several disadvantages. Some of these are: o The extra IP header introduces large overheads. o Data Confidentiality is not provided for the complete IP Packets, i.e. the outer IP Header are not secured, hence the IPSEC tunnel end points are not hidden. o IPSEC can be used to secure only IP datagrams and cannot be used to provide security services for any other network protocols that may be transported over the MPEG-2 Transport Streams using ULE (like Ethernet Frames, MPLS, ATM, etc.) o IPSEC is incompatible with NAT o IPSEC is incompatible with TCP Performance Enhancing Proxies (PEP) [RFC3135] that may be used in MPEG-2 based systems like the Digital Video Broadcast (DVB) using the satellite for downlink [DVBS] and uplink [DVBRCS] Secure ULE aims to provide the same level of security services as provided by IPSEC but with less packet overheads. Since Secure ULE provides security between the MPEG-2 transmitter and receiver for individual users at the link layer, it is not restricted to only IP Pillai & F. Hu Expires October 28, 2006 [Page 4] Internet-Draft Secure ULE April 2006 datagrams but can alsobe used for any network protocol that can be carried by ULE including IP, Ethernet, ATM, MPLS etc. Secure ULE shall use key management protocols like IKASMP, GDOI, GSAKMP, MIKEY, etc to manage all the security related keys for the individual users and multicast groups. These are out of scope of this document. Pillai & F. Hu Expires October 28, 2006 [Page 5] Internet-Draft Secure ULE April 2006 3. Security Requirements MPEG-2 based networks are susceptible to several security attacks, both passive and active. Some of the main security requirements that Secure ULE aims to achieve for IP services running on MPEG-2 based systems are: o Data Authentication: Data authentication allows a receiver to verify that the data is sent by the claimed sender. Data authentication can be achieved by calculating a Message Authentication Code (MAC) using a shared secret key. This MAC is also transmitted along with the data. The receiver would also calculate the MAC for the received data using the shared key, and then compare this computed MAC value to the one sent by the sender along with the data. If the two matches, then the receiver knows that the data had to be sent from the claimed sender. Hence the message is authenticated. o Data Integrity: Data integrity provides a way for the receiver of the data message to know if the data has been tampered in transit by an attacker. Data integrity is closely related to data authentication. The MAC used for data authentication also provides data integrity. The receiver of the data calculates the MAC and compares it to the one transmitted by the sender. If an adversary had tampered with the message then the two MACs would not match. o Data Confidentiality: Data confidentiality is achieved by encrypting the information before transmission so that only authorised people can decrypt the transmitted information while an adversary would not be able to recover the important information even if it got hold of the transmitted data. o Replay Attacks Countermeasures: Methods against replay attacks need to ensure that the received data is recent and that an adversary has not replayed old messages at a later time. One of the most common methods to provide data freshness is to use a monotonically increasing sequence number with every message and reject any messages with old sequence number values. Pillai & F. Hu Expires October 28, 2006 [Page 6] Internet-Draft Secure ULE April 2006 4. Secure ULE SNDU Format Secure ULE aims to secure the transmission of user traffic over MPEG-2 Transport Streams. In order to address the security issues, Figure 1 shows the packet format of the Secure ULE protocol. The higher layer data PDUs are encapsulated using Secure ULE to form an Secure ULE (S-ULE) SNDU similar to the standard ULE SNDUs. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |D| Length | Type = S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address * | | +------------------------------+ | | ULE_Security_ID | +------------------------------+------------------------------+ | ULE_Security_ID | Sequence Number | +------------------------------+------------------------------+ | Sequence Number | Type = Type of PDU | +------------------------------+------------------------------+ | | | | = Encrypted PDU = | | | | +-------------------------------------------------------------+ | Message Authentication Code (MAC) | | | +-------------------------------------------------------------+ Figure 1: Secure ULE SNDU The Secure ULE Header extension is derived from the ULE base header and follows the mandatory extension header format. The extension header for Secure ULE consists of a 32-bit security identifier, ULE_Security_ID and a 32-bit sequence number. This is then followed by the type field which indicates the type of the payload being encapsulated. The format of the Destination Address Absent field (D), the Length field the Type field and the Receiver Destination NPA address field directly follow and are used in the same way as defined for standard ULE [RFC4326]. 4.1. Destination Address Absent (D) Field The most significant bit of the Length Field carries the value of the Pillai & F. Hu Expires October 28, 2006 [Page 7] Internet-Draft Secure ULE April 2006 Destination Address Absent Field (D) which follows the same defination as in standard ULE[RFC4326]. When D is set to 0, it indicates the presence of the Destination Address Field while D set to 1 indicates that a Destination Address Field is not present. 4.2. Length Field A 15-bit Length field denotes the length, in bytes, of the SNDU counted from the byte following the Type field, up to and including the MAC[RFC4326]. 4.3. Type Field A 16-bit Type Field indicates that this is a Secure ULE SNDU [RFC4326]. [XXX IANA ACTION REQUIRED XXX] IANA action is required to assign the Type field for Secure ULE. [XXX END of IANA ACTION XXX] 4.4. Destination NPA Address Field The SNDU Destination Address Field is optional . This field is MUST be carried when field D is set to 0 and may be ommited when D=1 [RFC4326]. 4.5. ULE_Security_ID Field A 32-bit security identifier, the ULE_Security_ID similar to the Security Parameter Index (SPI)used in IPSEC has been added to uniquely identify the secure session. This ULE_Security_ID would represent the security association between the MPEG-2 transmitter and receiver for a particular session and will indicate the keys and algorithms used for encrypting the data payload. Encryption algorithms like DES, 3DES, etc. may be used for encrypting the data. 4.6. Sequence Number Field A 32-bit sequence number has been added to the ULE SNDU to prevent replay attacks. The value of this sequence number would be set to 0 at the beginning of the session. The gateway would monotonically increment this number when it sends a packet to the receiver and the receiver would verify the correct sequence number. If an adversary tries to inject or replay old packets the sequence number would not match. This would result in discarding the packet. Pillai & F. Hu Expires October 28, 2006 [Page 8] Internet-Draft Secure ULE April 2006 4.7. Type Field This second type field denotes the type of packet that is encapsulated in the Secure ULE SNDU. 4.8. Encrypted PDU To achieve data confidentiality, the traffic between the two MPEG-2 TS Transmitter and Receiver needs to be encrypted. The network layer PDUs are first encrypted and then encapsulated in the Secure ULE SNDU. The security associations between the two communicating points will describe the algorithms and keys used for encryption purposes. Secure ULE does not impose the use of any specific encryption algorithm, but instead should be able to support the commonly used algorithms like DES, 3DES etc. 4.9. Message Authentication Code (MAC) Field To provide both data authenticity and data integrity, a Message Authentication Code (MAC) is used instead of the 32-bit CRC proposed by the original ULE protocol. The MAC is calculated over the extension header and the data payload. The receiver would calculate the MAC for the received packet and compare it with the transmitted value. The two would not match in only 2 cases, firstly either there was an error during processing or transmission over the MPEG-2 Network, or secondly the packet has not been sent from an authenticated entity. In either case, the packet should be discarded. Hence the same MAC can be used for data origin authentication and to provide data integrity for transmission/ processing errors. To directly replace the 32-bit CRC, HMAC-MD5-32 or HMAC-SHA1-32 can be used for generating a 32-bit MAC. However, a short MAC may be susceptible to brute force attacks according to the birthday paradox. Secure ULE when used in MPEG-2 networks such as the Digital Video Broadcast (DVB) architecture or the Advanced Television Systems Committee (ATSC) would work along with other security mechanisms provided at the lower layers like the common scrambling and/or DVB- RCS individual scrambling mechanisms in DVB. Under such scenarios a 32-bit MAC may be sufficient. If a stronger MAC is still required, then similar to IPSEC, HMAC-SHA1-96 may be used. Pillai & F. Hu Expires October 28, 2006 [Page 9] Internet-Draft Secure ULE April 2006 5. Receiver Procedure Upon reception of the Secure ULE SNDU, the receiver may first filter the received packets according to the recevier destination NPA address (if present). It would then use the ULE_Security_ID to Obtain the security associations between the transmitter and receiver. With this the receiver would know the algorithms and keys used for both encryption of the encapsulated PDU and for generation of the message authentication code. It would then use the sequence number for filtering out any out-of-sequence packets. The next step would be to check the MAC to verify the authenticity and integrity of the received packet. If the calculated MAC does not match the transmitted MAC, then the packet is discarded. Finally the encapsulated payload will be decrypted. Pillai & F. Hu Expires October 28, 2006 [Page 10] Internet-Draft Secure ULE April 2006 6. Secure ULE SNDU example This section describes the Secure ULE SNDU when IP datagrams are secured using Secure ULE. First the header of the Secure ULE SNDU is formed by adding the ULE_Security_ID and the Sequence number for this particular session. Then the type of the PDU being carried is added to the header. The IPv4 datagrams are first encrypted using the algorithms and keys defined during the setup of the security association between the transmitter and receiver and then added to the Secure ULE SNDU, which is the followed by the message authentication code. The two encapsulation are shown below in Figure 2 and Figure 3. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |0| Length (15 bits) | Type = S-ULE | +-+----------------------------+------------------------------+ | Receiver Destination NPA Address (48 bits) | | +------------------------------+ | | ULE_Security_ID | +------------------------------+------------------------------+ | ULE_Security_ID | Sequence Number | +------------------------------+------------------------------+ | Sequence Number | Type = IPv4 | +------------------------------+------------------------------+ | | | | = Encrypted IP Datagram = | | | | +-------------------------------------------------------------+ | Message Authentication Code | | | +-------------------------------------------------------------+ Figure 2: Secure ULE SNDU with D=0 Pillai & F. Hu Expires October 28, 2006 [Page 11] Internet-Draft Secure ULE April 2006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+----------------------------+------------------------------+ |1| Length (15 bits) | Type = S-ULE | +-+----------------------------+------------------------------+ | ULE_Security_ID | +-------------------------------------------------------------+ | Sequence Number | +------------------------------+------------------------------+ | Type = IPv4 | | +------------------------------+ | | | | | = Encrypted IP Datagram = | | | | +-------------------------------------------------------------+ | Message Authentication Code | | | +-------------------------------------------------------------+ Figure 3: Secure ULE SNDU with D=1 Pillai & F. Hu Expires October 28, 2006 [Page 12] Internet-Draft Secure ULE April 2006 7. Security Considerations To Be Completed. Pillai & F. Hu Expires October 28, 2006 [Page 13] Internet-Draft Secure ULE April 2006 8. IANA Considerations IANA action will be required to assign a ULE Type registry entry for this protocol. Pillai & F. Hu Expires October 28, 2006 [Page 14] Internet-Draft Secure ULE April 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Streams", RFC 4326, December 2005. 9.2. Informative References [DVBRCS] "Digital Video Broadcasting (DVB): Interaction Channel for satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005. [DVBS] "Digital Video Broadcasting (DVB): Framing structure, channel coding and modulation for 11/12 GHz satellite services", ETSI EN 301 421 v1.1.2, 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, 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. [RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005. Pillai & F. Hu Expires October 28, 2006 [Page 15] Internet-Draft Secure ULE April 2006 Authors' Addresses Prashant Pillai University of Bradford School of Engineering, Design and Technology Bradford, West Yorkshire BD7 1DP United Kingdom Phone: +44 1274 233720 Email: p.pillai@bradford.ac.uk Yim Fun Hu University of Bradford School of Engineering, Design and Technology Bradford, West Yorkshire BD7 1DP United Kingdom Phone: +44 1274 234151 Email: y.f.hu@bradford.ac.uk Pillai & F. Hu Expires October 28, 2006 [Page 16] Internet-Draft Secure ULE April 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 ietf-ipr@ietf.org. 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. Acknowledgment To be completed. Pillai & F. Hu Expires October 28, 2006 [Page 17]