summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4718.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4718.txt')
-rw-r--r--doc/rfc/rfc4718.txt3251
1 files changed, 3251 insertions, 0 deletions
diff --git a/doc/rfc/rfc4718.txt b/doc/rfc/rfc4718.txt
new file mode 100644
index 0000000..35ad698
--- /dev/null
+++ b/doc/rfc/rfc4718.txt
@@ -0,0 +1,3251 @@
+
+
+
+
+
+
+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]
+