WDIFF

draft-eronen-ipsec-ikev2-clarifications-03.txt --> draft-eronen-ipsec-ikev2-clarifications-04.txt

Network Working Group P. Eronen
Internet-Draft Nokia
Expires: December 3, 2005 January 16, 2006 P. Hoffman
VPN Consortium
June 1,
July 15, 2005

IKEv2 Clarifications and Implementation Guidelines
draft-eronen-ipsec-ikev2-clarifications-03.txt
draft-eronen-ipsec-ikev2-clarifications-04.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 December 3, 2005. January 16, 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 December 3, 2005 January 16, 2006 [Page 1]

Internet-Draft IKEv2 Clarifications June July 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Authentication Creating the IKE_SA . . . . . . . . . . . . . . . . . . . . 4
2.1 SPI values in IKE_SA_INIT exchange . . . . . . . . . . . . 4
2.1
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
3. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Data included in AUTH payload calculation . . . . . . . . 4
2.2 7
3.2 Hash function for RSA signatures . . . . . . . . . . . . . 5
2.3 7
3.3 Encoding method for RSA signatures . . . . . . . . . . . . 6
2.4 8
3.4 Identification type for EAP . . . . . . . . . . . . . . . 6
2.5 9
3.5 Identity for policy lookups when using EAP . . . . . . . . 7
2.6 9
3.6 EAP authentication and the AUTH payload . . . . . . . . . 7
2.7 9
3.7 Certificate encoding types . . . . . . . . . . . . . . . . 7
2.8 10
3.8 Shared key authentication and fixed PRF key size . . . . . 8
2.9 10
3.9 EAP authentication and fixed PRF key size . . . . . . . . 9
2.10 11
3.10 Matching ID payloads to certificate contents . . . . . . 9
3. Keying and rekeying . . . 11
3.11 Message IDs for IKE_AUTH messages . . . . . . . . . . . 11
4. Creating CHILD_SAs . . . . . . 9
3.1 Semantics of the CREATE_CHILD_SA exchange . . . . . . . . 9
3.2 Rekeying the IKE_SA vs. reauthentication . . . . . . . 12
4.1 Creating SAs with the CREATE_CHILD_SA exchange . . 13
3.3 SPIs when rekeying the IKE_SA . . . . 12
4.2 Creating an IKE_SA without a CHILD_SA . . . . . . . . . . 14
3.4 SPI when rekeying a
4.3 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 15
4.4 Extended Sequence Numbers (ESN) transform . . . 14
3.5 Changing PRFs when rekeying the IKE_SA . . . . . . 15
4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . 14
3.6 Deleting vs. closing SAs . . . 16
4.6 Negotiation of NON_FIRST_FRAGMENTS_ALSO . . . . . . . . . 16
4.7 Semantics of complex traffic selector payloads . . . . . 14
3.7 Deleting a CHILD_SA pair . . 16
4.8 ICMP type/code in traffic selector payloads . . . . . . . 17
4.9 Mobility header in traffic selector payloads . . . . . . . 17
4.10 Narrowing the traffic selectors . 15
3.8 Deleting an IKE_SA . . . . . . . . . . . 18
4.11 SINGLE_PAIR_REQUIRED . . . . . . . . . 15
3.9 Who is the original initiator of IKE_SA . . . . . . . . . 15
4. 18
4.12 Traffic selectors violating own policy . . . . . . . . . 19
4.13 Definition of TSi and TSr . . . . . . . . . . . . 16
4.1 Semantics of complex traffic selector payloads . . . 19
4.14 Port ranges end at 65535 . . . 16
4.2 ICMP type/code in traffic selector payloads . . . . . . . 16
4.3 Mobility header in traffic selector payloads . . . . . . 20
5. Rekeying and deleting SAs . 17
4.4 Narrowing the traffic selectors . . . . . . . . . . . . . 17
4.5 SINGLE_PAIR_REQUIRED . . . 20
5.1 Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 20
5.2 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 21
5.3 SPIs when rekeying the IKE_SA . 17
4.6 Traffic selectors violating own policy . . . . . . . . . . 18
5. Configuration payloads . . . 22
5.4 SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 22
5.5 Changing PRFs when rekeying the IKE_SA . 19
5.1 Length of configuration attribute type field . . . . . . . 19
5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . 22
5.6 Deleting vs. closing SAs . . . . . . . 19
5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 19
5.4 INTERNAL_IP4_NETMASK . 23
5.7 Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 23
5.8 Deleting an IKE_SA . 22
5.5 Configuration payloads for IPv6 . . . . . . . . . . . . . 23
5.6 INTERNAL_IP6_ADDRESS prefix length . . . . . . 23
5.9 Who is the original initiator of IKE_SA . . . . . . . 24
5.7 INTERNAL_IP6_NBNS . . 24
5.10 Sending traffic while rekeying . . . . . . . . . . . . . 24
6. Configuration payloads . . . . . 25
5.8 INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . 24
6.1 Assigning IP addresses . . . 25
6. Miscellaneous issues . . . . . . . . . . . . . . . 24

Eronen & Hoffman Expires January 16, 2006 [Page 2]

Internet-Draft IKEv2 Clarifications July 2005

6.2 Length of configuration attribute type field . . . . . 26
6.1 Diffie-Hellman for first CHILD_SA . . 25
6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 25
6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 26
6.2 Extended Sequence Numbers (ESN) transform . . . . . . . . 26
6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR
6.5 INTERNAL_IP4_NETMASK . . . . . . . . . . 27
6.4 Relationship of IKEv2 to RFC2401bis . . . . . . . . . 28
6.6 Configuration payloads for IPv6 . . 27
6.5 Reducing the window size . . . . . . . . . . . 29
6.7 INTERNAL_IP6_ADDRESS prefix length . . . . . . 27
6.6 Minimum size of nonces . . . . . . 30
6.8 INTERNAL_IP6_NBNS . . . . . . . . . . . . 28
6.7 Initial zero octets on port 4500 . . . . . . . . 31
6.9 INTERNAL_ADDRESS_EXPIRY . . . . . 28

Eronen & Hoffman Expires December 3, 2005 [Page 2]

Internet-Draft IKEv2 Clarifications June 2005

6.8 SPI values in IKE_SA_INIT exchange . . . . . . . . . . . . 29
6.9 SPI values for messages outside of an IKE_SA 31
7. Miscellaneous issues . . . . . . . 30
6.10 Protocol ID/SPI fields in Notify payloads . . . . . . . 30
6.11 INVALID_IKE_SPI . . . . . . 32
7.1 Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 32
7.2 Relationship of IKEv2 to RFC2401bis . . . . . 30
6.12 Which message should contain INITIAL_CONTACT . . . . . . 31
6.13 Message IDs for IKE_SA_INIT messages 32
7.3 Reducing the window size . . . . . . . . . . . 31
6.14 Message IDs for IKE_AUTH messages . . . . . . 33
7.4 Minimum size of nonces . . . . . 32
6.15 Creating an IKE_SA without a CHILD_SA . . . . . . . . . 32
6.16 Alignment of payloads . . . . 33
7.5 Initial zero octets on port 4500 . . . . . . . . . . . . . 32
6.17 Negotiation 33
7.6 SPI values for messages outside of ESP_TFC_PADDING_NOT_SUPPORTED an IKE_SA . . . . . . 32
6.18 Negotiation . 34
7.7 Protocol ID/SPI fields in Notify payloads . . . . . . . . 34
7.8 Which message should contain INITIAL_CONTACT . . . . . . . 35
7.9 Alignment of NON_FIRST_FRAGMENTS_ALSO payloads . . . . . . . . 33
7. . . . . . . . . . . 35
8. Status of the clarifications . . . . . . . . . . . . . . . . 33
8. 35
9. Implementation mistakes . . . . . . . . . . . . . . . . . . 35
9. 37
10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 35
10. 38
11. Security considerations . . . . . . . . . . . . . . . . . . 36
11. 38
12. IANA considerations . . . . . . . . . . . . . . . . . . . . 36
12. 38
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36
13. 38
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
13.1 39
14.1 Normative References . . . . . . . . . . . . . . . . . . 36
13.2 39
14.2 Informative References . . . . . . . . . . . . . . . . . 37 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 41
A. Exchanges and payloads . . . . . . . . . . . . . . . . . . . 39 41
A.1 IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 39 42
A.2 IKE_AUTH exchange without EAP . . . . . . . . . . . . . . 40 42
A.3 IKE_AUTH exchange with EAP . . . . . . . . . . . . . . . . 41 43
A.4 CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs . 41 43
A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA . . . . . 42 44
A.6 INFORMATIONAL exchange . . . . . . . . . . . . . . . . . . 42 44
Intellectual Property and Copyright Statements . . . . . . . 43 45

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 3]

Internet-Draft IKEv2 Clarifications June July 2005

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. Authentication Creating the IKE_SA

2.1 Data included SPI values in AUTH payload calculation

Section 2.15 describes how IKE_SA_INIT exchange

