wdiff draft-ietf-mobike-protocol-02.txt draft-ietf-mobike-protocol-03.txt

MOBIKE Working Group P. Eronen, Ed.
Internet-Draft Nokia
Expires: March 16, April 2, 2006 September 12, 29, 2005

IKEv2 Mobility and Multihoming Protocol (MOBIKE)
draft-ietf-mobike-protocol-02.txt
draft-ietf-mobike-protocol-03.txt

Status of this Memo

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

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

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

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

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

This Internet-Draft will expire on March 16, April 2, 2006.

Abstract

This document describes the MOBIKE protocol, a mobility and
multihoming extension to IKEv2. Internet Key Exchange (IKEv2). MOBIKE
allows hosts to update the (outer) IP addresses associated with IKE IKEv2
and IPsec Security
Associations (SAs). Associations. A mobile VPN client could use
MOBIKE to keep the connection with the VPN gateway active while
moving from one address to another. Similarly, a multihomed host
could use MOBIKE to move the traffic to a different interface if, for
instance, the currently used one stops working.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
1.1 Motivation
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4
3.1 Basic Operation . . . . 3
1.2 MOBIKE Protocol Overview . . . . . . . . . . . . . . . . . 4
1.3 Terminology and Notations
3.2 Example Protocol Runs . . . . . . . . . . . . . . . . . . 5
2.
3.3 MOBIKE and Network Address Translation (NAT) . . . . . . . 8
3.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol Exchanges . . . . . . . . . . . . . . . . . . 6
2.1 . . . 9
4.1 Signaling Support for MOBIKE . . . . . . . . . . . . . . . 6
2.2 9
4.2 Initial Tunnel Header Addresses . . . . . . . . . . . . . 9
4.3 Additional Addresses . . . . . . . . . . . . . . . . . . . 6
2.3 9
4.4 Changing Addresses in IPsec SAs . . . . . . . . . . . . . 7
2.4 11
4.5 Updating Additional Addresses . . . . . . . . . . . . . . 10
2.5 14
4.6 Return Routability Check . . . . . . . . . . . . . . . . . 11
2.6 15
4.7 Changes in NAT Mappings . . . . . . . . . . . . . . . . . 12
2.7 16
4.8 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 12
2.8 16
4.9 Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17
4.10 Failure Recovery and Timeouts . . . . . . . . . . . . . . 14
3. 17
5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 19
5.1 MOBIKE_SUPPORTED Notification Notify Payload . . . . . . . . . . 15
3.2 . . . 19
5.2 ADDITIONAL_IP4/6_ADDRESS Notification Notify Payloads . . . . . . 15
3.3 . . . 19
5.3 NO_ADDITIONAL_ADDRESSES Notification Notify Payload . . . . . . . 15
3.4 . . . 19
5.4 UPDATE_SA_ADDRESSES Notification Notify Payload . . . . . . . . . 15
3.5 . . . 19
5.5 UNACCEPTABLE_ADDRESSES Notification Notify Payload . . . . . . . 16
3.6 . . . 20
5.6 COOKIE2 Notification Notify Payload . . . . . . . . . . . . . . . 16
3.7 . . . 20
5.7 NO_NATS_ALLOWED Notification Notify Payload . . . . . . . . . . . 16
3.8 . . . 20
5.8 UNEXPECTED_NAT_DETECTED Notification Notify Payload . . . . . . . 16
4. . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1 21
6.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 17
4.2 21
6.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 17
4.3 21
6.3 Denial-of-Service Attacks Against Third Parties . . . . . 18
4.4 22
6.4 Spoofing Network Connectivity Indications . . . . . . . . 19
5. 23
6.5 Address and Topology Disclosure . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 25
9.1 Normative References . . . . . . . . . . . . . . . . . . . 20
7.2 25
9.2 Informative References . . . . . . . . . . . . . . . . . . 20 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 27
A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 27
Intellectual Property and Copyright Statements . . . . . . . . 23 30

1. Introduction

1.1 Motivation

IKEv2 is used for performing mutual authentication and establishing
and maintaining IPsec security associations Security Associations (SAs). In the current
specifications, the IPsec and IKE SAs are created implicitly between
the IP addresses that are used when the IKE_SA is established. These
IP addresses are then used as the outer (tunnel header) addresses for
tunnel mode IPsec packets. Currently, it is not possible to change
these addresses after the IKE_SA has been created.

There are scenarios where these IP addresses might change. One
example is mobility: a host changes its point of network attachment,
and receives a new IP address. Another example is a multihoming host
that would like to change to a different interface if, for instance,
the currently used address interface stops working for some reason.

Although the problem can be solved by creating new IKE and IPsec SAs
when the addresses need to be changed, this may not be optimal for
several reasons. In some cases, creating a new IKE_SA may require
user interaction for authentication (entering a code from a token
card, for instance). Creating new SAs often also involves expensive
calculations and possibly a large number of roundtrips. Due to these
reasons, a mechanism for updating the IP addresses of existing IKE
and IPsec SAs is needed. The MOBIKE protocol described in this
document provides such a mechanism.

The main scenario for MOBIKE is making it possible for a remote
access VPN user to move from one address to another without re-
establishing all security associations with the VPN gateway. For
instance, a user could start from fixed Ethernet in the office, and
then disconnect the laptop and move to office wireless LAN. When
leaving the office the laptop could start using GPRS, and switch to a
different wireless LAN when the user arrives home. MOBIKE updates
only the outer (tunnel header) addresses of IPsec SAs, and the
addresses and others traffic selectors used inside the tunnel stay
unchanged. Thus, mobility can be (mostly) invisible to applications
and their connections using the VPN.

MOBIKE also supports more complex scenarios where the VPN gateway
also has several network interfaces: these interfaces could be
connected to different networks or ISPs, they may have may be a mix
of IPv4 and IPv6 addresses, and the addresses may change over time.
Furthermore, both parties could be VPN gateways relaying traffic for
other parties.

Note

2. Terminology and Notation

When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for
instance, "FOO+"). In some cases, the diagrams also show what
payloads defined in [IKEv2] would be typically included in, for
instance, the IKE_AUTH exchange. These payloads are shown for
illustrative purposes only; see [IKEv2] for an authoritative
description.

