WDIFF

draft-eronen-ipsec-ikev2-clarifications-07.txt --> draft-eronen-ipsec-ikev2-clarifications-08.txt

Network Working Group P. Eronen
Internet-Draft Nokia
Expires: August 6, 25, 2006 P. Hoffman
VPN Consortium
February 2, 21, 2006

IKEv2 Clarifications and Implementation Guidelines
draft-eronen-ipsec-ikev2-clarifications-07.txt
draft-eronen-ipsec-ikev2-clarifications-08.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 6, 25, 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 Expires August 6, 25, 2006 [Page 1]

Internet-Draft IKEv2 Clarifications February 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 . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Data included in AUTH payload calculation . . . . . . . . 8
3.2. Hash function for RSA signatures . . . . . . . . . . . . . 9
3.3. Encoding method for RSA signatures . . . . . . . . . . . . 10
3.4. Identification type for EAP . . . . . . . . . . . . . . . 10
3.5. Identity for policy lookups when using EAP . . . . . . . . 11
3.6. (Section removed) . . . . . . . . . . . . . . . . . . . . 11
3.7. Certificate encoding types . . . . . . . . . . . . . . . . 11
3.8.
3.7. Shared key authentication and fixed PRF key size . . . . . 12
3.9.
3.8. EAP authentication and fixed PRF key size . . . . . . . . 13
3.10.
3.9. Matching ID payloads to certificate contents . . . . . . . 13
3.11.
3.10. Message IDs for IKE_AUTH messages . . . . . . . . . . . . 13
4. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . 16
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . . . . 17
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO . . . . . . . . . 17
4.7. Semantics of complex traffic selector payloads . . . . . . 18
4.8. ICMP type/code in traffic selector payloads . . . . . . . 18
4.9. Mobility header in traffic selector payloads . . . . . . . 19
4.10. Narrowing the traffic selectors . . . . . . . . . . . . . 20
4.11. SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . . 20
4.12. Traffic selectors violating own policy . . . . . . . . . . 21
4.13. Traffic selector authorization . . . . . . . . . . . . . . 21
5. Rekeying and deleting SAs . . . . . . . . . . . . . . . . . . 21 22
5.1. Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 21 23
5.2. Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 23 24
5.3. SPIs when rekeying the IKE_SA . . . . . . . . . . . . . . 23 25
5.4. SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 24 25
5.5. Changing PRFs when rekeying the IKE_SA . . . . . . . . . . 24 25
5.6. Deleting vs. closing SAs . . . . . . . . . . . . . . . . . 24 25
5.7. Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 25 26
5.8. Deleting an IKE_SA . . . . . . . . . . . . . . . . . . . . 25 26
5.9. Who is the original initiator of IKE_SA . . . . . . . . . 25 26
5.10. (Section removed) . Comparing nonces . . . . . . . . . . . . . . . . . . . 25
5.11. Comparing nonces . . 27
5.11. Exchange collisions . . . . . . . . . . . . . . . . . . . 26 27
5.12. Exchange collisions Diffie-Hellman and rekeying the IKE_SA . . . . . . . . . . 36
6. Configuration payloads . . . . . . . . . . 26
5.13. Diffie-Hellman and rekeying the IKE_SA . . . . . . . . . . 34 36

Eronen & Hoffman Expires August 6, 25, 2006 [Page 2]

Internet-Draft IKEv2 Clarifications February 2006

6. Configuration payloads . . . . . . . . . . . . . . . . . . . . 35

6.1. Assigning IP addresses . . . . . . . . . . . . . . . . . . 35
6.2. (Section removed) . . . . . . . . . . . . . . . . . . . . 36
6.3.
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 36
6.4. 37
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 36
6.5. 38
6.4. INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 39
6.6. 40
6.5. Configuration payloads for IPv6 . . . . . . . . . . . . . 40
6.7. 41
6.6. INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 42
6.8. 43
6.7. INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . . . . 42
6.9. 43
6.8. Address assignment failures . . . . . . . . . . . . . . . 42 43
7. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . . 43 44
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 43 44
7.2. Relationship of IKEv2 to RFC4301 . . . . . . . . . . . . . 43 44
7.3. Reducing the window size . . . . . . . . . . . . . . . . . 44 45
7.4. Minimum size of nonces . . . . . . . . . . . . . . . . . . 44 45
7.5. Initial zero octets on port 4500 . . . . . . . . . . . . . 44 45
7.6. Destination port for NAT traversal . . . . . . . . . . . . 45 46
7.7. SPI values for messages outside of an IKE_SA . . . . . . . 45 46
7.8. Protocol ID/SPI fields in Notify payloads . . . . . . . . 46 47
7.9. Which message should contain INITIAL_CONTACT . . . . . . . 46 47
7.10. Alignment of payloads . . . . . . . . . . . . . . . . . . 46 47
7.11. Key length transform attribute . . . . . . . . . . . . . . 47 48
7.12. IPsec IANA considerations . . . . . . . . . . . . . . . . 47 48
7.13. Combining ESP and AH . . . . . . . . . . . . . . . . . . . 48 49
8. Status of the clarifications . . . . . . . . . . . . . . . . . 48
9. Implementation mistakes . . . . . . . . . . . . . . . . . . . 50
10. 49
9. Security considerations . . . . . . . . . . . . . . . . . . . 51
11. 50
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 51
12. 50
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
13. 50
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
13.1. 50
12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
13.2. 50
12.2. Informative References . . . . . . . . . . . . . . . . . . 52 51
Appendix A. Exchanges and payloads . . . . . . . . . . . . . . . 53
A.1. IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 54 53
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . . . . 58

Eronen & Hoffman Expires August 6, 25, 2006 [Page 3]

Internet-Draft IKEv2 Clarifications February 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.

Readers are advised that this document is work-in-progress, and may
contain incorrect interpretations. Issues where the clarification is
known to be incomplete, or there is no consensus on what the the
interpretation should be, are marked as such.

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 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 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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 4]

Internet-Draft IKEv2 Clarifications February 2006

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.

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).

Eronen & Hoffman Expires August 6, 25, 2006 [Page 5]

Internet-Draft IKEv2 Clarifications February 2006

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
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 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 co-exist. If the
initiator includes the cookie only in the next retry, one additional
roundtrip may be needed in some cases:

Eronen & Hoffman Expires August 6, 25, 2006 [Page 6]

Internet-Draft IKEv2 Clarifications February 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. 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 this.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 7]

Internet-Draft IKEv2 Clarifications February 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.)

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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 8]

Internet-Draft IKEv2 Clarifications February 2006

The initiator's signed octets can be described as:

The responder's signed octets can be described as:

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.

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 other end 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 semi-reasonable choice would be to use the hash function that

Eronen & Hoffman Expires August 6, 25, 2006 [Page 9]

Internet-Draft IKEv2 Clarifications February 2006

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, since it does not necessarily check the certificate
signature. 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 other algorithm 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.

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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 10]

Internet-Draft IKEv2 Clarifications February 2006

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.)

3.6. (Section removed)

(This issue was corrected in RFC 4306.)

3.7. 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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 11]

Internet-Draft IKEv2 Clarifications February 2006

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

(Future versions of this document may also contain clarifications
about how these values are to be used.)

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.8.

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.

This requirement means that it is difficult to use these 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
[RFC3664bis].

Eronen & Hoffman Expires August 6, 25, 2006 [Page 12]

Internet-Draft IKEv2 Clarifications February 2006

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.9.

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.10.

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. There has been some work done
on this in the PKI4IPSEC Working Group, but that work is not finished
at this time. However, Section 3.5 explicitly says that the ID
payload "does not necessarily have to match anything in the CERT
payload".

3.11.

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 have 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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 13]

Internet-Draft IKEv2 Clarifications February 2006

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 this.

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.

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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 14]

Internet-Draft IKEv2 Clarifications February 2006

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.

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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 15]

Internet-Draft IKEv2 Clarifications February 2006

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 sitation 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.

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).

Eronen & Hoffman Expires August 6, 25, 2006 [Page 16]

Internet-Draft IKEv2 Clarifications February 2006

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
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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 17]

Internet-Draft IKEv2 Clarifications February 2006

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).

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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 18]

Internet-Draft IKEv2 Clarifications February 2006

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:

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,

Eronen & Hoffman Expires August 6, 25, 2006 [Page 19]

Internet-Draft IKEv2 Clarifications February 2006

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].

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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 20]

Internet-Draft IKEv2 Clarifications February 2006

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 AES, and traffic to all other hosts in 192.0.1.0/24
is also sent via B, but must use 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.

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.)

5. Rekeying and deleting SAs

5.1. Rekeying SAs with the CREATE_CHILD_SA exchange

Continued from

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.1 4.4.3. When a peer
requests the creation of this document.

NEW-1.3.2 Rekeying IKE_SAs an IPsec SA with some traffic selectors, the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request
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 rekeying an IKE_SA is:

Initiator Responder

Eronen & Hoffman Expires August 6, 25, 2006 [Page 21]

Internet-Draft IKEv2 Clarifications February 2006

----------- -----------
HDR, SK {SA, Ni, [KEi]} -->

The initiator sends SA offer(s) in the SA payload, a nonce in
the Ni payload, and optionally

192.0.2.0/24, meaning this security gateway is a Diffie-Hellman value in the KEi
payload.

The CREATE_CHILD_SA response valid
"representative" for rekeying an IKE_SA is:

<-- HDR, SK {SA, Nr, [KEr]}

