WDIFF

draft-eronen-ipsec-ikev2-clarifications-01.txt --> draft-eronen-ipsec-ikev2-clarifications-02.txt

Network Working Group P. Eronen
Internet-Draft Nokia
Expires: August 18, September 25, 2005 February 17, P. Hoffman
VPN Consortium
March 27, 2005

IKEv2 Clarifications and Implementation Guidelines
draft-eronen-ipsec-ikev2-clarifications-01.txt
draft-eronen-ipsec-ikev2-clarifications-02.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.

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

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

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

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

This Internet-Draft will expire on August 18, September 25, 2005.

Abstract

This document clarifies some many areas of the IKEv2 specification that
may be difficult to understand to developers not intimately familiar
with the specification and its history. The intent is specification. It
does not to introduce any changes to the protocol, but rather to provide
provides descriptions that are less prone to ambiguous interpretations, and thus
interpretations. The purpose of this document is to encourage the
development of interoperable implementations. Readers
are advised that this document is work-in-progress, and may contain
incorrect interpretations.

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 1]

Internet-Draft IKEv2 Clarifications February March 2005

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 4
2. Authentication . . . . . . . . . . . . . . . . . . . . . . . 3 4
2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr') . . . . . 3
2.2 PRFs with a fixed key size . . . . . . . . Data included in AUTH payload calculation . . . . . . . . 4
2.3
2.2 Hash function for RSA signatures . . . . . . . . . . . . . 5
2.4
2.3 Encoding method for RSA signatures . . . . . . . . . . . . 6
2.5
2.4 Identification type for EAP . . . . . . . . . . . . . . . 6
2.6
2.5 Identity for policy lookups when using EAP . . . . . . . . 7
2.7
2.6 EAP authentication and the AUTH payload . . . . . . . . . 7
2.8
2.7 Certificate encoding types . . . . . . . . . . . . . . . . 7
2.9 Hash-and-URL certificate encoding
2.8 Shared key authentication and fixed PRF key size . . . . . 8
2.9 EAP authentication and fixed PRF key size . . . . . . . . 9
3. Keying and rekeying . 8
2.10 Rekeying CHILD_SAs . . . . . . . . . . . . . . . . . . . 8
2.11 Rekeying 9
3.1 Semantics of the IKE_SA vs. reauthentication CREATE_CHILD_SA exchange . . . . . . . . 11
2.12 9
3.2 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 13
3.3 SPIs when rekeying the IKE_SA . . . . . . . . . 11
3. Configuration payloads . . . . . . 13
3.4 SPI when rekeying a CHILD_SA . . . . . . . . . . . . . 11
3.1 Length of configuration attribute type field . . 14
3.5 Deleting SAs . . . . . 11
3.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 12
3.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 12
3.4 INTERNAL_IP4_NETMASK 14
4. Traffic selectors . . . . . . . . . . . . . . . . . . . 15
3.5 INTERNAL_IP6_ADDRESS prefix length . . 14
4.1 Semantics of complex traffic selector payloads . . . . . . 14
4.2 ICMP type/code in traffic selector payloads . . . . 16
4. Other issues . . . 15
4.3 Mobility header in traffic selector payloads . . . . . . . 15
4.4 Narrowing the traffic selectors . . . . . . . . . . . . . 15
4.5 SINGLE_PAIR_REQUIRED . 17
4.1 Message ID in IKE_SA_INIT messages . . . . . . . . . . . . 17
4.2 INITIAL_CONTACT notify payload . . . . . . 16
4.6 Traffic selectors violating own policy . . . . . . . . 17
4.3 Diffie-Hellman for first CHILD_SA . . 16
5. Configuration payloads . . . . . . . . . . 17
4.4 Matching ID_IPV4_ADDR/ID_IPV6_ADDR . . . . . . . . . 17
5.1 Length of configuration attribute type field . . . . 18
4.5 Semantics of traffic selector payloads . . . 17
5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 17
5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 18
4.6 Traffic selector negotiation
5.4 INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . 18
4.7 Coexistence of multiple IPsec implementations . . . . 20
5.5 Configuration payloads for IPv6 . . . . . . . 19
5. Security considerations . . . . . . 22
5.6 INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . . 20 22
5.7 INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 23
6. IANA considerations Miscellaneous issues . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments 23
6.1 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 24
6.2 Extended Sequence Numbers (ESN) transform . . . . . . . . 24
6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . 20
8. References . . . . . . . . 24
6.4 Relationship of IKEv2 to RFC2401bis . . . . . . . . . . . 25
6.5 Reducing the window size . . . . . . 20
8.1 Normative References . . . . . . . . . . . 25
6.6 Minimum size of nonces . . . . . . . . . 20
8.2 Informative References . . . . . . . . . 25
6.7 Initial zero octets on port 4500 . . . . . . . . . . 20
Author's Address . . . 25
6.8 SPI values in IKE_SA_INIT exchange . . . . . . . . . . . . 26
6.9 SPI values for messages outside of an IKE_SA . . . . . . . 22
Intellectual Property and Copyright Statements 27
6.10 Protocol ID/SPI fields in Notify payloads . . . . . . . 23 27
6.11 INVALID_IKE_SPI . . . . . . . . . . . . . . . . . . . . 27
6.12 Which message should contain INITIAL_CONTACT . . . . . . 28
7. Status of the clarifications . . . . . . . . . . . . . . . . 28

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 2]

Internet-Draft IKEv2 Clarifications February March 2005

1. Introduction

This document clarifies some areas of the IKEv2 specification that
may be difficult to understand to developers not intimately familiar
with the specification and its history. The intent is not to
introduce any changes to the protocol, but rather to provide
descriptions less prone to ambiguous interpretations, and thus
encourage the development of interoperable implementations.

Readers are advised that this document is work-in-progress,

8. Implementation mistakes . . . . . . . . . . . . . . . . . . 30
9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 30
10. Security considerations . . . . . . . . . . . . . . . . . . 31
11. IANA considerations . . . . . . . . . . . . . . . . . . . . 31
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1 Normative References . . . . . . . . . . . . . . . . . . . 32
13.2 Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 35

Eronen & Hoffman Expires September 25, 2005 [Page 3]

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

2.1 Data included in AUTH payload calculation

Section 2.15 describes how the AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
text describes the method in words, but does not give clear
definitions of what is signed or MACed.

The initiator's signed octets can be described as:

Eronen & Hoffman Expires September 25, 2005 [Page 4]

Internet-Draft IKEv2 Clarifications March 2005

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
in section 2.15 using an RSA private key over a PKCS#1 padded hash."

Unlike IKEv1, IKEv2 does not negotiate a hash function for the
IKE_SA. The algorithm for signatures is selected by the signing
party who, in general, may not know beforehand what algorithms the
verifying party supports. Furthermore, [IKEv2ALG] does not say what
algorithms implementations are required or recommended to support.
This clearly has a potential for causing interoperability problems,
since authentication will fail if the signing party selects an
algorithm that is not supported by the verifying party, or not
acceptable according to the verifying party's policy.

This document recommends that all implementations support SHA-1, and
use SHA-1 as the default hash function when generating the
signatures, unless there are good reasons (such as explicit manual
configuration) to believe that the other end supports something else.

Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
signature encoding method (see next section for details), which
includes the algorithm identifier for the hash algorithm. Thus, when
the verifying party receives the AUTH payload it can determine which
hash function was used.

Other possible choices include, for example, using the hash function

Eronen & Hoffman Expires September 25, 2005 [Page 5]

Internet-Draft IKEv2 Clarifications March 2005

that was used to sign the certificate. However, this approach
assumes that the recipient's "IKEv2 module" supports the same
algorithms as the "certificate validation module" (which may not be
true, especially if something like [SCVP] is used). Furthermore, not
all CERT payloads types include a signature; and the 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.)

2.3 Encoding method for RSA signatures

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

The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
encoding methods (ways of "padding the hash") for signatures.
However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That
version has only one encoding method for signatures
(EMSA-PKCS1-v1_5), and thus there is no ambiguity.

Note that this encoding method is different from the encoding method
used in IKEv1. If future revisions of IKEv2 provide support for
other encoding methods (such as EMSA-PSS), they will be given new
Auth Method numbers.

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

2.4 Identification type for EAP

Section 3.5 defines several different types for identification
payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI] 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 in [RFC822]. This raises the
question of which identification type should be used.