Normal IKE messages include the AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi') initiator's and prf(SK_pr,IDr'). The
text describes the method responder's SPIs,
both of which are non-zero, in words, but does the IKE header. However, there are
some corner cases where the IKEv2 specification is not give clear
definitions of fully
consistent about what is signed or MACed.

The initiator's signed octets can values should be described as: 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 December 3, 2005 January 16, 2006 [Page 4]

Internet-Draft IKEv2 Clarifications June July 2005

The

Since the responder's signed octets can be described as:

2.2 Hash function for RSA signatures

Section 3.8 says that RSA digital signature is "Computed as specified SPI identifies security-related state held by
the responder, and in section 2.15 using an RSA private key over this case no state is created, sending a PKCS#1 padded hash."

Unlike IKEv1, IKEv2 zero
value seems reasonable.

Second, in addition to cookies, there are several other cases when
the IKE_SA_INIT exchange does not negotiate a hash function for result in the
IKE_SA. The algorithm for signatures is selected by creation of an IKE_SA
(for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What
responder SPI value should be used in the signing
party who, IKE_SA_INIT response in general, may not know beforehand what algorithms
this case?

Since the
verifying party supports. Furthermore, [IKEv2ALG] does not say what
algorithms implementations are required or recommended to support.
This clearly IKE_SA_INIT request always has a potential for causing interoperability problems,
since authentication will fail if zero responder SPI, the signing party selects an
algorithm that is
value will not supported be actually used by the verifying party, or not
acceptable according to the verifying party's policy. initiator. Thus, we think
sending a zero value is correct also in this case.

2.2 Message IDs for IKE_SA_INIT messages

The Message ID for IKE_SA_INIT messages is always zero. This document recommends that all implementations support SHA-1, and
use SHA-1
includes retries of the message due to responses such as COOKIE and
INVALID_KE_PAYLOAD.

This is because Message IDs are part of the default hash function IKE_SA state, and when generating
the
signatures, unless there are good reasons (such as explicit manual
configuration) responder replies to believe that the other end supports something else.

Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
signature encoding method (see next section for details), which
includes IKE_SA_INIT request with N(COOKIE) or
N(INVALID_KE_PAYLOAD), the algorithm identifier for the hash algorithm. Thus, when
the verifying party 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 the AUTH payload an IKE_SA_INIT request, it can has to determine
whether the packet is a retransmission belonging to an existing
"half-open" IKE_SA (in which
hash function was used.

Other possible choices include, case the responder retransmits the same
response), or a new request (in which case the responder creates a
new IKE_SA and sends a fresh response).

The specification does not describe in detail how this determination
is done. In particular, it is not sufficient to use the initiator's
SPI and/or IP address for example, 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 function (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

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 5]

Internet-Draft IKEv2 Clarifications June July 2005

that was used to sign

bit in the certificate. However, this approach
assumes that IKE header).

2.4 Interaction of COOKIE and INVALID_KE_PAYLOAD

There are two common reasons why the recipient's "IKEv2 module" supports initiator may have to retry the same
algorithms as
IKE_SA_INIT exchange: the "certificate validation module" (which may not be
true, especially if something like [SCVP] is used). Furthermore, not
all CERT payloads types include responder requests a signature; and the certificate
could be signed with some other algorithm cookie or wants a
different Diffie-Hellman group than RSA.

(References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's
reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04.)

2.3 Encoding method for RSA signatures

Section 3.8 says that the RSA digital signature is "Computed as
specified was included in section 2.15 using an RSA private key over a PKCS#1
padded hash."

The current version the KEi payload.
Both of PKCS#1 (v2.1) [PKCS1v21] defines these cases are quite simple alone, but it is not totally
obvious what happens when they occur at the same time.

There are basically two different
encoding methods (ways of "padding cases, depending on whether the hash") for signatures.
However, IKEv2 points to
responder checks cookies before the older PKCS#1 v2.0 [PKCS1v20]. That
version has only one encoding method for signatures (EMSA-PKCS1-
v1_5), KEi payload or vice versa. If
cookies are checked first, the IKE_SA_INIT exchanges will look like
this:

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

If the KE payload is checked before cookies, the exchange is slightly
shorter:

HDR(A,0), 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

If checking both KE payload and thus there cookies at the same time were
allowed, it would potentially result in a even shorter exchange:

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

Note clear that this encoding method case is different from not allowed by the encoding method
used text in IKEv1. If future revisions the
spec. Section 2.6 clearly says that if the initiator receives a
cookie, it "MUST retry the IKE_SA_INIT with a Notify payload of type

Eronen & Hoffman Expires January 16, 2006 [Page 6]

Internet-Draft IKEv2 provide support for Clarifications July 2005

COOKIE containing the responder supplied cookie data as the first
payload and all other encoding methods (such payloads unchanged." Since "all other
payloads" clearly includes the KEi payload as EMSA-PSS), they will be given new
Auth Method numbers.

(References: Pasi Eronen's mail "RE:", 2005-01-04.)

2.4 Identification type for EAP

Section 3.5 defines several well, selecting a
different types Diffie-Hellman group 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 it is used not allowed when it occurs
together with Network Access Identifiers
(NAIs) defined in [NAI] and [NAIbis]. 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 cookie.

3. Authentication

3.1 Data included in [RFC822]. This raises the
question of which identification type should be used.

This document recommends that ID_RFC822_ADDR identification type is
used for those NAIs that include the realm component. Therefore,
responder implementations should not attempt to verify that AUTH payload calculation

Section 2.15 describes how the
contents actually conform to AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
text describes the exact syntax given method in [RFC822] or
[RFC2822], words, but instead should accept any reasonable looking NAI.

For NAIs that do does not include the realm component, this document
recommends give clear
definitions of what is signed or MACed.

The initiator's signed octets can be described as:

InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using the ID_KEY_ID identification type.

Eronen & Hoffman Expires December 3, 2005 [Page 6]

Internet-Draft IKEv2 Clarifications June 2005

(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
identifier issue with EAP" threads, Aug 2004.)

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

2.6 EAP authentication and the AUTH payload

Section 2.16 says that "For EAP methods that create a shared key as a
side effect of authentication, that shared key MUST be used by both
the initiator and responder to generate AUTH payloads in messages 5
and 6 using the syntax for shared secrets specified in section 2.15."

This text should say "messages 7 and 8".

(References: "How to do authentication with EAP" thread, Feb 2005)

2.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 December 3, 2005 [Page 7]

Internet-Draft IKEv2 Clarifications June 2005

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.

2.8 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 (currently only PRF_AES128_CBC)
should not be used with shared key authentication.

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,

Eronen & Hoffman Expires December 3, 2005 [Page 8]

Internet-Draft IKEv2 Clarifications June 2005

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

2.9 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. A strict
interpretation of this text also means that such PRFs are unlikely to
be useful for EAP authentication, since [EAP] specifies that the MSK
is at least 64 octets (512 bits) long, while PRF_AES128_CBC requires
a 128-bit key. It is currently under discussion whether truncation
or padding should be allowed in the EAP case (where the security
implications of truncation are slightly different).

(References: Thread "Question about PRFs with fixed size key", Jan
2005.)

2.10 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. Keying and rekeying

3.1 Semantics of the CREATE_CHILD_SA exchange

The section responder's signed octets can be reorganized
with subsections described as:

3.2 Hash function for each use of the CREATE_CHILD_SA exchange
(creating child SAs, rekeying IKE SAs, and rekeying child SAs.)

Further, specific parts of RSA signatures

Section 3.1 can be clarified. These
include:

o It 3.8 says that RSA digital signature is not clear which SA to send "Computed as specified
in section 2.15 using an RSA private key over a rekeying PKCS#1 padded hash."

Unlike IKEv1, IKEv2 does not negotiate a child SA. hash function for the
IKE_SA. The
relevant sentence says "If this CREATE_CHILD_SA exchange algorithm for signatures is
rekeying an existing SA other than the IKE_SA, selected by the leading N
payload of type REKEY_SA MUST identify signing
party who, in general, may not know beforehand what algorithms the SA being rekeyed."
That can be clarified by adding "sender's inbound" before "SA
being rekeyed".
verifying party supports. Furthermore, [IKEv2ALG] does not say what
algorithms implementations are required or recommended to support.

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 9] 7]

Internet-Draft IKEv2 Clarifications June July 2005

o The specific method for rekeying an IKE_SA is not described in the
section that describes the rekeying.

This is described in Section
2.8. Relevant text from Section 2.8 can be moved here.

o Section 1.3 never mentions the REKEY_SA Notification, but it does
have a mandatory Notification payload when rekeying. The
CREATE_CHILD_SA exchange MUST include a REKEY_SA Notification
payload with an SPI field identifying the SA being rekeyed.

o The spec is partially wrong about the use of nonces in computing
keys for CHILD_SAs. Section 1.3 says "The nonces from the initial
exchange are used in computing the keys for the CHILD_SA."
However, that is not always true. It is only true for clearly has a CHILD_SA
created in the IKE_AUTH exchange. Thus, the sentence can be
ignored because the use of the nonces potential for computing the keys is
clear in Section 2.17.

The new Section 1.3 with subsections and causing interoperability problems,
since authentication will fail if the above changes might look
like this.

NEW-1.3 The CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA Exchange signing party selects an
algorithm that is used to create new CHILD_SAs and not supported by the verifying party, or not
acceptable according to rekey both IKE_SAs and CHILD_SAs. the verifying party's policy.

This exchange consists of a
single request/response pair, document recommends that all implementations support SHA-1, and some of its function was
referred to
use SHA-1 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 default hash function when generating the initial exchange
signatures, unless there are
cryptographically protected using good reasons (such as explicit manual
configuration) to believe that the cryptographic algorithms
and keys negotiated in other end supports something else.

Note that unlike IKEv1, IKEv2 uses the first two messages of PKCS#1 v1.5 [PKCS1v20]
signature encoding method (see next section for details), which
includes the IKE
exchange. These subsequent messages use algorithm identifier for the syntax of hash algorithm. Thus, when
the
Encrypted Payload described in section 3.14. All subsequent
messages included an Encrypted Payload, even if they are
referred to in verifying party receives the text as "empty". For both messages in AUTH payload it can determine which
hash function was used.

Other possible choices include, for example, using the
CREATE_CHILD_SA, hash function
that was used to sign the message following certificate. However, this approach
assumes that the header is encrypted
and recipient's "IKEv2 module" supports the message including same
algorithms as the header "certificate validation module" (which may not be
true, especially if something like [SCVP] is integrity protected
using used). Furthermore, not
all CERT payloads types include a signature; and the cryptographic algorithms negotiated certificate
could be signed with some other algorithm than RSA.

(References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's
reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04.)

3.3 Encoding method for RSA signatures

Section 3.8 says that the IKE_SA.

The CREATE_CHILD_SA RSA digital signature is used for rekeying IKE_SAs and
CHILD_SAs. This "Computed as
specified in section describes the first part 2.15 using an RSA private key over a PKCS#1
padded hash."

The current version of rekeying,
the creation PKCS#1 (v2.1) [PKCS1v21] defines two different
encoding methods (ways of new SAs; Section 2.8 covers "padding the mechanics of
rekeying, including moving traffic from old hash") for signatures.
However, IKEv2 points to new SAs and the
deletion of the old SAs. The two sections must be read together
to understand 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 entire process of rekeying.

Either endpoint may initiate a CREATE_CHILD_SA exchange, so encoding method
used in

Eronen & Hoffman Expires December 3, 2005 [Page 10]

Internet-Draft IKEv1. If future revisions of IKEv2 Clarifications June 2005

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 provide support for an additional Diffie-Hellman exchange to enable stronger
guarantees of forward secrecy
other encoding methods (such as EMSA-PSS), they will be given new
Auth Method numbers.

(References: Pasi Eronen's mail "RE:", 2005-01-04.)

Eronen & Hoffman Expires January 16, 2006 [Page 8]

Internet-Draft IKEv2 Clarifications July 2005

3.4 Identification type for the CHILD_SA. The keying
material 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 CHILD_SA is a function use of SK_d established
during the establishment any particular type of the IKE_SA, the nonces exchanged
during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
value (if KE payloads are included
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in the CREATE_CHILD_SA
exchange).

If a CREATE_CHILD_SA exchange includes [NAI] and [NAIbis]. Although NAIs look a KEi payload, at least
one of bit like
email addresses (e.g., "joe@example.com"), the SA offers MUST include syntax is not exactly
the Diffie-Hellman group of same as the KEi. The Diffie-Hellman group syntax of email address in [RFC822]. This raises the KEi MUST be an element
question of which identification type should be used.

This document recommends that ID_RFC822_ADDR identification type is
used for those NAIs that include the group the initiator expects 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
(additional Diffie-Hellman groups can be proposed). If any reasonable looking NAI.

For NAIs that do not include the
responder rejects 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 Diffie-Hellman group
contents of the KEi payload,
the responder MUST reject the request IDi payload is used only for AAA routing purposes and indicate its preferred
Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
payload. In
selecting which EAP method to use. This value may be different from
the case of such a rejection, identity authenticated by the CREATE_CHILD_SA
exchange fails, EAP method (see [EAP], Sections 5.1
and 7.3).

It is important that policy lookups and access control decisions use
the initiator SHOULD retry actual authenticated identity. Often the exchange with
a Diffie-Hellman proposal and KEi EAP server is
implemented in the group a separate AAA server that communicates with the IKEv2
responder gave in the INVALID_KE_PAYLOAD.

NEW-1.3.1 Creating New CHILD_SAs with using, e.g., RADIUS [RADEAP]. In this case, the CREATE_CHILD_SA Exchange

A CHILD_SA may
authenticated identity has to 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 {SA, Ni, [KEi],
TSi, TSr} -->

The initiator sends SA offer(s) in sent from the SA payload, a nonce in AAA server to the Ni payload, optionally a Diffie-Hellman value
IKEv2 responder.

(References: Pasi Eronen's mail "RE: Reauthentication in the KEi
payload, IKEv2",
2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748,
Section 7.3.)

3.6 EAP authentication and the proposed traffic selectors for the proposed
CHILD_SA in the TSi and TSr payloads.

The CREATE_CHILD_SA response for creating AUTH payload

Section 2.16 says that "For EAP methods that create a new CHILD_SA is:

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

The responder replies (using shared key as a
side effect of authentication, that shared key MUST be used by both
the same Message ID initiator and responder to respond)
with the accepted offer generate AUTH payloads in an SA payload, messages 5
and a Diffie-Hellman 6 using the syntax for shared secrets specified in section 2.15."

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 11] 9]

Internet-Draft IKEv2 Clarifications June July 2005

value in

This text should say "messages 7 and 8".

(References: "How to do authentication with EAP" thread, Feb 2005)

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 KEr payload if KEi was included
certificate type codes above is not defined in this document."
However, the request and
the selected cryptographic suite includes text does not provide references to other documents that group.

The traffic selectors for traffic
would contain information about the exact contents and use of those
values.

Without this information, it is not possible to develop interoperable
implementations. Therefore, this document recommends that the
following certificate encoding values should not be sent on used before new
specifications that SA specify their use are
specified in the TS payloads in the response, which 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 a
subset of what the initiator of the CHILD_SA proposed.

NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request for rekeying an IKE_SA is:

Initiator Responder
----------- -----------
HDR, SK {SA, Ni, KEi} -->

The initiator sends SA offer(s) in the SA payload, a nonce used.)

This document recommends that most implementations should use only
those values that are "MUST"/"SHOULD" requirements in
the Ni payload, [IKEv2]; i.e.,
"X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and a Diffie-Hellman value in the KEi payload.
New initiator
URL of X.509 certificate" (12), and responder SPIs are supplied in "Hash and URL of X.509 bundle"
(13).

Furthermore, Section 3.7 says that the SPI fields.

The CREATE_CHILD_SA response "Certificate Encoding" field
for rekeying an IKE_SA is:

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

The responder replies (using the same Message ID to respond)
with the accepted offer in an SA payload, and a Diffie-Hellman
value in the KEr Certificate Request payload if uses the selected cryptographic suite
includes that group.

The new IKE_SA has its message counters set to 0, regardless same values as for
Certificate payload. However, the contents of
what they were in the earlier IKE_SA. The window size starts at
1 "Certification
Authority" field are defined only for any new IKE_SA.

KEi X.509 certificates (presumably
covering at least types 4, 10, 12, and KEr 13). This document recommends
that other values should not be used before new specifications that
specify their use are required for rekeying an IKE_SA.

NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request for rekeying a CHILD_SA is:

Initiator Responder
----------- -----------
HDR, SK {N, SA, Ni, [KEi],
TSi, TSr} --> available.

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 "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 Shared key authentication and TSr payloads. When rekeying an existing
CHILD_SA, fixed PRF key size

Section 2.15 says that "If the leading N payload of type REKEY_SA MUST be negotiated prf takes a fixed size key,

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 12] 10]

Internet-Draft IKEv2 Clarifications June July 2005

included and MUST give

the SPI (as they would shared secret MUST be expected in of that fixed size". This statement is
correct: the headers shared secret must be of inbound packets) 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 SAs
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_CBC [RFC3664] uses fixed key sizes; that
RFC is currently being rekeyed.