The responder replies (using the same Message ID to respond) these addresses. Host-to-host IPsec requires
similar entries, linking, for example, "fooserver4.example.com" with the accepted offer in an SA payload,
192.0.1.66/32, meaning this identity a nonce in valid "owner" or
"representative" of the Nr
payload, and, optionally, a Diffie-Hellman value address in the KEr
payload.

The new IKE_SA has its message counters set question.

As noted in [RFC4301], "It is necessary to 0, regardless impose these constraints
on creation 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 child SAs to prevent an authenticated peer from
spoofing IDs associated with other, legitimate peers." In the SPI fields
example given above, a correct configuration of the SA payloads.

NEW-1.3.3 Rekeying CHILD_SAs PAD prevents
sgw23 from creating IPsec 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, address 192.0.1.66, and contains the SPI prevents
fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.

It is important to note 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 simply sending IKEv2 packets using some
particular address does not imply a Diffie-Hellman value permission to create IPsec SAs
with that address in the KEi payload,
and the proposed traffic selectors in the TSi and TSr payloads. 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 request can also contain Notify payloads that IKEv2 specification does not 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 how exactly IP address
assignment using configuration payloads interacts with the accepted offer in PAD. Our
interpretation is that when a security gateway assigns an SA payload,
and address
using configuration payloads, it also creates a Diffie-Hellman value in the KEr payload if KEi was
included in temporary PAD entry
linking the request authenticated peer identity and the selected cryptographic suite
includes that group.

Eronen & Hoffman Expires August 6, 2006 [Page 22]

Internet-Draft IKEv2 Clarifications February 2006

The traffic selectors for traffic to be sent on newly allocated inner
address.

It has been recognized that SA are
specified in the TS payloads in configuring the response, which PAD correctly may be a
subset of what the initiator
difficult in some environments. For instance, if IPsec is used
between a pair of the CHILD_SA proposed.

5.2. Rekeying the IKE_SA vs. reauthentication

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

While rekeying the IKE_SA may be important in some environments,
reauthentication (the verification is extremely difficult to ensure that the parties still have access
to PAD
specifies the long-term credentials) is often more important.

IKEv2 does not have any special support correct "owner" for reauthentication.
Reauthentication is done by creating each IP address. This would
require a new IKE_SA mechanism to securely convey address assignments 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),
DHCP server, and finally deleting the old IKE_SA (which
deletes 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 old CHILD_SAs as well).

This means same address that reauthentication also establishes new keys was used for the
IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
more often than reauthentication, the situation
IKEv2 packets. In environments where "authentication
lifetime" IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create IPsec
SAs with any traffic selectors. This is shorter than "key lifetime" does not make sense.

While creation of a new IKE_SA can be initiated by either party
(initiator an appropriate or responder secure
configuration 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 does not currently allow the responder to
request reauthentication in this case; however, there is ongoing work
to add most circumstances. See [Aura05] for an extensive
discussion about this functionality [ReAuth].

(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)

5.3. SPIs when rekeying the IKE_SA

Section 2.18 says that "New initiator issue, 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 limitations of host-to-host
IPsec in the IKE header.

(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
Geoffrey Huang's reply, 2005-01-24.) general.

5. Rekeying and deleting SAs

Eronen & Hoffman Expires August 6, 25, 2006 [Page 23] 22]

Internet-Draft IKEv2 Clarifications February 2006

5.4. SPI when rekeying a CHILD_SA

5.1. Rekeying SAs with the CREATE_CHILD_SA exchange

Continued from Section 3.10.1 says that 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 REKEY_SA notifications, "The SPI field
identifies the SA being rekeyed."

Since CHILD_SAs always exist payload, a nonce in pairs, there are two different SPIs.
The SPI placed
the Ni payload, and optionally a Diffie-Hellman value in the REKEY_SA notification is KEi
payload.

The CREATE_CHILD_SA response for rekeying an IKE_SA is:

<-- HDR, SK {SA, Nr, [KEr]}

The responder replies (using the SPI same Message ID to respond)
with the exchange
initiator would expect accepted offer in inbound ESP or AH packets (just as an SA payload, a nonce in the Nr
payload, and, optionally, a Diffie-Hellman value in
Delete payloads).

5.5. Changing PRFs when rekeying the KEr
payload.

The new IKE_SA

When rekeying has its message counters set to 0, regardless of
what they were in the IKE_SA, Section 2.18 says that "SKEYSEED earlier IKE_SA. The window size starts at
1 for the any new IKE_SA is computed using SK_d from IKE_SA. The new initiator and responder SPIs are
supplied in the existing IKE_SA as
follows:

SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"

If SPI fields of the old and new IKE_SA selected a different PRF, it is not totally
clear which PRF should be used.

Since SA payloads.

NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request for rekeying exchange belongs to 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 old IKE_SA, it is
CHILD_SA being rekeyed, and contains the old
IKE_SA's PRF SPI that is used. This also follows the principle that initiator
expects in the
same key (the old SK_d) should not be used with multiple
cryptographic algorithms.

Note that this may work poorly if headers of inbound packets. In addition, the new IKE_SA's PRF has
initiator sends SA offer(s) in the SA payload, a fixed
key size, since nonce in the output of Ni
payload, optionally a Diffie-Hellman value in the PRF may not be of KEi payload,
and the correct size.
This supports our opinion earlier proposed traffic selectors in the document TSi and TSr payloads.
The request can also contain Notify payloads that specify
additional details for 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." CHILD_SA.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 24] 23]

Internet-Draft IKEv2 Clarifications February 2006

5.7. Deleting

The CREATE_CHILD_SA response for rekeying a CHILD_SA pair

Section 1.4 describes how to delete SA pairs using the Informational
exchange: "To delete an is:

<-- HDR, SK {[N+], SA, an INFORMATIONAL exchange Nr,
[KEr], TSi, TSr}

The responder replies with one or
more delete payloads is sent listing the SPIs (as they would be
expected accepted offer in an SA payload,
and a Diffie-Hellman value in the headers of inbound packets) of KEr payload if KEi was
included in the SAs to be deleted.
The recipient MUST close request and the designated SAs." selected cryptographic suite
includes that group.

The "one or more delete payloads" phrase has caused some confusion.
You never send delete payloads traffic selectors for the two sides of an traffic to be sent on that SA are
specified 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 TS payloads for in 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 response, which may 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 a
subset of what the original initiator of IKE_SA

In the IKEv2 document, "initiator" refers to CHILD_SA proposed.

5.2. Rekeying the party who initiated IKE_SA vs. reauthentication

Rekeying the exchange being described, IKE_SA and "original initiator" refers to the
party who initiated reauthentication are different concepts in
IKEv2. Rekeying the whole IKE_SA. However, there is some
potential IKE_SA establishes new keys 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 which resulted
in the current IKE_SA. In other words, if and
resets the Message ID counters, but it does not authenticate the "original
responder" starts
parties again (no AUTH or EAP payloads are involved).

While rekeying the IKE_SA, IKE_SA may be important in some environments,
reauthentication (the verification that party becomes the
"original initiator" of parties still have access
to the new IKE_SA.

(References: Paul Hoffman's mail "Original initiator in IKEv2", 2005-
04-21.)

5.10. (Section removed)

(This issue was corrected in RFC 4306.)

Eronen & Hoffman Expires August 6, 2006 [Page 25]

Internet-Draft long-term credentials) is often more important.

IKEv2 Clarifications February 2006

5.11. Comparing nonces

Section 2.8 about rekeying says that "If redundant SAs are created
though such does not have any special support for reauthentication.
Reauthentication is done by creating a collision, the SA created with the lowest of new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the four
nonces used in new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the two exchanges SHOULD be closed by old IKE_SA (which
deletes the endpoint old CHILD_SAs as well).

This means that created it."

Here "lowest" uses an octet-by-octet (lexicographical) comparison
(instead of, reauthentication also establishes new keys 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,
IKE_SA and so on. If you reach the end of one
nonce, that nonce is the lower one.

(References: "IKEv2 CHILD_SAs. Therefore, while rekeying question" thread, July 2005.)

5.12. Exchange collisions

Since IKEv2 exchanges can be initiated by both peers, it is possible
that two exchanges affecting performed
more often than reauthentication, the same SA partly overlap. This can
lead to a situation where the SA state information "authentication
lifetime" is temporarily out shorter than "key lifetime" does not make sense.

While creation of sync, and a peer new IKE_SA can receive a request it cannot process be initiated by either party
(initiator or responder in a
normal fashion. Some the original IKE_SA), the use of these corner cases are discussed EAP
authentication and/or configuration payloads means 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 practice 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.12.1. Simultaneous CHILD_SA close

Probably the simplest case happens if both peers decide
reauthentication has to close be initiated by the same CHILD_SA pair at party as 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
original IKE_SA. IKEv2 does not currently allow the responder to
request reauthentication in this case; however, there is ongoing work
to add this functionality [ReAuth].

(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)

Eronen & Hoffman Expires August 6, 25, 2006 [Page 26] 24]

Internet-Draft IKEv2 Clarifications February 2006

This case is described in

5.3. SPIs when rekeying the IKE_SA

Section 1.4, 2.18 says that "New initiator and is handled by omitting the
Delete payloads from responder SPIs are supplied
in the response messages.

5.12.2. Simultaneous IKE_SA close

Both peers can also decide SPI fields". This refers to close the IKE_SA at the same time. The
desired end result is obvious; however, SPI fields 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 Proposal
structures inside the IKE_SA, and stop retransmitting req2. This is
because once host A receives resp1, it may Security Association (SA) payloads, not be able to reply any
longer. 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 situation SPI placed in the REKEY_SA notification 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, SPI the end result is still
correct: exchange
initiator would expect in inbound ESP or AH packets (just as in
Delete payloads).

5.5. Changing PRFs when rekeying the IKE_SA is gone. The same happens if host A never
receives req2.

5.12.3. Simultaneous CHILD_SA

When rekeying

Another case that is described in the specification is simultaneous
rekeying. IKE_SA, Section 2.8 2.18 says

"If that "SKEYSEED for the two ends have
new IKE_SA is computed using SK_d from the same lifetime policies, 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 possible
that both will initiate a not totally
clear which PRF should be used.

Since the rekeying at exchange belongs to the same time (which will
result in redundant SAs). To reduce old IKE_SA, it is the probability of this
happening, old
IKE_SA's PRF that is used. This also follows the timing of rekeying requests SHOULD be jittered
(delayed by a random amount of time after principle that the need for rekeying is
noticed).

This form of rekeying may temporarily result in
same key (the old SK_d) should not be used with multiple similar
SAs between
cryptographic algorithms.

Note that this may work poorly if 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 new IKE_SA's PRF has a
collision, fixed
key size, since the SA created with output of the lowest PRF may not be of the four nonces used correct size.
This supports our opinion earlier in the two exchanges SHOULD be closed by the endpoint document that created 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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 27] 25]

