Internet Draft K. Grewal D. Durham M. Long Network Working Group Intel Corporation draft-grewal-ipsec-traffic-visibility-00.txt Intended Status: Standards Expires: June 2008 January 2008 Traffic visibility using IPsec ESP NULL encryption 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. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes leveraging UDP encapsulation for IPsec, using ESP NULL encryption in order for intermediary devices to inspect the IPsec packets. Currently in the IPsec standard, there is no way to Grewal Expires - July 2008 [Page 1] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. Conventions used in this document 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 RFC-2119 [ii]. Table of Contents 1. Introduction...................................................2 1.1 Applicability Statement....................................3 2. UDP Encapsulation of IPsec ESP.................................3 2.1 Extension Header...........................................4 2.2 Tunnel and Transport mode of considerations................5 2.3 Port conflicts.............................................5 3. IANA Considerations............................................6 4. Formal Syntax..................................................6 5. Security Considerations........................................6 6. References.....................................................6 7. Acknowledgements...............................................7 Author's Addresses.............................................7 Full Copyright Statement.......................................8 1. Introduction The RFCs for leveraging ESP within IPsec describes how ESP packet encapsulation is performed. Other RFCs describe how ESP can be leveraged using NULL encryption, while preserving data integrity and authenticity. However, the exact encapsulation employed and the algorithms employed are negotiated out-of-band using the Internet- Key-Exchange (IKE) protocol. Once the packet is formatted and sent on the wire, it is infeasible to distinguish if encryption has been employed or is absent (ESP-NULL) by purely examining the packet. In the case of employing IPsec within the Enterprise environment, it is desirable for intermediate devices (such as load balancers, Intrusion Detection / Prevention Systems (IDS/IPS)) to have access to the data within each packet to preserve existing critical network services. In a mixed mode environment, where some packets containing sensitive data may employ a given encryption cipher suite, while other packets are employing ESP-NULL, the intermediate devices is unable to discern which packets are leveraging ESP-NULL, hence inhibiting further analysis on that packet. This document describes a mechanism leveraging UDP-encapsulation of IPsec ESP packets using a fixed destination port, allowing the intermediate device to differentiate between encrypted data and NULL encrypted data for ESP. grewal Expires - June 2008 [Page 2] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 1.1 Applicability Statement The document is applicable to IPsec ESP only and does not describe any changes to IPsec AH. 2. UDP Encapsulation of IPsec ESP UDP encapsulation of IPsec ESP packets is defined in RFC 3948 and takes the following basic format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP header [RFC2406] | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ According to RFC 3948, the source / destination port values are as the same as used by IKE. We extend this to include a discrete destination port (value TBD) which identifies the UDP/ESP payload as accessible for intermediate devices. The source UDP port must be as used by IKE and does not change from the above specification. Having a reserved, unique destination port to identify the payload as decipherable by intermediate devices provides flexibility in adding an additional, unique header following the UDP header which allows the intermediate device to parse the packet according to additional hints on how the packet has been encoded. This is needed to pass information within each packet on the algorithm employed for the data authenticity and hence any IV requirements for that particular algorithm. As different algorithms may have differing IV requirements, this extension allows the intermediate device to take into account IV (/ICV) for a given algorithm and parse the remaining data pertaining to the upper layer protocol. This extension encoding is a fixed size and encodes information about the specific data authenticity algorithm used for the given packet / SA, the offset to the upper layer protocol and the upper layer protocol value. Diagrammatically, this may be depicted as follows. grewal Expires - June 2008 [Page 3] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next Header | offset |Reserved |Algo Encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP header [RFC2406] | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The attributes in the extension header are described further below. 2.1 Extension Header The extension header is exactly 32-bits, where the first 8-bits are used to convey the upper layer protocol being carried in the ESP payload. The value of this field is copied directly from the Next Header field of the ESP trailer and can be used by the intermediate device to determine / parse the upper layer protocol without having to find and parse the ESP trailer. The second 8-bits are used to convey the offset of the upper layer protocol from the end of this extension header (described further below). The third 8 bits are reserved for future expansion and set to zero. The last 8-bits contain the Algorithm Encoding and carries information about the algorithm being used to compute the ICV. This extension is needed in order for the intermediate device to determine which authentication algorithm is being used for generation of the ESP Integrity Check Value (ICV) and further parse the packet to extract the data portion. The size of the IV and ICV in the IPsec packet is algorithm dependent. In this document, we do not define explicit values for the Algorithm Encoding, but choose to reuse the same values defined in various IPsec RFCs which describe how to negotiate a given algorithm using IKE. In this manner, this specification will be future proofed for any new algorithm definitions. For example, RFC 4302, section 3.3.2 defines specific values for the integrity algorithms, which are used within IKE. These are reserved for IKE via IANA. Additional RFCs defining other (newer) algorithms build upon these definitions and define new values for these algorithms. One example is RFC 4543, which describes usage of AES-GMAC within IPsec and hence defines the values used for different AES key sizes in section 9. The algorithm grewal Expires - June 2008 [Page 4] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 encoding is also useful in determining the size of the ICV for a given algorithm in order to deterministically extract the upper layer payload. The offset is an 8-bit value, which defines the number of octets between the end of this extension header and the start of the upper layer protocol. This includes the ESP header, any additional IP header for tunnel mode and also the size of the IV, which may be algorithm dependent. Having an explicit value for the offset in the packet allows the intermediate device to directly parse past any algorithm dependent structures within the packet and reach the upper layer protocol header. The reserved 8-bits are used to pad this extension to a long word alignment. This should be set to 0 by the sender, but it is not mandatory for the recipient to validate this value. 2.2 Tunnel and Transport mode of considerations This extension is equally applicable for tunnel and transport mode where the ESP Next Header field is used to differentiate between these modes, as per the IPsec specifications. 2.3 Port conflicts Another consideration is that a legacy client may choose the UDP port reserved for this specification as a random source port for a totally different protocol exchange. Although this should not happen if the client is choosing ports from the dynamic range specified by IANA, it is still possible and hence the responsibility rests on the intermediate device to ensure it can differentiate between the two cases. The intermediate device can ensure that it is looking at ESP- NULL traffic that is UDP encapsulated in this form by validating additional data elements following the UDP header. The format of the UDP extension described above can be validated. If this is deemed insufficient, then as a process of extracting the upper layer payload from the ESP encapsulated packet, the ESP trailer needs to be examined (this will be at a fixed place in the packet, proceeding the ICV value) and can be validated according to IPsec ESP trailer construction, which may include some padding octets. Furthermore, the intermediate device can now validate that the upper layer protocol begins after a fixed length following the UDP header (UDP extension + ESP header). Additionally, if the upper layer protocol contains a checksum, the intermediate device can further validate the checksum to ensure that packet construction is as expected. Validating these additional elements reduces the probability of any random payload for a UDP exchange where the source port is the same as this specification from being treated as an ESP encapsulated payload. These checks are not mandatory, but should be performed to cater for grewal Expires - June 2008 [Page 5] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 this exception case. The extent and number of additional the checks performed are protocol dependent. 3. IANA Considerations Reserving an appropriate value for the UDP destination port in order to provide this encapsulation is TBD and can happen after further peer review of this document. 4. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [iii]. There is no new syntax defined by this document. 5. Security Considerations As this document augments the UDP encapsulation definitions specified in RFC 3948, the security observations made in that document also apply here. In addition, as this document promotes intermediate device visibility into IPsec ESP encapsulated frames for the purposes of Network monitoring functions, care should be taken not to send sensitive data over connections using definitions from this document. A strong key agreement protocol, such as IKE, together with a strong policy engine should be used to in determining appropriate security policy for the given traffic streams and data over which it is being employed. 6. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 grewal Expires - June 2008 [Page 6] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC4543] McGrew & Viega, "GMAC in IPsec ESP and AH", RFC 4543, May 2006. [RFC4306] Kaufman, C. "Internet Key Exchange (IKEv2) Protocol ", RFC 4306, December 2005. 7. Acknowledgements Author's Addresses Ken Grewal Intel Corporation 2111 NE 25th Avenue JF3-232 Hillsboro, OR 97124 USA Email: ken.grewal@intel.com David Durham Intel Corporation 2111 NE 25th Avenue JF3-232 Hillsboro, OR 97124 USA Email: david.durham@intel.com grewal Expires - June 2008 [Page 7] Internet-draft Traffic visibility using ESP NULL encryption Dec 2007 Men Long Intel Corporation 2111 NE 25th Avenue JF3-232 Hillsboro, OR 97124 USA Email: men.long@intel.com Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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. grewal Expires - June 2008 [Page 8]