This document recommends that ID_RFC822_ADDR identification type is
used for those NAIs that include the realm component. Therefore,
responder implementations should not attempt to verify that the
contents actually conform to the exact syntax given in [RFC822] or
[RFC2822], but instead should accept any reasonable looking NAI.

For NAIs that do not include the realm component, this document
recommends using the ID_KEY_ID identification type.

Eronen & Hoffman Expires September 25, 2005 [Page 6]

Internet-Draft IKEv2 Clarifications March 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 September 25, 2005 [Page 7]

Internet-Draft IKEv2 Clarifications March 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 September 25, 2005 [Page 8]

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

3. Keying and rekeying

3.1 Semantics of the CREATE_CHILD_SA exchange

Section 1.3's organization does not lead to clear understanding of
what is needed in which environment. The section can be reorganized
with subsections for each use of the CREATE_CHILD_SA exchange
(creating child SAs, rekeying IKE SAs, and rekeying child SAs.)

Further, specific parts of Section 3.1 can be clarified. These
include:

o It is not clear which SA to send in a 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 clarified by adding "sender's inbound" before "SA being
rekeyed".

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.

Eronen & Hoffman Expires September 25, 2005 [Page 9]

Internet-Draft IKEv2 Clarifications March 2005

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 a CHILD_SA
created in the IKE_AUTH exchange. Thus, the sentence can be
ignored because the use of the nonces for computing the keys is
clear in Section 2.17.

The new Section 1.3 with subsections and the above changes might look
like this.

NEW-1.3 The CREATE_CHILD_SA Exchange

The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
to rekey both IKE_SAs and CHILD_SAs. This exchange consists of a
single request/response pair, and some of its function was
referred to as a phase 2 exchange in IKEv1. It MAY be initiated
by either end of the IKE_SA after the initial exchanges are
completed.

All messages following the initial exchange are
cryptographically protected using the cryptographic algorithms
and keys negotiated in the first two messages of the IKE
exchange. These subsequent messages use the syntax of the
Encrypted Payload described in section 3.14. All subsequent
messages included an Encrypted Payload, even if they are
referred to in the text as "empty". For both messages in the
CREATE_CHILD_SA, the message following the header is encrypted
and the message including the header is integrity protected
using the cryptographic algorithms negotiated for the IKE_SA.

The CREATE_CHILD_SA is used for rekeying IKE_SAs and
CHILD_SAs. This section describes the first part of rekeying,
the creation of new SAs; Section 2.8 covers the mechanics of
rekeying, including moving traffic from old to new SAs and the
deletion of the old SAs. The two sections must be read together
to understand the entire process of rekeying.

Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
this section the term initiator refers to the endpoint
initiating this exchange. An implementation MAY refuse all
CREATE_CHILD_SA requests within an IKE_SA.

The CREATE_CHILD_SA request MAY optionally contain a KE payload
for an additional Diffie-Hellman exchange to enable stronger
guarantees of forward secrecy for the CHILD_SA. The keying
material for the CHILD_SA is a function of SK_d established
during the establishment of the IKE_SA, the nonces exchanged

Eronen & Hoffman Expires September 25, 2005 [Page 10]

Internet-Draft IKEv2 Clarifications March 2005

during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
value (if KE payloads are included in the CREATE_CHILD_SA
exchange).

If a CREATE_CHILD_SA exchange includes a KEi payload, at least
one of the SA offers MUST include the Diffie-Hellman group of
the KEi MUST be an element of the group the initiator expects
the responder to accept (additional Diffie-Hellman groups can be
proposed). If the responder rejects the Diffie-Hellman group of
the KEi payload, the responder MUST reject the request and
indicate its preferred Diffie-Hellman group in the
INVALID_KE_PAYLOAD Notification payload. In the case of such a
rejection, the CREATE_CHILD_SA exchange fails, and the initiator
SHOULD retry the exchange with a Diffie-Hellman proposal and KEi
in the group that the responder gave in the INVALID_KE_PAYLOAD.

NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange

A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
The CREATE_CHILD_SA request for creating a new CHILD_SA is:

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

The CREATE_CHILD_SA response for creating a new 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 TS payloads in the response, which may 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:

Eronen & Hoffman Expires September 25, 2005 [Page 11]

Internet-Draft IKEv2 Clarifications March 2005

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

The initiator sends SA offer(s) in the SA payload, a nonce in
the Ni payload, and optionally a Diffie-Hellman value in the KEi
payload. New initiator and responder SPIs are supplied in the
SPI fields.

The CREATE_CHILD_SA response for rekeying an IKE_SA is:

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

The new IKE_SA has its message counters set to 0, regardless of
what they were in the earlier IKE_SA. The window size starts at
1 for any new IKE_SA.

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

The initiator sends SA offer(s) in the SA payload, a nonce in
the Ni payload, optionally a Diffie-Hellman value in the KEi
payload, and the proposed traffic selectors for the proposed
CHILD_SA in the TSi and TSr payloads. When rekeying an existing
CHILD_SA, the leading N payload of type REKEY_SA MUST be
included and MUST identify the sender's inbound SA being
rekeyed.

The CREATE_CHILD_SA response for rekeying a CHILD_SA is:

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

Eronen & Hoffman Expires September 25, 2005 [Page 12]

Internet-Draft IKEv2 Clarifications March 2005

The traffic selectors for traffic to be sent on that SA are
specified in the TS payloadsin the response, which may
contain incorrect interpretations. Issues where be a
subset of what the initiator of the CHILD_SA proposed.

3.2 Rekeying the IKE_SA vs. reauthentication

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

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

IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
deletes the old CHILD_SAs as well).

This means that reauthentication also establishes new keys for the
IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
more often than reauthentication, the clarification situation where "authentication
lifetime" is
known to shorter than "key lifetime" does not make sense.

While creation of a new IKE_SA can be incomplete, initiated by either party
(initiator or there is no consensus on what responder in the original IKE_SA), the
interpretation should be, are marked as such. Clarifications use of EAP
authentication and/or configuration payloads means in practice that
are incorrect but
reauthentication has to be initiated by the author does not know this are not marked same party as
such :-).

This document does not place any requirements on anyone, and the
original IKE_SA. IKEv2 does not
use [RFC2119] keywords such as "MUST" and "SHOULD". The requirements
are given in currently allow the IKEv2 specification [IKEv2] and IKEv2 cryptographic
algorithms document [IKEv2ALG].

In this document, references responder to a numbered section (such as "Section
2.15") mean that section
request reauthentication in [IKEv2]. References to mailing list
messages refer this case; however, there is ongoing work
to add this functionality [ReAuth].

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

3.3 SPIs when rekeying 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

2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr') IKE_SA

Section 2.15 describes how AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
text continues 2.18 says that "In the above calculation, IDi' "New initiator and IDr' responder SPIs are supplied
in the
entire ID payloads excluding the fixed header.".

Here "fixed header" SPI fields". This refers to the "generic payload header" described SPI fields in Section 3.2. In other words, the data fed to Proposal
structures inside the prf includes Security Association (SA) payloads, not the
ID Type (1 octet), three RESERVED octets, followed by SPI
fields in the
Identification data (see Section 3.5). IKE header.

(References: Lakshminath Dondeti's Tom Stiemerling's mail "prf(SK_p, ID') computation",
2004-11-14. Charlie Kaufman's "Rekey IKE SA", 2005-01-24.
Geoffrey Huang's reply, 2004-11-16.) 2005-01-24.)

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 3] 13]

Internet-Draft IKEv2 Clarifications February March 2005

2.2 PRFs with

3.4 SPI when rekeying a fixed key size

(Preliminary text, still open.) CHILD_SA

Section 2.15 3.10.1 says that "If in REKEY_SA notifications, "The SPI field
identifies the negotiated prf takes a fixed size key, SA being rekeyed."

Since CHILD_SAs always exist in pairs, there are two different SPIs.
The SPI placed in the shared secret MUST be of that fixed size". This statement REKEY_SA notification is
correct: the shared secret must be of SPI the correct size. If it is
not, it cannot be used; there is no padding, truncation, exchange
initiator would expect in inbound ESP or other
processing involved to force it to that correct size.

This requirement means AH packets (just as in
Delete payloads).

3.5 Deleting SAs