Internet-Draft IKEv2 Clarifications February 2006

it."

However,

of the specification make it clear that when local state related to a better explanation on what impact this has on
implementations
CHILD_SA is needed. Assume that hosts A and B have an
existing IPsec removed, the SA pair must also be actively deleted with SPIs (SPIa1,SPIb1), and both start
rekeying a
Delete payload.

In particular, Section 2.4 says that "If an IKE endpoint chooses to
delete CHILD_SAs, it at the same time:

Host A Host B
-------- --------
send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
<-- MUST 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 Delete payloads to the
lowest nonce, so other end
notifying it will just note of the situation and respond as
usual.

send resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req1

Now B deletion". Section 1.4 also knows explains 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 "ESP
and B can now compare the nonces.
Suppose that the lowest nonce was Nr1 AH SAs always exist in message resp2; pairs, with one SA in this case,
B (the sender each direction.
When an SA is closed, both members of req2) deletes the redundant new 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, and A (the node
that initiated an INFORMATIONAL exchange with one or
more delete payloads is sent listing the surviving rekeyed SA), deletes SPIs (as they would be
expected in 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 headers of inbound packets) of events that can
happen if some packets are lost in the network, resulting in
retransmissions. SAs to be deleted.
The rekeying begins as usual, but A's first packet

Eronen & Hoffman Expires August 6, 2006 [Page 28]

Internet-Draft IKEv2 Clarifications February 2006

(req1) is lost.

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 <-- recipient MUST close the designated SAs."

The "one or more delete payloads" phrase has caused some confusion.
You never send resp3: D(SPIa1) -->
--> recv resp3

From B's point delete payloads for the two sides of view, an SA in a single
message. If you have many SAs to delete at the rekeying is now completed, and since it
has same time (such as
the nested example given in that paragraph), you include delete
payloads for in inbound half of each SA in your Informational
exchange.

5.8. Deleting an IKE_SA

Since IKE_SAs do not yet received A's req1, exist in pairs, it does is not even know that these was
simultaneous rekeying. However, A will continue retransmitting totally clear what the
message, and eventually it will reach B.

resend req1 -->
--> recv req1

What
response message should B do in this point? To B, it looks like A contain when the request deleted the IKE_SA.

Since there is trying no information that needs to
rekey an SA be sent to the other side
(except that no longer exists; thus failing the request with
something non-fatal such as NO_PROPOSAL_CHOSEN was received), an empty Informational
response 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.12.4. Simultaneous IKE_SA rekeying

Probably the most complex case occurs when both peers try to rekey logical choice.

(References: "Question about delete IKE SA" thread, May 2005.)

5.9. Who is the original initiator of IKE_SA at the same time. Basically,

In the text in Section 2.8
applies to this case as well; however, it is important IKEv2 document, "initiator" refers 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 party who initiated
the CREATE_CHILD_SA exchanges,
three IKE_SAs exist between A exchange being described, and B; the one containing "original initiator" refers to the lowest
nonce inherits
party who initiated the CHILD_SAs. whole IKE_SA. However, there is a twist 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 which resulted
in the current IKE_SA. In other case where one words, if the the "original
responder" starts rekeying the IKE_SA, that party becomes the

Eronen & Hoffman Expires August 6, 25, 2006 [Page 29] 26]

Internet-Draft IKEv2 Clarifications February 2006

finishes first:

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

"original initiator" of the new 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

(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 old IKE_SA,
and will not lowest of the four
nonces used in the two exchanges SHOULD be able to reply to it.

<-- send resp3: ()

5.12.5. Closing and rekeying a CHILD_SA

A case similar to simultaneous rekeying can occur if one peers
decides to close closed by the endpoint
that created it."

Here "lowest" uses an SA and octet-by-octet (lexicographical) comparison
(instead of, for instance, comparing the nonces as large integers).
In other peer tries words, start by comparing the first octet; if they're equal,
move 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 the next octet, and so on. If you reach the end of one
nonce, that host A nonce is trying 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 close an a situation where the SA
that host B is currently rekeying. Replying as usual state information is probably the
best choice:

<-- send resp1: D(SPIb)

Depending on in which order req2 temporarily out
of sync, and resp1 arrive, host A sees either a peer can receive a request to rekey an SA that it is currently closing, or cannot process in a request
to rekey an SA that does not exist.
normal fashion. Some of these corner cases are discussed in the
specification, some are not.

(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 cases,
NO_PROPOSAL_CHOSEN is probably fine.

recv req2
recv resp1
send resp2: N(NO_PROPOSAL_CHOSEN) -->
--> recv resp2 peers decide to close the
same CHILD_SA pair at the same time:

Eronen & Hoffman Expires August 6, 25, 2006 [Page 30] 27]

Internet-Draft IKEv2 Clarifications February 2006

5.12.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,..),.. D(SPIa) -->
<-- send req2: D(SPIb)
--> recv req1
(lost)
<-- send resp1: SA(..,SPIb2,..),.. ()
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.

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(SPIb2) D()
--> recv req2 req1

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 B should host A do?

One option would be to reply with an as usual (with empty Informational response.
However, this same reply would also be sent if
response), close the IKE_SA, and stop retransmitting req2. This is
because once host A has received receives resp1, but has already sent a new request to delete the SA that was
just created. This would lead it may not be able to a reply any
longer. The situation where the peers are no
longer in sync about which SAs exist between them. However, is symmetric, so host A should behave the same
way.

Host A Host B
would eventually notice that
-------- --------
<-- send resp1: ()
send resp2: ()

Even if neither resp1 nor resp2 ever arrives, the other half of 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 pair has
not been deleted. Section 1.4 describes this rekeying

Another 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 is described in the
IKE_SA".

Another solution that has been proposed specification is to reply with an
INVALID_SPI notification which contains SPIb. This would explicitly
tell host B that simultaneous
rekeying. Section 2.8 says

Eronen & Hoffman Expires August 25, 2006 [Page 28]

Internet-Draft IKEv2 Clarifications February 2006

"If the SA was not deleted, so host B could try deleting two ends have the same lifetime policies, it again later. However, this usage is not part of possible
that both will initiate a rekeying at the IKEv2
specification, and would not be same time (which will
result in line with normal use redundant SAs). To reduce the probability of this
happening, the
INVALID_SPI notification where timing of rekeying requests SHOULD be jittered
(delayed by a random amount of time after the data field contains need for rekeying is
noticed).

This form of rekeying may temporarily result in multiple similar
SAs between the SPI 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
recipient SA created with the lowest of the notification would put four nonces used
in outbound packets.

Yet another solution would the two exchanges SHOULD be to ignore req2 at this time, and wait
until we have received resp1. closed by the endpoint that created
it."

However, a better explanation on what impact this alternative has not been
fully analyzed at this time; in general, ignoring valid requests on
implementations is
always a bit dangerous, because needed. Assume that hosts A and B have an
existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both endpoints could do it, leading
to a deadlock.

Currently, this document recommends the first alternative.

Eronen & Hoffman Expires August 6, 2006 [Page 31]

Internet-Draft IKEv2 Clarifications February 2006

5.12.7. Rekeying a new CHILD_SA

Yet another case occurs when a CHILD_SA is rekeyed soon after start
rekeying it has
been created: at the same time:

Host A Host B
-------- --------
send req1: [N(REKEY_SA,SPIa1)],
SA(..,SPIa2,..),.. N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. -->
(lost) <-- send resp1: SA(..,SPIb2,..),..
<-- send req2: N(REKEY_SA,SPIb2),
SA(..,SPIb3,..),.. N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--

To host A,

At this looks like point, A knows there is 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.12.8. Collisions with IKE_SA rekeying

Another set going on.
However, it cannot yet know which of cases occur when one peer starts rekeying the IKE_SA
at exchanges will have the same time
lowest nonce, so it will just note the other peer starts creating, rekeying, or closing
a CHILD_SA. Suppose that host B starts creating a CHILD_SA, situation and soon
after, host A starts rekeying the IKE_SA:

Host A Host B
-------- --------
<-- send req1: SA,Ni1,TSi,TSr respond as
usual.