The CREATE_CHILD_SA response updated to handle variable key sizes.

Note that Section 2.13 also contains text that is related to PRFs
with fixed key size: "When the key for rekeying the prf function has fixed
length, the data provided as a CHILD_SA is:

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

The responder replies (using key is truncated or padded with zeros
as necessary unless exceptional processing is explained following the same Message ID
formula". However, this text applies only to respond)
with the accepted offer prf+ construction,
so it does not contradict the text in an SA payload, 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 EAP authentication and a Diffie-Hellman
value in the KEr payload if KEi was included fixed PRF key size

As described in the request and
the selected cryptographic suite includes previous section, PRFs with a fixed key size
require a shared secret of exactly that group.

The traffic selectors for traffic size. This restriction
applies also to EAP authentication. For instance, a PRF that
requires a 128-bit key cannot be sent on used with EAP since [EAP] specifies
that SA are
specified in the TS MSK is at least 512 bits long.

(References: Thread "Question about PRFs with fixed size key", Jan
2005.)

3.10 Matching ID payloads in to certificate contents

In IKEv1, there was some confusion about whether or not the response, which may be a
subset of what
identities in certificates used to authenticate IKE were required to
match the initiator contents of the CHILD_SA proposed.

3.2 Rekeying ID payloads. There has been some work done
on this in the IKE_SA vs. reauthentication

Rekeying PKI4IPSEC Working Group, but that work is not finished
at this time. However, Section 3.5 explicitly says that the IKE_SA and reauthentication are different concepts ID
payload "does not necessarily have to match anything in
IKEv2. Rekeying the IKE_SA establishes new keys CERT
payload".

3.11 Message IDs for the IKE_AUTH messages

According to Section 2.2, "The IKE_SA initial setup messages will

Eronen & Hoffman Expires January 16, 2006 [Page 11]

Internet-Draft IKEv2 Clarifications July 2005

always be numbered 0 and
resets 1." That is true when the Message ID counters, but it IKE_AUTH exchange
does not authenticate the
parties again (no AUTH or use EAP. When EAP payloads are involved).

While rekeying is used, each pair of messages have their
message numbers incremented. The first pair of AUTH messages will
have an ID of 1, the IKE_SA may second will be important 2, and so on.

(References: "Question about MsgID in some environments,
reauthentication (the verification that the parties still have access
to AUTH exchange" thread, April
2005.)

4. Creating CHILD_SAs

4.1 Creating SAs with the long-term credentials) is often more important.

IKEv2 CREATE_CHILD_SA exchange

Section 1.3's organization does not have any special support for reauthentication.
Reauthentication lead to clear understanding of
what is done by creating a new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
deletes the old CHILD_SAs as well).

This means that reauthentication also establishes new keys needed in which environment. The section can be reorganized
with subsections for each use of the
IKE_SA CREATE_CHILD_SA exchange
(creating child SAs, rekeying IKE SAs, and CHILD_SAs. Therefore, while rekeying child SAs.)

Further, specific parts of Section 3.1 can be performed
more often than reauthentication, the situation where "authentication
lifetime" clarified. These
include:

o It is shorter than "key lifetime" does not make sense.

While creation of clear which SA to send in a new IKE_SA rekeying a child SA. The
relevant sentence says "If this CREATE_CHILD_SA exchange is
rekeying an existing SA other than the IKE_SA, the leading N
payload of type REKEY_SA MUST identify the SA being rekeyed."
That can be initiated clarified by either party
(initiator or responder adding "sender's inbound" before "SA
being rekeyed".

o The specific method for rekeying an IKE_SA is not described in the original IKE_SA),
section that describes the use of EAP
authentication and/or configuration payloads means rekeying. This is described in practice that
reauthentication has to Section
2.8. Relevant text from Section 2.8 can be initiated by the same party as moved here.

o Section 1.3 never mentions the
original IKE_SA. IKEv2 REKEY_SA Notification, but it does not currently allow
have a mandatory Notification payload when rekeying. The
CREATE_CHILD_SA exchange MUST include a REKEY_SA Notification
payload with an SPI field identifying the responder to
request reauthentication in this case; however, there SA being rekeyed.

o The spec is ongoing work
to add this functionality [ReAuth].

Eronen & Hoffman Expires December 3, 2005 [Page 13]

Internet-Draft IKEv2 Clarifications June 2005

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

3.3 SPIs when rekeying partially wrong about the IKE_SA use of nonces in computing
keys for CHILD_SAs. Section 2.18 1.3 says that "New initiator and responder SPIs are supplied
in the SPI fields". This refers to "The nonces from the SPI fields initial
exchange are used in computing the Proposal
structures inside keys for the Security Association (SA) payloads, CHILD_SA."
However, that is not the SPI
fields in the IKE header.

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

3.4 SPI when rekeying always true. It is only true for a CHILD_SA

Section 3.10.1 says that
created in REKEY_SA notifications, "The SPI field
identifies the SA being rekeyed."

Since CHILD_SAs always exist IKE_AUTH exchange. Thus, the sentence can be
ignored because the use of the nonces for computing the keys is
clear in pairs, there are two different SPIs. Section 2.17.

The SPI placed in new Section 1.3 with subsections and the REKEY_SA notification above changes might look
like this.

NEW-1.3 The CREATE_CHILD_SA Exchange

Eronen & Hoffman Expires January 16, 2006 [Page 12]

Internet-Draft IKEv2 Clarifications July 2005

The CREATE_CHILD_SA Exchange is the SPI the used to create new CHILD_SAs and
to rekey both IKE_SAs and CHILD_SAs. This exchange
initiator would expect in inbound ESP or AH packets (just consists of a
single request/response pair, and some of its function was
referred to as a phase 2 exchange in
Delete payloads).

3.5 Changing PRFs when rekeying IKEv1. It MAY be initiated
by either end of the IKE_SA

When rekeying after the IKE_SA, Section 2.18 says that "SKEYSEED for initial exchanges are
completed.

All messages following the
new IKE_SA is computed initial exchange are
cryptographically protected using SK_d from the existing IKE_SA as
follows:

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

If the old cryptographic algorithms
and new IKE_SA selected a different PRF, it is not clear
which PRF should be used.

Regardless keys negotiated in the first two messages of which is the correct answer, it works poorly if IKE
exchange. These subsequent messages use the new
IKE_SA's PRF has a fixed key size. If syntax of the new PRF is also used
Encrypted Payload described in section 3.14. All subsequent
messages included an Encrypted Payload, even if they are
referred to
calculate SKEYSEED, then SK_d may not be of in the text as "empty". For both messages in the
CREATE_CHILD_SA, the message following the correct size. And if
SKEYSEED header is calculated using encrypted
and the old PRF, then it may not be of message including the
correct size header is integrity protected
using the cryptographic algorithms negotiated for the new PRF.

Although it is not yet clear which IKE_SA.

The CREATE_CHILD_SA is used for rekeying IKE_SAs and
CHILD_SAs. This section describes the correct answer, this
supports our opinion earlier in the document that first part of rekeying,
the use creation of PRFs
with a fixed key size is a bad idea.

3.6 Deleting vs. closing SAs

It is not clear that SAs must be actively deleted. The text
sometimes says that SAs are "closed" when it means that new SAs; Section 2.8 covers the mechanics of
rekeying, including moving traffic from old to new SAs are
actively deleted. Section 1.4 says "ESP and AH SAs always exist in

Eronen & Hoffman Expires December 3, 2005 [Page 14]

Internet-Draft IKEv2 Clarifications June 2005

pairs, with one SA in each direction. When an SA is closed, both
members the
deletion of the pair MUST old SAs. The two sections must be closed." It is important to note that
SAs that are closed need read together
to be actively deleted with DELETE payloads.

3.7 Deleting understand the entire process of rekeying.

Either endpoint may initiate a CHILD_SA pair

Section 1.4 describes how CREATE_CHILD_SA exchange, so in
this section the term initiator refers to delete SA pairs using the Informational
exchange: "To delete an SA, endpoint
initiating this exchange. An implementation MAY refuse all
CREATE_CHILD_SA requests within an INFORMATIONAL Exchange with one or
more delete payloads is sent listing 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 SPIs (as they would be
expected in CHILD_SA. The keying
material for the headers CHILD_SA is a function of inbound packets) SK_d established
during the establishment of the SAs to be deleted.
The recipient MUST close IKE_SA, the designated SAs."

The "one or more delete payloads" phrase has caused some confusion.
You never send delete payloads for nonces exchanged
during the two sides of an SA CREATE_CHILD_SA exchange, and the Diffie-Hellman
value (if KE payloads are included in a single
message. the CREATE_CHILD_SA
exchange).

If you have many SAs to delete a CREATE_CHILD_SA exchange includes a KEi payload, at least
one of the same time (such as
the nested example given in that paragraph), you include delete
payloads for in inbound half or each SA in your Informational
exchange.

3.8 Deleting offers MUST include the Diffie-Hellman group of
the KEi. The Diffie-Hellman group of the KEi MUST be an IKE_SA

Since IKE_SAs do not exist in pairs, it is not totally clear what element
of the
response message should contain when group the request deleted initiator expects the IKE_SA.

Since there is no information that needs responder to accept
(additional Diffie-Hellman groups can be sent to proposed). If the other side
(except that
responder rejects the Diffie-Hellman group of the KEi payload,
the responder MUST reject the request was received), an empty Informational
response seems like and indicate its preferred
Diffie-Hellman group in the most logical choice.

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

3.9 Who is INVALID_KE_PAYLOAD Notification
payload. In the original initiator case of IKE_SA

In such a rejection, the CREATE_CHILD_SA

Eronen & Hoffman Expires January 16, 2006 [Page 13]

Internet-Draft IKEv2 document, "initiator" refers to Clarifications July 2005

exchange fails, and the party who initiated initiator SHOULD retry the exchange being described, with
a Diffie-Hellman proposal and "original initiator" refers to KEi in the
party who initiated group that the whole IKE_SA. However, there is some
potential for confusion because
responder gave in the IKE_SA can INVALID_KE_PAYLOAD.

NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange

A CHILD_SA may be rekeyed created by either
party.

To clear up this confusion, we propose that "original initiator"
always refers to sending a CREATE_CHILD_SA request.
The CREATE_CHILD_SA request for creating a new CHILD_SA is:

Initiator Responder
----------- -----------
HDR, SK {SA, Ni, [KEi],
TSi, TSr} -->

The initiator sends SA offer(s) in the party who initiated SA payload, a nonce in
the exchange which resulted Ni payload, optionally a Diffie-Hellman value in the current IKE_SA. In other words, if KEi
payload, and the proposed traffic selectors for the "original
responder" starts rekeying proposed
CHILD_SA in the IKE_SA, that party becomes TSi and TSr payloads.

The CREATE_CHILD_SA response for creating a new CHILD_SA is:

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

The responder replies (using the
"original initiator" of same Message ID to respond)
with the new IKE_SA.

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

Eronen & Hoffman Expires December 3, 2005 [Page 15]

Internet-Draft IKEv2 Clarifications June 2005

4. Traffic an SA payload, and a Diffie-Hellman
value in the KEr payload if KEi was included in the request and
the selected cryptographic suite includes that group.

The traffic selectors

4.1 Semantics of complex for traffic selector payloads

As described to be sent on that SA are
specified in Section 3.13, the TSi/TSr 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 include one or
more individual traffic selectors.

There be found in Section 5.1 of this
document.

4.2 Creating an IKE_SA without a CHILD_SA

It is no requirement recommended 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 responder set up an IKE_SA even if it matches at least one of is
not possible to set up a CHILD_SA, as long as there is agreement on
the
individual selectors in TSi, and at least one cryptographic parts of the individual
selectors IKE_SA. This might happen when the
parties 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 IKE_AUTH exchange agree on cryptographic protocols but
fail to anywhere, with any agree on IPsec issues. The list of responses in the
four combinations of source/destination ports (100,300), (100,400),
(200,300), and (200, 400).

This implies IKE_AUTH
exchange 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 should not the other two combinations, cannot
be negotiated as a single CHILD_SA pair using IKEv2. prevent an IKE_SA from being set up include
NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE,
FAILED_CP_REQUIRED, and TS_UNACCEPTABLE.

Eronen & Hoffman Expires January 16, 2006 [Page 14]

Internet-Draft IKEv2 Clarifications July 2005

(References: "IKEv2 Traffic Selectors?" "Questions about internal address" thread, Feb April, 2005.)

4.2 ICMP type/code

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 traffic selector payloads 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 traffic selector types 7 and 8 can also refer to ICMP type and
code fields. As described description of the ESN transform in Section 3.13.1, "For 3.3 has be proved
difficult to understand. When the ICMP protocol, ESN transform is included, it has
the two following meaning:

o A proposal containing one octet fields Type 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 Code are treated as a single 16 bit
integer (with Type 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 significant eight bits and Code 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).

Section 3.3.2 also says that "If Transform Type 5 is not included in
a proposal, use of Extended Sequence Numbers is assumed". Or in
other words, omitting the
least significant eight bits) port number for ESN transform means the purposes of
filtering based on this field."