It is not clear that some special care SAs must be taken when
using these PRFs for shared key authentication. actively deleted. The implementation
must not propose these PRFs text
sometimes says that SAs are "closed" when it means that the secret is of incorrect size; or SAs are
actively deleted. Section 1.4 says "ESP and AH SAs always exist in other words, if the implementation proposes
pairs, with one SA in each direction. When an SA is closed, both
members of these PRFs, it
must not allow the user pair MUST be closed." It is important to configure a shared secret with incorrect
size.

A strict interpretation of this text also means note that SAs
that these PRFs are
unlikely closed need to be useful for EAP authentication, since [EAP] specifies
that the MSK is at least 64 octets (512 bits) long, while currently
the only PRF that takes a fixed size key (PRF_AES128_CBC) requires a
128-bit key. It is currently under discussion whether truncation or
padding should be allowed actively deleted with DELETE payloads.

4. Traffic selectors

4.1 Semantics of complex traffic selector payloads

As described in Section 3.13, the EAP case.

Due to the way the AUTH payload TSi/TSr payloads can include one or
more individual traffic selectors.

There is calculated, this no requirement also
implies that TSi and TSr contain the same number of
individual traffic selectors. Thus, they are interpreted as follows:
a PRF with packet matches a fixed size key can be used for shared key
authentication only given TSi/TSr if the PRF produces an output it matches at least one of the same size as
individual selectors in TSi, and at least one of the key. This is individual
selectors in TSr.

For instance, the case for PRF_AES128_CBC, which uses a 128-bit
key and produces a 128-bit output.

Section 2.13 also contains text that is related 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 PRFs anywhere, with fixed
key size: "When the key for any of the prf function has fixed length,
four combinations of source/destination ports (100,300), (100,400),
(200,300), and (200, 400).

This implies that some types of policies may require several CHILD_SA
pairs. For instance, a policy matching only source/destination ports
(100,300) and (200,400), but not the
data provided other two combinations, cannot
be negotiated as a key is truncated or padded with zeros as necessary
unless exceptional processing is explained following the formula".
It seems that this text applies single CHILD_SA pair using IKEv2.

Eronen & Hoffman Expires September 25, 2005 [Page 14]

Internet-Draft IKEv2 Clarifications March 2005

(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.2 ICMP type/code in traffic selector payloads

The traffic selector types 7 and 8 can also refer to the prf+ construction ICMP type and
code fields. As described in Section 2.13; or in other words, prf+ always accepts a key of any
length, even if 3.13.1, "For the ICMP protocol,
the two one octet fields Type and Code are treated as a single 16 bit
integer (with Type in the underlying prf does not. Since most significant eight bits and Code in IKEv2 the key
least significant eight bits) port number for prf+ the purposes of
filtering based on this field."

This encoding is quite clear. However, as both TSi and TSr are
always an output from prf, this padding or truncation can
happen present, together they have two "start port" fields (one in
TSi and one in TSr) and two "end port" fields. Since ICMP messages
only if the prf has have a fixed key size that single type/code field (instead of separate
source/destination ports, like TCP and UDP), there is different from
the output size (e.g., it cannot happen some room for PRF_AES128_CBC).

Section 2.14 continues
confusion.

One sensible interpretation would be that "If in case of ICMP, the negotiated prf takes a fixed
length key "start
port" fields in TSi and the lengths of Ni TSr must always be equal, and Nr do 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 add up
define how to represent the "MH Type" field in traffic selectors.

At some point, it was expected that length,
half this will be defined in a
separate document later. However, [RFC2401bis] says that "For IKE,
the bits must come from Ni and half from Nr, taking IPv6 mobility header message type (MH type) is placed in the first most
significant eight bits of each". This raises the question about what happens if either 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 a CHILD_SA. A more concise summary of the nonces narrowing process
is shorter than half of presented below.

o If the key length (note that responder's policy does not allow any part of the
nonces are at least 128 bits, so this case cannot happen traffic
covered by TSi/TSr, it responds with
PRF_AES128_CBC). TS_UNACCEPTABLE.

o If the responder's policy allows the entire set of traffic covered
by TSi/TSr, no narrowing is necessary, and the responder can
return the same TSi/TSr values.

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 4] 15]

Internet-Draft IKEv2 Clarifications February March 2005

Due to these complications, this document recommends that

o Implementations that use shared secret authentication should
prefer PRFs that accept a variable length key, since this makes
the life of the administrator easier.

o New IKEv2 PRFs defined in the future should accept variable length
keys.

o If, despite the previous recommendation, a new IKEv2 PRF with a
fixed key size Otherwise, narrowing is defined 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 future, it should produce responder narrows to an
output
acceptable subset of the same size as the key. TSi/TSr that includes TSi[1]/TSr[1].

o If the responder's policy does not allow all traffic covered by
TSi[1]/TSr[1], but does allow some future implementation supports a PRF with a fixed key size parts of greater than 256 bits: when such a PRF is included in a
Security Association payload, TSi/TSr, it narrows to
an acceptable subset of TSi/TSr.

In the corresponding Ni/Nr payload must
be at least key size/2 bits long.

(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.3 Hash function for RSA signatures

Section 3.8 says two cases, there may be several subsets that RSA digital signature are
acceptable (but their union is "Computed as specified not); in section 2.15 using an RSA private key over a PKCS#1 padded hash."

Unlike IKEv1, IKEv2 does not negotiate a hash function for this case, the
IKE_SA. responder
arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE
notification in the response.

4.5 SINGLE_PAIR_REQUIRED

The algorithm for signatures is selected by description of the signing
party who, SINGLE_PAIR_REQUIRED notify payload in general, may not know beforehand what algorithms the
verifying party supports. Furthermore, [IKEv2ALG] does
Sections 2.9 and 3.10.1 is not say what
algorithms implementations are required or recommended fully consistent.

We do not attempt to support.
This clearly has a potential for causing interoperability problems, describe this payload in this document either,
since authentication it is expected that most implementations will fail not have policies
that require separate SAs for each address pair.

Thus, if only some part (or parts) of the signing party selects an
algorithm that is not supported TSi/TSr proposed by the verifying party, or not
initiator is (are) acceptable according to the verifying party's responder, most responders
should simply narrow TSi/TSr to an acceptable subset (as described in
the last two paragraphs of Section 2.9), rather than use
SINGLE_PAIR_REQUIRED.

4.6 Traffic selectors violating own policy

Section 2.9 describes traffic selector negotiation in great detail.
One aspect of this negotiation that may need some clarification is
that when creating a new SA, the initiator should not propose traffic
selectors that violate its own policy. If this rule is not followed,
valid traffic may be dropped.

This document recommends is best illustrated by an example. Suppose that all implementations support SHA-1, host A has a
policy whose effect is that traffic to 192.0.1.66 is sent via host B
encrypted using AES, and
use SHA-1 as the default hash function when generating the
signatures, unless there are good reasons (such as explicit manual
configuration) traffic to believe that the all other end supports something else.

Other possible choices include, for example, using the hash function hosts in 192.0.1.0/24
is also sent via B, but must use 3DES. Suppose also that was used to sign the certificate. However, 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 approach
assumes that the recipient's "IKEv2 module" supports the same
algorithms as the "certificate validation module" (which may not SA to send traffic from 192.0.1.66,
but those packets will be
true, especially dropped by A since it requires the use of
AES for those traffic. Even if something like [SCVP] is used). Furthermore, not
all CERT payloads types include host A creates a signature; and the certificate new SA only for

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 5] 16]

Internet-Draft IKEv2 Clarifications February March 2005

could