send req2: SA,Ni2,.. resp2: SA(..,SPIa3,..),Nr1,.. -->
--> recv req2

What should host req1

Now B do at this point? Replying also knows that simultaneous rekeying is going on. Similarly
as usual would seem
like a reasonable choice: host A, it has to respond as usual.

<-- send resp2: SA,Ni2,.. resp1: SA(..,SPIb3,..),Nr2,..
recv resp2 resp1 <--
send req3: D() -->
--> recv req3

Now, a problem arises: If host B now replies normally with an empty
Informational response, resp2

At this will cause host point, there are three CHILD_SA pairs between A to delete state
associated with the IKE_SA. This means host B should stop
retransmitting req1. However, host and B cannot know whether or not host (the
old one and two new ones). A has received req1. If host 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 did receive it, it will move (the node
that initiated the surviving rekeyed SA), deletes the old one.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 32] 29]

Internet-Draft IKEv2 Clarifications February 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.

send req3: D(SPIa1) -->
<-- send req4: D(SPIb2)
--> recv req3
<-- send resp4: D(SPIb1)
recv req4 <--
send resp4: D(SPIa3) -->

The case where CHILD_SAs are being closed rekeying is even worse. Our
recommendation now finished.

However, there is a second possible sequence of events that can
happen if a host receives a request to rekey the
IKE_SA when it has CHILD_SAs some packets are lost 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 network, resulting in "half-closed" state, and will start a new
IKE_SA from scratch.

5.12.9. Closing and rekeying the IKE_SA
retransmissions. 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. rekeying begins as usual, but A's first packet
(req1) is lost.

Host A Host B
-------- --------
send req1: SA(..,SPIa1,..),Ni1 N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> (lost)
<-- send req2: D()
--> recv req1 N(REKEY_SA,SPIb1),
SA(..,SPIb2,..),Ni2,..
recv req2 <--

At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
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 host since it
has not yet received A's req1, it does not even know that these was
simultaneous rekeying. However, A should reply as usual, close will continue retransmitting the IKE_SA,
message, and stop
retransmitting req1. 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)
send resp2: ()

If host
recv resp1 <--

When A wants to continue communication with B, receives this error, it already knows there was simultaneous
rekeying, so it can now start a
new IKE_SA.

5.12.10. Summary

If a host receives a request to rekey: ignore the error message.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 33] 30]

Internet-Draft IKEv2 Clarifications February 2006

o a CHILD_SA pair that

5.11.4. Simultaneous IKE_SA rekeying

Probably the host is currently trying most complex case occurs when both peers try to close: reply
with NO_PROPOSAL_CHOSEN.

o a CHILD_SA pair that rekey
the host is currently rekeying: reply IKE_SA at the same time. Basically, the text in Section 2.8
applies to this case as
usual, but prepare well; however, it is important to close redundant SAs later based on the
nonces.

o a CHILD_SA pair ensure that does not exist: reply with
NO_PROPOSAL_CHOSEN.

o the IKE_SA, and
the host is currently CHILD_SAs are inherited by the right IKE_SA.

The case where both endpoints notice the simultaneous rekeying works
the IKE_SA: reply same way as usual, but prepare to close redundant SAs with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
three IKE_SAs exist between A and move inherited
CHILD_SAs later based on B; the nonces.

o one containing the IKE_SA, and lowest
nonce inherits the host CHILD_SAs.

However, there is currently creating, rekeying, or
closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.

o the IKE_SA, and twist to the other case where one rekeying
finishes first:

At this point, host is currently trying B sees a request to close the IKE_SA: IKE_SA. There's
not much more to do than to reply with NO_PROPOSAL_CHOSEN.

If a as usual. However, at this point
host B should stop retransmitting req2, since once host A receives a request
resp3, it will delete all the state associated with the old IKE_SA,
and will not be able to close:

o reply to it.

<-- send resp3: ()

5.11.5. Closing and rekeying a CHILD_SA pair that

A case similar to simultaneous rekeying can occur if one peers
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 currently trying to close: reply
without Delete payloads.

o a CHILD_SA pair close an SA
that the host B is currently rekeying: reply rekeying. Replying 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 usual is currently rekeying the IKE_SA: reply
as usual, and forget about our own rekeying request.

o probably the IKE_SA,
best choice:

Eronen & Hoffman Expires August 25, 2006 [Page 31]

Internet-Draft IKEv2 Clarifications February 2006

<-- send resp1: D(SPIb)

Depending on in which order req2 and the resp1 arrive, host A sees either
a request to rekey an SA that it is currently trying to close the IKE_SA:
reply as usual, and forget about our own close request.

If a host receives closing, or a request
to create or 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

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
currently rekeying the IKE_SA:
retransmitting message req1), so it does not recognize SPIb in
message req2. What should host A do?

One option would be to reply with NO_ADDITIONAL_SAS.

If a an empty Informational response.
However, this same reply would also be sent if host receives A has received
resp1, but has already sent a new request to delete the SA that was
just created. This would lead to a CHILD_SA when it is
currently rekeying situation where the IKE_SA: reply without Delete payloads.

5.13. Diffie-Hellman and rekeying peers are no
longer in sync about which SAs exist between them. However, host B
would eventually notice that the IKE_SA

There other half of the CHILD_SA pair has
not been some confusion whether doing 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 new Diffie-Hellman
exchange node MAY close the
IKE_SA".

Another solution that has been proposed is mandatory when to reply with an
INVALID_SPI notification which contains SPIb. This would explicitly
tell host B that the IKE_SA SA was not deleted, so host B could try deleting
it again later. However, this usage is rekeyed. not part of the IKEv2

Eronen & Hoffman Expires August 6, 25, 2006 [Page 34] 32]

Internet-Draft IKEv2 Clarifications February 2006

It seems that this case is allowed by

specification, and would not be in line with normal use of the IKEv2 specification.
Section 2.18 shows
INVALID_SPI notification where the Diffie-Hellman term (g^ir) in brackets, and data field contains the change history appendix in SPI the draft mentioned
recipient of the notification would put in outbound packets.

Yet another solution would be to ignore req2 at this as one change
between draft versions -00 time, and -01. Section 3.3.3 does wait
until we have received resp1. However, this alternative has not
contradict been
fully analyzed at this when it says that including the D-H transform time; in general, ignoring valid requests is
mandatory: although including
always a bit dangerous, because both endpoints could do it, leading
to a deadlock.

Currently, this document recommends the transform is mandatory, it can
contain the value "NONE".

However, having the option to skip the Diffie-Hellman exchange first alternative.

5.11.7. Rekeying a new CHILD_SA

Yet another case occurs when
rekeying the IKE_SA does not add useful functionality to the
protocol. The main purpose of rekeying the IKE_SA 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 ensure rekey an SA that
the compromise of old keying material does not provide information
about the current keys, or vice versa. This requires performing
exist. Like in the
Diffie-Hellman exchange when rekeying. Furthermore, it simultaneous rekeying case, replying with
NO_PROPOSAL_CHOSEN 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 probably reasonable:

send resp2: N(NO_PROPOSAL_CHOSEN) -->
recv resp1

5.11.8. Collisions with IKE_SA rekeying

Another set of cases occur when one peer starts rekeying the IKE_SA. In other words, the initiator should not
propose the value "NONE" for IKE_SA
at the D-H transform, and same time the responder
should not accept such other peer starts creating, rekeying, or closing
a proposal. This policy also implies CHILD_SA. Suppose that host B starts creating a
succesful exchange CHILD_SA, and soon
after, host A starts 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 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 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 point? Replying as agreed for this SA. The TSi payload itself does not
give the initiator permission to configure the initiator's TCP/IP usual would seem

Eronen & Hoffman Expires August 6, 25, 2006 [Page 35] 33]

Internet-Draft IKEv2 Clarifications February 2006

stack

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 address and use 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
CHILD_SA to the new IKE_SA 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, usual, and often
contain the same state information in the response message (see Section 6.4 will
then be out of sync.

It seems this document for some examples). However, their semantics are
still different.

6.2. (Section removed)

(This issue was corrected in RFC 4306.)

6.3. Requesting any INTERNAL_IP4/IP6_ADDRESS

When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
3.15.1 says that "In situation is tricky to handle correctly. Our proposal
is as follows: if a host receives a request message, to rekey the address specified is 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
requested address (or zero if no specific address is requested)". 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 question here case where CHILD_SAs are being closed is even worse. Our
recommendation is that does "zero" mean an address "0.0.0.0" or if a
zero length string?

Earlier, host receives a request to rekey the same section also says that "If an attribute
IKE_SA when it has CHILD_SAs in the
CFG_REQUEST Configuration Payload is not zero-length, "half-closed" state (currently being
closed), it is taken as should reply with NO_PROPOSAL_CHOSEN. And if a suggestion for that attribute". Also, host
receives a request to close a CHILD_SA after it has started rekeying
the table of configuration
attributes shows IKE_SA, it should reply with an empty Informational response.
This ensures that at least the length of INTERNAL_IP4_ADDRESS other peer will eventually notice that
the CHILD_SA is either "0
or 4 octets", still in "half-closed" state, and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
octets".

Thus, if the client does not request a specific address, it includes will start a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
containing an all-zeroes address. new
IKE_SA from scratch.

5.11.9. Closing and rekeying the IKE_SA

The example final case considered in 2.19 is thus
incorrect, since it shows this section occurs if one peer decides
to close the attribute as
"INTERNAL_ADDRESS(0.0.0.0)".