This encoding is quite clear. However, same thing as both TSi and TSr are
always present, together they have two "start port" fields (one in
TSi and
including one in TSr) ESN transform with value 1.

This choice of default value is somewhat counterintuitive and two "end port" fields. Since ICMP messages
only have a single type/code field (instead as
described above, rarely useful. IPsec WG decided recently to change
this part of separate source/
destination ports, like TCP the specification, and UDP), there is some room make it mandatory to include the
ESN transform for
confusion.

One sensible interpretation would be that ESP/AH.

(References: "Technical change needed to IKEv2 before publication",
"STRAW POLL: Dealing with the ESN negotiation interop issue in case IKEv2"
and "Results of ICMP, the "start straw poll regarding: IKEv2 interoperability issue"
threads, March-April 2005.)

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 16] 15]

Internet-Draft IKEv2 Clarifications June July 2005

port" fields in TSi and TSr must always be equal, and likewise for
the "end port" fields.

4.3 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

4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED

The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in a
separate document later. However, [RFC2401bis]
Section 3.10.1 says that "For IKE, "This notification asserts that the sending
endpoint will NOT accept packets that contain Flow Confidentiality
(TFC) padding".

However, the IPv6 mobility header message type (MH type) is placed text does not say in which messages this notification
should be included, or whether the most
significant eight bits scope of the 16 bit local "port" selector."

(References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
message type as selector", 2003-10-14.)

4.4 Narrowing the traffic selectors

Section 2.9 describes how traffic selectors are negotiated when
creating this notification is a CHILD_SA. A more concise summary
single CHILD_SA or all CHILD_SAs of the narrowing process peer.

Our interpretation 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 that the entire set of traffic covered
by TSi/TSr, no narrowing scope is necessary, a single CHILD_SA, and the responder can
return the same TSi/TSr values.

o Otherwise, narrowing thus
this notification is needed. If the responder's policy allows
all traffic covered by TSi[1]/TSr[1] (the first traffic selectors included in TSi/TSr) but not entire TSi/TSr, the responder narrows to messages containing an
acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].

o SA payload
negotiating a CHILD_SA. If neither endpoint accepts TFC padding,
this notification will be included in both 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 request proposing an acceptable subset of TSi/TSr.

In
SA and the last two cases, there may be several subsets that are
acceptable (but their union response accepting it. If this notification is not); included
in this case, only one of the responder
arbitrarily chooses messages, TFC padding can still be sent in one
direction.

4.6 Negotiation of them, and includes ADDITIONAL_TS_POSSIBLE NON_FIRST_FRAGMENTS_ALSO

NON_FIRST_FRAGMENTS_ALSO notification is described in the response.

4.5 SINGLE_PAIR_REQUIRED

The description Section 3.10.1
simply as "Used for fragmentation control. See [RFC2401bis] for
explanation."

[RFC2401bis] says "Implementations that will transmit non-initial
fragments on a tunnel mode SA that makes use of the SINGLE_PAIR_REQUIRED non-trivial port (or
ICMP type/code or MH type) selectors MUST notify payload in
Sections 2.9 and 3.10.1 is not fully consistent.

Eronen & Hoffman Expires December 3, 2005 [Page 17]

Internet-Draft IKEv2 Clarifications June 2005

We do not attempt to describe a peer via the IKE
NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this payload
proposal if it will not accept non-initial fragments in this document either,
since 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 expected that most implementations will not have policies clear exactly how the negotiation works. Our
interpretation is that require separate SAs for each address pair.

Thus, if only some part (or parts) of the TSi/TSr proposed by negotiation works the
initiator same way as for
IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
is (are) acceptable to enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
in both the responder, most responders
should simply narrow TSi/TSr to request proposing an acceptable subset (as described in SA and the last two paragraphs response accepting it.
In other words, if the peer "rejects this proposal", it only omits
NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
reject the whole CHILD_SA creation.

4.7 Semantics of Section 2.9), rather than use
SINGLE_PAIR_REQUIRED.

4.6 Traffic selectors violating own policy

Section 2.9 describes complex traffic selector negotiation payloads

As described in great detail.
One aspect of this negotiation that may need some clarification is
that when creating a new SA, Section 3.13, the initiator should not propose traffic
selectors that violate its own policy. If this rule is not followed,
valid TSi/TSr payloads can include one or
more individual traffic may be dropped.

This is best illustrated by an example. Suppose that host A has a
policy whose effect selectors.

Eronen & Hoffman Expires January 16, 2006 [Page 16]

Internet-Draft IKEv2 Clarifications July 2005

There is no requirement that TSi and TSr contain the same number of
individual traffic to 192.0.1.66 is sent via host B
encrypted using AES, 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 all other hosts in 192.0.1.0/24
is also sent via B, but must use 3DES. Suppose also that host B
accepts anywhere, with any combination of AES the
four combinations of source/destination ports (100,300), (100,400),
(200,300), and 3DES.

If host A now proposes an SA (200, 400).

This implies that uses 3DES, and includes TSr
containing (192.0.1.0-192.0.1.0.255), this will 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 accepted by host
B. Now, host B 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 use this SA refer to send traffic from 192.0.1.66,
but those packets will be dropped by A since it requires ICMP type and
code fields. As described in Section 3.13.1, "For the use of
AES for those traffic. Even if host A creates ICMP protocol,
the two one octet fields Type and Code are treated as a new SA only for
192.0.1.66 that uses AES, host B may freely continue to use single 16 bit
integer (with Type in the first
SA most significant eight bits and Code in the
least significant eight bits) port number for the traffic. In purposes of
filtering based on this situation, when proposing the SA, host A
should have followed its own policy, field."

This encoding is quite clear. However, as both TSi 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 are
always present, together they have two "start port" fields (one in
TSi and one in TSr) and two "end port" fields. Since ICMP messages
only have a proposal "for traffic X
(TSi/TSr), do SA", single type/code field (instead of separate source/
destination ports, like TCP and (2) for UDP), there is some subset X' room for
confusion.

One sensible interpretation would be that in case of X, ICMP, the initiator
does not actually accept traffic X' with SA, "start
port" fields in TSi and (3) the initiator
would be willing to accept traffic X' with some SA' (!=SAi), valid
traffic can TSr must always be unnecessarily dropped since equal, and likewise for
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 "end port" fields.

4.9 Mobility header in traffic selector
negotiation examples", 2004-08-08.) payloads

Traffic selectors can use IP Protocol ID 135 to match the IPv6
mobility header [MIPv6]. However, the IKEv2 specification does not

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 18] 17]

Internet-Draft IKEv2 Clarifications June July 2005

5. Configuration payloads

5.1 Length of configuration attribute type field

In Section 3.15.1, Figure 23 shows that the length of

define how to represent the "Attribute "MH Type" field is 15 bits, while the text below the figure in traffic selectors.

At some point, it was expected that this will be defined in a
separate document later. However, [RFC2401bis] says that "For IKE,
the
length is 7 bits.

The figure IPv6 mobility header message type (MH type) is correct, placed in the field is 15 bits. most
significant eight bits of the 16 bit local "port" selector."

(References: Tero Kivinen's mail "Comments to "Issue #86: Add IPv6 mobility header
message type as selector", 2003-10-14.)

4.10 Narrowing the
draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will
ikev2-16 be traffic selectors

Section 2.9 describes how traffic selectors are negotiated when
creating a CHILD_SA. A more concise summary of the charm?", 2004-09-23. Charlie Kaufman's
mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It narrowing process
is expected that
this issue will be fixed during the "Authors' 48 hours" before presented below.

o If the
RFC is published.)

5.2 Requesting responder's policy does not allow any INTERNAL_IP4/IP6_ADDRESS

When describing part of the INTERNAL_IP4/IP6_ADDRESS attributes, Section
3.15.1 says that "In a request message, traffic
covered by TSi/TSr, it responds with TS_UNACCEPTABLE.

o If the address specified is a
requested address (or zero if responder's policy allows the entire set of traffic covered
by TSi/TSr, no specific address is requested)".
The question here narrowing is that does "zero" mean an address "0.0.0.0" or a
zero length string?

Earlier, necessary, and the responder can
return the same section also says that "If an attribute 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
CFG_REQUEST Configuration Payload is responder narrows to an
acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].

o If the responder's policy does not zero length allow all traffic covered by
TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it is taken as a
suggestion for narrows to
an acceptable subset of TSi/TSr.

In the last two cases, there may be several subsets that attribute". Also, are
acceptable (but their union is not); in this case, the table responder
arbitrarily chooses one of configuration
attributes shows that them, and includes ADDITIONAL_TS_POSSIBLE
notification in the length response.

4.11 SINGLE_PAIR_REQUIRED

The description of INTERNAL_IP4_ADDRESS is either "0
or 4 octets", the SINGLE_PAIR_REQUIRED notify payload in
Sections 2.9 and likewise, INTERNAL_IP6_ADDRESS 3.10.1 is either "0 or 17
octets".

Thus, if the client does not request a specific address, it includes
a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, fully consistent.

We do not an attribute
containing an all-zeroes address. The example attempt to describe this payload in 2.19 is thus
incorrect, this document either,
since it shows the attribute as
"INTERNAL_ADDRESS(0.0.0.0)".

However, since the value is only a suggestion, expected that most implementations are
recommended to ignore suggestions they do will not accept; or in other
words, treat the same way a zero-length INTERNAL_IP4_ADDRESS,
"0.0.0.0", and any other addresses have policies
that require separate SAs for each address pair.

Thus, if only some part (or parts) of the implementation does not
recognize as a reasonable suggestion.

5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes TSi/TSr proposed by the INTERNAL_IP4_SUBNET as "The protected
sub-networks that this edge-device protects. This attribute
initiator is made (are) acceptable to the responder, most responders

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 19] 18]

Internet-Draft IKEv2 Clarifications June July 2005

up of two fields; the first being

should simply narrow TSi/TSr to an IP address and the second being
a netmask. Multiple sub-networks MAY be requested. The responder
MAY respond with zero or more sub-network attributes."
INTERNAL_IP6_SUBNET is defined in a similar manner.

This raises two questions: first, since this information is usually
included in the TSr payload, what functionality does this attribute
add? And second, what does this attribute mean acceptable subset (as described in CFG_REQUESTs?

For
the first question, there seem to be last two sensible
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
response) indicates which subnets are accessible through the SA that
was just created.

The first interpretation paragraphs of Section 2.9), rather than use
SINGLE_PAIR_REQUIRED.

4.12 Traffic selectors violating own policy

Section 2.9 describes traffic selector negotiation in great detail.
One aspect of the INTERNAL_IP4/6_SUBNET attributes is
that they indicate additional subnets that can be reached through this gateway, but negotiation that may need some clarification is
that when creating a separate SA. According to this
interpretation, new SA, the INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses initiator should not included in TSr.

The second interpretation 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 the INTERNAL_IP4/6_SUBNET
attributes express the gateway's host A has a
policy about what whose effect is that traffic should be to 192.0.1.66 is sent through the gateway. The client can choose whether other via host B
encrypted using AES, and traffic (covered by TSr, but not to all other hosts in INTERNAL_IP4/6_SUBNET) 192.0.1.0/24
is also sent
through the gateway or directly 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 destination. According 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 this
interpretation, use the attributes are useful mainly first
SA for the traffic. In this situation, when TSr contains
addresses not proposing the SA, host A
should have followed its own policy, and included in 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 INTERNAL_IP4/6_SUBNET attributes.

These two interpretations are initiator
does not totally incompatible: in both
cases, they suggest that actually accept traffic to the addresses listed in X' with SA, and (3) the
INTERNAL_IP4/6_SUBNET attributes should initiator
would be sent via this gateway
(and, of course, the packets have willing to be sent over accept traffic X' with some SA whose SA' (!=SAi), valid
traffic selectors cover can be unnecessarily dropped since the address in question).

A couple responder can apply
either SA or SA' to traffic X'.

(References: "Question about "narrowing" ..." thread, Feb 2005.
"IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
negotiation examples", 2004-08-08.)

4.13 Definition of examples are given below. For instance, if there are two
subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
contains the following:

CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS() TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) and TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)

Then

Section 2.9 has a valid response could be the following (in which TSr and
INTERNAL_IP4_SUBNET contain mistake that is understandable from the same information): example but
still needs to be corrected. It says:

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 20] 19]

Internet-Draft IKEv2 Clarifications June July 2005

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)

The first of the two TS payloads is known as TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) (Traffic
Selector-initiator). The second is known as TSr = ((0, 0-65536, 192.0.1.0-192.0.1.63),
(0, 0-65536, 192.0.2.0-192.0.2.255))

In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information. Another possible reply would have been this:

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) (Traffic
Selector-responder). TSi = (0, 0-65536, 192.0.1.234-192.0.1.234) specifies the source address of traffic
forwarded from (or the destination address of traffic forwarded
to) the initiator of the CHILD_SA pair. TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)

This would mean that specifies the
destination address of the client can send all its traffic through forwarded from (or the
gateway, but source
address of the gateway does not mind if traffic forwarded to) the responder of the CHILD_SA
pair.