192.0.1.66 that uses AES, host B may freely continue to use the first
SA for the traffic. In this situation, when proposing the SA, host A
should have followed its own policy, and included a TSr containing
((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

In general, if (1) the initiator makes a proposal "for traffic X
(TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
does not actually accept traffic X' with SA, and (3) the initiator
would be signed willing to accept traffic X' with some other algorithm than RSA. SA' (!=SAi), valid
traffic can be unnecessarily dropped since the responder can apply
either SA or SA' to traffic X'.

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

2.4 Encoding method for RSA signatures "Question about "narrowing" ..." thread, Feb 2005.
"IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
negotiation examples", 2004-08-08.)

5. Configuration payloads

5.1 Length of configuration attribute type field

In Section 3.8 says 3.15.1, Figure 23 shows that the RSA digital signature length of the "Attribute
Type" field is 15 bits, while the text below the figure says the
length is "Computed as
specified in section 2.15 using an RSA private key over a PKCS#1
padded hash." 7 bits.

The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
encoding methods (ways of "padding figure is correct, the hash") for signatures.
However, IKEv2 points field is 15 bits.

(References: Tero Kivinen's mail "Comments to the older PKCS#1 v2.0 [PKCS1v20]. That
version has only one encoding method for signatures
(EMSA-PKCS1-v1_5), and thus there
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 no ambiguity.

Note expected that
this encoding method is different from the encoding method
used in IKEv1. If future revisions of IKEv2 provide support for
other encoding methods (such as EMSA-PSS), they issue will be given new
Auth Method numbers.

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

2.5 Identification type for EAP

(Preliminary text, still open.)

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 fixed during the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI] and [NAIbis]. Although NAIs look a bit like
email addresses (e.g., "joe@example.com"), "Authors' 48 hours" before the syntax
RFC is not exactly published.)

5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS

When describing the same as INTERNAL_IP4/IP6_ADDRESS attributes, Section
3.15.1 says that "In a request message, the syntax of email address in [RFC822]. This raises the specified is a
requested address (or zero if no specific address is requested)".
The question of which identification type should be used.

This document recommends here is that does "zero" mean an address "0.0.0.0" or a
zero length string?

Earlier, the same section also says that ID_RFC822_ADDR identification type "If an attribute in the
CFG_REQUEST Configuration Payload is
used not zero length it is taken as a
suggestion for those NAIs that include attribute". Also, the realm component. Therefore,
responder implementations should not attempt to verify table of configuration
attributes shows that the
contents actually conform to the exact syntax given in [RFC822] length of INTERNAL_IP4_ADDRESS is either "0
or
[RFC2822], but instead should accept any reasonable looking NAI.

For NAIs that do not include the realm component, this document
recommends using the ID_KEY_ID identification type.

(References: "need your help on this IKEv2/i18n/EAP issue" 4 octets", and "IKEv2
identifier issue with EAP" threads, Aug 2004.) likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
octets".

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 6] 17]

Internet-Draft IKEv2 Clarifications February March 2005

2.6 Identity for policy lookups when using EAP

(Preliminary text, better explanation needed.)

When

Thus, if the initiator authentication uses EAP, client does not request a specific address, 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 includes
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 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 AAA server to attribute as
"INTERNAL_ADDRESS(0.0.0.0)".

However, since the
IKEv2 responder.

(References: Pasi Eronen's mail "RE: Reauthentication value is only a suggestion, implementations are
recommended to ignore suggestions they do not accept; or in IKEv2",
2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748,
Section 7.3.)

2.7 EAP authentication and other
words, treat the AUTH payload

Section 2.16 says that "For EAP methods that create same way a shared key zero-length INTERNAL_IP4_ADDRESS,
"0.0.0.0", and any other addresses the implementation does not
recognize as a
side effect of authentication, reasonable suggestion.

5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
sub-networks that shared key MUST be used by both this edge-device protects. This attribute is made
up of two fields; the initiator first being an IP address and the second being
a netmask. Multiple sub-networks MAY be requested. The responder to generate AUTH payloads
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 messages 5
and 6 using the syntax for shared secrets specified TSr payload, what functionality does this attribute
add? And second, what does this attribute mean in section 2.15."

This text should say "messages 7 and 8".

(References: "How CFG_REQUESTs?

For the first question, there seem to do authentication with EAP" thread, Feb 2005)

2.8 Certificate encoding types

(Preliminary text, still open.)

Section 3.6 defines a total of twelve different certificate encoding
types, and continues be two sensible
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
response) indicates which subnets are accessible through the SA that "Specific syntax is for some
was just created.

The first interpretation of the
certificate type codes above INTERNAL_IP4/6_SUBNET attributes is not defined in
that they indicate additional subnets that can be reached through
this document."
However, gateway, but need a separate SA. According to this
interpretation, the text does INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses not provide references to other documents included in TSr.

The second interpretation is that
would contain information the INTERNAL_IP4/6_SUBNET
attributes express the gateway's policy about what traffic should be
sent through the exact contents and use of those
values.

Without this information, it is gateway. The client can choose whether other
traffic (covered by TSr, but not possible in INTERNAL_IP4/6_SUBNET) is sent
through the gateway or directly the destination. According to develop interoperable
implementations. Therefore, this document recommends
interpretation, the attributes are useful mainly when TSr contains
addresses not included in the INTERNAL_IP4/6_SUBNET attributes.

These two interpretations are not totally incompatible: in both
cases, they suggest that traffic to the
following certificate encoding values addresses listed in the
INTERNAL_IP4/6_SUBNET attributes should not be used before new
specifications that specify their use are available. sent via this gateway
(and, of course, the packets have to be sent over some SA whose

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 7]

Internet-Draft IKEv2 Clarifications February 2005

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

Internet-Draft IKEv2 Clarifications March 2005

traffic selectors cover the address in question).

A couple of X.509 certificate" (12), examples are given below. For instance, if there are two
subnets, 192.0.1.0/26 and "Hash 192.0.2.0/24, and URL of X.509 bundle"
(13).

2.9 Hash-and-URL certificate encoding

To be written.

2.10 Rekeying CHILD_SAs

(Preliminary text, still open.)

Section 2.8 describes that rekeying a CHILD_SA within an existing
IKE_SA is done by first creating 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)
TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)

Then a new equivalent SA, valid response could be the following (in which TSr and then
deleting
INTERNAL_IP4_SUBNET contain the old one. However, this section 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-65536, 192.0.1.234-192.0.1.234)
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 describe
exactly what payloads are involved, and really carry any
useful information. Another possible reply would have been this:

This would mean that the client can send all its traffic through the
gateway, but the gateway does not even mention mind if the
REKEY_SA notify payload. Another description about rekeying can client sends traffic
not included by INTERNAL_IP4_SUBNET directly to the destination
(without going through the gateway).

A different situation arises if the gateway has a policy that
requires the traffic for the two subnets to be
found carried in Section 1.3, but separate
SAs. Then a response like this section also omits some of would indicate to the details client that are in Section 2.8. if
it wants access to the second subnet, it needs to create a separate
SA:

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

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 8] 19]

Internet-Draft IKEv2 Clarifications February March 2005

A typical conversation that rekeys an existing CHILD_SA pair and then
deletes the old SAs would look like this:

Initiator Responder
----------- -----------

[traffic flowing via CHILD_SA pair with SPIi1/SPIr1]

HDR, SK {N(REKEY_SA, SPIi1),
SA(..., SPIi2, ...),
Ni, [KEi], TSi, TSr} -->

<-- HDR, SK {SA(..., SPIr2, ...),
Nr, [KEr], TSi, TSr}

HDR, SK {D(SPIi1)} -->

<-- HDR, SK {D(SPIr1)}

[traffic flowing via new CHILD_SA pair with SPIi2/SPIr2]

However, it seems that exactly

TSr = (0, 0-65536, 192.0.1.0-192.0.1.63)

INTERNAL_IP4_SUBNET can also be useful if the same (or almost client's TSr included
only part of the same) end
result would have been achieved address space. For instance, if the REKEY_SA notify payload was
not included. Not including REKEY_SA here client requests
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 the gateway's reply could be this:

It is allowed less clear what the attributes mean in IKEv2; CFG_REQUESTs, and
whether other lengths than zero make sense in this situation (but for
INTERNAL_IP6_SUBNET, zero length is not allowed at all!). Currently
this document recommends that implementations should not include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
CFG_REQUESTs.

For the IPv4 case, it is 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 called rekeying, but creating be a parallel SA with
identical traffic selectors, and coincidentally, deleting one valid netmask for
INTERNAL_IP4_SUBNET.

(References: Tero Kivinen's mail "Intent of them
very soon after that. Why, then, was the REKEY_SA notify payload
included 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.)

5.4 INTERNAL_IP4_NETMASK

Section 3.15.1 defines the spec?

This document's interpretation is that by including REKEY_SA, the
initiator promises INTERNAL_IP4_NETMASK attribute, and says
that (1) it will move its outbound traffic to the
new SA as soon as it receives the CREATE_CHILD_SA response, (2) it
will not use "The internal network's netmask. Only one netmask is allowed in
the old outbound SA after that, request and reply messages (e.g., 255.255.255.0) and (3) it will delete
the old SA pair soon afterwards.