However, since IKE_SA while the value is only a suggestion, implementations are
recommended to ignore suggestions they do not accept; or in other
words, treat the same way a zero-length INTERNAL_IP4_ADDRESS,
"0.0.0.0", 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 any other addresses the implementation does not
recognize as a reasonable suggestion.

6.4. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes the INTERNAL_IP4_SUBNET host A should reply as "The protected
sub-networks that this edge-device protects. This attribute is made
up of two fields: usual, close the first is an IP address IKE_SA, and the second is a
netmask. Multiple sub-networks MAY be requested. The responder MAY
respond with zero or more sub-network attributes." stop
retransmitting req1.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 36] 34]

Internet-Draft IKEv2 Clarifications February 2006

INTERNAL_IP6_SUBNET is defined in

<-- send resp1: N(NO_PROPOSAL_CHOSEN)
send resp2: ()

If host A wants to continue communication with B, it can now start 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
new IKE_SA.

5.11.10. Summary

If a host receives a request to be two sensible
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
response) indicates which subnets are accessible through the SA rekey:

o a CHILD_SA pair that
was just created.

The first interpretation of the INTERNAL_IP4/6_SUBNET attributes host is currently trying to close: reply
with NO_PROPOSAL_CHOSEN.

o a CHILD_SA pair that they indicate additional subnets that can be reached through
this gateway, the host is currently rekeying: reply as
usual, but need a separate SA. According prepare to this
interpretation, close redundant SAs later based on the INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses not included in TSr.

The second interpretation is
nonces.

o a CHILD_SA pair that does not exist: reply with
NO_PROPOSAL_CHOSEN.

o the INTERNAL_IP4/6_SUBNET
attributes express IKE_SA, and the gateway's policy about what traffic should be
sent through host is currently rekeying the gateway. The client can choose whether other
traffic (covered by TSr, IKE_SA: reply
as usual, but not in INTERNAL_IP4/6_SUBNET) is sent
through prepare to close redundant SAs and move inherited
CHILD_SAs later based on the gateway or directly nonces.

o the destination. According to this
interpretation, IKE_SA, and the attributes are useful mainly when TSr contains
addresses not included in host is currently creating, rekeying, or
closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.

o the INTERNAL_IP4/6_SUBNET attributes.

It turns out that these two interpretations are not incompatible, but
rather two sides of IKE_SA, and the same principle: traffic host is currently trying to close the addresses
listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
this gateway. IKE_SA:
reply with NO_PROPOSAL_CHOSEN.

If there are no existing IPsec SAs whose traffic
selectors cover a host receives a request to close:

o a CHILD_SA pair that the address in question, new SAs have host is currently trying 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, 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 client's request
contains host is currently rekeying 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 IKE_SA: reply
as usual, and forget about our own rekeying request.

o the following (in which TSr IKE_SA, and
INTERNAL_IP4_SUBNET contain the same information): 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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 37] 35]

Internet-Draft IKEv2 Clarifications February 2006

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,

currently rekeying the INTERNAL_IP4_SUBNET does not really carry any
useful information. Another possible IKE_SA: reply would have 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 this:

This would mean 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 client can send all its traffic through IKEv2 specification.
Section 2.18 shows the
gateway, but Diffie-Hellman term (g^ir) in brackets, and
the gateway change history appendix in the draft mentioned this as one change
between draft versions -00 and -01. Section 3.3.3 does not mind if
contradict this when it says that including the client sends traffic
not included by INTERNAL_IP4_SUBNET directly to D-H transform is
mandatory: although including the destination
(without going through transform is mandatory, it can
contain the gateway).

A different situation arises if value "NONE".

However, having the gateway has a policy that
requires option to skip the traffic for Diffie-Hellman exchange when
rekeying the two subnets to be carried in separate
SAs. Then a response like this would indicate IKE_SA does not add useful functionality to the client that if
it wants access to
protocol. The main purpose of rekeying the second subnet, it needs IKE_SA is to create a separate
SA:

INTERNAL_IP4_SUBNET can also be useful if ensure that
the client's TSr included
only part compromise of old keying material does not provide information
about the address space. For instance, if current keys, or vice versa. This requires performing the client requests
Diffie-Hellman exchange when rekeying. Furthermore, it is likely
that this option would have been removed from 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 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 gateway's reply could be this: 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
succesful 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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 38] 36]

Internet-Draft IKEv2 Clarifications February 2006

This sentence is less clear what correct, but its placement is slightly confusing.
IKEv2 does allow the attributes mean in CFG_REQUESTs, and
whether other lengths than zero make sense in initiator to request assignment of an IP address
from the responder, but this situation (but for
INTERNAL_IP6_SUBNET, zero length is done using configuration payloads,
not allowed at all!). Currently
this document recommends that implementations should not include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes traffic selector payloads. An address in
CFG_REQUESTs.

For a TSi payload in a
response does not mean that the IPv4 case, this document recommends using only netmasks
consisting of some amount of "1" bits followed by "0" bits; for
instance, "255.0.255.0" would not be a valid netmask for
INTERNAL_IP4_SUBNET.

It is also worthwhile to note responder has assigned that address
to the contents of initiator; it only means that if packets matching these
traffic selectors are sent by the INTERNAL_IP4/
6_SUBNET attributes do initiator, IPsec processing can be
performed as agreed for this SA. The TSi payload itself does not imply link boundaries. For instance, a
gateway providing access
give the initiator permission to a large company intranet using addresses
from configure 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 initiator's TCP/IP
stack with 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 address and INTERNAL_IP6_SUBNET in
IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: use it as its source address.

In other words, IKEv2
Clarifications and Implementation Guidelines", 2005-02-07.
"Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
April 2005.)

6.5. INTERNAL_IP4_NETMASK

Section 3.15.1 defines does not have two different mechanisms for
assigning addresses, but only one: configuration payloads. In the INTERNAL_IP4_NETMASK attribute,
scenario described in Section 1.1.3, both configuration and says
that "The internal network's netmask. Only one netmask is allowed traffic
selector payloads are usually included in the request and reply messages (e.g., 255.255.255.0) same message, and it MUST be
used only with an INTERNAL_IP4_ADDRESS attribute".

However, it is not clear what exactly this attribute means, as often
contain the
concept same information in the response message (see Section 6.3
of "netmask" is not very well defined this document 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 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 router"). Even request message, the address specified is a
requested address (or zero if no specific address is requested)".
The question here is that does "zero" mean an address "0.0.0.0" or a
zero length string?

Earlier, the operating system's TCP/IP stack
requires same section also says that "If an attribute in the
CFG_REQUEST Configuration Payload is not zero-length, it is taken as
a netmask to be configured, suggestion for point-to-point links 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
could be just set to 255.255.255.255. So, why includes
a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
containing an all-zeroes address. The example in 2.19 is this information 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, 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.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 39] 37]

Internet-Draft IKEv2 Clarifications February 2006

sent in IKEv2?

One possible interpretation would be that

6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes the host INTERNAL_IP4_SUBNET as "The protected
sub-networks that this edge-device protects. This attribute is given a whole
block made
up of two fields: the first is an IP addresses instead of address and the second is a single address.
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 also what
Framed-IP-Netmask does usually
included in [RADIUS], the IPCP "subnet mask" extension TSr payload, what functionality does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
IPv6-Prefix this attribute
add? And second, what 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 attribute mean 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. CFG_REQUESTs?

For
instance, the client could use its own address and the netmask first question, there seem to
calculate be two sensible
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
response) indicates which subnets are accessible through the broadcast address SA that
was just created.

The first interpretation of the link. (Whether the gateway
will actually deliver broadcast packets to other VPN clients and/or
other nodes connected to this link INTERNAL_IP4/6_SUBNET attributes is another matter.)

An empty INTERNAL_IP4_NETMASK attribute
that they indicate additional subnets that can be included in reached through
this gateway, but need a
CFG_REQUEST separate SA. According to request this information (although the gateway can
send
interpretation, the information even when not requested). However, it seems
that non-empty values for this attribute do INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses not make sense included in
CFG_REQUESTs.

Fortunately, Section 4 clearly says TSr.

The second interpretation is that a minimal implementation
does not need to include or understand the INTERNAL_IP4_NETMASK
attribute, and thus this document recommends that implementations 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 use in INTERNAL_IP4/6_SUBNET) is sent
through the INTERNAL_IP4_NETMASK attribute gateway or assume that directly the
other peer supports it.

(References: Charlie Kaufman's mail "RE: Proposed Last Call based
revisions destination. According 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.6. Configuration payloads for IPv6

IKEv2 also defines configuration payloads for IPv6. However, they
are based on this
interpretation, the corresponding IPv4 payloads, and do attributes are useful mainly when TSr contains
addresses not fully follow included in the "normal IPv6 way INTERNAL_IP4/6_SUBNET attributes.

It turns out that these two interpretations are not incompatible, but
rather two sides of doing things".

Eronen & Hoffman Expires August 6, 2006 [Page 40]

Internet-Draft IKEv2 Clarifications February 2006

A client can the same principle: traffic to the addresses
listed in the INTERNAL_IP4/6_SUBNET attributes should be assigned an IPv6 address using sent via
this gateway. If there are no existing IPsec SAs whose traffic
selectors cover the
INTERNAL_IP6_ADDRESS configuration payload. address in question, new SAs have to be created.

A minimal exchange could
look like this: 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_IP6_ADDRESS()
INTERNAL_IP6_DNS()
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 0.0.0.0-255.255.255.255)