The last sentence above should read "TSr specifies the destination
address of the client sends traffic
not included by INTERNAL_IP4_SUBNET directly forwarded to (or the destination
(without going through source address of the gateway).

A different situation arises if
traffic forwarded from) the gateway has a policy that
requires responder of the CHILD_SA pair."

4.14 Port ranges end at 65535

In Section 2.19, the examples show traffic selectors with port ranges
"0-65536". That should be "0-65535".

5. Rekeying and deleting SAs

5.1 Rekeying SAs with the CREATE_CHILD_SA exchange

Continued from Section 4.1 of this document.

NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request for rekeying an IKE_SA is:

Initiator Responder
----------- -----------
HDR, SK {SA, Ni, KEi} -->

The initiator sends SA offer(s) in the two subnets to be carried SA payload, a nonce in separate
SAs. Then
the Ni payload, and a Diffie-Hellman value in the KEi payload.
New initiator and responder SPIs are supplied in the SPI fields.

The CREATE_CHILD_SA response like this would indicate to for rekeying an IKE_SA is:

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

The responder replies (using the client that if
it wants access same Message ID to respond)
with the second subnet, it needs to create accepted offer in an SA payload, and a separate
SA:

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65536, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65536, 192.0.1.0-192.0.1.63)

INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the address space. For instance, if Diffie-Hellman
value in the client requests KEr payload if the following:

CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65536, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65536, 192.0.2.155-192.0.2.155)

Then selected cryptographic suite
includes that group.

The new IKE_SA has its message counters set to 0, regardless of
what they were in the gateway's reply could be this: earlier IKE_SA. The window size starts at
1 for any new IKE_SA.

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 21] 20]

Internet-Draft IKEv2 Clarifications June July 2005

It is less clear what the attributes mean in CFG_REQUESTs,

KEi and
whether other lengths than zero make sense in this situation (but KEr are required for
INTERNAL_IP6_SUBNET, zero length is not allowed at all!). Currently
this document recommends that implementations should not include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
CFG_REQUESTs.

For rekeying an IKE_SA.

NEW-1.3.3 Rekeying CHILD_SAs with the IPv4 case, this document recommends using only netmasks
consisting of some amount of "1" bits followed by "0" bits; CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA request for
instance, "255.0.255.0" would not be rekeying a valid netmask for
INTERNAL_IP4_SUBNET.

(References: Tero Kivinen's mail "Intent of couple of attributes CHILD_SA is:

Initiator Responder
----------- -----------
HDR, SK {N, SA, Ni, [KEi],
TSi, TSr} -->

The initiator sends SA offer(s) in
Configuration Payload the SA payload, a nonce in IKEv2?", 2004-11-19. Srinivasa Rao
Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET
the Ni payload, optionally a Diffie-Hellman value in
IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
Clarifications and Implementation Guidelines", 2005-02-07.)

5.4 INTERNAL_IP4_NETMASK

Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, KEi
payload, and says
that "The internal network's netmask. Only one netmask is allowed the proposed traffic selectors for the proposed
CHILD_SA in the request TSi and reply messages (e.g., 255.255.255.0) TSr payloads. When rekeying an existing
CHILD_SA, the leading N payload of type REKEY_SA MUST be
included and it MUST give the SPI (as they would be
used only with an INTERNAL_IP4_ADDRESS attribute".

However, it is not clear what exactly this attribute means, as expected in
the
concept headers of "netmask" is not very well defined for point-to-point
links (unlike multi-access links, where it means "you can reach hosts
inside this netmask directly using layer 2, instead inbound packets) of sending
packets via the SAs being rekeyed.

The CREATE_CHILD_SA response for rekeying a router").

One possible interpretation would CHILD_SA is:

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

The responder replies (using the same Message ID to respond)
with the accepted offer in an SA payload, and a Diffie-Hellman
value in the KEr payload if KEi was included in the request and
the selected cryptographic suite includes that group.

The traffic selectors for traffic to be sent on that SA are
specified in the host is given TS payloads in the response, which may be a whole
block of IP addresses instead
subset of a single address. This is also what
Framed-IP-Netmask does the initiator of the CHILD_SA proposed.

5.2 Rekeying the IKE_SA vs. reauthentication

Rekeying the IKE_SA and reauthentication are different concepts in [RADIUS]
IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
resets the IPCP "subnet mask"
extension Message ID counters, but it does in PPP [IPCPSubnet]. This interpretation would also
work nicely with IPv6 (see not authenticate the following section).

However, one IKEv2 guru assured
parties again (no AUTH or EAP payloads are involved).

While rekeying the authors IKE_SA may be important in some environments,
reauthentication (the verification that this interpretation the parties still have access
to the long-term credentials) is often more important.

IKEv2 does not correct. Section 3.15.1 also says that multiple addresses are
assigned using multiple INTERNAL_IP4_ADDRESS attributes. have any special support for reauthentication.
Reauthentication is done by creating a new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 22] 21]

Internet-Draft IKEv2 Clarifications June July 2005

Currently, this document's interpretation is the following:

o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing
as INTERNAL_IP4_SUBNET containing the same information (see

payloads), creating new CHILD_SAs within the
previous section for description of INTERNAL_IP4_SUBNET).

o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the
example in Section 2.19 is incorrect in this sense. (Another
interpretation would be old IKE_SA (which
deletes the old CHILD_SAs as well).

This means that by sending, reauthentication also establishes new keys for instance, the
combination of INTERNAL_IP4_ADDRESS(192.0.2.0)
IKE_SA and
INTERNAL_IP4_NETMASK(255.255.255.0), the client is asking to CHILD_SAs. Therefore, while rekeying can be
assigned one IP address from performed
more often than reauthentication, the network 192.0.2.0/24. However,
this interpretation situation where "authentication
lifetime" is shorter than "key lifetime" does not supported make sense.

While creation of a new IKE_SA can be initiated by either party
(initiator or responder in the IKEv2 spec.)

This interpretation is not yet settled; and it would imply that original IKE_SA), the
whole attribute is totally unnecessary.

Yet another possible interpretation would be that
INTERNAL_IP4_NETMASK indicates a broadcast address, meaning use of EAP
authentication and/or configuration payloads means in practice that if a
client sends a packet
reauthentication has to this address, be initiated by the gateway will decrypt it
and send copies same party as the
original IKE_SA. IKEv2 does not currently allow the responder to all other VPN clients
request reauthentication in that address range.
However, no implementation is known to do this, and this case; however, there is nothing ongoing work
to add this functionality [ReAuth].

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

5.3 SPIs when rekeying the IKEv2 spec that would support this interpretation.

Fortunately, IKE_SA

Section 4 clearly 2.18 says that a minimal implementation
does not need "New initiator and responder SPIs are supplied
in the SPI fields". This refers to include or understand the INTERNAL_IP4_NETMASK
attribute, and thus this document recommends that implementations
should SPI fields in the Proposal
structures inside the Security Association (SA) payloads, not use the INTERNAL_IP4_NETMASK attribute at all. SPI
fields in the IKE header.

(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 Tom Stiemerling's mail "Re: New I-D: IKEv2 Clarifications and
Implementation Guidelines", 2005-02-07.) "Rekey IKE SA", 2005-01-24.
Geoffrey Huang's reply, 2005-01-24.)

5.4 SPI when rekeying a CHILD_SA

Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
identifies the SA being rekeyed."

Since CHILD_SAs always exist in pairs, there are two different SPIs.
The SPI placed in the REKEY_SA notification is the SPI the exchange
initiator would expect in inbound ESP or AH packets (just as in
Delete payloads).

5.5 Configuration payloads for IPv6

IKEv2 also defines configuration payloads Changing PRFs when rekeying the IKE_SA

When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for IPv6. However, they
are based on the corresponding IPv4 payloads,
new IKE_SA is computed using SK_d from the existing IKE_SA as
follows:

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

If the old and do new IKE_SA selected a different PRF, it is not fully follow
the "normal IPv6 way of doing things". totally

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 23] 22]

Internet-Draft IKEv2 Clarifications June July 2005

A client can

clear which PRF should be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS configuration payload. Presumably, used.

Since the idea was
that a minimal rekeying exchange would look something like this:

CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/?)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65536, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65536, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used; neither belongs to the old IKE_SA, it is neighbor discovery.

While this approach the old
IKE_SA's PRF that is reasonably simple, it has some limitations:
IPsec tunnels configured using IKEv2 are not fully-featured
"interfaces" in used. This also follows the IPv6 addressing architecture [IPv6Addr] sense.
In particular, they do principle that the
same key (the old SK_d) should not necessarily have link-local addresses, and be used with multiple
cryptographic algorithms.

Note that this may complicate work poorly if the use new IKE_SA's PRF has a fixed
key size, since the output of protocols that assume them, such as
[MLDv2]. (Whether they are called "interfaces" the PRF may not be of the correct size.
This supports our opinion earlier in some particular
operating system the document that the use of
PRFs with a fixed key size is a different issue.) bad idea.

(References: "VPN remote host configuration IPv6 ?" "Changing PRFs when rekeying the IKE_SA" thread, May
2004.) June
2005.)

5.6 INTERNAL_IP6_ADDRESS prefix length

Earlier versions of Deleting vs. closing SAs

It is not clear that SAs must be actively deleted. The text
sometimes says that SAs are "closed" when it means that the IKEv2 draft had SAs are
actively deleted. Section 1.4 says "ESP and AH SAs always exist in
pairs, with one SA in each direction. When an INTERNAL_IP6_NETMASK
attribute corresponding SA is closed, both
members of the pair MUST be closed." It is important to INTERNAL_IP4_NETMASK, but this was note that
SAs that are closed need to be actively deleted
when the prefix length field was added with DELETE payloads.

5.7 Deleting a CHILD_SA pair

Section 1.4 describes how to delete SA pairs using the INTERNAL_IP6_ADDRESS
attribute. Thus, it seems logical to assume that their purpose Informational
exchange: "To delete an SA, an INFORMATIONAL Exchange with one or
more delete payloads is sent listing the SPIs (as they would be similar; however, this is far from obvious.
expected in the headers of inbound packets) of the SAs to be deleted.
The draft quite clearly says that recipient MUST close the client is assigned designated SAs."

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

5.8 Deleting an IPv6
address using the INTERNAL_IP6_ADDRESS attribute. However, as with
the netmask IKE_SA

Since IKE_SAs do not exist in IPv4, pairs, it is not totally clear what the prefix length here
means.

Again, one possible interpretation is that a prefix length smaller
than 128 in a CFG_REPLY means that
response message should contain when the client request deleted the IKE_SA.

Since there is assigned a whole
block of IPv6 addresses. This would no information that needs to be in line with sent to the IPv6
addressing architecture in general, and with, e.g., other side
(except that the Framed-IPv6-
Prefix attribute in [RADIUS6]. However, request was received), an empty Informational
response seems like the previous section most logical choice.

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 24] 23]

Internet-Draft IKEv2 Clarifications June July 2005

rejected this interpretation for IPv4, so it would seem strange to
adopt it only for IPv6.

Thus, if we assume that INTERNAL_IP4_NETMASK and the prefix length in
INTERNAL_IP6_ADDRESS have the same meaning, and the reasoning in the
previous section

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

5.9 Who is correct, then a CFG_REPLY containing a prefix
length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET.

However, CFG_REQUESTs are more complicated. It seems that a
CFG_REQUEST message that requests a specific IPv6 address (usually an
address this client was using earlier) should have prefix length 128.
But what do other prefix lengths mean in CFG_REQUESTs?

Section 3.15.1 says that "With IPv6, a requestor MAY supply original initiator of IKE_SA

In the low
order address bytes it wants IKEv2 document, "initiator" refers to the party who initiated
the exchange being described, and "original initiator" refers to use": presumably the prefix length
tells how many low order bits there are (i.e., if
party who initiated the prefix length
is X, there requester supplies 128-X low order address bits). whole IKE_SA. However, this there is quite confusing: if, say, a prefix length 126 means
that "I want to use these 128-126=2 low order bits", why does prefix
length 128 mean some
potential for confusion because the IKE_SA can be rekeyed by either
party.

To clear up this confusion, we propose that "I want "original initiator"
always refers to use these 128 low order bits"?

Another interpretation is the party who initiated the exchange which resulted
in the current IKE_SA. In other words, if the the "original
responder" starts rekeying the IKE_SA, that instead party becomes the
"original initiator" of "low order", the draft
should have said "high order", and thus new IKE_SA.

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

5.10 Sending traffic while rekeying

The last paragraph of Section 2.8 says: "The responder can be assured
that the initiator is prepared to receive messages on an SA if either
(1) it has received a prefix length smaller than
128 means "I'd like cryptographically valid message on the new SA,
or (2) the new SA rekeys an existing SA and it receives an IKE
request to get close the replaced SA. When rekeying an address from this subnet".

Given this very confusing discussion, this document recommends that
implementations should not use other INTERNAL_IP6_ADDRESS prefix
lengths than 128.

5.7 INTERNAL_IP6_NBNS

