Internet Draft David L. Black Document: draft-ietf-ipsec-ikev2-ecnfix-01.txt EMC Corporation Expires: August 2003 February 2003 IKEv2: ECN Requirements for IPsec Tunnels Status of this Memo 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 IPsec (IP Security) tunnel encapsulation and decapsulation were specified prior to the addition of ECN (Explicit Congestion Notification) to IP, with the potential result that ECN congestion indications could be discarded by IPsec tunnel decapsulation. The current ECN specification includes two ECN operating modes for IPsec tunnels to avoid this situation, plus IKEv1/ISAKMP (Internet Key Exchange/Internet Security Association and Key Management Protocol) negotiation extensions to enable ECN to be used correctly with IPsec tunnels. To simplify this situation, IKEv2 requires changes to tunnel decapsulation that prevent discarding of ECN congestion indication, obviating the need for these multiple ECN operating modes and their associated negotiation support. Black Expires - August 2003 [Page 1] IKEv2: ECN Requirements for IPsec Tunnels February 2003 Table of Contents 1. Introduction..................................................2 2. Conventions used in this document.............................2 3. The ECN and DS Fields in IP headers...........................3 4. ECN vs. IPsec: The Problem....................................3 5. IPsec Changes.................................................4 6. Security Considerations.......................................5 Normative References.............................................5 Informative References...........................................6 Author's Address.................................................6 1. Introduction IPsec tunnel encapsulation and decapsulation were specified [RFC 2401] prior to the addition of ECN (Explicit Congestion Notification) to IP [RFC 3168], with the potential result that ECN congestion indications could be discarded by IPsec tunnel decapsulation. The original ECN specification [RFC 3168] specified two ECN operating modes for IPsec tunnels to avoid this situation, plus IKEv1/ISAKMP negotiation extensions to enable ECN to be used correctly with IPsec tunnels. To simplify this situation, IPsec implementations that support IKEv2 [IKEv2] MUST implement changes to tunnel decapsulation that prevent discarding of ECN congestion indications, obviating the need for these multiple ECN operating modes and their associated negotiation support. This document specifies the required changes to IPsec tunnel decapsulation, and updates both [RFC 2401] (IP Security Architecture) and [RFC 3168] (The Addition of ECN to IP). In turn, this document is intended to be obsoleted by an updated IP Security Architecture RFC (revision to RFC 2401) when time permits. This document is necessary at this time to prevent deployment of IKEv2 implementations that discard ECN congestion notifications; such deployment would require perpetuating the two ECN operating modes and the ECN negotiation support for IKEv2. 2. Conventions used in this document The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC 2119]. The term "router" is used to refer to all IP network nodes involved in the forwarding of IP traffic between its sender and receiver. Black Expires - July 2003 [Page 2] IKEv2: ECN Requirements for IPsec Tunnels February 2003 3. The ECN and DS Fields in IP headers Both the IPv4 TOS byte and the IPv6 traffic class octet are divided into a 6-bit DS (Differentiated Services) Field and a 2-bit ECN field [RFC 2474, RFC 2780, RFC 3168] as follows: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ DSCP: differentiated services codepoint ECN: Explicit Congestion Notification Figure 2: The Differentiated Services and ECN Fields in IP. Section 23.1 of [RFC 3168] specifies the ECN field to consist of the two least significant bits of the IPv4 TOS Byte and IPv6 Traffic Class Octet and defines the following four values for that field: Bits 6-7, ECN Field: Binary Keyword References ------ ------- ---------- 00 Not-ECT (Not ECN-Capable Transport) [RFC 3168] 01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168] 10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168] 11 CE (Congestion Experienced) [RFC 3168] Figure 1: The Values of the ECN Field. The not-ECT codepoint '00' indicates a packet that is not using ECN. The ECN-Capable Transport (ECT) codepoints '10' and '01' are set by the data sender to indicate that the end-points of the transport protocol are ECN-capable; they are called ECT(0) and ECT(1) respectively. The phrase "the ECT codepoint" in this document refers to either of the two ECT codepoints, which are treated equivalently by routers. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis. The CE codepoint '11' is set by a router to indicate congestion to the end nodes. Routers that encounter a packet arriving at a full queue drop the packet, just as they do in the absence of ECN. See [RFC 3168] for more ECN information. 4. ECN vs. IPsec: The Problem Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS byte and IPv6 traffic class octet are to be copied from the Black Expires - July 2003 [Page 3] IKEv2: ECN Requirements for IPsec Tunnels February 2003 inner header to the outer header by the IPsec tunnel encapsulator and that these fields in the outer header are to be discarded (no change to inner header) by the IPsec tunnel decapsulator. If ECN is in use, ECT codepoints will be copied to the outer header, but when a router within the tunnel changes an ECT codepoint to a CE codepoint to indicate congestion, that indication will be discarded by the decapsulator (the inner header's ECT codepoint will be forwarded). This behavior is highly undesirable, and Section 9.2 of [RFC 3168] specifies changes to IPsec to avoid it. These changes include two ECN operating modes and negotiation support to detect and cope with IPsec decapsulators that discard ECN congestion indications; use of ECN in the outer IP header of IPsec tunnels is not permitted when such discarding is a possibility. 5. IPsec Changes In order to avoid multiple ECN operating modes and negotiation, IPsec tunnel decapsulators for tunnel-mode Security Associations (SAs) created by IKEv2 MUST implement the following modifications to prevent discarding of ECN congestion indications. IKEv2 tunnel- mode SA negotiation is performed by the USE-TRANSPORT-MODE Notify Message (see Section 5.10.1 of [IKEv2]). The following IPsec modifications UPDATE Section 9.2 of [RFC 3168] and Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401]. Encapsulation and Decapsulation of packets for a tunnel-mode SA created by IKEv2 MUST NOT follow the modifications specified by Section 9.2 of [RFC 3168] and its subsections. Instead, the following modifications to encapsulation and decapsulation in Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] MUST be performed: Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ DS Field copied from inner hdr (5) no change ECN Field copied from inner hdr constructed (7) IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field copied from inner hdr constructed (7) (5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. See [RFC 2475] for further information. (7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then Black Expires - July 2003 [Page 4] IKEv2: ECN Requirements for IPsec Tunnels February 2003 set the ECN field in the inner header to CE, otherwise make no change to the ECN field in the inner header. (5) and (6) are identical to match the original usage in [RFC 2401], where they are different. These actions are not related to ECN, but are part of Differentiated Services support, and are carried over to this document from [RFC 3168] so that all of [RFC 3168]'s changes to IPsec can be made inapplicable to SAs created by IKEv2. Section 9.2 of [RFC 3168] continues to apply to IPsec tunnel-mode Security Associations created by IKEv1. 6. Security Considerations [RFC 3168] contains an extensive discussion of the security considerations of adding ECN to IP, including considerations specific to IPsec. This document is based on those considerations and makes ECN support for IPsec tunnels MANDATORY as opposed to [RFC 3168]'s treatment of it as a matter of security policy. See [RFC 3168- for a full discussion of ECN security considerations. Normative References [IKEv2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-04.txt, Work in Progress, January 2003. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2401] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998. [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC 2780] Bradner S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC 3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. Black Expires - July 2003 [Page 5] IKEv2: ECN Requirements for IPsec Tunnels February 2003 Informative References [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Author's Address David L. Black EMC Corporation 176 South Street Phone: +1 (508) 293-7953 Hopkinton, MA, 01748, USA Email: black_david@emc.com Acknowledgements Significant portions of the text of this document were copied or adapted from text in RFC 3168. The contributions of the authors of RFC 3168 are hereby acknowledged. Full Copyright Notice Copyright (C) The Internet Society (2003). 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. Intellectual Property Rights Notices The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and Black Expires - July 2003 [Page 6] IKEv2: ECN Requirements for IPsec Tunnels February 2003 standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Black Expires - July 2003 [Page 7]