Then a valid response could be the following (in which TSr and

Eronen & Hoffman Expires August 25, 2006 [Page 38]

Internet-Draft IKEv2 Clarifications February 2006

INTERNAL_IP4_SUBNET contain the same information):

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)
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, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
(0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) 192.0.2.0-192.0.2.255))

In particular, IPv6 stateless autoconfiguration or router
advertisement messages are these cases, the INTERNAL_IP4_SUBNET does not used; neither is neighbor discovery.

The really carry any
useful information. Another possible reply would have been this:

This would mean that the client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
in all its traffic through the CFG_REQUEST to request a specific address or interface
identifier. The gateway first checks if
gateway, but the specified address is
acceptable, and gateway does not mind if it is, returns that one. If the address was client sends traffic
not
acceptable, the gateway will attempt included by INTERNAL_IP4_SUBNET directly to use the interface identifier
with some other prefix; destination
(without going through the gateway).

A different situation arises if even that fails, the gateway will select
another interface identifier.

The INTERNAL_IP6_ADDRESS attribute also contains has a prefix length
field. When used policy that
requires the traffic for the two subnets to be carried in separate
SAs. Then a CFG_REPLY, response like this corresponds would indicate to the
INTERNAL_IP4_NETMASK attribute in client that if
it wants access to the IPv4 case (and indeed, was
called INTERNAL_IP6_NETMASK in earlier versions second subnet, it needs to create a separate
SA:

INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the IKEv2 draft).
See address space. For instance, if 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 client requests
the IPv6 addressing
architecture [IPv6Addr] sense. In particular, they do not
necessarily have link-local addresses, and this may complicate 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
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.) gateway's reply could be this:

Eronen & Hoffman Expires August 6, 25, 2006 [Page 41] 39]

Internet-Draft IKEv2 Clarifications February 2006

6.7. INTERNAL_IP6_NBNS

Section 3.15.1 defines

It is less clear what the INTERNAL_IP6_NBNS attribute attributes mean in CFG_REQUESTs, and
whether other lengths than zero make sense in this situation (but for sending
the IPv6 address of NetBIOS name servers.

However, NetBIOS
INTERNAL_IP6_SUBNET, zero length is not defined for IPv6, and probably never will be.
Thus, allowed at all!). Currently
this attribute most likely does document recommends that implementations should not make much sense.

(Pointed out by Bernard Aboba include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
CFG_REQUESTs.

For the IP Configuration Security (ICOS)
BoF at IETF62.)

6.8. INTERNAL_ADDRESS_EXPIRY

Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
"Specifies the number IPv4 case, this document recommends using only netmasks
consisting of seconds some amount of "1" bits followed by "0" bits; for
instance, "255.0.255.0" would not be a valid netmask for
INTERNAL_IP4_SUBNET.

It is also worthwhile to note that the host can use contents of the internal
IP address. The host MUST renew 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 IP address before this expiry
time. Only one 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 these attributes MAY be present in the reply."

Expiry times and explicit renewals are primarily useful
Configuration Payload in
environments like DHCP, where the server cannot reliably know when
the client has gone away. However, 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 this is known,
Clarifications and the
gateway can simply free the address when the IKE_SA is deleted.

Also, Implementation Guidelines", 2005-02-07.
"Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
April 2005.)

6.4. INTERNAL_IP4_NETMASK

Section 4 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says
that supporting renewals "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 mandatory.
Given that clear what exactly this functionality attribute means, as the
concept of "netmask" 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 very well defined for
CFG_REQUESTs, clients should not send it either.)

Note that according to Section 4, clients are required to understand
INTERNAL_ADDRESS_EXPIRY if the 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.9. 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, point-to-point
links (unlike multi-access links, where it means "you can simply ignore all configuration payloads. This type reach hosts
inside this netmask directly using layer 2, instead of
implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
If sending
packets via a router"). Even if the initiator operating system's TCP/IP stack
requires the assignment of an IP address, a netmask to be configured, for point-to-point links it will
could be just set to 255.255.255.255. So, why is this information

Eronen & Hoffman Expires August 6, 25, 2006 [Page 42] 40]

Internet-Draft IKEv2 Clarifications February 2006

treat a response without CFG_REPLY as an error.

A second case is where

sent in IKEv2?

One possible interpretation would be that the responder does support configuration
payloads, but only for particular type host is given a whole
block of IP addresses (IPv4 or IPv6).
Section 4 says that "A minimal IPv4 responder implementation will
ignore the contents instead of a single address. This is also what
Framed-IP-Netmask does in [RADIUS], 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 IPCP "subnet mask" extension
does in PPP [IPCPSubnet], and the CFG_REQUEST, an IPv4-only responder can thus simply ignore prefix length in the IPv6 part and process Framed-
IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the IPv4 request as usual.

A third case is where
specification supports this interpretation, and discussions on the initiator requests
IPsec WG mailing list have confirmed it was not intended. Section
3.15.1 also says that multiple addresses of a
type that the responder supports: what should happen if some (but not
all) of are assigned using multiple
INTERNAL_IP4/6_ADDRESS attributes.

Currently, this document's interpretation is the requests fail? It seems that an optimistic approach
would be following:
INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the best one here: if same thing as
INTERNAL_IP4_SUBNET containing the responder is able same information ("send traffic to assign at
least one address, it replies with those; it sends
INTERNAL_ADDRESS_FAILURE only if no
these addresses can be assigned.

(References: "ikev2 and internal_ivpn_address" thread, June 2005.)

7. Miscellaneous issues

7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR

When using through me"), but also implies a link boundary. For
instance, the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require this client could use its own address and the netmask to match
calculate the broadcast address in
the IP header (of IKEv2 packets), or anything in the TSi/TSr
payloads. The contents of IDi/IDr is used purely to fetch the policy
and authentication data related to link. (Whether the other party.

(References: "Identities types IP address,FQDN/user FQDN and DN and
its usage in preshared key authentication" thread, Jan 2005.)

7.2. Relationship of IKEv2 gateway
will actually deliver broadcast packets to RFC4301

The IKEv2 specification refers other VPN clients and/or
other nodes connected to [RFC4301], but it never makes clear
what the exact relationship is.

However, there are some requirements this link is another matter.)

An empty INTERNAL_IP4_NETMASK attribute can be included in a
CFG_REQUEST to request this information (although the specification gateway can
send the information even when not requested). However, it seems
that non-empty values for this attribute do not make
it clear sense in
CFG_REQUESTs.

Fortunately, Section 4 clearly says that IKEv2 requires [RFC4301]. In other words, an a minimal implementation that
does IPsec processing strictly according not need to
[RFC2401] cannot be compliant with 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 specification.

One such example can be found in Section 2.24: "Specifically, tunnel
encapsulators Clarifications and decapsulators
Implementation Guidelines", 2005-02-07. "Clarifications open issue:
INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)

6.5. Configuration payloads for all tunnel-mode SAs created by IPv6

IKEv2 [...] MUST implement also defines configuration payloads for IPv6. However, they
are based on the tunnel encapsulation corresponding IPv4 payloads, and
decapsulation processing specified in [RFC4301] to prevent discarding do not fully follow
the "normal IPv6 way of doing things".

Eronen & Hoffman Expires August 6, 25, 2006 [Page 43] 41]

Internet-Draft IKEv2 Clarifications February 2006

of ECN congestion indications."

Nevertheless, the changes required to existing [RFC2401]
implementations

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 very large, especially since supporting many
of the new features (such as Extended Sequence Numbers) used; neither is optional.

7.3. Reducing the window size

In IKEv2, neighbor discovery.

The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
in the window size is assumed CFG_REQUEST to be a (possibly configurable)
property of request a particular implementation, and 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 related
acceptable, the gateway will attempt to
congestion control (unlike use the window size in TCP, for instance).

In particular, it is not defined what interface identifier
with some other prefix; if even that fails, the responder should do when it
receives a SET_WINDOW_SIZE notification containing gateway will select
another interface identifier.

The INTERNAL_IP6_ADDRESS attribute also contains a smaller value
than is currently prefix length
field. When used in effect. Thus, there is currently no way a CFG_REPLY, this corresponds to
reduce the window size
INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
called INTERNAL_IP6_NETMASK in earlier versions 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 draft).
See the
negotiation is known. In previous section for more details.

While this case, the nonce has approach to be long enough
for all the PRFs being proposed.

7.5. Initial zero octets on port 4500

It configuring IPv6 addresses 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 reasonably
simple, it does has some limitations: IPsec tunnels configured using IKEv2
are not say what to fully-featured "interfaces" in the IPv6 addressing
architecture [IPv6Addr] sense. In particular, they do if message 1 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 sent on port 4500. a
different issue.)

(References: "VPN remote host configuration IPv6 ?" thread, May 2004.
"Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
April 2005.)

Eronen & Hoffman Expires August 6, 25, 2006 [Page 44] 42]

Internet-Draft IKEv2 Clarifications February 2006

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

6.6. INTERNAL_IP6_NBNS

Section 3.15.1 defines the outer packet MUST tunnel
all future IKE INTERNAL_IP6_NBNS attribute for sending
the IPv6 address of NetBIOS name servers.

However, NetBIOS is not defined for IPv6, and ESP packets associated with probably never will be.
Thus, this IKE_SA over
UDP port 4500.

To tunnel IKE packets over UDP port 4500, attribute most likely does not make much sense.