When this document does not claim to solve all talks about updating the problems IETF
MOBIKE working group has been chartered to work on. It is assumed source/destination
addresses of an IPsec SA, it means updating IPsec-related state so
that issues such as transport mode (updating traffic selectors),
PFKEY extensions, and outgoing ESP/AH packets use those addresses in the tunnel overhead reduction will be handled
header. Depending on how the nominal division between Security
Association Database (SAD), Security Policy Database (SPD), and Peer
Authorization Database (PAD) described in
separate documents.

1.2 MOBIKE Protocol Overview

Since MOBIKE allows both parties to [IPsecArch] is actually
implemented, an implementation can have several addresses, this
leads us to an important question: there are up to N*M pairs of IP
addresses different places that could potentially be used. How
have to decide which of
these pairs should be used? The decision has to take into account
several factors. First, updated.

In this document, the parties have may preferences about which
interface should be used, due to performance and cost reasons, for
instance. Second, term "initiator" means the decision party who originally
initiated the first IKE_SA (in a series of possibly several rekeyed
IKE_SAs); "responder" is constrained by the fact that some other peer. During the lifetime of the pairs
IKE_SA, both parties may not work at all due to initiate INFORMATIONAL or CREATE_CHILD_SA
exchanges; in this case, the terms "exchange initiator" and "exchange
responder" are used. The term "original initiator" (which in [IKEv2]
refers to the party who started the latest IKE_SA rekeying) is not
used in this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].

3. Protocol Overview

3.1 Basic Operation

MOBIKE allows both parties to have several addresses, and there are
up to N*M pairs of IP addresses that could potentially be used. The
decision of which of these pairs to use has to take into account
several factors. First, the parties have may preferences about which
interface should be used, due to performance and cost reasons, for
instance. Second, the decision is constrained by the fact that some
of the pairs may not work at all due to incompatible IP versions,
outages somewhere in the network, problems at the local link at
either end, and so on.

MOBIKE solves this problem by taking a simple approach: the party
that initiated the IKE_SA (the "client" in remote access VPN
scenario) is responsible for deciding which address pair is used for
the IPsec SAs, and collecting the information it needs to make this
decision (such as determining which address pairs work or do not
work). The other party (the "gateway" in remote access VPN scenario)
simply tells the initiator what addresses it has, but does not update
the IPsec SAs until it receives a message from the initiator to do
so.

Making the decision at the initiator is consistent with how normal
IKEv2 works: the initiator decides which addresses it uses when
contacting the responder. It also makes sense especially when the
initiator is the mobile node: it is in a better position to decide
which of its network interfaces should be used for both upstream and
downstream traffic.

The details of exactly how the initiator makes the decision, what
information is used in making it, how the information is collected,
how preferences affect the decision, and when a decision needs to be
changed, are largely beyond the scope of MOBIKE. This does not mean
that these details are unimportant: on the contrary, they are likely
to be crucial in any real system. However, MOBIKE is concerned with
these details only to the extent that they are visible in IKEv2/IPsec
messages exchanged between the peers (and thus need to be
standardized to ensure interoperability). Issues such as mobility
detection and local policies

Many of these issues are also not specific to MOBIKE, but
apply to common with
the use of existing hosts in dynamic environments or with mobility
protocols such as Mobile IPv4 IP [MIP4] as
well.

MOBIKE also has [MIP6]. A number of mechanisms
already exist or are being developed to deal with situations where the network contains
NATs or stateful packet filters (for brevity, these issues. For
instance, link layer and IP layer mechanisms can be used to track the rest
status of this
document talks simply about NATs). When connectivity within the addresses used local link [RFC2461], movement
detection is being specified in for both IPv4 and IPv6 [DNA4] [DNA6],
and so on.

Updating the addresses of IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as
needed. However, if the party "outside" the NAT changes its IP
address, it may no longer be able to send packets to the party
"behind" the NAT, since the packets may not (depending on the exact
type of NAT) match the NAT mapping state. Here MOBIKE assumes that
the initiator is the party "behind" the NAT, and does not fully
support the case where the responder's addresses change when NATs are
present.

Updating the addresses of IPsec SAs naturally has to take into
account several security considerations. naturally has to take into
account several security considerations. MOBIKE includes two
features designed to address these considerations. First, a "return
routability" check can be used to verify the addresses provided by
the peer. This makes it more difficult to flood third parties with
large amounts of traffic. Second, a "NAT prohibition" feature
ensures that IP addresses have not been modified by NATs, IPv4/IPv6
translation agents, or other similar devices. This feature is mainly
intended for site-to-site VPNs where the administrators may know
beforehand that NATs are not present, and thus any modification to
the packet can be considered to be an attack.

1.3 Terminology and Notations

When messages containing IKEv2 payloads are shown, optional payloads
are shown

3.2 Example Protocol Runs

A simple MOBIKE exchange in brackets (for instance, "[FOO]"), a mobile scenario is illustrated below:

Initiator Responder
----------- -----------
1) HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_*_IP) -->

<-- HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP)

2) HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->

<-- HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED) }

(Initiator gets information from lower layers that its attachment
point and address has changed.)

3) HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP) } -->

<-- HDR, SK { N(NAT_DETECTION_*_IP) }

(Responder verifies that the initiator has given it
a plus sign
indicates correct IP address.)

4) <-- HDR, SK { N(COOKIE2) }

HDR, SK { N(COOKIE2) } -->

Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform
each other that they support MOBIKE. In step 3, the initiator
notices a payload can be repeated one or more times (for
instance, "FOO+").

When this document talks about updating change in its own address, and informs the source/destination
addresses of an IPsec SA, responder about
this. At this point, it means updating IPsec-related state so
that outgoing ESP/AH packets also starts to use those addresses in the tunnel
header. Depending on how new address as a
source address in its own outgoing ESP traffic. The responder
records the nominal division between Security
Association Database (SAD), Security Policy Database (SPD), new address, and Peer
Authorization Database (PAD) described if so required by policy, performs a
return routability check of the address. When this check completes,
the responder starts to use the new address as the destination for
its outgoing ESP traffic.

Another protocol run in [IPsecArch] multihoming scenario is actually
implemented, illustrated below.
In this scenario the initiator has one address but the responder has
two.

