GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4718

Network Working Group P. Eronen Request for Comments: 4718 Nokia Category: Informational P. Hoffman

                                                        VPN Consortium
                                                          October 2006
         IKEv2 Clarifications and Implementation Guidelines

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document clarifies many areas of the IKEv2 specification.  It
 does not to introduce any changes to the protocol, but rather
 provides descriptions that are less prone to ambiguous
 interpretations.  The purpose of this document is to encourage the
 development of interoperable implementations.

Eronen & Hoffman Informational [Page 1] RFC 4718 IKEv2 Clarifications October 2006

Table of Contents

 1. Introduction ....................................................4
 2. Creating the IKE_SA .............................................4
    2.1. SPI Values in IKE_SA_INIT Exchange .........................4
    2.2. Message IDs for IKE_SA_INIT Messages .......................5
    2.3. Retransmissions of IKE_SA_INIT Requests ....................5
    2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
    2.5. Invalid Cookies ............................................8
 3. Authentication ..................................................9
    3.1. Data Included in AUTH Payload Calculation ..................9
    3.2. Hash Function for RSA Signatures ...........................9
    3.3. Encoding Method for RSA Signatures ........................10
    3.4. Identification Type for EAP ...............................11
    3.5. Identity for Policy Lookups When Using EAP ................11
    3.6. Certificate Encoding Types ................................12
    3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
    3.8. EAP Authentication and Fixed PRF Key Size .................13
    3.9. Matching ID Payloads to Certificate Contents ..............13
    3.10. Message IDs for IKE_AUTH Messages ........................14
 4. Creating CHILD_SAs .............................................14
    4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
    4.2. Creating an IKE_SA without a CHILD_SA .....................16
    4.3. Diffie-Hellman for First CHILD_SA .........................16
    4.4. Extended Sequence Numbers (ESN) Transform .................17
    4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
    4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
    4.7. Semantics of Complex Traffic Selector Payloads ............18
    4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
    4.9. Mobility Header in Traffic Selector Payloads ..............20
    4.10. Narrowing the Traffic Selectors ..........................20
    4.11. SINGLE_PAIR_REQUIRED .....................................21
    4.12. Traffic Selectors Violating Own Policy ...................21
    4.13. Traffic Selector Authorization ...........................22
 5. Rekeying and Deleting SAs ......................................23
    5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
    5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
    5.3. SPIs When Rekeying the IKE_SA .............................25
    5.4. SPI When Rekeying a CHILD_SA ..............................25
    5.5. Changing PRFs When Rekeying the IKE_SA ....................26
    5.6. Deleting vs. Closing SAs ..................................26
    5.7. Deleting a CHILD_SA Pair ..................................26
    5.8. Deleting an IKE_SA ........................................27
    5.9. Who is the original initiator of IKE_SA ...................27
    5.10. Comparing Nonces .........................................27
    5.11. Exchange Collisions ......................................28
    5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36

Eronen & Hoffman Informational [Page 2] RFC 4718 IKEv2 Clarifications October 2006

 6. Configuration Payloads .........................................37
    6.1. Assigning IP Addresses ....................................37
    6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
    6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
    6.4. INTERNAL_IP4_NETMASK ......................................41
    6.5. Configuration Payloads for IPv6 ...........................42
    6.6. INTERNAL_IP6_NBNS .........................................43
    6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
    6.8. Address Assignment Failures ...............................44
 7. Miscellaneous Issues ...........................................45
    7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
    7.2. Relationship of IKEv2 to RFC 4301 .........................45
    7.3. Reducing the Window Size ..................................46
    7.4. Minimum Size of Nonces ....................................46
    7.5. Initial Zero Octets on Port 4500 ..........................46
    7.6. Destination Port for NAT Traversal ........................47
    7.7. SPI Values for Messages outside an IKE_SA .................47
    7.8. Protocol ID/SPI Fields in Notify Payloads .................48
    7.9. Which message should contain INITIAL_CONTACT ..............48
    7.10. Alignment of Payloads ....................................48
    7.11. Key Length Transform Attribute ...........................48
    7.12. IPsec IANA Considerations ................................49
    7.13. Combining ESP and AH .....................................50
 8. Implementation Mistakes ........................................50
 9. Security Considerations ........................................51
 10. Acknowledgments ...............................................51
 11. References ....................................................51
    11.1. Normative References .....................................51
    11.2. Informative References ...................................52
 Appendix A. Exchanges and Payloads ................................54
    A.1. IKE_SA_INIT Exchange ......................................54
    A.2. IKE_AUTH Exchange without EAP .............................54
    A.3. IKE_AUTH Exchange with EAP ................................55
    A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
         CHILD_SAs .................................................56
    A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
    A.6. INFORMATIONAL Exchange ....................................56

Eronen & Hoffman Informational [Page 3] RFC 4718 IKEv2 Clarifications October 2006

1. Introduction

 This document clarifies many areas of the IKEv2 specification that
 may be difficult to understand to developers not intimately familiar
 with the specification and its history.  The clarifications in this
 document come from the discussion on the IPsec WG mailing list, from
 experience in interoperability testing, and from implementation
 issues that have been brought to the editors' attention.
 IKEv2/IPsec can be used for several different purposes, including
 IPsec-based remote access (sometimes called the "road warrior" case),
 site-to-site virtual private networks (VPNs), and host-to-host
 protection of application traffic.  While this document attempts to
 consider all of these uses, the remote access scenario has perhaps
 received more attention here than the other uses.
 This document does not place any requirements on anyone and does not
 use [RFC2119] keywords such as "MUST" and "SHOULD", except in
 quotations from the original IKEv2 documents.  The requirements are
 given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
 algorithms document [IKEv2ALG].
 In this document, references to a numbered section (such as "Section
 2.15") mean that section in [IKEv2].  References to mailing list
 messages or threads refer to the IPsec WG mailing list at
 ipsec@ietf.org.  Archives of the mailing list can be found at
 <http://www.ietf.org/mail-archive/web/ipsec/index.html>.

2. Creating the IKE_SA

2.1. SPI Values in IKE_SA_INIT Exchange

 Normal IKE messages include the initiator's and responder's Security
 Parameter Indexes (SPIs), both of which are non-zero, in the IKE
 header.  However, there are some corner cases where the IKEv2
 specification is not fully consistent about what values should be
 used.
 First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero
 in any other message" (than the first message of the IKE_SA_INIT
 exchange).  However, the figure in Section 2.6 shows the second
 IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
 in 3.1.
 Since the responder's SPI identifies security-related state held by
 the responder, and in this case no state is created, sending a zero
 value seems reasonable.