(Pointed out by Bernard Aboba in the IKE header has four
octets 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 zero prepended and seconds that the result immediately follows host can use the
UDP header. [...] internal
IP address. The very beginning host MUST renew the IP address before this expiry
time. Only one of Section 2 says "... though IKE messages may
also these attributes MAY be received on UDP port 4500 with a slightly different format
(see section 2.23)."

That "slightly different format" is only described present 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, reply."

Expiry times and explicit renewals are primarily useful in
environments like DHCP, where the processing engine server cannot
determine whether reliably know when
the packet client has gone away. However, in IKEv2 this is an IKE packet or an ESP packet.

Thus, all packets sent on port 4500 need known, and the four zero prefix;
otherwise,
gateway can simply free the receiver won't know how to handle them.

7.6. Destination port for NAT traversal address when the IKE_SA is deleted.

Also, Section 2.23 4 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 supporting renewals 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 not mandatory.
Given that this functionality is usually dynamically allocated by the NAT.

7.7. SPI values for messages outside of an IKE_SA

The IKEv2 specification is not quite clear what SPI values needed, we recommend
that gateways should be
used in the IKE header for not send the small number of notifications that are
allowed INTERNAL_ADDRESS_EXPIRY attribute.
(And since this attribute does not seem to be sent outside of an IKE_SA. make much sense for
CFG_REQUESTs, clients should not send it either.)

Note that such
notifications are explicitly *not* Informational exchanges; according to Section
1.5 makes it clear that these are one-way messages that must not be
responded to.

There 4, clients are two cases when such a one-way notification can be sent:
INVALID_IKE_SPI and INVALID_SPI.

Eronen & Hoffman Expires August 6, 2006 [Page 45]

Internet-Draft IKEv2 Clarifications February 2006

In case of INVALID_IKE_SPI, required to understand
INTERNAL_ADDRESS_EXPIRY if the message sent is a response message,
and Section 2.21 says that "If a response is sent, receive it. A minimum implementation
would use the response MUST
be sent value to limit the IP address and port from whence it came with the same
IKE SPIs and lifetime of the Message ID copied."

In case IKE_SA.

(References: Tero Kivinen's mail "Comments of INVALID_SPI, however,
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
"Questions about internal address" thread, April 2005.)

6.8. Address assignment failures

First, if the recipient responder does not support configuration payloads at
all, it can simply ignore all configuration payloads. This type of such a notification. Also,
implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
If the message sent is now initiator requires the assignment of an INFORMATIONAL request. IP address, it will

Eronen & Hoffman Expires August 25, 2006 [Page 43]

Internet-Draft IKEv2 Clarifications February 2006

treat a response without CFG_REPLY as an error.

A strict
interpretation 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 specification would require contents of the sender CP payload except to
invent garbage values determine that it
includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the SPI fields. However, we think this was
not the intention,
initiator includes both INTERNAL_IP4_ADDRESS and using zero values is acceptable.

(References: "INVALID_IKE_SPI" thread, June 2005.)

7.8. Protocol ID/SPI fields INTERNAL_IP6_ADDRESS
in Notify payloads

Section 3.10 says that the Protocol ID field in Notify payloads "For
notifications that do not relate to CFG_REQUEST, an existing SA, this field MUST
be sent as zero IPv4-only responder can thus simply ignore the
IPv6 part and MUST be ignored on receipt". However, process 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 IPv4 request as usual.

A third case is to specify where the
type initiator requests multiple addresses of the SPI, our interpretation is a
type that the Protocol ID field responder supports: what should happen if some (but not
all) of the requests fail? It seems that an optimistic approach
would be non-zero only when the SPI field best one here: if the responder is non-empty.

There are currently able to assign at
least one address, it replies with those; it sends
INTERNAL_ADDRESS_FAILURE only two notifications where this is the case:
INVALID_SELECTORS if no addresses can be assigned.

(References: "ikev2 and REKEY_SA.

7.9. Which message should contain INITIAL_CONTACT

The description of internal_ivpn_address" thread, June 2005.)

7. Miscellaneous issues

7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR

When using the INITIAL_CONTACT notification ID_IPV4_ADDR/ID_IPV6_ADDR identity types in Section 3.10.1
says that "This notification asserts that IDi/IDr
payloads, IKEv2 does not require this IKE_SA is address to match the only
IKE_SA currently active between address in
the authenticated identities".
However, neither Section 2.4 nor 3.10.1 says IP header (of IKEv2 packets), or anything in which message this
payload should be placed. the TSi/TSr
payloads. The general agreement is that INITIAL_CONTACT contents of IDi/IDr is best communicated in used purely to fetch the first IKE_AUTH request, not as a separate exchange afterwards.

(References: "Clarifying policy
and authentication data related to the use of INITIAL_CONTACT in IKEv2" thread,
April 2005. "Initial Contact messages" thread, December 2004.
"IKEv2 other party.

(References: "Identities types IP address,FQDN/user FQDN and Initial Contact" thread, September 2004 DN and April 2005.)

7.10. Alignment of payloads

Many
its usage in preshared key authentication" thread, Jan 2005.)

7.2. Relationship of IKEv2 payloads contain fields marked as "RESERVED", mostly
because IKEv1 had them, and partly because they to RFC4301

The IKEv2 specification refers to [RFC4301], but it never makes clear
what the exact relationship is.

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 pictures 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

Eronen & Hoffman Expires August 6, 25, 2006 [Page 46] 44]

Internet-Draft IKEv2 Clarifications February 2006

easier

of ECN congestion indications."

Nevertheless, the changes required to draw. In particular, payloads in IKEv2 existing [RFC2401]
implementations are not, in
general, aligned not very large, especially since supporting many
of the new features (such as Extended Sequence Numbers) is optional.

7.3. Reducing the window size

In IKEv2, the window size is assumed to 4-byte boundaries. (Note that payloads were be a (possibly configurable)
property of a particular implementation, and is not
aligned related to 4-byte boundaries
congestion control (unlike the window size 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 TCP, for instance).

In particular, it is not defined in this document
that accept attributes are what the AES based encryption, integrity, and
pseudo-random functions, which require responder should do when it
receives a single attribute specifying
key width."

This SET_WINDOW_SIZE notification containing a smaller value
than is incorrect. The AES-based integrity and pseudo-random
functions defined currently in [IKEv2] always use a 128-bit key. In fact, effect. Thus, there are is currently no integrity or PRF algorithms that use the key
length attribute (and we recommend that they should not be defined in way to
reduce the future either).

For encryption algorithms, window size of an existing IKE_SA. However, when rekeying
an IKE_SA, the situation new IKE_SA starts with window size 1 until it is slightly more complex
since there are three different types
explicitly increased by sending a new SET_WINDOW_SIZE notification.

(References: Tero Kivinen's mail "Comments of algorithms:

o The key length attribute is never used with algorithms
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

7.4. Minimum size of nonces

Section 2.10 says that use a
fixed length key, such as DES "Nonces used in IKEv2 MUST be randomly chosen,
MUST be at least 128 bits in size, and IDEA.

o The MUST be at least half the key length attribute is always included for
size of the currently
defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting negotiated prf."

However, the key length attribute is not allowed; if initiator chooses the proposal does not
contain it, nonce before the proposal outcome of the
negotiation is known. In this case, the nonce has to be rejected.

o For other algorithms, long enough
for all the key length attribute can be included but PRFs being proposed.

7.5. Initial zero octets on port 4500

It is not mandatory. These algorithms include, e.g., RC5, CAST and
BLOWFISH. If clear whether a peer sending an IKE_SA_INIT request on port
4500 should include the key length attribute is initial four zero octets. Section 2.23 talks
about how to upgrade to tunneling over port 4500 after message 2, but
it does 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. Implementors should note that IKEv2 may use numbers
different from IKEv1 for a particular algorithm.

For instance, an encryption algorithm can have up say what to three different
numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
the IKEv1 phase do if message 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 is sent on port 4500.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 47] 45]

Internet-Draft IKEv2 Clarifications February 2006

all three registries, the registries are

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 identical.

Similarly, an integrity algorithm can have at least match the IKEv2
"Transform Type 3" identifier addresses in ikev2-registry, the IKEv1 phase 2
"IPSEC AH Transform Identifier" in isakmp-registry, 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 IKEv1
phase IKE header has four
octets of zero prepended and the result immediately follows the
UDP header. [...]

The very beginning of Section 2 ESP "Authentication Algorithm Security Association Attribute"
identifier in isakmp-registry. And there is says "... though IKE messages may
also the IKEv1 phase 1
"Hash Algorithm" list in ipsec-registry.

This issue needs special care also when writing be received on UDP port 4500 with a specification 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
how a new algorithm initiators on port 4500.
Furthermore, without the initial zeros, the processing engine cannot
determine whether the packet is used together with IPsec.

7.13. Combining ESP and AH

The IKEv2 specification contains some misleading text about how an IKE packet or an ESP
and AH can be combined.

IKEv2 is based packet.

Thus, all packets sent 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 port 4500 need the passes are coordinated by four zero prefix;
otherwise, the forwarding tables. In IKEv2,
each of these SAs has receiver won't know how to be created using a separate CREATE_CHILD_SA
exchange. Thus, the text in handle them.

7.6. Destination port for NAT traversal

Section 2.7 about 2.23 says that "an IPsec endpoint that discovers a single proposal
containing both ESP NAT
between it and AH its correspondent MUST send all subsequent traffic to
and from port 4500".

This sentence is incorrect.

Morever, misleading. The peer "outside" the combination NAT uses source
port 4500 for the traffic it sends, but the destination port is, of ESP and AH (between
course, taken from packets sent by the same endpoints)
become largely obsolete already in 1998 when RFC 2406 was published.
Our recommendation peer behind the NAT. This
port number is that usually dynamically allocated by the NAT.

7.7. SPI values for messages outside of an IKE_SA

The IKEv2 implementations should specification is not support
this combination, and implementors quite clear what SPI values should not assume the combination
can be made to work
used in interoperable manner.

(References: "Rekeying SA bundles" thread, Oct 2005.)

8. Status of the clarifications

This document is work-in-progress, and it contains both relatively
stable and finished parts, and other parts that are incomplete or
even incorrect. To help IKE header for the reader in deciding how much weight
should be given to each clarification, this section contains our
opinions about which parts we believe to are stable, and which small number of notifications that are
likely to change in future versions.

Those clarifications believed
allowed to be correct and without controversy sent outside of an IKE_SA. Note that such
notifications are marked with three asterisks (***); those where the clarification
is known to explicitly *not* Informational exchanges; Section
1.5 makes it clear that these are one-way messages that must not be incomplete and/or there is disagreement about what the
correct interpretation is
responded to.

There are marked with one asterisk (*). The
clarifications marked with two asterisks (**) are somewhere between cases when such a one-way notification can be sent:
INVALID_IKE_SPI and INVALID_SPI.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 48] 46]