Initiator Responder
----------- -----------
1) HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_*_IP) -->

<-- HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_*_IP)

2) HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->

<-- HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IPV4_ADDRESS) }

(The initiator suspects a problem in the currently used address pair,
and probes its liveness.)

3) HDR, SK { N(NAT_DETECTION_*_IP) } -->

<-- HDR, SK { N(NAT_DETECTION_*_IP) }

(The initiator gives up on the current address pair, and tests the
other available address pair.)

4) HDR, SK { N(NAT_DETECTION_*_IP),
N(COOKIE2) } -->

<-- HDR, SK { N(NAT_DETECTION_*_IP),
N(COOKIE2) }

(This worked, and the initiator requests the peer to switch to new
addresses.)

5) HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_*_IP) } -->

<-- HDR, SK { N(NAT_DETECTION_*_IP) }

3.3 MOBIKE and Network Address Translation (NAT)

In some MOBIKE scenarios the network may contain NATs or stateful
packet filters (for brevity, the rest of this document talks simply
about NATs). The NAT Traversal feature specified in [IKEv2] allows
IKEv2 to work through NATs in many cases, and MOBIKE can leverage
this functionality: when the addresses used for IPsec SAs are
changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed.

Nevertheless, there are some limitations since NATs usually introduce
an implementation asymmetry in the network: only packets coming from the "inside"
cause state to be created. This asymmetry leads to restrictions on
what MOBIKE can do. To give a concrete example, consider a situation
where both peers have several only a single address, and the initiator is
behind a NAT. If the responder's address now changes, it needs to
send a packet to the initiator using its new address. However, if
the NAT is, for instance, of the common "restricted cone" type (see
[STUN] for one description of different places NAT types), this is not
possible: the NAT will drop packets sent from the new address (unless
the initiator has previously sent a packet to that
have address -- which
it cannot do until it knows the address).

For simplicity, MOBIKE does not attempt to be updated.

In this document, handle all possible NAT-
related scenarios. Instead, MOBIKE assumes that if NATs are present,
the term "initiator" means initiator is the party who originally
initiated "behind" the first IKE_SA (in a series of possibly several rekeyed
IKE_SAs); "responder" NAT, and does not fully
support the case where the responder's addresses change.

"Does not fully support" means that no special effort is made to
support this functionality. However, if the alternative is losing
connectivity completely, the responder can still attempt to proceed
with the other peer. During change, and depending on, e.g., the lifetime exact type of the
IKE_SA, both parties NAT, it
may initiate INFORMATIONAL succeed. However, analyzing the exact circumstances when this
will or CREATE_CHILD_SA
exchanges; will not work is not done in this case, document.

3.4 Limitations

This document focuses on the terms "exchange initiator" main scenario outlined in Section 1, and "exchange
responder" are used.
supports only tunnel mode.

The term "original initiator" (which in [IKEv2]
refers to the party who started base version of the latest IKE_SA rekeying) is MOBIKE protocol may not
used in this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted cover all potential
future use scenarios, such as described transport mode, application to securing
SCTP or optimizations desirable in [KEYWORDS].

2. MOBIKE specific circumstances. Future
extensions may be defined later to support additional requirements.

4. Protocol Exchanges

2.1

4.1 Signaling Support for MOBIKE

Implementations that wish to use MOBIKE for use MOBIKE for a particular IKE_SA MUST
include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
case of multiple IKE_AUTH exchanges, in the message containing the SA
payload).

The format of the MOBIKE_SUPPORTED notification is described in
Section 5.

4.2 Initial Tunnel Header Addresses

When an IPsec SA is created, the tunnel header IP addresses (and port
if doing UDP encapsulation) are taken from the IKE_SA, not the IP
header of the IKEv2 message requesting the IPsec SA. The addresses
in the IKE_SA are initialized as follows: If the IKE_SA_INIT request
contains the NAT_DETECTION_*_IP notifications and the responder
supports NAT Traversal, the values are initialized from the IP header
of the first IKE_AUTH request. Otherwise, the values are initialized
from the IP header of the IKE_SA_INIT request.

The addresses are taken from the IKE_AUTH request when NAT Traversal
is being used because IKEv2 requires changing from port 500 to 4500
if a particular IKE_SA NAT is discovered. To simplify things, implementations that
support both this specification and NAT Traversal MUST
include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
case of multiple IKE_AUTH exchanges, in the message containing change to port
4500 if the SA
payload).

The MOBIKE_SUPPORTED notification payload correspondent also supports both, even if no NAT was
detected between them (this way, there is described in Section 3.

2.2 no need to change the ports
later).

4.3 Additional Addresses

Both the initiator and responder MAY include one or more
ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification
payloads notifications in
the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
message containing the SA payload).

Initiator Responder
----------- -----------
HDR, SK { IDi, [CERT], [IDr], AUTH,
[CP(CFG_REQUEST)]
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED),
[N(ADDITIONAL_*_ADDRESS)+] } -->

<-- HDR, SK { IDr, [CERT], AUTH,
[CP(CFG_REPLY)],
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED)
[N(ADDITIONAL_*_ADDRESS)+] }

The recipient stores this information, but no other action is taken
at this time.

Although both the initiator and responder maintain a set of peer
addresses (logically associated with the IKE_SA), it is important to
note that they use this information for slightly different purposes.

The initiator uses the set of responder addresses as an input to its
address selection policy; it may at some later point decide to move
the IPsec traffic to one of these addresses using the procedure
described in Section 2.3. 4.4. The responder normally does not use the
set of initiator addresses for anything: the addresses are used only
when the responder's own addresses change. change (see Section 4.5).

The set of addresses available to the peers can change during the
lifetime of the IKE_SA. The procedure for updating this information
is described in Section 2.4. 4.5.