If this interpretation is correct (which is not clear yet), there
seems to MUST be three main differences between the cases
used only with and without
REKEY_SA. First, if REKEY_SA an INTERNAL_IP4_ADDRESS attribute".

However, it is included, the responder can do
certain optimizations that would not be possible without it. Second,
the exact point when the responder moves the outbound traffic to clear what exactly this attribute means, as the
new SA may be different. Third, there may be some differences if
rekeying
concept of "netmask" is started simultaneously by both parties.

Let's consider the optimization case first. It seems that when doing
rekeying, a simple responder implementation could, in fact, replace
the old SAs "in place". This not very well defined for point-to-point
links (unlike multi-access links, where it means "you can result in some packets being lost,
so Section 2.8 recommends against this. reach hosts

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 9] 20]

Internet-Draft IKEv2 Clarifications February March 2005

Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA, SPIi1),
SA(..., SPIi2, ...),
Ni, [KEi], TSi, TSr} -->

[responder replaces the old SAs
with new ones, but remembers
the values SPIi1/SPIr1]

<-- HDR, SK {SA(..., SPIr2, ...),
Nr, [KEr], TSi, TSr}

HDR, SK {D(SPIi1)} -->

[the old SA is already gone,
but

inside this netmask directly using layer 2, instead of sending
packets via a router").

One possible interpretation would be that the responder still
remembers SPIi1/SPIr1]

<-- HDR, SK {D(SPIr1)}

[now responder can forget
SPIi1 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 SPIr1]

The second difference seems to be when exactly the responder should
move IPCP "subnet mask"
extension does in PPP [IPCPSubnet]. This interpretation would also
work nicely with IPv6 (see the traffic to following section).

However, one IKEv2 guru assured the new SA. When REKEY_SA authors that this interpretation
is used, not correct. Section 2.8 3.15.1 also says that the responder should continue multiple addresses are
assigned using multiple INTERNAL_IP4_ADDRESS attributes.

Currently, this document's interpretation is the old SA until it
either receives following:

o INTERNAL_IP4_NETMASK in a packet on CFG_REPLY means exactly the new inbound SA, or receives a Delete
request same thing
as INTERNAL_IP4_SUBNET containing the same information (see the
previous section for description of INTERNAL_IP4_SUBNET).

o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the old SA pair. When REKEY_SA
example in Section 2.19 is not used, incorrect in this sense. (Another
interpretation would be that by sending, for instance, the traffic
combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and
INTERNAL_IP4_NETMASK(255.255.255.0), the client is obviously moved when asking to be
assigned one IP address from the old SA network 192.0.2.0/24. However,
this interpretation is deleted, but not necessarily
earlier.

The third difference may be what exactly happens when both parties
start rekeying at supported by the same time, IKEv2 spec.)

This interpretation is not yet settled; and it would imply that the requests cross
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 this address, the gateway will decrypt it
and send copies to all other VPN clients in the
network. Here REKEY_SA indicates that neither party wants address range.
However, no implementation is known to keep
parallel CHILD_SAs around. (TO BE WRITTEN: details of exactly what
happens do this, and there is nothing
in the IKEv2 spec that would support this case.)

Yet another interpretation is interpretation.

Fortunately, Section 4 clearly says that an IPsec a minimal implementation that
does not work strictly on per-packet basis, but instead associates SAs
with transport layer sockets, could use this information need to update
the socket instead of searching include or understand the SADB/SPD for a suitable SA. (TO
BE WRITTEN: details, INTERNAL_IP4_NETMASK
attribute, and whether thus this makes sense.) document recommends that implementations
should not use the 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.)

Eronen Expires August 18, 2005 [Page 10]

Internet-Draft IKEv2 Clarifications February 2005

2.11 Rekeying the IKE_SA vs. reauthentication

While rekeying the IKE_SA may be important in some environments,
reauthentication, i.e., verifying that the parties still have access
to the long-term credentials, is often more important.

This means that reauthentication Guidelines", 2005-02-07.)

Eronen & Hoffman Expires September 25, 2005 [Page 21]

Internet-Draft IKEv2 Clarifications March 2005

5.5 Configuration payloads for IPv6

IKEv2 also establishes new keys defines configuration payloads for IPv6. However, they
are based on the
IKE_SA corresponding IPv4 payloads, and CHILD_SAs. Therefore, while rekeying can be performed
more often than reauthentication, the situation where "authentication
lifetime" is shorter than "key lifetime" does do not make sense.

While creation fully follow
the "normal IPv6 way of a new IKE_SA doing things".

A client can be initiated by either party
(initiator assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS configuration payload. Presumably, the idea was
that a minimal 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 responder router
advertisement messages are not used; neither is neighbor discovery.

While this approach is reasonably simple, it has some limitations:
IPsec tunnels configured using IKEv2 are not fully-featured
"interfaces" in the original IKE_SA), IPv6 addressing architecture [IPv6Addr] sense.
In particular, they do not necessarily have link-local addresses, and
this may complicate the use of EAP
authentication and/or configuration payloads means in practice protocols that
reauthentication has to be initiated by the same party assume them, such as the
original IKE_SA. IKEv2 does not currently allow the responder to
request reauthentication
[MLDv2]. (Whether they are called "interfaces" in this case; however, there some particular
operating system is ongoing work
to add this functionality [ReAuth]. a different issue.)

(References: "Reauthentication in IKEv2" "VPN remote host configuration IPv6 ?" thread, Oct/Nov May
2004.)

2.12 Rekeying the IKE_SA

To be written.

3. Configuration payloads

3.1 Length of configuration attribute type field

In Section 3.15.1, Figure 23 shows that the

5.6 INTERNAL_IP6_ADDRESS prefix length

Earlier versions of the "Attribute
Type" IKEv2 draft had an INTERNAL_IP6_NETMASK
attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted
when the prefix length field is 15 bits, while the text below the figure says was added to the
length INTERNAL_IP6_ADDRESS
attribute. Thus, it seems logical to assume that their purpose would
be similar; however, this is 7 bits. far from obvious.

The figure draft quite clearly says that the client is correct, assigned an IPv6
address using the field INTERNAL_IP6_ADDRESS attribute. However, as with
the netmask in IPv4, it is 15 bits. not clear what the prefix length here
means.

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 11] 22]

Internet-Draft IKEv2 Clarifications February March 2005

(References: Tero Kivinen's mail "Comments to

Again, one possible interpretation is that a prefix length smaller
than 128 in a CFG_REPLY means that the
draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will
ikev2-16 client is assigned a whole
block of IPv6 addresses. This would be in line with the charm?", 2004-09-23. Charlie Kaufman's
mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It is expected that IPv6
addressing architecture in general, and with, e.g., the
Framed-IPv6-Prefix attribute in [RADIUS6]. However, the previous
section rejected this issue will be fixed during interpretation for IPv4, so it would seem
strange to adopt it only for IPv6.

Thus, if we assume that INTERNAL_IP4_NETMASK and the "Authors' 48 hours" before prefix length in
INTERNAL_IP6_ADDRESS have the
RFC same meaning, and the reasoning in the
previous section is published.)

3.2 Requesting any INTERNAL_IP4/IP6_ADDRESS

When describing correct, then a CFG_REPLY containing a prefix
length smaller than 128 has the INTERNAL_IP4/IP6_ADDRESS attributes, 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 "In "With IPv6, a request message, requestor MAY supply the low
order address specified is a
requested address (or zero bytes it wants to use": presumably the prefix length
tells how many low order bits there are (i.e., if no specific address is requested)".
The question here the prefix length
is that does "zero" mean an X, there requester supplies 128-X low order address "0.0.0.0" or bits).
However, this is quite confusing: if, say, a
zero prefix length string?

Earlier, the same section also says 126 means
that "If an attribute in the
CFG_REQUEST Configuration Payload is not zero "I want to use these 128-126=2 low order bits", why does prefix
length it 128 mean that "I want to use these 128 low order bits"?

Another interpretation is taken as a
suggestion for that attribute". Also, the table instead of configuration
attributes shows that "low order", the length of INTERNAL_IP4_ADDRESS is either "0
or 4 octets", draft
should have said "high order", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
octets".

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

However, since the value is only a suggestion, implementations are
recommended prefix length smaller than
128 means "I'd like to ignore suggestions they do not accept; or in other
words, treat the same way a zero-length INTERNAL_IP4_ADDRESS,
"0.0.0.0", and any other addresses the implementation does get an address from this subnet".

