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