Request for Comments: 4621 Safenet, Inc.
Category: Informational H. Tschofenig
Siemens
August 2006
Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension
of the Internet Key Exchange Protocol version 2 (IKEv2). These
extensions should enable an efficient management of IKE and IPsec
Security Associations when a host possesses multiple IP addresses
and/or where IP addresses of an IPsec host change over time (for
example, due to mobility).
This document discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by
other protocols. Design decisions for the MOBIKE protocol,
background information, and discussions within the working group are
recorded.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Scenarios .......................................................6
3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE .................................................8
5. Design Considerations ..........................................10
5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach .................................12
5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size ..............................23
6.3. Message Presentation ......................................24
6.4. Updating Address Set ......................................25
7. Security Considerations ........................................26
8. Acknowledgements ...............................................26
9. References .....................................................27
9.1. Normative references ......................................27
9.2. Informative References ....................................27
1. Introduction
The purpose of IKEv2 is to mutually authenticate two hosts, to
establish one or more IPsec Security Associations (SAs) between them,
and subsequently to manage these SAs (for example, by rekeying or
deleting). IKEv2 enables the hosts to share information that is
relevant to both the usage of the cryptographic algorithms that
should be employed (e.g., parameters required by cryptographic
algorithms and session keys) and to the usage of local security
policies, such as information about the traffic that should
experience protection.
IKEv2 assumes that an IKE SA is created implicitly between the IP
address pair that is used during the protocol execution when
establishing the IKEv2 SA. This means that, in each host, only one
IP address pair is stored for the IKEv2 SA as part of a single IKEv2
protocol session, and, for tunnel mode SAs, the host places this
single pair in the outer IP headers. Existing IPsec documents make
no provision to change this pair after an IKE SA is created (except
for dynamic address update of Network Address Translation Traversal
(NAT-T)).
There are scenarios where one or both of the IP addresses of this
pair may change during an IPsec session. In principle, the IKE SA
and all corresponding IPsec SAs could be re-established after the IP
address has changed. However, this is a relatively expensive
operation, and it can be problematic when such changes are frequent.
Moreover, manual user interaction (for example, when using human-
operated token cards (SecurID)) might be required as part of the
IKEv2 authentication procedure. Therefore, an automatic mechanism is
needed that updates the IP addresses associated with the IKE SA and
the IPsec SAs. The MOBIKE protocol provides such a mechanism.
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As
IKEv2 is built on the IPsec architecture [RFC4301], all protocols
developed within the MOBIKE working group must be compatible with
both IKEv2 and the architecture described in RFC 4301. This document
does not discuss mobility and multi-homing support for IKEv1
[RFC2409] or the obsoleted IPsec architecture described in RFC 2401
[RFC2401].
This document is structured as follows: After some important terms
are introduced in Section 2, a number of relevant usage scenarios are
discussed in Section 3. Section 4 describes the scope of the MOBIKE
protocol. Section 5 discusses design considerations affecting the
MOBIKE protocol. Section 6 investigates details regarding the MOBIKE
protocol. Finally, this document concludes in Section 7 with
security considerations.
2. Terminology
This section introduces the terminology that is used in this
document.
Peer
A peer is an IKEv2 endpoint. In addition, a peer implements the
MOBIKE extensions, defined in [RFC4555].
Available address
An address is said to be available if the following conditions are
met:
* The address has been assigned to an interface.
* If the address is an IPv6 address, we additionally require (a)
that the address is valid as defined in RFC 2461 [RFC2461], and
(b) that the address is not tentative as defined in RFC 2462
[RFC2462]. In other words, we require the address assignment
to be complete.
Note that this explicitly allows an address to be optimistic as
defined in [RFC4429].
* If the address is an IPv6 address, it is a global unicast or
unique site-local address, as defined in [RFC4193]. That is,
it is not an IPv6 link-local address.
* The address and interface is acceptable for sending and
receiving traffic according to a local policy.
This definition is taken from [WIP-Ark06] and adapted for the
MOBIKE context.
Locally operational address
An address is said to be locally operational if it is available
and its use is locally known to be possible and permitted. This
definition is taken from [WIP-Ark06].
Operational address pair
A pair of operational addresses are said to be an operational
address pair if and only if bidirectional connectivity can be
shown between the two addresses. Note that sometimes it is
necessary to consider connectivity on a per-flow level between two
endpoints. This differentiation might be necessary to address
certain Network Address Translation types or specific firewalls.
This definition is taken from [WIP-Ark06] and adapted for the
MOBIKE context. Although it is possible to further differentiate
unidirectional and bidirectional operational address pairs, only
bidirectional connectivity is relevant to this document, and
unidirectional connectivity is out of scope.
Path
The sequence of routers traversed by the MOBIKE and IPsec packets
exchanged between the two peers. Note that this path may be
affected not only by the involved source and destination IP
addresses, but also by the transport protocol. Since MOBIKE and
IPsec packets have a different appearance on the wire, they might
be routed along a different path, for example, due to load
balancing. This definition is taken from [RFC2960] and adapted to
the MOBIKE context.
Current path
The sequence of routers traversed by an IP packet that carries the
default source and destination addresses is said to be the Current
Path. This definition is taken from [RFC2960] and adapted to the
MOBIKE context.
Preferred address
The IP address of a peer to which MOBIKE and IPsec traffic should
be sent by default. A given peer has only one active preferred
address at a given point in time, except for the small time period
where it switches from an old to a new preferred address. This
definition is taken from [WIP-Nik06] and adapted to the MOBIKE
context.
Peer address set
We denote the two peers of a MOBIKE session by peer A and peer B.
A peer address set is the subset of locally operational addresses
of peer A that is sent to peer B. A policy available at peer A
indicates which addresses are included in the peer address set.
Such a policy might be created either manually or automatically
through interaction with other mechanisms that indicate new
available addresses.
Bidirectional address pair
The address pair, where traffic can be sent to both directions,
simply by reversing the IP addresses. Note that the path of the
packets going to each direction might be different.
Unidirectional address pair
The address pair, where traffic can only be sent in one direction,
and reversing the IP addresses and sending reply back does not
work.
For mobility-related terminology (e.g., Make-before-break or Break-
before-make), see [RFC3753].
3. Scenarios
In this section, we discuss three typical usage scenarios for the
MOBIKE protocol.
3.1. Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile
node (MN) changes its point of network attachment. Prior to the
change, the mobile node had established an IPsec connection with a
security gateway that offered, for example, access to a corporate
network. The IKEv2 exchange that facilitated the setup of the IPsec
SA(s) took place over the path labeled as ’old path’. The involved
packets carried the MN’s "old" IP address and were forwarded by the
"old" access router (OAR) to the security gateway (GW).
When the MN changes its point of network attachment, it obtains a new
IP address using stateful or stateless address configuration. The
goal of MOBIKE, in this scenario, is to enable the MN and the GW to
continue using the existing SAs and to avoid setting up a new IKE SA.
A protocol exchange, denoted by ’MOBIKE Address Update’, enables the
peers to update their state as necessary.
Note that in a break-before-make scenario the MN obtains the new IP
address after it can no longer be reached at the old IP address. In
a make-before-break scenario, the MN is, for a given period of time,
reachable at both the old and the new IP address. MOBIKE should work
in both of the above scenarios.
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | R | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario
3.2. Multihoming Scenario
Another MOBIKE usage scenario is depicted in Figure 2. In this
scenario, the MOBIKE peers are equipped with multiple interfaces (and
multiple IP addresses). Peer A has two interface cards with two IP
addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
and IP_B2. Each peer selects one of its IP addresses as the
preferred address, which is used for subsequent communication.
Various reasons (e.g., hardware or network link failures) may require
a peer to switch from one interface to another.
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B change their preferred
address)
Figure 2: Multihoming Scenario
Note that MOBIKE does not aim to support load balancing between
multiple IP addresses. That is, each peer uses only one of the
available address pairs at a given point in time.
3.3. Multihomed Laptop Scenario
The third scenario we consider is about a laptop that has multiple
interface cards and therefore several ways to connect to the network.
It may, for example, have a fixed Ethernet card, a WLAN interface, a
General Packet Radio Service (GPRS) adaptor, a Bluetooth interface,
or USB hardware. Not all interfaces are used for communication all
the time for a number of reasons (e.g., cost, network availability,
user convenience). The policies that determine which interfaces are
connected to the network at any given point in time is outside the
scope of the MOBIKE protocol and, as such, this document. However,
as the laptop changes its point of attachment to the network, the set
of IP addresses under which the laptop is reachable changes too.
In all of these scenarios, even if IP addresses change due to
interface switching or mobility, the IP address obtained via the
configuration payloads within IKEv2 remain unaffected. The IP
address obtained via the IKEv2 configuration payloads allow the
configuration of the inner IP address of the IPsec tunnel. As such,
applications might not detect any change at all.
4. Scope of MOBIKE
Getting mobility and multihoming actually working requires many
different components to work together, including coordinating
decisions between different layers, different mobility mechanisms,
and IPsec/IKEv2. Most of those aspects are beyond the scope of
MOBIKE: MOBIKE focuses only on what two peers need in order to agree
at the IKEv2 level (like new message formats and some aspects of
their processing) required for interoperability.
The MOBIKE protocol is not trying to be a full mobility protocol;
there is no support for simultaneous movement or rendezvous
mechanism, and there is no support for route optimization, etc. The
design document focuses on tunnel mode; everything going inside the
tunnel is unaffected by the changes in the tunnel header IP address,
and this is the mobility feature provided by the MOBIKE. That is,
applications running inside the MOBIKE-controlled IPsec tunnel might
not detect the movement since their IP addresses remain constant.
The MOBIKE protocol should be able to perform the following
operations (not all of which are done explicitly by the current
protocol):
o Inform the other peer about the peer address set
o Inform the other peer about the preferred address
o Test connectivity along a path and thereby detect an outage
situation
o Change the preferred address
o Change the peer address set
o Ability to deal with Network Address Translation devices
Figure 3 shows an example protocol interaction between a pair of
MOBIKE peers. MOBIKE interacts with the packet processing module of
the IPsec implementation using an internal API (such as those based
on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create
entries in the Security Association (SAD) and Security Policy
Databases (SPD). The packet processing module of the IPsec
implementation may also interact with IKEv2 and MOBIKE module using
this API. The content of the Security Policy and Security
Association Databases determines what traffic is protected with IPsec
in which fashion. MOBIKE, on the other hand, receives information
from a number of sources that may run both in kernel-mode and in
user-mode. These sources form the basis on which MOBIKE makes
decisions regarding the set of available addresses, the peer address
set, and the preferred address. Policies may also affect the
selection process.
The peer address set and the preferred address needs to be made
available to the other peer. In order to address certain failure
cases, MOBIKE should perform connectivity tests between the peers
(potentially over a number of different paths). Although a number of
address pairs may be available for such tests, the most important is
the pair (source address, destination address) of the current path.
This is because this pair is selected for sending and receiving
MOBIKE signaling and IPsec traffic. If a problem along this current
path is detected (e.g., due to a router failure), it is necessary to
switch to a new current path. In order to be able to do so quickly,
it may be helpful to perform connectivity tests of other paths
periodically. Such a technique would also help identify previously
disconnected paths that become operational again.
+---------------------+ +----------------+
| User-space | | |
| Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+
+---------------------+ ^
^ |
| | User space
++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++
| | Kernel space
| v
| +----------------+
v | |
+---------------------+ | IPsec engine |
| Kernel-space |<---------->| (and databases)|
| Protocols | | |
| Relevant for | +----------------+
| MOBIKE (e.g., ND, | ^
| DNA, L2) |<---------------+ |
+---------------------+ v v
|| +----------------+
\/ | |
Inter- =====================>| IP forwarding, |
faces <=====================|input and output|
| |