Section 3.15.1 defines SA, the INTERNAL_IP6_NBNS attribute for sending responder
SHOULD continue to send requests on the IPv6 address old SA until it one of NetBIOS name servers.

However, NetBIOS those
events occurs."

It is not defined for IPv6, clear that the paragraph is discussing both IKE_SAs and probably never will be.
Thus, this attribute most likely does not make much sense.

(Pointed out by Bernard Aboba in
CHILD_SAs. Therefore, the IP last sentence above should read "...SHOULD
continue to send traffic on the old SA...".

6. Configuration Security (ICOS)
BoF at IETF62.)

5.8 INTERNAL_ADDRESS_EXPIRY payloads

6.1 Assigning IP addresses

Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
"Specifies the number of seconds 2.9 talks about traffic selector negotiation and mentions
that "In support of the host can use scenario described in section 1.1.3, an
initiator may request that the internal responder assign an IP address. The host MUST renew 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 before
from the responder, but this expiry
time. Only one of these attributes MAY be present is done using configuration payloads,
not traffic selector payloads. An address in the reply."

Expiry times and explicit renewals are primarily useful 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

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 25] 24]

Internet-Draft IKEv2 Clarifications June July 2005

environments like DHCP, where

traffic selectors are sent by the server cannot reliably know when initiator, IPsec processing can be
performed as agreed for this SA. The TSi payload itself does not
give the initiator permission to configure the initiator's TCP/IP
stack with the address and use it as its source address.

In other words, IKEv2 does not have two different mechanisms for
assigning addresses, but only one: configuration payloads. In the client has gone away. However,
scenario described in IKEv2 this is known, Section 1.1.3, both configuration and traffic
selector payloads are usually included in the
gateway can simply free same message, and often
contain the address when same information in the IKE_SA is deleted.

Also, response message (see Section 4 says that supporting renewals is not mandatory.
Given that this functionality is usually not needed, we recommend
that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
(And since 6.4
of this attribute does not seem to make much sense document for
CFG_REQUESTs, clients should not send it either.)

Note that according to Section 4, clients some examples). However, their semantics are required to understand
INTERNAL_ADDRESS_EXPIRY if
still different.

6.2 Length of configuration attribute type field

In Section 3.15.1, Figure 23 shows that the receive it. A minimum implementation
would use length of the value to limit "Attribute
Type" field is 15 bits, while the lifetime of text below the IKE_SA. figure says the
length is 7 bits.

The figure is correct, the field is 15 bits.

(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. Miscellaneous issues

6.1 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 to the
draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will
ikev2-16 be the charm?", 2004-09-23. Charlie Kaufman's
mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It is expected that
this issue will be fixed during 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 "Authors' 48 hours" before the
RFC is published.)

6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS

When describing the
transform out entirely in this case.

6.2 Extended Sequence Numbers (ESN) transform INTERNAL_IP4/IP6_ADDRESS attributes, Section
3.15.1 says that "In a request message, the address specified is a
requested address (or zero if no specific address is requested)".
The description of question here is that does "zero" mean an address "0.0.0.0" or a
zero length string?

Earlier, the ESN transform same section also says that "If an attribute in Section 3.3 has be proved
difficult to understand. When the ESN transform
CFG_REQUEST Configuration Payload is included, it 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 zero length it is only allowed in requests; taken as a
suggestion for that attribute". Also, the response
will contain only one ESN transform.)

In most cases, table of configuration
attributes shows that the exchange initiator will include length of INTERNAL_IP4_ADDRESS is either the first "0
or third alternative in its SA payload. The second alternative 4 octets", and likewise, INTERNAL_IP6_ADDRESS is
rarely useful for either "0 or 17
octets".

Thus, if the initiator: client does not request a specific address, it means that using normal sequence includes
a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
containing an all-zeroes address. The example in 2.19 is thus
incorrect, since it shows the attribute as
"INTERNAL_ADDRESS(0.0.0.0)".

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 26] 25]

Internet-Draft IKEv2 Clarifications June July 2005

numbers is not acceptable (so if the responder does not support ESNs,

However, since the exchange will fail with NO_PROPOSAL_CHOSEN).

Section 3.3.2 also says that "If Transform Type 5 value is not included in only a proposal, use of Extended Sequence Numbers is assumed". Or suggestion, implementations are
recommended to ignore suggestions they do not accept; or in other
words, omitting the ESN transform means treat the same thing as
including one ESN transform with value 1.

This choice of default value is somewhat counterintuitive way a zero-length INTERNAL_IP4_ADDRESS,
"0.0.0.0", and any other addresses the implementation does not
recognize as
described above, rarely useful. IPsec WG decided recently to change a reasonable suggestion.

6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
sub-networks that this part edge-device protects. This attribute is made
up of two fields; the specification, first being an IP address and make it mandatory to include the
ESN transform for ESP/AH.

(References: "Technical change needed to IKEv2 before publication",
"STRAW POLL: Dealing second being
a netmask. Multiple sub-networks MAY be requested. The responder
MAY respond with zero or more sub-network attributes."
INTERNAL_IP6_SUBNET is defined in a similar manner.

This raises two questions: first, since this information is usually
included in the ESN negotiation interop issue TSr payload, what functionality does this attribute
add? And second, what does this attribute mean in IKEv2"
and "Results of straw poll regarding: IKEv2 interoperability issue"
threads, March-April 2005.)

6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR

When using CFG_REQUESTs?

For the first question, there seem to be two sensible
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
response) indicates which subnets are accessible through the SA that
was just created.

The first interpretation of the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require INTERNAL_IP4/6_SUBNET attributes is
that they indicate additional subnets that can be reached through
this address gateway, but need a separate SA. According to match the address in this
interpretation, the IP header (of IKEv2 packets), or anything INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses not included in the TSi/TSr
payloads. TSr.

The contents of IDi/IDr second interpretation is used purely to fetch that the INTERNAL_IP4/6_SUBNET
attributes express the gateway's policy
and authentication data related to about what traffic should be
sent through the other party.

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

6.4 Relationship of IKEv2 to RFC2401bis gateway. The IKEv2 document refers to [RFC2401bis], client can choose whether other
traffic (covered by TSr, but it never makes clear
what the exact relationship is. That is probably because there not in INTERNAL_IP4/6_SUBNET) is no
exact relationship. However, sent
through the IKEv2 document could state gateway or directly the destination. According to this
explicitly.

Section 2.24 of IKEv2 says "Specifically, tunnel encapsulators and
decapsulators for all tunnel-mode Security Associations (SAs) created
by IKEv2 MUST support
interpretation, the ECN full-functionality option for tunnels
specified attributes are useful mainly when TSr contains
addresses not included in [RFC3168] and MUST implement the tunnel encapsulation
and decapsulation processing specified in [RFC2401bis] to prevent
discarding of ECN congestion indications." This, in essence, says
that IKEv2 must be used with [RFC2401bis] only, not with RFC 2401,
because RFC 2401 has no requirements for ECN.

6.5 Reducing INTERNAL_IP4/6_SUBNET attributes.

These two interpretations are not totally incompatible: in both
cases, they suggest that traffic to the window size

In IKEv2, addresses listed in the window size is assumed
INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway
(and, of course, the packets have to be a (possibly configurable) sent over some SA whose
traffic selectors cover the address in question).

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 27] 26]

Internet-Draft IKEv2 Clarifications June July 2005

property

A couple of a particular implementation, and is not related to
congestion control (unlike the window size in TCP, for instance).

In particular, it is not defined what the responder should do when it
receives a SET_WINDOW_SIZE notification containing a smaller value
than is currently in effect. Thus, examples are given below. For instance, if there is currently no way to
reduce are two
subnets, 192.0.1.0/26 and 192.0.2.0/24, and the window size of an existing IKE_SA. However, when rekeying
an IKE_SA, client's request
contains the new IKE_SA starts with window size 1 until it is
explicitly increased by sending 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 new SET_WINDOW_SIZE notification.

(References: Tero Kivinen's mail "Comments of
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

6.6 Minimum size of nonces

Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
MUST valid response could be at least 128 bits in size, the following (in which TSr and MUST be at least half
INTERNAL_IP4_SUBNET contain the same information):

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))

In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information. Another possible reply would have been this:

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

This would mean that the key
size of client can send all its traffic through the negotiated prf."

However,
gateway, but the initiator chooses gateway does not mind if the nonce before client sends traffic
not included by INTERNAL_IP4_SUBNET directly to the outcome of destination
(without going through the
negotiation is known. In this case, gateway).

A different situation arises if the nonce gateway has to be long enough a policy that
requires the traffic for all the PRFs being proposed.

6.7 Initial zero octets on port 4500

It is not clear whether two subnets to be carried in separate
SAs. Then a peer sending an IKE_SA_INIT request on port
4500 should include the initial four zero octets. Section 2.23 talks
about how response like this would indicate to upgrade the client that if
it wants access to tunneling over port 4500 after message 2, but the second subnet, it does not say what needs to do if message 1 is sent on port 4500.

IKE MUST listen on port 4500 as well as port 500.

[...]

The IKE initiator MUST check these payloads create a separate
SA:

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)

Eronen & Hoffman Expires January 16, 2006 [Page 27]

Internet-Draft IKEv2 Clarifications July 2005

INTERNAL_IP4_SUBNET can also be useful if present and the client's TSr included
only part of the address space. For instance, if
they do not match the addresses client requests
the following:

CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Then the gateway's reply could be this:

CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

It is less clear what the attributes mean in the outer packet MUST tunnel
all future IKE CFG_REQUESTs, and ESP packets associated with
whether other lengths than zero make sense in this IKE_SA over
UDP port 4500.

To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of situation (but for
INTERNAL_IP6_SUBNET, zero prepended and the result immediately follows length is not allowed at all!). Currently
this document recommends that implementations should not include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
CFG_REQUESTs.

For the
UDP header. [...]

The very beginning 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.

(References: Tero Kivinen's mail "Intent of couple of attributes in
Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao
Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
Clarifications and Implementation Guidelines", 2005-02-07.)

6.5 INTERNAL_IP4_NETMASK

Section 2 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says "... though IKE
that "The internal network's netmask. Only one netmask is allowed in
the request and reply messages may
also (e.g., 255.255.255.0) and it MUST be received on UDP port 4500
used only with a slightly different format
(see section 2.23)."

That "slightly different format" an INTERNAL_IP4_ADDRESS attribute".

However, it is only described in discussing not clear what exactly this attribute means, as the
concept of "netmask" is not very well defined for point-to-point
links (unlike multi-access links, where it means "you can reach hosts
inside this netmask directly using layer 2, instead of sending
packets via a router").

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 28]

Internet-Draft IKEv2 Clarifications June July 2005

to do after changing to port 4500.

One possible interpretation would be that the host is given a whole
block of IP addresses instead of a single address. This is also what
Framed-IP-Netmask does in [RADIUS] and the IPCP "subnet mask"
extension does in PPP [IPCPSubnet]. This interpretation would also
work nicely with IPv6 (see the following section).

However, [RFC3948] shows clearly one IKEv2 guru assured the format has authors that this interpretation
is not correct. Section 3.15.1 also says that multiple addresses are
assigned using multiple INTERNAL_IP4_ADDRESS attributes.

Currently, this document's interpretation is the initial zeros even following:

o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing
as INTERNAL_IP4_SUBNET containing the same information (see the
previous section for initiators on port 4500.
Furthermore, without description of INTERNAL_IP4_SUBNET).

o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the initial zeros,
example in Section 2.19 is incorrect in this sense. (Another
interpretation would be that by sending, for instance, the processing engine cannot
determine whether
combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and
INTERNAL_IP4_NETMASK(255.255.255.0), the packet client is an IKE packet or an ESP packet.

Thus, all packets sent on port 4500 need asking to be
assigned one IP address from the four zero prefix;
otherwise, network 192.0.2.0/24. However,
this interpretation is not supported by the receiver won't know how IKEv2 spec.)

This interpretation is not yet settled; and it would imply that the
whole attribute is totally unnecessary.

Yet another possible interpretation would be that
INTERNAL_IP4_NETMASK indicates a broadcast address, meaning that if a
client sends a packet to handle them.

6.8 SPI values in IKE_SA_INIT exchange

Normal IKE messages include this address, the initiator's gateway will decrypt it
and responder's SPIs,
both of which are non-zero, send copies to all other VPN clients in the IKE header. that address range.
However, no implementation is known to do this, and there are
some corner cases where is nothing
in the IKEv2 specification is not fully
consistent about what values should be used.

First, spec that would support this interpretation.

Fortunately, Section 3.1 4 clearly says that a minimal implementation
does not need to include or understand the Responder's SPI "...MUST NOT be zero
in any other message" (than the first message of INTERNAL_IP4_NETMASK
attribute, and thus this document recommends that implementations
should not use the IKE_SA_INIT
exchange). INTERNAL_IP4_NETMASK attribute at all.

(References: Charlie Kaufman's mail "RE: Proposed Last Call based
revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
Implementation Guidelines", 2005-02-07.)

6.6 Configuration payloads for IPv6

IKEv2 also defines configuration payloads for IPv6. However, they
are based on the figure in Section 2.6 shows the second
IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting corresponding IPv4 payloads, and do not fully follow

Eronen & Hoffman Expires January 16, 2006 [Page 29]

Internet-Draft IKEv2 Clarifications July 2005

the text
in 3.1.

Since "normal IPv6 way of doing things".

A client can be assigned an IPv6 address using the responder's SPI identifies security-related state held by
INTERNAL_IP6_ADDRESS configuration payload. Presumably, the responder, and in idea was
that a minimal exchange would look something 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/?)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used; neither is neighbor discovery.

While this case no state approach is created, sending a zero
value seems reasonable.

Second, in addition to cookies, there reasonably simple, it has some limitations:
IPsec tunnels configured using IKEv2 are several other cases when
the IKE_SA_INIT exchange does not result fully-featured
"interfaces" in the creation IPv6 addressing architecture [IPv6Addr] sense.
In particular, they do not necessarily have link-local addresses, and
this may complicate the use of an IKE_SA
(for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What
responder SPI value should be used 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.)

6.7 INTERNAL_IP6_ADDRESS prefix length

Earlier versions of the IKE_SA_INIT response in IKEv2 draft had an INTERNAL_IP6_NETMASK
attribute corresponding to INTERNAL_IP4_NETMASK, but this case?

Since the IKE_SA_INIT request always has a zero responder SPI, was deleted
when the
value will not be actually used by prefix length field was added to the initiator. INTERNAL_IP6_ADDRESS
attribute. Thus, we think
sending a zero value is correct also in this case.

There is also an important detail about the Initiator SPI it seems logical to assume that must their purpose would
be taken into account by responders. If a responder receives two
IKE_SA_INIT requests with the same Initiator SPI, it must not
automatically conclude similar; however, this is far from obvious.

The draft quite clearly says that the latter client is a retransmission of assigned an IPv6
address using the
former. It INTERNAL_IP6_ADDRESS attribute. However, as with
the netmask in IPv4, it is possible that not clear what the packets were sent by two different
peers prefix length here
means.

Again, one possible interpretation is that just happened to choose the same Initiator SPI (IKEv2 does
not require a prefix length smaller
than 128 in a CFG_REPLY means that SPIs are chosen randomly). Instead, the responder
should compare the client is assigned a whole packets (or at
block of IPv6 addresses. This would be in line with the minimum, Ni payloads,
which are always chosen randomly) to determine whether or not this
packet creates a new IKE_SA or belongs to an existing IKE_SA. IPv6

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 29] 30]

