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