Note that if some of the initiator's interfaces are behind a NAT
(from the responder's point of view), the addresses received by the
responder will be incorrect. This means the procedure for changing
responder addresses described in Section 2.4 4.5 does not fully work when
the initiator is behind a NAT. For the same reason, the peers also
SHOULD NOT use this information for any other purposes than what is
explicitly described in this document.

2.3

4.4 Changing Addresses in IPsec SAs

In MOBIKE, the initiator decides what addresses are used in the IPsec
SAs. That is, the responder usually never updates any IPsec SAs
without receiving an explicit UPDATE_SA_ADDRESSES request from the
initiator. (As described below, the responder can, however, update
the IKE_SA in some circumstances.)

The reasons why the initiator wishes to change the addresses are
largely beyond the scope of MOBIKE. Typically triggers include
information received from lower layers, such as changes in IP
addresses or link-down indications. Some of this information can be
unreliable: for instance, ICMP messages could be spoofed by an
attacker. Such Unreliable information itself MUST NOT be used to conclude
than an update is needed: instead, the initiator SHOULD trigger dead
peer
detection. detection (that is, send an INFORMATIONAL request).

Changing addresses can also be triggered by events within IKEv2. At
least the following events can cause the initiator to re-evaluate its
local address selection policy, possibly leading to changing the
addresses.

o An IKEv2 request has been re-transmitted several times, but no
valid reply has been received. This suggests the current path is
no longer working.

o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS
payloads
notifications is received. This means the peer's addresses may
have changed.

o An UNACCEPTABLE_ADDRESSES notification is received as a response
to address update request (described below).

o The initiator receives a NAT_DETECTION_DESTINATION_IP payload notification
that does not match the previous UPDATE_SA_ADDRESSES response (see
Section 2.6 4.7 for a more detailed description).

The description in the rest of this section assumes that the
initiator has already decided what the new addresses should be. When
this decision has been made, the initiator initiator:

o Updates the IKE_SA with the new addresses, and sets the
"pending_update" flag in the IKE_SA.

o Updates the IPsec SAs associated with this IKE_SA with the new addresses,
addresses (unless the initiator's policy requires a return
routability check before updating the IPsec SAs, and sets the "pending_update" flag check has
not been done for this responder address yet).

o If the IPsec SAs were updated in the
IKE_SA.

o previous step: If NAT
Traversal is not enabled, and the responder supports NAT Traversal
(as indicated by NAT detection payloads in the IKE_SA_INIT
exchange), and the initiator either suspects or knows that a NAT
is likely to be present, enables NAT Traversal.

o If there are outstanding IKEv2 requests (requests for which the
initiator has not yet received a reply), continues retransmitting
them using the addresses in the IKE_SA (the new addresses).

o When the window size allows, sends an INFORMATIONAL request
containing the UPDATE_SA_ADDRESSES notification payload (which does not
contain any data), and clears the "pending_update" flag. The
request will be as follows:

Initiator Responder
----------- -----------
HDR, SK { N(UPDATE_SA_ADDRESSES),
[N(NAT_DETECTION_*_IP)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->

o If a new address change occurs while waiting for the response,
starts again from the first step (and ignores responses to this
UPDATE_SA_ADDRESSES request).

When processing an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification, the responder responder:

o Determines whether it has already received a newer
UPDATE_SA_ADDRESSES request than this one (if the responder uses a
window size greater than one, it is possible that requests are
received out of order). If it has, a normal response message
(described below) is sent, but no other action is taken.

o If the NO_NATS_ALLOWED payload notification is present, processes it as
described in Section 2.7. 4.8.

o Checks that the (source IP address, destination IP address) pair
in the IP header is acceptable according to local policy. If it
is not, replies with a message containing the
UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).

o Updates the IP addresses in the IKE_SA with the values from the IP
header. (Using the address from the IP header is consistent with
normal IKEv2, and allows IKEv2 to work with NATs without needing
unilateral self-address fixing [UNSAF].)
o Replies with an INFORMATIONAL response:

Initiator Responder
----------- -----------
<-- HDR, SK { [N(NAT_DETECTION_*_IP)],
[N(COOKIE2)],
[N(COOKIE2)] }

o If necessary, initiates a return routability check for the new
initiator address (see Section 2.5) 4.6) and waits until the check is
completed.

o Updates the IPsec SAs associated with this IKE_SA with the new
addresses.

o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.

When the initiator receives the reply, it it:

o If an address change has occured occurred after the request was first
sent, no MOBIKE processing is done for the reply message, since a
new UPDATE_SA_ADDRESSES is going to be sent (or has already been
sent, if window size greater than one is in use).

o If the response contains the UNEXPECTED_NAT_DETECTED payload, notification,
processes it as described in Section 2.7. 4.8.

o If the response contains an UNACCEPTABLE_ADDRESSES notification
payload, notification,
the initiator MAY select another addresses and retry the exchange,
keep on using the current addresses, or disconnect.

o Updates the IPsec SAs associated with this IKE_SA with the new
addresses (unless this was already done before sending the
request).

o If NAT Traversal is supported and NAT detection payloads were
included, enables or disables NAT Traversal.

There is one exception to the rule that the responder never updates
any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
the source address the responder is currently using becomes
unavailable (i.e., sending packets using that source address is no
longer possible), the responder is allowed to update the IPsec SAs to
use some other address (in addition to initiating the procedure
described in the next section).

2.4

4.5 Updating Additional Addresses

As described in Section 2.2, 4.3, both the initiator and responder can
send a list of additional addresses in the IKE_AUTH exchange. This
information can be updated by sending an INFORMATIONAL exchange
request message that contains either one or more ADDITIONAL_IP4/
6_ADDRESS payloads notifications or the NO_ADDITIONAL_ADDRESSES payload. notification.
The message exchange will look as follows:

Initiator Responder
----------- -----------
HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
[N(NO_ADDITIONAL_ADDRESSES)],
[N(NO_NATS_ALLOWED)],
[N(COOKIE2)] } -->

<-- HDR, SK { [N(COOKIE2)] }

When a request containing ADDITIONAL_*_ADDRESS or
NO_ADDITIONAL_ADDRESSES payloads notification is received, the exchange responder
responder:

o Determines whether it has already received a newer request to
update the addresses (if a window size greater than one is used,
it is possible that the requests are received out of order). If
it has, a response message is sent, but the address set is not
updated.

o If the NO_NATS_ALLOWED payload notification is present, processes it as
described in Section 2.7. 4.8.

o Updates the set of peer addresses based on the IP header and
ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS payloads. notifications.

o Sends a response.

The initiator MAY include these payloads notifications in the same request as
UPDATE_SA_ADDRESSES.

