idnits 2.17.1 draft-eronen-ipsec-ikev2-clarifications-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2660. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- == There are 21 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 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 2, 2006) is 6658 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) == Missing Reference: 'KEi' is mentioned on line 2606, but not defined == Missing Reference: 'KEr' is mentioned on line 2608, but not defined -- Looks like a reference, but probably isn't: '1' on line 928 == Missing Reference: 'IDr' is mentioned on line 2559, but not defined ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (ref. 'IKEv2ALG') (Obsoleted by RFC 8247) ** Obsolete normative reference: RFC 2437 (ref. 'PKCS1v20') (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1v21') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-06) exists of draft-hoffman-ike-ipsec-hash-use-01 -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. 'IPv6Addr') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4282 (ref. 'NAI') (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3664 (Obsoleted by RFC 4434) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) == Outdated reference: A later version (-05) exists of draft-nir-ikev2-auth-lt-03 == Outdated reference: A later version (-33) exists of draft-ietf-pkix-scvp-21 Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Expires: August 6, 2006 P. Hoffman 5 VPN Consortium 6 February 2, 2006 8 IKEv2 Clarifications and Implementation Guidelines 9 draft-eronen-ipsec-ikev2-clarifications-07.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document clarifies many areas of the IKEv2 specification. It 43 does not to introduce any changes to the protocol, but rather 44 provides descriptions that are less prone to ambiguous 45 interpretations. The purpose of this document is to encourage the 46 development of interoperable implementations. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Creating the IKE_SA . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. SPI values in IKE_SA_INIT exchange . . . . . . . . . . . . 4 53 2.2. Message IDs for IKE_SA_INIT messages . . . . . . . . . . . 5 54 2.3. Retransmissions of IKE_SA_INIT requests . . . . . . . . . 5 55 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . . . . 6 56 2.5. Invalid cookies . . . . . . . . . . . . . . . . . . . . . 8 57 3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1. Data included in AUTH payload calculation . . . . . . . . 8 59 3.2. Hash function for RSA signatures . . . . . . . . . . . . . 9 60 3.3. Encoding method for RSA signatures . . . . . . . . . . . . 10 61 3.4. Identification type for EAP . . . . . . . . . . . . . . . 10 62 3.5. Identity for policy lookups when using EAP . . . . . . . . 11 63 3.6. (Section removed) . . . . . . . . . . . . . . . . . . . . 11 64 3.7. Certificate encoding types . . . . . . . . . . . . . . . . 11 65 3.8. Shared key authentication and fixed PRF key size . . . . . 12 66 3.9. EAP authentication and fixed PRF key size . . . . . . . . 13 67 3.10. Matching ID payloads to certificate contents . . . . . . . 13 68 3.11. Message IDs for IKE_AUTH messages . . . . . . . . . . . . 13 69 4. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . 13 70 4.1. Creating SAs with the CREATE_CHILD_SA exchange . . . . . . 14 71 4.2. Creating an IKE_SA without a CHILD_SA . . . . . . . . . . 16 72 4.3. Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 16 73 4.4. Extended Sequence Numbers (ESN) transform . . . . . . . . 16 74 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . . . . 17 75 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO . . . . . . . . . 17 76 4.7. Semantics of complex traffic selector payloads . . . . . . 18 77 4.8. ICMP type/code in traffic selector payloads . . . . . . . 18 78 4.9. Mobility header in traffic selector payloads . . . . . . . 19 79 4.10. Narrowing the traffic selectors . . . . . . . . . . . . . 20 80 4.11. SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . . 20 81 4.12. Traffic selectors violating own policy . . . . . . . . . . 21 82 5. Rekeying and deleting SAs . . . . . . . . . . . . . . . . . . 21 83 5.1. Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 21 84 5.2. Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 23 85 5.3. SPIs when rekeying the IKE_SA . . . . . . . . . . . . . . 23 86 5.4. SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 24 87 5.5. Changing PRFs when rekeying the IKE_SA . . . . . . . . . . 24 88 5.6. Deleting vs. closing SAs . . . . . . . . . . . . . . . . . 24 89 5.7. Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 25 90 5.8. Deleting an IKE_SA . . . . . . . . . . . . . . . . . . . . 25 91 5.9. Who is the original initiator of IKE_SA . . . . . . . . . 25 92 5.10. (Section removed) . . . . . . . . . . . . . . . . . . . . 25 93 5.11. Comparing nonces . . . . . . . . . . . . . . . . . . . . . 26 94 5.12. Exchange collisions . . . . . . . . . . . . . . . . . . . 26 95 5.13. Diffie-Hellman and rekeying the IKE_SA . . . . . . . . . . 34 97 6. Configuration payloads . . . . . . . . . . . . . . . . . . . . 35 98 6.1. Assigning IP addresses . . . . . . . . . . . . . . . . . . 35 99 6.2. (Section removed) . . . . . . . . . . . . . . . . . . . . 36 100 6.3. Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 36 101 6.4. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 36 102 6.5. INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 39 103 6.6. Configuration payloads for IPv6 . . . . . . . . . . . . . 40 104 6.7. INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 42 105 6.8. INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . . . . 42 106 6.9. Address assignment failures . . . . . . . . . . . . . . . 42 107 7. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . . 43 108 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 43 109 7.2. Relationship of IKEv2 to RFC4301 . . . . . . . . . . . . . 43 110 7.3. Reducing the window size . . . . . . . . . . . . . . . . . 44 111 7.4. Minimum size of nonces . . . . . . . . . . . . . . . . . . 44 112 7.5. Initial zero octets on port 4500 . . . . . . . . . . . . . 44 113 7.6. Destination port for NAT traversal . . . . . . . . . . . . 45 114 7.7. SPI values for messages outside of an IKE_SA . . . . . . . 45 115 7.8. Protocol ID/SPI fields in Notify payloads . . . . . . . . 46 116 7.9. Which message should contain INITIAL_CONTACT . . . . . . . 46 117 7.10. Alignment of payloads . . . . . . . . . . . . . . . . . . 46 118 7.11. Key length transform attribute . . . . . . . . . . . . . . 47 119 7.12. IPsec IANA considerations . . . . . . . . . . . . . . . . 47 120 7.13. Combining ESP and AH . . . . . . . . . . . . . . . . . . . 48 121 8. Status of the clarifications . . . . . . . . . . . . . . . . . 48 122 9. Implementation mistakes . . . . . . . . . . . . . . . . . . . 50 123 10. Security considerations . . . . . . . . . . . . . . . . . . . 51 124 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 51 125 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 126 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 127 13.1. Normative References . . . . . . . . . . . . . . . . . . . 51 128 13.2. Informative References . . . . . . . . . . . . . . . . . . 52 129 Appendix A. Exchanges and payloads . . . . . . . . . . . . . . . 53 130 A.1. IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 54 131 A.2. IKE_AUTH exchange without EAP . . . . . . . . . . . . . . 54 132 A.3. IKE_AUTH exchange with EAP . . . . . . . . . . . . . . . . 55 133 A.4. CREATE_CHILD_SA exchange for creating/rekeying 134 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 56 135 A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA . . . . . 56 136 A.6. INFORMATIONAL exchange . . . . . . . . . . . . . . . . . . 56 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 138 Intellectual Property and Copyright Statements . . . . . . . . . . 58 140 1. Introduction 142 This document clarifies many areas of the IKEv2 specification that 143 may be difficult to understand to developers not intimately familiar 144 with the specification and its history. The clarifications in this 145 document come from the discussion on the IPsec WG mailing list, from 146 experience in interoperability testing, and from implementation 147 issues that have been brought to the editors' attention. 149 Readers are advised that this document is work-in-progress, and may 150 contain incorrect interpretations. Issues where the clarification is 151 known to be incomplete, or there is no consensus on what the the 152 interpretation should be, are marked as such. 154 IKEv2/IPsec can be used for several different purposes, including 155 IPsec-based remote access (sometimes called the "road warrior" case), 156 site-to-site virtual private networks (VPNs), and host-to-host 157 protection of application traffic. While this document attempts to 158 consider all of these uses, the remote access scenario has perhaps 159 received more attention here than the other uses. 161 This document does not place any requirements on anyone, and does not 162 use [RFC2119] keywords such as "MUST" and "SHOULD", except in 163 quotations from the original IKEv2 documents. The requirements are 164 given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic 165 algorithms document [IKEv2ALG]. 167 In this document, references to a numbered section (such as "Section 168 2.15") mean that section in [IKEv2]. References to mailing list 169 messages refer to the IPsec WG mailing list at ipsec@ietf.org. 170 Archives of the mailing list can be found at 171 . 173 2. Creating the IKE_SA 175 2.1. SPI values in IKE_SA_INIT exchange 177 Normal IKE messages include the initiator's and responder's SPIs, 178 both of which are non-zero, in the IKE header. However, there are 179 some corner cases where the IKEv2 specification is not fully 180 consistent about what values should be used. 182 First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero 183 in any other message" (than the first message of the IKE_SA_INIT 184 exchange). However, the figure in Section 2.6 shows the second 185 IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text 186 in 3.1. 188 Since the responder's SPI identifies security-related state held by 189 the responder, and in this case no state is created, sending a zero 190 value seems reasonable. 192 Second, in addition to cookies, there are several other cases when 193 the IKE_SA_INIT exchange does not result in the creation of an IKE_SA 194 (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What 195 responder SPI value should be used in the IKE_SA_INIT response in 196 this case? 198 Since the IKE_SA_INIT request always has a zero responder SPI, the 199 value will not be actually used by the initiator. Thus, we think 200 sending a zero value is correct also in this case. 202 If the responder sends a non-zero responder SPI, the initiator should 203 not reject the response only for that reason. However, when retrying 204 the IKE_SA_INIT request, the initiator will use a zero responder SPI, 205 as described in Section 3.1: "Responder's SPI [...] This value MUST 206 be zero in the first message of an IKE Initial Exchange (including 207 repeats of that message including a cookie) [...]". We believe the 208 intent was to cover repeats of that message due to other reasons, 209 such as INVALID_KE_PAYLOAD, as well. 211 (References: "INVALID_KE_PAYLOAD and clarifications document" thread, 212 Sep-Oct 2005.) 214 2.2. Message IDs for IKE_SA_INIT messages 216 The Message ID for IKE_SA_INIT messages is always zero. This 217 includes retries of the message due to responses such as COOKIE and 218 INVALID_KE_PAYLOAD. 220 This is because Message IDs are part of the IKE_SA state, and when 221 the responder replies to IKE_SA_INIT request with N(COOKIE) or 222 N(INVALID_KE_PAYLOAD), the responder does not allocate any state. 224 (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) 225 combination" thread, Oct 2004. Tero Kivinen's mail "Comments of 226 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.) 228 2.3. Retransmissions of IKE_SA_INIT requests 230 When a responder receives an IKE_SA_INIT request, it has to determine 231 whether the packet is a retransmission belonging to an existing 232 "half-open" IKE_SA (in which case the responder retransmits the same 233 response), or a new request (in which case the responder creates a 234 new IKE_SA and sends a fresh response). 236 The specification does not describe in detail how this determination 237 is done. In particular, it is not sufficient to use the initiator's 238 SPI and/or IP address for this purpose: two different peers behind a 239 single NAT could choose the same initiator SPI (and the probability 240 of this happening is not necessarily small, since IKEv2 does not 241 require SPIs to be chosen randomly). Instead, the responder should 242 do the IKE_SA lookup using the whole packet or its hash (or at the 243 minimum, the Ni payload which is always chosen randomly). 245 For all other packets than IKE_SA_INIT requests, looking up right 246 IKE_SA is of course done based on the the recipient's SPI (either the 247 initiator or responder SPI depending on the value of the Initiator 248 bit in the IKE header). 250 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD 252 There are two common reasons why the initiator may have to retry the 253 IKE_SA_INIT exchange: the responder requests a cookie or wants a 254 different Diffie-Hellman group than was included in the KEi payload. 255 Both of these cases are quite simple alone, but it is not totally 256 obvious what happens when they occur at the same time, that is, the 257 IKE_SA_INIT exchange is retried several times. 259 The main question seems to be the following: if the initiator 260 receives a cookie from the responder, should it include the cookie in 261 only the next retry of the IKE_SA_INIT request, or in all subsequent 262 retries as well? Section 3.10.1 says that: 264 "This notification MUST be included in an IKE_SA_INIT request 265 retry if a COOKIE notification was included in the initial 266 response." 268 This could be interpreted as saying that when a cookie is received in 269 the initial response, it is included in all retries. On the other 270 hand, Section 2.6 says that: 272 "Initiators who receive such responses MUST retry the 273 IKE_SA_INIT with a Notify payload of type COOKIE containing 274 the responder supplied cookie data as the first payload and 275 all other payloads unchanged." 277 Including the same cookie in later retries makes sense only if the 278 "all other payloads unchanged" restriction applies only to the first 279 retry, but not to subsequent retries. 281 It seems that both interpretations can peacefully co-exist. If the 282 initiator includes the cookie only in the next retry, one additional 283 roundtrip may be needed in some cases: 285 Initiator Responder 286 ----------- ----------- 287 HDR(A,0), SAi1, KEi, Ni --> 288 <-- HDR(A,0), N(COOKIE) 289 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 290 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 291 HDR(A,0), SAi1, KEi', Ni --> 292 <-- HDR(A,0), N(COOKIE') 293 HDR(A,0), N(COOKIE'), SAi1, KEi',Ni --> 294 <-- HDR(A,B), SAr1, KEr, Nr 296 An additional roundtrip is needed also if the initiator includes the 297 cookie in all retries, but the responder does not support this. For 298 instance, if the responder includes the SAi1 and KEi payloads in 299 cookie calculation, it will reject the request by sending a new 300 cookie (see also Section 2.5 of this document for more text about 301 invalid cookies): 303 Initiator Responder 304 ----------- ----------- 305 HDR(A,0), SAi1, KEi, Ni --> 306 <-- HDR(A,0), N(COOKIE) 307 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 308 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 309 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 310 <-- HDR(A,0), N(COOKIE') 311 HDR(A,0), N(COOKIE'), SAi1, KEi',Ni --> 312 <-- HDR(A,B), SAr1, KEr, Nr 314 If both peers support including the cookie in all retries, a slightly 315 shorter exchange can happen: 317 Initiator Responder 318 ----------- ----------- 319 HDR(A,0), SAi1, KEi, Ni --> 320 <-- HDR(A,0), N(COOKIE) 321 HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> 322 <-- HDR(A,0), N(INVALID_KE_PAYLOAD) 323 HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> 324 <-- HDR(A,B), SAr1, KEr, Nr 326 This document recommends that implementations should support this 327 shorter exchange, but it must not be assumed the other peer also 328 supports this. 330 In theory, even this exchange has one unnecessary roundtrip, as both 331 the cookie and Diffie-Hellman group could be checked at the same 332 time: 334 Initiator Responder 335 ----------- ----------- 336 HDR(A,0), SAi1, KEi, Ni --> 337 <-- HDR(A,0), N(COOKIE), 338 N(INVALID_KE_PAYLOAD) 339 HDR(A,0), N(COOKIE), SAi1, KEi',Ni --> 340 <-- HDR(A,B), SAr1, KEr, Nr 342 However, it is clear that this case is not allowed by the text in 343 Section 2.6, since "all other payloads" clearly includes the KEi 344 payload as well. 346 (References: "INVALID_KE_PAYLOAD and clarifications document" thread, 347 Sep-Oct 2005.) 349 2.5. Invalid cookies 351 There has been some confusion what should be done when an IKE_SA_INIT 352 request containing an invalid cookie is received ("invalid" in the 353 sense that its contents do not match the value expected by the 354 responder). 356 The correct action is to ignore the cookie, and process the message 357 as if no cookie had been included (usually this means sending a 358 response containing a new cookie). This is shown in Section 2.6 when 359 it says "The responder in that case MAY reject the message by sending 360 another response with a new cookie [...]". 362 Other possible actions, such as ignoring the whole request (or even 363 all requests from this IP address for some time), create strange 364 failure modes even in the absence of any malicious attackers, and do 365 not provide any additional protection against DoS attacks. 367 (References: "Invalid Cookie" thread, Sep-Oct 2005.) 369 3. Authentication 371 3.1. Data included in AUTH payload calculation 373 Section 2.15 describes how the AUTH payloads are calculated; this 374 calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The 375 text describes the method in words, but does not give clear 376 definitions of what is signed or MACed. 378 The initiator's signed octets can be described as: 380 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI 381 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 382 RealIKEHDR = SPIi | SPIr | . . . | Length 383 RealMessage1 = RealIKEHDR | RestOfMessage1 384 NonceRPayload = PayloadHeader | NonceRData 385 InitiatorIDPayload = PayloadHeader | RestOfIDPayload 386 RestOfInitIDPayload = IDType | RESERVED | InitIDData 387 MACedIDForI = prf(SK_pi, RestOfInitIDPayload) 389 The responder's signed octets can be described as: 391 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR 392 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR 393 RealIKEHDR = SPIi | SPIr | . . . | Length 394 RealMessage2 = RealIKEHDR | RestOfMessage2 395 NonceIPayload = PayloadHeader | NonceIData 396 ResponderIDPayload = PayloadHeader | RestOfIDPayload 397 RestOfRespIDPayload = IDType | RESERVED | InitIDData 398 MACedIDForR = prf(SK_pr, RestOfRespIDPayload) 400 3.2. Hash function for RSA signatures 402 Section 3.8 says that RSA digital signature is "Computed as specified 403 in section 2.15 using an RSA private key over a PKCS#1 padded hash." 405 Unlike IKEv1, IKEv2 does not negotiate a hash function for the 406 IKE_SA. The algorithm for signatures is selected by the signing 407 party who, in general, may not know beforehand what algorithms the 408 verifying party supports. Furthermore, [IKEv2ALG] does not say what 409 algorithms implementations are required or recommended to support. 410 This clearly has a potential for causing interoperability problems, 411 since authentication will fail if the signing party selects an 412 algorithm that is not supported by the verifying party, or not 413 acceptable according to the verifying party's policy. 415 This document recommends that all implementations support SHA-1, and 416 use SHA-1 as the default hash function when generating the 417 signatures, unless there are good reasons (such as explicit manual 418 configuration) to believe that the other end supports something else. 420 Note that hash function collision attacks are not important for the 421 AUTH payloads, since they are not intended for third-party 422 verification, and the data includes fresh nonces. See [HashUse] for 423 more discussion about hash function attacks and IPsec. 425 Another semi-reasonable choice would be to use the hash function that 426 was used by the CA when signing the peer certificate. However, this 427 does not guarantee that the IKEv2 peer would be able to validate the 428 AUTH payload, since it does not necessarily check the certificate 429 signature. The peer could be configured with a fingerprint of the 430 certificate, or certificate validation could be performed by an 431 external entity using [SCVP]. Furthermore, not all CERT payloads 432 types include a signature, and the certificate could be signed with 433 some other algorithm than RSA. 435 Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] 436 signature encoding method (see next section for details), which 437 includes the algorithm identifier for the hash algorithm. Thus, when 438 the verifying party receives the AUTH payload it can at least 439 determine which hash function was used. 441 (References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's 442 reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft 443 of IKEv2.1" thread, Dec 2005/Jan 2006.) 445 3.3. Encoding method for RSA signatures 447 Section 3.8 says that the RSA digital signature is "Computed as 448 specified in section 2.15 using an RSA private key over a PKCS#1 449 padded hash." 451 The PKCS#1 specification [PKCS1v21] defines two different encoding 452 methods (ways of "padding the hash") for signatures. However, the 453 Internet-Draft approved by the IESG had a reference to the older 454 PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method 455 for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity. 457 Note that this encoding method is different from the encoding method 458 used in IKEv1. If future revisions of IKEv2 provide support for 459 other encoding methods (such as EMSA-PSS), they will be given new 460 Auth Method numbers. 462 (References: Pasi Eronen's mail "RE:", 2005-01-04.) 464 3.4. Identification type for EAP 466 Section 3.5 defines several different types for identification 467 payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID. 468 EAP [EAP] does not mandate the use of any particular type of 469 identifier, but often EAP is used with Network Access Identifiers 470 (NAIs) defined in [NAI]. Although NAIs look a bit like email 471 addresses (e.g., "joe@example.com"), the syntax is not exactly the 472 same as the syntax of email address in [RFC822]. This raises the 473 question of which identification type should be used. 475 This document recommends that ID_RFC822_ADDR identification type is 476 used for those NAIs that include the realm component. Therefore, 477 responder implementations should not attempt to verify that the 478 contents actually conform to the exact syntax given in [RFC822] or 479 [RFC2822], but instead should accept any reasonable looking NAI. 481 For NAIs that do not include the realm component, this document 482 recommends using the ID_KEY_ID identification type. 484 (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2 485 identifier issue with EAP" threads, Aug 2004.) 487 3.5. Identity for policy lookups when using EAP 489 When the initiator authentication uses EAP, it is possible that the 490 contents of the IDi payload is used only for AAA routing purposes and 491 selecting which EAP method to use. This value may be different from 492 the identity authenticated by the EAP method (see [EAP], Sections 5.1 493 and 7.3). 495 It is important that policy lookups and access control decisions use 496 the actual authenticated identity. Often the EAP server is 497 implemented in a separate AAA server that communicates with the IKEv2 498 responder using, e.g., RADIUS [RADEAP]. In this case, the 499 authenticated identity has to be sent from the AAA server to the 500 IKEv2 responder. 502 (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2", 503 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748, 504 Section 7.3.) 506 3.6. (Section removed) 508 (This issue was corrected in RFC 4306.) 510 3.7. Certificate encoding types 512 Section 3.6 defines a total of twelve different certificate encoding 513 types, and continues that "Specific syntax is for some of the 514 certificate type codes above is not defined in this document." 515 However, the text does not provide references to other documents that 516 would contain information about the exact contents and use of those 517 values. 519 Without this information, it is not possible to develop interoperable 520 implementations. Therefore, this document recommends that the 521 following certificate encoding values should not be used before new 522 specifications that specify their use are available. 524 PKCS #7 wrapped X.509 certificate 1 525 PGP Certificate 2 526 DNS Signed Key 3 527 Kerberos Token 6 528 SPKI Certificate 9 530 (Future versions of this document may also contain clarifications 531 about how these values are to be used.) 533 This document recommends that most implementations should use only 534 those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., 535 "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and 536 URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" 537 (13). 539 Furthermore, Section 3.7 says that the "Certificate Encoding" field 540 for the Certificate Request payload uses the same values as for 541 Certificate payload. However, the contents of the "Certification 542 Authority" field are defined only for X.509 certificates (presumably 543 covering at least types 4, 10, 12, and 13). This document recommends 544 that other values should not be used before new specifications that 545 specify their use are available. 547 The "Raw RSA Key" type needs one additional clarification. Section 548 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is 549 a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21]. 551 3.8. Shared key authentication and fixed PRF key size 553 Section 2.15 says that "If the negotiated prf takes a fixed-size key, 554 the shared secret MUST be of that fixed size". This statement is 555 correct: the shared secret must be of the correct size. If it is 556 not, it cannot be used; there is no padding, truncation, or other 557 processing involved to force it to that correct size. 559 This requirement means that it is difficult to use these PRFs with 560 shared key authentication. The authors think this part of the 561 specification was very poorly thought out, and using PRFs with a 562 fixed key size is likely to result in interoperability problems. 563 Thus, we recommend that such PRFs should not be used with shared key 564 authentication. PRF_AES128_XCBC [RFC3664] originally used fixed key 565 sizes; that RFC has been updated to handle variable key sizes in 566 [RFC3664bis]. 568 Note that Section 2.13 also contains text that is related to PRFs 569 with fixed key size: "When the key for the prf function has fixed 570 length, the data provided as a key is truncated or padded with zeros 571 as necessary unless exceptional processing is explained following the 572 formula". However, this text applies only to the prf+ construction, 573 so it does not contradict the text in Section 2.15. 575 (References: Paul Hoffman's mail "Re: ikev2-07: last nits", 576 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question 577 about PRFs with fixed size key", Jan 2005.) 579 3.9. EAP authentication and fixed PRF key size 581 As described in the previous section, PRFs with a fixed key size 582 require a shared secret of exactly that size. This restriction 583 applies also to EAP authentication. For instance, a PRF that 584 requires a 128-bit key cannot be used with EAP since [EAP] specifies 585 that the MSK is at least 512 bits long. 587 (References: Thread "Question about PRFs with fixed size key", Jan 588 2005.) 590 3.10. Matching ID payloads to certificate contents 592 In IKEv1, there was some confusion about whether or not the 593 identities in certificates used to authenticate IKE were required to 594 match the contents of the ID payloads. There has been some work done 595 on this in the PKI4IPSEC Working Group, but that work is not finished 596 at this time. However, Section 3.5 explicitly says that the ID 597 payload "does not necessarily have to match anything in the CERT 598 payload". 600 3.11. Message IDs for IKE_AUTH messages 602 According to Section 2.2, "The IKE_SA initial setup messages will 603 always be numbered 0 and 1." That is true when the IKE_AUTH exchange 604 does not use EAP. When EAP is used, each pair of messages have their 605 message numbers incremented. The first pair of AUTH messages will 606 have an ID of 1, the second will be 2, and so on. 608 (References: "Question about MsgID in AUTH exchange" thread, April 609 2005.) 611 4. Creating CHILD_SAs 612 4.1. Creating SAs with the CREATE_CHILD_SA exchange 614 Section 1.3's organization does not lead to clear understanding of 615 what is needed in which environment. The section can be reorganized 616 with subsections for each use of the CREATE_CHILD_SA exchange 617 (creating child SAs, rekeying IKE SAs, and rekeying child SAs.) 619 The new Section 1.3 with subsections and the above changes might look 620 like this. 622 NEW-1.3 The CREATE_CHILD_SA Exchange 624 The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and 625 to rekey both IKE_SAs and CHILD_SAs. This exchange consists of 626 a single request/response pair, and some of its function was 627 referred to as a phase 2 exchange in IKEv1. It MAY be initiated 628 by either end of the IKE_SA after the initial exchanges are 629 completed. 631 All messages following the initial exchange are 632 cryptographically protected using the cryptographic algorithms 633 and keys negotiated in the first two messages of the IKE 634 exchange. These subsequent messages use the syntax of the 635 Encrypted Payload described in section 3.14. All subsequent 636 messages include an Encrypted Payload, even if they are referred 637 to in the text as "empty". 639 The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs. 640 This section describes the first part of rekeying, the creation 641 of new SAs; Section 2.8 covers the mechanics of rekeying, 642 including moving traffic from old to new SAs and the deletion of 643 the old SAs. The two sections must be read together to 644 understand the entire process of rekeying. 646 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in 647 this section the term initiator refers to the endpoint 648 initiating this exchange. An implementation MAY refuse all 649 CREATE_CHILD_SA requests within an IKE_SA. 651 The CREATE_CHILD_SA request MAY optionally contain a KE payload 652 for an additional Diffie-Hellman exchange to enable stronger 653 guarantees of forward secrecy for the CHILD_SA or IKE_SA. The 654 keying material for the SA is a function of SK_d established 655 during the establishment of the IKE_SA, the nonces exchanged 656 during the CREATE_CHILD_SA exchange, and the Diffie-Hellman 657 value (if KE payloads are included in the CREATE_CHILD_SA 658 exchange). The details are described in sections 2.17 and 2.18. 660 If a CREATE_CHILD_SA exchange includes a KEi payload, at least 661 one of the SA offers MUST include the Diffie-Hellman group of 662 the KEi. The Diffie-Hellman group of the KEi MUST be an element 663 of the group the initiator expects the responder to accept 664 (additional Diffie-Hellman groups can be proposed). If the 665 responder rejects the Diffie-Hellman group of the KEi payload, 666 the responder MUST reject the request and indicate its preferred 667 Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification 668 payload. In the case of such a rejection, the CREATE_CHILD_SA 669 exchange fails, and the initiator SHOULD retry the exchange with 670 a Diffie-Hellman proposal and KEi in the group that the 671 responder gave in the INVALID_KE_PAYLOAD. 673 NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 675 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. 676 The CREATE_CHILD_SA request for creating a new CHILD_SA is: 678 Initiator Responder 679 ----------- ----------- 680 HDR, SK {[N+], SA, Ni, [KEi], 681 TSi, TSr} --> 683 The initiator sends SA offer(s) in the SA payload, a nonce in 684 the Ni payload, optionally a Diffie-Hellman value in the KEi 685 payload, and the proposed traffic selectors for the proposed 686 CHILD_SA in the TSi and TSr payloads. The request can also 687 contain Notify payloads that specify additional details for the 688 CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, 689 ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO. 691 The CREATE_CHILD_SA response for creating a new CHILD_SA is: 693 <-- HDR, SK {[N+], SA, Nr, 694 [KEr], TSi, TSr} 696 The responder replies with the accepted offer in an SA payload, 697 and a Diffie-Hellman value in the KEr payload if KEi was 698 included in the request and the selected cryptographic suite 699 includes that group. As with the request, optional Notification 700 payloads can specify additional details for the CHILD_SA. 702 The traffic selectors for traffic to be sent on that SA are 703 specified in the TS payloads in the response, which may be a 704 subset of what the initiator of the CHILD_SA proposed. 706 The text about rekeying SAs can be found in Section 5.1 of this 707 document. 709 4.2. Creating an IKE_SA without a CHILD_SA 711 CHILD_SAs can be created either by being piggybacked on the IKE_AUTH 712 exchange, or using a separate CREATE_CHILD_SA exchange. The 713 specification is not clear about what happens if creating the 714 CHILD_SA during the IKE_AUTH exchange fails for some reason. 716 Our recommendation in this sitation is that the IKE_SA is created as 717 usual. This is also in line with how the CREATE_CHILD_SA exchange 718 works: a failure to create a CHILD_SA does not close the IKE_SA. 720 The list of responses in the IKE_AUTH exchange that do not prevent an 721 IKE_SA from being set up include at least the following: 722 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, 723 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. 725 (References: "Questions about internal address" thread, April, 2005.) 727 4.3. Diffie-Hellman for first CHILD_SA 729 Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or 730 Ni/Nr payloads. This implies that the SA payload in IKE_AUTH 731 exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with 732 any other value than NONE. Implementations should probably leave the 733 transform out entirely in this case. 735 4.4. Extended Sequence Numbers (ESN) transform 737 The description of the ESN transform in Section 3.3 has be proved 738 difficult to understand. The ESN transform has the following 739 meaning:: 741 o A proposal containing one ESN transform with value 0 means "do not 742 use extended sequence numbers". 744 o A proposal containing one ESN transform with value 1 means "use 745 extended sequence numbers". 747 o A proposal containing two ESN transforms with values 0 and 1 means 748 "I support both normal and extended sequence numbers, you choose". 749 (Obviously this case is only allowed in requests; the response 750 will contain only one ESN transform.) 752 In most cases, the exchange initiator will include either the first 753 or third alternative in its SA payload. The second alternative is 754 rarely useful for the initiator: it means that using normal sequence 755 numbers is not acceptable (so if the responder does not support ESNs, 756 the exchange will fail with NO_PROPOSAL_CHOSEN). 758 Note that including the ESN transform is mandatory when creating 759 ESP/AH SAs (it was optional in earlier drafts of the IKEv2 760 specification). 762 (References: "Technical change needed to IKEv2 before publication", 763 "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2" 764 and "Results of straw poll regarding: IKEv2 interoperability issue" 765 threads, March-April 2005.) 767 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED 769 The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in 770 Section 3.10.1 says that "This notification asserts that the sending 771 endpoint will NOT accept packets that contain Flow Confidentiality 772 (TFC) padding". 774 However, the text does not say in which messages this notification 775 should be included, or whether the scope of this notification is a 776 single CHILD_SA or all CHILD_SAs of the peer. 778 Our interpretation is that the scope is a single CHILD_SA, and thus 779 this notification is included in messages containing an SA payload 780 negotiating a CHILD_SA. If neither endpoint accepts TFC padding, 781 this notification will be included in both the request proposing an 782 SA and the response accepting it. If this notification is included 783 in only one of the messages, TFC padding can still be sent in one 784 direction. 786 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO 788 NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1 789 simply as "Used for fragmentation control. See [RFC4301] for 790 explanation." 792 [RFC4301] says "Implementations that will transmit non-initial 793 fragments on a tunnel mode SA that makes use of non-trivial port (or 794 ICMP type/code or MH type) selectors MUST notify a peer via the IKE 795 NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this 796 proposal if it will not accept non-initial fragments in this context. 797 If an implementation does not successfully negotiate transmission of 798 non-initial fragments for such an SA, it MUST NOT send such fragments 799 over the SA." 801 However, it is not clear exactly how the negotiation works. Our 802 interpretation is that the negotiation works the same way as for 803 IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments 804 is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included 805 in both the request proposing an SA and the response accepting it. 807 In other words, if the peer "rejects this proposal", it only omits 808 NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not 809 reject the whole CHILD_SA creation. 811 4.7. Semantics of complex traffic selector payloads 813 As described in Section 3.13, the TSi/TSr payloads can include one or 814 more individual traffic selectors. 816 There is no requirement that TSi and TSr contain the same number of 817 individual traffic selectors. Thus, they are interpreted as follows: 818 a packet matches a given TSi/TSr if it matches at least one of the 819 individual selectors in TSi, and at least one of the individual 820 selectors in TSr. 822 For instance, the following traffic selectors: 824 TSi = ((17, 100, 192.0.1.66-192.0.1.66), 825 (17, 200, 192.0.1.66-192.0.1.66)) 826 TSr = ((17, 300, 0.0.0.0-255.255.255.255), 827 (17, 400, 0.0.0.0-255.255.255.255)) 829 would match UDP packets from 192.0.1.66 to anywhere, with any of the 830 four combinations of source/destination ports (100,300), (100,400), 831 (200,300), and (200, 400). 833 This implies that some types of policies may require several CHILD_SA 834 pairs. For instance, a policy matching only source/destination ports 835 (100,300) and (200,400), but not the other two combinations, cannot 836 be negotiated as a single CHILD_SA pair using IKEv2. 838 (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.) 840 4.8. ICMP type/code in traffic selector payloads 842 The traffic selector types 7 and 8 can also refer to ICMP type and 843 code fields. As described in Section 3.13.1, "For the ICMP protocol, 844 the two one-octet fields Type and Code are treated as a single 16-bit 845 integer (with Type in the most significant eight bits and Code in the 846 least significant eight bits) port number for the purposes of 847 filtering based on this field." 849 Since ICMP packets do not have separate source and destination port 850 fields, there is some room for confusion what exactly the four TS 851 payloads (two in the request, two in the response, each containing 852 both start and end port fields) should contain. 854 The answer to this question can be found from [RFC4301] Section 855 4.4.1.3. 857 To give a concrete example, if a host at 192.0.1.234 wants to create 858 a transport mode SA for sending "Destination Unreachable" packets 859 (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them 860 over this SA pair, the CREATE_CHILD_SA exchange would look like this: 862 Initiator Responder 863 ----------- ----------- 864 HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni, 865 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234), 866 TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } --> 868 <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr, 869 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234), 870 TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } 872 Since IKEv2 always creates IPsec SAs in pairs, two SAs are also 873 created in this case, even though the second SA is never used for 874 data traffic. 876 An exchange creating an SA pair that can be used both for sending and 877 receiving "Destination Unreachable" places the same value in all the 878 port: 880 Initiator Responder 881 ----------- ----------- 882 HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni, 883 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234), 884 TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } --> 886 <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr, 887 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234), 888 TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } 890 (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.) 892 4.9. Mobility header in traffic selector payloads 894 Traffic selectors can use IP Protocol ID 135 to match the IPv6 895 mobility header [MIPv6]. However, the IKEv2 specification does not 896 define how to represent the "MH Type" field in traffic selectors. 898 At some point, it was expected that this will be defined in a 899 separate document later. However, [RFC4301] says that "For IKE, the 900 IPv6 mobility header message type (MH type) is placed in the most 901 significant eight bits of the 16 bit local "port" selector". The 902 direction semantics of TSi/TSr port fields are the same as for ICMP, 903 and are described in the previous section. 905 (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header 906 message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2" 907 thread, Sep 2005.) 909 4.10. Narrowing the traffic selectors 911 Section 2.9 describes how traffic selectors are negotiated when 912 creating a CHILD_SA. A more concise summary of the narrowing process 913 is presented below. 915 o If the responder's policy does not allow any part of the traffic 916 covered by TSi/TSr, it responds with TS_UNACCEPTABLE. 918 o If the responder's policy allows the entire set of traffic covered 919 by TSi/TSr, no narrowing is necessary, and the responder can 920 return the same TSi/TSr values. 922 o Otherwise, narrowing is needed. If the responder's policy allows 923 all traffic covered by TSi[1]/TSr[1] (the first traffic selectors 924 in TSi/TSr) but not entire TSi/TSr, the responder narrows to an 925 acceptable subset of TSi/TSr that includes TSi[1]/TSr[1]. 927 o If the responder's policy does not allow all traffic covered by 928 TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to 929 an acceptable subset of TSi/TSr. 931 In the last two cases, there may be several subsets that are 932 acceptable (but their union is not); in this case, the responder 933 arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE 934 notification in the response. 936 4.11. SINGLE_PAIR_REQUIRED 938 The description of the SINGLE_PAIR_REQUIRED notify payload in 939 Sections 2.9 and 3.10.1 is not fully consistent. 941 We do not attempt to describe this payload in this document either, 942 since it is expected that most implementations will not have policies 943 that require separate SAs for each address pair. 945 Thus, if only some part (or parts) of the TSi/TSr proposed by the 946 initiator is (are) acceptable to the responder, most responders 947 should simply narrow TSi/TSr to an acceptable subset (as described in 948 the last two paragraphs of Section 2.9), rather than use 949 SINGLE_PAIR_REQUIRED. 951 4.12. Traffic selectors violating own policy 953 Section 2.9 describes traffic selector negotiation in great detail. 954 One aspect of this negotiation that may need some clarification is 955 that when creating a new SA, the initiator should not propose traffic 956 selectors that violate its own policy. If this rule is not followed, 957 valid traffic may be dropped. 959 This is best illustrated by an example. Suppose that host A has a 960 policy whose effect is that traffic to 192.0.1.66 is sent via host B 961 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 962 is also sent via B, but must use 3DES. Suppose also that host B 963 accepts any combination of AES and 3DES. 965 If host A now proposes an SA that uses 3DES, and includes TSr 966 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host 967 B. Now, host B can also use this SA to send traffic from 192.0.1.66, 968 but those packets will be dropped by A since it requires the use of 969 AES for those traffic. Even if host A creates a new SA only for 970 192.0.1.66 that uses AES, host B may freely continue to use the first 971 SA for the traffic. In this situation, when proposing the SA, host A 972 should have followed its own policy, and included a TSr containing 973 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. 975 In general, if (1) the initiator makes a proposal "for traffic X 976 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator 977 does not actually accept traffic X' with SA, and (3) the initiator 978 would be willing to accept traffic X' with some SA' (!=SA), valid 979 traffic can be unnecessarily dropped since the responder can apply 980 either SA or SA' to traffic X'. 982 (References: "Question about "narrowing" ..." thread, Feb 2005. 983 "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 984 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector 985 negotiation examples", 2004-08-08.) 987 5. Rekeying and deleting SAs 989 5.1. Rekeying SAs with the CREATE_CHILD_SA exchange 991 Continued from Section 4.1 of this document. 993 NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange 995 The CREATE_CHILD_SA request for rekeying an IKE_SA is: 997 Initiator Responder 999 ----------- ----------- 1000 HDR, SK {SA, Ni, [KEi]} --> 1002 The initiator sends SA offer(s) in the SA payload, a nonce in 1003 the Ni payload, and optionally a Diffie-Hellman value in the KEi 1004 payload. 1006 The CREATE_CHILD_SA response for rekeying an IKE_SA is: 1008 <-- HDR, SK {SA, Nr, [KEr]} 1010 The responder replies (using the same Message ID to respond) 1011 with the accepted offer in an SA payload, a nonce in the Nr 1012 payload, and, optionally, a Diffie-Hellman value in the KEr 1013 payload. 1015 The new IKE_SA has its message counters set to 0, regardless of 1016 what they were in the earlier IKE_SA. The window size starts at 1017 1 for any new IKE_SA. The new initiator and responder SPIs are 1018 supplied in the SPI fields of the SA payloads. 1020 NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange 1022 The CREATE_CHILD_SA request for rekeying a CHILD_SA is: 1024 Initiator Responder 1025 ----------- ----------- 1026 HDR, SK {N(REKEY_SA), [N+], SA, 1027 Ni, [KEi], TSi, TSr} --> 1029 The leading Notify payload of type REKEY_SA identifies the 1030 CHILD_SA being rekeyed, and contains the SPI that the initiator 1031 expects in the headers of inbound packets. In addition, the 1032 initiator sends SA offer(s) in the SA payload, a nonce in the Ni 1033 payload, optionally a Diffie-Hellman value in the KEi payload, 1034 and the proposed traffic selectors in the TSi and TSr payloads. 1035 The request can also contain Notify payloads that specify 1036 additional details for the CHILD_SA. 1038 The CREATE_CHILD_SA response for rekeying a CHILD_SA is: 1040 <-- HDR, SK {[N+], SA, Nr, 1041 [KEr], TSi, TSr} 1043 The responder replies with the accepted offer in an SA payload, 1044 and a Diffie-Hellman value in the KEr payload if KEi was 1045 included in the request and the selected cryptographic suite 1046 includes that group. 1048 The traffic selectors for traffic to be sent on that SA are 1049 specified in the TS payloads in the response, which may be a 1050 subset of what the initiator of the CHILD_SA proposed. 1052 5.2. Rekeying the IKE_SA vs. reauthentication 1054 Rekeying the IKE_SA and reauthentication are different concepts in 1055 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and 1056 resets the Message ID counters, but it does not authenticate the 1057 parties again (no AUTH or EAP payloads are involved). 1059 While rekeying the IKE_SA may be important in some environments, 1060 reauthentication (the verification that the parties still have access 1061 to the long-term credentials) is often more important. 1063 IKEv2 does not have any special support for reauthentication. 1064 Reauthentication is done by creating a new IKE_SA from scratch (using 1065 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify 1066 payloads), creating new CHILD_SAs within the new IKE_SA (without 1067 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which 1068 deletes the old CHILD_SAs as well). 1070 This means that reauthentication also establishes new keys for the 1071 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed 1072 more often than reauthentication, the situation where "authentication 1073 lifetime" is shorter than "key lifetime" does not make sense. 1075 While creation of a new IKE_SA can be initiated by either party 1076 (initiator or responder in the original IKE_SA), the use of EAP 1077 authentication and/or configuration payloads means in practice that 1078 reauthentication has to be initiated by the same party as the 1079 original IKE_SA. IKEv2 does not currently allow the responder to 1080 request reauthentication in this case; however, there is ongoing work 1081 to add this functionality [ReAuth]. 1083 (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.) 1085 5.3. SPIs when rekeying the IKE_SA 1087 Section 2.18 says that "New initiator and responder SPIs are supplied 1088 in the SPI fields". This refers to the SPI fields in the Proposal 1089 structures inside the Security Association (SA) payloads, not the SPI 1090 fields in the IKE header. 1092 (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24. 1093 Geoffrey Huang's reply, 2005-01-24.) 1095 5.4. SPI when rekeying a CHILD_SA 1097 Section 3.10.1 says that in REKEY_SA notifications, "The SPI field 1098 identifies the SA being rekeyed." 1100 Since CHILD_SAs always exist in pairs, there are two different SPIs. 1101 The SPI placed in the REKEY_SA notification is the SPI the exchange 1102 initiator would expect in inbound ESP or AH packets (just as in 1103 Delete payloads). 1105 5.5. Changing PRFs when rekeying the IKE_SA 1107 When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the 1108 new IKE_SA is computed using SK_d from the existing IKE_SA as 1109 follows: 1111 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)" 1113 If the old and new IKE_SA selected a different PRF, it is not totally 1114 clear which PRF should be used. 1116 Since the rekeying exchange belongs to the old IKE_SA, it is the old 1117 IKE_SA's PRF that is used. This also follows the principle that the 1118 same key (the old SK_d) should not be used with multiple 1119 cryptographic algorithms. 1121 Note that this may work poorly if the new IKE_SA's PRF has a fixed 1122 key size, since the output of the PRF may not be of the correct size. 1123 This supports our opinion earlier in the document that the use of 1124 PRFs with a fixed key size is a bad idea. 1126 (References: "Changing PRFs when rekeying the IKE_SA" thread, June 1127 2005.) 1129 5.6. Deleting vs. closing SAs 1131 The IKEv2 specification talks about "closing" and "deleting" SAs, but 1132 it is not always clear what exactly is meant. However, other parts 1133 of the specification make it clear that when local state related to a 1134 CHILD_SA is removed, the SA must also be actively deleted with a 1135 Delete payload. 1137 In particular, Section 2.4 says that "If an IKE endpoint chooses to 1138 delete CHILD_SAs, it MUST send Delete payloads to the other end 1139 notifying it of the deletion". Section 1.4 also explains that "ESP 1140 and AH SAs always exist in pairs, with one SA in each direction. 1141 When an SA is closed, both members of the pair MUST be closed." 1143 5.7. Deleting a CHILD_SA pair 1145 Section 1.4 describes how to delete SA pairs using the Informational 1146 exchange: "To delete an SA, an INFORMATIONAL exchange with one or 1147 more delete payloads is sent listing the SPIs (as they would be 1148 expected in the headers of inbound packets) of the SAs to be deleted. 1149 The recipient MUST close the designated SAs." 1151 The "one or more delete payloads" phrase has caused some confusion. 1152 You never send delete payloads for the two sides of an SA in a single 1153 message. If you have many SAs to delete at the same time (such as 1154 the nested example given in that paragraph), you include delete 1155 payloads for in inbound half of each SA in your Informational 1156 exchange. 1158 5.8. Deleting an IKE_SA 1160 Since IKE_SAs do not exist in pairs, it is not totally clear what the 1161 response message should contain when the request deleted the IKE_SA. 1163 Since there is no information that needs to be sent to the other side 1164 (except that the request was received), an empty Informational 1165 response seems like the most logical choice. 1167 (References: "Question about delete IKE SA" thread, May 2005.) 1169 5.9. Who is the original initiator of IKE_SA 1171 In the IKEv2 document, "initiator" refers to the party who initiated 1172 the exchange being described, and "original initiator" refers to the 1173 party who initiated the whole IKE_SA. However, there is some 1174 potential for confusion because the IKE_SA can be rekeyed by either 1175 party. 1177 To clear up this confusion, we propose that "original initiator" 1178 always refers to the party who initiated the exchange which resulted 1179 in the current IKE_SA. In other words, if the the "original 1180 responder" starts rekeying the IKE_SA, that party becomes the 1181 "original initiator" of the new IKE_SA. 1183 (References: Paul Hoffman's mail "Original initiator in IKEv2", 2005- 1184 04-21.) 1186 5.10. (Section removed) 1188 (This issue was corrected in RFC 4306.) 1190 5.11. Comparing nonces 1192 Section 2.8 about rekeying says that "If redundant SAs are created 1193 though such a collision, the SA created with the lowest of the four 1194 nonces used in the two exchanges SHOULD be closed by the endpoint 1195 that created it." 1197 Here "lowest" uses an octet-by-octet (lexicographical) comparison 1198 (instead of, for instance, comparing the nonces as large integers). 1199 In other words, start by comparing the first octet; if they're equal, 1200 move to the next octet, and so on. If you reach the end of one 1201 nonce, that nonce is the lower one. 1203 (References: "IKEv2 rekeying question" thread, July 2005.) 1205 5.12. Exchange collisions 1207 Since IKEv2 exchanges can be initiated by both peers, it is possible 1208 that two exchanges affecting the same SA partly overlap. This can 1209 lead to a situation where the SA state information is temporarily out 1210 of sync, and a peer can receive a request it cannot process in a 1211 normal fashion. Some of these corner cases are discussed in the 1212 specification, some are not. 1214 Obviously, using a window size greater than one leads to infinitely 1215 more complex situations, especially if requests are processed out of 1216 order. In this section, we concentrate on problems that can arise 1217 even with window size 1. 1219 (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/ 1220 Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.) 1222 5.12.1. Simultaneous CHILD_SA close 1224 Probably the simplest case happens if both peers decide to close the 1225 same CHILD_SA pair at the same time: 1227 Host A Host B 1228 -------- -------- 1229 send req1: D(SPIa) --> 1230 <-- send req2: D(SPIb) 1231 --> recv req1 1232 <-- send resp1: () 1233 recv resp1 1234 recv req2 1235 send resp2: () --> 1236 --> recv resp2 1238 This case is described in Section 1.4, and is handled by omitting the 1239 Delete payloads from the response messages. 1241 5.12.2. Simultaneous IKE_SA close 1243 Both peers can also decide to close the IKE_SA at the same time. The 1244 desired end result is obvious; however, in certain cases the final 1245 exchanges may not be fully completed. 1247 Host A Host B 1248 -------- -------- 1249 send req1: D() --> 1250 <-- send req2: D() 1251 --> recv req1 1253 At this point, host B should reply as usual (with empty Informational 1254 response), close the IKE_SA, and stop retransmitting req2. This is 1255 because once host A receives resp1, it may not be able to reply any 1256 longer. The situation is symmetric, so host A should behave the same 1257 way. 1259 Host A Host B 1260 -------- -------- 1261 <-- send resp1: () 1262 send resp2: () 1264 Even if neither resp1 nor resp2 ever arrives, the end result is still 1265 correct: the IKE_SA is gone. The same happens if host A never 1266 receives req2. 1268 5.12.3. Simultaneous CHILD_SA rekeying 1270 Another case that is described in the specification is simultaneous 1271 rekeying. Section 2.8 says 1273 "If the two ends have the same lifetime policies, it is possible 1274 that both will initiate a rekeying at the same time (which will 1275 result in redundant SAs). To reduce the probability of this 1276 happening, the timing of rekeying requests SHOULD be jittered 1277 (delayed by a random amount of time after the need for rekeying is 1278 noticed). 1280 This form of rekeying may temporarily result in multiple similar 1281 SAs between the same pairs of nodes. When there are two SAs 1282 eligible to receive packets, a node MUST accept incoming packets 1283 through either SA. If redundant SAs are created though such a 1284 collision, the SA created with the lowest of the four nonces used 1285 in the two exchanges SHOULD be closed by the endpoint that created 1286 it." 1288 However, a better explanation on what impact this has on 1289 implementations is needed. Assume that hosts A and B have an 1290 existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start 1291 rekeying it at the same time: 1293 Host A Host B 1294 -------- -------- 1295 send req1: N(REKEY_SA,SPIa1), 1296 SA(..,SPIa2,..),Ni1,.. --> 1297 <-- send req2: N(REKEY_SA,SPIb1), 1298 SA(..,SPIb2,..),Ni2,.. 1299 recv req2 <-- 1301 At this point, A knows there is a simultaneous rekeying going on. 1302 However, it cannot yet know which of the exchanges will have the 1303 lowest nonce, so it will just note the situation and respond as 1304 usual. 1306 send resp2: SA(..,SPIa3,..),Nr1,.. --> 1307 --> recv req1 1309 Now B also knows that simultaneous rekeying is going on. Similarly 1310 as host A, it has to respond as usual. 1312 <-- send resp1: SA(..,SPIb3,..),Nr2,.. 1313 recv resp1 <-- 1314 --> recv resp2 1316 At this point, there are three CHILD_SA pairs between A and B (the 1317 old one and two new ones). A and B can now compare the nonces. 1318 Suppose that the lowest nonce was Nr1 in message resp2; in this case, 1319 B (the sender of req2) deletes the redundant new SA, and A (the node 1320 that initiated the surviving rekeyed SA), deletes the old one. 1322 send req3: D(SPIa1) --> 1323 <-- send req4: D(SPIb2) 1324 --> recv req3 1325 <-- send resp4: D(SPIb1) 1326 recv req4 <-- 1327 send resp4: D(SPIa3) --> 1329 The rekeying is now finished. 1331 However, there is a second possible sequence of events that can 1332 happen if some packets are lost in the network, resulting in 1333 retransmissions. The rekeying begins as usual, but A's first packet 1334 (req1) is lost. 1336 Host A Host B 1337 -------- -------- 1338 send req1: N(REKEY_SA,SPIa1), 1339 SA(..,SPIa2,..),Ni1,.. --> (lost) 1340 <-- send req2: N(REKEY_SA,SPIb1), 1341 SA(..,SPIb2,..),Ni2,.. 1342 recv req2 <-- 1343 send resp2: SA(..,SPIa3,..),Nr1,.. --> 1344 --> recv resp2 1345 <-- send req3: D(SPIb1) 1346 recv req3 <-- 1347 send resp3: D(SPIa1) --> 1348 --> recv resp3 1350 From B's point of view, the rekeying is now completed, and since it 1351 has not yet received A's req1, it does not even know that these was 1352 simultaneous rekeying. However, A will continue retransmitting the 1353 message, and eventually it will reach B. 1355 resend req1 --> 1356 --> recv req1 1358 What should B do in this point? To B, it looks like A is trying to 1359 rekey an SA that no longer exists; thus failing the request with 1360 something non-fatal such as NO_PROPOSAL_CHOSEN seems like a 1361 reasonable approach. 1363 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1364 recv resp1 <-- 1366 When A receives this error, it already knows there was simultaneous 1367 rekeying, so it can ignore the error message. 1369 5.12.4. Simultaneous IKE_SA rekeying 1371 Probably the most complex case occurs when both peers try to rekey 1372 the IKE_SA at the same time. Basically, the text in Section 2.8 1373 applies to this case as well; however, it is important to ensure that 1374 the CHILD_SAs are inherited by the right IKE_SA. 1376 The case where both endpoints notice the simultaneous rekeying works 1377 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, 1378 three IKE_SAs exist between A and B; the one containing the lowest 1379 nonce inherits the CHILD_SAs. 1381 However, there is a twist to the other case where one rekeying 1382 finishes first: 1384 Host A Host B 1385 -------- -------- 1386 send req1: 1387 SA(..,SPIa1,..),Ni1,.. --> 1388 <-- send req2: SA(..,SPIb1,..),Ni2,.. 1389 --> recv req1 1390 <-- send resp1: SA(..,SPIb2,..),Nr2,.. 1391 recv resp1 <-- 1392 send req3: D() --> 1393 --> recv req3 1395 At this point, host B sees a request to close the IKE_SA. There's 1396 not much more to do than to reply as usual. However, at this point 1397 host B should stop retransmitting req2, since once host A receives 1398 resp3, it will delete all the state associated with the old IKE_SA, 1399 and will not be able to reply to it. 1401 <-- send resp3: () 1403 5.12.5. Closing and rekeying a CHILD_SA 1405 A case similar to simultaneous rekeying can occur if one peers 1406 decides to close an SA and the other peer tries to rekey it: 1408 Host A Host B 1409 -------- -------- 1410 send req1: D(SPIa) --> 1411 <-- send req2: N(REKEY_SA,SPIb),SA,.. 1412 --> recv req1 1414 At this point, host B notices that host A is trying to close an SA 1415 that host B is currently rekeying. Replying as usual is probably the 1416 best choice: 1418 <-- send resp1: D(SPIb) 1420 Depending on in which order req2 and resp1 arrive, host A sees either 1421 a request to rekey an SA that it is currently closing, or a request 1422 to rekey an SA that does not exist. In both cases, 1423 NO_PROPOSAL_CHOSEN is probably fine. 1425 recv req2 1426 recv resp1 1427 send resp2: N(NO_PROPOSAL_CHOSEN) --> 1428 --> recv resp2 1430 5.12.6. Closing a new CHILD_SA 1432 Yet another case occurs when host A creates a CHILD_SA pair, but soon 1433 thereafter host B decides to delete it (possible because its policy 1434 changed): 1436 Host A Host B 1437 -------- -------- 1438 send req1: [N(REKEY_SA,SPIa1)], 1439 SA(..,SPIa2,..),.. --> 1440 --> recv req1 1441 (lost) <-- send resp1: SA(..,SPIb2,..),.. 1443 <-- send req2: D(SPIb2) 1444 recv req2 1446 At this point, host A has not yet received message resp1 (and is 1447 retransmitting message req1), so it does not recognize SPIb in 1448 message req2. What should host A do? 1450 One option would be to reply with an empty Informational response. 1451 However, this same reply would also be sent if host A has received 1452 resp1, but has already sent a new request to delete the SA that was 1453 just created. This would lead to a situation where the peers are no 1454 longer in sync about which SAs exist between them. However, host B 1455 would eventually notice that the other half of the CHILD_SA pair has 1456 not been deleted. Section 1.4 describes this case and notes that "a 1457 node SHOULD regard half-closed connections as anomalous and audit 1458 their existence should they persist", and continues that "if 1459 connection state becomes sufficiently messed up, a node MAY close the 1460 IKE_SA". 1462 Another solution that has been proposed is to reply with an 1463 INVALID_SPI notification which contains SPIb. This would explicitly 1464 tell host B that the SA was not deleted, so host B could try deleting 1465 it again later. However, this usage is not part of the IKEv2 1466 specification, and would not be in line with normal use of the 1467 INVALID_SPI notification where the data field contains the SPI the 1468 recipient of the notification would put in outbound packets. 1470 Yet another solution would be to ignore req2 at this time, and wait 1471 until we have received resp1. However, this alternative has not been 1472 fully analyzed at this time; in general, ignoring valid requests is 1473 always a bit dangerous, because both endpoints could do it, leading 1474 to a deadlock. 1476 Currently, this document recommends the first alternative. 1478 5.12.7. Rekeying a new CHILD_SA 1480 Yet another case occurs when a CHILD_SA is rekeyed soon after it has 1481 been created: 1483 Host A Host B 1484 -------- -------- 1485 send req1: [N(REKEY_SA,SPIa1)], 1486 SA(..,SPIa2,..),.. --> 1487 (lost) <-- send resp1: SA(..,SPIb2,..),.. 1489 <-- send req2: N(REKEY_SA,SPIb2), 1490 SA(..,SPIb3,..),.. 1491 recv req2 <-- 1493 To host A, this looks like a request to rekey an SA that does not 1494 exist. Like in the simultaneous rekeying case, replying with 1495 NO_PROPOSAL_CHOSEN is probably reasonable: 1497 send resp2: N(NO_PROPOSAL_CHOSEN) --> 1498 recv resp1 1500 5.12.8. Collisions with IKE_SA rekeying 1502 Another set of cases occur when one peer starts rekeying the IKE_SA 1503 at the same time the other peer starts creating, rekeying, or closing 1504 a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon 1505 after, host A starts rekeying the IKE_SA: 1507 Host A Host B 1508 -------- -------- 1509 <-- send req1: SA,Ni1,TSi,TSr 1510 send req2: SA,Ni2,.. --> 1511 --> recv req2 1513 What should host B do at this point? Replying as usual would seem 1514 like a reasonable choice: 1516 <-- send resp2: SA,Ni2,.. 1517 recv resp2 <-- 1518 send req3: D() --> 1519 --> recv req3 1521 Now, a problem arises: If host B now replies normally with an empty 1522 Informational response, this will cause host A to delete state 1523 associated with the IKE_SA. This means host B should stop 1524 retransmitting req1. However, host B cannot know whether or not host 1525 A has received req1. If host A did receive it, it will move the 1526 CHILD_SA to the new IKE_SA as usual, and the state information will 1527 then be out of sync. 1529 It seems this situation is tricky to handle correctly. Our proposal 1530 is as follows: if a host receives a request to rekey the IKE_SA when 1531 it has CHILD_SAs in "half-open" state (currently being created or 1532 rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host 1533 receives a request to create or rekey a CHILD_SA after it has started 1534 rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. 1536 The case where CHILD_SAs are being closed is even worse. Our 1537 recommendation is that if a host receives a request to rekey the 1538 IKE_SA when it has CHILD_SAs in "half-closed" state (currently being 1539 closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host 1540 receives a request to close a CHILD_SA after it has started rekeying 1541 the IKE_SA, it should reply with an empty Informational response. 1542 This ensures that at least the other peer will eventually notice that 1543 the CHILD_SA is still in "half-closed" state, and will start a new 1544 IKE_SA from scratch. 1546 5.12.9. Closing and rekeying the IKE_SA 1548 The final case considered in this section occurs if one peer decides 1549 to close the IKE_SA while the other peer tries to rekey it. 1551 Host A Host B 1552 -------- -------- 1553 send req1: SA(..,SPIa1,..),Ni1 --> 1554 <-- send req2: D() 1555 --> recv req1 1556 recv req2 <-- 1558 At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, 1559 and host A should reply as usual, close the IKE_SA, and stop 1560 retransmitting req1. 1562 <-- send resp1: N(NO_PROPOSAL_CHOSEN) 1563 send resp2: () 1565 If host A wants to continue communication with B, it can now start a 1566 new IKE_SA. 1568 5.12.10. Summary 1570 If a host receives a request to rekey: 1572 o a CHILD_SA pair that the host is currently trying to close: reply 1573 with NO_PROPOSAL_CHOSEN. 1575 o a CHILD_SA pair that the host is currently rekeying: reply as 1576 usual, but prepare to close redundant SAs later based on the 1577 nonces. 1579 o a CHILD_SA pair that does not exist: reply with 1580 NO_PROPOSAL_CHOSEN. 1582 o the IKE_SA, and the host is currently rekeying the IKE_SA: reply 1583 as usual, but prepare to close redundant SAs and move inherited 1584 CHILD_SAs later based on the nonces. 1586 o the IKE_SA, and the host is currently creating, rekeying, or 1587 closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN. 1589 o the IKE_SA, and the host is currently trying to close the IKE_SA: 1590 reply with NO_PROPOSAL_CHOSEN. 1592 If a host receives a request to close: 1594 o a CHILD_SA pair that the host is currently trying to close: reply 1595 without Delete payloads. 1597 o a CHILD_SA pair that the host is currently rekeying: reply as 1598 usual, with Delete payload. 1600 o a CHILD_SA pair that does not exist: reply without Delete 1601 payloads. 1603 o the IKE_SA, and the host is currently rekeying the IKE_SA: reply 1604 as usual, and forget about our own rekeying request. 1606 o the IKE_SA, and the host is currently trying to close the IKE_SA: 1607 reply as usual, and forget about our own close request. 1609 If a host receives a request to create or rekey a CHILD_SA when it is 1610 currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS. 1612 If a host receives a request to delete a CHILD_SA when it is 1613 currently rekeying the IKE_SA: reply without Delete payloads. 1615 5.13. Diffie-Hellman and rekeying the IKE_SA 1617 There has been some confusion whether doing a new Diffie-Hellman 1618 exchange is mandatory when the IKE_SA is rekeyed. 1620 It seems that this case is allowed by the IKEv2 specification. 1621 Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets, and 1622 the change history appendix in the draft mentioned this as one change 1623 between draft versions -00 and -01. Section 3.3.3 does not 1624 contradict this when it says that including the D-H transform is 1625 mandatory: although including the transform is mandatory, it can 1626 contain the value "NONE". 1628 However, having the option to skip the Diffie-Hellman exchange when 1629 rekeying the IKE_SA does not add useful functionality to the 1630 protocol. The main purpose of rekeying the IKE_SA is to ensure that 1631 the compromise of old keying material does not provide information 1632 about the current keys, or vice versa. This requires performing the 1633 Diffie-Hellman exchange when rekeying. Furthermore, it is likely 1634 that this option would have been removed from the protocol as 1635 unnecessary complexity had it been discussed earlier. 1637 Given this, we recommend that implementations should have a hard- 1638 coded policy that requires performing a new Diffie-Hellman exchange 1639 when rekeying the IKE_SA. In other words, the initiator should not 1640 propose the value "NONE" for the D-H transform, and the responder 1641 should not accept such a proposal. This policy also implies that a 1642 succesful exchange rekeying the IKE_SA always includes the KEi/KEr 1643 payloads. 1645 (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange" 1646 thread, Oct 2005. "Comments of 1647 draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.) 1649 6. Configuration payloads 1651 6.1. Assigning IP addresses 1653 Section 2.9 talks about traffic selector negotiation and mentions 1654 that "In support of the scenario described in section 1.1.3, an 1655 initiator may request that the responder assign an IP address and 1656 tell the initiator what it is." 1658 This sentence is correct, but its placement is slightly confusing. 1659 IKEv2 does allow the initiator to request assignment of an IP address 1660 from the responder, but this is done using configuration payloads, 1661 not traffic selector payloads. An address in a TSi payload in a 1662 response does not mean that the responder has assigned that address 1663 to the initiator; it only means that if packets matching these 1664 traffic selectors are sent by the initiator, IPsec processing can be 1665 performed as agreed for this SA. The TSi payload itself does not 1666 give the initiator permission to configure the initiator's TCP/IP 1667 stack with the address and use it as its source address. 1669 In other words, IKEv2 does not have two different mechanisms for 1670 assigning addresses, but only one: configuration payloads. In the 1671 scenario described in Section 1.1.3, both configuration and traffic 1672 selector payloads are usually included in the same message, and often 1673 contain the same information in the response message (see Section 6.4 1674 of this document for some examples). However, their semantics are 1675 still different. 1677 6.2. (Section removed) 1679 (This issue was corrected in RFC 4306.) 1681 6.3. Requesting any INTERNAL_IP4/IP6_ADDRESS 1683 When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 1684 3.15.1 says that "In a request message, the address specified is a 1685 requested address (or zero if no specific address is requested)". 1686 The question here is that does "zero" mean an address "0.0.0.0" or a 1687 zero length string? 1689 Earlier, the same section also says that "If an attribute in the 1690 CFG_REQUEST Configuration Payload is not zero-length, it is taken as 1691 a suggestion for that attribute". Also, the table of configuration 1692 attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 1693 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 1694 octets". 1696 Thus, if the client does not request a specific address, it includes 1697 a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute 1698 containing an all-zeroes address. The example in 2.19 is thus 1699 incorrect, since it shows the attribute as 1700 "INTERNAL_ADDRESS(0.0.0.0)". 1702 However, since the value is only a suggestion, implementations are 1703 recommended to ignore suggestions they do not accept; or in other 1704 words, treat the same way a zero-length INTERNAL_IP4_ADDRESS, 1705 "0.0.0.0", and any other addresses the implementation does not 1706 recognize as a reasonable suggestion. 1708 6.4. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 1710 Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected 1711 sub-networks that this edge-device protects. This attribute is made 1712 up of two fields: the first is an IP address and the second is a 1713 netmask. Multiple sub-networks MAY be requested. The responder MAY 1714 respond with zero or more sub-network attributes." 1715 INTERNAL_IP6_SUBNET is defined in a similar manner. 1717 This raises two questions: first, since this information is usually 1718 included in the TSr payload, what functionality does this attribute 1719 add? And second, what does this attribute mean in CFG_REQUESTs? 1721 For the first question, there seem to be two sensible 1722 interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA 1723 response) indicates which subnets are accessible through the SA that 1724 was just created. 1726 The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is 1727 that they indicate additional subnets that can be reached through 1728 this gateway, but need a separate SA. According to this 1729 interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful 1730 mainly when they contain addresses not included in TSr. 1732 The second interpretation is that the INTERNAL_IP4/6_SUBNET 1733 attributes express the gateway's policy about what traffic should be 1734 sent through the gateway. The client can choose whether other 1735 traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent 1736 through the gateway or directly the destination. According to this 1737 interpretation, the attributes are useful mainly when TSr contains 1738 addresses not included in the INTERNAL_IP4/6_SUBNET attributes. 1740 It turns out that these two interpretations are not incompatible, but 1741 rather two sides of the same principle: traffic to the addresses 1742 listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via 1743 this gateway. If there are no existing IPsec SAs whose traffic 1744 selectors cover the address in question, new SAs have to be created. 1746 A couple of examples are given below. For instance, if there are two 1747 subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request 1748 contains the following: 1750 CP(CFG_REQUEST) = 1751 INTERNAL_IP4_ADDRESS() 1752 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 1753 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 1755 Then a valid response could be the following (in which TSr and 1756 INTERNAL_IP4_SUBNET contain the same information): 1758 CP(CFG_REPLY) = 1759 INTERNAL_IP4_ADDRESS(192.0.1.234) 1760 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 1761 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 1762 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 1763 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), 1764 (0, 0-65535, 192.0.2.0-192.0.2.255)) 1766 In these cases, the INTERNAL_IP4_SUBNET does not really carry any 1767 useful information. Another possible reply would have been this: 1769 CP(CFG_REPLY) = 1770 INTERNAL_IP4_ADDRESS(192.0.1.234) 1771 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 1772 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 1773 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 1774 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) 1776 This would mean that the client can send all its traffic through the 1777 gateway, but the gateway does not mind if the client sends traffic 1778 not included by INTERNAL_IP4_SUBNET directly to the destination 1779 (without going through the gateway). 1781 A different situation arises if the gateway has a policy that 1782 requires the traffic for the two subnets to be carried in separate 1783 SAs. Then a response like this would indicate to the client that if 1784 it wants access to the second subnet, it needs to create a separate 1785 SA: 1787 CP(CFG_REPLY) = 1788 INTERNAL_IP4_ADDRESS(192.0.1.234) 1789 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 1790 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 1791 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 1792 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) 1794 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included 1795 only part of the address space. For instance, if the client requests 1796 the following: 1798 CP(CFG_REQUEST) = 1799 INTERNAL_IP4_ADDRESS() 1800 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) 1801 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 1803 Then the gateway's reply could be this: 1805 CP(CFG_REPLY) = 1806 INTERNAL_IP4_ADDRESS(192.0.1.234) 1807 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) 1808 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) 1809 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) 1810 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) 1812 It is less clear what the attributes mean in CFG_REQUESTs, and 1813 whether other lengths than zero make sense in this situation (but for 1814 INTERNAL_IP6_SUBNET, zero length is not allowed at all!). Currently 1815 this document recommends that implementations should not include 1816 INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in 1817 CFG_REQUESTs. 1819 For the IPv4 case, this document recommends using only netmasks 1820 consisting of some amount of "1" bits followed by "0" bits; for 1821 instance, "255.0.255.0" would not be a valid netmask for 1822 INTERNAL_IP4_SUBNET. 1824 It is also worthwhile to note that the contents of the INTERNAL_IP4/ 1825 6_SUBNET attributes do not imply link boundaries. For instance, a 1826 gateway providing access to a large company intranet using addresses 1827 from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET 1828 attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of 1829 routers and separate links. 1831 (References: Tero Kivinen's mail "Intent of couple of attributes in 1832 Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao 1833 Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in 1834 IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2 1835 Clarifications and Implementation Guidelines", 2005-02-07. 1836 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, 1837 April 2005.) 1839 6.5. INTERNAL_IP4_NETMASK 1841 Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says 1842 that "The internal network's netmask. Only one netmask is allowed in 1843 the request and reply messages (e.g., 255.255.255.0) and it MUST be 1844 used only with an INTERNAL_IP4_ADDRESS attribute". 1846 However, it is not clear what exactly this attribute means, as the 1847 concept of "netmask" is not very well defined for point-to-point 1848 links (unlike multi-access links, where it means "you can reach hosts 1849 inside this netmask directly using layer 2, instead of sending 1850 packets via a router"). Even if the operating system's TCP/IP stack 1851 requires a netmask to be configured, for point-to-point links it 1852 could be just set to 255.255.255.255. So, why is this information 1853 sent in IKEv2? 1855 One possible interpretation would be that the host is given a whole 1856 block of IP addresses instead of a single address. This is also what 1857 Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension 1858 does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed- 1859 IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the 1860 specification supports this interpretation, and discussions on the 1861 IPsec WG mailing list have confirmed it was not intended. Section 1862 3.15.1 also says that multiple addresses are assigned using multiple 1863 INTERNAL_IP4/6_ADDRESS attributes. 1865 Currently, this document's interpretation is the following: 1866 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as 1867 INTERNAL_IP4_SUBNET containing the same information ("send traffic to 1868 these addresses through me"), but also implies a link boundary. For 1869 instance, the client could use its own address and the netmask to 1870 calculate the broadcast address of the link. (Whether the gateway 1871 will actually deliver broadcast packets to other VPN clients and/or 1872 other nodes connected to this link is another matter.) 1874 An empty INTERNAL_IP4_NETMASK attribute can be included in a 1875 CFG_REQUEST to request this information (although the gateway can 1876 send the information even when not requested). However, it seems 1877 that non-empty values for this attribute do not make sense in 1878 CFG_REQUESTs. 1880 Fortunately, Section 4 clearly says that a minimal implementation 1881 does not need to include or understand the INTERNAL_IP4_NETMASK 1882 attribute, and thus this document recommends that implementations 1883 should not use the INTERNAL_IP4_NETMASK attribute or assume that the 1884 other peer supports it. 1886 (References: Charlie Kaufman's mail "RE: Proposed Last Call based 1887 revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen, 1888 Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and 1889 Implementation Guidelines", 2005-02-07. "Clarifications open issue: 1890 INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.) 1892 6.6. Configuration payloads for IPv6 1894 IKEv2 also defines configuration payloads for IPv6. However, they 1895 are based on the corresponding IPv4 payloads, and do not fully follow 1896 the "normal IPv6 way of doing things". 1898 A client can be assigned an IPv6 address using the 1899 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could 1900 look like this: 1902 CP(CFG_REQUEST) = 1903 INTERNAL_IP6_ADDRESS() 1904 INTERNAL_IP6_DNS() 1905 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1906 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1908 CP(CFG_REPLY) = 1909 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) 1910 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) 1911 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 1912 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 1914 In particular, IPv6 stateless autoconfiguration or router 1915 advertisement messages are not used; neither is neighbor discovery. 1917 The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute 1918 in the CFG_REQUEST to request a specific address or interface 1919 identifier. The gateway first checks if the specified address is 1920 acceptable, and if it is, returns that one. If the address was not 1921 acceptable, the gateway will attempt to use the interface identifier 1922 with some other prefix; if even that fails, the gateway will select 1923 another interface identifier. 1925 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length 1926 field. When used in a CFG_REPLY, this corresponds to the 1927 INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was 1928 called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft). 1929 See the previous section for more details. 1931 While this approach to configuring IPv6 addresses is reasonably 1932 simple, it has some limitations: IPsec tunnels configured using IKEv2 1933 are not fully-featured "interfaces" in the IPv6 addressing 1934 architecture [IPv6Addr] sense. In particular, they do not 1935 necessarily have link-local addresses, and this may complicate the 1936 use of protocols that assume them, such as [MLDv2]. (Whether they 1937 are called "interfaces" in some particular operating system is a 1938 different issue.) 1940 (References: "VPN remote host configuration IPv6 ?" thread, May 2004. 1941 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread, 1942 April 2005.) 1944 6.7. INTERNAL_IP6_NBNS 1946 Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending 1947 the IPv6 address of NetBIOS name servers. 1949 However, NetBIOS is not defined for IPv6, and probably never will be. 1950 Thus, this attribute most likely does not make much sense. 1952 (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) 1953 BoF at IETF62.) 1955 6.8. INTERNAL_ADDRESS_EXPIRY 1957 Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as 1958 "Specifies the number of seconds that the host can use the internal 1959 IP address. The host MUST renew the IP address before this expiry 1960 time. Only one of these attributes MAY be present in the reply." 1962 Expiry times and explicit renewals are primarily useful in 1963 environments like DHCP, where the server cannot reliably know when 1964 the client has gone away. However, in IKEv2 this is known, and the 1965 gateway can simply free the address when the IKE_SA is deleted. 1967 Also, Section 4 says that supporting renewals is not mandatory. 1968 Given that this functionality is usually not needed, we recommend 1969 that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. 1970 (And since this attribute does not seem to make much sense for 1971 CFG_REQUESTs, clients should not send it either.) 1973 Note that according to Section 4, clients are required to understand 1974 INTERNAL_ADDRESS_EXPIRY if the receive it. A minimum implementation 1975 would use the value to limit the lifetime of the IKE_SA. 1977 (References: Tero Kivinen's mail "Comments of 1978 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05. 1979 "Questions about internal address" thread, April 2005.) 1981 6.9. Address assignment failures 1983 If the responder encounters an error while attempting to assign an IP 1984 address to the initiator, it responds with an 1985 INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. 1986 However, there are some more complex error cases. 1988 First, if the responder does not support configuration payloads at 1989 all, it can simply ignore all configuration payloads. This type of 1990 implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 1991 If the initiator requires the assignment of an IP address, it will 1992 treat a response without CFG_REPLY as an error. 1994 A second case is where the responder does support configuration 1995 payloads, but only for particular type of addresses (IPv4 or IPv6). 1996 Section 4 says that "A minimal IPv4 responder implementation will 1997 ignore the contents of the CP payload except to determine that it 1998 includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the 1999 initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS 2000 in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the 2001 IPv6 part and process the IPv4 request as usual. 2003 A third case is where the initiator requests multiple addresses of a 2004 type that the responder supports: what should happen if some (but not 2005 all) of the requests fail? It seems that an optimistic approach 2006 would be the best one here: if the responder is able to assign at 2007 least one address, it replies with those; it sends 2008 INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. 2010 (References: "ikev2 and internal_ivpn_address" thread, June 2005.) 2012 7. Miscellaneous issues 2014 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR 2016 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr 2017 payloads, IKEv2 does not require this address to match the address in 2018 the IP header (of IKEv2 packets), or anything in the TSi/TSr 2019 payloads. The contents of IDi/IDr is used purely to fetch the policy 2020 and authentication data related to the other party. 2022 (References: "Identities types IP address,FQDN/user FQDN and DN and 2023 its usage in preshared key authentication" thread, Jan 2005.) 2025 7.2. Relationship of IKEv2 to RFC4301 2027 The IKEv2 specification refers to [RFC4301], but it never makes clear 2028 what the exact relationship is. 2030 However, there are some requirements in the specification that make 2031 it clear that IKEv2 requires [RFC4301]. In other words, an 2032 implementation that does IPsec processing strictly according to 2033 [RFC2401] cannot be compliant with the IKEv2 specification. 2035 One such example can be found in Section 2.24: "Specifically, tunnel 2036 encapsulators and decapsulators for all tunnel-mode SAs created by 2037 IKEv2 [...] MUST implement the tunnel encapsulation and 2038 decapsulation processing specified in [RFC4301] to prevent discarding 2039 of ECN congestion indications." 2041 Nevertheless, the changes required to existing [RFC2401] 2042 implementations are not very large, especially since supporting many 2043 of the new features (such as Extended Sequence Numbers) is optional. 2045 7.3. Reducing the window size 2047 In IKEv2, the window size is assumed to be a (possibly configurable) 2048 property of a particular implementation, and is not related to 2049 congestion control (unlike the window size in TCP, for instance). 2051 In particular, it is not defined what the responder should do when it 2052 receives a SET_WINDOW_SIZE notification containing a smaller value 2053 than is currently in effect. Thus, there is currently no way to 2054 reduce the window size of an existing IKE_SA. However, when rekeying 2055 an IKE_SA, the new IKE_SA starts with window size 1 until it is 2056 explicitly increased by sending a new SET_WINDOW_SIZE notification. 2058 (References: Tero Kivinen's mail "Comments of 2059 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.) 2061 7.4. Minimum size of nonces 2063 Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen, 2064 MUST be at least 128 bits in size, and MUST be at least half the key 2065 size of the negotiated prf." 2067 However, the initiator chooses the nonce before the outcome of the 2068 negotiation is known. In this case, the nonce has to be long enough 2069 for all the PRFs being proposed. 2071 7.5. Initial zero octets on port 4500 2073 It is not clear whether a peer sending an IKE_SA_INIT request on port 2074 4500 should include the initial four zero octets. Section 2.23 talks 2075 about how to upgrade to tunneling over port 4500 after message 2, but 2076 it does not say what to do if message 1 is sent on port 4500. 2078 IKE MUST listen on port 4500 as well as port 500. 2080 [...] 2082 The IKE initiator MUST check these payloads if present and if 2083 they do not match the addresses in the outer packet MUST tunnel 2084 all future IKE and ESP packets associated with this IKE_SA over 2085 UDP port 4500. 2087 To tunnel IKE packets over UDP port 4500, the IKE header has four 2088 octets of zero prepended and the result immediately follows the 2089 UDP header. [...] 2091 The very beginning of Section 2 says "... though IKE messages may 2092 also be received on UDP port 4500 with a slightly different format 2093 (see section 2.23)." 2095 That "slightly different format" is only described in discussing what 2096 to do after changing to port 4500. However, [RFC3948] shows clearly 2097 the format has the initial zeros even for initiators on port 4500. 2098 Furthermore, without the initial zeros, the processing engine cannot 2099 determine whether the packet is an IKE packet or an ESP packet. 2101 Thus, all packets sent on port 4500 need the four zero prefix; 2102 otherwise, the receiver won't know how to handle them. 2104 7.6. Destination port for NAT traversal 2106 Section 2.23 says that "an IPsec endpoint that discovers a NAT 2107 between it and its correspondent MUST send all subsequent traffic to 2108 and from port 4500". 2110 This sentence is misleading. The peer "outside" the NAT uses source 2111 port 4500 for the traffic it sends, but the destination port is, of 2112 course, taken from packets sent by the peer behind the NAT. This 2113 port number is usually dynamically allocated by the NAT. 2115 7.7. SPI values for messages outside of an IKE_SA 2117 The IKEv2 specification is not quite clear what SPI values should be 2118 used in the IKE header for the small number of notifications that are 2119 allowed to be sent outside of an IKE_SA. Note that such 2120 notifications are explicitly *not* Informational exchanges; Section 2121 1.5 makes it clear that these are one-way messages that must not be 2122 responded to. 2124 There are two cases when such a one-way notification can be sent: 2125 INVALID_IKE_SPI and INVALID_SPI. 2127 In case of INVALID_IKE_SPI, the message sent is a response message, 2128 and Section 2.21 says that "If a response is sent, the response MUST 2129 be sent to the IP address and port from whence it came with the same 2130 IKE SPIs and the Message ID copied." 2132 In case of INVALID_SPI, however, there are no IKE SPI values that 2133 would be meaningful to the recipient of such a notification. Also, 2134 the message sent is now an INFORMATIONAL request. A strict 2135 interpretation of the specification would require the sender to 2136 invent garbage values for the SPI fields. However, we think this was 2137 not the intention, and using zero values is acceptable. 2139 (References: "INVALID_IKE_SPI" thread, June 2005.) 2141 7.8. Protocol ID/SPI fields in Notify payloads 2143 Section 3.10 says that the Protocol ID field in Notify payloads "For 2144 notifications that do not relate to an existing SA, this field MUST 2145 be sent as zero and MUST be ignored on receipt". However, the 2146 specification does not clearly say which notifications are related to 2147 existing SAs and which are not. 2149 Since the main purpose of the Protocol ID field is to specify the 2150 type of the SPI, our interpretation is that the Protocol ID field 2151 should be non-zero only when the SPI field is non-empty. 2153 There are currently only two notifications where this is the case: 2154 INVALID_SELECTORS and REKEY_SA. 2156 7.9. Which message should contain INITIAL_CONTACT 2158 The description of the INITIAL_CONTACT notification in Section 3.10.1 2159 says that "This notification asserts that this IKE_SA is the only 2160 IKE_SA currently active between the authenticated identities". 2161 However, neither Section 2.4 nor 3.10.1 says in which message this 2162 payload should be placed. 2164 The general agreement is that INITIAL_CONTACT is best communicated in 2165 the first IKE_AUTH request, not as a separate exchange afterwards. 2167 (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread, 2168 April 2005. "Initial Contact messages" thread, December 2004. 2169 "IKEv2 and Initial Contact" thread, September 2004 and April 2005.) 2171 7.10. Alignment of payloads 2173 Many IKEv2 payloads contain fields marked as "RESERVED", mostly 2174 because IKEv1 had them, and partly because they make the pictures 2175 easier to draw. In particular, payloads in IKEv2 are not, in 2176 general, aligned to 4-byte boundaries. (Note that payloads were not 2177 aligned to 4-byte boundaries in IKEv1 either.) 2179 (References: "IKEv2: potential 4-byte alignment problem" thread, June 2180 2004.) 2182 7.11. Key length transform attribute 2184 Section 3.3.5 says that "The only algorithms defined in this document 2185 that accept attributes are the AES based encryption, integrity, and 2186 pseudo-random functions, which require a single attribute specifying 2187 key width." 2189 This is incorrect. The AES-based integrity and pseudo-random 2190 functions defined in [IKEv2] always use a 128-bit key. In fact, 2191 there are currently no integrity or PRF algorithms that use the key 2192 length attribute (and we recommend that they should not be defined in 2193 the future either). 2195 For encryption algorithms, the situation is slightly more complex 2196 since there are three different types of algorithms: 2198 o The key length attribute is never used with algorithms that use a 2199 fixed length key, such as DES and IDEA. 2201 o The key length attribute is always included for the currently 2202 defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting 2203 the key length attribute is not allowed; if the proposal does not 2204 contain it, the proposal has to be rejected. 2206 o For other algorithms, the key length attribute can be included but 2207 is not mandatory. These algorithms include, e.g., RC5, CAST and 2208 BLOWFISH. If the key length attribute is not included, the 2209 default value specified in [RFC2451] is used. 2211 7.12. IPsec IANA considerations 2213 There are currently three different IANA registry files that contain 2214 important numbers for IPsec: ikev2-registry, isakmp-registry, and 2215 ipsec-registry. Implementors should note that IKEv2 may use numbers 2216 different from IKEv1 for a particular algorithm. 2218 For instance, an encryption algorithm can have up to three different 2219 numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry, 2220 the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec- 2221 registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier" 2222 isakmp-registry. Although some algorithms have the same number in 2223 all three registries, the registries are not identical. 2225 Similarly, an integrity algorithm can have at least the IKEv2 2226 "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2 2227 "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1 2228 phase 2 ESP "Authentication Algorithm Security Association Attribute" 2229 identifier in isakmp-registry. And there is also the IKEv1 phase 1 2230 "Hash Algorithm" list in ipsec-registry. 2232 This issue needs special care also when writing a specification for 2233 how a new algorithm is used together with IPsec. 2235 7.13. Combining ESP and AH 2237 The IKEv2 specification contains some misleading text about how ESP 2238 and AH can be combined. 2240 IKEv2 is based on [RFC4301] which does not include "SA bundles" that 2241 were part of [RFC2401]. While a single packet can go through IPsec 2242 processing multiple times, each of these passes uses a separate SA, 2243 and the passes are coordinated by the forwarding tables. In IKEv2, 2244 each of these SAs has to be created using a separate CREATE_CHILD_SA 2245 exchange. Thus, the text in Section 2.7 about a single proposal 2246 containing both ESP and AH is incorrect. 2248 Morever, the combination of ESP and AH (between the same endpoints) 2249 become largely obsolete already in 1998 when RFC 2406 was published. 2250 Our recommendation is that IKEv2 implementations should not support 2251 this combination, and implementors should not assume the combination 2252 can be made to work in interoperable manner. 2254 (References: "Rekeying SA bundles" thread, Oct 2005.) 2256 8. Status of the clarifications 2258 This document is work-in-progress, and it contains both relatively 2259 stable and finished parts, and other parts that are incomplete or 2260 even incorrect. To help the reader in deciding how much weight 2261 should be given to each clarification, this section contains our 2262 opinions about which parts we believe to are stable, and which are 2263 likely to change in future versions. 2265 Those clarifications believed to be correct and without controversy 2266 are marked with three asterisks (***); those where the clarification 2267 is known to be incomplete and/or there is disagreement about what the 2268 correct interpretation is are marked with one asterisk (*). The 2269 clarifications marked with two asterisks (**) are somewhere between 2270 the extremes. 2272 2. Creating the IKE_SA 2273 2.1 SPI values in IKE_SA_INIT exchange *** 2274 2.2 Message IDs for IKE_SA_INIT messages *** 2275 2.3 Retransmissions of IKE_SA_INIT requests *** 2276 2.4 Interaction of COOKIE and INVALID_KE_PAYLOAD *** 2277 2.5 Invalid cookies *** 2278 3. Authentication 2279 3.1 Data included in AUTH payload calculation *** 2280 3.2 Hash function for RSA signatures *** 2281 3.3 Encoding method for RSA signatures *** 2282 3.4 Identification type for EAP *** 2283 3.5 Identity for policy lookups when using EAP *** 2284 3.6 (Section removed) 2285 3.7 Certificate encoding types *** 2286 3.8 Shared key authentication and fixed PRF key size *** 2287 3.9 EAP authentication and fixed PRF key size *** 2288 3.10 Matching ID payloads to certificate contents *** 2289 3.11 Message IDs for IKE_AUTH messages *** 2290 4. Creating CHILD_SAs 2291 4.1 Creating SAs with the CREATE_CHILD_SA exchange ** 2292 4.2 Creating an IKE_SA without a CHILD_SA *** 2293 4.3 Diffie-Hellman for first CHILD_SA *** 2294 4.4 Extended Sequence Numbers (ESN) transform *** 2295 4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED *** 2296 4.6 Negotiation of NON_FIRST_FRAGMENTS_ALSO *** 2297 4.7 Semantics of complex traffic selector payloads *** 2298 4.8 ICMP type/code in traffic selector payloads *** 2299 4.9 Mobility header in traffic selector payloads *** 2300 4.10 Narrowing the traffic selectors *** 2301 4.11 SINGLE_PAIR_REQUIRED *** 2302 4.12 Traffic selectors violating own policy *** 2303 5. Rekeying and deleting SAs 2304 5.1 Rekeying SAs with the CREATE_CHILD_SA exchange ** 2305 5.2 Rekeying the IKE_SA vs. reauthentication *** 2306 5.3 SPIs when rekeying the IKE_SA *** 2307 5.4 SPI when rekeying a CHILD_SA *** 2308 5.5 Changing PRFs when rekeying the IKE_SA *** 2309 5.6 Deleting vs. closing SAs *** 2310 5.7 Deleting an SA pair *** 2311 5.8 Deleting an IKE_SA *** 2312 5.9 Who is the original initiator of IKE_SA *** 2313 5.10 (Section removed) 2314 5.11 Comparing nonces *** 2315 5.12 Exchange collisions * 2316 5.13 Diffie-Hellman and rekeying the IKE_SA ** 2317 6. Configuration payloads 2318 6.1 Assigning IP addresses *** 2319 6.2 (Section removed) 2320 6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS *** 2321 6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET *** 2322 6.5 INTERNAL_IP4_NETMASK ** 2323 6.6 Configuration payloads for IPv6 ** 2324 6.7 INTERNAL_IP6_NBNS *** 2325 6.8 INTERNAL_ADDRESS_EXPIRY *** 2326 6.9 Address assignment failures ** 2327 7. Miscellaneous issues 2328 7.1 Matching ID_IPV4_ADDR and ID_IPV6_ADDR *** 2329 7.2 Relationship of IKEv2 to RFC4301 *** 2330 7.3 Reducing the window size *** 2331 7.4 Minimum size of nonces *** 2332 7.5 Initial zero octets on port 4500 *** 2333 7.6 Destination port for NAT traversal *** 2334 7.7 SPI values for messages outside of an IKE_SA *** 2335 7.8 Protocol ID/SPI fields in Notify payloads *** 2336 7.9 Which message should contain INITIAL_CONTACT *** 2337 7.10 Alignment of payloads *** 2338 7.11 Key length transform attribute *** 2339 7.12 IPsec IANA considerations ** 2340 7.13 Combining ESP and AH * 2342 Future versions of this document will, of course, change these 2343 estimates (and changes in both directions are possible, though 2344 hopefully it's more towards higher confidence). 2346 9. Implementation mistakes 2348 Some implementers at the early IKEv2 bakeoffs didn't do everything 2349 correctly. This may seem like an obvious statement, but it is 2350 probably useful to list a few things that were clear in the document 2351 and not needing clarification, that some implementors didn't do. All 2352 of these things caused interoperability problems. 2354 o Some implementations continued to send traffic on a CHILD_SA after 2355 it was rekeyed, even after receiving an DELETE payload. 2357 o After rekeying an IKE_SA, some implementations did not reset their 2358 message counters to zero. One set the counter to 2, another did 2359 not reset the counter at all. 2361 o Some implementations could only handle a single pair of traffic 2362 selectors, or would only process the first pair in the proposal. 2364 o Some implementations responded to a delete request by sending an 2365 empty INFORMATIONAL response, and then initiated their own 2366 INFORMATIONAL exchange with the pair of SAs to delete. 2368 o Although this did not happen at the bakeoff, from the discussion 2369 there, it is clear that some people had not implemented message 2370 window sizes correctly. Some implementations might have sent 2371 messages that did not fit into the responder's message windows, 2372 and some implementations may not have torn down an SA if they did 2373 not ever receive a message that they know they should have. 2375 10. Security considerations 2377 This document does not introduce any new security considerations to 2378 IKEv2. If anything, clarifying complex areas of the specification 2379 can reduce the likelihood of implementation problems that may have 2380 security implications. 2382 11. IANA considerations 2384 This document does not change or create any IANA-registered values. 2386 12. Acknowledgments 2388 This document is mainly based on conversations on the IPsec WG 2389 mailing list. The authors would especially like to thank Bernard 2390 Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont, 2391 Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero Kivinen, Yoav 2392 Nir, Michael Richardson, and Joel Snyder for their contributions. 2394 In addition, the authors would like to thank all the participants of 2395 the first public IKEv2 bakeoff, held in Santa Clara in February 2005, 2396 for their questions and proposed clarifications. 2398 13. References 2400 13.1. Normative References 2402 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 2403 Protocol", RFC 4306, December 2005. 2405 [IKEv2ALG] 2406 Schiller, J., "Cryptographic Algorithms for Use in the 2407 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 2408 December 2005. 2410 [PKCS1v20] 2411 Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 2412 Specifications Version 2.0", RFC 2437, October 1998. 2414 [PKCS1v21] 2415 Jonsson, J. and B. Kaliski, "Public-Key Cryptography 2416 Standards (PKCS) #1: RSA Cryptography Specifications 2417 Version 2.1", RFC 3447, February 2003. 2419 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2420 Internet Protocol", RFC 2401, November 1998. 2422 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2423 Internet Protocol", RFC 4301, December 2005. 2425 13.2. Informative References 2427 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2428 Levkowetz, "Extensible Authentication Protocol (EAP)", 2429 RFC 3748, June 2004. 2431 [HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec", 2432 draft-hoffman-ike-ipsec-hash-use-01 (work in progress), 2433 December 2005. 2435 [IPCPSubnet] 2436 Cisco Systems, Inc., "IPCP Subnet Mask Support 2437 Enhancements", http://www.cisco.com/univercd/cc/td/doc/ 2438 product/software/ios121/121newft/121limit/121dc/121dc3/ 2439 ipcp_msk.htm, January 2003. 2441 [IPv6Addr] 2442 Hinden, R. and S. Deering, "Internet Protocol Version 6 2443 (IPv6) Addressing Architecture", RFC 3513, April 2004. 2445 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2446 in IPv6", RFC 3775, June 2004. 2448 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery 2449 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2451 [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2452 Network Access Identifier", RFC 4282, December 2005. 2454 [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2455 Dial In User Service) Support For Extensible 2456 Authentication Protocol (EAP)", RFC 3579, September 2003. 2458 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2459 "Remote Authentication Dial In User Service (RADIUS)", 2460 RFC 2865, June 2000. 2462 [RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 2463 RFC 3162, August 2001. 2465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2466 Requirement Levels", RFC 2119, March 1997. 2468 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 2469 Algorithms", RFC 2451, November 1998. 2471 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 2472 April 2001. 2474 [RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 2475 Internet Key Exchange Protocol (IKE)", RFC 3664, 2476 January 2004. 2478 [RFC3664bis] 2479 Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the 2480 Internet Key Exchange Protocol (IKE)", 2481 draft-hoffman-rfc3664bis (work in progress), October 2005. 2483 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 2484 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 2485 RFC 3948, January 2005. 2487 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 2488 text messages", RFC 822, August 1982. 2490 [ReAuth] Nir, Y., "Repeated Authentication in IKEv2", 2491 draft-nir-ikev2-auth-lt-03 (work in progress), 2492 November 2005. 2494 [SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T. 2495 Polk, "Simple Certificate Validation Protocol (SCVP)", 2496 draft-ietf-pkix-scvp-21 (work in progress), October 2005. 2498 Appendix A. Exchanges and payloads 2500 This appendix contains a short summary of the IKEv2 exchanges, and 2501 what payloads can appear in which message. This appendix is purely 2502 informative; if it disagrees with the body of this document or the 2503 IKEv2 specification, the other text is considered correct. 2505 Vendor-ID (V) payloads may be included in any place in any message. 2506 This sequence shows what are, in our opinion, the most logical places 2507 for them. 2509 The specification does not say which messages can contain 2510 N(SET_WINDOW_SIZE). It can possibly be included in any message, but 2511 it is not yet shown below. 2513 A.1. IKE_SA_INIT exchange 2515 request --> [N(COOKIE)], 2516 SA, KE, Ni, 2517 [N(NAT_DETECTION_SOURCE_IP)+, 2518 N(NAT_DETECTION_DESTINATION_IP)], 2519 [V+] 2521 normal response <-- SA, KE, Nr, 2522 (no cookie) [N(NAT_DETECTION_SOURCE_IP), 2523 N(NAT_DETECTION_DESTINATION_IP)], 2524 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 2525 [V+] 2527 A.2. IKE_AUTH exchange without EAP 2529 request --> IDi, [CERT+], 2530 [N(INITIAL_CONTACT)], 2531 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 2532 [IDr], 2533 AUTH, 2534 [CP(CFG_REQUEST)], 2535 [N(IPCOMP_SUPPORTED)+], 2536 [N(USE_TRANSPORT_MODE)], 2537 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2538 [N(NON_FIRST_FRAGMENTS_ALSO)], 2539 SA, TSi, TSr, 2540 [V+] 2542 response <-- IDr, [CERT+], 2543 AUTH, 2544 [CP(CFG_REPLY)], 2545 [N(IPCOMP_SUPPORTED)], 2546 [N(USE_TRANSPORT_MODE)], 2547 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2548 [N(NON_FIRST_FRAGMENTS_ALSO)], 2549 SA, TSi, TSr, 2550 [N(ADDITIONAL_TS_POSSIBLE)], 2552 [V+] 2554 A.3. IKE_AUTH exchange with EAP 2556 first request --> IDi, 2557 [N(INITIAL_CONTACT)], 2558 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 2559 [IDr], 2560 [CP(CFG_REQUEST)], 2561 [N(IPCOMP_SUPPORTED)+], 2562 [N(USE_TRANSPORT_MODE)], 2563 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2564 [N(NON_FIRST_FRAGMENTS_ALSO)], 2565 SA, TSi, TSr, 2566 [V+] 2568 first response <-- IDr, [CERT+], AUTH, 2569 EAP, 2570 [V+] 2572 / --> EAP 2573 repeat 1..N times | 2574 \ <-- EAP 2576 last request --> AUTH 2578 last response <-- AUTH, 2579 [CP(CFG_REPLY)], 2580 [N(IPCOMP_SUPPORTED)], 2581 [N(USE_TRANSPORT_MODE)], 2582 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2583 [N(NON_FIRST_FRAGMENTS_ALSO)], 2584 SA, TSi, TSr, 2585 [N(ADDITIONAL_TS_POSSIBLE)], 2586 [V+] 2588 A.4. CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs 2590 request --> [N(REKEY_SA)], 2591 [N(IPCOMP_SUPPORTED)+], 2592 [N(USE_TRANSPORT_MODE)], 2593 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2594 [N(NON_FIRST_FRAGMENTS_ALSO)], 2595 SA, Ni, [KEi], TSi, TSr 2597 response <-- [N(IPCOMP_SUPPORTED)], 2598 [N(USE_TRANSPORT_MODE)], 2599 [N(ESP_TFC_PADDING_NOT_SUPPORTED)], 2600 [N(NON_FIRST_FRAGMENTS_ALSO)], 2601 SA, Nr, [KEr], TSi, TSr, 2602 [N(ADDITIONAL_TS_POSSIBLE)] 2604 A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA 2606 request --> SA, Ni, [KEi] 2608 response <-- SA, Nr, [KEr] 2610 A.6. INFORMATIONAL exchange 2612 request --> [N+], 2613 [D+], 2614 [CP(CFG_REQUEST)] 2616 response <-- [N+], 2617 [D+], 2618 [CP(CFG_REPLY)] 2620 Authors' Addresses 2622 Pasi Eronen 2623 Nokia Research Center 2624 P.O. Box 407 2625 FIN-00045 Nokia Group 2626 Finland 2628 Email: pasi.eronen@nokia.com 2630 Paul Hoffman 2631 VPN Consortium 2632 127 Segre Place 2633 Santa Cruz, CA 95060 2634 USA 2636 Email: paul.hoffman@vpnc.org 2638 Intellectual Property Statement 2640 The IETF takes no position regarding the validity or scope of any 2641 Intellectual Property Rights or other rights that might be claimed to 2642 pertain to the implementation or use of the technology described in 2643 this document or the extent to which any license under such rights 2644 might or might not be available; nor does it represent that it has 2645 made any independent effort to identify any such rights. Information 2646 on the procedures with respect to rights in RFC documents can be 2647 found in BCP 78 and BCP 79. 2649 Copies of IPR disclosures made to the IETF Secretariat and any 2650 assurances of licenses to be made available, or the result of an 2651 attempt made to obtain a general license or permission for the use of 2652 such proprietary rights by implementers or users of this 2653 specification can be obtained from the IETF on-line IPR repository at 2654 http://www.ietf.org/ipr. 2656 The IETF invites any interested party to bring to its attention any 2657 copyrights, patents or patent applications, or other proprietary 2658 rights that may cover technology that may be required to implement 2659 this standard. Please address the information to the IETF at 2660 ietf-ipr@ietf.org. 2662 Disclaimer of Validity 2664 This document and the information contained herein are provided on an 2665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2667 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2668 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2669 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2672 Copyright Statement 2674 Copyright (C) The Internet Society (2006). This document is subject 2675 to the rights, licenses and restrictions contained in BCP 78, and 2676 except as set forth therein, the authors retain all their rights. 2678 Acknowledgment 2680 Funding for the RFC Editor function is currently provided by the 2681 Internet Society.