Eronen & Hoffman Informational [Page 4] RFC 4718 IKEv2 Clarifications October 2006

 Second, in addition to cookies, there are several other cases when
 the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
 (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  What
 responder SPI value should be used in the IKE_SA_INIT response in
 this case?
 Since the IKE_SA_INIT request always has a zero responder SPI, the
 value will not be actually used by the initiator.  Thus, we think
 sending a zero value is correct also in this case.
 If the responder sends a non-zero responder SPI, the initiator should
 not reject the response only for that reason.  However, when retrying
 the IKE_SA_INIT request, the initiator will use a zero responder SPI,
 as described in Section 3.1: "Responder's SPI [...]  This value MUST
 be zero in the first message of an IKE Initial Exchange (including
 repeats of that message including a cookie) [...]".  We believe the
 intent was to cover repeats of that message due to other reasons,
 such as INVALID_KE_PAYLOAD, as well.
 (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
 Sep-Oct 2005.)

2.2. Message IDs for IKE_SA_INIT Messages

 The Message ID for IKE_SA_INIT messages is always zero.  This
 includes retries of the message due to responses such as COOKIE and
 INVALID_KE_PAYLOAD.
 This is because Message IDs are part of the IKE_SA state, and when
 the responder replies to IKE_SA_INIT request with N(COOKIE) or
 N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
 (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
 combination" thread, Oct 2004.  Tero Kivinen's mail "Comments of
 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

2.3. Retransmissions of IKE_SA_INIT Requests

 When a responder receives an IKE_SA_INIT request, it has to determine
 whether the packet is a retransmission belonging to an existing
 "half-open" IKE_SA (in which case the responder retransmits the same
 response), or a new request (in which case the responder creates a
 new IKE_SA and sends a fresh response).
 The specification does not describe in detail how this determination
 is done.  In particular, it is not sufficient to use the initiator's
 SPI and/or IP address for this purpose: two different peers behind a
 single NAT could choose the same initiator SPI (and the probability

Eronen & Hoffman Informational [Page 5] RFC 4718 IKEv2 Clarifications October 2006

 of this happening is not necessarily small, since IKEv2 does not
 require SPIs to be chosen randomly).  Instead, the responder should
 do the IKE_SA lookup using the whole packet or its hash (or at the
 minimum, the Ni payload which is always chosen randomly).
 For all other packets than IKE_SA_INIT requests, looking up right
 IKE_SA is of course done based on the recipient's SPI (either the
 initiator or responder SPI depending on the value of the Initiator
 bit in the IKE header).

2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD

 There are two common reasons why the initiator may have to retry the
 IKE_SA_INIT exchange: the responder requests a cookie or wants a
 different Diffie-Hellman group than was included in the KEi payload.
 Both of these cases are quite simple alone, but it is not totally
 obvious what happens when they occur at the same time, that is, the
 IKE_SA_INIT exchange is retried several times.
 The main question seems to be the following: if the initiator
 receives a cookie from the responder, should it include the cookie in
 only the next retry of the IKE_SA_INIT request, or in all subsequent
 retries as well?  Section 3.10.1 says that:
    "This notification MUST be included in an IKE_SA_INIT request
    retry if a COOKIE notification was included in the initial
    response."
 This could be interpreted as saying that when a cookie is received in
 the initial response, it is included in all retries.  On the other
 hand, Section 2.6 says that:
    "Initiators who receive such responses MUST retry the
    IKE_SA_INIT with a Notify payload of type COOKIE containing
    the responder supplied cookie data as the first payload and
    all other payloads unchanged."
 Including the same cookie in later retries makes sense only if the
 "all other payloads unchanged" restriction applies only to the first
 retry, but not to subsequent retries.
 It seems that both interpretations can peacefully coexist.  If the
 initiator includes the cookie only in the next retry, one additional
 roundtrip may be needed in some cases:

Eronen & Hoffman Informational [Page 6] RFC 4718 IKEv2 Clarifications October 2006

    Initiator                   Responder
   -----------                 -----------
    HDR(A,0), SAi1, KEi, Ni -->
                            <-- HDR(A,0), N(COOKIE)
    HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                            <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
    HDR(A,0), SAi1, KEi', Ni -->
                            <-- HDR(A,0), N(COOKIE')
    HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                            <-- HDR(A,B), SAr1, KEr, Nr
 An additional roundtrip is needed also if the initiator includes the
 cookie in all retries, but the responder does not support this
 functionality.  For instance, if the responder includes the SAi1 and
 KEi payloads in cookie calculation, it will reject the request by
 sending a new cookie (see also Section 2.5 of this document for more
 text about invalid cookies):
    Initiator                   Responder
   -----------                 -----------
    HDR(A,0), SAi1, KEi, Ni -->
                            <-- HDR(A,0), N(COOKIE)
    HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                            <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
    HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                            <-- HDR(A,0), N(COOKIE')
    HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                            <-- HDR(A,B), SAr1, KEr, Nr
 If both peers support including the cookie in all retries, a slightly
 shorter exchange can happen:
    Initiator                   Responder
   -----------                 -----------
    HDR(A,0), SAi1, KEi, Ni -->
                            <-- HDR(A,0), N(COOKIE)
    HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                            <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
    HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                            <-- HDR(A,B), SAr1, KEr, Nr
 This document recommends that implementations should support this
 shorter exchange, but it must not be assumed the other peer also
 supports the shorter exchange.

Eronen & Hoffman Informational [Page 7] RFC 4718 IKEv2 Clarifications October 2006

 In theory, even this exchange has one unnecessary roundtrip, as both
 the cookie and Diffie-Hellman group could be checked at the same
 time:
    Initiator                   Responder
   -----------                 -----------
    HDR(A,0), SAi1, KEi, Ni -->
                            <-- HDR(A,0), N(COOKIE),
                                          N(INVALID_KE_PAYLOAD)
    HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
                            <-- HDR(A,B), SAr1, KEr, Nr
 However, it is clear that this case is not allowed by the text in
 Section 2.6, since "all other payloads" clearly includes the KEi
 payload as well.
 (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
 Sep-Oct 2005.)

2.5. Invalid Cookies

 There has been some confusion what should be done when an IKE_SA_INIT
 request containing an invalid cookie is received ("invalid" in the
 sense that its contents do not match the value expected by the
 responder).
 The correct action is to ignore the cookie and process the message as
 if no cookie had been included (usually this means sending a response
 containing a new cookie).  This is shown in Section 2.6 when it says
 "The responder in that case MAY reject the message by sending another
 response with a new cookie [...]".
 Other possible actions, such as ignoring the whole request (or even
 all requests from this IP address for some time), create strange
 failure modes even in the absence of any malicious attackers and do
 not provide any additional protection against DoS attacks.
 (References: "Invalid Cookie" thread, Sep-Oct 2005.)

Eronen & Hoffman Informational [Page 8] RFC 4718 IKEv2 Clarifications October 2006

3. Authentication

3.1. Data Included in AUTH Payload Calculation

 Section 2.15 describes how the AUTH payloads are calculated; this
 calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr').  The
 text describes the method in words, but does not give clear
 definitions of what is signed or MACed (i.e., protected with a
 message authentication code).
 The initiator's signed octets can be described as:
     InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
     GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
     RealIKEHDR =  SPIi | SPIr |  . . . | Length
     RealMessage1 = RealIKEHDR | RestOfMessage1
     NonceRPayload = PayloadHeader | NonceRData
     InitiatorIDPayload = PayloadHeader | RestOfIDPayload
     RestOfInitIDPayload = IDType | RESERVED | InitIDData
     MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
 The responder's signed octets can be described as:
     ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
     GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
     RealIKEHDR =  SPIi | SPIr |  . . . | Length
     RealMessage2 = RealIKEHDR | RestOfMessage2
     NonceIPayload = PayloadHeader | NonceIData
     ResponderIDPayload = PayloadHeader | RestOfIDPayload
     RestOfRespIDPayload = IDType | RESERVED | InitIDData
     MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

3.2. Hash Function for RSA Signatures

 Section 3.8 says that RSA digital signature is "Computed as specified
 in section 2.15 using an RSA private key over a PKCS#1 padded hash."
 Unlike IKEv1, IKEv2 does not negotiate a hash function for the
 IKE_SA.  The algorithm for signatures is selected by the signing
 party who, in general, may not know beforehand what algorithms the
 verifying party supports.  Furthermore, [IKEv2ALG] does not say what
 algorithms implementations are required or recommended to support.
 This clearly has a potential for causing interoperability problems,
 since authentication will fail if the signing party selects an
 algorithm that is not supported by the verifying party, or not
 acceptable according to the verifying party's policy.

Eronen & Hoffman Informational [Page 9] RFC 4718 IKEv2 Clarifications October 2006

 This document recommends that all implementations support SHA-1 and
 use SHA-1 as the default hash function when generating the
 signatures, unless there are good reasons (such as explicit manual
 configuration) to believe that the peer supports something else.
 Note that hash function collision attacks are not important for the
 AUTH payloads, since they are not intended for third-party
 verification, and the data includes fresh nonces.  See [HashUse] for
 more discussion about hash function attacks and IPsec.
 Another reasonable choice would be to use the hash function that was
 used by the CA when signing the peer certificate.  However, this does
 not guarantee that the IKEv2 peer would be able to validate the AUTH
 payload, because the same code might not be used to validate
 certificate signatures and IKEv2 message signatures, and these two
 routines may support a different set of hash algorithms.  The peer
 could be configured with a fingerprint of the certificate, or
 certificate validation could be performed by an external entity using
 [SCVP].  Furthermore, not all CERT payloads types include a
 signature, and the certificate could be signed with some algorithm
 other than RSA.
 Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
 signature encoding method (see next section for details), which
 includes the algorithm identifier for the hash algorithm.  Thus, when
 the verifying party receives the AUTH payload it can at least
 determine which hash function was used.
 (References: Magnus Alstrom's mail "RE:", 2005-01-03.  Pasi Eronen's
 reply, 2005-01-04.  Tero Kivinen's reply, 2005-01-04.  "First draft
 of IKEv2.1" thread, Dec 2005/Jan 2006.)

3.3. Encoding Method for RSA Signatures

 Section 3.8 says that the RSA digital signature is "Computed as
 specified in section 2.15 using an RSA private key over a PKCS#1
 padded hash."
 The PKCS#1 specification [PKCS1v21] defines two different encoding
 methods (ways of "padding the hash") for signatures.  However, the
 Internet-Draft approved by the IESG had a reference to the older
 PKCS#1 v2.0 [PKCS1v20].  That version has only one encoding method
 for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.

Eronen & Hoffman Informational [Page 10] RFC 4718 IKEv2 Clarifications October 2006

 Note that this encoding method is different from the encoding method
 used in IKEv1.  If future revisions of IKEv2 provide support for
 other encoding methods (such as EMSA-PSS), they will be given new
 Auth Method numbers.
 (References: Pasi Eronen's mail "RE:", 2005-01-04.)

3.4. Identification Type for EAP

 Section 3.5 defines several different types for identification
 payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
 EAP [EAP] does not mandate the use of any particular type of
 identifier, but often EAP is used with Network Access Identifiers
 (NAIs) defined in [NAI].  Although NAIs look a bit like email
 addresses (e.g., "joe@example.com"), the syntax is not exactly the
 same as the syntax of email address in [RFC822].  This raises the
 question of which identification type should be used.
 This document recommends that ID_RFC822_ADDR identification type is
 used for those NAIs that include the realm component.  Therefore,
 responder implementations should not attempt to verify that the
 contents actually conform to the exact syntax given in [RFC822] or
 [RFC2822], but instead should accept any reasonable looking NAI.
 For NAIs that do not include the realm component, this document
 recommends using the ID_KEY_ID identification type.
 (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
 identifier issue with EAP" threads, Aug 2004.)

3.5. Identity for Policy Lookups When Using EAP

 When the initiator authentication uses EAP, it is possible that the
 contents of the IDi payload is used only for AAA routing purposes and
 selecting which EAP method to use.  This value may be different from
 the identity authenticated by the EAP method (see [EAP], Sections 5.1
 and 7.3).
 It is important that policy lookups and access control decisions use
 the actual authenticated identity.  Often the EAP server is
 implemented in a separate AAA server that communicates with the IKEv2
 responder using, e.g., RADIUS [RADEAP].  In this case, the
 authenticated identity has to be sent from the AAA server to the
 IKEv2 responder.
 (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2",
 2004-10-28.  "Policy lookups" thread, Oct/Nov 2004.  RFC 3748,
 Section 7.3.)

Eronen & Hoffman Informational [Page 11] RFC 4718 IKEv2 Clarifications October 2006

3.6. Certificate Encoding Types

 Section 3.6 defines a total of twelve different certificate encoding
 types, and continues that "Specific syntax is for some of the
 certificate type codes above is not defined in this document."
 However, the text does not provide references to other documents that
 would contain information about the exact contents and use of those
 values.
 Without this information, it is not possible to develop interoperable
 implementations.  Therefore, this document recommends that the
 following certificate encoding values should not be used before new
 specifications that specify their use are available.
      PKCS #7 wrapped X.509 certificate    1
      PGP Certificate                      2
      DNS Signed Key                       3
      Kerberos Token                       6
      SPKI Certificate                     9
 This document recommends that most implementations should use only
 those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
 "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
 URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
 (13).
 Furthermore, Section 3.7 says that the "Certificate Encoding" field
 for the Certificate Request payload uses the same values as for
 Certificate payload.  However, the contents of the "Certification
 Authority" field are defined only for X.509 certificates (presumably
 covering at least types 4, 10, 12, and 13).  This document recommends
 that other values should not be used before new specifications that
 specify their use are available.
 The "Raw RSA Key" type needs one additional clarification.  Section
 3.6 says it contains "a PKCS #1 encoded RSA key".  What this means is
 a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].

3.7. Shared Key Authentication and Fixed PRF Key Size

 Section 2.15 says that "If the negotiated prf takes a fixed-size key,
 the shared secret MUST be of that fixed size".  This statement is
 correct: the shared secret must be of the correct size.  If it is
 not, it cannot be used; there is no padding, truncation, or other
 processing involved to force it to that correct size.

Eronen & Hoffman Informational [Page 12] RFC 4718 IKEv2 Clarifications October 2006

 This requirement means that it is difficult to use these pseudo-
 random functions (PRFs) with shared key authentication.  The authors
 think this part of the specification was very poorly thought out, and
 using PRFs with a fixed key size is likely to result in
 interoperability problems.  Thus, we recommend that such PRFs should
 not be used with shared key authentication.  PRF_AES128_XCBC
 [RFC3664] originally used fixed key sizes; that RFC has been updated
 to handle variable key sizes in [RFC4434].
 Note that Section 2.13 also contains text that is related to PRFs
 with fixed key size: "When the key for the prf function has fixed
 length, the data provided as a key is truncated or padded with zeros
 as necessary unless exceptional processing is explained following the
 formula".  However, this text applies only to the prf+ construction,
 so it does not contradict the text in Section 2.15.
 (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
 2003-05-02.  Hugo Krawczyk's reply, 2003-05-12.  Thread "Question
 about PRFs with fixed size key", Jan 2005.)

3.8. EAP Authentication and Fixed PRF Key Size

 As described in the previous section, PRFs with a fixed key size
 require a shared secret of exactly that size.  This restriction
 applies also to EAP authentication.  For instance, a PRF that
 requires a 128-bit key cannot be used with EAP since [EAP] specifies
 that the MSK is at least 512 bits long.
 (References: Thread "Question about PRFs with fixed size key", Jan
 2005.)

3.9. Matching ID Payloads to Certificate Contents

 In IKEv1, there was some confusion about whether or not the
 identities in certificates used to authenticate IKE were required to
 match the contents of the ID payloads.  The PKI4IPsec Working Group
 produced the document [PKI4IPsec] which covers this topic in much
 more detail.  However, Section 3.5 of [IKEv2] explicitly says that
 the ID payload "does not necessarily have to match anything in the
 CERT payload".

Eronen & Hoffman Informational [Page 13] RFC 4718 IKEv2 Clarifications October 2006

3.10. Message IDs for IKE_AUTH Messages

 According to Section 2.2, "The IKE_SA initial setup messages will
 always be numbered 0 and 1."  That is true when the IKE_AUTH exchange
 does not use EAP.  When EAP is used, each pair of messages has their
 message numbers incremented.  The first pair of AUTH messages will
 have an ID of 1, the second will be 2, and so on.
 (References: "Question about MsgID in AUTH exchange" thread, April
 2005.)

4. Creating CHILD_SAs

4.1. Creating SAs with the CREATE_CHILD_SA Exchange

 Section 1.3's organization does not lead to clear understanding of
 what is needed in which environment.  The section can be reorganized
 with subsections for each use of the CREATE_CHILD_SA exchange
 (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
 The new Section 1.3 with subsections and the above changes might look
 like the following.
 NEW-1.3 The CREATE_CHILD_SA Exchange
      The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
      to rekey both IKE_SAs and CHILD_SAs.  This exchange consists of
      a single request/response pair, and some of its function was
      referred to as a phase 2 exchange in IKEv1.  It MAY be initiated
      by either end of the IKE_SA after the initial exchanges are
      completed.
      All messages following the initial exchange are
      cryptographically protected using the cryptographic algorithms
      and keys negotiated in the first two messages of the IKE
      exchange.  These subsequent messages use the syntax of the
      Encrypted Payload described in section 3.14.  All subsequent
      messages include an Encrypted Payload, even if they are referred
      to in the text as "empty".
      The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
      This section describes the first part of rekeying, the creation
      of new SAs; Section 2.8 covers the mechanics of rekeying,
      including moving traffic from old to new SAs and the deletion of
      the old SAs.  The two sections must be read together to
      understand the entire process of rekeying.

Eronen & Hoffman Informational [Page 14] RFC 4718 IKEv2 Clarifications October 2006

      Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
      this section the term initiator refers to the endpoint
      initiating this exchange.  An implementation MAY refuse all
      CREATE_CHILD_SA requests within an IKE_SA.
      The CREATE_CHILD_SA request MAY optionally contain a KE payload
      for an additional Diffie-Hellman exchange to enable stronger
      guarantees of forward secrecy for the CHILD_SA or IKE_SA.  The
      keying material for the SA is a function of SK_d established
      during the establishment of the IKE_SA, the nonces exchanged
      during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
      value (if KE payloads are included in the CREATE_CHILD_SA
      exchange).  The details are described in sections 2.17 and 2.18.
      If a CREATE_CHILD_SA exchange includes a KEi payload, at least
      one of the SA offers MUST include the Diffie-Hellman group of
      the KEi.  The Diffie-Hellman group of the KEi MUST be an element
      of the group the initiator expects the responder to accept
      (additional Diffie-Hellman groups can be proposed).  If the
      responder rejects the Diffie-Hellman group of the KEi payload,
      the responder MUST reject the request and indicate its preferred
      Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
      payload.  In the case of such a rejection, the CREATE_CHILD_SA
      exchange fails, and the initiator SHOULD retry the exchange with
      a Diffie-Hellman proposal and KEi in the group that the
      responder gave in the INVALID_KE_PAYLOAD.
 NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
      A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
      The CREATE_CHILD_SA request for creating a new CHILD_SA is:
          Initiator                                 Responder
         -----------                               -----------
          HDR, SK {[N+], SA, Ni, [KEi],
                     TSi, TSr}        -->
      The initiator sends SA offer(s) in the SA payload, a nonce in
      the Ni payload, optionally a Diffie-Hellman value in the KEi
      payload, and the proposed traffic selectors for the proposed
      CHILD_SA in the TSi and TSr payloads.  The request can also
      contain Notify payloads that specify additional details for the
      CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
      ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.

Eronen & Hoffman Informational [Page 15] RFC 4718 IKEv2 Clarifications October 2006

      The CREATE_CHILD_SA response for creating a new CHILD_SA is:
                                     <--    HDR, SK {[N+], SA, Nr,
                                                  [KEr], TSi, TSr}
      The responder replies with the accepted offer in an SA payload,
      and a Diffie-Hellman value in the KEr payload if KEi was
      included in the request and the selected cryptographic suite
      includes that group.  As with the request, optional Notification
      payloads can specify additional details for the CHILD_SA.
      The traffic selectors for traffic to be sent on that SA are
      specified in the TS payloads in the response, which may be a
      subset of what the initiator of the CHILD_SA proposed.
 The text about rekeying SAs can be found in Section 5.1 of this
 document.

4.2. Creating an IKE_SA without a CHILD_SA

 CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
 exchange, or using a separate CREATE_CHILD_SA exchange.  The
 specification is not clear about what happens if creating the
 CHILD_SA during the IKE_AUTH exchange fails for some reason.
 Our recommendation in this situation is that the IKE_SA is created as
 usual.  This is also in line with how the CREATE_CHILD_SA exchange
 works: a failure to create a CHILD_SA does not close the IKE_SA.
 The list of responses in the IKE_AUTH exchange that do not prevent an
 IKE_SA from being set up include at least the following:
 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
 (References: "Questions about internal address" thread, April 2005.)

4.3. Diffie-Hellman for First CHILD_SA

 Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
 Ni/Nr payloads.  This implies that the SA payload in IKE_AUTH
 exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
 any other value than NONE.  Implementations should probably leave the
 transform out entirely in this case.

Eronen & Hoffman Informational [Page 16] RFC 4718 IKEv2 Clarifications October 2006

4.4. Extended Sequence Numbers (ESN) Transform

 The description of the ESN transform in Section 3.3 has be proved
 difficult to understand.  The ESN transform has the following
 meaning:
 o  A proposal containing one ESN transform with value 0 means "do not
    use extended sequence numbers".
 o  A proposal containing one ESN transform with value 1 means "use
    extended sequence numbers".
 o  A proposal containing two ESN transforms with values 0 and 1 means
    "I support both normal and extended sequence numbers, you choose".
    (Obviously this case is only allowed in requests; the response
    will contain only one ESN transform.)
 In most cases, the exchange initiator will include either the first
 or third alternative in its SA payload.  The second alternative is
 rarely useful for the initiator: it means that using normal sequence
 numbers is not acceptable (so if the responder does not support ESNs,
 the exchange will fail with NO_PROPOSAL_CHOSEN).
 Note that including the ESN transform is mandatory when creating
 ESP/AH SAs (it was optional in earlier drafts of the IKEv2
 specification).
 (References: "Technical change needed to IKEv2 before publication",
 "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
 and "Results of straw poll regarding: IKEv2 interoperability issue"
 threads, March-April 2005.)

4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED

 The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
 Section 3.10.1 says that "This notification asserts that the sending
 endpoint will NOT accept packets that contain Flow Confidentiality
 (TFC) padding".
 However, the text does not say in which messages this notification
 should be included, or whether the scope of this notification is a
 single CHILD_SA or all CHILD_SAs of the peer.
 Our interpretation is that the scope is a single CHILD_SA, and thus
 this notification is included in messages containing an SA payload
 negotiating a CHILD_SA.  If neither endpoint accepts TFC padding,
 this notification will be included in both the request proposing an
 SA and the response accepting it.  If this notification is included

Eronen & Hoffman Informational [Page 17] RFC 4718 IKEv2 Clarifications October 2006

 in only one of the messages, TFC padding can still be sent in one
 direction.

4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO

 NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
 simply as "Used for fragmentation control.  See [RFC4301] for
 explanation."
 [RFC4301] says "Implementations that will transmit non-initial
 fragments on a tunnel mode SA that makes use of non-trivial port (or
 ICMP type/code or MH type) selectors MUST notify a peer via the IKE
 NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.  The peer MUST reject this
 proposal if it will not accept non-initial fragments in this context.
 If an implementation does not successfully negotiate transmission of
 non-initial fragments for such an SA, it MUST NOT send such fragments
 over the SA."
 However, it is not clear exactly how the negotiation works.  Our
 interpretation is that the negotiation works the same way as for
 IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
 is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
 in both the request proposing an SA and the response accepting it.
 In other words, if the peer "rejects this proposal", it only omits
 NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
 reject the whole CHILD_SA creation.

4.7. Semantics of Complex Traffic Selector Payloads

 As described in Section 3.13, the TSi/TSr payloads can include one or
 more individual traffic selectors.
 There is no requirement that TSi and TSr contain the same number of
 individual traffic selectors.  Thus, they are interpreted as follows:
 a packet matches a given TSi/TSr if it matches at least one of the
 individual selectors in TSi, and at least one of the individual
 selectors in TSr.
 For instance, the following traffic selectors:
      TSi = ((17, 100, 192.0.1.66-192.0.1.66),
             (17, 200, 192.0.1.66-192.0.1.66))
      TSr = ((17, 300, 0.0.0.0-255.255.255.255),
             (17, 400, 0.0.0.0-255.255.255.255))
 would match UDP packets from 192.0.1.66 to anywhere, with any of the
 four combinations of source/destination ports (100,300), (100,400),
 (200,300), and (200, 400).

Eronen & Hoffman Informational [Page 18] RFC 4718 IKEv2 Clarifications October 2006

 This implies that some types of policies may require several CHILD_SA
 pairs.  For instance, a policy matching only source/destination ports
 (100,300) and (200,400), but not the other two combinations, cannot
 be negotiated as a single CHILD_SA pair using IKEv2.
 (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.8. ICMP Type/Code in Traffic Selector Payloads

 The traffic selector types 7 and 8 can also refer to ICMP type and
 code fields.  As described in Section 3.13.1, "For the ICMP protocol,
 the two one-octet fields Type and Code are treated as a single 16-bit
 integer (with Type in the most significant eight bits and Code in the
 least significant eight bits) port number for the purposes of
 filtering based on this field."
 Since ICMP packets do not have separate source and destination port
 fields, there is some room for confusion what exactly the four TS
 payloads (two in the request, two in the response, each containing
 both start and end port fields) should contain.
 The answer to this question can be found from [RFC4301] Section
 4.4.1.3.
 To give a concrete example, if a host at 192.0.1.234 wants to create
 a transport mode SA for sending "Destination Unreachable" packets
 (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
 over this SA pair, the CREATE_CHILD_SA exchange would look like this:
    Initiator                   Responder
   -----------                 -----------
    HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
              TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
              TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
       <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                     TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                     TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
 Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
 created in this case, even though the second SA is never used for
 data traffic.
 An exchange creating an SA pair that can be used both for sending and
 receiving "Destination Unreachable" places the same value in all the
 port:

Eronen & Hoffman Informational [Page 19] RFC 4718 IKEv2 Clarifications October 2006

    Initiator                   Responder
   -----------                 -----------
    HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
              TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
              TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
       <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                     TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                     TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
 (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)

4.9. Mobility Header in Traffic Selector Payloads

 Traffic selectors can use IP Protocol ID 135 to match the IPv6
 mobility header [MIPv6].  However, the IKEv2 specification does not
 define how to represent the "MH Type" field in traffic selectors.
 At some point, it was expected that this will be defined in a
 separate document later.  However, [RFC4301] says that "For IKE, the
 IPv6 mobility header message type (MH type) is placed in the most
 significant eight bits of the 16 bit local "port" selector".  The
 direction semantics of TSi/TSr port fields are the same as for ICMP
 and are described in the previous section.
 (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
 message type as selector", 2003-10-14.  "ICMP and MH TSs for IKEv2"
 thread, Sep 2005.)

4.10. Narrowing the Traffic Selectors

 Section 2.9 describes how traffic selectors are negotiated when
 creating a CHILD_SA.  A more concise summary of the narrowing process
 is presented below.
 o  If the responder's policy does not allow any part of the traffic
    covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
 o  If the responder's policy allows the entire set of traffic covered
    by TSi/TSr, no narrowing is necessary, and the responder can
    return the same TSi/TSr values.
 o  Otherwise, narrowing is needed.  If the responder's policy allows
    all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
    in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
    acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].

Eronen & Hoffman Informational [Page 20] RFC 4718 IKEv2 Clarifications October 2006

 o  If the responder's policy does not allow all traffic covered by
    TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
    an acceptable subset of TSi/TSr.
 In the last two cases, there may be several subsets that are
 acceptable (but their union is not); in this case, the responder
 arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
 notification in the response.

4.11. SINGLE_PAIR_REQUIRED

 The description of the SINGLE_PAIR_REQUIRED notify payload in
 Sections 2.9 and 3.10.1 is not fully consistent.
 We do not attempt to describe this payload in this document either,
 since it is expected that most implementations will not have policies
 that require separate SAs for each address pair.
 Thus, if only some part (or parts) of the TSi/TSr proposed by the
 initiator is (are) acceptable to the responder, most responders
 should simply narrow TSi/TSr to an acceptable subset (as described in
 the last two paragraphs of Section 2.9), rather than use
 SINGLE_PAIR_REQUIRED.

4.12. Traffic Selectors Violating Own Policy

 Section 2.9 describes traffic selector negotiation in great detail.
 One aspect of this negotiation that may need some clarification is
 that when creating a new SA, the initiator should not propose traffic
 selectors that violate its own policy.  If this rule is not followed,
 valid traffic may be dropped.
 This is best illustrated by an example.  Suppose that host A has a
 policy whose effect is that traffic to 192.0.1.66 is sent via host B
 encrypted using Advanced Encryption Standard (AES), and traffic to
 all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
 using Triple Data Encryption Standard (3DES).  Suppose also that host
 B accepts any combination of AES and 3DES.
 If host A now proposes an SA that uses 3DES, and includes TSr
 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
 B.  Now, host B can also use this SA to send traffic from 192.0.1.66,
 but those packets will be dropped by A since it requires the use of
 AES for those traffic.  Even if host A creates a new SA only for
 192.0.1.66 that uses AES, host B may freely continue to use the first
 SA for the traffic.  In this situation, when proposing the SA, host A
 should have followed its own policy, and included a TSr containing
 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

Eronen & Hoffman Informational [Page 21] RFC 4718 IKEv2 Clarifications October 2006

 In general, if (1) the initiator makes a proposal "for traffic X
 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
 does not actually accept traffic X' with SA, and (3) the initiator
 would be willing to accept traffic X' with some SA' (!=SA), valid
 traffic can be unnecessarily dropped since the responder can apply
 either SA or SA' to traffic X'.
 (References: "Question about "narrowing" ..." thread, Feb 2005.
 "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
 Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
 negotiation examples", 2004-08-08.)

4.13. Traffic Selector Authorization

 IKEv2 relies on information in the Peer Authorization Database (PAD)
 when determining what kind of IPsec SAs a peer is allowed to create.
 This process is described in [RFC4301] Section 4.4.3.  When a peer
 requests the creation of an IPsec SA with some traffic selectors, the
 PAD must contain "Child SA Authorization Data" linking the identity
 authenticated by IKEv2 and the addresses permitted for traffic
 selectors.
 For example, the PAD might be configured so that authenticated
 identity "sgw23.example.com" is allowed to create IPsec SAs for
 192.0.2.0/24, meaning this security gateway is a valid
 "representative" for these addresses.  Host-to-host IPsec requires
 similar entries, linking, for example, "fooserver4.example.com" with
 192.0.1.66/32, meaning this identity a valid "owner" or
 "representative" of the address in question.
 As noted in [RFC4301], "It is necessary to impose these constraints
 on creation of child SAs to prevent an authenticated peer from
 spoofing IDs associated with other, legitimate peers."  In the
 example given above, a correct configuration of the PAD prevents
 sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents
 fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
 It is important to note that simply sending IKEv2 packets using some
 particular address does not imply a permission to create IPsec SAs
 with that address in the traffic selectors.  For example, even if
 sgw23 would be able to spoof its IP address as 192.0.1.66, it could
 not create IPsec SAs matching fooserver4's traffic.
 The IKEv2 specification does not specify how exactly IP address
 assignment using configuration payloads interacts with the PAD.  Our
 interpretation is that when a security gateway assigns an address

Eronen & Hoffman Informational [Page 22] RFC 4718 IKEv2 Clarifications October 2006

 using configuration payloads, it also creates a temporary PAD entry
 linking the authenticated peer identity and the newly allocated inner
 address.
 It has been recognized that configuring the PAD correctly may be
 difficult in some environments.  For instance, if IPsec is used
 between a pair of hosts whose addresses are allocated dynamically
 using Dynamic Host Configuration Protocol (DHCP), it is extremely
 difficult to ensure that the PAD specifies the correct "owner" for
 each IP address.  This would require a mechanism to securely convey
 address assignments from the DHCP server and link them to identities
 authenticated using IKEv2.
 Due to this limitation, some vendors have been known to configure
 their PADs to allow an authenticated peer to create IPsec SAs with
 traffic selectors containing the same address that was used for the
 IKEv2 packets.  In environments where IP spoofing is possible (i.e.,
 almost everywhere) this essentially allows any peer to create IPsec
 SAs with any traffic selectors.  This is not an appropriate or secure
 configuration in most circumstances.  See [Aura05] for an extensive
 discussion about this issue, and the limitations of host-to-host
 IPsec in general.

5. Rekeying and Deleting SAs

5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange

 Continued from Section 4.1 of this document.

NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange

    The CREATE_CHILD_SA request for rekeying an IKE_SA is:
        Initiator                                 Responder
       -----------                               -----------
        HDR, SK {SA, Ni, [KEi]} -->
    The initiator sends SA offer(s) in the SA payload, a nonce in
    the Ni payload, and optionally a Diffie-Hellman value in the KEi
    payload.
    The CREATE_CHILD_SA response for rekeying an IKE_SA is:
                                   <--    HDR, SK {SA, Nr, [KEr]}

Eronen & Hoffman Informational [Page 23] RFC 4718 IKEv2 Clarifications October 2006

    The responder replies (using the same Message ID to respond)
    with the accepted offer in an SA payload, a nonce in the Nr
    payload, and, optionally, a Diffie-Hellman value in the KEr
    payload.
    The new IKE_SA has its message counters set to 0, regardless of
    what they were in the earlier IKE_SA.  The window size starts at
    1 for any new IKE_SA.  The new initiator and responder SPIs are
    supplied in the SPI fields of the SA payloads.

NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange

    The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
        Initiator                                 Responder
       -----------                               -----------
        HDR, SK {N(REKEY_SA), [N+], SA,
            Ni, [KEi], TSi, TSr}  -->
    The leading Notify payload of type REKEY_SA identifies the
    CHILD_SA being rekeyed, and it contains the SPI that the initiator
    expects in the headers of inbound packets.  In addition, the
    initiator sends SA offer(s) in the SA payload, a nonce in the Ni
    payload, optionally a Diffie-Hellman value in the KEi payload,
    and the proposed traffic selectors in the TSi and TSr payloads.
    The request can also contain Notify payloads that specify
    additional details for the CHILD_SA.
    The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
                                   <--    HDR, SK {[N+], SA, Nr,
                                                [KEr], TSi, TSr}
    The responder replies with the accepted offer in an SA payload,
    and a Diffie-Hellman value in the KEr payload if KEi was
    included in the request and the selected cryptographic suite
    includes that group.
    The traffic selectors for traffic to be sent on that SA are
    specified in the TS payloads in the response, which may be a
    subset of what the initiator of the CHILD_SA proposed.

5.2. Rekeying the IKE_SA vs. Reauthentication

 Rekeying the IKE_SA and reauthentication are different concepts in
 IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA and
 resets the Message ID counters, but it does not authenticate the
 parties again (no AUTH or EAP payloads are involved).

Eronen & Hoffman Informational [Page 24] RFC 4718 IKEv2 Clarifications October 2006

 While rekeying the IKE_SA may be important in some environments,
 reauthentication (the verification that the parties still have access
 to the long-term credentials) is often more important.
 IKEv2 does not have any special support for reauthentication.
 Reauthentication is done by creating a new IKE_SA from scratch (using
 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
 payloads), creating new CHILD_SAs within the new IKE_SA (without
 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
 deletes the old CHILD_SAs as well).
 This means that reauthentication also establishes new keys for the
 IKE_SA and CHILD_SAs.  Therefore, while rekeying can be performed
 more often than reauthentication, the situation where "authentication
 lifetime" is shorter than "key lifetime" does not make sense.
 While creation of a new IKE_SA can be initiated by either party
 (initiator or responder in the original IKE_SA), the use of EAP
 authentication and/or configuration payloads means in practice that
 reauthentication has to be initiated by the same party as the
 original IKE_SA.  IKEv2 base specification does not allow the
 responder to request reauthentication in this case; however, this
 functionality is added in [ReAuth].
 (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)

5.3. SPIs When Rekeying the IKE_SA

 Section 2.18 says that "New initiator and responder SPIs are supplied
 in the SPI fields".  This refers to the SPI fields in the Proposal
 structures inside the Security Association (SA) payloads, not the SPI
 fields in the IKE header.
 (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
 Geoffrey Huang's reply, 2005-01-24.)

5.4. SPI When Rekeying a CHILD_SA

 Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
 identifies the SA being rekeyed."
 Since CHILD_SAs always exist in pairs, there are two different SPIs.
 The SPI placed in the REKEY_SA notification is the SPI the exchange
 initiator would expect in inbound ESP or AH packets (just as in
 Delete payloads).

Eronen & Hoffman Informational [Page 25] RFC 4718 IKEv2 Clarifications October 2006

5.5. Changing PRFs When Rekeying the IKE_SA

 When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
 new IKE_SA is computed using SK_d from the existing IKE_SA as
 follows:
    SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
 If the old and new IKE_SA selected a different PRF, it is not totally
 clear which PRF should be used.
 Since the rekeying exchange belongs to the old IKE_SA, it is the old
 IKE_SA's PRF that is used.  This also follows the principle that the
 same key (the old SK_d) should not be used with multiple
 cryptographic algorithms.
 Note that this may work poorly if the new IKE_SA's PRF has a fixed
 key size, since the output of the PRF may not be of the correct size.
 This supports our opinion earlier in the document that the use of
 PRFs with a fixed key size is a bad idea.
 (References: "Changing PRFs when rekeying the IKE_SA" thread, June
 2005.)

5.6. Deleting vs. Closing SAs

 The IKEv2 specification talks about "closing" and "deleting" SAs, but
 it is not always clear what exactly is meant.  However, other parts
 of the specification make it clear that when local state related to a
 CHILD_SA is removed, the SA must also be actively deleted with a
 Delete payload.
 In particular, Section 2.4 says that "If an IKE endpoint chooses to
 delete CHILD_SAs, it MUST send Delete payloads to the other end
 notifying it of the deletion".  Section 1.4 also explains that "ESP
 and AH SAs always exist in pairs, with one SA in each direction.
 When an SA is closed, both members of the pair MUST be closed."

5.7. Deleting a CHILD_SA Pair

 Section 1.4 describes how to delete SA pairs using the Informational
 exchange: "To delete an SA, an INFORMATIONAL exchange with one or
 more delete payloads is sent listing the SPIs (as they would be
 expected in the headers of inbound packets) of the SAs to be deleted.
 The recipient MUST close the designated SAs."

Eronen & Hoffman Informational [Page 26] RFC 4718 IKEv2 Clarifications October 2006

 The "one or more delete payloads" phrase has caused some confusion.
 You never send delete payloads for the two sides of an SA in a single
 message.  If you have many SAs to delete at the same time (such as
 the nested example given in that paragraph), you include delete
 payloads for the inbound half of each SA in your Informational
 exchange.

5.8. Deleting an IKE_SA

 Since IKE_SAs do not exist in pairs, it is not totally clear what the
 response message should contain when the request deleted the IKE_SA.
 Since there is no information that needs to be sent to the other side
 (except that the request was received), an empty Informational
 response seems like the most logical choice.
 (References: "Question about delete IKE SA" thread, May 2005.)

5.9. Who is the original initiator of IKE_SA

 In the IKEv2 document, "initiator" refers to the party who initiated
 the exchange being described, and "original initiator" refers to the
 party who initiated the whole IKE_SA.  However, there is some
 potential for confusion because the IKE_SA can be rekeyed by either
 party.
 To clear up this confusion, we propose that "original initiator"
 always refers to the party who initiated the exchange that resulted
 in the current IKE_SA.  In other words, if the "original responder"
 starts rekeying the IKE_SA, that party becomes the "original
 initiator" of the new IKE_SA.
 (References: Paul Hoffman's mail "Original initiator in IKEv2",
 2005-04-21.)

5.10. Comparing Nonces

 Section 2.8 about rekeying says that "If redundant SAs are created
 though such a collision, the SA created with the lowest of the four
 nonces used in the two exchanges SHOULD be closed by the endpoint
 that created it."

Eronen & Hoffman Informational [Page 27] RFC 4718 IKEv2 Clarifications October 2006

 Here "lowest" uses an octet-by-octet (lexicographical) comparison
 (instead of, for instance, comparing the nonces as large integers).
 In other words, start by comparing the first octet; if they're equal,
 move to the next octet, and so on.  If you reach the end of one
 nonce, that nonce is the lower one.
 (References: "IKEv2 rekeying question" thread, July 2005.)

5.11. Exchange Collisions

 Since IKEv2 exchanges can be initiated by both peers, it is possible
 that two exchanges affecting the same SA partly overlap.  This can
 lead to a situation where the SA state information is temporarily not
 synchronized, and a peer can receive a request it cannot process in a
 normal fashion.  Some of these corner cases are discussed in the
 specification, some are not.
 Obviously, using a window size greater than one leads to infinitely
 more complex situations, especially if requests are processed out of
 order.  In this section, we concentrate on problems that can arise
 even with window size 1.
 (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
 Jan 2006.  "Problem with exchanges collisions" thread, Dec 2005.)

5.11.1. Simultaneous CHILD_SA Close

 Probably the simplest case happens if both peers decide to close the
 same CHILD_SA pair at the same time:
    Host A                      Host B
   --------                    --------
    send req1: D(SPIa) -->
                            <-- send req2: D(SPIb)
                            --> recv req1
                            <-- send resp1: ()
    recv resp1
    recv req2
    send resp2: () -->
                            --> recv resp2
 This case is described in Section 1.4 and is handled by omitting the
 Delete payloads from the response messages.

Eronen & Hoffman Informational [Page 28] RFC 4718 IKEv2 Clarifications October 2006

5.11.2. Simultaneous IKE_SA Close

 Both peers can also decide to close the IKE_SA at the same time.  The
 desired end result is obvious; however, in certain cases the final
 exchanges may not be fully completed.
    Host A                      Host B
   --------                    --------
    send req1: D() -->
                            <-- send req2: D()
                            --> recv req1
 At this point, host B should reply as usual (with empty Informational
 response), close the IKE_SA, and stop retransmitting req2.  This is
 because once host A receives resp1, it may not be able to reply any
 longer.  The situation is symmetric, so host A should behave the same
 way.
    Host A                      Host B
   --------                    --------
                            <-- send resp1: ()
    send resp2: ()
 Even if neither resp1 nor resp2 ever arrives, the end result is still
 correct: the IKE_SA is gone.  The same happens if host A never
 receives req2.

5.11.3. Simultaneous CHILD_SA Rekeying

 Another case that is described in the specification is simultaneous
 rekeying.  Section 2.8 says
    "If the two ends have the same lifetime policies, it is possible
    that both will initiate a rekeying at the same time (which will
    result in redundant SAs).  To reduce the probability of this
    happening, the timing of rekeying requests SHOULD be jittered
    (delayed by a random amount of time after the need for rekeying is
    noticed).
    This form of rekeying may temporarily result in multiple similar
    SAs between the same pairs of nodes.  When there are two SAs
    eligible to receive packets, a node MUST accept incoming packets
    through either SA.  If redundant SAs are created though such a
    collision, the SA created with the lowest of the four nonces used
    in the two exchanges SHOULD be closed by the endpoint that created
    it."

Eronen & Hoffman Informational [Page 29] RFC 4718 IKEv2 Clarifications October 2006

 However, a better explanation on what impact this has on
 implementations is needed.  Assume that hosts A and B have an
 existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
 rekeying it at the same time:
    Host A                      Host B
   --------                    --------
    send req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),Ni1,..  -->
                            <-- send req2: N(REKEY_SA,SPIb1),
                                   SA(..,SPIb2,..),Ni2,..
    recv req2 <--
 At this point, A knows there is a simultaneous rekeying going on.
 However, it cannot yet know which of the exchanges will have the
 lowest nonce, so it will just note the situation and respond as
 usual.
    send resp2: SA(..,SPIa3,..),Nr1,.. -->
                            --> recv req1
 Now B also knows that simultaneous rekeying is going on.  Similarly
 as host A, it has to respond as usual.
                            <-- send resp1: SA(..,SPIb3,..),Nr2,..
     recv resp1 <--
                            --> recv resp2
 At this point, there are three CHILD_SA pairs between A and B (the
 old one and two new ones).  A and B can now compare the nonces.
 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
 B (the sender of req2) deletes the redundant new SA, and A (the node
 that initiated the surviving rekeyed SA) deletes the old one.
    send req3: D(SPIa1) -->
                            <-- send req4: D(SPIb2)
                            --> recv req3
                            <-- send resp4: D(SPIb1)
    recv req4 <--
    send resp4: D(SPIa3) -->
 The rekeying is now finished.
 However, there is a second possible sequence of events that can
 happen if some packets are lost in the network, resulting in
 retransmissions.  The rekeying begins as usual, but A's first packet
 (req1) is lost.

Eronen & Hoffman Informational [Page 30] RFC 4718 IKEv2 Clarifications October 2006

    Host A                      Host B
   --------                    --------
    send req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),Ni1,..  -->  (lost)
                            <-- send req2: N(REKEY_SA,SPIb1),
                                   SA(..,SPIb2,..),Ni2,..
    recv req2 <--
    send resp2: SA(..,SPIa3,..),Nr1,.. -->
                            --> recv resp2
                            <-- send req3: D(SPIb1)
    recv req3 <--
    send resp3: D(SPIa1) -->
                            --> recv resp3
 From B's point of view, the rekeying is now completed, and since it
 has not yet received A's req1, it does not even know that these was
 simultaneous rekeying.  However, A will continue retransmitting the
 message, and eventually it will reach B.
    resend req1 -->
                             --> recv req1
 What should B do in this point?  To B, it looks like A is trying to
 rekey an SA that no longer exists; thus failing the request with
 something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
 reasonable approach.
                             <-- send resp1: N(NO_PROPOSAL_CHOSEN)
    recv resp1 <--
 When A receives this error, it already knows there was simultaneous
 rekeying, so it can ignore the error message.

5.11.4. Simultaneous IKE_SA Rekeying

 Probably the most complex case occurs when both peers try to rekey
 the IKE_SA at the same time.  Basically, the text in Section 2.8
 applies to this case as well; however, it is important to ensure that
 the CHILD_SAs are inherited by the right IKE_SA.
 The case where both endpoints notice the simultaneous rekeying works
 the same way as with CHILD_SAs.  After the CREATE_CHILD_SA exchanges,
 three IKE_SAs exist between A and B; the one containing the lowest
 nonce inherits the CHILD_SAs.
 However, there is a twist to the other case where one rekeying
 finishes first:

Eronen & Hoffman Informational [Page 31] RFC 4718 IKEv2 Clarifications October 2006

    Host A                      Host B
   --------                    --------
    send req1:
       SA(..,SPIa1,..),Ni1,.. -->
                            <-- send req2: SA(..,SPIb1,..),Ni2,..
                            --> recv req1
                            <-- send resp1: SA(..,SPIb2,..),Nr2,..
    recv resp1 <--
    send req3: D() -->
                            --> recv req3
 At this point, host B sees a request to close the IKE_SA.  There's
 not much more to do than to reply as usual.  However, at this point
 host B should stop retransmitting req2, since once host A receives
 resp3, it will delete all the state associated with the old IKE_SA
 and will not be able to reply to it.
                            <-- send resp3: ()

5.11.5. Closing and Rekeying a CHILD_SA

 A case similar to simultaneous rekeying can occur if one peer decides
 to close an SA and the other peer tries to rekey it:
    Host A                      Host B
   --------                    --------
    send req1: D(SPIa) -->
                            <-- send req2: N(REKEY_SA,SPIb),SA,..
                            --> recv req1
 At this point, host B notices that host A is trying to close an SA
 that host B is currently rekeying.  Replying as usual is probably the
 best choice:
                            <-- send resp1: D(SPIb)
 Depending on in which order req2 and resp1 arrive, host A sees either
 a request to rekey an SA that it is currently closing, or a request
 to rekey an SA that does not exist.  In both cases,
 NO_PROPOSAL_CHOSEN is probably fine.
    recv req2
    recv resp1
    send resp2: N(NO_PROPOSAL_CHOSEN) -->
                            --> recv resp2

Eronen & Hoffman Informational [Page 32] RFC 4718 IKEv2 Clarifications October 2006

5.11.6. Closing a New CHILD_SA

 Yet another case occurs when host A creates a CHILD_SA pair, but soon
 thereafter host B decides to delete it (possible because its policy
 changed):
    Host A                      Host B
   --------                    --------
    send req1: [N(REKEY_SA,SPIa1)],
       SA(..,SPIa2,..),.. -->
                            --> recv req1
                     (lost) <-- send resp1: SA(..,SPIb2,..),..
                            <-- send req2: D(SPIb2)
    recv req2
 At this point, host A has not yet received message resp1 (and is
 retransmitting message req1), so it does not recognize SPIb in
 message req2.  What should host A do?
 One option would be to reply with an empty Informational response.
 However, this same reply would also be sent if host A has received
 resp1, but has already sent a new request to delete the SA that was
 just created.  This would lead to a situation where the peers are no
 longer in sync about which SAs exist between them.  However, host B
 would eventually notice that the other half of the CHILD_SA pair has
 not been deleted.  Section 1.4 describes this case and notes that "a
 node SHOULD regard half-closed connections as anomalous and audit
 their existence should they persist", and continues that "if
 connection state becomes sufficiently messed up, a node MAY close the
 IKE_SA".
 Another solution that has been proposed is to reply with an
 INVALID_SPI notification that contains SPIb.  This would explicitly
 tell host B that the SA was not deleted, so host B could try deleting
 it again later.  However, this usage is not part of the IKEv2
 specification and would not be in line with normal use of the
 INVALID_SPI notification where the data field contains the SPI the
 recipient of the notification would put in outbound packets.
 Yet another solution would be to ignore req2 at this time and wait
 until we have received resp1.  However, this alternative has not been
 fully analyzed at this time; in general, ignoring valid requests is
 always a bit dangerous, because both endpoints could do it, leading
 to a deadlock.
 This document recommends the first alternative.

Eronen & Hoffman Informational [Page 33] RFC 4718 IKEv2 Clarifications October 2006

5.11.7. Rekeying a New CHILD_SA

 Yet another case occurs when a CHILD_SA is rekeyed soon after it has
 been created:
    Host A                      Host B
   --------                    --------
    send req1: [N(REKEY_SA,SPIa1)],
       SA(..,SPIa2,..),..  -->
                     (lost) <-- send resp1: SA(..,SPIb2,..),..
                            <-- send req2: N(REKEY_SA,SPIb2),
                                   SA(..,SPIb3,..),..
    recv req2 <--
 To host A, this looks like a request to rekey an SA that does not
 exist.  Like in the simultaneous rekeying case, replying with
 NO_PROPOSAL_CHOSEN is probably reasonable:
    send resp2: N(NO_PROPOSAL_CHOSEN) -->
    recv resp1

5.11.8. Collisions with IKE_SA Rekeying

 Another set of cases occurs when one peer starts rekeying the IKE_SA
 at the same time the other peer starts creating, rekeying, or closing
 a CHILD_SA.  Suppose that host B starts creating a CHILD_SA, and soon
 after, host A starts rekeying the IKE_SA:
    Host A                      Host B
   --------                    --------
                            <-- send req1: SA,Ni1,TSi,TSr
    send req2: SA,Ni2,.. -->
                            --> recv req2
 What should host B do at this point?  Replying as usual would seem
 like a reasonable choice:
                            <-- send resp2: SA,Ni2,..
    recv resp2 <--
    send req3: D() -->
                            --> recv req3
 Now, a problem arises: If host B now replies normally with an empty
 Informational response, this will cause host A to delete state
 associated with the IKE_SA.  This means host B should stop
 retransmitting req1.  However, host B cannot know whether or not host
 A has received req1.  If host A did receive it, it will move the

Eronen & Hoffman Informational [Page 34] RFC 4718 IKEv2 Clarifications October 2006

 CHILD_SA to the new IKE_SA as usual, and the state information will
 then be out of sync.
 It seems this situation is tricky to handle correctly.  Our proposal
 is as follows: if a host receives a request to rekey the IKE_SA when
 it has CHILD_SAs in "half-open" state (currently being created or
 rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
 receives a request to create or rekey a CHILD_SA after it has started
 rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
 The case where CHILD_SAs are being closed is even worse.  Our
 recommendation is that if a host receives a request to rekey the
 IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
 closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
 receives a request to close a CHILD_SA after it has started rekeying
 the IKE_SA, it should reply with an empty Informational response.
 This ensures that at least the other peer will eventually notice that
 the CHILD_SA is still in "half-closed" state and will start a new
 IKE_SA from scratch.

5.11.9. Closing and Rekeying the IKE_SA

 The final case considered in this section occurs if one peer decides
 to close the IKE_SA while the other peer tries to rekey it.
    Host A                      Host B
   --------                    --------
    send req1: SA(..,SPIa1,..),Ni1 -->
                            <-- send req2: D()
                            --> recv req1
    recv req2 <--
 At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
 and host A should reply as usual, close the IKE_SA, and stop
 retransmitting req1.
                            <-- send resp1: N(NO_PROPOSAL_CHOSEN)
    send resp2: ()
 If host A wants to continue communication with B, it can now start a
 new IKE_SA.

5.11.10. Summary

 If a host receives a request to rekey:
 o  a CHILD_SA pair that the host is currently trying to close: reply
    with NO_PROPOSAL_CHOSEN.

Eronen & Hoffman Informational [Page 35] RFC 4718 IKEv2 Clarifications October 2006

 o  a CHILD_SA pair that the host is currently rekeying: reply as
    usual, but prepare to close redundant SAs later based on the
    nonces.
 o  a CHILD_SA pair that does not exist: reply with
    NO_PROPOSAL_CHOSEN.
 o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
    as usual, but prepare to close redundant SAs and move inherited
    CHILD_SAs later based on the nonces.
 o  the IKE_SA, and the host is currently creating, rekeying, or
    closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
 o  the IKE_SA, and the host is currently trying to close the IKE_SA:
    reply with NO_PROPOSAL_CHOSEN.
 If a host receives a request to close:
 o  a CHILD_SA pair that the host is currently trying to close: reply
    without Delete payloads.
 o  a CHILD_SA pair that the host is currently rekeying: reply as
    usual, with Delete payload.
 o  a CHILD_SA pair that does not exist: reply without Delete
    payloads.
 o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
    as usual, and forget about our own rekeying request.
 o  the IKE_SA, and the host is currently trying to close the IKE_SA:
    reply as usual, and forget about our own close request.
 If a host receives a request to create or rekey a CHILD_SA when it is
 currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
 If a host receives a request to delete a CHILD_SA when it is
 currently rekeying the IKE_SA: reply without Delete payloads.

5.12. Diffie-Hellman and Rekeying the IKE_SA

 There has been some confusion whether doing a new Diffie-Hellman
 exchange is mandatory when the IKE_SA is rekeyed.
 It seems that this case is allowed by the IKEv2 specification.
 Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
 Section 3.3.3 does not contradict this when it says that including

Eronen & Hoffman Informational [Page 36] RFC 4718 IKEv2 Clarifications October 2006

 the D-H transform is mandatory: although including the transform is
 mandatory, it can contain the value "NONE".
 However, having the option to skip the Diffie-Hellman exchange when
 rekeying the IKE_SA does not add useful functionality to the
 protocol.  The main purpose of rekeying the IKE_SA is to ensure that
 the compromise of old keying material does not provide information
 about the current keys, or vice versa.  This requires performing the
 Diffie-Hellman exchange when rekeying.  Furthermore, it is likely
 that this option would have been removed from the protocol as
 unnecessary complexity had it been discussed earlier.
 Given this, we recommend that implementations should have a hard-
 coded policy that requires performing a new Diffie-Hellman exchange
 when rekeying the IKE_SA.  In other words, the initiator should not
 propose the value "NONE" for the D-H transform, and the responder
 should not accept such a proposal.  This policy also implies that a
 successful exchange rekeying the IKE_SA always includes the KEi/KEr
 payloads.
 (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
 thread, Oct 2005.  "Comments of
 draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)

6. Configuration Payloads

6.1. Assigning IP Addresses

 Section 2.9 talks about traffic selector negotiation and mentions
 that "In support of the scenario described in section 1.1.3, an
 initiator may request that the responder assign an IP address and
 tell the initiator what it is."
 This sentence is correct, but its placement is slightly confusing.
 IKEv2 does allow the initiator to request assignment of an IP address
 from the responder, but this is done using configuration payloads,
 not traffic selector payloads.  An address in a TSi payload in a
 response does not mean that the responder has assigned that address
 to the initiator; it only means that if packets matching these
 traffic selectors are sent by the initiator, IPsec processing can be
 performed as agreed for this SA.  The TSi payload itself does not
 give the initiator permission to configure the initiator's TCP/IP
 stack with the address and use it as its source address.
 In other words, IKEv2 does not have two different mechanisms for
 assigning addresses, but only one: configuration payloads.  In the
 scenario described in Section 1.1.3, both configuration and traffic
 selector payloads are usually included in the same message, and they

Eronen & Hoffman Informational [Page 37] RFC 4718 IKEv2 Clarifications October 2006

 often contain the same information in the response message (see
 Section 6.3 of this document for some examples).  However, their
 semantics are still different.

6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS

 When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
 3.15.1 says that "In a request message, the address specified is a
 requested address (or zero if no specific address is requested)".
 The question here is whether "zero" means an address "0.0.0.0" or a
 zero-length string.
 Earlier, the same section also says that "If an attribute in the
 CFG_REQUEST Configuration Payload is not zero-length, it is taken as
 a suggestion for that attribute".  Also, the table of configuration
 attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
 octets".
 Thus, if the client does not request a specific address, it includes
 a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
 containing an all-zeroes address.  The example in 2.19 is thus
 incorrect, since it shows the attribute as
 "INTERNAL_ADDRESS(0.0.0.0)".
 However, since the value is only a suggestion, implementations are
 recommended to ignore suggestions they do not accept; or in other
 words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS,
 "0.0.0.0", and any other addresses the implementation does not
 recognize as a reasonable suggestion.

6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

 Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
 sub-networks that this edge-device protects.  This attribute is made
 up of two fields: the first is an IP address and the second is a
 netmask.  Multiple sub-networks MAY be requested.  The responder MAY
 respond with zero or more sub-network attributes."
 INTERNAL_IP6_SUBNET is defined in a similar manner.
 This raises two questions: first, since this information is usually
 included in the TSr payload, what functionality does this attribute
 add?  And second, what does this attribute mean in CFG_REQUESTs?
 For the first question, there seem to be two sensible
 interpretations.  Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
 response) indicates which subnets are accessible through the SA that
 was just created.

Eronen & Hoffman Informational [Page 38] RFC 4718 IKEv2 Clarifications October 2006

 The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
 that they indicate additional subnets that can be reached through
 this gateway, but need a separate SA.  According to this
 interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
 mainly when they contain addresses not included in TSr.
 The second interpretation is that the INTERNAL_IP4/6_SUBNET
 attributes express the gateway's policy about what traffic should be
 sent through the gateway.  The client can choose whether other
 traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
 through the gateway or directly to the destination.  According to
 this interpretation, the attributes are useful mainly when TSr
 contains addresses not included in the INTERNAL_IP4/6_SUBNET
 attributes.
 It turns out that these two interpretations are not incompatible, but
 rather two sides of the same principle: traffic to the addresses
 listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
 this gateway.  If there are no existing IPsec SAs whose traffic
 selectors cover the address in question, new SAs have to be created.
 A couple of examples are given below.  For instance, if there are two
 subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
 contains the following:
      CP(CFG_REQUEST) =
        INTERNAL_IP4_ADDRESS()
      TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
      TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
 Then a valid response could be the following (in which TSr and
 INTERNAL_IP4_SUBNET contain the same information):
      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
      TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
             (0, 0-65535, 192.0.2.0-192.0.2.255))
 In these cases, the INTERNAL_IP4_SUBNET does not really carry any
 useful information.  Another possible reply would have been this:
      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)

Eronen & Hoffman Informational [Page 39] RFC 4718 IKEv2 Clarifications October 2006

      TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
      TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
 This would mean that the client can send all its traffic through the
 gateway, but the gateway does not mind if the client sends traffic
 not included by INTERNAL_IP4_SUBNET directly to the destination
 (without going through the gateway).
 A different situation arises if the gateway has a policy that
 requires the traffic for the two subnets to be carried in separate
 SAs.  Then a response like this would indicate to the client that if
 it wants access to the second subnet, it needs to create a separate
 SA:
      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
      TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
 INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
 only part of the address space.  For instance, if the client requests
 the following:
      CP(CFG_REQUEST) =
        INTERNAL_IP4_ADDRESS()
      TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
      TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
 Then the gateway's reply could be this:
      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
      TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
 It is less clear what the attributes mean in CFG_REQUESTs, and
 whether other lengths than zero make sense in this situation (but for
 INTERNAL_IP6_SUBNET, zero length is not allowed at all!).  This
 document recommends that implementations should not include
 INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
 CFG_REQUESTs.
 For the IPv4 case, this document recommends using only netmasks
 consisting of some amount of "1" bits followed by "0" bits; for

Eronen & Hoffman Informational [Page 40] RFC 4718 IKEv2 Clarifications October 2006

 instance, "255.0.255.0" would not be a valid netmask for
 INTERNAL_IP4_SUBNET.
 It is also worthwhile to note that the contents of the INTERNAL_IP4/
 6_SUBNET attributes do not imply link boundaries.  For instance, a
 gateway providing access to a large company intranet using addresses
 from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
 attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
 routers and separate links.
 (References: Tero Kivinen's mail "Intent of couple of attributes in
 Configuration Payload in IKEv2?", 2004-11-19.  Srinivasa Rao
 Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
 IKEv2", 2004-09-10.  Yoav Nir's mail "Re: New I-D: IKEv2
 Clarifications and Implementation Guidelines", 2005-02-07.
 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
 April 2005.)

6.4. INTERNAL_IP4_NETMASK

 Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says
 that "The internal network's netmask.  Only one netmask is allowed in
 the request and reply messages (e.g., 255.255.255.0) and it MUST be
 used only with an INTERNAL_IP4_ADDRESS attribute".
 However, it is not clear what exactly this attribute means, as the
 concept of "netmask" is not very well defined for point-to-point
 links (unlike multi-access links, where it means "you can reach hosts
 inside this netmask directly using layer 2, instead of sending
 packets via a router").  Even if the operating system's TCP/IP stack
 requires a netmask to be configured, for point-to-point links it
 could be just set to 255.255.255.255.  So, why is this information
 sent in IKEv2?
 One possible interpretation would be that the host is given a whole
 block of IP addresses instead of a single address.  This is also what
 Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
 does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
 IPv6-Prefix attribute does in [RADIUS6].  However, nothing in the
 specification supports this interpretation, and discussions on the
 IPsec WG mailing list have confirmed it was not intended.  Section
 3.15.1 also says that multiple addresses are assigned using multiple
 INTERNAL_IP4/6_ADDRESS attributes.
 Currently, this document's interpretation is the following:
 INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
 INTERNAL_IP4_SUBNET containing the same information ("send traffic to
 these addresses through me"), but also implies a link boundary.  For

Eronen & Hoffman Informational [Page 41] RFC 4718 IKEv2 Clarifications October 2006

 instance, the client could use its own address and the netmask to
 calculate the broadcast address of the link.  (Whether the gateway
 will actually deliver broadcast packets to other VPN clients and/or
 other nodes connected to this link is another matter.)
 An empty INTERNAL_IP4_NETMASK attribute can be included in a
 CFG_REQUEST to request this information (although the gateway can
 send the information even when not requested).  However, it seems
 that non-empty values for this attribute do not make sense in
 CFG_REQUESTs.
 Fortunately, Section 4 clearly says that a minimal implementation
 does not need to include or understand the INTERNAL_IP4_NETMASK
 attribute, and thus this document recommends that implementations
 should not use the INTERNAL_IP4_NETMASK attribute or assume that the
 other peer supports it.
 (References: Charlie Kaufman's mail "RE: Proposed Last Call based
 revisions to IKEv2", 2004-05-27.  Email discussion with Tero Kivinen,
 Jan 2005.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
 Implementation Guidelines", 2005-02-07.  "Clarifications open issue:
 INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)

6.5. Configuration Payloads for IPv6

 IKEv2 also defines configuration payloads for IPv6.  However, they
 are based on the corresponding IPv4 payloads and do not fully follow
 the "normal IPv6 way of doing things".
 A client can be assigned an IPv6 address using the
 INTERNAL_IP6_ADDRESS configuration payload.  A minimal exchange could
 look like this:
      CP(CFG_REQUEST) =
        INTERNAL_IP6_ADDRESS()
        INTERNAL_IP6_DNS()
      TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
      TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
      CP(CFG_REPLY) =
        INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
        INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
      TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
      TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
 In particular, IPv6 stateless autoconfiguration or router
 advertisement messages are not used; neither is neighbor discovery.

Eronen & Hoffman Informational [Page 42] RFC 4718 IKEv2 Clarifications October 2006

 The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
 in the CFG_REQUEST to request a specific address or interface
 identifier.  The gateway first checks if the specified address is
 acceptable, and if it is, returns that one.  If the address was not
 acceptable, the gateway will attempt to use the interface identifier
 with some other prefix; if even that fails, the gateway will select
 another interface identifier.
 The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
 field.  When used in a CFG_REPLY, this corresponds to the
 INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
 called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
 See the previous section for more details.
 While this approach to configuring IPv6 addresses is reasonably
 simple, it has some limitations: IPsec tunnels configured using IKEv2
 are not fully-featured "interfaces" in the IPv6 addressing
 architecture [IPv6Addr] sense.  In particular, they do not
 necessarily have link-local addresses, and this may complicate the
 use of protocols that assume them, such as [MLDv2].  (Whether they
 are called "interfaces" in some particular operating system is a
 different issue.)
 (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
 "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
 April 2005.)

6.6. INTERNAL_IP6_NBNS

 Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
 the IPv6 address of NetBIOS name servers.
 However, NetBIOS is not defined for IPv6 and probably never will be.
 Thus, this attribute most likely does not make much sense.
 (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
 BoF at IETF62.)

6.7. INTERNAL_ADDRESS_EXPIRY

 Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
 "Specifies the number of seconds that the host can use the internal
 IP address.  The host MUST renew the IP address before this expiry
 time.  Only one of these attributes MAY be present in the reply."
 Expiry times and explicit renewals are primarily useful in
 environments like DHCP, where the server cannot reliably know when

Eronen & Hoffman Informational [Page 43] RFC 4718 IKEv2 Clarifications October 2006

 the client has gone away.  However, in IKEv2 this is known, and the
 gateway can simply free the address when the IKE_SA is deleted.
 Also, Section 4 says that supporting renewals is not mandatory.
 Given that this functionality is usually not needed, we recommend
 that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
 (And since this attribute does not seem to make much sense for
 CFG_REQUESTs, clients should not send it either.)
 Note that according to Section 4, clients are required to understand
 INTERNAL_ADDRESS_EXPIRY if they receive it.  A minimum implementation
 would use the value to limit the lifetime of the IKE_SA.
 (References: Tero Kivinen's mail "Comments of
 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
 "Questions about internal address" thread, April 2005.)

6.8. Address Assignment Failures

 If the responder encounters an error while attempting to assign an IP
 address to the initiator, it responds with an
 INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
 However, there are some more complex error cases.
 First, if the responder does not support configuration payloads at
 all, it can simply ignore all configuration payloads.  This type of
 implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
 If the initiator requires the assignment of an IP address, it will
 treat a response without CFG_REPLY as an error.
 A second case is where the responder does support configuration
 payloads, but only for particular type of addresses (IPv4 or IPv6).
 Section 4 says that "A minimal IPv4 responder implementation will
 ignore the contents of the CP payload except to determine that it
 includes an INTERNAL_IP4_ADDRESS attribute".  If, for instance, the
 initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
 in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
 IPv6 part and process the IPv4 request as usual.
 A third case is where the initiator requests multiple addresses of a
 type that the responder supports: what should happen if some (but not
 all) of the requests fail?  It seems that an optimistic approach
 would be the best one here: if the responder is able to assign at
 least one address, it replies with those; it sends
 INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
 (References: "ikev2 and internal_ivpn_address" thread, June 2005.)

Eronen & Hoffman Informational [Page 44] RFC 4718 IKEv2 Clarifications October 2006

7. Miscellaneous Issues

7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR

 When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
 payloads, IKEv2 does not require this address to match anything in
 the TSi/TSr payloads.  For example, in a site-to-site VPN between two
 security gateways, the gateways could authenticate each other as
 ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
 a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
 behind the first security gateway) and 192.0.2.240/28 (a network
 behind the second security gateway).  The authenticated identities
 (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
 using "Child SA Authorization Data" in the Peer Authorization
 Database (PAD).
 Furthermore, IKEv2 does not require that the addresses in
 ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
 IKE packets.  However, other specifications may place additional
 requirements regarding this.  For example, [PKI4IPsec] requires that
 implementation must be capable of comparing the addresses in the
 ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
 IKE packets, and this comparison must be enabled by default.
 (References: "Identities types IP address,FQDN/user FQDN and DN and
 its usage in preshared key authentication" thread, Jan 2005.
 "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)

7.2. Relationship of IKEv2 to RFC 4301

 The IKEv2 specification refers to [RFC4301], but it never clearly
 defines the exact relationship.
 However, there are some requirements in the specification that make
 it clear that IKEv2 requires [RFC4301].  In other words, an
 implementation that does IPsec processing strictly according to
 [RFC2401] cannot be compliant with the IKEv2 specification.
 One such example can be found in Section 2.24: "Specifically, tunnel
 encapsulators and decapsulators for all tunnel-mode SAs created by
 IKEv2 [...]  MUST implement the tunnel encapsulation and
 decapsulation processing specified in [RFC4301] to prevent discarding
 of ECN congestion indications."
 Nevertheless, the changes required to existing [RFC2401]
 implementations are not very large, especially since supporting many
 of the new features (such as Extended Sequence Numbers) is optional.

Eronen & Hoffman Informational [Page 45] RFC 4718 IKEv2 Clarifications October 2006

7.3. Reducing the Window Size

 In IKEv2, the window size is assumed to be a (possibly configurable)
 property of a particular implementation and is not related to
 congestion control (unlike the window size in TCP, for instance).
 In particular, it is not defined what the responder should do when it
 receives a SET_WINDOW_SIZE notification containing a smaller value
 than is currently in effect.  Thus, there is currently no way to
 reduce the window size of an existing IKE_SA.  However, when rekeying
 an IKE_SA, the new IKE_SA starts with window size 1 until it is
 explicitly increased by sending a new SET_WINDOW_SIZE notification.
 (References: Tero Kivinen's mail "Comments of
 draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

7.4. Minimum Size of Nonces

 Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
 MUST be at least 128 bits in size, and MUST be at least half the key
 size of the negotiated prf."
 However, the initiator chooses the nonce before the outcome of the
 negotiation is known.  In this case, the nonce has to be long enough
 for all the PRFs being proposed.

7.5. Initial Zero Octets on Port 4500

 It is not clear whether a peer sending an IKE_SA_INIT request on port
 4500 should include the initial four zero octets.  Section 2.23 talks
 about how to upgrade to tunneling over port 4500 after message 2, but
 it does not say what to do if message 1 is sent on port 4500.
     IKE MUST listen on port 4500 as well as port 500.
     [...]
     The IKE initiator MUST check these payloads if present and if
     they do not match the addresses in the outer packet MUST tunnel
     all future IKE and ESP packets associated with this IKE_SA over
     UDP port 4500.
     To tunnel IKE packets over UDP port 4500, the IKE header has four
     octets of zero prepended and the result immediately follows the
     UDP header. [...]

Eronen & Hoffman Informational [Page 46] RFC 4718 IKEv2 Clarifications October 2006

 The very beginning of Section 2 says "... though IKE messages may
 also be received on UDP port 4500 with a slightly different format
 (see section 2.23)."
 That "slightly different format" is only described in discussing what
 to do after changing to port 4500.  However, [RFC3948] shows clearly
 the format has the initial zeros even for initiators on port 4500.
 Furthermore, without the initial zeros, the processing engine cannot
 determine whether the packet is an IKE packet or an ESP packet.
 Thus, all packets sent on port 4500 need the four-zero prefix;
 otherwise, the receiver won't know how to handle them.

7.6. Destination Port for NAT Traversal

 Section 2.23 says that "an IPsec endpoint that discovers a NAT
 between it and its correspondent MUST send all subsequent traffic to
 and from port 4500".
 This sentence is misleading.  The peer "outside" the NAT uses source
 port 4500 for the traffic it sends, but the destination port is, of
 course, taken from packets sent by the peer behind the NAT.  This
 port number is usually dynamically allocated by the NAT.

7.7. SPI Values for Messages outside an IKE_SA

 The IKEv2 specification is not quite clear what SPI values should be
 used in the IKE header for the small number of notifications that are
 allowed to be sent outside an IKE_SA.  Note that such notifications
 are explicitly not Informational exchanges; Section 1.5 makes it
 clear that these are one-way messages that must not be responded to.
 There are two cases when such a one-way notification can be sent:
 INVALID_IKE_SPI and INVALID_SPI.
 In case of INVALID_IKE_SPI, the message sent is a response message,
 and Section 2.21 says that "If a response is sent, the response MUST
 be sent to the IP address and port from whence it came with the same
 IKE SPIs and the Message ID copied."
 In case of INVALID_SPI, however, there are no IKE SPI values that
 would be meaningful to the recipient of such a notification.  Also,
 the message sent is now an INFORMATIONAL request.  A strict
 interpretation of the specification would require the sender to
 invent garbage values for the SPI fields.  However, we think this was
 not the intention, and using zero values is acceptable.
 (References: "INVALID_IKE_SPI" thread, June 2005.)

Eronen & Hoffman Informational [Page 47] RFC 4718 IKEv2 Clarifications October 2006

7.8. Protocol ID/SPI Fields in Notify Payloads

 Section 3.10 says that the Protocol ID field in Notify payloads "For
 notifications that do not relate to an existing SA, this field MUST
 be sent as zero and MUST be ignored on receipt".  However, the
 specification does not clearly say which notifications are related to
 existing SAs and which are not.
 Since the main purpose of the Protocol ID field is to specify the
 type of the SPI, our interpretation is that the Protocol ID field
 should be non-zero only when the SPI field is non-empty.
 There are currently only two notifications where this is the case:
 INVALID_SELECTORS and REKEY_SA.

7.9. Which message should contain INITIAL_CONTACT

 The description of the INITIAL_CONTACT notification in Section 3.10.1
 says that "This notification asserts that this IKE_SA is the only
 IKE_SA currently active between the authenticated identities".
 However, neither Section 2.4 nor 3.10.1 says in which message this
 payload should be placed.
 The general agreement is that INITIAL_CONTACT is best communicated in
 the first IKE_AUTH request, not as a separate exchange afterwards.
 (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
 April 2005.  "Initial Contact messages" thread, December 2004.
 "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)

7.10. Alignment of Payloads

 Many IKEv2 payloads contain fields marked as "RESERVED", mostly
 because IKEv1 had them, and partly because they make the pictures
 easier to draw.  In particular, payloads in IKEv2 are not, in
 general, aligned to 4-octet boundaries.  (Note that payloads were not
 aligned to 4-octet boundaries in IKEv1 either.)
 (References: "IKEv2: potential 4-byte alignment problem" thread, June
 2004.)

7.11. Key Length Transform Attribute

 Section 3.3.5 says that "The only algorithms defined in this document
 that accept attributes are the AES based encryption, integrity, and
 pseudo-random functions, which require a single attribute specifying
 key width."

Eronen & Hoffman Informational [Page 48] RFC 4718 IKEv2 Clarifications October 2006

 This is incorrect.  The AES-based integrity and pseudo-random
 functions defined in [IKEv2] always use a 128-bit key.  In fact,
 there are currently no integrity or PRF algorithms that use the key
 length attribute (and we recommend that they should not be defined in
 the future either).
 For encryption algorithms, the situation is slightly more complex
 since there are three different types of algorithms:
 o  The key length attribute is never used with algorithms that use a
    fixed length key, such as DES and IDEA.
 o  The key length attribute is always included for the currently
    defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
    (CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
    (GCM)).  Omitting the key length attribute is not allowed; if the
    proposal does not contain it, the proposal has to be rejected.
 o  For other algorithms, the key length attribute can be included but
    is not mandatory.  These algorithms include, e.g., RC5, CAST, and
    BLOWFISH.  If the key length attribute is not included, the
    default value specified in [RFC2451] is used.

7.12. IPsec IANA Considerations

 There are currently three different IANA registry files that contain
 important numbers for IPsec: ikev2-registry, isakmp-registry, and
 ipsec-registry.  Implementers should note that IKEv2 may use numbers
 different from those of IKEv1 for a particular algorithm.
 For instance, an encryption algorithm can have up to three different
 numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
 the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
 registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
 isakmp-registry.  Although some algorithms have the same number in
 all three registries, the registries are not identical.
 Similarly, an integrity algorithm can have at least the IKEv2
 "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
 "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
 phase 2 ESP "Authentication Algorithm Security Association Attribute"
 identifier in isakmp-registry.  And there is also the IKEv1 phase 1
 "Hash Algorithm" list in ipsec-registry.
 This issue needs special care also when writing a specification for
 how a new algorithm is used with IPsec.

Eronen & Hoffman Informational [Page 49] RFC 4718 IKEv2 Clarifications October 2006

7.13. Combining ESP and AH

 The IKEv2 specification contains some misleading text about how ESP
 and AH can be combined.
 IKEv2 is based on [RFC4301], which does not include "SA bundles" that
 were part of [RFC2401].  While a single packet can go through IPsec
 processing multiple times, each of these passes uses a separate SA,
 and the passes are coordinated by the forwarding tables.  In IKEv2,
 each of these SAs has to be created using a separate CREATE_CHILD_SA
 exchange.  Thus, the text in Section 2.7 about a single proposal
 containing both ESP and AH is incorrect.
 Moreover, the combination of ESP and AH (between the same endpoints)
 had already become largely obsolete in 1998 when RFC 2406 was
 published.  Our recommendation is that IKEv2 implementations should
 not support this combination, and implementers should not assume the
 combination can be made to work in an interoperable manner.
 (References: "Rekeying SA bundles" thread, Oct 2005.)

8. Implementation Mistakes

 Some implementers at the early IKEv2 bakeoffs didn't do everything
 correctly.  This may seem like an obvious statement, but it is
 probably useful to list a few things that were clear in the document,
 but that some implementers didn't do.  All of these things caused
 interoperability problems.
 o  Some implementations continued to send traffic on a CHILD_SA after
    it was rekeyed, even after receiving an DELETE payload.
 o  After rekeying an IKE_SA, some implementations did not reset their
    message counters to zero.  One set the counter to 2, another did
    not reset the counter at all.
 o  Some implementations could only handle a single pair of traffic
    selectors or would only process the first pair in the proposal.
 o  Some implementations responded to a delete request by sending an
    empty INFORMATIONAL response and then initiated their own
    INFORMATIONAL exchange with the pair of SAs to delete.
 o  Although this did not happen at the bakeoff, from the discussion
    there, it is clear that some people had not implemented message
    window sizes correctly.  Some implementations might have sent

Eronen & Hoffman Informational [Page 50] RFC 4718 IKEv2 Clarifications October 2006

    messages that did not fit into the responder's message windows,
    and some implementations may not have torn down an SA if they did
    not ever receive a message that they know they should have.

9. Security Considerations

 This document does not introduce any new security considerations to
 IKEv2.  If anything, clarifying complex areas of the specification
 can reduce the likelihood of implementation problems that may have
 security implications.

10. Acknowledgments

 This document is mainly based on conversations on the IPsec WG
 mailing list.  The authors would especially like to thank Bernard
 Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
 Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
 Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
 contributions.
 In addition, the authors would like to thank all the participants of
 the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
 for their questions and proposed clarifications.

11. References

11.1. Normative References

 [IKEv2]       Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
               Protocol", RFC 4306, December 2005.
 [IKEv2ALG]    Schiller, J., "Cryptographic Algorithms for Use in the
               Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
               December 2005.
 [PKCS1v20]    Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
               Specifications Version 2.0", RFC 2437, October 1998.
 [PKCS1v21]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
               Standards (PKCS) #1: RSA Cryptography Specifications
               Version 2.1", RFC 3447, February 2003.
 [RFC2401]     Kent, S. and R. Atkinson, "Security Architecture for
               the Internet Protocol", RFC 2401, November 1998.
 [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.

Eronen & Hoffman Informational [Page 51] RFC 4718 IKEv2 Clarifications October 2006

11.2. Informative References

 [Aura05]      Aura, T., Roe, M., and A. Mohammed, "Experiences with
               Host-to-Host IPsec", 13th International Workshop on
               Security Protocols, Cambridge, UK, April 2005.
 [EAP]         Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
               H. Levkowetz, "Extensible Authentication Protocol
               (EAP)", RFC 3748, June 2004.
 [HashUse]     Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
               Work in Progress, July 2006.
 [IPCPSubnet]  Cisco Systems, Inc., "IPCP Subnet Mask Support
               Enhancements",  http://www.cisco.com/univercd/cc/td/
               doc/product/software/ios121/121newft/121limit/121dc/
               121dc3/ipcp_msk.htm, January 2003.
 [IPv6Addr]    Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.
 [MIPv6]       Johnson, D., Perkins, C., and J. Arkko, "Mobility
               Support in IPv6", RFC 3775, June 2004.
 [MLDv2]       Vida, R. and L. Costa, "Multicast Listener Discovery
               Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
 [NAI]         Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
               Network Access Identifier", RFC 4282, December 2005.
 [PKI4IPsec]   Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
               IKEv2, and PKIX", Work in Progress, April 2006.
 [RADEAP]      Aboba, B. and P. Calhoun, "RADIUS (Remote
               Authentication Dial In User Service) Support For
               Extensible Authentication Protocol (EAP)", RFC 3579,
               September 2003.
 [RADIUS]      Rigney, C., Willens, S., Rubens, A., and W. Simpson,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.
 [RADIUS6]     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
               RFC 3162, August 2001.
 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement  Levels", RFC 2119, March 1997.

Eronen & Hoffman Informational [Page 52] RFC 4718 IKEv2 Clarifications October 2006

 [RFC2451]     Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
               Algorithms", RFC 2451, November 1998.
 [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822,
               April 2001.
 [RFC3664]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
               Internet Key Exchange Protocol (IKE)", RFC 3664,
               January 2004.
 [RFC3948]     Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
               M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
               RFC 3948, January 2005.
 [RFC4434]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
               Internet Key Exchange Protocol (IKE)", RFC 4434,
               February 2006.
 [RFC822]      Crocker, D., "Standard for the format of ARPA Internet
               text messages", RFC 822, August 1982.
 [ReAuth]      Nir, Y., "Repeated Authentication in Internet Key
               Exchange (IKEv2) Protocol", RFC 4478, April 2006.
 [SCVP]        Freeman, T., Housley, R., Malpani, A., Cooper, D., and
               T. Polk, "Simple Certificate Validation Protocol
               (SCVP)", Work in Progress, June 2006.

Eronen & Hoffman Informational [Page 53] RFC 4718 IKEv2 Clarifications October 2006

Appendix A. Exchanges and Payloads

 This appendix contains a short summary of the IKEv2 exchanges, and
 what payloads can appear in which message.  This appendix is purely
 informative; if it disagrees with the body of this document or the
 IKEv2 specification, the other text is considered correct.
 Vendor-ID (V) payloads may be included in any place in any message.
 This sequence shows what are, in our opinion, the most logical places
 for them.
 The specification does not say which messages can contain
 N(SET_WINDOW_SIZE).  It can possibly be included in any message, but
 it is not yet shown below.

A.1. IKE_SA_INIT Exchange

 request             --> [N(COOKIE)],
                         SA, KE, Ni,
                         [N(NAT_DETECTION_SOURCE_IP)+,
                          N(NAT_DETECTION_DESTINATION_IP)],
                         [V+]
 normal response     <-- SA, KE, Nr,
 (no cookie)             [N(NAT_DETECTION_SOURCE_IP),
                          N(NAT_DETECTION_DESTINATION_IP)],
                         [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                         [V+]

A.2. IKE_AUTH Exchange without EAP

 request             --> IDi, [CERT+],
                         [N(INITIAL_CONTACT)],
                         [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                         [IDr],
                         AUTH,
                         [CP(CFG_REQUEST)],
                         [N(IPCOMP_SUPPORTED)+],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [V+]

Eronen & Hoffman Informational [Page 54] RFC 4718 IKEv2 Clarifications October 2006

 response            <-- IDr, [CERT+],
                         AUTH,
                         [CP(CFG_REPLY)],
                         [N(IPCOMP_SUPPORTED)],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [N(ADDITIONAL_TS_POSSIBLE)],
                         [V+]

A.3. IKE_AUTH Exchange with EAP

 first request       --> IDi,
                         [N(INITIAL_CONTACT)],
                         [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                         [IDr],
                         [CP(CFG_REQUEST)],
                         [N(IPCOMP_SUPPORTED)+],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [V+]
 first response      <-- IDr, [CERT+], AUTH,
                         EAP,
                         [V+]
                   / --> EAP
 repeat 1..N times |
                   \ <-- EAP
 last request        --> AUTH
 last response       <-- AUTH,
                         [CP(CFG_REPLY)],
                         [N(IPCOMP_SUPPORTED)],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [N(ADDITIONAL_TS_POSSIBLE)],
                         [V+]

Eronen & Hoffman Informational [Page 55] RFC 4718 IKEv2 Clarifications October 2006

A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs

 request             --> [N(REKEY_SA)],
                         [N(IPCOMP_SUPPORTED)+],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, Ni, [KEi], TSi, TSr
 response            <-- [N(IPCOMP_SUPPORTED)],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, Nr, [KEr], TSi, TSr,
                         [N(ADDITIONAL_TS_POSSIBLE)]

A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA

 request             --> SA, Ni, [KEi]
 response            <-- SA, Nr, [KEr]

A.6. INFORMATIONAL Exchange

 request             --> [N+],
                         [D+],
                         [CP(CFG_REQUEST)]
 response            <-- [N+],
                         [D+],
                         [CP(CFG_REPLY)]

Eronen & Hoffman Informational [Page 56] RFC 4718 IKEv2 Clarifications October 2006

Authors' Addresses

 Pasi Eronen
 Nokia Research Center
 P.O. Box 407
 FIN-00045 Nokia Group
 Finland
 EMail: pasi.eronen@nokia.com
 Paul Hoffman
 VPN Consortium
 127 Segre Place
 Santa Cruz, CA 95060
 USA
 EMail: paul.hoffman@vpnc.org

Eronen & Hoffman Informational [Page 57] RFC 4718 IKEv2 Clarifications October 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Eronen & Hoffman Informational [Page 58]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4718.txt · Last modified: 2006/10/26 17:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki