idnits 2.17.1 draft-ietf-ipsec-ikev2-ecnfix-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-04 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft David L. Black 3 Document: draft-ietf-ipsec-ikev2-ecnfix-01.txt EMC Corporation 4 Expires: August 2003 February 2003 6 IKEv2: ECN Requirements for IPsec Tunnels 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 IPsec (IP Security) tunnel encapsulation and decapsulation were 32 specified prior to the addition of ECN (Explicit Congestion 33 Notification) to IP, with the potential result that ECN congestion 34 indications could be discarded by IPsec tunnel decapsulation. The 35 current ECN specification includes two ECN operating modes for 36 IPsec tunnels to avoid this situation, plus IKEv1/ISAKMP (Internet 37 Key Exchange/Internet Security Association and Key Management 38 Protocol) negotiation extensions to enable ECN to be used correctly 39 with IPsec tunnels. To simplify this situation, IKEv2 requires 40 changes to tunnel decapsulation that prevent discarding of ECN 41 congestion indication, obviating the need for these multiple ECN 42 operating modes and their associated negotiation support. 44 Table of Contents 46 1. Introduction..................................................2 47 2. Conventions used in this document.............................2 48 3. The ECN and DS Fields in IP headers...........................3 49 4. ECN vs. IPsec: The Problem....................................3 50 5. IPsec Changes.................................................4 51 6. Security Considerations.......................................5 52 Normative References.............................................5 53 Informative References...........................................6 54 Author's Address.................................................6 56 1. Introduction 58 IPsec tunnel encapsulation and decapsulation were specified 59 [RFC 2401] prior to the addition of ECN (Explicit Congestion 60 Notification) to IP [RFC 3168], with the potential result that ECN 61 congestion indications could be discarded by IPsec tunnel 62 decapsulation. The original ECN specification [RFC 3168] specified 63 two ECN operating modes for IPsec tunnels to avoid this situation, 64 plus IKEv1/ISAKMP negotiation extensions to enable ECN to be used 65 correctly with IPsec tunnels. To simplify this situation, IPsec 66 implementations that support IKEv2 [IKEv2] MUST implement changes 67 to tunnel decapsulation that prevent discarding of ECN congestion 68 indications, obviating the need for these multiple ECN operating 69 modes and their associated negotiation support. 71 This document specifies the required changes to IPsec tunnel 72 decapsulation, and updates both [RFC 2401] (IP Security 73 Architecture) and [RFC 3168] (The Addition of ECN to IP). In turn, 74 this document is intended to be obsoleted by an updated IP Security 75 Architecture RFC (revision to RFC 2401) when time permits. This 76 document is necessary at this time to prevent deployment of IKEv2 77 implementations that discard ECN congestion notifications; such 78 deployment would require perpetuating the two ECN operating modes 79 and the ECN negotiation support for IKEv2. 81 2. Conventions used in this document 83 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 84 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in 85 this document, are to be interpreted as described in [RFC 2119]. 87 The term "router" is used to refer to all IP network nodes involved 88 in the forwarding of IP traffic between its sender and receiver. 90 3. The ECN and DS Fields in IP headers 92 Both the IPv4 TOS byte and the IPv6 traffic class octet are divided 93 into a 6-bit DS (Differentiated Services) Field and a 2-bit ECN 94 field [RFC 2474, RFC 2780, RFC 3168] as follows: 96 0 1 2 3 4 5 6 7 97 +-----+-----+-----+-----+-----+-----+-----+-----+ 98 | DS FIELD, DSCP | ECN FIELD | 99 +-----+-----+-----+-----+-----+-----+-----+-----+ 101 DSCP: differentiated services codepoint 102 ECN: Explicit Congestion Notification 104 Figure 2: The Differentiated Services and ECN Fields in IP. 106 Section 23.1 of [RFC 3168] specifies the ECN field to consist of 107 the two least significant bits of the IPv4 TOS Byte and IPv6 108 Traffic Class Octet and defines the following four values for that 109 field: 111 Bits 6-7, ECN Field: 113 Binary Keyword References 114 ------ ------- ---------- 115 00 Not-ECT (Not ECN-Capable Transport) [RFC 3168] 116 01 ECT(1) (ECN-Capable Transport(1)) [RFC 3168] 117 10 ECT(0) (ECN-Capable Transport(0)) [RFC 3168] 118 11 CE (Congestion Experienced) [RFC 3168] 120 Figure 1: The Values of the ECN Field. 122 The not-ECT codepoint '00' indicates a packet that is not using ECN. 123 The ECN-Capable Transport (ECT) codepoints '10' and '01' are set by 124 the data sender to indicate that the end-points of the transport 125 protocol are ECN-capable; they are called ECT(0) and ECT(1) 126 respectively. The phrase "the ECT codepoint" in this document 127 refers to either of the two ECT codepoints, which are treated 128 equivalently by routers. Senders are free to use either the ECT(0) 129 or the ECT(1) codepoint to indicate ECT, on a packet-by-packet 130 basis. The CE codepoint '11' is set by a router to indicate 131 congestion to the end nodes. Routers that encounter a packet 132 arriving at a full queue drop the packet, just as they do in the 133 absence of ECN. See [RFC 3168] for more ECN information. 135 4. ECN vs. IPsec: The Problem 137 Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 138 TOS byte and IPv6 traffic class octet are to be copied from the 139 inner header to the outer header by the IPsec tunnel encapsulator 140 and that these fields in the outer header are to be discarded (no 141 change to inner header) by the IPsec tunnel decapsulator. If ECN 142 is in use, ECT codepoints will be copied to the outer header, but 143 when a router within the tunnel changes an ECT codepoint to a CE 144 codepoint to indicate congestion, that indication will be discarded 145 by the decapsulator (the inner header's ECT codepoint will be 146 forwarded). This behavior is highly undesirable, and Section 9.2 147 of [RFC 3168] specifies changes to IPsec to avoid it. These 148 changes include two ECN operating modes and negotiation support to 149 detect and cope with IPsec decapsulators that discard ECN 150 congestion indications; use of ECN in the outer IP header of IPsec 151 tunnels is not permitted when such discarding is a possibility. 153 5. IPsec Changes 155 In order to avoid multiple ECN operating modes and negotiation, 156 IPsec tunnel decapsulators for tunnel-mode Security Associations 157 (SAs) created by IKEv2 MUST implement the following modifications 158 to prevent discarding of ECN congestion indications. IKEv2 tunnel- 159 mode SA negotiation is performed by the USE-TRANSPORT-MODE Notify 160 Message (see Section 5.10.1 of [IKEv2]). The following IPsec 161 modifications UPDATE Section 9.2 of [RFC 3168] and Sections 5.1.2.1 162 and 5.1.2.2 of [RFC 2401]. 164 Encapsulation and Decapsulation of packets for a tunnel-mode SA 165 created by IKEv2 MUST NOT follow the modifications specified by 166 Section 9.2 of [RFC 3168] and its subsections. Instead, the 167 following modifications to encapsulation and decapsulation in 168 Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] MUST be performed: 170 Outer Hdr at Inner Hdr at 171 IPv4 Encapsulator Decapsulator 172 Header fields: -------------------- ------------ 173 DS Field copied from inner hdr (5) no change 174 ECN Field copied from inner hdr constructed (7) 175 IPv6 176 Header fields: 177 DS Field copied from inner hdr (6) no change 178 ECN Field copied from inner hdr constructed (7) 180 (5)(6) If the packet will immediately enter a domain for which 181 the DSCP value in the outer header is not appropriate, that 182 value MUST be mapped to an appropriate value for the domain 183 [RFC 2474]. See [RFC 2475] for further information. 185 (7) If the ECN field in the inner header is set to ECT(0) or 186 ECT(1) and the ECN field in the outer header is set to CE, then 187 set the ECN field in the inner header to CE, otherwise make no 188 change to the ECN field in the inner header. 190 (5) and (6) are identical to match the original usage in [RFC 191 2401], where they are different. These actions are not related to 192 ECN, but are part of Differentiated Services support, and are 193 carried over to this document from [RFC 3168] so that all of [RFC 194 3168]'s changes to IPsec can be made inapplicable to SAs created by 195 IKEv2. Section 9.2 of [RFC 3168] continues to apply to IPsec 196 tunnel-mode Security Associations created by IKEv1. 198 6. Security Considerations 200 [RFC 3168] contains an extensive discussion of the security 201 considerations of adding ECN to IP, including considerations 202 specific to IPsec. This document is based on those considerations 203 and makes ECN support for IPsec tunnels MANDATORY as opposed to 204 [RFC 3168]'s treatment of it as a matter of security policy. See 205 [RFC 3168- for a full discussion of ECN security considerations. 207 Normative References 209 [IKEv2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) 210 Protocol", draft-ietf-ipsec-ikev2-04.txt, Work in 211 Progress, January 2003. 213 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC 2401] Kent, S. and R. Atkinson, Security Architecture for 217 the Internet Protocol, RFC 2401, November 1998. 219 [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, 220 "Definition of the Differentiated Services Field (DS 221 Field) in the IPv4 and IPv6 Headers", RFC 2474, 222 December 1998. 224 [RFC 2780] Bradner S. and V. Paxson, "IANA Allocation Guidelines 225 For Values In the Internet Protocol and Related 226 Headers", BCP 37, RFC 2780, March 2000. 228 [RFC 3168] Ramakrishnan, K., Floyd, S. and D. Black, "The 229 Addition of Explicit Congestion Notification (ECN) to 230 IP", RFC 3168, September 2001. 232 Informative References 234 [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, 235 Z. and W. Weiss, "An Architecture for Differentiated 236 Services", RFC 2475, December 1998. 238 Author's Address 240 David L. Black 241 EMC Corporation 242 176 South Street Phone: +1 (508) 293-7953 243 Hopkinton, MA, 01748, USA Email: black_david@emc.com 245 Acknowledgements 247 Significant portions of the text of this document were copied or 248 adapted from text in RFC 3168. The contributions of the authors of 249 RFC 3168 are hereby acknowledged. 251 Full Copyright Notice 253 Copyright (C) The Internet Society (2003). All Rights Reserved. 255 This document and translations of it may be copied and furnished to 256 others, and derivative works that comment on or otherwise explain 257 it or assist in its implementation may be prepared, copied, 258 published and distributed, in whole or in part, without restriction 259 of any kind, provided that the above copyright notice and this 260 paragraph are included on all such copies and derivative works. 261 However, this document itself may not be modified in any way, such 262 as by removing the copyright notice or references to the Internet 263 Society or other Internet organizations, except as needed for the 264 purpose of developing Internet standards in which case the 265 procedures for copyrights defined in the Internet Standards process 266 must be followed, or as required to translate it into languages 267 other than English. 269 The limited permissions granted above are perpetual and will not be 270 revoked by the Internet Society or its successors or assigns. 272 Intellectual Property Rights Notices 274 The IETF takes no position regarding the validity or scope of any 275 intellectual property or other rights that might be claimed to 276 pertain to the implementation or use of the technology described in 277 this document or the extent to which any license under such rights 278 might or might not be available; neither does it represent that it 279 has made any effort to identify any such rights. Information on 280 the IETF's procedures with respect to rights in standards-track and 281 standards-related documentation can be found in BCP-11. Copies of 282 claims of rights made available for publication and any assurances 283 of licenses to be made available, or the result of an attempt made 284 to obtain a general license or permission for the use of such 285 proprietary rights by implementors or users of this specification 286 can be obtained from the IETF Secretariat. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights which may cover technology that may be required to practice 291 this standard. Please address the information to the IETF 292 Executive Director.