If the request to update the addresses is retransmitted using several
different source addresses, a new INFORMATIONAL request MUST be sent.

There is one additional complication: when the responder wants to
update the address set, the currently used addresses may no longer
work. In this case, the responder uses the additional address list
received from the initiator and the list of its own addresses to
determine which addresses to use for sending the INFORMATIONAL
request. This is the only time the responder uses the additional
address list received from the initiator.

Note that both peers can have their own policies about what addresses
are acceptable to use. A minimal "mobile client" could have a policy
that says that only the responder's address specified in local
configuration is acceptable. This kind of client does not have to
send or process ADDITIONAL_*_ADDRESS notification payloads. notifications. Similarly, a
simple "VPN gateway" that has only a single address, and is not going
to change it, does not need to send or understand
ADDITIONAL_*_ADDRESS notification payloads.

2.5 notifications.

4.6 Return Routability Check

Both parties can optionally verify that the other party can actually
receive packets at the claimed address. This "return routability
check" can be done before updating the IPsec SAs, immediately after
updating them, or continuously during the connection.

By default, return routability check SHOULD be done before updating
the IPsec SAs. In environments where the peer is expected to be
well-behaving (many corporate VPNs, for instance), or the address can
be verified by some other means (e.g., the address is included in the
peer's certificate), the return routability check MAY be skipped omitted or
postponed until after the IPsec SAs have been updated.

Any INFORMATIONAL exchange can be used for return routability
purposes (with one exception, described below): when a valid response
is received, we know the other party can receive packets at the
claimed address.

To ensure that the peer cannot generate the correct INFORMATIONAL
response without seeing the request, a new payload is added to
INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
include a COOKIE2 notification payload, notification, and if included, the recipient of an
INFORMATIONAL request MUST copy the payload notification as-is to the
response. When processing the response, the original sender MUST
verify that the value is the same one as sent. If the values do not
match, the IKE_SA MUST be closed.

There is one additional issue that must be taken into account.

If the same INFORMATIONAL request has been sent to several different
addresses (i.e., the destination address in the IKE_SA has been
updated after the request was first sent), receiving the
INFORMATIONAL response does not tell which address is the working
one. In this case, a new INFORMATIONAL request needs to be sent to
check return routability.

2.6

4.7 Changes in NAT Mappings

IKEv2 performs Dead Peer Detection (DPD) if there has recently been
only outgoing traffic on all of the SAs associated with the IKE_SA.

In MOBIKE, these messages can also be used to detect if NAT mappings
have changed (for example, if the keepalive internal is too long, or
the NAT box is rebooted). More specifically, if both peers support
both this specification and NAT Traversal, NAT_DETECTION_*_IP
payloads
notifications MAY be included in any INFORMATIONAL request; if the
request includes them, the responder MUST also include them in the
response (but no other action is taken, unless otherwise specified).

When the initiator is behind a NAT, NAT (as detected earlier using
NAT_DETECTION_*_IP notifications), it SHOULD include these payloads
notifications in DPD messages, and compare the received
NAT_DETECTION_DESTINATION_IP payload notifications with the value from the
previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response).
If the values do not match, the IP address and/or port seen by the
responder has changed, and the initiator SHOULD send
UPDATE_SA_ADDRESSES as described in Section 2.3.

When MOBIKE is in use, the host not behind a NAT SHOULD NOT use in Section 4.4.

When MOBIKE is in use, the dynamic updates specified in [IKEv2]
Section 2.23 (where the peer address and port are updated from the
last valid authenticated
packet). This ensures that both peers have packet) work in a consistent view of when
addresses are to be changed, and prevents conflicts between MOBIKE-
originated updates and NAT-T slightly different
fashion. The host not behind a NAT MUST NOT use these dynamic updates. It also means
updates for IKEv2 packets, but MAY use them for ESP packets. This
ensures that an INFORMATIONAL exchange that does not contain
UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
used for, e.g., testing
whether a particular path works.

2.7 NAT Prohibition

IKEv2/IPsec implementations that do not support NAT Traversal can, in
fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6
translation agents in tunnel mode. This may be considered a problem
in some circumstances, since in some sense any modification of the IP
addresses can be considered to be an attack.

The "NAT prohibition" feature allows the initiator to have a policy
that prevents the use of paths that contain NATs, IPv4/IPv6
translation agents, or other nodes that modify the addresses in the
IP header. This feature is mainly intended for site-to-site VPN
cases, where the administrators may know beforehand that NATs are not
present, and thus any modification to the packet can be considered to
be an attack.

This specification addresses the issue as follows. When an IPsec SA
is created, the tunnel header IP addresses (and port if doing UDP
encapsulation) are taken from the IKE_SA, not the message IP header.
The NO_NATS_ALLOWED payload is used to guarantee that NATs have not
modified the address used in IKE_SA. However, all response messages
are still sent to the address and port the corresponding request came
from.

An initiator who wishes to use this feature includes for, e.g., testing whether a
NO_NATS_ALLOWED payload in the IKE_SA_INIT request. The responder
then MUST calculate the expected value based on the values from the
IP header, particular path works.

4.8 NAT Prohibition

Basic IKEv2/IPsec without NAT Traversal support may work across some
types of one-to-one "basic" NATs and compare this with the value IPv4/IPv6 translation agents in
tunnel mode. This is because the NO_NATS_ALLOWED
payload. If they do not match, the responder replies with "HDR(A,0),
N(UNEXPECTED_NAT_DETECTED)" and IKEv2 integrity checksum does not create any state.

Initiator Responder
----------- -----------
HDR, [N(COOKIE)],
SAi1, KEi, Ni,
[N(NO_NATS_ALLOWED)] -->

<-- HDR, SAr1, KEr, Nr,
[CERTREQ]

If the values do match,
cover the responder initializes (local_address,
local_port, peer_address, peer_port) addresses in the to-be-created IKE_SA with
values from the IP header. The same applies if neither
NO_NATS_ALLOWED nor NAT_DETECTION_*_IP payloads were included, or if
the responder does not support NAT Traversal.

If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
no NO_NATS_ALLOWED payload, the situation is different This may be considered a
problem in some circumstances, since in some sense any modification
of the
initiator may at this point change from port 500 IP addresses can be considered to 4500. In this
case, be an attack.