Internet-Draft IKEv2 Clarifications June July 2005

6.9 SPI values for messages outside of an IKE_SA

The IKEv2 specification does not say what SPI values should be used

addressing architecture in general, and with, e.g., the IKE header for Framed-IPv6-
Prefix attribute in [RADIUS6]. However, the small number of notifications that are
allowed previous section
rejected this interpretation for IPv4, so it would seem strange to be sent outside of an IKE_SA. Note that such
notifications are explicitly *not* Informational exchanges; Section
1.5 makes
adopt it clear that these are one-way messages only for IPv6.

Thus, if we assume that must not be
responded to.

There are two cases when such a one-way notification can be sent:
INVALID_IKE_SPI INTERNAL_IP4_NETMASK and INVALID_SPI. In both cases, there are no IKE SPI
values that would be meaningful to the recipient of such a
notification.

A strict interpretation of prefix length in
INTERNAL_IP6_ADDRESS have the specification would require same meaning, and the sender
to invent garbage values for reasoning in the SPI fields.
previous section is correct, then a CFG_REPLY containing a prefix
length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET.

However, we think CFG_REQUESTs are more complicated. It seems that a
CFG_REQUEST message that requests a specific IPv6 address (usually an
address this client was not the intention, and using zero values is acceptable.

6.10 Protocol ID/SPI fields earlier) should have prefix length 128.
But what do other prefix lengths mean in Notify payloads CFG_REQUESTs?

Section 3.10 3.15.1 says that "With IPv6, a requestor MAY supply the Protocol ID field in Notify payloads "For
notifications which do not relate low
order address bytes it wants to an existing SA, this field MUST
be sent as zero and MUST be ignored on receipt". However, use": presumably the
specification does not clearly say which notifications are related to
existing SAs and which prefix length
tells how many low order bits there are not.

Since the main purpose of the Protocol ID field is to specify the
type of the SPI, our interpretation is that the Protocol ID field
should be non-zero only when (i.e., if the SPI field prefix length
is non-empty.

There are currently only two notifications where X, there requester supplies 128-X low order address bits).
However, this is the case:
INVALID_SELECTORS and REKEY_SA.

6.11 INVALID_IKE_SPI

Section 3.10.1 says that the INVALID_IKE_SPI notification "indicates
an IKE message was received with an unrecognized destination SPI.
This usually indicates quite confusing: if, say, a prefix length 126 means
that the recipient has rebooted and forgotten
the existence of an IKE_SA."

The text "I want to use these 128-126=2 low order bits", why does not say whether the SPI value should be included in the
notification. However, it is clear prefix
length 128 mean that the notification will be
useful "I want to use these 128 low order bits"?

Another interpretation is that instead of "low order", the recipient only if it can find the IKE_SA somehow, so
the SPI should be included.

This still leaves two questions open: which SPI(s) draft
should be
included, have said "high order", and how it (or they) thus a prefix length smaller than
128 means "I'd like to get an address from this subnet".

Given this very confusing discussion, this document recommends that
implementations should be sent. For the first
question, the alternatives are the unrecognized destination SPI, not use other INTERNAL_IP6_ADDRESS prefix
lengths than 128.

6.8 INTERNAL_IP6_NBNS

Section 3.15.1 defines the

Eronen & Hoffman Expires December 3, 2005 [Page 30]

Internet-Draft IKEv2 Clarifications June 2005

source SPI (which presumably would be more useful INTERNAL_IP6_NBNS attribute for sending
the recipient),
or both. For the second question, the SPI(s) could be placed in the
SPI field(s) in the IKE header, the SPI field in the Notify payload,
or the Notification Data field.

In the case IPv6 address of another related notification, INVALID_SPI, the
situation is clearer: there NetBIOS name servers.

However, NetBIOS is only a single SPI, not defined for IPv6, and probably never will be.
Thus, this attribute most likely does not make much sense.

(Pointed out by Bernard Aboba in the text
explicitly says that IP Configuration Security (ICOS)
BoF at IETF62.)

6.9 INTERNAL_ADDRESS_EXPIRY

Section 3.15.1 defines the SPI is sent INTERNAL_ADDRESS_EXPIRY attribute as Notification Data (since the
notification is not about an existing SA,
"Specifies the SPI field in number of seconds that the Notify
payload is not used; and obviously host can use the value cannot internal
IP address. The host MUST renew the IP address before this expiry
time. Only one of these attributes MAY be placed present in the
IKE header).

Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA, reply."

Eronen & Hoffman Expires January 16, 2006 [Page 31]

Internet-Draft IKEv2 Clarifications July 2005

Expiry times and it is not about an existing SA, it seems that using Notification
Data would be explicit renewals are primarily useful in
environments like DHCP, where the logical choice. server cannot reliably know when
the client has gone away. However, this issue needs more
discussion and we do not yet propose any solution in IKEv2 this document.

6.12 Which message should contain INITIAL_CONTACT

The description of is known, and the INITIAL_CONTACT notification in
gateway can simply free the address when the IKE_SA is deleted.

Also, Section 3.10.1 4 says that "This notification asserts supporting renewals is not mandatory.
Given that this IKE_SA functionality is usually not needed, we recommend
that gateways should not send the only
IKE_SA currently active between the authenticated identities".
However, neither Section 2.4 nor 3.10.1 says in which message INTERNAL_ADDRESS_EXPIRY attribute.
(And since this
payload should be placed.

The text attribute does talk about authenticated identities, so not seem to make much sense for
CFG_REQUESTs, clients should not send it seems the
notification cannot be sent before both endpoints have been
authenticated. Thus, the possible places either.)

Note that according to Section 4, clients are required to understand
INTERNAL_ADDRESS_EXPIRY if the last IKE_AUTH
response message and a separate Informational exchange.

Based on how this was implemented in IKEv1, it seems receive it. A minimum implementation
would use the intent was value to use a separate Informational exchange.

(References: "Clarifying limit the use lifetime of INITIAL_CONTACT in IKEv2" 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. "Initial Contact messages" thread, December 2004.
"IKEv2 2005.)

7. Miscellaneous issues

7.1 Matching ID_IPV4_ADDR and Initial Contact" thread, September 2004.)

6.13 Message IDs for IKE_SA_INIT messages ID_IPV6_ADDR

When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require this address to match the address in
the IP header (of IKEv2 packets), or anything in the TSi/TSr
payloads. The Message ID for IKE_SA_INIT messages is always zero. This
includes retries contents of IDi/IDr is used purely to fetch the message due policy
and authentication data related to responses such as COOKIE the other party.

(References: "Identities types IP address,FQDN/user FQDN and
INVALID_KE_PAYLOAD.

This DN and
its usage in preshared key authentication" thread, Jan 2005.)

7.2 Relationship of IKEv2 to RFC2401bis

The IKEv2 document refers to [RFC2401bis], but it never makes clear
what the exact relationship is. That is probably because Message IDs are part of there is no
exact relationship. However, the IKE_SA state, IKEv2 document could state this
explicitly.

Section 2.24 of IKEv2 says "Specifically, tunnel encapsulators and when
decapsulators for all tunnel-mode Security Associations (SAs) created
by IKEv2 MUST support the responder replies to IKE_SA_INIT request with N(COOKIE) or
N(INVALID_KE_PAYLOAD), ECN full-functionality option for tunnels
specified in [RFC3168] and MUST implement the responder does not allocate any state.

(References: "Question about N(COOKIE) tunnel encapsulation
and N(INVALID_KE_PAYLOAD) decapsulation processing specified in [RFC2401bis] to prevent
discarding of ECN congestion indications." This, in essence, says
that IKEv2 must be used with [RFC2401bis] only, not with RFC 2401,
because RFC 2401 has no requirements for ECN.

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 31] 32]

Internet-Draft IKEv2 Clarifications June July 2005

combination" thread, Oct 2004. Tero Kivinen's mail "Comments of
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

6.14 Message IDs for IKE_AUTH messages

According

7.3 Reducing the window size

In IKEv2, the window size is assumed to Section 2.2, "The IKE_SA initial setup messages will
always be numbered 0 a (possibly configurable)
property of a particular implementation, 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, related to
congestion control (unlike the second will be 2, and so on.

(References: "Question about MsgID window size in AUTH exchange" thread, April
2005.)

6.15 Creating an IKE_SA without a CHILD_SA

It TCP, for instance).

In particular, it is recommended that not defined what the responder set up should do when it
receives a SET_WINDOW_SIZE notification containing a smaller value
than is currently in effect. Thus, there is currently no way to
reduce the window size of an existing IKE_SA. However, when rekeying
an IKE_SA, the new IKE_SA even if starts with window size 1 until it is
not possible to set up
explicitly increased by sending a CHILD_SA, as long as there is agreement on 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 cryptographic parts key
size of the IKE_SA. This might happen when negotiated prf."

However, the
parties in initiator chooses the IKE_AUTH exchange agree on cryptographic protocols but
fail to agree on IPsec issues. The list nonce before the outcome of responses in the IKE_AUTH
exchange that should
negotiation is known. In this case, the nonce has to be long enough
for all the PRFs being proposed.

7.5 Initial zero octets on port 4500

It is not prevent clear whether a peer sending an IKE_SA from being set up IKE_SA_INIT request on port
4500 should include
NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE,
FAILED_CP_REQUIRED, and TS_UNACCEPTABLE.

(References: "Questions about internal address" thread, April, 2005.)

6.16 Alignment of payloads

Many IKEv2 payloads contain fields marked as "RESERVED", mostly
because IKEv1 had them, and partly because they make the pictures
easier initial four zero octets. Section 2.23 talks
about how to draw. In particular, payloads in IKEv2 are not, in
general, aligned upgrade to 4-byte boundaries. (Note that payloads were tunneling over port 4500 after message 2, but
it does not
aligned say what to 4-byte boundaries do if message 1 is sent on port 4500.

IKE MUST listen on port 4500 as well as port 500.

[...]

The IKE initiator MUST check these payloads if present and if
they do not match the addresses in IKEv1 either.)

(References: "IKEv2: potential 4-byte alignment problem" thread, June
2004.)

6.17 Negotiation the outer packet MUST tunnel
all future IKE and ESP packets associated with this IKE_SA over
UDP port 4500.

To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of ESP_TFC_PADDING_NOT_SUPPORTED zero prepended and the result immediately follows the
UDP header. [...]

The description very beginning of ESP_TFC_PADDING_NOT_SUPPORTED notification in Section 3.10.1 2 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 "... though IKE messages this notification
should may
also be included, or whether the scope of this notification is received on UDP port 4500 with a
single CHILD_SA or all CHILD_SAs of the peer. slightly different format

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 32] 33]

Internet-Draft IKEv2 Clarifications June July 2005

