Internet Engineering Task Force INTERNET-DRAFT draft-kasera-esvp-00.txt Date: October 28, 2002 S. Kasera, Editor Expires: May 2003 IP Encapsulating Security Variable Payload (ESVP) Status of this memo Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This note describes a new IPsec option called Encapsulating Security Variable Payload (ESVP) that allows a variable but contiguous portion of the payload received from upper protocol layers to be encrypted/authenticated between the two end-points of a security association. The remaining portion of the payload is left in the clear. The upper layer payload contains the upper layer protocol headers and data. The decision about which portions of the payload should be available as cleartext is taken only by the end-points of the security association. By leaving a certain portion of the payload as cleartext, ESVP provides the option of encrypting and decrypting an IPsec ESVP datagram at other protocol layers to allow limited and secure access to the Kasera et al. Expires 05/03 [Page 1] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 cleartext data at these protocol layers. These layers could be terminated inside the network for providing network-based value added services and performance optimizations. These network-based value added services and performance optimizations include policy implementation and QoS based on packet classification, TCP performance enhancement in the case of wireless networks and firewall services. Contents 1 Introduction 2 2 Terminology 3 3 ESVP - Encapsulating Security Variable Payload 3 4 Applications of ESVP 7 4.1 Performance enhancements ................................. 7 4.2 Firewall-based Denial of Service Protection .............. 8 4.3 Enhancing SSL ............................................ 9 4.4 Priority Assignment Based on Transport Protocol .......... 9 5 Comparison of ESVP with Other Approaches 10 6 Security Considerations 11 1 Introduction The current standard for IP level security (IPsec) enforces the encryption/authentication of the entire payload that is received from the upper layers. Such a function ensures the security of the entire payload, including the transport headers and even network layer headers in some cases, between two end-points that have established a security association [1]. Unfortunately, the current IPsec architecture prevents even trusted intermediaries from examining the payload for providing value added services and performance optimizations including packet classification and policy execution, TCP performance enhancements in case of wireless networks, and firewall services. In this document we propose a new IPsec option called Encapsulating Security Variable Payload (ESVP) that allows a variable but contiguous portion of the payload to be encrypted/authenticated between the two end-points of a security association and leaves the remaining portion of the payload in the clear. The decision about which portions of the payload should be Kasera et al. Expires 05/03 [Page 2] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 available as cleartext is taken only by the end-points of the security association. This option allows IPsec to accommodate the tussle between the end-points and the service providers [2], i.e., the service providers want to peek into visible information of the packets for providing value-added services while the end-points decide, based on the benefits they receive, what portion of the information is available to the service providers. While the ESVP security association determines what portion of the payload is cleartext, this does not necessarily mean that the cleartext is exposed to every intermediary. For example, the cleartext in the IP ESVP packet could be potentially encrypted/decrypted by other protocol layers including another IPsec ESP or IPsec ESVP layer. The termination points of these layers are trusted intermediaries that are allowed to examine or in some special cases even modify the cleartext for enabling value added services and performance enhancements. In Section 4, we describe several examples where ESVP is essential and does not expose the negotiated cleartext to anyone other than the trusted intermediaries. It is assumed that ESVP will be used when an end-point (e.g. enterprise VPN gateway) desires to allow a portion of the upper layer payload to be examined (or altered) by only a trusted intermediary (e.g. network service provider node, overlay network node), but protected from any other party. This is done by design and there is a ``trust'' between the endpoint and the intermediary. The end-points have complete control over what is allowed in the cleartext. The end-points also control whether or not the cleartext is authenticated end-to-end. The trust model between the end-points and the intermediary requires that the intermediary would not use the information in cleartext to attack the end-points or play ``end-to-end'' games. Trusting the intermediary does not imply that the end-points do not detect and respond to inappropriate actions of the intermediary. 2 Terminology 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 [3]. 3 ESVP - Encapsulating Security Variable Payload ESVP extends ESP to obtain more flexibility by leaving out certain Kasera et al. Expires 05/03 [Page 3] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 portion of the payload in the clear. The cleartext must be a contiguous block from the head or tail of the payload. An ESVP packet has four additional octets in comparison to an ESP packet. All the fields of the ESVP packet are described below. 0 1 2 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 A=0 ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |A|T| Reserved | Proto | Cleartext Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cleartext (variable) | A ~ ~ A=1 U | | ^ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H | Security Parameter Index (SPI) | | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A N | Sequence Number | ^ U T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T I | Encrypted Payload (variable) | E H C ~ ~ N . A | | C | T + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | E | | Padding (0-255 octets) | . | D +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Pad Length | Next Header | v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (Variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A This is a one bit field, called the A-bit. When the A-bit is set to 0 the cleartext is authenticated end-to-end. Otherwise, the cleartext is not authenticated end-to-end. T This is a one bit field, called the T-bit. It indicates whether the head or tail of the payload is encrypted. When the tail of the payload is encrypted, the T-bit is set to zero to indicate that the cleartext is placed before the SPI field. When the head of the payload is encrypted, the T-bit is set to 1 and the cleartext follows the Authentication Data field. Kasera et al. Expires 05/03 [Page 4] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 Reserved These six bits are reserved for indicating any other properties of the cleartext in the future. Proto This is a one octet field that indicates the next protocol. Cleartext Length This field contains the length in octets of the cleartext. This field is two octets long. Cleartext This is the part of the payload received from the upper layers that is left out in the clear. Security Parameter Index (SPI) As defined in [4], the SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESPV), uniquely identifies the Security Association used in this datagram. Sequence Number As defined in [4], the sequence number is an unsigned 32 bit field containing a monotonically increasing counter value. This field is useful against replay attacks. Encrypted Payload This is a variable length field that contains the payload passed from the upper protocol layers minus the cleartext. As in the case of the Payload Data field of ESP, the Encrypted Payload Data field may also explicitly carry an Initialization Vector (IV) if required by the encryption algorithm. Kasera et al. Expires 05/03 [Page 5] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 Padding Same as the Padding field in ESP. Pad Length Same as the Pad Length field in ESP. Next Header Same as the Next Header field in ESP. Authentication Data The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESVP packet starting from the Security Parameter Index (SPI) field until the end of the datagram minus the Authentication Data. The rules that apply to the Authentication Data field of ESP also apply to this field. ESVP must be supported in both transport and tunnel mode. We now show the ESVP transport mode positioning for a typical IPv4 packet when the TCP header is left in the clear. BEFORE APPLYING ESVP ------------- |IP|TCP|Data| ------------- AFTER APPLYING ESVP --------------------------------------------------------- |IP|A|T| |Proto|Cleartext|TCP|SPI|Seq|Data|ESVP |ESVP| | |0|0| | |Length=20| | | # | |trailer|Auth| --------------------------------------------------------- <--> <--Encrypted-> Reserved <--------------------Authenticated--------------> We now show the ESVP tunnel mode positioning for a typical IPv4 packet when the inner IP and TCP headers are left in the clear. Kasera et al. Expires 05/03 [Page 6] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 BEFORE APPLYING ESVP ------------- |IP|TCP|Data| ------------- AFTER APPLYING ESVP ------------------------------------------------------------ |Outer|A|T| |Proto|Cleartext|IP |SPI|Seq|Data|ESVP |ESVP| | IP |1|0| | |Length=40|TCP| | # | |trailer|Auth| ------------------------------------------------------------ <--> <--Encrypted-> Reserved <----Authenticated---> In both the transport and the tunnel mode the Proto field of the outer IP header should have a new value indicating that the next protocol is ESVP. 4 Applications of ESVP In this section, we present four examples where the flexibility offered by ESVP is essential for providing value-added services. The first exposes protocol headers to the service provider in order to improve performance. The second involves deploying a network-based firewall that prevents denial of service attacks. The third involves enhancing the security of Secure Sockets Layer(SSL). The fourth example demonstrates how a priority policy could be implemented by examining the transport protocol field. 4.1 Performance enhancements We first present a scenario where two end-points are communicating using an IPsec security association but wish to expose the IP/TCP headers to a trusted intermediary. In the figure below, end-point E1 establishes a security association with end-point E2. E1 also establishes a security association with trusted intermediary TI and TI establishes a security association with E2. E1 uses ESVP in tunnel mode to encrypt the TCP data using the security parameters exchanged with E2 but leaves the inner IP and TCP headers in cleartext. The A-bit is set to 1 only if E1 wants TI to change the TCP headers for performance enhancement. Next, E1 sends the resulting ESVP packet over the other ESVP tunnel (terminating at TI) that leaves the encrypted part from the first ESVP operation Kasera et al. Expires 05/03 [Page 7] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 including the encrypted TCP data in the cleartext but encrypts the rest of the first ESVP packet. The T-bit of the outer ESVP packet is set to 1. The second ESVP tunnel ensures that inner IP and TCP headers are not visible to any node in the path between E1 and TI. It also ensures the authenticity of these headers. On receiving the ESVP packet on its tunnel from E1, TI decrypts the outer ESVP packet and hence the IP/TCP header and further sends the inner ESVP packet to E2 through another ESVP tunnel. ESVP Tunnel for TCP data -------------------------------------- -------------------------------------- E1 TI E2 (End-Host) (Trusted Intermediary) (End-Host) ------------------ ------------------ ------------------ ------------------ ESVP Tunnel for ESVP Tunnel for IP/TCP header IP/TCP header This approach of securing payload and headers independently results in a simple and scalable deployment. Consider a specific case where E2 is a VPN gateway, TI is the wireless service provider and E1's are mobile hosts accessing the enterprise Intranet through the gateway, E2. In this case, E1 negotiates with E2 for allowing the TCP/IP headers in the open in the upper tunnel. The lower left ESVP tunnel is not even necessary since the wireless link layer's privacy and message integrity mechanism could be used to secure the headers between the mobile host and the intermediary. In the case of the lower right tunnel, the security association can be established independently of the host to gateway security association and can be common to all the hosts accessing the gateway. This approach is simple and scalable since it preserves the one-to-one nature of security association establishment and requires only one extra security association between TI and E2 for enabling header-based services to all users communicating with E2. 4.2 Firewall-based Denial of Service Protection ESVP could be used to provide firewall-based denial-of-service protection. This is demonstrated in the following example. Kasera et al. Expires 05/03 [Page 8] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 Consider a scenario where an enterprise user is communicating with an enterprise VPN gateway using an IPsec ESP tunnel. Let there be a network based firewall between the enterprise user and the VPN gateway that blocks all the packets toward the user with source address other than that of the enterprise or destination address that is different from the user's destination address. The problem is that a malicious user could spoof the addresses of the VPN gateway and the user and send IPsec packets that would be allowed in by the firewall. The user would eventually drop the IPsec packets it cannot authenticate but before it does that some precious last hop/access network bandwidth and potentially processing resources get wasted. This problem is more severe in the case of mobile users communicating over wireless links. Using ESVP tunnels for encrypting IP/TCP headers between the VPN gateway and the firewall and between the firewall and the user, in addition to an ESVP tunnel between the user and the VPN gateway for protecting data, firewall-based denial-of-service protection could be provided to the enterprise user. Note that an ESP or an AH tunnel could also be used between the VPN gateway and the firewall instead of an ESVP tunnel. The ESVP tunnel saves the overhead of double encryption/authentication. 4.3 Enhancing SSL Using ESVP, we could efficiently secure the IP/TCP headers left in the clear by applications using SSL. This could be done by encrypting the IP/TCP headers and leaving the encrypted TCP payload part in cleartext. ESVP allows the headers to be protected without the overhead of doubly encrypting the TCP payload that is already encrypted by SSL. The ESVP layer could terminate at the SSL server or at a network intermediary (for example, a Virtual Private Network, VPN, gateway), depending on how the security association has been set up. 4.4 Priority Assignment Based on Transport Protocol ESVP allows trusted intermediaries to deploy QoS mechanisms and policy implementations using five-tuple-based (IP source and destination addresses, source and destination port numbers, type of protocol) packet classification even for encrypted Kasera et al. Expires 05/03 [Page 9] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 traffic. For e.g., ESVP could be used to allow a trusted intermediary (possibly a router) to examine what transport protocol is being used by packets between two end-points. The trusted intermediary could assign a lower priority to the ``non-conforming'' UDP traffic and a higher priority to TCP traffic during link congestion. classification techniques for encrypted traffic also. 5 Comparison of ESVP with Other Approaches We now compare the performance of ESVP with two existing extensions to IPsec that allows intermediaries, partial access to the payload. In [5], Bellovin proposed a variant of ESP called Transport-Friendly ESP (TF-ESP) which allowed for leaving out certain portions of the payload in the clear. He also suggested that the cleartext be integrity protected with the rest of the ESP header. The problem with this approach is that when the ESP header is integrity protected with keys known only to end-points, the intermediaries cannot verify if the information is correct. Also, the end-to-end integrity protection does not allow an intermediary to enable those services or performance enhancements that require modification of the cleartext. In ESVP, the A-bit allows the flexibility of deciding whether or not the cleartext should be authenticated end-to-end. The A-bit allows the end-point to selectively grant the trusted intermediary, read-only or read/write access to the cleartext. We propose to address the problem of verification of cleartext (whether authenticated end-to-end or not) at the trusted intermediary by using another ESVP tunnel between the end-point and the trusted intermediary. ESVP also allows the flexibility of having the head or tail of the payload in the clear which prevents double encryption for certain applications e.g., SSL over ESVP mentioned above. Bellovin proposed another variant of ESP called ``Disclosure'' Header where all fields of interest are copied from the payload into an unencrypted portion of the ESP header [5]. Although cleaner, this approach requires pre-defined header formats to be known to the trusted intermediaries and end-points, making it less flexible. The trusted intermediaries also need to be informed about which ``disclosure'' header format is being used. This approach also increases the length of the packet which might be prohibitive for bandwidth limited scenarios. Kasera et al. Expires 05/03 [Page 10] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 In [6, 7], Zhang et al have proposed a very generic approach called Multi-Layer IPsec (ML-IPsec) that divides the payload into multiple zones such that each zone could be encrypted with a different key. Composite security associations involving intermediaries are established and intermediaries with the keys to encrypt/decrypt certain zones are allowed access to those zones. The fine-granular control provided by this approach makes it very complex. Especially, ML-IPsec changes the nature of the security associations from one-to-one to one-to-many. We retain the security association as one-to-one. We believe that ESVP will address most of the needs of offering network based services and performance enhancements without the complexity of ML-IPsec. It is possible to provide a simpler version of ML-IPsec with ESVP by encrypting/authenticating the cleartext with keys exchanged with the intermediaries and indicating this in the flags field of the ESVP header. Further discussion on this issue is beyond the scope of this document. 6 Security Considerations ESVP relies on ESP for handling the encrypted portion of the payload. Furthermore, it relies on IKE for setting up and managing the keys required to perform encryption and authentication. Therefore, the security properties of ESVP with respect to the encrypted portion of the payload should derive directly from the properties of IKE and ESP. Conversely, the security properties of the portion of the packets that ESVP leaves unencrypted (the cleartext) derive from the properties of the additional mechanism used to secure that portion of the packets. For example, in case ESVP is used to secure the unencrypted portion of the packets between the end points and a trusted intermediary, as with the IP/TCP headers in the case of the example of Section 4.1, the security properties of ESP will also apply to the IP/TCP headers, albeit allowing a trusted intermediary to have access to them. In this case, no end-to-end security property applies to the unencrypted portion of the packets, since the handling of such portion of the payload is left to security associations which are not end-to-end. However, it must be noted that with ESVP the end points have complete control over which portion of the packets, if at all, is not encrypted or authenticated. Therefore security policies can be implemented by system administrators who can decide, even on a Kasera et al. Expires 05/03 [Page 11] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 per-packet basis, to what extent of the packets ESVP should be applied, depending on the trust relationship that they have established with their service providers, as well as on the additional security mechanisms that are available to protect the unencrypted portions of the packets. Acknowledgments We would like to thank Milind Buddhikot, Juan Garay, Semyon Mizikovsky and Sanjoy Paul from Lucent Technologies for useful discussions on this topic and comments on this draft. References [1] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC 2401, IETF, November 1998. [2] D. Clark, J. Wroclawski, K. Sollins, and Robert Braden. Tussle in cyberspace: Defining tomorrow's internet. In Proc. ACM SICOMM Conference, Aug. 2002. [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [4] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, IETF, November 1998. [5] S. Bellovin. Transport-friendly esp (or layer violation for fun and profit). IETF-44 TF-ESP BOF, Mar. 1999. [6] Y. Zhang. Multi-Layer Protection Scheme for IPSEC. Work in progress - Internet Draft, IETF, May 1999. draft-zhang-ipsec-mlipsec-00.txt. [7] Y. Zhang and B. Singh. A multi-layer ipsec protocol. In Proc. 9th Usenix Security Symposium, Aug. 2000. Authors' Addresses Sneha Kasera, Ramachandran Ramjee, Luca Salgarelli, Scott Miller, Ganesh Sundaram, Eric Grosse Bell Laboratories - Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733, USA Voice: +1-732-949-1660 Fax: +1-732-949-7397 E-mail: {kasera,ramjee,salga,scm,ganeshs,ehg}@lucent.com Kasera et al. Expires 05/03 [Page 12] INTERNET-DRAFT draft-kasera-esvp-00.txt 10/02 Full Copyright Statement "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Kasera et al. Expires 05/03 [Page 13]