This specification addresses the responder initializes (local_address, local_port,
peer_address, peer_port) from issue by protecting the first IKE_AUTH request.

IKEv2 requires that if an IPsec endpoint discovers a IP addresses
when NAT between it
and its correspondent, it MUST send all subsequent traffic to and
from port 4500. To simplify things, implementations Traversal has not been explicitly enabled. This means that support
both this specification and
MOBIKE without NAT Traversal MUST change to port 4500 support will not work if the correspondent also supports both, even if no NAT was detected
between them (this way, there paths
contain NATs, IPv4/IPv6 translation agents, or other nodes that
modify the addresses in the IP header. This feature is no need mainly
intended for site-to-site VPN cases, where the administrators may
know beforehand that NATs are not present, and thus any modification
to change the ports later).

NO_NATS_ALLOWED payloads packet can also be included considered to be an attack.

More specifically, when changing NAT Traversal is not enabled, all messages
that can update the addresses of associated with the IKE_SA and/or IPsec
SAs (see Section 2.3) (the IKE_SA_INIT request and updating all INFORMATIONAL requests that
contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS
notifications) MUST also include a NO_NATS_ALLOWED notification. The
exchange responder MUST verify that the contents of the
NO_NATS_ALLOWED notification match the additional addresses (see Section 2.4). An initiator using this "NAT
prohibition" feature includes in the IP header.
If they do not match, a NO_NATS_ALLOWED payload response containing an
UNEXPECTED_NAT_DETECTED notification is sent (and in all the case of the
IKE_SA_INIT exchange, no state is created at the responder). The
response message is sent to the address update messages. and port the corresponding
request came from, not the address contained in the NO_NATS_ALLOWED
notification.

If the exchange initiator receives an UNEXPECTED_NAT_DETECTION
notification in response to its request, it SHOULD retry the
operation several times using new IKE_SA_INIT/INFORMATIONAL requests.
This ensures that an attacker who is able to modify only a single
packet does not unnecessarily cause a path to remain unused.

2.8 to remain unused.

If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
responder MUST NOT use the contents of the NO_NATS_ALLOWED
notification for any other purpose than possibly logging the
information for troubleshooting purposes.

4.9 Path Testing

IKEv2 Dead Peer Detection allows the peers to detect if the currently
used path has stopped working. However, if either of the peers has
several addresses, Dead Peer Detection alone does not tell which of
the other paths might work.

If required by its address selection policy, the initiator can use
normal IKEv2 INFORMATIONAL request/response messages to test whether
a certain path works. Implementations MAY do path testing even if
the currenly used path is working to, for example, detect when a
better (but previously unavailable) path becomes available.

4.10 Failure Recovery and Timeouts

In MOBIKE, the initiator is responsible for detecting and recovering
from most failures.

To give the initiator enough time to detect the error, the responder
SHOULD use relatively long timeout intervals when, for instance,
retransmitting IKEv2 requests or deciding whether to initiate dead
peer detection.

3. While no specific timeout lengths are required, it
is suggested that responders continue retransmitting IKEv2 requests
for at least five minutes before giving up.

5. Payload Formats

3.1

5.1 MOBIKE_SUPPORTED Notification Notify Payload

The MOBIKE_SUPPORTED notification payload is included in the IKE_AUTH
exchange to indicate that the implementation supports this
specification.

The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-
IANA(16396..40959). TBD-BY-IANA1. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.

3.2

5.2 ADDITIONAL_IP4/6_ADDRESS Notification Notify Payloads

Both parties can include ADDITIONAL_IP4_ADDRESS and/or
ADDITIONAL_IP6_ADDRESS payloads notifications in the IKE_AUTH exchange and
INFORMATIONAL exchange request messages; see Section 2.2 4.3 and
Section 2.4 4.5 for more detailed description.

The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA(16396..40959) TBD-BY-IANA2 and TBD-BY-
IANA(16396..40959), TBD-BY-IANA3,
respectively. The Protocol ID and SPI Size fields are set to zero.
The data associated with these Notify types is either a four-octet
IPv4 address or a 16-octet IPv6 address.

3.3

5.3 NO_ADDITIONAL_ADDRESSES Notification Notify Payload

The NO_ADDITIONAL_ADDRESSES payload notification can be included in an
INFORMATIONAL exchange request messages to indicate that the exchange
initiator does not have addresses beyond the one used in the exchange
(see Section 2.4 4.5 for more detailed description).

The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-
IANA(16396..40959). TBD-BY-IANA4.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.

3.4

5.4 UPDATE_SA_ADDRESSES Notification Notify Payload

This payload notification is included in INFORMATIONAL exchange requests sent
by the initiator to update addresses of the IKE_SA and IPsec SAs (see
Section 2.3). 4.4).

The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-
IANA(16396..40959). TBD-BY-IANA5. The
Protocol ID and SPI Size fields are set to zero. There is no data
associated with this Notify type.

3.5

5.5 UNACCEPTABLE_ADDRESSES Notification Notify Payload

The responder can include this notification payload in an INFORMATIONAL
exchange response to indicate that the address change in the
corresponding request message (which contained an UPDATE_SA_ADDRESSES notification payload)
notification) was not carried out.

The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-
IANA(40..8191). TBD-BY-IANA6.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.

3.6

5.6 COOKIE2 Notification Notify Payload

This payload notification MAY be included in any INFORMATIONAL request for
return routability check purposes (see Section 2.5). 4.6). If the
INFORMATIONAL request includes COOKIE2, the exchange responder MUST
copy the
payload notification to the response message.

The data associated with this notification MUST be between 8 and 64
octets in length (inclusive), and MUST be chosen by the exchange
initiator in a way that is unpredictable to the exchange responder.
The Notify Message Type for this message is TBD-BY-
IANA(16396..40959). TBD-BY-IANA7. The
Protocol ID and SPI Size fields are set to zero.

3.7

5.7 NO_NATS_ALLOWED Notification Notify Payload

See Section 2.7 4.8 for a description of this payload. notification.