Internet-Draft IKEv2 Clarifications February 2006

In case of INVALID_IKE_SPI, the extremes.

2. Creating message sent is a response message,
and Section 2.21 says that "If a response is sent, the IKE_SA
2.1 SPI values in IKE_SA_INIT exchange ***
2.2 Message IDs for IKE_SA_INIT messages ***
2.3 Retransmissions of IKE_SA_INIT requests ***
2.4 Interaction of COOKIE response MUST
be sent to the IP address and INVALID_KE_PAYLOAD ***
2.5 Invalid cookies ***
3. Authentication
3.1 Data included in AUTH payload calculation ***
3.2 Hash function for RSA signatures ***
3.3 Encoding method for RSA signatures ***
3.4 Identification type for EAP ***
3.5 Identity for policy lookups when using EAP ***
3.6 (Section removed)
3.7 Certificate encoding types ***
3.8 Shared key authentication and fixed PRF key size ***
3.9 EAP authentication port from whence it came with the same
IKE SPIs and fixed PRF key size ***
3.10 Matching the Message ID payloads copied."

In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to certificate contents ***
3.11 Message IDs for IKE_AUTH messages ***
4. Creating CHILD_SAs
4.1 Creating SAs with the CREATE_CHILD_SA exchange **
4.2 Creating an IKE_SA without a CHILD_SA ***
4.3 Diffie-Hellman for first CHILD_SA ***
4.4 Extended Sequence Numbers (ESN) transform ***
4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ***
4.6 Negotiation recipient of NON_FIRST_FRAGMENTS_ALSO ***
4.7 Semantics such a notification. Also,
the message sent is now an INFORMATIONAL request. A strict
interpretation of complex traffic selector payloads ***
4.8 ICMP type/code 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.)

7.8. Protocol ID/SPI fields in traffic selector Notify payloads ***
4.9 Mobility header

Section 3.10 says that the Protocol ID field in traffic selector Notify payloads ***
4.10 Narrowing the traffic selectors ***
4.11 SINGLE_PAIR_REQUIRED ***
4.12 Traffic selectors violating own policy ***
5. Rekeying "For
notifications that do not relate to an existing SA, this field MUST
be sent as zero and deleting SAs
5.1 Rekeying SAs with MUST be ignored on receipt". However, the CREATE_CHILD_SA exchange **
5.2 Rekeying
specification does not clearly say which notifications are related to
existing SAs and which are not.

Since the IKE_SA vs. reauthentication ***
5.3 SPIs 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 rekeying the IKE_SA ***
5.4 SPI when rekeying a CHILD_SA ***
5.5 Changing PRFs when rekeying 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 ***
5.6 Deleting vs. closing SAs ***
5.7 Deleting an SA pair ***
5.8 Deleting 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

Eronen & Hoffman Expires August 25, 2006 [Page 47]

Internet-Draft IKEv2 Clarifications February 2006

easier to draw. In particular, payloads in IKEv2 are not, in
general, aligned to 4-byte boundaries. (Note that payloads were not
aligned to 4-byte 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."

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 (CBC, CTR, CCM and 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

For instance, an IKE_SA ***
5.9 Who is encryption algorithm can have up to three different
numbers: the original initiator of IKE_SA ***
5.10 (Section removed)
5.11 Comparing nonces ***
5.12 Exchange collisions *
5.13 Diffie-Hellman IKEv2 "Transform Type 1" identifier in ikev2-registry,
the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
registry, and rekeying the IKE_SA **
6. Configuration payloads IKEv1 phase 2 "IPSEC ESP Transform Identifier"
isakmp-registry. Although some algorithms have the same number in

Eronen & Hoffman Expires August 6, 25, 2006 [Page 49] 48]

Internet-Draft IKEv2 Clarifications February 2006

6.1 Assigning IP addresses ***
6.2 (Section removed)
6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS ***
6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ***
6.5 INTERNAL_IP4_NETMASK **
6.6 Configuration payloads

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 IPv6 **
6.7 INTERNAL_IP6_NBNS ***
6.8 INTERNAL_ADDRESS_EXPIRY ***
6.9 Address assignment failures **
7. Miscellaneous issues
7.1 Matching ID_IPV4_ADDR
how a new algorithm is used together with IPsec.

7.13. Combining ESP and ID_IPV6_ADDR ***
7.2 Relationship of AH

The IKEv2 to RFC4301 ***
7.3 Reducing the window size ***
7.4 Minimum size of nonces ***
7.5 Initial zero octets specification contains some misleading text about how ESP
and AH can be combined.

IKEv2 is based on port 4500 ***
7.6 Destination port for NAT traversal ***
7.7 SPI values for messages outside [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 an IKE_SA ***
7.8 Protocol ID/SPI fields these SAs has to be created using a separate CREATE_CHILD_SA
exchange. Thus, the text in Notify payloads ***
7.9 Which message should contain INITIAL_CONTACT ***
7.10 Alignment of payloads ***
7.11 Key length transform attribute ***
7.12 IPsec IANA considerations **
7.13 Combining Section 2.7 about a single proposal
containing both ESP and AH *

Future versions is incorrect.

Morever, the combination of ESP and AH (between the same endpoints)
become largely obsolete already in 1998 when RFC 2406 was published.
Our recommendation is that IKEv2 implementations should not support
this document will, of course, change these
estimates (and changes combination, and implementors should not assume the combination
can be made to work in both directions are possible, though
hopefully it's more towards higher confidence).

9. 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
and not needing clarification, that some implementors 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.

Eronen & Hoffman Expires August 25, 2006 [Page 49]

Internet-Draft IKEv2 Clarifications February 2006

o Some implementations could only handle a single pair of traffic
selectors, or would only process the first pair in the proposal.

Eronen & Hoffman Expires August 6, 2006 [Page 50]

Internet-Draft IKEv2 Clarifications February 2006

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
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.

10.

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.

11.

10. IANA considerations

This document does not change or create any IANA-registered values.

12.

11. 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,
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.

13.

12. References

13.1.

12.1. Normative References

[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.

Eronen & Hoffman Expires August 25, 2006 [Page 50]

Internet-Draft IKEv2 Clarifications February 2006

[IKEv2ALG]
Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,

Eronen & Hoffman Expires August 6, 2006 [Page 51]

Internet-Draft IKEv2 Clarifications February 2006
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.

13.2.

12.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",
draft-hoffman-ike-ipsec-hash-use-01 (work in progress),
December 2005.

[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, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2004.

[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

Eronen & Hoffman Expires August 25, 2006 [Page 51]

Internet-Draft IKEv2 Clarifications February 2006

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.

[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible

Eronen & Hoffman Expires August 6, 2006 [Page 52]

Internet-Draft IKEv2 Clarifications February 2006
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.

[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.

[RFC3664bis]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)",
draft-hoffman-rfc3664bis (work in progress), October 2005.

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.

[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", RFC 822, August 1982.

[ReAuth] Nir, Y., "Repeated Authentication in IKEv2",
draft-nir-ikev2-auth-lt-03 (work in progress),
November 2005.

[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T.
Polk, "Simple Certificate Validation Protocol (SCVP)",
draft-ietf-pkix-scvp-21 (work in progress), October 2005.

Eronen & Hoffman Expires August 25, 2006 [Page 52]

Internet-Draft IKEv2 Clarifications February 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

Eronen & Hoffman Expires August 6, 2006 [Page 53]

Internet-Draft IKEv2 Clarifications February 2006
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+]

Eronen & Hoffman Expires August 25, 2006 [Page 53]

Internet-Draft IKEv2 Clarifications February 2006

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+]

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+]

Eronen & Hoffman Expires August 6, 25, 2006 [Page 54]

Internet-Draft IKEv2 Clarifications February 2006

[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 Expires August 6, 25, 2006 [Page 55]

Internet-Draft IKEv2 Clarifications February 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 Expires August 6, 25, 2006 [Page 56]

Internet-Draft IKEv2 Clarifications February 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 Expires August 6, 25, 2006 [Page 57]

Internet-Draft IKEv2 Clarifications February 2006

Intellectual Property Statement

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.

Disclaimer of Validity

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.

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Eronen & Hoffman Expires August 6, 25, 2006 [Page 58]

----