Given this very confusing discussion, this document recommends that
implementations should not
recognize as a reasonable suggestion.

3.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

(Preliminary text, still open.) use other INTERNAL_IP6_ADDRESS prefix
lengths than 128.

5.7 INTERNAL_IP6_NBNS

Section 3.15.1 describes defines the INTERNAL_IP4_SUBNET as "The protected
sub-networks that this edge-device protects. This INTERNAL_IP6_NBNS attribute is made
up of two fields; for sending
the first being an IP IPv6 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 of NetBIOS name servers.

However, NetBIOS is not defined in a similar manner.

This raises two questions: first, since this information is usually
included in the TSr payload, what functionality does for IPv6, and probably never will be.
Thus, this attribute
add? And second, what most likely does this attribute mean not make much sense.

(Pointed out by Bernard Aboba in CFG_REQUESTs? the IP Configuration Security (ICOS)
BoF at IETF62.)

6. Miscellaneous issues

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 12] 23]

Internet-Draft IKEv2 Clarifications February March 2005

For the

6.1 Diffie-Hellman for first question, there seem to be two sensible
interpretations. Clearly TSr (in CHILD_SA

Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or CREATE_CHILD_SA
response) indicates which subnets are accessible through
Ni/Nr payloads. This implies that the SA that
was just created. payload in IKE_AUTH
exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
any other value than NONE.

6.2 Extended Sequence Numbers (ESN) transform

The first interpretation description of the INTERNAL_IP4/6_SUBNET attributes is
that they indicate additional subnets that can ESN transform in Section 3.3 has be reached through
this gateway, but need a separate SA. According proved
difficult to this
interpretation, understand. When the INTERNAL_IP4/6_SUBNET attributes are useful
mainly when they contain addresses ESN transform is included, it has
the following meaning:

o A proposal containing one ESN transform with value 0 means "do not included in TSr.

The second interpretation
use extended sequence numbers".

o A proposal containing one ESN transform with value 1 means "use
extended sequence numbers".

o A proposal containing two ESN transforms with values 0 and 1 means
"I support both normal and extended sequence numbers, you choose".
(Obviously this case is that only allowed in requests; the INTERNAL_IP4/6_SUBNET
attributes express response
will contain only one ESN transform.)

In most cases, the gateway's policy about what traffic should be
sent through exchange initiator will include either the gateway. The client can choose whether other
traffic (covered by TSr, but not first
or third alternative in INTERNAL_IP4/6_SUBNET) its SA payload. The second alternative is sent
through the gateway or directly the destination. According to this
interpretation, the attributes are
rarely useful mainly when TSr contains
addresses for the initiator: it means that using normal sequence
numbers is not included in acceptable (so if the INTERNAL_IP4/6_SUBNET attributes.

These two interpretations are responder does not totally incompatible: in both
cases, they suggest that traffic to support ESNs,
the addresses listed exchange will fail with NO_PROPOSAL_CHOSEN).

Section 3.3.2 also says that "If Transform Type 5 is not included in the
INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway
(and,
a proposal, use of course, Extended Sequence Numbers is assumed". Or in
other words, omitting the packets have to be sent over some SA whose
traffic selectors cover ESN transform means the address in question).

A couple same thing as
including one ESN transform with value 1.

This choice of examples are given below. For instance, if there are two
subnets, 192.0.1.0/26 and 192.0.2.0/24, default value is somewhat counterintuitive and as
described above, rarely useful. There is ongoing discussion about
making including 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)
TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)

Then a valid response could be the following (in which TSr ESN transform mandatory, thus removing this
illogical default value.

(References: "Technical change needed to IKEv2 before publication"
and
INTERNAL_IP4_SUBNET contain "STRAW POLL: Dealing with the same information):

In these cases, ESN negotiation interop issuein
IKEv2" threads, March 2005.)

6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR

When using the INTERNAL_IP4_SUBNET ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not really carry any
useful information. Another possible reply would have been this: require this address to match the address in

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 13] 24]

Internet-Draft IKEv2 Clarifications February March 2005

This would mean that

the client can send all its traffic through IP header (of IKEv2 packets), or anything in the
gateway, TSi/TSr
payloads. The contents of IDi/IDr is used purely to fetch the policy
and authentication data related to the other party.

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

6.4 Relationship of IKEv2 to RFC2401bis

The IKEv2 document refers to [RFC2401bis], but it never makes clear
what the gateway does not mind if exact relationship is. That is probably because there is no
exact relationship. However, the client sends traffic
not included IKEv2 document could state this
explicitly.

IKEv2 can be used with either [RFC2401] or [RFC2401bis], except in
places that are only covered by INTERNAL_IP4_SUBNET directly [RFC2401bis]. The areas specific to
[RFC2401bis] are ECN (Section 2.24), fragmentation control (Section
3.10), and the destination
(without going through the gateway).

A different situation arises if use of opaque ports in traffic selectors (Section
3.13.1). IKEv2 allows the gateway has creation of a policy single SA that
requires has multiple
protocols when being used with [RFC2401]; this is not allowed in
[RFC2401bis].

6.5 Reducing the traffic for window size

In IKEv2, the two subnets window size is assumed to be carried in separate
SAs. Then a response like this would indicate (possibly configurable)
property of a particular implementation, and is not related to
congestion control (unlike the client that if
it wants access window size in TCP, for instance).

In particular, there is no way to reduce the window size of an
existing IKE_SA. However, when rekeying an IKE_SA, the second subnet, new IKE_SA
starts with window size 1 until it needs to create is explicitly increased by sending
a separate
SA:

INTERNAL_IP4_SUBNET can also new SET_WINDOW_SIZE notification.

6.6 Minimum size of nonces

Section 2.10 says that "Nonces used in IKEv2 MUST be useful if randomly chosen,
MUST be at least 128 bits in size, and MUST be at least half the client's TSr included
only part key
size of the address space. For instance, if negotiated prf."

However, the client requests initiator chooses 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 nonce before the gateway's reply could be this:

It is less clear what outcome of the attributes mean in CFG_REQUESTs, and
whether other lengths than zero make sense in
negotiation is known. In this situation (but case, the nonce has to be long enough
for
INTERNAL_IP6_SUBNET, all the PRFs being proposed.

6.7 Initial zero length octets on port 4500

It is not allowed at all!). Currently
this document recommends that implementations clear whether a peer sending an IKE_SA_INIT request on port
4500 should not include
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in the initial four zero octets. Section 2.23 talks
about how to upgrade to tunneling over port 4500 after message 2, but

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 14] 25]

Internet-Draft IKEv2 Clarifications February March 2005

CFG_REQUESTs.

For the IPv4 case, this document recommends using only netmasks
consisting of some amount of "1" bits followed by "0" bits; for
instance, "255.0.255.0" would

it does 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 say what to do if message 1 is sent on port 4500.

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

[...]

The IKE initiator MUST check these payloads if present and INTERNAL_IP6_SUBNET if
they do not match the addresses in
IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
Clarifications and Implementation Guidelines", 2005-02-07.)

3.4 INTERNAL_IP4_NETMASK

(Preliminary text, still open.)

Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, outer packet MUST tunnel
all future IKE and says
that "The internal network's netmask. Only one netmask is allowed in ESP packets associated with this IKE_SA over
UDP port 4500.

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

The very beginning of Section 2 says "... though IKE messages (e.g., 255.255.255.0) and it MUST may
also be
used only received on UDP port 4500 with an INTERNAL_IP4_ADDRESS attribute".

However, it a slightly different format
(see section 2.23)."

That "slightly different format" is not clear only described in discussing what exactly this attribute means, as
to do after changing to port 4500. However, [RFC3948] shows clearly
the
concept format has the initial zeros even for initiators on port 4500.
Furthermore, without the initial zeros, the processing engine cannot
determine whether the packet is an IKE packet or an ESP packet.

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

6.8 SPI values in IKE_SA_INIT exchange

Normal IKE messages include the initiator's and responder's SPIs,
both of "netmask" which are non-zero, in the IKE header. However, there are
some corner cases where the IKEv2 specification 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").

One possible interpretation would fully
consistent about what values should be used.

First, Section 3.1 says that the host Responder's SPI "...MUST NOT be zero
in any other message" (than the first message of the IKE_SA_INIT
exchange). However, the figure in Section 2.6 shows the second
IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
in 3.1.