The data associated with field of this notification is the SHA-1 hash
[FIPS180-2] of contains the following data: IKE SPIs (in the order they appear
in the header),
information: the IP address and port from which the packet was sent,
and the IP address and port to which the packet was sent. The Notify
Message Type for this message is TBD-BY-IANA(16396..40959). TBD-BY-IANA8. The Protocol ID and
SPI Size fields are set to zero.

3.8

5.8 UNEXPECTED_NAT_DETECTED Notification Notify Payload

See Section 2.7 4.8 for a description of this payload. notification.

The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-
IANA(40..8191). TBD-BY-IANA9.
The Protocol ID and SPI Size fields are set to zero. There is no
data associated with this Notify type.

6. Security Considerations

The main goals of this specification are to not reduce the security
offered by usual IKEv2 procedures and to counter mobility related
threats in an appropriate manner. This section describes new
security considerations introduced by MOBIKE. See [IKEv2] for
security considerations for IKEv2 in general.

4.1

6.1 Traffic Redirection and Hijacking

MOBIKE payload payloads relating to updating addresses are encrypted,
integrity protected, and replay protected using the IKE_SA. This
assures that no one except the participants can, for instance, give a
control message to change the addresses.

However, just like with normal IKEv2, the actual IP addresses in the
IP header are not covered by the integrity protection. This means
that a NAT between the parties (or an attacker acting as a NAT) can
modify the addresses and cause incorrect tunnel header (outer) IP
addresses to be used for IPsec SAs. The scope of this attack is
limited mainly to denial-of-service, since all traffic is protected
using IPsec.

This attack can only be launched by on-path attackers that are
capable of modifying IKEv2 messages carrying NAT detection payloads
(such as Dead Peer Detection messages). By modifying the IP header
of these packets, the attackers can lead the peers believe a new NAT
or a changed NAT binding exists between them. The attack can
continue as long as the attacker is on the path, modifying the IKEv2
messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
designed to detect NAT mapping changes will eventually recognize that
the intended traffic is not getting through, and update the addresses
appropriately.

MOBIKE introduces the NO_NATS_ALLOWED payload notification that can be is used to
detect modification of the addresses in the IP header by outsiders outsiders.
When this payload notification is used, communication through NATs and other
address translators is impossible. impossible, so it is sent only when not doing
NAT Traversal. This feature is mainly intended for site-to-site VPN
cases, where the administrators may know beforehand that valid NATs
are not present, and thus any modification to the packet can be
considered to be an attack. However, this
feature SHOULD NOT be enabled by default, since it creates a denial-
of-service vulnerability even when no malicious attackers are
present: a misconfiguration or introduction of a (non-malicious) NAT
can cause the connection to fail.

4.2

6.2 IPsec Payload Protection

The use of IPsec protection on payload traffic protects the
participants against disclosure of the contents of the traffic,
should the traffic end up in an incorrect destination or be
eavesdropped along the way.

However, security associations originally created for the protection
of a specific flow between specific addresses may be moved through
MOBIKE. The updated by
MOBIKE later on. This has to be taken into account if the level of
required protection may be different in a new depends on, for instance, the current location of a
the VPN client, for instance. client.

It is recommended that security policies for peers that are allowed
to use MOBIKE are configured in a manner that takes into account that
a single security association can be used through different paths of varying
security properties at different times.

4.3

6.3 Denial-of-Service Attacks Against Third Parties

Traffic redirection may be performed not just to gain access to the
traffic (not very interesting since it is encrypted) or to deny
service to the peers, but also to cause a denial-of-service attack
for a third party. For instance, a high-speed TCP session or a
multimedia stream may be redirected towards a victim host, causing
its communications capabilities to suffer.

The attackers in this threat can be either outsiders or even one of
the participants. IKEv2 peers. In usual VPN usage scenarios, attacks by the
participants peers
can be easily dealt with if the authentication performed in the
initial IKEv2 negotiation can be traced to persons who can be held
responsible for the attack. This may not be the case in all
scenarios, particularly with opportunistic approaches to security.

Normally such attacks would expire in a short time frame due to the
lack of responses (such as transport layer acknowledgements) from the
victim. However, as described in [Aura02], malicious participants
would typically be able to spoof such acknowledgements and maintain
the traffic flow for an extended period of time. For instance, if
the attacker opened the TCP stream itself before redirecting it to
the victim, the attacker becomes aware of the sequence number space
used in this particular session.

It should also be noted, as shown in [Bombing], that without ingress
filtering in the attacker's network such attacks are already possible
simply by sending spoofed packets from the attacker to the victim
directly. Furthermore, if the attacker's network has ingress
filtering, this attack is largely prevented for MOBIKE as well.
Consequently, it makes little sense to protect against attacks of
similar nature in MOBIKE. However, it still makes sense to limit the
amplification capabilities provided to attackers, so that they cannot
use stream redirection to send 1000 a large number of packets to the
victim by sending just a few packets themselves.

This specification requires the use of themselves.

This specification includes return routability tests
(under certain conditions) to limit the
duration of any "third party bombing" attacks by off-path (relative
to the victim) attackers. The tests are authenticated messages that
the peer has to respond to, and can be performed either before the
address change takes effect, immediately afterwards, or even
periodically during the session. The tests contain unpredictable
data, and only someone who has the keys associated with the IKE SA
and has seen the request packet can properly respond to the test.

4.4

6.4 Spoofing Network Connectivity Indications

Attackers may spoof various indications from lower layers and the
network in an effort to confuse the peers about which addresses are
or are not working. For example, attackers may spoof link-layer
error messages in an effort to cause the parties to move their
traffic elsewhere or even to disconnect. Attackers may also spoof
information related to network attachments, router discovery, and
address assignments in an effort to make the parties believe they
have Internet connectivity when in reality they do not.

This may cause use of non-preferred addresses or even denial-of-
service.

MOBIKE does not provide any protection of its own for indications
from other parts of the protocol stack. These vulnerabilities can be
mitigated through the use of techniques specific to the other parts
of the stack, such as properly dealing with validation of ICMP errors [ICMPAttacks], link
layer security, or the use of [SEND] to protect IPv6 Router and
Neighbor Discovery.

Ultimately MOBIKE depends on the delivery of IKEv2 messages to
determine which paths can be used. If IKEv2 messages sent using a
particular source and destination addresses reach the recipient and a
reply is received, MOBIKE will usually consider the path working;if working; if
no reply is received even after retransmissions, MOBIKE will suspect
the path is broken. An attacker who can consistently control the
delivery or non-delivery of the IKEv2 messages in the network can
thus influence which addresses actually get used.