Our interpretation

(see section 2.23)."

That "slightly different format" is that only described in discussing what
to do after changing to port 4500. However, [RFC3948] shows clearly
the scope is a single CHILD_SA, and thus
this notification format has the initial zeros even for initiators on port 4500.
Furthermore, without the initial zeros, the processing engine cannot
determine whether the packet is included in an IKE packet or an ESP packet.

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

7.6 SPI values for messages containing outside of an SA payload
negotiating a CHILD_SA. If neither endpoint accepts TFC padding,
this notification will IKE_SA

The IKEv2 specification is not quite clear what SPI values should be included
used in both the request proposing an
SA and IKE header for the response accepting it. If this small number of notifications that are
allowed to be sent outside of an IKE_SA. Note that such
notifications are explicitly *not* Informational exchanges; Section
1.5 makes it clear that these are one-way messages that must not be
responded to.

There are two cases when such a one-way notification is included
in only one of the messages, TFC padding can still be sent in one
direction.

6.18 Negotiation sent:
INVALID_IKE_SPI and INVALID_SPI.

In case of NON_FIRST_FRAGMENTS_ALSO

NON_FIRST_FRAGMENTS_ALSO notification INVALID_IKE_SPI, the message sent is described in a response message,
and Section 3.10.1
simply as "Used for fragmentation control. See [RFC2401bis] for
explanation."

[RFC2401bis] 2.21 says "Implementations that will transmit non-initial
fragments on "If a tunnel mode SA response is sent, the response MUST
be sent to the IP address and port from whence it came with the same
IKE SPIs and the Message ID copied."

In case of INVALID_SPI, however, there are no IKE SPI values that makes use
would be meaningful to the recipient of non-trivial port (or
ICMP type/code or MH type) selectors MUST notify such a peer via notification. Also,
the IKE
NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject message sent is now an INFORMATIONAL request. A strict
interpretation of the specification would require the sender to
invent garbage values for the SPI fields. However, we think this
proposal if it will was
not accept non-initial fragments the intention, and using zero values is acceptable.

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

7.7 Protocol ID/SPI fields in this context.
If an implementation does Notify payloads

Section 3.10 says that the Protocol ID field in Notify payloads "For
notifications which do not successfully negotiate transmission of
non-initial fragments for such relate to an existing SA, it this field MUST NOT send such fragments
over the SA."
be sent as zero and MUST be ignored on receipt". However, it the
specification does not clearly say which notifications are related to
existing SAs and which are not.

Since the main purpose of the Protocol ID field is not clear exactly how to specify the negotiation works. Our
type of the SPI, our interpretation is that the negotiation works Protocol ID field
should be non-zero only when the same way as for
IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments SPI field is enabled non-empty.

Eronen & Hoffman Expires January 16, 2006 [Page 34]

Internet-Draft IKEv2 Clarifications July 2005

There are currently only if NON_FIRST_FRAGMENTS_ALSO two notifications where this is the case:
INVALID_SELECTORS and REKEY_SA.

7.8 Which message should contain INITIAL_CONTACT

The description of the INITIAL_CONTACT notification in Section 3.10.1
says that "This notification asserts that this IKE_SA is included 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 text does talk about authenticated identities, so it seems the
notification cannot be sent before both endpoints have been
authenticated. Thus, the request proposing an SA and possible places are the last IKE_AUTH
response accepting it.
In other words, if the peer "rejects message and a separate Informational exchange.

Based on how this proposal", was implemented in IKEv1, it only omits
NON_FIRST_FRAGMENTS_ALSO notification from seems the response, but does not
reject intent was
to use a separate Informational exchange.

(References: "Clarifying the whole CHILD_SA creation.

7. use of INITIAL_CONTACT in IKEv2" thread,
April 2005. "Initial Contact messages" thread, December 2004.
"IKEv2 and Initial Contact" thread, September 2004.)

7.9 Alignment of payloads

Many IKEv2 payloads contain fields marked as "RESERVED", mostly
because IKEv1 had them, and partly because they make the pictures
easier to draw. In particular, payloads in IKEv2 are not, in
general, aligned to 4-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.)

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 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 are
likely to change in future versions.

Those clarifications believed to be correct and without controversy
are marked with three asterisks (***); those where the clarification
is known to be incomplete and/or there is disagreement about what the
correct interpretation is are marked with one asterisk (*). The
clarifications marked with two asterisks (**) are somewhere between
the extremes.

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 33] 35]

Internet-Draft IKEv2 Clarifications June July 2005

the extremes.

2. Authentication Creating 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 and INVALID_KE_PAYLOAD ***
3. Authentication
3.1 Data included in AUTH payload calculation ***
2.2
3.2 Hash function for RSA signatures ***
2.3
3.3 Encoding method for RSA signatures ***
2.4
3.4 Identification type for EAP ***
2.5
3.5 Identity for policy lookups when using EAP ***
2.6
3.6 EAP authentication and the AUTH payload ***
2.7
3.7 Certificate encoding types ***
2.8
3.8 Shared key authentication and fixed PRF key size **
2.9
3.9 EAP authentication and fixed PRF key size *
2.10 ***
3.10 Matching ID payloads to certificate contents ***
3. Keying and rekeying
3.1
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 of NON_FIRST_FRAGMENTS_ALSO **
4.7 Semantics of complex traffic selector payloads ***
4.8 ICMP type/code in traffic selector payloads ***
4.9 Mobility header in traffic selector payloads ***
4.10 Narrowing the traffic selectors ***
4.11 SINGLE_PAIR_REQUIRED **
4.12 Traffic selectors violating own policy *
4.13 Definition of TSi and TSr **
4.14 Port ranges end at 65535 ***
5. Rekeying and deleting SAs
5.1 Rekeying SAs with the CREATE_CHILD_SA exchange *
3.2
5.2 Rekeying the IKE_SA vs. reauthentication **
3.3
5.3 SPIs when rekeying the IKE_SA ***
3.4 Which
5.4 SPI to use in REKEY_SA when rekeying a CHILD_SA ***
3.5
5.5 Changing PRFs when rekeying the IKE_SA *
3.6 ***
5.6 Deleting vs. closing SAs **
3.7
5.7 Deleting an SA pair **
3.8
5.8 Deleting an IKE_SA **
3.9
5.9 Who is the original initiator of IKE_SA **
4. Traffic selectors
4.1 Semantics of complex traffic selector payloads ***
4.2 ICMP type/code in traffic selector payloads ***
4.3 Mobility header in traffic selector payloads ***
4.4 Narrowing the
5.10 Sending traffic selectors ***
4.5 SINGLE_PAIR_REQUIRED while rekeying **
4.6 Traffic selectors violating own policy *
5.
6. Configuration payloads
5.1
6.1 Assigning IP addresses **
6.2 Length of configuration attribute type field ***
5.2

Eronen & Hoffman Expires January 16, 2006 [Page 36]

Internet-Draft IKEv2 Clarifications July 2005

6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS ***
5.3
6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET **
5.4
6.5 INTERNAL_IP4_NETMASK **
5.5
6.6 Configuration payloads for IPv6 *
5.6
6.7 INTERNAL_IP6_ADDRESS prefix length *
5.7
6.8 INTERNAL_IP6_NBNS ***
5.8
6.9 INTERNAL_ADDRESS_EXPIRY **
6.
7. Miscellaneous issues
6.1 Diffie-Hellman for first CHILD_SA ***
6.2 Extended Sequence Numbers (ESN) transform **
6.3
7.1 Matching ID_IPV4_ADDR and ID_IPV6_ADDR ***
6.4
7.2 Relationship of IKEv2 to RFC2401bis **
6.5
7.3 Reducing the window size **
6.6
7.4 Minimum size of nonces ***
6.7
7.5 Initial zero octets on port 4500 ***
6.8 SPI values in IKE_SA_INIT exchange **
6.9
7.6 SPI values for messages outside of an IKE_SA *
6.10
7.7 Protocol ID/SPI fields in Notify payloads **

Eronen & Hoffman Expires December 3, 2005 [Page 34]

Internet-Draft IKEv2 Clarifications June 2005

6.11 INVALID_IKE_SPI *
6.12
7.8 Which message should contain INITIAL_CONTACT **
6.13 Message IDs for IKE_SA_INIT messages **
6.14 Message IDs for IKE_AUTH messages ***
6.15 Creating an IKE_SA without a CHILD_SA **
6.16
7.9 Alignment of payloads ***
6.17 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED **
6.18 Negotiation of NON_FIRST_FRAGMENTS_ALSO **

Future versions of this document will, of course, change these
estimates (and changes in both directions are possible, though
hopefully it's more towards higher confidence).

9. Implementation mistakes

Some implementers at the first IKEv2 bakeoff 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.

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

o Some implementations responded to a delete request by sending an
empty INFORMATIONAL response, and then initiated their own
INFORMATIONAL exchange with the pair of SAs to delete.

o Although this did not happen at the bakeoff, from the discussion
there, it is clear that some people had not implemented message
window sizes correctly. Some implementations might have sent
messages that did not fit into the responder's message windows,

Eronen & Hoffman Expires January 16, 2006 [Page 37]

Internet-Draft IKEv2 Clarifications July 2005

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

This section lists issues that this document probably should address,
but has not done so yet.

Eronen & Hoffman Expires December 3, 2005 [Page 35]

Internet-Draft IKEv2 Clarifications June 2005

o Many of the configuration payload issues in this draft are still
far from clear. These need to be resolved before implementers can
feel assured of creating interoperable implementations.

o It would be very useful to have actual examples of certificate
type 12 (hash and URL of X.509 certificates) and type 13 (hash and
URL of X.509 bundle).

o This document might want to explicitly talk about not doing ESP-
in-AH even though it is possible. We could say "implementations
do not need to support this".

10.

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

12. IANA considerations

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

12.

13. 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, Mika
Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, and Michael
Richardson
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.

14. References

13.1

Eronen & Hoffman Expires January 16, 2006 [Page 38]

Internet-Draft IKEv2 Clarifications July 2005

14.1 Normative References

[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17 (work in progress),
September 2004.

[IKEv2ALG]
Schiller, J., "Cryptographic Algorithms for use in the
Internet Key Exchange Version 2",
draft-ietf-ipsec-ikev2-algorithms-05 (work in progress),

Eronen & Hoffman Expires December 3, 2005 [Page 36]

Internet-Draft IKEv2 Clarifications June 2005
April 2004.

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

[RFC2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), March 2005.

13.2

14.2 Informative References

[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.

[EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-06 (work in
progress), April 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

Eronen & Hoffman Expires January 16, 2006 [Page 39]

Internet-Draft IKEv2 Clarifications July 2005

(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
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.

Eronen & Hoffman Expires December 3, 2005 [Page 37]

Internet-Draft IKEv2 Clarifications June 2005

[NAIbis] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier",
draft-ietf-radext-rfc2486bis-05 (work in progress),
February 2005.

[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.

[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.

[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.

[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 3664,
January 2004.

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

[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-02 (work in progress), May 2005.

[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T.

Eronen & Hoffman Expires January 16, 2006 [Page 40]

Internet-Draft IKEv2 Clarifications July 2005

Polk, "Simple Certificate Validation Protocol (SCVP)",
draft-ietf-pkix-scvp-18 (work in progress), February 2005.

Authors' Addresses

Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland

Email: pasi.eronen@nokia.com

Eronen & Hoffman Expires December 3, 2005 [Page 38]

Internet-Draft IKEv2 Clarifications June 2005

Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
USA

Email: paul.hoffman@vpnc.org

Appendix A. Exchanges and payloads

This appendix contains a short summary of the IKEv2 exchanges, and
what payloads can appear in which message. This appendix is purely
informative; if it disagrees with the body of this document or the
IKEv2 specification, the other text is considered correct.

Vendor-ID (V) payloads may be included in any place in any message.
This sequence shows what are, in our opinion, the most logical places
for them.

The specification does not say which messages can contain
N(SET_WINDOW_SIZE). It can possibly be included in any message, but
it is not yet shown below.

Note: N(INITIAL_CONTACT) is still under discussion and is not shown
below.

Eronen & Hoffman Expires January 16, 2006 [Page 41]

Internet-Draft IKEv2 Clarifications July 2005

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 December 3, 2005 [Page 39]

Internet-Draft IKEv2 Clarifications June 2005

A.2 IKE_AUTH exchange without EAP

request --> IDi, [CERT+],
[[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 December 3, 2005 January 16, 2006 [Page 40] 42]

Internet-Draft IKEv2 Clarifications June July 2005

A.3 IKE_AUTH exchange with EAP

first request --> IDi,
[[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+]

A.4 CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs

request --> [N(REKEY)],
[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)]

Eronen & Hoffman Expires December 3, 2005 January 16, 2006 [Page 41] 43]

Internet-Draft IKEv2 Clarifications June July 2005

A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA

request --> N(REKEY),
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 December 3, 2005 January 16, 2006 [Page 42] 44]

Internet-Draft IKEv2 Clarifications June July 2005

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 (2005). 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 December 3, 2005 January 16, 2006 [Page 43] 45]

----