7 Network Working Group P. Eronen
8 Request for Comments: 4718 Nokia
9 Category: Informational P. Hoffman
14 IKEv2 Clarifications and Implementation Guidelines
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (2006).
28 This document clarifies many areas of the IKEv2 specification. It
29 does not to introduce any changes to the protocol, but rather
30 provides descriptions that are less prone to ambiguous
31 interpretations. The purpose of this document is to encourage the
32 development of interoperable implementations.
58 Eronen & Hoffman Informational [Page 1]
60 RFC 4718 IKEv2 Clarifications October 2006
65 1. Introduction ....................................................4
66 2. Creating the IKE_SA .............................................4
67 2.1. SPI Values in IKE_SA_INIT Exchange .........................4
68 2.2. Message IDs for IKE_SA_INIT Messages .......................5
69 2.3. Retransmissions of IKE_SA_INIT Requests ....................5
70 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
71 2.5. Invalid Cookies ............................................8
72 3. Authentication ..................................................9
73 3.1. Data Included in AUTH Payload Calculation ..................9
74 3.2. Hash Function for RSA Signatures ...........................9
75 3.3. Encoding Method for RSA Signatures ........................10
76 3.4. Identification Type for EAP ...............................11
77 3.5. Identity for Policy Lookups When Using EAP ................11
78 3.6. Certificate Encoding Types ................................12
79 3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
80 3.8. EAP Authentication and Fixed PRF Key Size .................13
81 3.9. Matching ID Payloads to Certificate Contents ..............13
82 3.10. Message IDs for IKE_AUTH Messages ........................14
83 4. Creating CHILD_SAs .............................................14
84 4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
85 4.2. Creating an IKE_SA without a CHILD_SA .....................16
86 4.3. Diffie-Hellman for First CHILD_SA .........................16
87 4.4. Extended Sequence Numbers (ESN) Transform .................17
88 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
89 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
90 4.7. Semantics of Complex Traffic Selector Payloads ............18
91 4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
92 4.9. Mobility Header in Traffic Selector Payloads ..............20
93 4.10. Narrowing the Traffic Selectors ..........................20
94 4.11. SINGLE_PAIR_REQUIRED .....................................21
95 4.12. Traffic Selectors Violating Own Policy ...................21
96 4.13. Traffic Selector Authorization ...........................22
97 5. Rekeying and Deleting SAs ......................................23
98 5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
99 5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
100 5.3. SPIs When Rekeying the IKE_SA .............................25
101 5.4. SPI When Rekeying a CHILD_SA ..............................25
102 5.5. Changing PRFs When Rekeying the IKE_SA ....................26
103 5.6. Deleting vs. Closing SAs ..................................26
104 5.7. Deleting a CHILD_SA Pair ..................................26
105 5.8. Deleting an IKE_SA ........................................27
106 5.9. Who is the original initiator of IKE_SA ...................27
107 5.10. Comparing Nonces .........................................27
108 5.11. Exchange Collisions ......................................28
109 5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
114 Eronen & Hoffman Informational [Page 2]
116 RFC 4718 IKEv2 Clarifications October 2006
119 6. Configuration Payloads .........................................37
120 6.1. Assigning IP Addresses ....................................37
121 6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
122 6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
123 6.4. INTERNAL_IP4_NETMASK ......................................41
124 6.5. Configuration Payloads for IPv6 ...........................42
125 6.6. INTERNAL_IP6_NBNS .........................................43
126 6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
127 6.8. Address Assignment Failures ...............................44
128 7. Miscellaneous Issues ...........................................45
129 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
130 7.2. Relationship of IKEv2 to RFC 4301 .........................45
131 7.3. Reducing the Window Size ..................................46
132 7.4. Minimum Size of Nonces ....................................46
133 7.5. Initial Zero Octets on Port 4500 ..........................46
134 7.6. Destination Port for NAT Traversal ........................47
135 7.7. SPI Values for Messages outside an IKE_SA .................47
136 7.8. Protocol ID/SPI Fields in Notify Payloads .................48
137 7.9. Which message should contain INITIAL_CONTACT ..............48
138 7.10. Alignment of Payloads ....................................48
139 7.11. Key Length Transform Attribute ...........................48
140 7.12. IPsec IANA Considerations ................................49
141 7.13. Combining ESP and AH .....................................50
142 8. Implementation Mistakes ........................................50
143 9. Security Considerations ........................................51
144 10. Acknowledgments ...............................................51
145 11. References ....................................................51
146 11.1. Normative References .....................................51
147 11.2. Informative References ...................................52
148 Appendix A. Exchanges and Payloads ................................54
149 A.1. IKE_SA_INIT Exchange ......................................54
150 A.2. IKE_AUTH Exchange without EAP .............................54
151 A.3. IKE_AUTH Exchange with EAP ................................55
152 A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
153 CHILD_SAs .................................................56
154 A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
155 A.6. INFORMATIONAL Exchange ....................................56
170 Eronen & Hoffman Informational [Page 3]
172 RFC 4718 IKEv2 Clarifications October 2006
177 This document clarifies many areas of the IKEv2 specification that
178 may be difficult to understand to developers not intimately familiar
179 with the specification and its history. The clarifications in this
180 document come from the discussion on the IPsec WG mailing list, from
181 experience in interoperability testing, and from implementation
182 issues that have been brought to the editors' attention.
184 IKEv2/IPsec can be used for several different purposes, including
185 IPsec-based remote access (sometimes called the "road warrior" case),
186 site-to-site virtual private networks (VPNs), and host-to-host
187 protection of application traffic. While this document attempts to
188 consider all of these uses, the remote access scenario has perhaps
189 received more attention here than the other uses.
191 This document does not place any requirements on anyone and does not
192 use [RFC2119] keywords such as "MUST" and "SHOULD", except in
193 quotations from the original IKEv2 documents. The requirements are
194 given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
195 algorithms document [IKEv2ALG].
197 In this document, references to a numbered section (such as "Section
198 2.15") mean that section in [IKEv2]. References to mailing list
199 messages or threads refer to the IPsec WG mailing list at
200 ipsec@ietf.org. Archives of the mailing list can be found at
201 <http://www.ietf.org/mail-archive/web/ipsec/index.html>.
203 2. Creating the IKE_SA
205 2.1. SPI Values in IKE_SA_INIT Exchange
207 Normal IKE messages include the initiator's and responder's Security
208 Parameter Indexes (SPIs), both of which are non-zero, in the IKE
209 header. However, there are some corner cases where the IKEv2
210 specification is not fully consistent about what values should be
213 First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero
214 in any other message" (than the first message of the IKE_SA_INIT
215 exchange). However, the figure in Section 2.6 shows the second
216 IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
219 Since the responder's SPI identifies security-related state held by
220 the responder, and in this case no state is created, sending a zero
221 value seems reasonable.
226 Eronen & Hoffman Informational [Page 4]
228 RFC 4718 IKEv2 Clarifications October 2006
231 Second, in addition to cookies, there are several other cases when
232 the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
233 (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What
234 responder SPI value should be used in the IKE_SA_INIT response in
237 Since the IKE_SA_INIT request always has a zero responder SPI, the
238 value will not be actually used by the initiator. Thus, we think
239 sending a zero value is correct also in this case.
241 If the responder sends a non-zero responder SPI, the initiator should
242 not reject the response only for that reason. However, when retrying
243 the IKE_SA_INIT request, the initiator will use a zero responder SPI,
244 as described in Section 3.1: "Responder's SPI [...] This value MUST
245 be zero in the first message of an IKE Initial Exchange (including
246 repeats of that message including a cookie) [...]". We believe the
247 intent was to cover repeats of that message due to other reasons,
248 such as INVALID_KE_PAYLOAD, as well.
250 (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
253 2.2. Message IDs for IKE_SA_INIT Messages
255 The Message ID for IKE_SA_INIT messages is always zero. This
256 includes retries of the message due to responses such as COOKIE and
259 This is because Message IDs are part of the IKE_SA state, and when
260 the responder replies to IKE_SA_INIT request with N(COOKIE) or
261 N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
263 (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
264 combination" thread, Oct 2004. Tero Kivinen's mail "Comments of
265 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
267 2.3. Retransmissions of IKE_SA_INIT Requests
269 When a responder receives an IKE_SA_INIT request, it has to determine
270 whether the packet is a retransmission belonging to an existing
271 "half-open" IKE_SA (in which case the responder retransmits the same
272 response), or a new request (in which case the responder creates a
273 new IKE_SA and sends a fresh response).
275 The specification does not describe in detail how this determination
276 is done. In particular, it is not sufficient to use the initiator's
277 SPI and/or IP address for this purpose: two different peers behind a
278 single NAT could choose the same initiator SPI (and the probability
282 Eronen & Hoffman Informational [Page 5]
284 RFC 4718 IKEv2 Clarifications October 2006
287 of this happening is not necessarily small, since IKEv2 does not
288 require SPIs to be chosen randomly). Instead, the responder should
289 do the IKE_SA lookup using the whole packet or its hash (or at the
290 minimum, the Ni payload which is always chosen randomly).
292 For all other packets than IKE_SA_INIT requests, looking up right
293 IKE_SA is of course done based on the recipient's SPI (either the
294 initiator or responder SPI depending on the value of the Initiator
295 bit in the IKE header).
297 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD
299 There are two common reasons why the initiator may have to retry the
300 IKE_SA_INIT exchange: the responder requests a cookie or wants a
301 different Diffie-Hellman group than was included in the KEi payload.
302 Both of these cases are quite simple alone, but it is not totally
303 obvious what happens when they occur at the same time, that is, the
304 IKE_SA_INIT exchange is retried several times.
306 The main question seems to be the following: if the initiator
307 receives a cookie from the responder, should it include the cookie in
308 only the next retry of the IKE_SA_INIT request, or in all subsequent
309 retries as well? Section 3.10.1 says that:
311 "This notification MUST be included in an IKE_SA_INIT request
312 retry if a COOKIE notification was included in the initial
315 This could be interpreted as saying that when a cookie is received in
316 the initial response, it is included in all retries. On the other
317 hand, Section 2.6 says that:
319 "Initiators who receive such responses MUST retry the
320 IKE_SA_INIT with a Notify payload of type COOKIE containing
321 the responder supplied cookie data as the first payload and
322 all other payloads unchanged."
324 Including the same cookie in later retries makes sense only if the
325 "all other payloads unchanged" restriction applies only to the first
326 retry, but not to subsequent retries.
328 It seems that both interpretations can peacefully coexist. If the
329 initiator includes the cookie only in the next retry, one additional
330 roundtrip may be needed in some cases:
338 Eronen & Hoffman Informational [Page 6]
340 RFC 4718 IKEv2 Clarifications October 2006
344 ----------- -----------
345 HDR(A,0), SAi1, KEi, Ni -->
346 <-- HDR(A,0), N(COOKIE)
347 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
348 <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
349 HDR(A,0), SAi1, KEi', Ni -->
350 <-- HDR(A,0), N(COOKIE')
351 HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
352 <-- HDR(A,B), SAr1, KEr, Nr
354 An additional roundtrip is needed also if the initiator includes the
355 cookie in all retries, but the responder does not support this
356 functionality. For instance, if the responder includes the SAi1 and
357 KEi payloads in cookie calculation, it will reject the request by
358 sending a new cookie (see also Section 2.5 of this document for more
359 text about invalid cookies):
363 ----------- -----------
364 HDR(A,0), SAi1, KEi, Ni -->
365 <-- HDR(A,0), N(COOKIE)
366 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
367 <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
368 HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
369 <-- HDR(A,0), N(COOKIE')
370 HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
371 <-- HDR(A,B), SAr1, KEr, Nr
373 If both peers support including the cookie in all retries, a slightly
374 shorter exchange can happen:
377 ----------- -----------
378 HDR(A,0), SAi1, KEi, Ni -->
379 <-- HDR(A,0), N(COOKIE)
380 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
381 <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
382 HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
383 <-- HDR(A,B), SAr1, KEr, Nr
385 This document recommends that implementations should support this
386 shorter exchange, but it must not be assumed the other peer also
387 supports the shorter exchange.
394 Eronen & Hoffman Informational [Page 7]
396 RFC 4718 IKEv2 Clarifications October 2006
399 In theory, even this exchange has one unnecessary roundtrip, as both
400 the cookie and Diffie-Hellman group could be checked at the same
404 ----------- -----------
405 HDR(A,0), SAi1, KEi, Ni -->
406 <-- HDR(A,0), N(COOKIE),
407 N(INVALID_KE_PAYLOAD)
408 HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
409 <-- HDR(A,B), SAr1, KEr, Nr
411 However, it is clear that this case is not allowed by the text in
412 Section 2.6, since "all other payloads" clearly includes the KEi
415 (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
420 There has been some confusion what should be done when an IKE_SA_INIT
421 request containing an invalid cookie is received ("invalid" in the
422 sense that its contents do not match the value expected by the
425 The correct action is to ignore the cookie and process the message as
426 if no cookie had been included (usually this means sending a response
427 containing a new cookie). This is shown in Section 2.6 when it says
428 "The responder in that case MAY reject the message by sending another
429 response with a new cookie [...]".
431 Other possible actions, such as ignoring the whole request (or even
432 all requests from this IP address for some time), create strange
433 failure modes even in the absence of any malicious attackers and do
434 not provide any additional protection against DoS attacks.
436 (References: "Invalid Cookie" thread, Sep-Oct 2005.)
450 Eronen & Hoffman Informational [Page 8]
452 RFC 4718 IKEv2 Clarifications October 2006
457 3.1. Data Included in AUTH Payload Calculation
459 Section 2.15 describes how the AUTH payloads are calculated; this
460 calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
461 text describes the method in words, but does not give clear
462 definitions of what is signed or MACed (i.e., protected with a
463 message authentication code).
465 The initiator's signed octets can be described as:
467 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
468 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
469 RealIKEHDR = SPIi | SPIr | . . . | Length
470 RealMessage1 = RealIKEHDR | RestOfMessage1
471 NonceRPayload = PayloadHeader | NonceRData
472 InitiatorIDPayload = PayloadHeader | RestOfIDPayload
473 RestOfInitIDPayload = IDType | RESERVED | InitIDData
474 MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
476 The responder's signed octets can be described as:
478 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
479 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
480 RealIKEHDR = SPIi | SPIr | . . . | Length
481 RealMessage2 = RealIKEHDR | RestOfMessage2
482 NonceIPayload = PayloadHeader | NonceIData
483 ResponderIDPayload = PayloadHeader | RestOfIDPayload
484 RestOfRespIDPayload = IDType | RESERVED | InitIDData
485 MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
487 3.2. Hash Function for RSA Signatures
489 Section 3.8 says that RSA digital signature is "Computed as specified
490 in section 2.15 using an RSA private key over a PKCS#1 padded hash."
492 Unlike IKEv1, IKEv2 does not negotiate a hash function for the
493 IKE_SA. The algorithm for signatures is selected by the signing
494 party who, in general, may not know beforehand what algorithms the
495 verifying party supports. Furthermore, [IKEv2ALG] does not say what
496 algorithms implementations are required or recommended to support.
497 This clearly has a potential for causing interoperability problems,
498 since authentication will fail if the signing party selects an
499 algorithm that is not supported by the verifying party, or not
500 acceptable according to the verifying party's policy.
506 Eronen & Hoffman Informational [Page 9]
508 RFC 4718 IKEv2 Clarifications October 2006
511 This document recommends that all implementations support SHA-1 and
512 use SHA-1 as the default hash function when generating the
513 signatures, unless there are good reasons (such as explicit manual
514 configuration) to believe that the peer supports something else.
516 Note that hash function collision attacks are not important for the
517 AUTH payloads, since they are not intended for third-party
518 verification, and the data includes fresh nonces. See [HashUse] for
519 more discussion about hash function attacks and IPsec.
521 Another reasonable choice would be to use the hash function that was
522 used by the CA when signing the peer certificate. However, this does
523 not guarantee that the IKEv2 peer would be able to validate the AUTH
524 payload, because the same code might not be used to validate
525 certificate signatures and IKEv2 message signatures, and these two
526 routines may support a different set of hash algorithms. The peer
527 could be configured with a fingerprint of the certificate, or
528 certificate validation could be performed by an external entity using
529 [SCVP]. Furthermore, not all CERT payloads types include a
530 signature, and the certificate could be signed with some algorithm
533 Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
534 signature encoding method (see next section for details), which
535 includes the algorithm identifier for the hash algorithm. Thus, when
536 the verifying party receives the AUTH payload it can at least
537 determine which hash function was used.
539 (References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's
540 reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft
541 of IKEv2.1" thread, Dec 2005/Jan 2006.)
543 3.3. Encoding Method for RSA Signatures
545 Section 3.8 says that the RSA digital signature is "Computed as
546 specified in section 2.15 using an RSA private key over a PKCS#1
549 The PKCS#1 specification [PKCS1v21] defines two different encoding
550 methods (ways of "padding the hash") for signatures. However, the
551 Internet-Draft approved by the IESG had a reference to the older
552 PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method
553 for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
562 Eronen & Hoffman Informational [Page 10]
564 RFC 4718 IKEv2 Clarifications October 2006
567 Note that this encoding method is different from the encoding method
568 used in IKEv1. If future revisions of IKEv2 provide support for
569 other encoding methods (such as EMSA-PSS), they will be given new
572 (References: Pasi Eronen's mail "RE:", 2005-01-04.)
574 3.4. Identification Type for EAP
576 Section 3.5 defines several different types for identification
577 payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
578 EAP [EAP] does not mandate the use of any particular type of
579 identifier, but often EAP is used with Network Access Identifiers
580 (NAIs) defined in [NAI]. Although NAIs look a bit like email
581 addresses (e.g., "joe@example.com"), the syntax is not exactly the
582 same as the syntax of email address in [RFC822]. This raises the
583 question of which identification type should be used.
585 This document recommends that ID_RFC822_ADDR identification type is
586 used for those NAIs that include the realm component. Therefore,
587 responder implementations should not attempt to verify that the
588 contents actually conform to the exact syntax given in [RFC822] or
589 [RFC2822], but instead should accept any reasonable looking NAI.
591 For NAIs that do not include the realm component, this document
592 recommends using the ID_KEY_ID identification type.
594 (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
595 identifier issue with EAP" threads, Aug 2004.)
597 3.5. Identity for Policy Lookups When Using EAP
599 When the initiator authentication uses EAP, it is possible that the
600 contents of the IDi payload is used only for AAA routing purposes and
601 selecting which EAP method to use. This value may be different from
602 the identity authenticated by the EAP method (see [EAP], Sections 5.1
605 It is important that policy lookups and access control decisions use
606 the actual authenticated identity. Often the EAP server is
607 implemented in a separate AAA server that communicates with the IKEv2
608 responder using, e.g., RADIUS [RADEAP]. In this case, the
609 authenticated identity has to be sent from the AAA server to the
612 (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2",
613 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748,
618 Eronen & Hoffman Informational [Page 11]
620 RFC 4718 IKEv2 Clarifications October 2006
623 3.6. Certificate Encoding Types
625 Section 3.6 defines a total of twelve different certificate encoding
626 types, and continues that "Specific syntax is for some of the
627 certificate type codes above is not defined in this document."
628 However, the text does not provide references to other documents that
629 would contain information about the exact contents and use of those
632 Without this information, it is not possible to develop interoperable
633 implementations. Therefore, this document recommends that the
634 following certificate encoding values should not be used before new
635 specifications that specify their use are available.
637 PKCS #7 wrapped X.509 certificate 1
643 This document recommends that most implementations should use only
644 those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
645 "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
646 URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
649 Furthermore, Section 3.7 says that the "Certificate Encoding" field
650 for the Certificate Request payload uses the same values as for
651 Certificate payload. However, the contents of the "Certification
652 Authority" field are defined only for X.509 certificates (presumably
653 covering at least types 4, 10, 12, and 13). This document recommends
654 that other values should not be used before new specifications that
655 specify their use are available.
657 The "Raw RSA Key" type needs one additional clarification. Section
658 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is
659 a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
661 3.7. Shared Key Authentication and Fixed PRF Key Size
663 Section 2.15 says that "If the negotiated prf takes a fixed-size key,
664 the shared secret MUST be of that fixed size". This statement is
665 correct: the shared secret must be of the correct size. If it is
666 not, it cannot be used; there is no padding, truncation, or other
667 processing involved to force it to that correct size.
674 Eronen & Hoffman Informational [Page 12]
676 RFC 4718 IKEv2 Clarifications October 2006
679 This requirement means that it is difficult to use these pseudo-
680 random functions (PRFs) with shared key authentication. The authors
681 think this part of the specification was very poorly thought out, and
682 using PRFs with a fixed key size is likely to result in
683 interoperability problems. Thus, we recommend that such PRFs should
684 not be used with shared key authentication. PRF_AES128_XCBC
685 [RFC3664] originally used fixed key sizes; that RFC has been updated
686 to handle variable key sizes in [RFC4434].
688 Note that Section 2.13 also contains text that is related to PRFs
689 with fixed key size: "When the key for the prf function has fixed
690 length, the data provided as a key is truncated or padded with zeros
691 as necessary unless exceptional processing is explained following the
692 formula". However, this text applies only to the prf+ construction,
693 so it does not contradict the text in Section 2.15.
695 (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
696 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question
697 about PRFs with fixed size key", Jan 2005.)
699 3.8. EAP Authentication and Fixed PRF Key Size
701 As described in the previous section, PRFs with a fixed key size
702 require a shared secret of exactly that size. This restriction
703 applies also to EAP authentication. For instance, a PRF that
704 requires a 128-bit key cannot be used with EAP since [EAP] specifies
705 that the MSK is at least 512 bits long.
707 (References: Thread "Question about PRFs with fixed size key", Jan
710 3.9. Matching ID Payloads to Certificate Contents
712 In IKEv1, there was some confusion about whether or not the
713 identities in certificates used to authenticate IKE were required to
714 match the contents of the ID payloads. The PKI4IPsec Working Group
715 produced the document [PKI4IPsec] which covers this topic in much
716 more detail. However, Section 3.5 of [IKEv2] explicitly says that
717 the ID payload "does not necessarily have to match anything in the
730 Eronen & Hoffman Informational [Page 13]
732 RFC 4718 IKEv2 Clarifications October 2006
735 3.10. Message IDs for IKE_AUTH Messages
737 According to Section 2.2, "The IKE_SA initial setup messages will
738 always be numbered 0 and 1." That is true when the IKE_AUTH exchange
739 does not use EAP. When EAP is used, each pair of messages has their
740 message numbers incremented. The first pair of AUTH messages will
741 have an ID of 1, the second will be 2, and so on.
743 (References: "Question about MsgID in AUTH exchange" thread, April
746 4. Creating CHILD_SAs
748 4.1. Creating SAs with the CREATE_CHILD_SA Exchange
750 Section 1.3's organization does not lead to clear understanding of
751 what is needed in which environment. The section can be reorganized
752 with subsections for each use of the CREATE_CHILD_SA exchange
753 (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
755 The new Section 1.3 with subsections and the above changes might look
758 NEW-1.3 The CREATE_CHILD_SA Exchange
760 The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
761 to rekey both IKE_SAs and CHILD_SAs. This exchange consists of
762 a single request/response pair, and some of its function was
763 referred to as a phase 2 exchange in IKEv1. It MAY be initiated
764 by either end of the IKE_SA after the initial exchanges are
767 All messages following the initial exchange are
768 cryptographically protected using the cryptographic algorithms
769 and keys negotiated in the first two messages of the IKE
770 exchange. These subsequent messages use the syntax of the
771 Encrypted Payload described in section 3.14. All subsequent
772 messages include an Encrypted Payload, even if they are referred
773 to in the text as "empty".
775 The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
776 This section describes the first part of rekeying, the creation
777 of new SAs; Section 2.8 covers the mechanics of rekeying,
778 including moving traffic from old to new SAs and the deletion of
779 the old SAs. The two sections must be read together to
780 understand the entire process of rekeying.
786 Eronen & Hoffman Informational [Page 14]
788 RFC 4718 IKEv2 Clarifications October 2006
791 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
792 this section the term initiator refers to the endpoint
793 initiating this exchange. An implementation MAY refuse all
794 CREATE_CHILD_SA requests within an IKE_SA.
796 The CREATE_CHILD_SA request MAY optionally contain a KE payload
797 for an additional Diffie-Hellman exchange to enable stronger
798 guarantees of forward secrecy for the CHILD_SA or IKE_SA. The
799 keying material for the SA is a function of SK_d established
800 during the establishment of the IKE_SA, the nonces exchanged
801 during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
802 value (if KE payloads are included in the CREATE_CHILD_SA
803 exchange). The details are described in sections 2.17 and 2.18.
805 If a CREATE_CHILD_SA exchange includes a KEi payload, at least
806 one of the SA offers MUST include the Diffie-Hellman group of
807 the KEi. The Diffie-Hellman group of the KEi MUST be an element
808 of the group the initiator expects the responder to accept
809 (additional Diffie-Hellman groups can be proposed). If the
810 responder rejects the Diffie-Hellman group of the KEi payload,
811 the responder MUST reject the request and indicate its preferred
812 Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
813 payload. In the case of such a rejection, the CREATE_CHILD_SA
814 exchange fails, and the initiator SHOULD retry the exchange with
815 a Diffie-Hellman proposal and KEi in the group that the
816 responder gave in the INVALID_KE_PAYLOAD.
818 NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
820 A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
821 The CREATE_CHILD_SA request for creating a new CHILD_SA is:
824 ----------- -----------
825 HDR, SK {[N+], SA, Ni, [KEi],
828 The initiator sends SA offer(s) in the SA payload, a nonce in
829 the Ni payload, optionally a Diffie-Hellman value in the KEi
830 payload, and the proposed traffic selectors for the proposed
831 CHILD_SA in the TSi and TSr payloads. The request can also
832 contain Notify payloads that specify additional details for the
833 CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
834 ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
842 Eronen & Hoffman Informational [Page 15]
844 RFC 4718 IKEv2 Clarifications October 2006
847 The CREATE_CHILD_SA response for creating a new CHILD_SA is:
849 <-- HDR, SK {[N+], SA, Nr,
852 The responder replies with the accepted offer in an SA payload,
853 and a Diffie-Hellman value in the KEr payload if KEi was
854 included in the request and the selected cryptographic suite
855 includes that group. As with the request, optional Notification
856 payloads can specify additional details for the CHILD_SA.
858 The traffic selectors for traffic to be sent on that SA are
859 specified in the TS payloads in the response, which may be a
860 subset of what the initiator of the CHILD_SA proposed.
862 The text about rekeying SAs can be found in Section 5.1 of this
865 4.2. Creating an IKE_SA without a CHILD_SA
867 CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
868 exchange, or using a separate CREATE_CHILD_SA exchange. The
869 specification is not clear about what happens if creating the
870 CHILD_SA during the IKE_AUTH exchange fails for some reason.
872 Our recommendation in this situation is that the IKE_SA is created as
873 usual. This is also in line with how the CREATE_CHILD_SA exchange
874 works: a failure to create a CHILD_SA does not close the IKE_SA.
876 The list of responses in the IKE_AUTH exchange that do not prevent an
877 IKE_SA from being set up include at least the following:
878 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
879 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
881 (References: "Questions about internal address" thread, April 2005.)
883 4.3. Diffie-Hellman for First CHILD_SA
885 Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
886 Ni/Nr payloads. This implies that the SA payload in IKE_AUTH
887 exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
888 any other value than NONE. Implementations should probably leave the
889 transform out entirely in this case.
898 Eronen & Hoffman Informational [Page 16]
900 RFC 4718 IKEv2 Clarifications October 2006
903 4.4. Extended Sequence Numbers (ESN) Transform
905 The description of the ESN transform in Section 3.3 has be proved
906 difficult to understand. The ESN transform has the following
909 o A proposal containing one ESN transform with value 0 means "do not
910 use extended sequence numbers".
912 o A proposal containing one ESN transform with value 1 means "use
913 extended sequence numbers".
915 o A proposal containing two ESN transforms with values 0 and 1 means
916 "I support both normal and extended sequence numbers, you choose".
917 (Obviously this case is only allowed in requests; the response
918 will contain only one ESN transform.)
920 In most cases, the exchange initiator will include either the first
921 or third alternative in its SA payload. The second alternative is
922 rarely useful for the initiator: it means that using normal sequence
923 numbers is not acceptable (so if the responder does not support ESNs,
924 the exchange will fail with NO_PROPOSAL_CHOSEN).
926 Note that including the ESN transform is mandatory when creating
927 ESP/AH SAs (it was optional in earlier drafts of the IKEv2
930 (References: "Technical change needed to IKEv2 before publication",
931 "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
932 and "Results of straw poll regarding: IKEv2 interoperability issue"
933 threads, March-April 2005.)
935 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED
937 The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
938 Section 3.10.1 says that "This notification asserts that the sending
939 endpoint will NOT accept packets that contain Flow Confidentiality
942 However, the text does not say in which messages this notification
943 should be included, or whether the scope of this notification is a
944 single CHILD_SA or all CHILD_SAs of the peer.
946 Our interpretation is that the scope is a single CHILD_SA, and thus
947 this notification is included in messages containing an SA payload
948 negotiating a CHILD_SA. If neither endpoint accepts TFC padding,
949 this notification will be included in both the request proposing an
950 SA and the response accepting it. If this notification is included
954 Eronen & Hoffman Informational [Page 17]
956 RFC 4718 IKEv2 Clarifications October 2006
959 in only one of the messages, TFC padding can still be sent in one
962 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO
964 NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
965 simply as "Used for fragmentation control. See [RFC4301] for
968 [RFC4301] says "Implementations that will transmit non-initial
969 fragments on a tunnel mode SA that makes use of non-trivial port (or
970 ICMP type/code or MH type) selectors MUST notify a peer via the IKE
971 NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this
972 proposal if it will not accept non-initial fragments in this context.
973 If an implementation does not successfully negotiate transmission of
974 non-initial fragments for such an SA, it MUST NOT send such fragments
977 However, it is not clear exactly how the negotiation works. Our
978 interpretation is that the negotiation works the same way as for
979 IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
980 is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
981 in both the request proposing an SA and the response accepting it.
982 In other words, if the peer "rejects this proposal", it only omits
983 NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
984 reject the whole CHILD_SA creation.
986 4.7. Semantics of Complex Traffic Selector Payloads
988 As described in Section 3.13, the TSi/TSr payloads can include one or
989 more individual traffic selectors.
991 There is no requirement that TSi and TSr contain the same number of
992 individual traffic selectors. Thus, they are interpreted as follows:
993 a packet matches a given TSi/TSr if it matches at least one of the
994 individual selectors in TSi, and at least one of the individual
997 For instance, the following traffic selectors:
999 TSi = ((17, 100, 192.0.1.66-192.0.1.66),
1000 (17, 200, 192.0.1.66-192.0.1.66))
1001 TSr = ((17, 300, 0.0.0.0-255.255.255.255),
1002 (17, 400, 0.0.0.0-255.255.255.255))
1004 would match UDP packets from 192.0.1.66 to anywhere, with any of the
1005 four combinations of source/destination ports (100,300), (100,400),
1006 (200,300), and (200, 400).
1010 Eronen & Hoffman Informational [Page 18]
1012 RFC 4718 IKEv2 Clarifications October 2006
1015 This implies that some types of policies may require several CHILD_SA
1016 pairs. For instance, a policy matching only source/destination ports
1017 (100,300) and (200,400), but not the other two combinations, cannot
1018 be negotiated as a single CHILD_SA pair using IKEv2.
1020 (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
1022 4.8. ICMP Type/Code in Traffic Selector Payloads
1024 The traffic selector types 7 and 8 can also refer to ICMP type and
1025 code fields. As described in Section 3.13.1, "For the ICMP protocol,
1026 the two one-octet fields Type and Code are treated as a single 16-bit
1027 integer (with Type in the most significant eight bits and Code in the
1028 least significant eight bits) port number for the purposes of
1029 filtering based on this field."
1031 Since ICMP packets do not have separate source and destination port
1032 fields, there is some room for confusion what exactly the four TS
1033 payloads (two in the request, two in the response, each containing
1034 both start and end port fields) should contain.
1036 The answer to this question can be found from [RFC4301] Section
1039 To give a concrete example, if a host at 192.0.1.234 wants to create
1040 a transport mode SA for sending "Destination Unreachable" packets
1041 (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
1042 over this SA pair, the CREATE_CHILD_SA exchange would look like this:
1045 ----------- -----------
1046 HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
1047 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1048 TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
1050 <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
1051 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1052 TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
1054 Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
1055 created in this case, even though the second SA is never used for
1058 An exchange creating an SA pair that can be used both for sending and
1059 receiving "Destination Unreachable" places the same value in all the
1066 Eronen & Hoffman Informational [Page 19]
1068 RFC 4718 IKEv2 Clarifications October 2006
1072 ----------- -----------
1073 HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
1074 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1075 TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
1077 <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
1078 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1079 TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
1081 (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
1083 4.9. Mobility Header in Traffic Selector Payloads
1085 Traffic selectors can use IP Protocol ID 135 to match the IPv6
1086 mobility header [MIPv6]. However, the IKEv2 specification does not
1087 define how to represent the "MH Type" field in traffic selectors.
1089 At some point, it was expected that this will be defined in a
1090 separate document later. However, [RFC4301] says that "For IKE, the
1091 IPv6 mobility header message type (MH type) is placed in the most
1092 significant eight bits of the 16 bit local "port" selector". The
1093 direction semantics of TSi/TSr port fields are the same as for ICMP
1094 and are described in the previous section.
1096 (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
1097 message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2"
1100 4.10. Narrowing the Traffic Selectors
1102 Section 2.9 describes how traffic selectors are negotiated when
1103 creating a CHILD_SA. A more concise summary of the narrowing process
1106 o If the responder's policy does not allow any part of the traffic
1107 covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
1109 o If the responder's policy allows the entire set of traffic covered
1110 by TSi/TSr, no narrowing is necessary, and the responder can
1111 return the same TSi/TSr values.
1113 o Otherwise, narrowing is needed. If the responder's policy allows
1114 all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
1115 in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
1116 acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
1122 Eronen & Hoffman Informational [Page 20]
1124 RFC 4718 IKEv2 Clarifications October 2006
1127 o If the responder's policy does not allow all traffic covered by
1128 TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
1129 an acceptable subset of TSi/TSr.
1131 In the last two cases, there may be several subsets that are
1132 acceptable (but their union is not); in this case, the responder
1133 arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
1134 notification in the response.
1136 4.11. SINGLE_PAIR_REQUIRED
1138 The description of the SINGLE_PAIR_REQUIRED notify payload in
1139 Sections 2.9 and 3.10.1 is not fully consistent.
1141 We do not attempt to describe this payload in this document either,
1142 since it is expected that most implementations will not have policies
1143 that require separate SAs for each address pair.
1145 Thus, if only some part (or parts) of the TSi/TSr proposed by the
1146 initiator is (are) acceptable to the responder, most responders
1147 should simply narrow TSi/TSr to an acceptable subset (as described in
1148 the last two paragraphs of Section 2.9), rather than use
1149 SINGLE_PAIR_REQUIRED.
1151 4.12. Traffic Selectors Violating Own Policy
1153 Section 2.9 describes traffic selector negotiation in great detail.
1154 One aspect of this negotiation that may need some clarification is
1155 that when creating a new SA, the initiator should not propose traffic
1156 selectors that violate its own policy. If this rule is not followed,
1157 valid traffic may be dropped.
1159 This is best illustrated by an example. Suppose that host A has a
1160 policy whose effect is that traffic to 192.0.1.66 is sent via host B
1161 encrypted using Advanced Encryption Standard (AES), and traffic to
1162 all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
1163 using Triple Data Encryption Standard (3DES). Suppose also that host
1164 B accepts any combination of AES and 3DES.
1166 If host A now proposes an SA that uses 3DES, and includes TSr
1167 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
1168 B. Now, host B can also use this SA to send traffic from 192.0.1.66,
1169 but those packets will be dropped by A since it requires the use of
1170 AES for those traffic. Even if host A creates a new SA only for
1171 192.0.1.66 that uses AES, host B may freely continue to use the first
1172 SA for the traffic. In this situation, when proposing the SA, host A
1173 should have followed its own policy, and included a TSr containing
1174 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
1178 Eronen & Hoffman Informational [Page 21]
1180 RFC 4718 IKEv2 Clarifications October 2006
1183 In general, if (1) the initiator makes a proposal "for traffic X
1184 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
1185 does not actually accept traffic X' with SA, and (3) the initiator
1186 would be willing to accept traffic X' with some SA' (!=SA), valid
1187 traffic can be unnecessarily dropped since the responder can apply
1188 either SA or SA' to traffic X'.
1190 (References: "Question about "narrowing" ..." thread, Feb 2005.
1191 "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
1192 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
1193 negotiation examples", 2004-08-08.)
1195 4.13. Traffic Selector Authorization
1197 IKEv2 relies on information in the Peer Authorization Database (PAD)
1198 when determining what kind of IPsec SAs a peer is allowed to create.
1199 This process is described in [RFC4301] Section 4.4.3. When a peer
1200 requests the creation of an IPsec SA with some traffic selectors, the
1201 PAD must contain "Child SA Authorization Data" linking the identity
1202 authenticated by IKEv2 and the addresses permitted for traffic
1205 For example, the PAD might be configured so that authenticated
1206 identity "sgw23.example.com" is allowed to create IPsec SAs for
1207 192.0.2.0/24, meaning this security gateway is a valid
1208 "representative" for these addresses. Host-to-host IPsec requires
1209 similar entries, linking, for example, "fooserver4.example.com" with
1210 192.0.1.66/32, meaning this identity a valid "owner" or
1211 "representative" of the address in question.
1213 As noted in [RFC4301], "It is necessary to impose these constraints
1214 on creation of child SAs to prevent an authenticated peer from
1215 spoofing IDs associated with other, legitimate peers." In the
1216 example given above, a correct configuration of the PAD prevents
1217 sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents
1218 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
1220 It is important to note that simply sending IKEv2 packets using some
1221 particular address does not imply a permission to create IPsec SAs
1222 with that address in the traffic selectors. For example, even if
1223 sgw23 would be able to spoof its IP address as 192.0.1.66, it could
1224 not create IPsec SAs matching fooserver4's traffic.
1226 The IKEv2 specification does not specify how exactly IP address
1227 assignment using configuration payloads interacts with the PAD. Our
1228 interpretation is that when a security gateway assigns an address
1234 Eronen & Hoffman Informational [Page 22]
1236 RFC 4718 IKEv2 Clarifications October 2006
1239 using configuration payloads, it also creates a temporary PAD entry
1240 linking the authenticated peer identity and the newly allocated inner
1243 It has been recognized that configuring the PAD correctly may be
1244 difficult in some environments. For instance, if IPsec is used
1245 between a pair of hosts whose addresses are allocated dynamically
1246 using Dynamic Host Configuration Protocol (DHCP), it is extremely
1247 difficult to ensure that the PAD specifies the correct "owner" for
1248 each IP address. This would require a mechanism to securely convey
1249 address assignments from the DHCP server and link them to identities
1250 authenticated using IKEv2.
1252 Due to this limitation, some vendors have been known to configure
1253 their PADs to allow an authenticated peer to create IPsec SAs with
1254 traffic selectors containing the same address that was used for the
1255 IKEv2 packets. In environments where IP spoofing is possible (i.e.,
1256 almost everywhere) this essentially allows any peer to create IPsec
1257 SAs with any traffic selectors. This is not an appropriate or secure
1258 configuration in most circumstances. See [Aura05] for an extensive
1259 discussion about this issue, and the limitations of host-to-host
1262 5. Rekeying and Deleting SAs
1264 5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange
1266 Continued from Section 4.1 of this document.
1268 NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
1270 The CREATE_CHILD_SA request for rekeying an IKE_SA is:
1273 ----------- -----------
1274 HDR, SK {SA, Ni, [KEi]} -->
1276 The initiator sends SA offer(s) in the SA payload, a nonce in
1277 the Ni payload, and optionally a Diffie-Hellman value in the KEi
1280 The CREATE_CHILD_SA response for rekeying an IKE_SA is:
1282 <-- HDR, SK {SA, Nr, [KEr]}
1290 Eronen & Hoffman Informational [Page 23]
1292 RFC 4718 IKEv2 Clarifications October 2006
1295 The responder replies (using the same Message ID to respond)
1296 with the accepted offer in an SA payload, a nonce in the Nr
1297 payload, and, optionally, a Diffie-Hellman value in the KEr
1300 The new IKE_SA has its message counters set to 0, regardless of
1301 what they were in the earlier IKE_SA. The window size starts at
1302 1 for any new IKE_SA. The new initiator and responder SPIs are
1303 supplied in the SPI fields of the SA payloads.
1305 NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
1307 The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
1310 ----------- -----------
1311 HDR, SK {N(REKEY_SA), [N+], SA,
1312 Ni, [KEi], TSi, TSr} -->
1314 The leading Notify payload of type REKEY_SA identifies the
1315 CHILD_SA being rekeyed, and it contains the SPI that the initiator
1316 expects in the headers of inbound packets. In addition, the
1317 initiator sends SA offer(s) in the SA payload, a nonce in the Ni
1318 payload, optionally a Diffie-Hellman value in the KEi payload,
1319 and the proposed traffic selectors in the TSi and TSr payloads.
1320 The request can also contain Notify payloads that specify
1321 additional details for the CHILD_SA.
1323 The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
1325 <-- HDR, SK {[N+], SA, Nr,
1328 The responder replies with the accepted offer in an SA payload,
1329 and a Diffie-Hellman value in the KEr payload if KEi was
1330 included in the request and the selected cryptographic suite
1331 includes that group.
1333 The traffic selectors for traffic to be sent on that SA are
1334 specified in the TS payloads in the response, which may be a
1335 subset of what the initiator of the CHILD_SA proposed.
1337 5.2. Rekeying the IKE_SA vs. Reauthentication
1339 Rekeying the IKE_SA and reauthentication are different concepts in
1340 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
1341 resets the Message ID counters, but it does not authenticate the
1342 parties again (no AUTH or EAP payloads are involved).
1346 Eronen & Hoffman Informational [Page 24]
1348 RFC 4718 IKEv2 Clarifications October 2006
1351 While rekeying the IKE_SA may be important in some environments,
1352 reauthentication (the verification that the parties still have access
1353 to the long-term credentials) is often more important.
1355 IKEv2 does not have any special support for reauthentication.
1356 Reauthentication is done by creating a new IKE_SA from scratch (using
1357 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
1358 payloads), creating new CHILD_SAs within the new IKE_SA (without
1359 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
1360 deletes the old CHILD_SAs as well).
1362 This means that reauthentication also establishes new keys for the
1363 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
1364 more often than reauthentication, the situation where "authentication
1365 lifetime" is shorter than "key lifetime" does not make sense.
1367 While creation of a new IKE_SA can be initiated by either party
1368 (initiator or responder in the original IKE_SA), the use of EAP
1369 authentication and/or configuration payloads means in practice that
1370 reauthentication has to be initiated by the same party as the
1371 original IKE_SA. IKEv2 base specification does not allow the
1372 responder to request reauthentication in this case; however, this
1373 functionality is added in [ReAuth].
1375 (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
1377 5.3. SPIs When Rekeying the IKE_SA
1379 Section 2.18 says that "New initiator and responder SPIs are supplied
1380 in the SPI fields". This refers to the SPI fields in the Proposal
1381 structures inside the Security Association (SA) payloads, not the SPI
1382 fields in the IKE header.
1384 (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
1385 Geoffrey Huang's reply, 2005-01-24.)
1387 5.4. SPI When Rekeying a CHILD_SA
1389 Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
1390 identifies the SA being rekeyed."
1392 Since CHILD_SAs always exist in pairs, there are two different SPIs.
1393 The SPI placed in the REKEY_SA notification is the SPI the exchange
1394 initiator would expect in inbound ESP or AH packets (just as in
1402 Eronen & Hoffman Informational [Page 25]
1404 RFC 4718 IKEv2 Clarifications October 2006
1407 5.5. Changing PRFs When Rekeying the IKE_SA
1409 When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
1410 new IKE_SA is computed using SK_d from the existing IKE_SA as
1413 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
1415 If the old and new IKE_SA selected a different PRF, it is not totally
1416 clear which PRF should be used.
1418 Since the rekeying exchange belongs to the old IKE_SA, it is the old
1419 IKE_SA's PRF that is used. This also follows the principle that the
1420 same key (the old SK_d) should not be used with multiple
1421 cryptographic algorithms.
1423 Note that this may work poorly if the new IKE_SA's PRF has a fixed
1424 key size, since the output of the PRF may not be of the correct size.
1425 This supports our opinion earlier in the document that the use of
1426 PRFs with a fixed key size is a bad idea.
1428 (References: "Changing PRFs when rekeying the IKE_SA" thread, June
1431 5.6. Deleting vs. Closing SAs
1433 The IKEv2 specification talks about "closing" and "deleting" SAs, but
1434 it is not always clear what exactly is meant. However, other parts
1435 of the specification make it clear that when local state related to a
1436 CHILD_SA is removed, the SA must also be actively deleted with a
1439 In particular, Section 2.4 says that "If an IKE endpoint chooses to
1440 delete CHILD_SAs, it MUST send Delete payloads to the other end
1441 notifying it of the deletion". Section 1.4 also explains that "ESP
1442 and AH SAs always exist in pairs, with one SA in each direction.
1443 When an SA is closed, both members of the pair MUST be closed."
1445 5.7. Deleting a CHILD_SA Pair
1447 Section 1.4 describes how to delete SA pairs using the Informational
1448 exchange: "To delete an SA, an INFORMATIONAL exchange with one or
1449 more delete payloads is sent listing the SPIs (as they would be
1450 expected in the headers of inbound packets) of the SAs to be deleted.
1451 The recipient MUST close the designated SAs."
1458 Eronen & Hoffman Informational [Page 26]
1460 RFC 4718 IKEv2 Clarifications October 2006
1463 The "one or more delete payloads" phrase has caused some confusion.
1464 You never send delete payloads for the two sides of an SA in a single
1465 message. If you have many SAs to delete at the same time (such as
1466 the nested example given in that paragraph), you include delete
1467 payloads for the inbound half of each SA in your Informational
1470 5.8. Deleting an IKE_SA
1472 Since IKE_SAs do not exist in pairs, it is not totally clear what the
1473 response message should contain when the request deleted the IKE_SA.
1475 Since there is no information that needs to be sent to the other side
1476 (except that the request was received), an empty Informational
1477 response seems like the most logical choice.
1479 (References: "Question about delete IKE SA" thread, May 2005.)
1481 5.9. Who is the original initiator of IKE_SA
1483 In the IKEv2 document, "initiator" refers to the party who initiated
1484 the exchange being described, and "original initiator" refers to the
1485 party who initiated the whole IKE_SA. However, there is some
1486 potential for confusion because the IKE_SA can be rekeyed by either
1489 To clear up this confusion, we propose that "original initiator"
1490 always refers to the party who initiated the exchange that resulted
1491 in the current IKE_SA. In other words, if the "original responder"
1492 starts rekeying the IKE_SA, that party becomes the "original
1493 initiator" of the new IKE_SA.
1495 (References: Paul Hoffman's mail "Original initiator in IKEv2",
1498 5.10. Comparing Nonces
1500 Section 2.8 about rekeying says that "If redundant SAs are created
1501 though such a collision, the SA created with the lowest of the four
1502 nonces used in the two exchanges SHOULD be closed by the endpoint
1514 Eronen & Hoffman Informational [Page 27]
1516 RFC 4718 IKEv2 Clarifications October 2006
1519 Here "lowest" uses an octet-by-octet (lexicographical) comparison
1520 (instead of, for instance, comparing the nonces as large integers).
1521 In other words, start by comparing the first octet; if they're equal,
1522 move to the next octet, and so on. If you reach the end of one
1523 nonce, that nonce is the lower one.
1525 (References: "IKEv2 rekeying question" thread, July 2005.)
1527 5.11. Exchange Collisions
1529 Since IKEv2 exchanges can be initiated by both peers, it is possible
1530 that two exchanges affecting the same SA partly overlap. This can
1531 lead to a situation where the SA state information is temporarily not
1532 synchronized, and a peer can receive a request it cannot process in a
1533 normal fashion. Some of these corner cases are discussed in the
1534 specification, some are not.
1536 Obviously, using a window size greater than one leads to infinitely
1537 more complex situations, especially if requests are processed out of
1538 order. In this section, we concentrate on problems that can arise
1539 even with window size 1.
1541 (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
1542 Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.)
1544 5.11.1. Simultaneous CHILD_SA Close
1546 Probably the simplest case happens if both peers decide to close the
1547 same CHILD_SA pair at the same time:
1551 send req1: D(SPIa) -->
1552 <-- send req2: D(SPIb)
1560 This case is described in Section 1.4 and is handled by omitting the
1561 Delete payloads from the response messages.
1570 Eronen & Hoffman Informational [Page 28]
1572 RFC 4718 IKEv2 Clarifications October 2006
1575 5.11.2. Simultaneous IKE_SA Close
1577 Both peers can also decide to close the IKE_SA at the same time. The
1578 desired end result is obvious; however, in certain cases the final
1579 exchanges may not be fully completed.
1587 At this point, host B should reply as usual (with empty Informational
1588 response), close the IKE_SA, and stop retransmitting req2. This is
1589 because once host A receives resp1, it may not be able to reply any
1590 longer. The situation is symmetric, so host A should behave the same
1598 Even if neither resp1 nor resp2 ever arrives, the end result is still
1599 correct: the IKE_SA is gone. The same happens if host A never
1602 5.11.3. Simultaneous CHILD_SA Rekeying
1604 Another case that is described in the specification is simultaneous
1605 rekeying. Section 2.8 says
1607 "If the two ends have the same lifetime policies, it is possible
1608 that both will initiate a rekeying at the same time (which will
1609 result in redundant SAs). To reduce the probability of this
1610 happening, the timing of rekeying requests SHOULD be jittered
1611 (delayed by a random amount of time after the need for rekeying is
1614 This form of rekeying may temporarily result in multiple similar
1615 SAs between the same pairs of nodes. When there are two SAs
1616 eligible to receive packets, a node MUST accept incoming packets
1617 through either SA. If redundant SAs are created though such a
1618 collision, the SA created with the lowest of the four nonces used
1619 in the two exchanges SHOULD be closed by the endpoint that created
1626 Eronen & Hoffman Informational [Page 29]
1628 RFC 4718 IKEv2 Clarifications October 2006
1631 However, a better explanation on what impact this has on
1632 implementations is needed. Assume that hosts A and B have an
1633 existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
1634 rekeying it at the same time:
1638 send req1: N(REKEY_SA,SPIa1),
1639 SA(..,SPIa2,..),Ni1,.. -->
1640 <-- send req2: N(REKEY_SA,SPIb1),
1641 SA(..,SPIb2,..),Ni2,..
1644 At this point, A knows there is a simultaneous rekeying going on.
1645 However, it cannot yet know which of the exchanges will have the
1646 lowest nonce, so it will just note the situation and respond as
1649 send resp2: SA(..,SPIa3,..),Nr1,.. -->
1652 Now B also knows that simultaneous rekeying is going on. Similarly
1653 as host A, it has to respond as usual.
1655 <-- send resp1: SA(..,SPIb3,..),Nr2,..
1659 At this point, there are three CHILD_SA pairs between A and B (the
1660 old one and two new ones). A and B can now compare the nonces.
1661 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1662 B (the sender of req2) deletes the redundant new SA, and A (the node
1663 that initiated the surviving rekeyed SA) deletes the old one.
1665 send req3: D(SPIa1) -->
1666 <-- send req4: D(SPIb2)
1668 <-- send resp4: D(SPIb1)
1670 send resp4: D(SPIa3) -->
1672 The rekeying is now finished.
1674 However, there is a second possible sequence of events that can
1675 happen if some packets are lost in the network, resulting in
1676 retransmissions. The rekeying begins as usual, but A's first packet
1682 Eronen & Hoffman Informational [Page 30]
1684 RFC 4718 IKEv2 Clarifications October 2006
1689 send req1: N(REKEY_SA,SPIa1),
1690 SA(..,SPIa2,..),Ni1,.. --> (lost)
1691 <-- send req2: N(REKEY_SA,SPIb1),
1692 SA(..,SPIb2,..),Ni2,..
1694 send resp2: SA(..,SPIa3,..),Nr1,.. -->
1696 <-- send req3: D(SPIb1)
1698 send resp3: D(SPIa1) -->
1701 From B's point of view, the rekeying is now completed, and since it
1702 has not yet received A's req1, it does not even know that these was
1703 simultaneous rekeying. However, A will continue retransmitting the
1704 message, and eventually it will reach B.
1709 What should B do in this point? To B, it looks like A is trying to
1710 rekey an SA that no longer exists; thus failing the request with
1711 something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
1712 reasonable approach.
1714 <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1717 When A receives this error, it already knows there was simultaneous
1718 rekeying, so it can ignore the error message.
1720 5.11.4. Simultaneous IKE_SA Rekeying
1722 Probably the most complex case occurs when both peers try to rekey
1723 the IKE_SA at the same time. Basically, the text in Section 2.8
1724 applies to this case as well; however, it is important to ensure that
1725 the CHILD_SAs are inherited by the right IKE_SA.
1727 The case where both endpoints notice the simultaneous rekeying works
1728 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
1729 three IKE_SAs exist between A and B; the one containing the lowest
1730 nonce inherits the CHILD_SAs.
1732 However, there is a twist to the other case where one rekeying
1738 Eronen & Hoffman Informational [Page 31]
1740 RFC 4718 IKEv2 Clarifications October 2006
1746 SA(..,SPIa1,..),Ni1,.. -->
1747 <-- send req2: SA(..,SPIb1,..),Ni2,..
1749 <-- send resp1: SA(..,SPIb2,..),Nr2,..
1754 At this point, host B sees a request to close the IKE_SA. There's
1755 not much more to do than to reply as usual. However, at this point
1756 host B should stop retransmitting req2, since once host A receives
1757 resp3, it will delete all the state associated with the old IKE_SA
1758 and will not be able to reply to it.
1762 5.11.5. Closing and Rekeying a CHILD_SA
1764 A case similar to simultaneous rekeying can occur if one peer decides
1765 to close an SA and the other peer tries to rekey it:
1769 send req1: D(SPIa) -->
1770 <-- send req2: N(REKEY_SA,SPIb),SA,..
1773 At this point, host B notices that host A is trying to close an SA
1774 that host B is currently rekeying. Replying as usual is probably the
1777 <-- send resp1: D(SPIb)
1779 Depending on in which order req2 and resp1 arrive, host A sees either
1780 a request to rekey an SA that it is currently closing, or a request
1781 to rekey an SA that does not exist. In both cases,
1782 NO_PROPOSAL_CHOSEN is probably fine.
1786 send resp2: N(NO_PROPOSAL_CHOSEN) -->
1794 Eronen & Hoffman Informational [Page 32]
1796 RFC 4718 IKEv2 Clarifications October 2006
1799 5.11.6. Closing a New CHILD_SA
1801 Yet another case occurs when host A creates a CHILD_SA pair, but soon
1802 thereafter host B decides to delete it (possible because its policy
1807 send req1: [N(REKEY_SA,SPIa1)],
1808 SA(..,SPIa2,..),.. -->
1810 (lost) <-- send resp1: SA(..,SPIb2,..),..
1812 <-- send req2: D(SPIb2)
1815 At this point, host A has not yet received message resp1 (and is
1816 retransmitting message req1), so it does not recognize SPIb in
1817 message req2. What should host A do?
1819 One option would be to reply with an empty Informational response.
1820 However, this same reply would also be sent if host A has received
1821 resp1, but has already sent a new request to delete the SA that was
1822 just created. This would lead to a situation where the peers are no
1823 longer in sync about which SAs exist between them. However, host B
1824 would eventually notice that the other half of the CHILD_SA pair has
1825 not been deleted. Section 1.4 describes this case and notes that "a
1826 node SHOULD regard half-closed connections as anomalous and audit
1827 their existence should they persist", and continues that "if
1828 connection state becomes sufficiently messed up, a node MAY close the
1831 Another solution that has been proposed is to reply with an
1832 INVALID_SPI notification that contains SPIb. This would explicitly
1833 tell host B that the SA was not deleted, so host B could try deleting
1834 it again later. However, this usage is not part of the IKEv2
1835 specification and would not be in line with normal use of the
1836 INVALID_SPI notification where the data field contains the SPI the
1837 recipient of the notification would put in outbound packets.
1839 Yet another solution would be to ignore req2 at this time and wait
1840 until we have received resp1. However, this alternative has not been
1841 fully analyzed at this time; in general, ignoring valid requests is
1842 always a bit dangerous, because both endpoints could do it, leading
1845 This document recommends the first alternative.
1850 Eronen & Hoffman Informational [Page 33]
1852 RFC 4718 IKEv2 Clarifications October 2006
1855 5.11.7. Rekeying a New CHILD_SA
1857 Yet another case occurs when a CHILD_SA is rekeyed soon after it has
1862 send req1: [N(REKEY_SA,SPIa1)],
1863 SA(..,SPIa2,..),.. -->
1864 (lost) <-- send resp1: SA(..,SPIb2,..),..
1866 <-- send req2: N(REKEY_SA,SPIb2),
1870 To host A, this looks like a request to rekey an SA that does not
1871 exist. Like in the simultaneous rekeying case, replying with
1872 NO_PROPOSAL_CHOSEN is probably reasonable:
1874 send resp2: N(NO_PROPOSAL_CHOSEN) -->
1877 5.11.8. Collisions with IKE_SA Rekeying
1879 Another set of cases occurs when one peer starts rekeying the IKE_SA
1880 at the same time the other peer starts creating, rekeying, or closing
1881 a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon
1882 after, host A starts rekeying the IKE_SA:
1886 <-- send req1: SA,Ni1,TSi,TSr
1887 send req2: SA,Ni2,.. -->
1890 What should host B do at this point? Replying as usual would seem
1891 like a reasonable choice:
1893 <-- send resp2: SA,Ni2,..
1898 Now, a problem arises: If host B now replies normally with an empty
1899 Informational response, this will cause host A to delete state
1900 associated with the IKE_SA. This means host B should stop
1901 retransmitting req1. However, host B cannot know whether or not host
1902 A has received req1. If host A did receive it, it will move the
1906 Eronen & Hoffman Informational [Page 34]
1908 RFC 4718 IKEv2 Clarifications October 2006
1911 CHILD_SA to the new IKE_SA as usual, and the state information will
1912 then be out of sync.
1914 It seems this situation is tricky to handle correctly. Our proposal
1915 is as follows: if a host receives a request to rekey the IKE_SA when
1916 it has CHILD_SAs in "half-open" state (currently being created or
1917 rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host
1918 receives a request to create or rekey a CHILD_SA after it has started
1919 rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
1921 The case where CHILD_SAs are being closed is even worse. Our
1922 recommendation is that if a host receives a request to rekey the
1923 IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
1924 closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host
1925 receives a request to close a CHILD_SA after it has started rekeying
1926 the IKE_SA, it should reply with an empty Informational response.
1927 This ensures that at least the other peer will eventually notice that
1928 the CHILD_SA is still in "half-closed" state and will start a new
1929 IKE_SA from scratch.
1931 5.11.9. Closing and Rekeying the IKE_SA
1933 The final case considered in this section occurs if one peer decides
1934 to close the IKE_SA while the other peer tries to rekey it.
1938 send req1: SA(..,SPIa1,..),Ni1 -->
1943 At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
1944 and host A should reply as usual, close the IKE_SA, and stop
1945 retransmitting req1.
1947 <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1950 If host A wants to continue communication with B, it can now start a
1955 If a host receives a request to rekey:
1957 o a CHILD_SA pair that the host is currently trying to close: reply
1958 with NO_PROPOSAL_CHOSEN.
1962 Eronen & Hoffman Informational [Page 35]
1964 RFC 4718 IKEv2 Clarifications October 2006
1967 o a CHILD_SA pair that the host is currently rekeying: reply as
1968 usual, but prepare to close redundant SAs later based on the
1971 o a CHILD_SA pair that does not exist: reply with
1974 o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
1975 as usual, but prepare to close redundant SAs and move inherited
1976 CHILD_SAs later based on the nonces.
1978 o the IKE_SA, and the host is currently creating, rekeying, or
1979 closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
1981 o the IKE_SA, and the host is currently trying to close the IKE_SA:
1982 reply with NO_PROPOSAL_CHOSEN.
1984 If a host receives a request to close:
1986 o a CHILD_SA pair that the host is currently trying to close: reply
1987 without Delete payloads.
1989 o a CHILD_SA pair that the host is currently rekeying: reply as
1990 usual, with Delete payload.
1992 o a CHILD_SA pair that does not exist: reply without Delete
1995 o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
1996 as usual, and forget about our own rekeying request.
1998 o the IKE_SA, and the host is currently trying to close the IKE_SA:
1999 reply as usual, and forget about our own close request.
2001 If a host receives a request to create or rekey a CHILD_SA when it is
2002 currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
2004 If a host receives a request to delete a CHILD_SA when it is
2005 currently rekeying the IKE_SA: reply without Delete payloads.
2007 5.12. Diffie-Hellman and Rekeying the IKE_SA
2009 There has been some confusion whether doing a new Diffie-Hellman
2010 exchange is mandatory when the IKE_SA is rekeyed.
2012 It seems that this case is allowed by the IKEv2 specification.
2013 Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
2014 Section 3.3.3 does not contradict this when it says that including
2018 Eronen & Hoffman Informational [Page 36]
2020 RFC 4718 IKEv2 Clarifications October 2006
2023 the D-H transform is mandatory: although including the transform is
2024 mandatory, it can contain the value "NONE".
2026 However, having the option to skip the Diffie-Hellman exchange when
2027 rekeying the IKE_SA does not add useful functionality to the
2028 protocol. The main purpose of rekeying the IKE_SA is to ensure that
2029 the compromise of old keying material does not provide information
2030 about the current keys, or vice versa. This requires performing the
2031 Diffie-Hellman exchange when rekeying. Furthermore, it is likely
2032 that this option would have been removed from the protocol as
2033 unnecessary complexity had it been discussed earlier.
2035 Given this, we recommend that implementations should have a hard-
2036 coded policy that requires performing a new Diffie-Hellman exchange
2037 when rekeying the IKE_SA. In other words, the initiator should not
2038 propose the value "NONE" for the D-H transform, and the responder
2039 should not accept such a proposal. This policy also implies that a
2040 successful exchange rekeying the IKE_SA always includes the KEi/KEr
2043 (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
2044 thread, Oct 2005. "Comments of
2045 draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
2047 6. Configuration Payloads
2049 6.1. Assigning IP Addresses
2051 Section 2.9 talks about traffic selector negotiation and mentions
2052 that "In support of the scenario described in section 1.1.3, an
2053 initiator may request that the responder assign an IP address and
2054 tell the initiator what it is."
2056 This sentence is correct, but its placement is slightly confusing.
2057 IKEv2 does allow the initiator to request assignment of an IP address
2058 from the responder, but this is done using configuration payloads,
2059 not traffic selector payloads. An address in a TSi payload in a
2060 response does not mean that the responder has assigned that address
2061 to the initiator; it only means that if packets matching these
2062 traffic selectors are sent by the initiator, IPsec processing can be
2063 performed as agreed for this SA. The TSi payload itself does not
2064 give the initiator permission to configure the initiator's TCP/IP
2065 stack with the address and use it as its source address.
2067 In other words, IKEv2 does not have two different mechanisms for
2068 assigning addresses, but only one: configuration payloads. In the
2069 scenario described in Section 1.1.3, both configuration and traffic
2070 selector payloads are usually included in the same message, and they
2074 Eronen & Hoffman Informational [Page 37]
2076 RFC 4718 IKEv2 Clarifications October 2006
2079 often contain the same information in the response message (see
2080 Section 6.3 of this document for some examples). However, their
2081 semantics are still different.
2083 6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS
2085 When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
2086 3.15.1 says that "In a request message, the address specified is a
2087 requested address (or zero if no specific address is requested)".
2088 The question here is whether "zero" means an address "0.0.0.0" or a
2091 Earlier, the same section also says that "If an attribute in the
2092 CFG_REQUEST Configuration Payload is not zero-length, it is taken as
2093 a suggestion for that attribute". Also, the table of configuration
2094 attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
2095 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
2098 Thus, if the client does not request a specific address, it includes
2099 a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
2100 containing an all-zeroes address. The example in 2.19 is thus
2101 incorrect, since it shows the attribute as
2102 "INTERNAL_ADDRESS(0.0.0.0)".
2104 However, since the value is only a suggestion, implementations are
2105 recommended to ignore suggestions they do not accept; or in other
2106 words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS,
2107 "0.0.0.0", and any other addresses the implementation does not
2108 recognize as a reasonable suggestion.
2110 6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
2112 Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
2113 sub-networks that this edge-device protects. This attribute is made
2114 up of two fields: the first is an IP address and the second is a
2115 netmask. Multiple sub-networks MAY be requested. The responder MAY
2116 respond with zero or more sub-network attributes."
2117 INTERNAL_IP6_SUBNET is defined in a similar manner.
2119 This raises two questions: first, since this information is usually
2120 included in the TSr payload, what functionality does this attribute
2121 add? And second, what does this attribute mean in CFG_REQUESTs?
2123 For the first question, there seem to be two sensible
2124 interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
2125 response) indicates which subnets are accessible through the SA that
2130 Eronen & Hoffman Informational [Page 38]
2132 RFC 4718 IKEv2 Clarifications October 2006
2135 The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
2136 that they indicate additional subnets that can be reached through
2137 this gateway, but need a separate SA. According to this
2138 interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
2139 mainly when they contain addresses not included in TSr.
2141 The second interpretation is that the INTERNAL_IP4/6_SUBNET
2142 attributes express the gateway's policy about what traffic should be
2143 sent through the gateway. The client can choose whether other
2144 traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
2145 through the gateway or directly to the destination. According to
2146 this interpretation, the attributes are useful mainly when TSr
2147 contains addresses not included in the INTERNAL_IP4/6_SUBNET
2150 It turns out that these two interpretations are not incompatible, but
2151 rather two sides of the same principle: traffic to the addresses
2152 listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
2153 this gateway. If there are no existing IPsec SAs whose traffic
2154 selectors cover the address in question, new SAs have to be created.
2156 A couple of examples are given below. For instance, if there are two
2157 subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
2158 contains the following:
2161 INTERNAL_IP4_ADDRESS()
2162 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
2163 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
2165 Then a valid response could be the following (in which TSr and
2166 INTERNAL_IP4_SUBNET contain the same information):
2169 INTERNAL_IP4_ADDRESS(192.0.1.234)
2170 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2171 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2172 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2173 TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
2174 (0, 0-65535, 192.0.2.0-192.0.2.255))
2176 In these cases, the INTERNAL_IP4_SUBNET does not really carry any
2177 useful information. Another possible reply would have been this:
2180 INTERNAL_IP4_ADDRESS(192.0.1.234)
2181 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2182 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2186 Eronen & Hoffman Informational [Page 39]
2188 RFC 4718 IKEv2 Clarifications October 2006
2191 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2192 TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
2194 This would mean that the client can send all its traffic through the
2195 gateway, but the gateway does not mind if the client sends traffic
2196 not included by INTERNAL_IP4_SUBNET directly to the destination
2197 (without going through the gateway).
2199 A different situation arises if the gateway has a policy that
2200 requires the traffic for the two subnets to be carried in separate
2201 SAs. Then a response like this would indicate to the client that if
2202 it wants access to the second subnet, it needs to create a separate
2206 INTERNAL_IP4_ADDRESS(192.0.1.234)
2207 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2208 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2209 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2210 TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
2212 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
2213 only part of the address space. For instance, if the client requests
2217 INTERNAL_IP4_ADDRESS()
2218 TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
2219 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
2221 Then the gateway's reply could be this:
2224 INTERNAL_IP4_ADDRESS(192.0.1.234)
2225 INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2226 INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2227 TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2228 TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
2230 It is less clear what the attributes mean in CFG_REQUESTs, and
2231 whether other lengths than zero make sense in this situation (but for
2232 INTERNAL_IP6_SUBNET, zero length is not allowed at all!). This
2233 document recommends that implementations should not include
2234 INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
2237 For the IPv4 case, this document recommends using only netmasks
2238 consisting of some amount of "1" bits followed by "0" bits; for
2242 Eronen & Hoffman Informational [Page 40]
2244 RFC 4718 IKEv2 Clarifications October 2006
2247 instance, "255.0.255.0" would not be a valid netmask for
2248 INTERNAL_IP4_SUBNET.
2250 It is also worthwhile to note that the contents of the INTERNAL_IP4/
2251 6_SUBNET attributes do not imply link boundaries. For instance, a
2252 gateway providing access to a large company intranet using addresses
2253 from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
2254 attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
2255 routers and separate links.
2257 (References: Tero Kivinen's mail "Intent of couple of attributes in
2258 Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao
2259 Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
2260 IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
2261 Clarifications and Implementation Guidelines", 2005-02-07.
2262 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
2265 6.4. INTERNAL_IP4_NETMASK
2267 Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says
2268 that "The internal network's netmask. Only one netmask is allowed in
2269 the request and reply messages (e.g., 255.255.255.0) and it MUST be
2270 used only with an INTERNAL_IP4_ADDRESS attribute".
2272 However, it is not clear what exactly this attribute means, as the
2273 concept of "netmask" is not very well defined for point-to-point
2274 links (unlike multi-access links, where it means "you can reach hosts
2275 inside this netmask directly using layer 2, instead of sending
2276 packets via a router"). Even if the operating system's TCP/IP stack
2277 requires a netmask to be configured, for point-to-point links it
2278 could be just set to 255.255.255.255. So, why is this information
2281 One possible interpretation would be that the host is given a whole
2282 block of IP addresses instead of a single address. This is also what
2283 Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
2284 does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
2285 IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the
2286 specification supports this interpretation, and discussions on the
2287 IPsec WG mailing list have confirmed it was not intended. Section
2288 3.15.1 also says that multiple addresses are assigned using multiple
2289 INTERNAL_IP4/6_ADDRESS attributes.
2291 Currently, this document's interpretation is the following:
2292 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
2293 INTERNAL_IP4_SUBNET containing the same information ("send traffic to
2294 these addresses through me"), but also implies a link boundary. For
2298 Eronen & Hoffman Informational [Page 41]
2300 RFC 4718 IKEv2 Clarifications October 2006
2303 instance, the client could use its own address and the netmask to
2304 calculate the broadcast address of the link. (Whether the gateway
2305 will actually deliver broadcast packets to other VPN clients and/or
2306 other nodes connected to this link is another matter.)
2308 An empty INTERNAL_IP4_NETMASK attribute can be included in a
2309 CFG_REQUEST to request this information (although the gateway can
2310 send the information even when not requested). However, it seems
2311 that non-empty values for this attribute do not make sense in
2314 Fortunately, Section 4 clearly says that a minimal implementation
2315 does not need to include or understand the INTERNAL_IP4_NETMASK
2316 attribute, and thus this document recommends that implementations
2317 should not use the INTERNAL_IP4_NETMASK attribute or assume that the
2318 other peer supports it.
2320 (References: Charlie Kaufman's mail "RE: Proposed Last Call based
2321 revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
2322 Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
2323 Implementation Guidelines", 2005-02-07. "Clarifications open issue:
2324 INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
2326 6.5. Configuration Payloads for IPv6
2328 IKEv2 also defines configuration payloads for IPv6. However, they
2329 are based on the corresponding IPv4 payloads and do not fully follow
2330 the "normal IPv6 way of doing things".
2332 A client can be assigned an IPv6 address using the
2333 INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could
2337 INTERNAL_IP6_ADDRESS()
2339 TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2340 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2343 INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
2344 INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
2345 TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
2346 TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2348 In particular, IPv6 stateless autoconfiguration or router
2349 advertisement messages are not used; neither is neighbor discovery.
2354 Eronen & Hoffman Informational [Page 42]
2356 RFC 4718 IKEv2 Clarifications October 2006
2359 The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
2360 in the CFG_REQUEST to request a specific address or interface
2361 identifier. The gateway first checks if the specified address is
2362 acceptable, and if it is, returns that one. If the address was not
2363 acceptable, the gateway will attempt to use the interface identifier
2364 with some other prefix; if even that fails, the gateway will select
2365 another interface identifier.
2367 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
2368 field. When used in a CFG_REPLY, this corresponds to the
2369 INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
2370 called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
2371 See the previous section for more details.
2373 While this approach to configuring IPv6 addresses is reasonably
2374 simple, it has some limitations: IPsec tunnels configured using IKEv2
2375 are not fully-featured "interfaces" in the IPv6 addressing
2376 architecture [IPv6Addr] sense. In particular, they do not
2377 necessarily have link-local addresses, and this may complicate the
2378 use of protocols that assume them, such as [MLDv2]. (Whether they
2379 are called "interfaces" in some particular operating system is a
2382 (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
2383 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
2386 6.6. INTERNAL_IP6_NBNS
2388 Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
2389 the IPv6 address of NetBIOS name servers.
2391 However, NetBIOS is not defined for IPv6 and probably never will be.
2392 Thus, this attribute most likely does not make much sense.
2394 (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
2397 6.7. INTERNAL_ADDRESS_EXPIRY
2399 Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
2400 "Specifies the number of seconds that the host can use the internal
2401 IP address. The host MUST renew the IP address before this expiry
2402 time. Only one of these attributes MAY be present in the reply."
2404 Expiry times and explicit renewals are primarily useful in
2405 environments like DHCP, where the server cannot reliably know when
2410 Eronen & Hoffman Informational [Page 43]
2412 RFC 4718 IKEv2 Clarifications October 2006
2415 the client has gone away. However, in IKEv2 this is known, and the
2416 gateway can simply free the address when the IKE_SA is deleted.
2418 Also, Section 4 says that supporting renewals is not mandatory.
2419 Given that this functionality is usually not needed, we recommend
2420 that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
2421 (And since this attribute does not seem to make much sense for
2422 CFG_REQUESTs, clients should not send it either.)
2424 Note that according to Section 4, clients are required to understand
2425 INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation
2426 would use the value to limit the lifetime of the IKE_SA.
2428 (References: Tero Kivinen's mail "Comments of
2429 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
2430 "Questions about internal address" thread, April 2005.)
2432 6.8. Address Assignment Failures
2434 If the responder encounters an error while attempting to assign an IP
2435 address to the initiator, it responds with an
2436 INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
2437 However, there are some more complex error cases.
2439 First, if the responder does not support configuration payloads at
2440 all, it can simply ignore all configuration payloads. This type of
2441 implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
2442 If the initiator requires the assignment of an IP address, it will
2443 treat a response without CFG_REPLY as an error.
2445 A second case is where the responder does support configuration
2446 payloads, but only for particular type of addresses (IPv4 or IPv6).
2447 Section 4 says that "A minimal IPv4 responder implementation will
2448 ignore the contents of the CP payload except to determine that it
2449 includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the
2450 initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
2451 in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
2452 IPv6 part and process the IPv4 request as usual.
2454 A third case is where the initiator requests multiple addresses of a
2455 type that the responder supports: what should happen if some (but not
2456 all) of the requests fail? It seems that an optimistic approach
2457 would be the best one here: if the responder is able to assign at
2458 least one address, it replies with those; it sends
2459 INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
2461 (References: "ikev2 and internal_ivpn_address" thread, June 2005.)
2466 Eronen & Hoffman Informational [Page 44]
2468 RFC 4718 IKEv2 Clarifications October 2006
2471 7. Miscellaneous Issues
2473 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR
2475 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
2476 payloads, IKEv2 does not require this address to match anything in
2477 the TSi/TSr payloads. For example, in a site-to-site VPN between two
2478 security gateways, the gateways could authenticate each other as
2479 ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
2480 a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
2481 behind the first security gateway) and 192.0.2.240/28 (a network
2482 behind the second security gateway). The authenticated identities
2483 (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
2484 using "Child SA Authorization Data" in the Peer Authorization
2487 Furthermore, IKEv2 does not require that the addresses in
2488 ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
2489 IKE packets. However, other specifications may place additional
2490 requirements regarding this. For example, [PKI4IPsec] requires that
2491 implementation must be capable of comparing the addresses in the
2492 ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
2493 IKE packets, and this comparison must be enabled by default.
2495 (References: "Identities types IP address,FQDN/user FQDN and DN and
2496 its usage in preshared key authentication" thread, Jan 2005.
2497 "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
2499 7.2. Relationship of IKEv2 to RFC 4301
2501 The IKEv2 specification refers to [RFC4301], but it never clearly
2502 defines the exact relationship.
2504 However, there are some requirements in the specification that make
2505 it clear that IKEv2 requires [RFC4301]. In other words, an
2506 implementation that does IPsec processing strictly according to
2507 [RFC2401] cannot be compliant with the IKEv2 specification.
2509 One such example can be found in Section 2.24: "Specifically, tunnel
2510 encapsulators and decapsulators for all tunnel-mode SAs created by
2511 IKEv2 [...] MUST implement the tunnel encapsulation and
2512 decapsulation processing specified in [RFC4301] to prevent discarding
2513 of ECN congestion indications."
2515 Nevertheless, the changes required to existing [RFC2401]
2516 implementations are not very large, especially since supporting many
2517 of the new features (such as Extended Sequence Numbers) is optional.
2522 Eronen & Hoffman Informational [Page 45]
2524 RFC 4718 IKEv2 Clarifications October 2006
2527 7.3. Reducing the Window Size
2529 In IKEv2, the window size is assumed to be a (possibly configurable)
2530 property of a particular implementation and is not related to
2531 congestion control (unlike the window size in TCP, for instance).
2533 In particular, it is not defined what the responder should do when it
2534 receives a SET_WINDOW_SIZE notification containing a smaller value
2535 than is currently in effect. Thus, there is currently no way to
2536 reduce the window size of an existing IKE_SA. However, when rekeying
2537 an IKE_SA, the new IKE_SA starts with window size 1 until it is
2538 explicitly increased by sending a new SET_WINDOW_SIZE notification.
2540 (References: Tero Kivinen's mail "Comments of
2541 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
2543 7.4. Minimum Size of Nonces
2545 Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
2546 MUST be at least 128 bits in size, and MUST be at least half the key
2547 size of the negotiated prf."
2549 However, the initiator chooses the nonce before the outcome of the
2550 negotiation is known. In this case, the nonce has to be long enough
2551 for all the PRFs being proposed.
2553 7.5. Initial Zero Octets on Port 4500
2555 It is not clear whether a peer sending an IKE_SA_INIT request on port
2556 4500 should include the initial four zero octets. Section 2.23 talks
2557 about how to upgrade to tunneling over port 4500 after message 2, but
2558 it does not say what to do if message 1 is sent on port 4500.
2560 IKE MUST listen on port 4500 as well as port 500.
2564 The IKE initiator MUST check these payloads if present and if
2565 they do not match the addresses in the outer packet MUST tunnel
2566 all future IKE and ESP packets associated with this IKE_SA over
2569 To tunnel IKE packets over UDP port 4500, the IKE header has four
2570 octets of zero prepended and the result immediately follows the
2578 Eronen & Hoffman Informational [Page 46]
2580 RFC 4718 IKEv2 Clarifications October 2006
2583 The very beginning of Section 2 says "... though IKE messages may
2584 also be received on UDP port 4500 with a slightly different format
2585 (see section 2.23)."
2587 That "slightly different format" is only described in discussing what
2588 to do after changing to port 4500. However, [RFC3948] shows clearly
2589 the format has the initial zeros even for initiators on port 4500.
2590 Furthermore, without the initial zeros, the processing engine cannot
2591 determine whether the packet is an IKE packet or an ESP packet.
2593 Thus, all packets sent on port 4500 need the four-zero prefix;
2594 otherwise, the receiver won't know how to handle them.
2596 7.6. Destination Port for NAT Traversal
2598 Section 2.23 says that "an IPsec endpoint that discovers a NAT
2599 between it and its correspondent MUST send all subsequent traffic to
2600 and from port 4500".
2602 This sentence is misleading. The peer "outside" the NAT uses source
2603 port 4500 for the traffic it sends, but the destination port is, of
2604 course, taken from packets sent by the peer behind the NAT. This
2605 port number is usually dynamically allocated by the NAT.
2607 7.7. SPI Values for Messages outside an IKE_SA
2609 The IKEv2 specification is not quite clear what SPI values should be
2610 used in the IKE header for the small number of notifications that are
2611 allowed to be sent outside an IKE_SA. Note that such notifications
2612 are explicitly not Informational exchanges; Section 1.5 makes it
2613 clear that these are one-way messages that must not be responded to.
2615 There are two cases when such a one-way notification can be sent:
2616 INVALID_IKE_SPI and INVALID_SPI.
2618 In case of INVALID_IKE_SPI, the message sent is a response message,
2619 and Section 2.21 says that "If a response is sent, the response MUST
2620 be sent to the IP address and port from whence it came with the same
2621 IKE SPIs and the Message ID copied."
2623 In case of INVALID_SPI, however, there are no IKE SPI values that
2624 would be meaningful to the recipient of such a notification. Also,
2625 the message sent is now an INFORMATIONAL request. A strict
2626 interpretation of the specification would require the sender to
2627 invent garbage values for the SPI fields. However, we think this was
2628 not the intention, and using zero values is acceptable.
2630 (References: "INVALID_IKE_SPI" thread, June 2005.)
2634 Eronen & Hoffman Informational [Page 47]
2636 RFC 4718 IKEv2 Clarifications October 2006
2639 7.8. Protocol ID/SPI Fields in Notify Payloads
2641 Section 3.10 says that the Protocol ID field in Notify payloads "For
2642 notifications that do not relate to an existing SA, this field MUST
2643 be sent as zero and MUST be ignored on receipt". However, the
2644 specification does not clearly say which notifications are related to
2645 existing SAs and which are not.
2647 Since the main purpose of the Protocol ID field is to specify the
2648 type of the SPI, our interpretation is that the Protocol ID field
2649 should be non-zero only when the SPI field is non-empty.
2651 There are currently only two notifications where this is the case:
2652 INVALID_SELECTORS and REKEY_SA.
2654 7.9. Which message should contain INITIAL_CONTACT
2656 The description of the INITIAL_CONTACT notification in Section 3.10.1
2657 says that "This notification asserts that this IKE_SA is the only
2658 IKE_SA currently active between the authenticated identities".
2659 However, neither Section 2.4 nor 3.10.1 says in which message this
2660 payload should be placed.
2662 The general agreement is that INITIAL_CONTACT is best communicated in
2663 the first IKE_AUTH request, not as a separate exchange afterwards.
2665 (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
2666 April 2005. "Initial Contact messages" thread, December 2004.
2667 "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
2669 7.10. Alignment of Payloads
2671 Many IKEv2 payloads contain fields marked as "RESERVED", mostly
2672 because IKEv1 had them, and partly because they make the pictures
2673 easier to draw. In particular, payloads in IKEv2 are not, in
2674 general, aligned to 4-octet boundaries. (Note that payloads were not
2675 aligned to 4-octet boundaries in IKEv1 either.)
2677 (References: "IKEv2: potential 4-byte alignment problem" thread, June
2680 7.11. Key Length Transform Attribute
2682 Section 3.3.5 says that "The only algorithms defined in this document
2683 that accept attributes are the AES based encryption, integrity, and
2684 pseudo-random functions, which require a single attribute specifying
2690 Eronen & Hoffman Informational [Page 48]
2692 RFC 4718 IKEv2 Clarifications October 2006
2695 This is incorrect. The AES-based integrity and pseudo-random
2696 functions defined in [IKEv2] always use a 128-bit key. In fact,
2697 there are currently no integrity or PRF algorithms that use the key
2698 length attribute (and we recommend that they should not be defined in
2701 For encryption algorithms, the situation is slightly more complex
2702 since there are three different types of algorithms:
2704 o The key length attribute is never used with algorithms that use a
2705 fixed length key, such as DES and IDEA.
2707 o The key length attribute is always included for the currently
2708 defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
2709 (CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
2710 (GCM)). Omitting the key length attribute is not allowed; if the
2711 proposal does not contain it, the proposal has to be rejected.
2713 o For other algorithms, the key length attribute can be included but
2714 is not mandatory. These algorithms include, e.g., RC5, CAST, and
2715 BLOWFISH. If the key length attribute is not included, the
2716 default value specified in [RFC2451] is used.
2718 7.12. IPsec IANA Considerations
2720 There are currently three different IANA registry files that contain
2721 important numbers for IPsec: ikev2-registry, isakmp-registry, and
2722 ipsec-registry. Implementers should note that IKEv2 may use numbers
2723 different from those of IKEv1 for a particular algorithm.
2725 For instance, an encryption algorithm can have up to three different
2726 numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
2727 the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
2728 registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
2729 isakmp-registry. Although some algorithms have the same number in
2730 all three registries, the registries are not identical.
2732 Similarly, an integrity algorithm can have at least the IKEv2
2733 "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
2734 "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
2735 phase 2 ESP "Authentication Algorithm Security Association Attribute"
2736 identifier in isakmp-registry. And there is also the IKEv1 phase 1
2737 "Hash Algorithm" list in ipsec-registry.
2739 This issue needs special care also when writing a specification for
2740 how a new algorithm is used with IPsec.
2746 Eronen & Hoffman Informational [Page 49]
2748 RFC 4718 IKEv2 Clarifications October 2006
2751 7.13. Combining ESP and AH
2753 The IKEv2 specification contains some misleading text about how ESP
2754 and AH can be combined.
2756 IKEv2 is based on [RFC4301], which does not include "SA bundles" that
2757 were part of [RFC2401]. While a single packet can go through IPsec
2758 processing multiple times, each of these passes uses a separate SA,
2759 and the passes are coordinated by the forwarding tables. In IKEv2,
2760 each of these SAs has to be created using a separate CREATE_CHILD_SA
2761 exchange. Thus, the text in Section 2.7 about a single proposal
2762 containing both ESP and AH is incorrect.
2764 Moreover, the combination of ESP and AH (between the same endpoints)
2765 had already become largely obsolete in 1998 when RFC 2406 was
2766 published. Our recommendation is that IKEv2 implementations should
2767 not support this combination, and implementers should not assume the
2768 combination can be made to work in an interoperable manner.
2770 (References: "Rekeying SA bundles" thread, Oct 2005.)
2772 8. Implementation Mistakes
2774 Some implementers at the early IKEv2 bakeoffs didn't do everything
2775 correctly. This may seem like an obvious statement, but it is
2776 probably useful to list a few things that were clear in the document,
2777 but that some implementers didn't do. All of these things caused
2778 interoperability problems.
2780 o Some implementations continued to send traffic on a CHILD_SA after
2781 it was rekeyed, even after receiving an DELETE payload.
2783 o After rekeying an IKE_SA, some implementations did not reset their
2784 message counters to zero. One set the counter to 2, another did
2785 not reset the counter at all.
2787 o Some implementations could only handle a single pair of traffic
2788 selectors or would only process the first pair in the proposal.
2790 o Some implementations responded to a delete request by sending an
2791 empty INFORMATIONAL response and then initiated their own
2792 INFORMATIONAL exchange with the pair of SAs to delete.
2794 o Although this did not happen at the bakeoff, from the discussion
2795 there, it is clear that some people had not implemented message
2796 window sizes correctly. Some implementations might have sent
2802 Eronen & Hoffman Informational [Page 50]
2804 RFC 4718 IKEv2 Clarifications October 2006
2807 messages that did not fit into the responder's message windows,
2808 and some implementations may not have torn down an SA if they did
2809 not ever receive a message that they know they should have.
2811 9. Security Considerations
2813 This document does not introduce any new security considerations to
2814 IKEv2. If anything, clarifying complex areas of the specification
2815 can reduce the likelihood of implementation problems that may have
2816 security implications.
2820 This document is mainly based on conversations on the IPsec WG
2821 mailing list. The authors would especially like to thank Bernard
2822 Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
2823 Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
2824 Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
2827 In addition, the authors would like to thank all the participants of
2828 the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
2829 for their questions and proposed clarifications.
2833 11.1. Normative References
2835 [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
2836 Protocol", RFC 4306, December 2005.
2838 [IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the
2839 Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
2842 [PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
2843 Specifications Version 2.0", RFC 2437, October 1998.
2845 [PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
2846 Standards (PKCS) #1: RSA Cryptography Specifications
2847 Version 2.1", RFC 3447, February 2003.
2849 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
2850 the Internet Protocol", RFC 2401, November 1998.
2852 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
2853 Internet Protocol", RFC 4301, December 2005.
2858 Eronen & Hoffman Informational [Page 51]
2860 RFC 4718 IKEv2 Clarifications October 2006
2863 11.2. Informative References
2865 [Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with
2866 Host-to-Host IPsec", 13th International Workshop on
2867 Security Protocols, Cambridge, UK, April 2005.
2869 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
2870 H. Levkowetz, "Extensible Authentication Protocol
2871 (EAP)", RFC 3748, June 2004.
2873 [HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
2874 Work in Progress, July 2006.
2876 [IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support
2877 Enhancements", http://www.cisco.com/univercd/cc/td/
2878 doc/product/software/ios121/121newft/121limit/121dc/
2879 121dc3/ipcp_msk.htm, January 2003.
2881 [IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
2882 Architecture", RFC 4291, February 2006.
2884 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
2885 Support in IPv6", RFC 3775, June 2004.
2887 [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
2888 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
2890 [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
2891 Network Access Identifier", RFC 4282, December 2005.
2893 [PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
2894 IKEv2, and PKIX", Work in Progress, April 2006.
2896 [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
2897 Authentication Dial In User Service) Support For
2898 Extensible Authentication Protocol (EAP)", RFC 3579,
2901 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
2902 "Remote Authentication Dial In User Service (RADIUS)",
2903 RFC 2865, June 2000.
2905 [RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
2906 RFC 3162, August 2001.
2908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2909 Requirement Levels", RFC 2119, March 1997.
2914 Eronen & Hoffman Informational [Page 52]
2916 RFC 4718 IKEv2 Clarifications October 2006
2919 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
2920 Algorithms", RFC 2451, November 1998.
2922 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2925 [RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
2926 Internet Key Exchange Protocol (IKE)", RFC 3664,
2929 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
2930 M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
2931 RFC 3948, January 2005.
2933 [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
2934 Internet Key Exchange Protocol (IKE)", RFC 4434,
2937 [RFC822] Crocker, D., "Standard for the format of ARPA Internet
2938 text messages", RFC 822, August 1982.
2940 [ReAuth] Nir, Y., "Repeated Authentication in Internet Key
2941 Exchange (IKEv2) Protocol", RFC 4478, April 2006.
2943 [SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
2944 T. Polk, "Simple Certificate Validation Protocol
2945 (SCVP)", Work in Progress, June 2006.
2970 Eronen & Hoffman Informational [Page 53]
2972 RFC 4718 IKEv2 Clarifications October 2006
2975 Appendix A. Exchanges and Payloads
2977 This appendix contains a short summary of the IKEv2 exchanges, and
2978 what payloads can appear in which message. This appendix is purely
2979 informative; if it disagrees with the body of this document or the
2980 IKEv2 specification, the other text is considered correct.
2982 Vendor-ID (V) payloads may be included in any place in any message.
2983 This sequence shows what are, in our opinion, the most logical places
2986 The specification does not say which messages can contain
2987 N(SET_WINDOW_SIZE). It can possibly be included in any message, but
2988 it is not yet shown below.
2990 A.1. IKE_SA_INIT Exchange
2992 request --> [N(COOKIE)],
2994 [N(NAT_DETECTION_SOURCE_IP)+,
2995 N(NAT_DETECTION_DESTINATION_IP)],
2998 normal response <-- SA, KE, Nr,
2999 (no cookie) [N(NAT_DETECTION_SOURCE_IP),
3000 N(NAT_DETECTION_DESTINATION_IP)],
3001 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3004 A.2. IKE_AUTH Exchange without EAP
3006 request --> IDi, [CERT+],
3007 [N(INITIAL_CONTACT)],
3008 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3012 [N(IPCOMP_SUPPORTED)+],
3013 [N(USE_TRANSPORT_MODE)],
3014 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3015 [N(NON_FIRST_FRAGMENTS_ALSO)],
3026 Eronen & Hoffman Informational [Page 54]
3028 RFC 4718 IKEv2 Clarifications October 2006
3031 response <-- IDr, [CERT+],
3034 [N(IPCOMP_SUPPORTED)],
3035 [N(USE_TRANSPORT_MODE)],
3036 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3037 [N(NON_FIRST_FRAGMENTS_ALSO)],
3039 [N(ADDITIONAL_TS_POSSIBLE)],
3042 A.3. IKE_AUTH Exchange with EAP
3044 first request --> IDi,
3045 [N(INITIAL_CONTACT)],
3046 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3049 [N(IPCOMP_SUPPORTED)+],
3050 [N(USE_TRANSPORT_MODE)],
3051 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3052 [N(NON_FIRST_FRAGMENTS_ALSO)],
3056 first response <-- IDr, [CERT+], AUTH,
3064 last request --> AUTH
3066 last response <-- AUTH,
3068 [N(IPCOMP_SUPPORTED)],
3069 [N(USE_TRANSPORT_MODE)],
3070 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3071 [N(NON_FIRST_FRAGMENTS_ALSO)],
3073 [N(ADDITIONAL_TS_POSSIBLE)],
3082 Eronen & Hoffman Informational [Page 55]
3084 RFC 4718 IKEv2 Clarifications October 2006
3087 A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
3089 request --> [N(REKEY_SA)],
3090 [N(IPCOMP_SUPPORTED)+],
3091 [N(USE_TRANSPORT_MODE)],
3092 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3093 [N(NON_FIRST_FRAGMENTS_ALSO)],
3094 SA, Ni, [KEi], TSi, TSr
3096 response <-- [N(IPCOMP_SUPPORTED)],
3097 [N(USE_TRANSPORT_MODE)],
3098 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3099 [N(NON_FIRST_FRAGMENTS_ALSO)],
3100 SA, Nr, [KEr], TSi, TSr,
3101 [N(ADDITIONAL_TS_POSSIBLE)]
3103 A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
3105 request --> SA, Ni, [KEi]
3107 response <-- SA, Nr, [KEr]
3109 A.6. INFORMATIONAL Exchange
3138 Eronen & Hoffman Informational [Page 56]
3140 RFC 4718 IKEv2 Clarifications October 2006
3146 Nokia Research Center
3148 FIN-00045 Nokia Group
3151 EMail: pasi.eronen@nokia.com
3157 Santa Cruz, CA 95060
3160 EMail: paul.hoffman@vpnc.org
3194 Eronen & Hoffman Informational [Page 57]
3196 RFC 4718 IKEv2 Clarifications October 2006
3199 Full Copyright Statement
3201 Copyright (C) The Internet Society (2006).
3203 This document is subject to the rights, licenses and restrictions
3204 contained in BCP 78, and except as set forth therein, the authors
3205 retain all their rights.
3207 This document and the information contained herein are provided on an
3208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3215 Intellectual Property
3217 The IETF takes no position regarding the validity or scope of any
3218 Intellectual Property Rights or other rights that might be claimed to
3219 pertain to the implementation or use of the technology described in
3220 this document or the extent to which any license under such rights
3221 might or might not be available; nor does it represent that it has
3222 made any independent effort to identify any such rights. Information
3223 on the procedures with respect to rights in RFC documents can be
3224 found in BCP 78 and BCP 79.
3226 Copies of IPR disclosures made to the IETF Secretariat and any
3227 assurances of licenses to be made available, or the result of an
3228 attempt made to obtain a general license or permission for the use of
3229 such proprietary rights by implementers or users of this
3230 specification can be obtained from the IETF on-line IPR repository at
3231 http://www.ietf.org/ipr.
3233 The IETF invites any interested party to bring to its attention any
3234 copyrights, patents or patent applications, or other proprietary
3235 rights that may cover technology that may be required to implement
3236 this standard. Please address the information to the IETF at
3241 Funding for the RFC Editor function is provided by the IETF
3242 Administrative Support Activity (IASA).
3250 Eronen & Hoffman Informational [Page 58]