5. network can
thus influence which addresses actually get used.

6.5 Address and Topology Disclosure

MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications
reveal information about which networks the peers are connected to.

For example, consider a host A with two network interfaces: a
cellular connection and a wired Ethernet connection to a company LAN.
If host A now contacts host B using IKEv2/MOBIKE and sends
ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional
information it might not otherwise know. If host A used the cellular
connection for the IKEv2/MOBIKE traffic, host B can also see the
company LAN address (and perhaps further guess that host A is used by
an employee of that company). If host A used the company LAN to make
the connection, host B can see that host A has a subscription from
this particular cellular operator.

These additional addresses can also disclose more accurate location
information than just a single address. Suppose that host A uses its
cellular connection for IKEv2/MOBIKE traffic, but also sends an
ADDITIONAL_IP4_ADDRESS notification containing an IP address
corresponding to, say, a wireless LAN at a particular coffee shop
location. It is likely that host B can now make a much better guess
at A's location than would be possible based on the cellular IP
address alone.

Furthermore, as described in Section 4.3, some of the addresses could
also be private addresses behind a NAT.

In many environments, disclosing address information is not a problem
(and indeed it cannot be avoided if the hosts wish to use those
addresses for IPsec traffic). For instance, a remote access VPN
client could consider the corporate VPN gateway sufficiently
trustworthy for this purpose.

However, if MOBIKE is used in some more opportunistic approach, it
can be desirable to limit the information that is sent. The peers
naturally do not have to disclose any addresses they do not want to
use for IPsec traffic. Also, as noted in Section 4.5, an initiator
whose policy is to always use the locally configured responder
address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads.

7. IANA Considerations

This document does not create any new namespaces to be maintained by
IANA, but it requires new values in namespaces that have been defined
in the IKEv2 base specification [IKEv2].

This document defines several new IKEv2 notification payloads notifications whose values
are to be allocated from the "IKEv2 Notification Payload Notify Message Types" namespace.

Notify Message Value
--------------------------- -----
MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959)
ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959)
ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959)
NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959)
UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959)
UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191)
COOKIE2 TBD-BY-IANA7 (16396..40959)
NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959)
UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191)

These notification payloads notifications are described in Section 3.

6. 5.

8. Acknowledgements

This document is a collaborative effort of the entire MOBIKE WG. We
would particularly like to thank Jari Arkko, Francis Dupont, Paul
Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also
incorporates ideas and text from earlier MOBIKE protocol proposals,
including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the
MOBIKE design document [Design].

9. References

7.1

9.1 Normative References

[FIPS180-2]
National Institute of Standards and Technology,
"Specifications for the Secure Hash Standard", Federal
Information Processing Standard (FIPS) Publication 180-2,
August 2002.

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

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

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

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

7.2

9.2 Informative References

[AddrMgmt]
Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-07 (work in progress),
May 2005.

[Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", Proc. 18th Annual Computer Security
Applications Conference (ACSAC), December 2002.

[Bombing] Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),
June 2005.

[DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-15 (work in progress),
August 2005.

[DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting
Network Attachment in IPv6 - Best Current Practices for
hosts", draft-ietf-dna-hosts-01 (work in progress),
June 2005.

[Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE
protocol", draft-ietf-mobike-design-02 (work in progress),
February 2005.

[ICMPAttacks]
Gont, F., "ICMP attacks against TCP",
draft-gont-tcpm-icmp-attacks-03 (work in progress),
December 2004.

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

[Kivinen] Kivinen, T., "MOBIKE protocol",
draft-kivinen-mobike-protocol-00 (work in progress),
February 2004.

[MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

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

[MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO-
IKE)", draft-eronen-mobike-mopo-02 (work in progress),
February 2005.

[PseudoNAT]
Dupont, F.

[RFC2461] Narten, T., Nordmark, E., and J-J. Bernard, "Transient pseudo-NAT attacks
or how NATs are even more evil than you believed",
draft-dupont-transient-pseudonat-04 (expired) (work in
progress), June 2004. W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.

[SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

[SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
Multihoming Extensions for IKEv2 (SMOBIKE)",
draft-eronen-mobike-simple-00 (work in progress),
March 2004.

[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.

[UNSAF] Daigle, L., "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.

Author's Address

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

Email: pasi.eronen@nokia.com

Appendix A. Changelog

(This section should be removed by the RFC editor.)

Changes from -02 to -03:

o Editorial fixes and clarifications (issues 42 and 43).

o Clarified IANA considerations (issue 42).

o Added security considerations about address and topology
disclosure (issue 42).

o Added a suggestion about retransmission timeout (issue 42).

o Change dynamic address updates: MUST NOT do them based on IKEv2
packets, MAY do based on ESP (issue 34).

o Mandate NAT prohibition if not doing NAT traversal (issue 41).

o Clarified security considerations related to NATs (issue 41).

o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue
42).

o Added a short section about path testing.

o Added an example protocol run in Section 1.

Changes from -01 to -02:

o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35,
37).

o Changed terminology related to NAT prohibition (issues 22, 24).

o Rewrote much of the ADDITIONAL_*_ADDRESS text, added
NO_ADDITIONAL_ADDRESSES notification.

o Use NAT detection payloads to detect changes in NAT mappings
(issue 34).

o Removed separate PATH_TEST message (issue 34).

o Clarified processing of UNACCEPTABLE_ADDRESSES when request has
been sent using several different addresses (issue 36).

o Clarified changing of ports 500/4500 (issue 33).

o Updated security considerations (issues 27 and 28).

o No need to include COOKIE2 in non-RR messages (issue 32).

o Many editorial fixes and clarifications (issue 38, 40).

o Use the terms initiator and responder more consistently.

o Clarified that this document does not solve all problems in MOBIKE
WG charter (issue 40).

Changes from -00 to -01:

o Editorial fixes and small clarifications (issues 21, 25, 26, 29).

o Use Protocol ID zero for notifications (issue 30).

o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue
23).

o Use the word "path" only in senses that include the route taken
(issue 29).

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.