Request for Comments: 4555 Nokia
Category: Standards Track June 2006
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the MOBIKE protocol, a mobility and
multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
allows the IP addresses associated with IKEv2 and tunnel mode IPsec
Security Associations to change. A mobile Virtual Private Network
(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 one currently being used stops
working.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Implementation Considerations . . . . . . . . . . . . 31
A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
1. Introduction
1.1. Motivation
IKEv2 is used for performing mutual authentication, as well as
establishing and maintaining IPsec Security Associations (SAs). In
the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
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
(transport mode IPsec SAs are beyond the scope of this document).
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 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, such as entering a code from a
token card. Creating new SAs often involves expensive calculations
and possibly a large number of round-trips. For 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 enabling 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 the office’s wireless LAN. When the user leaves the office,
the laptop could start using General Packet Radio Service (GPRS);
when the user arrives home, the laptop could switch to the home
wireless LAN. MOBIKE updates only the outer (tunnel header)
addresses of IPsec SAs, and the addresses and other 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 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.
1.2. Scope and Limitations
This document focuses on the main scenario outlined above and
supports only tunnel mode IPsec SAs.
The mobility support in MOBIKE allows both parties to move, but does
not provide a "rendezvous" mechanism that would allow simultaneous
movement of both parties or discovery of the addresses when the
IKE_SA is first established. Therefore, MOBIKE is best suited for
situations where the address of at least one endpoint is relatively
stable and can be discovered using existing mechanisms such as DNS
(see Section 3.1).
MOBIKE allows both parties to be multihomed; however, only one pair
of addresses is used for an SA at a time. In particular, load
balancing is beyond the scope of this specification.
MOBIKE follows the IKEv2 practice where a response message is sent to
the same address and port from which the request was received. This
implies that MOBIKE does not work over address pairs that provide
only unidirectional connectivity.
Network Address Translators (NATs) introduce additional limitations
beyond those listed above. For details, refer to Section 2.3.
The base version of the MOBIKE protocol does not cover all potential
future use scenarios, such as transport mode, application to securing
SCTP, or optimizations desirable in specific circumstances. Future
extensions may be defined later to support additional requirements.
Please consult the MOBIKE design document [Design] for further
information and rationale behind these limitations.
1.3. 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+"). To provide context, some diagrams also show what
existing IKEv2 payloads would typically be included in the exchanges.
These payloads are shown for illustrative purposes only; see [IKEv2]
for an authoritative description.
When this document describes updating the source/destination
addresses of an IPsec SA, it means updating IPsec-related state so
that outgoing Encapsulating Security Payload (ESP)/Authentication
Header (AH) packets use those addresses in the tunnel header.
Depending on how the nominal divisions between Security Association
Database (SAD), Security Policy Database (SPD), and Peer
Authorization Database (PAD) described in [IPsecArch] are actually
implemented, an implementation can have several different places that
have to be updated.
In this document, the term "initiator" means the party who originally
initiated the first IKE_SA (in a series of possibly several rekeyed
IKE_SAs); "responder" is the other peer. During the lifetime of the
IKE_SA, both parties may 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].
2. Protocol Overview
2.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 may have preferences about which
interface should be used due to, for instance, performance and cost
reasons. Second, the decision is constrained by the fact that some
of the pairs may not work at all due to incompatible IP versions,
outages 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 a remote access VPN
scenario) is responsible for deciding which address pair is used for
the IPsec SAs and for 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 a 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. This approach applies to the addresses in the
IPsec SAs; in the IKE_SA case, the exchange initiator can decide
which addresses are used.
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 a 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).
Many of these issues are not specific to MOBIKE, but are common with
the use of existing hosts in dynamic environments or with mobility
protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms
already exist or are being developed to deal with these issues. For
instance, link-layer and IP-layer mechanisms can be used to track the
status of connectivity within the local link [RFC2461]; movement
detection is being specified for both IPv4 and IPv6 in [DNA4],
[DNA6], and so on.
Naturally, updating the addresses of IPsec SAs 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
enabled only when NAT Traversal is not used.
2.2. Example Protocol Exchanges
A simple MOBIKE exchange in a mobile scenario is illustrated below.
The notation is based on [IKEv2], Section 1.2. In addition, the
source/destination IP addresses and ports are shown for each packet:
here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
the initiator and the responder.
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
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 have changed.)
3) (IP_I2:4500 -> IP_R1:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
<-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(Responder verifies that the initiator has given it a correct IP
address.)
4) <-- (IP_R1:4500 -> IP_I2:4500)
HDR, SK { N(COOKIE2) }
(IP_I2:4500 -> IP_R1:4500)
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 change in its own address, and informs the responder about
this by sending an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification. The request is sent using the new
IP address. At this point, it also starts to use the new address as
a source address in its own outgoing ESP traffic. Upon receiving the
UPDATE_SA_ADDRESSES notification, the responder records the new
address and, if it is required by policy, performs a return
routability check of the address. When this check (step 4)
completes, the responder starts to use the new address as the
destination for its outgoing ESP traffic.
Another protocol run in a multihoming scenario is illustrated below.
In this scenario, the initiator has one address but the responder has
two.
Initiator Responder
----------- -----------
1) (IP_I1:500 -> IP_R1:500)
HDR, SAi1, KEi, Ni,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) -->
<-- (IP_R1:500 -> IP_I1:500)
HDR, SAr1, KEr, Nr,
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)
2) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { IDi, CERT, AUTH,
CP(CFG_REQUEST),
SAi2, TSi, TSr,
N(MOBIKE_SUPPORTED) } -->
<-- (IP_R1:4500 -> IP_I1:4500)
HDR, SK { IDr, CERT, AUTH,
CP(CFG_REPLY),
SAr2, TSi, TSr,
N(MOBIKE_SUPPORTED),
N(ADDITIONAL_IP4_ADDRESS) }
(The initiator suspects a problem in the currently used address pair
and probes its liveness.)
3) (IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
(IP_I1:4500 -> IP_R1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) } -->
...
(Eventually, the initiator gives up on the current address pair and
tests the other available address pair.)
4) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP) }
(This worked, and the initiator requests the peer to switch to new
addresses.)
5) (IP_I1:4500 -> IP_R2:4500)
HDR, SK { N(UPDATE_SA_ADDRESSES),
N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) } -->
<-- (IP_R2:4500 -> IP_I1:4500)
HDR, SK { N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),
N(COOKIE2) }
2.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 simply
describes 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 because NATs usually
introduce an asymmetry into 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 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
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 address -- which it cannot do until it knows the
address).
For simplicity, MOBIKE does not attempt to handle all possible NAT-
related scenarios. Instead, MOBIKE assumes that if NATs are present,
the initiator is the party "behind" the NAT, and the case where the
responder’s addresses change is not fully supported (meaning that no
special effort is made to support this functionality). Responders
may also be unaware of NATs or specific types of NATs they are
behind. However, when a change has occurred that will cause a loss
of connectivity, MOBIKE responders will still attempt to inform the
initiator of the change. Depending on, for instance, the exact type
of NAT, it may or may not succeed. However, analyzing the exact
circumstances when this will or will not work is not done in this
document.
3. Protocol Exchanges
3.1. Initial IKE Exchange
The initiator is responsible for finding a working pair of addresses
so that the initial IKE exchange can be carried out. Any information
from MOBIKE extensions will only be available later, when the
exchange has progressed far enough. Exactly how the addresses used