Network Working Group G. Montenegro Internet Draft Microsoft Corporation Intended status: Standards Track K. Grewal Expires: May 9, 2010 Intel Corporation November 9, 2009 Wrapped ESP Extensions draft-montenegro-ipsecme-wesp-extensions-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 May 09, 2010. Copyright Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Montenegro, et. al. Expires May 9, 2010 [Page 1] Internet-Draft WESP Extensions November 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines the Wrapped ESP (WESP) Extensions capability, which builds on the Wrapped Encapsulating Security Payload [WESP]. The extensions described in this document enable applications like operations and management as well as traffic inspection by intermediate nodes for value added network services such as Intrusion Detection and Prevention (IDS/IPS) on traffic that is encrypted. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 1.2. Applicability Statement...................................3 2. Wrapped ESP (WESP) Header Extensions format....................3 2.1. Operation Administration and Maintenance (OAM) Options....5 2.1.1. Connectivity Verification Option (OAM-CV)............6 2.1.2. Error Notification Option (OAM-EN)...................6 2.1.3. SA Monitoring Option (OAM-SM)........................7 2.2. Pad Option................................................8 2.3. Encryption Offset Option..................................8 3. IKE Considerations.............................................9 4. Security Considerations........................................9 5. IANA Considerations............................................9 6. Acknowledgments...............................................10 7. References....................................................10 7.1. Normative References.....................................10 7.2. Informative References...................................10 1. Introduction This document defines an extension mechanism for Wrapped ESP (WESP) [WESP]. The document is consistent with the operation of ESP in NAT environments [RFC3947]. The design principles for this extension to WESP are: Montenegro, et. al. Expires May 9, 2010 [Page 2] Internet-Draft WESP Extensions November 2009 o Provide an extensible packet format to enable better diagnostics and future innovation in IPsec. o Leverage packet extensions to convey encryption offsets (if used), allowing visibility into packet headers, while still protecting the packet payload and its integrity. 1.1. Requirements Language 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 [RFC2119]. 1.2. Applicability Statement The document is applicable only to wrapped ESP [WESP]. 2. Wrapped ESP (WESP) Header Extensions format Wrapped ESP encapsulation (WESP) follows RFC 4303 [RFC4303] for all IPv6 and IPv4 considerations (e.g., alignment considerations) within ESP, and these considerations apply equally to the WESP Extensions mechanisms defined in this document. The WESP Extension is present if the 'X' (eXtension) flag in the WESP Header Flags field is set. If so, the WESP extension payload is inserted between the WESP Header and the ESP encapsulation. This may be depicted as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WESP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WESP Extension Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 WESP Packet Format with Extensions Further details (including the 'X' bit in the Flags field in the WESP header) are shown below: Montenegro, et. al. Expires May 9, 2010 [Page 3] Internet-Draft WESP Extensions November 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrLen | TrailerLen |V|V|E|P|X|Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Detailed WESP Packet Format with Extensions Where: All fields in the WESP Header are as defined in [WESP], except for the Flags field in which one additional bit is used to signal the use of WESP extensions as follows: Flags, 8 bits: The bits are defined LSB first, so bit 0 is the least significant bit of the flags octet. [WESP] 1 bit: Extensions Present (X). Setting the Extensions Present bit to 1 indicates that WESP Extensions are present between the WESP Header and the ESP Header (as shown above). The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise. 3 bits: Flags, reserved for future use. The flags MUST be sent as 0, and ignored by the receiver. Otherwise, these flags are treated per [WESP]. The fields in the WESP Extension allow the definition of options with the following format: Type, 8 bits: defines the WESP Extension type Length, 8 bits: defines the length of the WESP Extension in octets, excluding the Type and Length fields Montenegro, et. al. Expires May 9, 2010 [Page 4] Internet-Draft WESP Extensions November 2009 Data, variable length: defines the value(s) associated with a given WESP Extension. The length is defined by the Length field above. Furthermore, the Type contains some fixed format bits, following RFC 2460, clause 4.2 to ensure consistency with IPv6 extension header encoding. This will allow simple and consistent hardware- based parsing of the WESP Extensions. [RFC2460] Accordingly, the high order 2 bits specify the following behavior when the option is not recognized. 00 - silently skip the option 01 - silently discard the packet 10 - discard and send ICMP parameter error 11 - discard and send ICMP parameter error if not multicast The next high order bit specifies mutability of the option field. 0 - option data does not change en-route. This option is included in the WESP ICV computation. 1 - option data may change en-route. This option is excluded from the ICV computation. The possibility of using WESP Extensions applies equally to the UDP Encapsulation of WESP. 2.1. Operation Administration and Maintenance (OAM) Options In its most common implementation, IPsec uses different protocols for key negotiation (IKE over UDP port 500/4500) and traffic encapsulation (ESP, UDP-ESP(NAT-T), or AH). Having different control and data channels can make troubleshooting connectivity difficult. The various OAM options enable the monitoring of connectivity within the data channel. OAM options can potentially be generated for every packet. It is up to the implementation to properly keep this traffic within reasonable Montenegro, et. al. Expires May 9, 2010 [Page 5] Internet-Draft WESP Extensions November 2009 bounds, e.g by piggybacking OAM options onto existing packets or throttling the generation of OAM options. 2.1.1. Connectivity Verification Option (OAM-CV) The OAM-CV option allows a sender to test for connectivity to a remote peer over an IPsec SA. OAM-CV is a zero-length option. The OAM-CV option is immutable. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (OAM-CV)| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The recipient of an OAM CV option MUST add the OAM CV option to the first subsequent packet that is small enough to hold it, or generate an empty packet after a timeout. 2.1.2. Error Notification Option (OAM-EN) The OAM-EN option is used to notify communicating peers of an error in the path. The OAM-EN option can be generated by the end host or by an intermediary (e.g. an intermediary dropping a packet because of policy restrictions on the type of traffic that can go through it). An intermediary generating an OAM-EN option SHOULD forward it to both the source and destination of the packet triggering the error. The OAM-EN option is mutable, hence not included in the integrity check for a packet. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (PAD) | Length | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Information (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Type: defines the option type Length: defines the length of the option in octets. Montenegro, et. al. Expires May 9, 2010 [Page 6] Internet-Draft WESP Extensions November 2009 Error Code, 2 octets: A code indicating the nature of the error. Extended Information, variable length: Additional error code specific information. The currently defined error codes are: Error Code Value generated by Extended Information ========== ===== ============ ================== RESERVED 0 N/A N/A NO_SA 1 end node N/A ADMIN_PROHIB 2 end node, IP address (optional) intermediary NOT_PARSED 3 intermediary IP address (optional) Types 4-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. The NO_SA error code SHOULD be sent by an end node in an empty packet when it receives a packet which cannot match the corresponding SA. The ADMIN_PROHIB error code indicates that the packet has been dropped by a firewalling policy. If the end node drops the packet, it SHOULD send back the ADMIN_PROHIB error code with no extended information to the sender. If an intermediary node drops the packet, it SHOULD send the ADMIN_PROHIB error code with its IP address in the extended information to both the sender and the end node. The NOT_PARSED error code indicates that an intermediary was not able to correctly parse the packet and dropped it. This typically happens when an intermediary requires all traffic to be NULL encrypted and receives an encrypted packet. The intermediary SHOULD then send the ADMIN_PROHIB error code with its IP address in the extended information to both the sender and the end node. 2.1.3. SA Monitoring Option (OAM-SM) The OAM-SM option is used to report statistics on the current SA usage. It is patterned after [RFC1989]. The OAM-SM option is immutable. Montenegro, et. al. Expires May 9, 2010 [Page 7] Internet-Draft WESP Extensions November 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (OAM-SM) | Length | Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2. Pad Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (PAD) | Length | PAD Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAD Data (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Type, 8 bits: defines the Pad option identifier (value TBD) Length, 8 bits: defines the length of the pad in octets, excluding the type and length fields. PAD Data, variable: defines the pad value (the exact data used to pad is implementation dependent). The purpose of this option is to allow additional data obfuscation and also used to align the options data on a 4 octet boundary. This option MUST be used if other options are present and do not align the options data on a 4-octet boundary. 2.3. Encryption Offset Option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (EO) | Length | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Montenegro, et. al. Expires May 9, 2010 [Page 8] Internet-Draft WESP Extensions November 2009 Type: Encryption Offset (EO) option identifier (value TBD) Length: 2 octets Offset: Defines the encryption offset in octets. This is the number of octets that are not encrypted (but integrity protected) from the beginning of the payload data. The purpose of this option is to allow additional visibility into the payload data, when a given encryption scheme is used. The exact value of the offset is negotiated via the control channel handshake. This option can be used in scenarios where intermediate devices require visibility into headers of upper layer protocols (TCP/UDP headers), without compromising the confidentiality of the application payload. 3. IKE Considerations This document assumes that WESP Extensions negotiation is performed using IKEv2. In order to negotiate WESP extensions support via IKEv2 [RFC4306], both parties need to agree to support the WESP extensions. This requirement assumes that both parties are already able to negotiate and support WESP. The WESP extensions negotiation can be achieved using a notification method similar to USE_TRANSPORT_MODE defined in RFC 4306. The notification, USE_WESP_EXTENSIONS (value TBD) MAY be included in a request message that also includes an SA payload requesting a CHILD_SA using WESP. It requests that the CHILD_SA use WESP extensions for the SA created. If the request is accepted, the response MUST also include a notification of type USE_WESP_EXTENSIONS. If the responder declines the request, the CHILD_SA will be established without WESP extensions. If this is unacceptable to the initiator, the initiator MUST delete the SA. 4. Security Considerations TBD 5. IANA Considerations This specification requests that IANA assign the 'X' bit for Extensions Present (as shown above) out of the "WESP Flags" field. Montenegro, et. al. Expires May 9, 2010 [Page 9] Internet-Draft WESP Extensions November 2009 This specification requests that IANA create new registries for WESP Extension Type and Error Notification Option Error Codes as follows. To Be Completed. Further assignments of these fields are to be managed via the IANA policy of "Specification Required" [RFC5226]. 6. Acknowledgments The authors thank the following people for their feedback on this document. Philippe Joubert, Brian Swander, Pascal Menezez. This document was prepared using 2-Word-v2.0.template.doc. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [WESP] Grewal, K., Montenegro., G., Bhatia, M., "Wrapped ESP for Traffic Visibility", draft-ietf-ipsecme-traffic- visibility, September 2009. 7.2. Informative References [RFC1989] Simpson, W., "PPP Link Quality Monitoring", RFC 1989, August 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Montenegro, et. al. Expires May 9, 2010 [Page 10] Internet-Draft WESP Extensions November 2009 [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. Author's Addresses Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: Email: gabriel.montenegro@microsoft.com Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Phone: Email: ken.grewal@intel.com Montenegro, et. al. Expires May 9, 2010 [Page 11]