DICE D. Migault (Ed) Internet-Draft Orange Intended status: Standards Track C. Bormann Expires: January 24, 2015 Universitaet Bremen TZI July 23, 2014 IPsec/ESP for Application Payload draft-mglt-dice-ipsec-for-application-payload-00.txt Abstract This document is a strawman specification describing how IPsec/ESP could be used to secure application payloads, in particular to enable multicast applications where DTLS would be used for unicast. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 24, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Migault (Ed) & Bormann Expires January 24, 2015 [Page 1] Internet-Draft IPsec/ESP for Application Payload July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 2. State of the Art . . . . . . . . . . . . . . . . . . . . . . 3 3. UDP-Encapsulation Header . . . . . . . . . . . . . . . . . . 5 4. Removing Transport Header . . . . . . . . . . . . . . . . . . 6 5. Additional Compression . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informational References . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [I-D.keoh-dice-multicast-security] defines a way to protect multicast traffic against group outsiders using a modified DTLS record protocol. Reservations have been voiced about modifying DTLS this way without strengthening security by adding data origin authentication. However, many applications do not require this additional security. One protocol that already supports group-level security for multicast is IPsec. This document discusses how IPsec can be used to secure data at the application layer. The resulting packet structure is expected to resemble a DTLS flavor as represented in Figure 1. +--------+-------------------------------------------------+ | | +--------+------------------------------------+ | | | | | +-------------+------------------+ | | | | | | | | +--------------+ | | | | IP | | UDP | | Security | | Application | | | | | header | | header | | Header | | Data | | | | | | | | | | +--------------+ | | | | | | | +-------------+------------------+ | | | | +--------+------------------------------------+ | +--------+-------------------------------------------------+ Figure 1: Securing Application Data Migault (Ed) & Bormann Expires January 24, 2015 [Page 2] Internet-Draft IPsec/ESP for Application Payload July 2014 1.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]. 2. State of the Art IPsec/ESP [RFC4303] has been designed to secure IP payload according to two different modes: the transport mode and the tunnel mode. Figure 2 represents an non protected UDP packet that is protected with IPsec/ESP. UDP is chosen as an example and could be any other transport mode like TCP or SCTP, or ANY for unknown transport. Figure 3 illustrates how IPsec/ESP secures the non protected packet using the transport mode and Figure 4 illustrates how IPsec/ESP secures the packet with the tunnel mode. +--------------------------+ | IP Header | +--------------------------+ | UDP Header | +--------------------------+ | Application | | Data | +--------------------------+ Figure 2: Example: non protected IP Packet +--------------------------+ | IP Header | +--------------------------+--- | ESP Header | ^ ---+--------------------------+ | ^ | IV | | | +--------------------------+ | | | UDP Header | | Integrity | +--------------------------+ | Protection Encryption | | Application | | | | Data | | | +--------------------------+ | v | ESP Trailer | v --- +--------------------------+--- | ICV | +--------------------------+ Figure 3: Example: IPsec/ESP with transport mode Migault (Ed) & Bormann Expires January 24, 2015 [Page 3] Internet-Draft IPsec/ESP for Application Payload July 2014 +--------------------------+ | Tunnel IP Header | +--------------------------+--- | ESP Header | ^ ---+--------------------------+ | ^ | IV | | | +--------------------------+ | | | IP Header | | Integrity Encryption | +--------------------------+ | Protection | | UDP Header | | | +--------------------------+ | | | Encrypted Application | | | | Data | | | +--------------------------+ | v | ESP Trailer | v ---+--------------------------+--- | ICV | +--------------------------+ Figure 4: Ex: IPsec/ESP with tunnel mode This document does not consider the tunnel mode and only the transport mode. DTLS is usually used to secure application data. Among other differences, IPsec/ESP with transport mode differs from DTLS on the following aspects: 1) The Security Header is placed before the transport header, as a result 2) the transport header is encrypted. Then 3) IPsec/ESP is an extension of IP which makes the whole packet described in Figure 3 and Figure 4 an IP packet with an empty IP payload. One consequence is that the packet has to respect the bit alignment required for IP headers, that is 32 bit alignment for IPv4 and 64 bit alignment for IPv6. This is why the ESP Trailer presents some Padding. Figure 3 and Figure 4 mentions the IV which is necessary for encryption and decryption. The IV is usually not part of the IPsec/ ESP protocol, but is defined by the encryption protocol used by IPsec/ESP. Each encryption protocol defines the size of its IV. It is mentioned in the figures in order to clarify the way we compute the overhead. For NAT traversal, IPsec has defined a UDP encapsulation in [RFC3948]. UDP encapsulation of the IPsec/ESP packet with transport mode is illustrated in Figure 5. Migault (Ed) & Bormann Expires January 24, 2015 [Page 4] Internet-Draft IPsec/ESP for Application Payload July 2014 +--------------------------+ | IP Header | +--------------------------+ | UDP-Encapsulation | +--------------------------+--- | ESP Header | ^ ---+--------------------------+ | ^ | IV | | | +--------------------------+ | | | UDP Header | | Integrity | +--------------------------+ | Protection Encryption | | Application | | | | Data | | | +--------------------------+ | v | ESP Trailer | v --- +--------------------------+--- | ICV | +--------------------------+ Figure 5: Ex: UDP Encapsulation of IPsec/ESP Transport mode As illustrated in Figure 5, using IPsec/ESP with UDP encapsulation achieves our goal: A UDP packet carries a encrypted payload. In Figure 5, the encrypted payload is the concatenation of the IV, the UDP header, the application data and the ESP Trailer. The overhead of such a packet is the ESP Header (8 bytes), the IV (8 bytes for AES-CCM mode [RFC4309]), an extra UDP header (8 bytes), the ESP Trailer (2 bytes and padding bytes. Padding bytes are between 0 and 8 for 64 bit alignment in IPv6 and between 0 and 4 bytes for IPv4. As a result, the average is 6 bytes for IPv6 and 4 bytes for IPv4). This leads to a 30 bytes overhead for IPv6 and 28 byte overhead for IPv4. If this approach is to be pursued, it is probably worthwhile to reduce this overhead The remaining sections describe ways to do that. 3. UDP-Encapsulation Header [RFC3948] specifies that ports of the UDP-Encapsulation Header MUST be the one used during the IKEv2 negotiation. In addition IKEv2 is listening for UDP encapsulation on port 4500. As a result, the port of the responder is always set to 4500 for any ESP packet. The use of a fix port in 4500 for IKEv2 is a standard port that specifies, IKEv2 packets are expected to be UDP encapsulated. The Migault (Ed) & Bormann Expires January 24, 2015 [Page 5] Internet-Draft IPsec/ESP for Application Payload July 2014 reason to keep these ports in the ESP UDP encapsulated communication, is that 1) IKEv2 has set a channel between the peers through a NAT -- note that each peer may have a different set of (port source, port destination). 2) IKEv2 is used to set up the IPsec/ESP communication on each peer by setting the various IPsec database. Since IKEv2 is aware of a through-NAT-reachable channel, IKEv2 can proceed to UDP encapsulation setting on each hosts. Port fixing is not required in applications other than the UDP encapsulation or if IKEv2 is not used to setup the IPsec/ESP communication. 4. Removing Transport Header The Transport Header is used to identify the application with ports, once IPsec has decrypted an incoming packet. For sending packets, the ports in the transport header can be used as Traffic Selectors to identify the right Securicy Policy. Removing the Transport Header implies that none of the ports or transport protocol can be used as selectors. IPsec [RFC4301] does not prevent that, and only the IP addresses will be considered, and thus all applications that do not use ports as selectors between the two peers will be protected with the same SA. Note that IPsec SPD is an ordered database. This means that if an application between the two peers with ports specified as Traffic Selectors needs a specific Security Association, this is still possible. The policy has simply to be placed before the policy using only IP addresses. 5. Additional Compression With the current standard [RFC3948], [RFC4301], no additional compression can be completed, which leaves an overhead of 22 bytes for IPv4 and 20 bytes for IPv4. Protocols like 6LowPAN [I-D.raza-6lowpan-ipsec], ROHC [RFC3095], [RFC5225] can compress the ESP Header up to zero bytes. The ESP Header contains a Security Policy Index (SPI) of 4 bytes and a Sequence Number (SN) of 4 bytes. The SPI may be completely compressed if the UDP decapsulation decompressor is able to derive the SPI from UDP ports. Both SPI and SN are necessary to perform authentication and integrity check. Compression of the ESP Trailer cannot be currently performed. However, ongoing work [I-D.mglt-ipsecme-diet-esp] makes possible the compression of all fields of the ESP Trailer. Migault (Ed) & Bormann Expires January 24, 2015 [Page 6] Internet-Draft IPsec/ESP for Application Payload July 2014 Compression of IV is not currently permitted with IPsec, and this field MUST be included in each IP packet. However, some ongoing work [I-D.mglt-ipsecme-diet-esp-iv-generation]. Finally, compression of the transport header may also be performed using [I-D.mglt-ipsecme-diet-esp-payload-compression]. The advanatge of compressing it over removing it is that compression enables the use of ports as Traffic Selectors without carrying the transport header. Note that this is done under conditions. 6. IANA Considerations There are no IANA consideration for this document. 7. Security Considerations The security considerations of IPsec and Diet-ESP (if used) apply. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. Migault (Ed) & Bormann Expires January 24, 2015 [Page 7] Internet-Draft IPsec/ESP for Application Payload July 2014 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008. 8.2. Informational References [I-D.keoh-dice-multicast-security] Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Rahman, "DTLS-based Multicast Security in Constrained Environments", draft-keoh-dice-multicast-security-08 (work in progress), July 2014. [I-D.mglt-ipsecme-diet-esp] Migault, D. and T. Guggemos, "Diet-ESP: a flexible and compressed format for IPsec/ESP", draft-mglt-ipsecme-diet- esp-01 (work in progress), July 2014. [I-D.mglt-ipsecme-diet-esp-iv-generation] Migault, D. and T. Guggemos, "Diet-ESP: Generating compressed IV and SN", draft-mglt-ipsecme-diet-esp-iv- generation-00 (work in progress), July 2014. [I-D.mglt-ipsecme-diet-esp-payload-compression] Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite", draft-mglt- ipsecme-diet-esp-payload-compression-00 (work in progress), July 2014. [I-D.raza-6lowpan-ipsec] Raza, S., Duquennoy, S., and G. Selander, "Compression of IPsec AH and ESP Headers for Constrained Environments", draft-raza-6lowpan-ipsec-01 (work in progress), September 2013. Authors' Addresses Daniel Migault Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France Phone: +33 1 45 29 60 52 Email: daniel.migault@orange.com Migault (Ed) & Bormann Expires January 24, 2015 [Page 8] Internet-Draft IPsec/ESP for Application Payload July 2014 Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Migault (Ed) & Bormann Expires January 24, 2015 [Page 9]