Since the responder's SPI identifies security-related state held by
the responder, and in this case no state is given a whole
block of IP addresses instead of created, sending a single address. This is also what
Framed-IP-Netmask does zero
value seems reasonable.

Second, in [RADIUS] and addition to cookies, there are several other cases when
the IPCP "subnet mask"
extension IKE_SA_INIT exchange does not result in PPP [IPCPSubnet]. This interpretation would also
work nicely with IPv6 (see the following section).

However, one creation of an IKE_SA
(for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What

Eronen & Hoffman Expires September 25, 2005 [Page 26]

Internet-Draft IKEv2 guru assured Clarifications March 2005

responder SPI value should be used in the author that this interpretation
is not correct. Section 3.15.1 also says that multiple addresses are
assigned using multiple INTERNAL_IP4_ADDRESS attributes.

Currently, IKE_SA_INIT response in
this document's interpretation is case?

Since the following:

o INTERNAL_IP4_NETMASK in IKE_SA_INIT request always has a CFG_REPLY means exactly the same thing
as INTERNAL_IP4_SUBNET containing zero responder SPI, the same information (see
value will not be actually used by the
previous section initiator. Thus, we think
sending a zero value is correct also in this case.

6.9 SPI values for description messages outside of INTERNAL_IP4_SUBNET).

o INTERNAL_IP4_NETMASK an IKE_SA

The IKEv2 specification does not make sense say what SPI values should be used
for CFG_REQUESTs, Informational requests sent outside of an IKE_SA.

There seem to be two cases when such a message can be sent:
INVALID_IKE_SPI and INVALID_SPI notifications. Especially in the
example
latter case, no meaningful IKE SPI values are available.

A strict interpretation of the specification would require the sender
to invent garbage values for the SPI fields. However, we think this
was not the intention, and using zero values is acceptable.

6.10 Protocol ID/SPI fields in Notify payloads

Section 2.19 is incorrect 3.10 says that the Protocol ID field in Notify payloads "For
notifications which do not relate to an existing SA, this sense. (Another
interpretation would field MUST
be sent as zero and MUST be that by sending, for instance, ignored on receipt". However, the
combination of INTERNAL_IP4_ADDRESS(192.0.2.0)
specification does not clearly say which notifications are related to
existing SAs and

Eronen Expires August 18, 2005 [Page 15]

Internet-Draft IKEv2 Clarifications February 2005

INTERNAL_IP4_NETMASK(255.255.255.0), which are not.

Since the client main purpose of the Protocol ID field is asking to be
assigned one IP address from specify the network 192.0.2.0/24. However,
this interpretation is not supported by
type of the IKEv2 spec.)

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

Yet another possible interpretation would Protocol ID field
should be that
INTERNAL_IP4_NETMASK indicates a broadcast address, meaning that if a
client sends a packet to this address, non-zero only when the gateway will decrypt it
and send copies to all other VPN clients in that address range.
However, no implementation SPI field is known to do this, and there non-empty.

There are currently only two notifications where this is nothing
in the IKEv2 spec that would support this interpretation.

Fortunately, case:
INVALID_SELECTORS and REKEY_SA.

6.11 INVALID_IKE_SPI

Section 4 clearly 3.10.1 says that a minimal implementation the INVALID_IKE_SPI notification "indicates
an IKE message was received with an unrecognized destination SPI.
This usually indicates that the recipient has rebooted and forgotten
the existence of an IKE_SA."

The text does not need to include or understand say whether the INTERNAL_IP4_NETMASK
attribute, and thus this document recommends that implementations SPI value should not use be included in the INTERNAL_IP4_NETMASK attribute at all.

(References: Charlie Kaufman's mail "RE: Proposed Last Call based
revisions
notification. However, it is clear that the notification will be
useful to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
Jan 2005. Yoav Nir's mail "Re: New I-D: 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) should be

Eronen & Hoffman Expires September 25, 2005 [Page 27]

Internet-Draft IKEv2 Clarifications March 2005

included, and
Implementation Guidelines", 2005-02-07.)

3.5 INTERNAL_IP6_ADDRESS prefix length

(Preliminary text, still open.)

Earlier versions of how it (or they) should be sent. For the IKEv2 draft had an INTERNAL_IP6_NETMASK
attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted
when first
question, the prefix length field was added to alternatives are the INTERNAL_IP6_ADDRESS
attribute. Thus, it seems logical to assume that their purpose unrecognized destination SPI, the
source SPI (which presumably would be similar; however, this more useful for 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 of another related notification, INVALID_SPI, the
situation is far from obvious.

But first clearer: there is only a step back: single SPI, and the draft quite clearly text
explicitly says that the client SPI is assigned sent as Notification Data (since the
notification is not about an IPv6 address using existing SA, the INTERNAL_IP6_ADDRESS attribute;
so using this attribute with prefix length 128 SPI field in a CFG_REPLY seems
to be clear. Also, this implies that IPv6 stateless
autoconfiguration the Notify
payload is not involved (and indeed, that would used; and obviously the value cannot be quite
difficult to align with TSi/TSr payloads).

Again, one possible interpretation is that a prefix length smaller
than 128 placed in a CFG_REPLY means that the client
IKE header).

Since the INVALID_IKE_SPI notification is assigned a whole
block sent outside of IPv6 addresses. This would be in line with the IPv6
addressing architecture in general, an IKE_SA,
and with, e.g., the
Framed-IPv6-Prefix attribute in [RADIUS6]. However, the previous
section rejected this interpretation for IPv4, so it would seem
strange to adopt is not about an existing SA, it only for IPv6.

Eronen Expires August 18, 2005 [Page 16]

Internet-Draft IKEv2 Clarifications February 2005

Thus, if we assume seems that INTERNAL_IP4_NETMASK using Notification
Data would be the logical choice. However, this issue needs more
discussion and we do not yet propose any solution in this document.

6.12 Which message should contain INITIAL_CONTACT

The description of the prefix length INITIAL_CONTACT notification in
INTERNAL_IP6_ADDRESS have Section 3.10.1
says that "This notification asserts that this IKE_SA is the same meaning, and only
IKE_SA currently active between the reasoning 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
previous section is correct, then a CFG_REPLY containing a prefix
length smaller than 128 has
notification cannot be sent before both endpoints have been
authenticated. Thus, the same purpose as INTERNAL_IP6_SUBNET.

However, CFG_REQUESTs possible places are more complicated. It seems that a
CFG_REQUEST the last IKE_AUTH
response message that requests and a specific IPv6 address (usually an
address separate Informational exchange.

Based on how this client was using earlier) should have prefix length 128.
But what do other prefix lengths mean implemented in CFG_REQUESTs?

Section 3.15.1 says that "With IPv6, a requestor MAY supply the low
order address bytes IKEv1, it wants seems the intent was
to use": presumably use a separate Informational exchange.

7. Status of the prefix length
tells how many low order bits there clarifications

This document is work-in-progress, and it contains both relatively
stable and finished parts, and other parts that are (i.e., if incomplete or
even incorrect. To help the prefix length
is X, there requester supplies 128-X low order address bits).
However, reader in deciding how much weight
should be given to each clarification, this is quite confusing: if, say, a prefix length 126 means
that "I want section contains our
opinions about which parts we believe to use these 128-126=2 low order bits", why does prefix
length 128 mean that "I want 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 use these 128 low order bits"?

Another be incomplete and/or there is disagreement about what the
correct interpretation is that instead of "low order", are marked with one asterisk (*). The

Eronen & Hoffman Expires September 25, 2005 [Page 28]

Internet-Draft IKEv2 Clarifications March 2005

clarifications marked with two asterisks (**) are somewhere between
the draft
should have said "high order", extremes.

2. Authentication
2.1 Data included in AUTH payload calculation ***
2.2 Hash function for RSA signatures ***
2.3 Encoding method for RSA signatures ***
2.4 Identification type for EAP ***
2.5 Identity for policy lookups when using EAP ***
2.6 EAP authentication and thus a prefix length smaller than
128 means "I'd like the AUTH payload ***
2.7 Certificate encoding types ***
2.8 Shared key authentication and fixed PRF key size **
2.9 EAP authentication and fixed PRF key size *
3. Keying and rekeying
3.1 Semantics of the CREATE_CHILD_SA exchange *
3.2 Rekeying the IKE_SA vs. reauthentication **
3.3 SPIs when rekeying the IKE_SA ***
3.4 Which SPI to get 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. in REKEY_SA ***
3.5 Deleting SAs **
4. Other issues Traffic selectors
4.1 Message ID in IKE_SA_INIT messages

To be written.

(References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
combination" thread, Oct 2004.) Semantics of complex traffic selector payloads ***
4.2 INITIAL_CONTACT notify payload

To be written.

(References: Michael Richardson's mail "Initial Contact Messages",
2004-12-05. Paul Hoffman's reply, 2004-12-05. Tero Kivinen's reply,
2004-12-07. "Replicated identities" thread ICMP type/code in Jan 2005.) traffic selector payloads ***
4.3 Mobility header in traffic selector payloads ***
4.4 Narrowing the traffic selectors ***
4.5 SINGLE_PAIR_REQUIRED **
4.6 Traffic selectors violating own policy *
5. Configuration payloads
5.1 Length of configuration attribute type field ***
5.2 Requesting any INTERNAL_IP4/IP6_ADDRESS ***
5.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET **
5.4 INTERNAL_IP4_NETMASK **
5.5 Configuration payloads for IPv6 *
5.6 INTERNAL_IP6_ADDRESS prefix length *
5.7 INTERNAL_IP6_NBNS ***
6. Miscellaneous issues
6.1 Diffie-Hellman for first CHILD_SA

(Preliminary text, references missing.)

Section 1.2 shows that IKE_AUTH ***
6.2 Extended Sequence Numbers (ESN) transform **
6.3 Matching ID_IPV4_ADDR and ID_IPV6_ADDR ***
6.4 Relationship of IKEv2 to RFC2401bis **
6.5 Reducing the window size **
6.6 Minimum size of nonces ***
6.7 Initial zero octets on port 4500 ***
6.8 SPI values in IKE_SA_INIT exchange **
6.9 SPI values for messages do not outside of an IKE_SA *
6.10 Protocol ID/SPI fields in Notify payloads **
6.11 INVALID_IKE_SPI *
6.12 Which message should contain KEi/KEr or INITIAL_CONTACT **

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 17] 29]

Internet-Draft IKEv2 Clarifications February March 2005

Ni/Nr payloads. This implies that the SA payload in IKE_AUTH
exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
any other value than NONE.

4.4 Matching ID_IPV4_ADDR/ID_IPV6_ADDR

When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require

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

8. Implementation mistakes

Some implementers at the IP header (of first IKEv2 packets), or anything in the TSi/TSr
payloads. The contents of IDi/IDr bakeoff didn't do everything
correctly. This may seem like an obvious statement, but it is used purely to fetch the policy
and authentication data related
probably useful to the other party.

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

4.5 Semantics of traffic selector payloads

As described list a few things that were clear in Section 3.13, the TSi/TSr payloads can include one or
more individual traffic selectors.

There is no requirement that TSi document
and TSr contain the same number not needing clarification, that some implementors didn't do. All
of
individual these things caused interoperability problems.

o Some implementations continued to send traffic selectors. Thus, they are interpreted as follows:
a packet matches on a given TSi/TSr if CHILD_SA after
it matches at least one of 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
individual selectors in TSi, and counter to 2, another did
not reset the counter at least one all.

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

For instance, the following proposal.

9. Open issues

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

o In the 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 selector discussion, we need to anywhere, come up with any of better
wording for the
four combinations of source/destination ports (100,300), (100,400),
(200,300), and (200, 400).

This implies "sender's inbound" SAs. Is that some types traffic that is
being sent to the sender, or traffic being sent from the sender?

o Many of policies 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 There may require several CHILD_SA
pairs. For instance, need to be more text about deleting an old SA after
rekeying is finished.

o The text about sending a policy matching DELETE for only source/destination ports
(100,300) one direction of an SA
(and the responder sending the DELETE for the other direction of
the SA in its response) doesn't explain the logic, and (200,400), but doesn't say
why you should not send DELETEs for both directions of the other two combinations, cannot
be negotiated as SA. We
need to add a single CHILD_SA pair using IKEv2.

(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.6 Traffic selector negotiation

(Preliminary text, more text needed.) description of the race condition if one side
deletes both SAs at once.

o When the document uses the term "original initiator" (or similar
terms), it is not clear whether or not that term also applies to

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 18] 30]

Internet-Draft IKEv2 Clarifications February March 2005

Section 2.9 describes traffic selector negotiation in great detail.

One aspect of this negotiation

the side that may need some clarification originates an rekeying of the IKE_SA. That is, if
Alice starts the first IKE_SA, but then Bob rekeys the IKE_SA, is
that when creating a new SA,
the initiator should not propose traffic
selectors "original initiator" from that violate its own policy. If this rule point on now Bob, or is not followed,
valid traffic may be dropped.

This it
still Alice? Also, if it is best illustrated by an example. Suppose that host A has Bob, at what exact point does it
become Bob? This needs to be cleared up on a
policy whose effect is that traffic case-by-case basis
throughout the document.

o It would be very useful to 192.0.1.66 is sent via host B
encrypted using AES, have actual examples of certificate
type 12 (hash and traffic to all other hosts in 192.0.1.0/24
is also sent via B, but must use 3DES. Suppose also that host B
accepts any combination URL of AES X.509 certificates) and 3DES.

If host A now proposes an SA that uses 3DES, type 13 (hash and includes TSr
containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
B. Now, host B can also use this SA to send traffic from 192.0.1.66,
but those packets will be dropped by A since it requires the use
URL of
AES for those traffic. Even X.509 bundle).

o The message IDs of IKE_SA_INIT messages is unclear if host A creates a new SA only for
192.0.1.66 that uses AES, host B may freely continue to use the first
SA for the traffic. In this situation, when proposing the SA, host A
should have there are
cookies followed its own policy, and included a TSr containing
((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

(References: by INVALID_KE_PAYLOAD. See "Question about "narrowing" ..."
N(COOKIE) and N(INVALID_KE_PAYLOAD) combination" thread, Feb 2005.
"IKEv2 Oct 2004.
This definitely needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
negotiation examples", 2004-08-08.)

4.7 Coexistence of multiple IPsec implementations

To to be written.

Eronen Expires August 18, 2005 [Page 19]

Internet-Draft IKEv2 Clarifications February 2005

5. clarified.

o There is some confusion on when to emit and process
INITIAL_CONTACT payloads. References: Michael Richardson's mail
"Initial Contact Messages", 2004-12-05. Paul Hoffman's reply,
2004-12-05. Tero Kivinen's reply, 2004-12-07. "Replicated
identities" thread in Jan 2005.) It is not clear if there is an
interoperability issue because reacting to INITIAL_CONTACT is
optional, but this should be cleared up.

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

This document has no IANA Actions.

7. does not change or create any IANA-registered values.

12. Acknowledgments

This document is mainly based on conversations on the IPsec WG
mailing list. The author authors would especially like to thank Bernard
Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Paul Hoffman, Mika
Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, and Michael
Richardson 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.

Eronen & Hoffman Expires September 25, 2005 [Page 31]

Internet-Draft IKEv2 Clarifications March 2005

13. References

8.1

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

8.2

[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-05 (work
in progress), December 2004.

13.2 Informative References

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

Eronen Expires August 18, 2005 [Page 20]

Internet-Draft IKEv2 Clarifications February 2005

[EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-04 (work in
progress), November 2004.

[IPCPSubnet]
Cisco Systems, Inc., "IPCP Subnet Mask Support
Enhancements",
http://www.cisco.com/univercd/cc/td/doc/product/software/i
os121/121newft/121limit/121dc/121dc3/ipcp_msk.htm, January
2003.

Eronen & Hoffman Expires September 25, 2005 [Page 32]

Internet-Draft IKEv2 Clarifications March 2005

[IPv6Addr]
Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2004.

[MIPv6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.

[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

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

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

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

[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-01 (work in progress), November
2004.

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

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 21] 33]

Internet-Draft IKEv2 Clarifications February March 2005

Author's Address

draft-ietf-pkix-scvp-16 (work in progress), October 2004.

Authors' Addresses

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

EMail: pasi.eronen@nokia.com

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

EMail: paul.hoffman@vpnc.org

Eronen & Hoffman Expires August 18, September 25, 2005 [Page 22] 34]

Internet-Draft IKEv2 Clarifications February March 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 August 18, September 25, 2005 [Page 23] 35]

----