draft-ietf-mobike-design-02.txt   draft-ietf-mobike-design-03.txt 
IKEv2 Mobility and Multihoming T. Kivinen IKEv2 Mobility and Multihoming T. Kivinen
(mobike) Safenet, Inc. (mobike) Safenet, Inc.
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: August 24, 2005 Siemens Expires: January 19, 2006 Siemens
February 20, 2005 July 18, 2005
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-02.txt draft-ietf-mobike-design-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) working group is The MOBIKE (IKEv2 Mobility and Multihoming) working group is
developing protocol extensions to the Internet Key Exchange Protocol developing extensions for the Internet Key Exchange Protocol version
version 2 (IKEv2) to enable its use in the context where there are 2 (IKEv2). These extensions should enable an efficient management of
multiple IP addresses per host or where IP addresses of an IPsec host IKE and IPsec Security Associations when a host possesses multiple IP
change over time (for example, due to mobility). 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 This document discusses the involved network entities, and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols and the rest of the network. Design decisions for other protocols. Design decisions for the MOBIKE protocol,
the base MOBIKE protocol, background information and discussions background information and discussions within the working group are
within the working group are recorded. recorded.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7
3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8
3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13
5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13
5.2 Changing a Preferred Address and Multihoming Support . . . 13 5.2 Changing a Preferred Address and Multi-homing Support . . 13
5.2.1 Storing a single or multiple addresses . . . . . . . . 14 5.2.1 Storing a single or multiple addresses . . . . . . . . 14
5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16
5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17
5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Changing addresses or changing the paths . . . . . . . . . 19 5.5 Changing addresses or changing the paths . . . . . . . . . 20
5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20
5.7 Employing MOBIKE results in other protocols . . . . . . . 22 5.7 Employing MOBIKE results in other protocols . . . . . . . 23
5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 23 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 24
5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 24 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 25
5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25
5.11 Message Representation . . . . . . . . . . . . . . . . . . 25 5.11 Message Representation . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1 Normative references . . . . . . . . . . . . . . . . . . . 32 10.1 Normative references . . . . . . . . . . . . . . . . . . . 32
10.2 Informative References . . . . . . . . . . . . . . . . . . 32 10.2 Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 35
1. Introduction 1. Introduction
IKEv2 is used for performing mutual authentication and establishing The purpose of IKEv2 is to mutually authenticate two hosts, establish
and maintaining IPsec security associations (SAs). IKEv2 establishes one or more IPsec Security Associations (SAs) between them, and
both cryptographic state (such as session keys and algorithms) as subsequently manage these SAs (for example, by rekeying or deleting).
well as non-cryptographic information (such as IP addresses). 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.
The current IKEv2 and IPsec documents explicitly say that the IPsec IKEv2 assumes that an IKE SA is created implicitly between the IP
and IKE SAs are created implicitly between the IP address pair used address pair that is used during the protocol execution when
during the protocol execution when establishing the IKEv2 SA. This establishing the IKEv2 SA. This means that, in each host, only one
means that there is only one IP address pair stored for the IKEv2 SA, IP address pair is stored for the IKEv2 SA as part of a single IKEv2
and this single IP address pair is used as an outer endpoint address protocol session, and, for tunnel mode SAs, the hosts places this
for tunnel mode IPsec SAs. After the IKE SA is created there is no single pair in the outer IP headers. Existing documents make no
way to change them. provision to change this pair after an IKE SA is created.
There are scenarios where this IP address might change, even There are scenarios where one or both of the IP addresses of this
frequently. In some cases the problem could be solved by rekeying pair may change during an IPsec session. In principle, the IKE SA
all the IPsec and IKE SAs after the IP address has changed. However, and all corresponding IPsec SAs could be re-established after the IP
this can be problematic, as the device might be too slow to rekey the address has changed. However, this can be problematic, as the device
SAs that often, and other scenarios the rekeying and required IKEv2 might be too slow for this task. Moreover, manual user interaction
authentication might require user interaction (SecurID cards etc). (for example when using SecurID cards) might be required as part of
Due to these reasons, a mechanism to update the IP addresses tied to the IKEv2 authentication procedure. Therefore, an automatic
the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the mechanism is neeed that updates the IP addresses associated with the
problem of the updating the IP addresses stored with IKE SAs and IKE SA and the IPsec SAs. MOBIKE provides such a mechanism.
IPsec SAs.
The charter of the MOBIKE working group requires IKEv2 The work of the MOBIKE working group and therefore this document is
[I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis based on the assumption that the mobility and multi-homing extensions
architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on
developed will use both IKEv2 and RFC2401bis. MOBIKE does not the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis],
support IKEv1 [RFC2409] or the old RFC2401 architecture [RFC2401]. all protocols developed within the MOBIKE working group must be
compatible with both IKEv2 and the architecture described in
RFC2401bis. The document does not aim to neither provide support
IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401].
This document is structured as follows. After introducing some This document is structured as follows. After introducing some
important terms in Section 2 we list a few scenarios in Section 3, to important terms in Section 2 a number of relevant usage scenarios are
illustrate possible deployment environments. MOBIKE depends on discussed in Section 3. Section 4 discusses the interoperation of
information from other sources (e.g., detect an address change) which MOBIKE with other protocols and processes that may run in the local
are discussed in Section 4. Finally, Section 5 discusses design machine. Finally, Section 5 discusses design considerations
considerations effecting the MOBIKE protocol. The document concludes affecting the MOBIKE protocol. The document concludes in Section 6
with security considerations in Section 6. with security considerations.
2. Terminology 2. Terminology
This section introduces some useful terms for a MOBIKE protocol. This section introduces the terminology that is used in this
document.
Peer: Peer:
Within this document we refer to IKEv2 endpoints as peers. A peer A peer is an IKEv2 endpoint. In addition, a peer implements the
implements MOBIKE and therefore IKEv2. MOBIKE extensions, as defined in this and related documents.
Available address: Available address:
An address is said to be available if the following conditions are An address is said to be available if the following conditions are
fulfilled: met:
* The address has been assigned to an interface of the node.
* If the address is an IPv6 address, we additionally require that
(a) the address is valid in the sense of RFC 2461 [RFC2461],
and that (b) the address is not tentative in the sense of RFC
2462 [RFC2462]. In other words, the address assignment is
complete so that communications can be started.
Note this explicitly allows an address to be optimistic in the * The address has been assigned to an interface.
sense of [I-D.ietf-ipv6-optimistic-dad] even though
implementations are probably better off using other addresses * If the address is an IPv6 address, we additionally require (a)
as long as there is an alternative. that the address is valid as defined in RFC 2461 [RFC2461], and
* The address is a global unicast or unique site-local address (b) that the address is not tentative as defined in RFC 2462
[I-D.ietf-ipv6-unique-local-addr]. That is, it is not an IPv6 [RFC2462]. In other words, we require the address assignment
link-local or site-local address. Where IPv4 is considered, it to be complete.
is not an RFC 1918 [RFC1918] address.
* The address and interface is acceptable for use according to a Note that this explicitly allows an address to be optimistic as
local policy. defined in [I-D.ietf-ipv6-optimistic-dad].
This definition is reused from
[I-D.arkko-multi6dt-failure-detection] * If the address is an IPv6 address, it is a global unicast or
unique site-local address, as defined in [I-D.ietf-ipv6-unique-
local-addr]. That is, it is not an IPv6 link-local. Where
IPv4 is considered, it is not an RFC 1918 [RFC1918] address.
* The address and interface is acceptable for sending and
receiving traffic according to a local policy.
This definition is taken from [I-D.arkko-multi6dt-failure-
detection]
. .
Locally Operational Address: Locally Operational Address:
An available address is said to be locally operational when its An address is said to be locally operational if it is available
use is known to be possible locally. This definition is taken and its use is locally known to be possible and permitted. This
from [I-D.arkko-multi6dt-failure-detection]. definition is taken from [I-D.arkko-multi6dt-failure-detection].
Operational address pair: Operational address pair:
A pair of operational addresses are said to be an operational A pair of operational addresses are said to be an operational
address pair, iff bidirectional connectivity can be shown between address pair, if and only if bidirectional connectivity can be
the two addresses. Note that sometimes it is necessary to shown between the two addresses. Note that sometimes it is
consider a 5-tuple when connectivity between two endpoints need to necessary to consider connectivity on a per-flow level between two
be tested. This differentiation might be necessary to address endpoints needs to be tested. This differentiation might be
load balancers, certain Network Address Translation types or necessary to address certain Network Address Translation types or
specific firewalls. This definition is taken from specific firewalls. This definition is taken from [I-D.arkko-
[I-D.arkko-multi6dt-failure-detection] and enhanced to fit the multi6dt-failure-detection] and adapted for the MOBIKE context.
MOBIKE context. Although it is possible to further differentiate Although it is possible to further differentiate unidirectional
unidirectional and bidirectional operational address pairs only and bidirectional operational address pairs, only bidirectional
bidirectional connectivity is relevant for this document and connectivity is relevant to this document and unidirectional
unidirectional connectivity is out of scope. connectivity is out of scope.
Path: Path:
The route taken by the MOBIKE and/or IPsec packets sent via the IP The sequence of routers traversed by the MOBIKE and IPsec packets
address of one peer to a specific destination address of the other exchanged between the two peers. Note that this path may be
peer. Note that the path might be effected not only by the source affected not only by the involved source and destination IP
and destination IP addresses but also by the selected transport addresses, but also by the transport protocol. Since MOBIKE and
protocol and transport protocol identifier. Since MOBIKE and
IPsec packets have a different appearance on the wire they might IPsec packets have a different appearance on the wire they might
be routed along a different path. This definition is taken from be routed along a different path, for example by load balancers.
[RFC2960] and modified to fit the MOBIKE context. This definition is taken from [RFC2960] and adapted to the MOBIKE
context.
Primary Path: Primary Path:
The primary path is the destination and source address that will The sequence of routers traversed by an IP packet that carries the
be put into a packet outbound to the peer by default. This default source and destination addresses is said to be the Primary
definition is taken from [RFC2960] and modified to fit the MOBIKE Path. This definition is taken from [RFC2960] and adapted to the
context. MOBIKE context.
Preferred Address: Preferred Address:
An address on which a peer prefers to receive MOBIKE messages and The IP address of a peer to which MOBIKE and IPsec traffic should
IPsec protected data traffic. A given peer has only one active be sent by default. A given peer has only one active preferred
preferred address at a given point in time (ignoring the small address at a given point in time, except for the small time period
time period where it needs to switch from the old preferred where it switches from an old to a new preferred address. This
address to a new preferred address). This definition is taken definition is taken from [I-D.ietf-hip-mm] and adapted to the
from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context. MOBIKE context.
Peer Address Set: Peer Address Set:
We denote the two peers in this Mobike session by peer A and peer We denote the two peers of a MOBIKE session by peer A and peer B.
B. A peer address set is a subset of locally operational A peer address set is the subset of locally operational addresses
addresses of peer A that are sent to peer B. A policy available of peer A that is sent to peer B. A policy available at peer A
at peer A indicates which addresses to include in the peer address indicates which addresses are included in the peer address set.
set. Such a policy might be impacted by manual configuration or Such a policy might be created either manually or automatically
by interaction with other protocols that indicate new available through interaction with other mechanisms that indicate new
addresses. available addresses.
Terminology for different NAT types, such as Full Cone, Restricted Terminology regarding NAT types (e.g. Full Cone, Restricted Cone,
Cone, Port Restricted Cone and Symmetric, can be found in Section 5 Port Restricted Cone and Symmetric), can be found in Section 5 of
of [RFC3489]. For mobility related terminology, such as [RFC3489]. For mobility related terminology (e.g. Make-before-break
Make-before-break or Break-before-make see [RFC3753]. or Break-before-make) see [RFC3753].
3. Scenarios 3. Scenarios
The MOBIKE protocol can be used in different scenarios. Three of In this section we discuss three typical usage scenarios for the
them are discussed below. MOBIKE protocol.
3.1 Mobility Scenario 3.1 Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile Figure 1 shows a break-before-make mobility scenario where a mobile
node attaches to, for example a wireless LAN, to obtain connectivity node changes its point of network attachment. Prior to the change,
to some security gateway. This security gateway might connect the the mobile node had established an IPsec connection with a security
mobile node to a corporate network, to a 3G network or to some other gateway which offered, for example, access to a corporate network.
network. The initial IKEv2 exchange takes place along the path The IKEv2 exchange that facilitated the set up of the IPsec SA(s)
labeled as 'old path' from the MN using its old IP address via the took place over the path labeled as 'old path'. The involved packets
old access router (OAR) towards the security gateway (GW). The IPsec carried the MN's "old" IP address and were forwarded by the "old"
tunnel mode terminates there but the decapsulated data packet will access router (OAR) to the security gateway (GW).
typically address another destination. Since only MOBIKE
communication from the MN to the gateway is relevant for this
discussion the end-to-end communication between the MN and some
destination is not shown in Figure 1.
When the MN moves to a new network and obtains a new IP address from When the MN changes its point of network attachment, it obtains a new
a new access router (NAR) it is the responsibility of MOBIKE to avoid IP address using statefu address configuration techniques or via the
restarting the IKEv2 exchange from scratch. As a result, a protocol stateless address autoconfiguration mechanism. The goal of MOBIKE,
exchange, denoted by 'MOBIKE Address Update' , will perform the in this scenario, is to enable the MN and the GW to continue using
necessary state update. 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 mobility scenario the MN obtains a Note that in a break-before-make scenario the MN obtains the new IP
new IP address after reachability to the old IP address has been address after it can no longer be reached at the old IP address. In
lost. MOBIKE is also assumed to work in scenarios where the mobile a make-before-break scenario, the MN is, for a given period of time,
node is able to establish connectivity with the new IP address while reachable at both the old and the new IP address. MOBIKE should work
still being reachable at the old IP address. in both the above scenarios.
(Initial IKEv2 Exchange) (Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v +--+ +---+ Old path V v
. +----+ v>>>>> +--+ . +----+ v>>>>> +--+
.move | R | -------> |GW| .move | R | -------> |GW|
. | | >>>>> | | . | | >>>>> | |
v +----+ ^ +--+ v +----+ ^ +--+
skipping to change at page 8, line 28 skipping to change at page 8, line 28
(MOBIKE Address Update) (MOBIKE Address Update)
---> = Path taken by data packets ---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE) >>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement ...> = End host movement
Figure 1: Mobility Scenario Figure 1: Mobility Scenario
3.2 Multihoming Scenario 3.2 Multihoming Scenario
Another scenario where MOBIKE might be used is between two peers Another MOBIKE usage scenario is depicted in Figure 2. In this
equipped with multiple interfaces (and multiple IP addresses). scenario, the MOBIKE peers are equipped with multiple interfaces (and
Figure 2 shows two such multi-homed peers. Peer A has two interface multiple IP addresses). Peer A has two interface cards with two IP
cards with two IP addresses IP_A1 and IP_A2. Additionally, Peer B addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
also has two IP addresses, IP_B1 and IP_B2. Each peer selects one of and IP_B2. Each peer selects one of its IP addresses as the
its IP addresses as the preferred address which will subsequently be preferred address which is used for subsequent communication.
used for communication. Various reasons, such as problems with the Various reasons, (e.g hardware or network link failures), may require
interface card, might require a peer to switch from one IP address to a peer to switch from one interface to another.
the other one.
+------------+ +------------+ +------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B | | Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| | | |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 | | IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | | | | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 | | IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
skipping to change at page 9, line 19 skipping to change at page 9, line 4
| | | | | | | | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 | | IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets ---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE) >>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network ***> = Potential future path through the network
(if Peer A and Peer B change their preferred (if Peer A and Peer B change their preferred
address) address)
Figure 2: Multihoming Scenario Figure 2: Multihoming Scenario
Note that MOBIKE does not support load balancing between multiple IP Note that MOBIKE does not aim to support load balancing between
addresses. That is, each peer uses only one of the available IP multiple IP addresses. That is, each peer uses only one of the
addresses at a given point in time. available IP addresses at a given point in time.
3.3 Multihomed Laptop Scenario 3.3 Multihomed Laptop Scenario
In the multihomed laptop scenario we consider a laptop, which has The third scenario we consider is about a laptop, which has multiple
multiple interface cards and therefore several ways to connect to a interface cards and therefore several ways to connect to the network.
network. It might for example have a fixed Ethernet, WLAN, GPRS, It may for example have a fixed Ethernet card, a WLAN interface, a
Bluetooth or USB hardware in order to send IP packets. A number of GPRS adaptor, a Bluetooth interface or USB hardware. Not all
interfaces might connected to a network over time depending on a interfaces are connected to the network at all times for a number of
number of reasons (e.g., cost, availability of certain link layer reasons (e.g., cost, availability of certain link layer technologies,
technologies, user convenience). Note that a policy for selecting a user convenience). The mechanism that determines which interfaces
network interface based on cost, etc. is out of scope for MOBIKE. are connected to the network at any given point in time is outside
For example, the user can disconnect himself from the fixed Ethernet, the scope of the MOBIKE protocol and, as such, this document.
use the office WLAN, and then later leave the office and start using However, as the laptop changes its point of attachment to the
GPRS during the trip home. At home he might use WLAN. At a certain network, the set of IP addresses under which the laptop is reachable,
point in time multiple interfaces might be connected. As such, the changes too.
laptop is a multihomed device. In any case, the IP address of the
individual interfaces are subject to change.
The user desires to keep the established IKE-SA and IPsec SAs alive Even if IP addresses change due to interface switching or mobility,
all the time without the need to re-run the initial IKEv2 exchange the IP address obtained via the configuration payloads within IKEv2
which could require user interaction as part of the authentication remain unaffected. The IP address obtained via the IKEv2
process. Furthermore, even if IP addresses change due to interface configuration payloads allow the configuration of the inner IP
switching or mobility, the IP source and destination address obtained address of the IPsec tunnel. As such, applications might not detect
via the configuration payloads within IKEv2 and used inside the IPsec any change at all.
tunnel remains unaffected, i.e., applications might not detect any
change at all.
4. Framework 4. Framework
The working group will develop a MOBIKE protocol which needs to The working group will develop a MOBIKE protocol which needs to
perform the following functionality: perform the following operations:
o Ability to inform the other peer about the peer address set
o Ability to inform the other peer about the preferred address o inform the other peer about the peer address set
o Ability to test connectivity along a path and thereby to detect an
outage situation o inform the other peer about the preferred address
o Ability to change the preferred address
o Ability to change the peer address set o test connectivity along a path and thereby to detect an outage
situation
o change the preferred address
o change the peer address set
o Ability to deal with Network Address Translation devices o Ability to deal with Network Address Translation devices
The technical details of these functions are discussed below. The technical details of these functions are discussed below.
Although the interaction with other protocols is important for MOBIKE Although MOBIKE will have to interact with other mechanisms, the
to operate correctly the working group is chartered to leave this working group is chartered to leave this aspect outside the scope.
aspect outside the scope.
When a MOBIKE peer initiates a protocol exchange with its MOBIKE peer When a MOBIKE peer initiates a protocol exchange it needs to define a
it needs to define a peer address set based on the available peer address set based on the IP addresses available to it. The peer
addresses. It might want to make this peer address set available to may want to make this set available to the other peer. The IKEv2
the other peer. The Initiator does not need to explicitly indicate Initiator does not need to indicate which of the addresses in the
its preferred address since it is already using its preferred peer address set is its preferred address. This is because the
address. The outgoing IKEv2 and MOBIKE messages use this preferred Initiator has to place its preferred address into the source IP
address as the source IP address and the MOBIKE peer expects incoming address field of the IP header with the initial message exchange.
signaling messages to be sent to this address. Interaction with Additionally, the Initiator expects incoming signaling messages to
other protocols at the MOBIKE host is required to build the peer arrive at this address. The peer address set and the preferred
address set and the preferred address. In some cases the peer address are defined based on interaction with other components within
address set is available before the initial protocol exchange and a host. In some cases, the peer address set may be available before
does not change during the lifetime of the IKE-SA. The preferred the initial protocol exchange and does not change during the lifetime
address might change due to policy reasons. Section 3 describes of the IKE-SA. The preferred address might change due to policy
three scenarios in which the peer address set is modified (by adding reasons. Section 3 describes three scenarios in which the peer
or deleting addresses). In these scenarios the preferred address address set is modified (by adding or deleting addresses). In these
needs to be changed as well. scenarios the preferred address may change as well.
Modifying the peer address set or changing the preferred address is A modification of the peer address set or a change of the preferred
effected by the host's local policy and by the interaction with other address typically is the result of the MOBIKE peer's local policy and
protocols (such as DHCP or IPv6 Neighbor Discovery). by the interaction with other protocols (such as DHCP or IPv6
Neighbor Discovery).
Figure 3 shows an example protocol interaction at a MOBIKE peer. Figure 3 shows an example protocol interaction between a pair of
MOBIKE interacts with the IPsec engine using the PF_KEY interface MOBIKE peers. MOBIKE interacts with the IPsec engine using the
[RFC2367] to create entries in the Security Association and Security PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create
Policy Databases. The IPsec engine might also interact with IKEv2 entries in the Security Association (SAD) and Security Policy
and MOBIKE. Established state at the IPsec databases has an impact Databases (SPD). The IPsec engine may also interact with IKEv2 and
on the incoming and outgoing data traffic. MOBIKE receives MOBIKE daemon using this API. The content of the Security Policy and
information from other protocols running in both kernel-mode and Security Association Databases determines what traffic is protected
user-mode, as previously mentioned. Information relevant for MOBIKE with IPsec in which fashion. MOBIKE, on the other hand, receives
is stored in a database, referred as Trigger database, that guides information from a number of sources that may run both in kernel-mode
MOBIKE in its decisions regarding the available addresses, peer and in user-mode. Information relevant for MOBIKE might be stored in
address set, and the preferred address. Policies might affect the a database. The contents of such a database, along with the
selection process. occurrence of events of which the MOBIKE process is notified, form
the basis on which MOBIKE decides regarding the set of available
addresses, the peer address set, and the preferred address. Policies
may also affect the selection process.
Building and maintaining a peer address set and selecting or changing The a peer address set and the preferred address needs to be
a preferred address based on locally available information is, available to the other peer. In order to address certain failure
however, insufficient. This information needs to be available to the cases, MOBIKE should perform connectivity tests between the peers
other peer and in order to address various failure cases it is (potentially over a number of different paths). Although a number of
necessary to test connectivity along a path. A number of address address pairs may be available for such tests, the most important is
pairs might be available for connectivity tests but most important the pair (source address, destination address) of the primary path.
are the source and the destination IP address of the primary path This is because this pair is selected for sending and receiving
since these addresses are selected for sending and receiving MOBIKE MOBIKE signaling and IPsec traffic. If a problem along this primary
signaling messages and for sending and receiving IPsec protected data path is detected (e.g., due to a router failure) it is necessary to
traffic. If a problem along this primary path is detected (e.g., due switch to a new primary path. In order to be able to do so quickly,
to a router failure) it is necessary to switch to the new primary it may be helpful to perform connectivity tests of other paths
path. Optionally, periodic testing of other paths might be useful to periodically. Such a technique would also help in identifying
determine when a disconnected path becomes operational. previously disconnected paths that become operational.
+-------------+ +---------+ +-------------+ +---------+
|User-space | | MOBIKE | |User-space | | MOBIKE |
|Protocols | +-->>| Daemon | |Protocols | +-->>| Daemon |
|relevant for | | | | |relevant for | | | |
|MOBIKE | | +---------+ |MOBIKE | | +---------+
+-------------+ | ^ +-------------+ | ^
User Space ^ | ^ User Space ^ | ^
++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
Kernel Space v | v Kernel Space v | v
skipping to change at page 12, line 39 skipping to change at page 12, line 39
f | Packet +<--------------------------+ | Interface | f f | Packet +<--------------------------+ | Interface | f
==a>|Processing|===============================| Processing |=a> ==a>|Processing|===============================| Processing |=a>
c | | | | c c | | | | c
e +----------+ +------------+ e e +----------+ +------------+ e
s s s s
===> = IP packets arriving/leaving a MOBIKE node ===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations <-> = control and configuration operations
Figure 3: Framework Figure 3: Framework
Please note that Figure 3 is only one way of implementing MOBIKE. Please note that Figure 3 illustrates an example of how a MOBIKE
Hence, it serves illustrative purposes only. implementation could work. Hence, it serves illustrative purposes
only.
Extensions of the PF_KEY interface required by MOBIKE are also within Extensions of the PF_KEY interface required by MOBIKE are also within
the scope of the working group. Finally, optimizations in wireless the scope of the working group. Finally, certain optimizations for
environment will also be covered. wireless environments are also covered.
5. Design Considerations 5. Design Considerations
This section discusses aspects affecting the design of the MOBIKE This section discusses aspects affecting the design of the MOBIKE
protocol. protocol.
5.1 Indicating Support for MOBIKE 5.1 Indicating Support for MOBIKE
In order for MOBIKE to function correctly, both peers must implement In order for MOBIKE to function, both peers must implement the MOBIKE
this extension. We propose extensions to IKEv2 described below for extension of IKEv2. If one or none of the peers supports MOBIKE,
MOBIKE support. If only one peer supports MOBIKE, then the peers then, whenever an IP address changes, IKEv2 will have to be re-run in
will just run IKEv2. Specifically, a node needs to be able to order to create a new IKE SA and the respective IPsec SAs. In
guarantee that its address change messages are understood by its MOBIKE, a peer needs to be confident that its address change messages
corresponding peer. Otherwise an address change may render the are understood by the other peer. If these messages are not
connection useless, and it is important that both sides realize this understood, it is possible that connectivity between the peers is
as early as possible. lost.
Ensuring that the messages are understood can in be arranged either One way to ensure that a peer receives feedback on whether or not its
by marking some IKEv2 payloads critical so that they are either messages are understood by the other peer, is by using IKEv2
processed or an error message is returned, by using Vendor ID messaging for MOBIKE and to mark some messages as "critical".
payloads or via a Notify. According to the IKEv2 specification, such messages either have to be
understood by the receiver, or an error message has to be returned to
the sender.
The first solution approach is to use Vendor ID payloads during the A second way to ensure receipt of the above-mentioned feedback is by
initial IKEv2 exchange using a specific string denoting MOBIKE to using Vendor ID payloads that are exchanged during the initial IKEv2
signal the support of the MOBIKE protocol. This ensures that in all exchange. These payloads would then indicate whether or not a given
cases a MOBIKE capable node knows whether its peer supports MOBIKE or peer supports the MOBIKE protocol.
not.
The second solution approach uses the Notify payload which is also A third approach would use the Notify payload which is also used for
used for NAT detection (via NAT_DETECTION_SOURCE_IP and NAT detection (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP). NAT_DETECTION_DESTINATION_IP payloads).
Both a Vendor ID and a Notify payload might be used to indicate the Both a Vendor ID and a Notify payload may be used to indicate the
support of certain extensions. support of certain extensions.
Note that the node could also attempt MOBIKE opportunistically with Note that a MOBIKE peer could also attempt to execute MOBIKE
the critical bit set when an address change has occurred. The opportunistically with the critical bit set when an address change
drawback of this approach is, however, that the an unnecessary MOBIKE has occurred. The drawback of this approach is, however, that an
message exchange is introduced. unnecessary MOBIKE message exchange is introduced.
Although Vendor ID payloads and Notifications are technically Although Vendor ID payloads and Notifications are technically
equivalent Notifications are already used in IKEv2 as a capability equivalent, Notifications are already used in IKEv2 as a capability
negotiation mechanism and is therefore the preferred mechanism. negotiation mechanism. Hence, Notifications and Vendor ID payloads
are the preferred mechanisms.
5.2 Changing a Preferred Address and Multihoming Support
From MOBIKE's point of view multihoming support is integrated by 5.2 Changing a Preferred Address and Multi-homing Support
supporting a peer address set rather than a single address and
protocol mechanisms to change to use a new preferred IP address.
From a protocol point of view each peer needs to learn the preferred From MOBIKE's point of view, support for multi-homing is inherently
address and the peer address set either implicitly or explicitly. provided by the fact that it manages a set of peer addresses, rather
than a single address. Further, MOBIKE provides mechanisms to change
a peer's preferred IP address. Each peer needs to learn the
preferred address and the peer address set.
5.2.1 Storing a single or multiple addresses 5.2.1 Storing a single or multiple addresses
One design decision is whether an IKE-SA should store a single IP One design decision is whether an IKE-SA should be associated with a
address or multiple IP addresses as part of the peer address set. single IP address or multiple IP addresses. One option is that a
One option is that the other end can provide a list of addresses peer can provide a list of addresses to its counterpart which can
which can be used as destination addresses. MOBIKE does not support then be used as destination addresses.
load balancing, i.e., only one IP address is set to a preferred
address at a time and changing the preferred address typically Note that MOBIKE does not support load balancing, i.e., only one IP
requires some MOBIKE signaling. address is set to a preferred address at a time and changing the
preferred address typically requires some MOBIKE signaling.
Another option is to only communicate one address to the other peer Another option is to only communicate one address to the other peer
and both peers only use that address when communicating. If this and both peers only use that address when communicating. If this
preferred address cannot be used anymore then an address update is address cannot be used anymore then an address update is sent to the
sent to the other peer changing the preferred address. other peer that changes the preferred address.
If peer A provides a peer address set with multiple IP addresses then Alternatively, if peer A, for example,provides a peer address set
peer B can recover from a failure of the preferred address on its with multiple IP addresses then peer B can recover from a failure of
own, meaning that when it detects that the primary path does not work the preferred address without further communication with peer A. That
anymore it can either switch to a new preferred address locally is, if it detects that the primary path does not work anymore it can
(i.e., causing the source IP address of outgoing MOBIKE messages to either switch to a new preferred address locally (i.e., changing the
have a non-preferred address) or try an IP address from A's peer source IP address of outgoing MOBIKE messages) or to try an IP
address set. If peer B only received a single IP address as the A's address from A's peer address set (i.e., changing the destination
peer address set then peer B can only change its own preferred address). If peer B only received a single IP address from peer A
address. The other end has to wait for an address update from peer A for A then peer B can only change its own preferred address. Peer B
with a new IP address in order to fix the problem. The main would have to wait for an address update from peer A with a new IP
advantage about using a single IP address for the remote host is that address in order to fix the problem.
it makes retransmission easy, and it also simplifies the recovery
procedure. The peer, whose IP address changed, must start the
recovery process and send the new IP address to the other peer.
Failures along the path are not well covered with advertising a
single IP address.
The single IP address approach will not work if both peers happen to The main advantage of storing only a single IP address for the remote
loose their IP address at the same time (due to, say, the failure of peer is that it makes retransmission handling easier. Moreover, it
one of the links that both nodes are connected to). It may also simplifies the recovery procedure. The peer whose IP address changed
require the IKEv2 window size to be larger than 1, especially if only must start the recovery process and send the new IP address to the
direct indications are used. This is because the host needs to be other peer. However, connectivity failures along the path are not
able to send the IP address change notifications before it can switch well addressed with advertising a single IP address.
to another address, and depending on the return routability checks,
retransmissions policies etc, it might be hard to make the protocol
such that it works with window size of 1 too. Furthermore, the
single IP address approach does not really benefit much from indirect
indications as the peer receiving these indications might not be able
to fix the situation by itself (e.g., even if a peer receives an ICMP
host unreachable message for the old IP address, it cannot try other
IP addresses, since they are unknown).
The problems with IP address lists are mostly in its complexity. The single IP address approach does not work if both peers change
Notification and recovery processes are more complex. Both ends can their IP addresses at the same time, for example if both hosts move
recover from the IP address changes. However, both peers should not simultaneously, even though multiple addresses are available to the
attempt to recover at the same time or nearly the same time as it two peers. The IKEv2 implementation might also require window size
could cause them to lose connectivity. The MOBIKE protocol is to be larger than 1 because the MOBIKE peer needs to be able to send
the IP address change notifications before it switches to another
address. Depending on the occurrence of return routability checks,
retransmissions policies and similar message exchanges a window size
larger than 1 might be required to deal with more than one pending
response at the same time. Furthermore, the single IP address
approach does not really benefit much from indirect indications as
the peer receiving these indications might not be able to fix the
situation by itself (e.g., even if a peer receives an ICMP host
unreachable message for the old IP address, it cannot try another IP
address, since it does not know any).
The problems with IP address lists lie mostly in their complexity.
Notification and recovery processes are more complicated. Both ends
can recover from the IP address changes. However, both peers should
not attempt to recover at the same time or nearly the same time as
this could cause them to lose connectivity. The MOBIKE protocol is
required to prevent this. required to prevent this.
The previous discussion is independent of the question of how many The previous discussion is independent of the question of how many
addresses to send in a single MOBIKE message. A MOBIKE message might addresses to send in a single MOBIKE message. A MOBIKE message might
be able to carry more than one IP address (with the IP address list be able to carry more than one IP address (with the IP address list
approach) or a single address only. The latter approach has the approach) or a single address only. A NAT does not change addresses
advantage of dealing with NAT traversal in a proper fashion. A NAT carried inside the MOBIKE message but it can change IP address (and
cannot change addresses carried inside the MOBIKE message but it can transport layer addresses) in the IP header and Transport Protocol
change IP address (and transport layer addresses) in the IP header header (if NAT traversal is enabled as part of configuration or
and Transport Protocol header (if NAT traversal is enabled). dynamically through the NAT discovery mechanism. Furthermore, a
Furthermore, a MOBIKE message carrying the peer address set could be MOBIKE message carrying the peer address set could be idempotent
idempotent (i.e., always resending the full address list) or the (i.e., always resending the full address list) or the protocol may
protocol may allow add/delete operations to be specified. allow add/delete operations to be specified. [I-D.dupont-ikev2-
[I-D.dupont-ikev2-addrmgmt], for example, offers an approach which addrmgmt], for example, offers an approach which defines add/delete
defines add/delete operations. The same is true for the dynamic operations. The same is true for the dynamic address reconfiguration
address reconfiguration extension for SCTP extension for SCTP [I-D.ietf-tsvwg-addip-sctp].
[I-D.ietf-tsvwg-addip-sctp].
5.2.2 Indirect or Direct Indication 5.2.2 Indirect or Direct Indication
An indication to change the preferred IP address might be either An indication to change the preferred IP address might be either
direct or indirect. direct or indirect.
Direct indication: Direct indication:
A direct indication means that the other peer will send an message A direct indication means that the other peer will send an message
with the address change. Such a message can, for example, with the address change. This can, for example, be accomplished
accomplished by having MOBIKE sending an authenticated address by having MOBIKE sending an authenticated address update
update notification with a different preferred address. notification with a different preferred address.
Indirect indication: Indirect indication:
An indirect indication to change the preferred address can be An indirect indication to change the preferred address can be
obtained by observing the environment. An indirect indication obtained by observing the environment. An indirect indication
might, for example, be be the receipt of an ICMP message or might, for example, be the receipt of an ICMP message or
information of a link failure. This information should be seen as information about a link failure. This information should be seen
a hint and might not directly cause any changes to the preferred as a hint and should not cause a change of the remote peer's
address. Depending on the local policy MOBIKE might decide to preferred address. Depending on the local policy, MOBIKE may
perform a dead-peer detection exchange for the preferred address decide to perform a dead-peer detection exchange for the preferred
pair (or another address pair from the peer address set). When a address pair (or another address pair from the peer address set).
peer detects that the other end started to use a different source When a peer detects that the other end started to use a different
IP address than before, it might want to authorize the new source IP address than before, it might want to authorize the new
preferred address (if not already authorized). A peer might also preferred address (if not already authorized). Authorization aims
start a connectivity test of this particular address. If a to ensure that a particular peer is allowed to use the indicated
bidirectionally operational address pair is selected then MOBIKE address. Claiming to be at an arbitrary address without
needs to communicate this new preferred address to its remote performing a return-routability test or without verifying that the
peer. IP address is listed within a certificate opens the door for
various denial of service attacks. Hence a peer may also start a
connectivity test of this particular address.
MOBIKE will utilize both mechanisms, direct and indirect indications, If more information is available to the MOBIKE daemon then a more
to make a more intelligent decision which address pair to select as intelligent decision regarding the selection of a new primary path
the preferred address. The more information will be available to can be made.
MOBIKE the faster a new primary path can be selected among the
available candiates.
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection
This section discusses the suitability of the IKEv2 dead-peer This section discusses the suitability of the IKEv2 dead-peer
detection (DPD) mechanism for connectivity tests between address detection (DPD) mechanism for connectivity tests between address
pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but
it needs to be investigated whether it can be used for MOBIKE it needs to be investigated whether it can be used for MOBIKE
purposes as well. purposes as well.
The IKEv2 DPD mechanism is done by sending an empty informational The IKEv2 DPD mechanism involves sending an empty informational
exchange packet to the other peer, in which case the other end will exchange packet to a given address of the remote peer. On receipt,
respond with an acknowledgement. If no acknowledgement is received the remote peer responds with an acknowledgement. If no
after a certain timeout (and after couple of retransmissions), the acknowledgement is received after a certain timeout period (and after
other peer is considered to be not reachable. Note that the receipt couple of retransmissions), the remote peer is considered to be not
of IPsec protected data traffic is also a guarantee that the other reachable at the address in question. On the other hand, receipt of
peer is alive. IPsec protected acknowledgement is a guarantee that the other peer is
reachable at the address in question.
When reusing dead-peer detection in MOBIKE for connectivity tests it When reusing dead-peer detection in MOBIKE for connectivity tests it
seems to be reasonable to try other IP addresses (if they are seems to be reasonable to try other IP addresses (if they are
available) in case of an unsuccessful connectivity test for a given available) in case of an unsuccessful connectivity test for a given
address pair. Dead-peer detection messages using a different address address pair. Dead-peer detection messages using a different address
pair should use the same message-id as the original dead-peer pair should use the same message-id as the original dead-peer
detection message (i.e. they are simply retransmissions of the detection message (i.e. they are simply retransmissions of the dead-
dead-peer detection packet using different destination IP address). peer detection packet using different destination IP address). If
If different message-id is used then it violates constraints placed different message-id is used then it violates constraints placed by
by the IKEv2 specification on the DPD message with regard to the the IKEv2 specification on the DPD message with regard to the
mandatory ACK for each message-id, causing the IKEv2 SA to be mandatory ACK for each message-id, causing the IKEv2 SA to be
deleted. deleted.
If MOBIKE strictly follows the guidelines of the dead-peer detection If MOBIKE strictly follows the guidelines of the dead-peer detection
mechanism in IKEv2 then an IKE-SA should be marked as dead and mechanism in IKEv2 then an IKE-SA should be marked as dead and
deleted if the connectivity test for all address pairs fails. Note deleted if the connectivity test for all available address pairs
that this is not in-line with the approach used, for example, in SCTP fails. Note that this is not in-line with the approach used, for
where a failed connectivity test for an address does not lead to (a) example, in SCTP where a failed connectivity test for an address does
the IP address or IP address pair to be marked as dead and (b) delete not lead to (a) the IP address or IP address pair to be marked as
state. Connectivity tests will be continued for the address pairs in dead and (b) delete state. Connectivity tests will be continued for
hope that the problem will recover soon. the address pairs in hope that the problem will recover soon. This
comparison with SCTP aims to point at another IETF protocol that aims
Note that as IKEv2 implementations might have window size of 1, which to address the multi-homing problem (although with a different scope
prevents it from initiating a dead-peer detection exchange while and a different layer).
doing another exchange. As a result, all other exchanges experience
the identical retransmission policy as used for the dead-peer
detection.
The dead-peer detection for the other IP address pairs can also be Note that IKEv2 implementations may have a window size of 1, and
executed simultaneously (with a window size larger than 1), meaning therefore be unable to initiate a dead-peer detection exchange while
that after the initial timeout of the preferred address expires, we another exchange is pending. As a result, all other exchanges are
send packets simultaneously to all other address pairs. It is subject to an identical retransmission policy as used for the dead-
necessary to differentiate individual acknowledgement messages in peer detection. To use a different policy for different message
order to determine which address pair is operational. Therefore the types seems to be reasonable.
source IP address of the acknowledgement should match the destination
IP towards the message that was previously sent.
Also the other peer is most likely going to reply only to the first The dead-peer detection mechanism for the other IP address pairs can
packet it receives, and that first packet might not be the best (by also be executed simultaneously if the window size larger than 1,
whatever criteria) address pair. The reason the other peer is only meaning that after the initial timeout period of the preferred
responding to the first packet it receives is that implementations address expires, DPD packets are sent simultaneously to all other
should not send retransmissions if they have just sent out an address pairs. It is necessary to differentiate acknowledgement
identical response message. This is to protect the packet messages in order to determine which address pair is operational.
multiplication problem, which can happen if some node in the network The source IP address of the acknowledgement can be used for this
queues up packets and then sends them to the destination. If the purpose.
destination were to reply to all of them then the other end will
again see multiple packets, and will reply to all of them, etc.
The protocol should also be nice to the network, meaning, that when The protocol should also be nice to the network, meaning, that when
some core router link goes down, and a large number of MOBIKE clients some core link goes down, and a large number of MOBIKE clients notice
notice it, they should not start sending a large number of messages this, they should not start sending a large number of messages while
while trying to recover from the problem. This might be especially trying to recover from the problem. This may be particularly
bad because packets are dropped because of the congested network. If unfortunate because packets may be dropped because of congestion in
MOBIKE clients simultaneously try to test all possible address pairs the first place. If MOBIKE clients simultaneously try to test all
by executing connectivity tests then the congestion problem only gets possible address pairs by executing connectivity tests then the
worse. congestion problem only gets worse.
Also note that the IKEv2 dead-peer detection is not sufficient for Also note that the IKEv2 dead-peer detection is not sufficient for
the return routability check. See Section 5.6 for more information. the return routability check. See Section 5.6 for more information.
5.3 Simultaneous Movements 5.3 Simultaneous Movements
MOBIKE does not aim to provide a full mobility solution which allows MOBIKE does not aim to provide a mobility solution that allows
simultaneous movements. Instead, the MOBIKE working group focuses on simultaneous movements. Instead, the MOBIKE working group focuses on
selected scenarios as described in Section 3. Some of the scenarios selected scenarios as described in Section 3. Some of the scenarios
assume that one peer has a fixed set of addresses (from which some assume that one peer has a fixed set of addresses (from which some
subset might be in use). Thus it cannot move to the address unknown subset might be in use). Thus it cannot move to an address that is
to the other peer. Situations in which both peers move and the unknown to the other peer. Situations in which both peers move
movement notifications cannot reach the other peer are outside the simultaneously are outside the scope of the MOBIKE WG. MOBIKE has
scope of the MOBIKE WG. MOBIKE has not being chartered to deal with not been chartered to deal with the rendezvous problem, or with the
the rendezvous problem, or with the introduction of any new entities introduction of new entities in the network.
in the network.
Note that if only a single address is stored in the peer address set Note that if only a single address is stored in the peer address set
(instead of an address list) we might end up in the case where it (instead of an address list) we might end up in the case where it
seems that both peers changed their addresses at the same time. This seems that both peers changed their addresses at the same time (e.g.,
is something that the protocol must deal with. if both nodes change their addresses at the same time). This is
something that the MOBIKE protocol must deal with.
Three cases can be differentiated: Three cases can be differentiated:
o Two mobile nodes obtain a new address at the same time, and then o Two mobile nodes obtain a new address at the same time, and then
being unable to tell each other where they are (in a being unable to tell each other where they are (in a break-before-
break-before-make scenario). This problem is called the make scenario). This problem is called the rendezvous problem,
rendezvous problem, and is traditionally solved by introducing and is traditionally solved by introducing another third entity,
another third entity, for example, the home agents (in Mobile for example, the home agents (in Mobile IPv4/IPv6) or forwarding
IPv4/IPv6) or forwarding agents (in Host Identity Protocol). agents (in the Host Identity Protocol). Essentially, solving this
Essentially, solving this problem requires the existence of a problem requires the existence of additional infrastructure nodes.
stable infrastructure node somewhere.
o Simultaneous changes to addresses such that at least one of the o Simultaneous changes to addresses such that at least one of the
new addresses is known to the other peer before the change new addresses is known to the other peer before the change
occurred. occurred.
o No simultaneous changes at all. o No simultaneous changes at all.
5.4 NAT Traversal 5.4 NAT Traversal
IKEv2 has support of legacy NAT traversal built-in. This feature is IKEv2 supports legacy NAT traversal. This feature is known as NAT-T
known as NAT-T which allows IKEv2 to work even if a NAT along the which allows IKEv2 to work even if a NAT along the path between the
path between the Initiator and the Responder modified the source and Initiator and the Responder modifies the source and possibly the
possibly the destination IP address. With NAPT even the transport destination IP address. With NAPT even the transport protocol
protocol identifiers are modified (which then requires UDP identifiers are modified (which then requires UDP encapsulation for
encapsulation for subsequent IPsec protected data traffic). exchanged IPsec protected data traffic). Therefore, the MOBIKE
Therefore, the required IP address information is taken from the IP daemon needs to obtain to required IP address informationfrom the IP
header (if a NAT was detected who rewrote IP header information) header (if a NAT was detected that modified the IP header) rather
rather than from the protected payload. This problem is not new and than from the protected payload. This problem is not new and is an
was discovered during the design of mobility protocol where the only issues of every mobility protocol where the most important
valuable information is IP address information. information exchanged is the IP address .
One of the goals in the MOBIKE protocol is to securely exchange one One of the goals in the MOBIKE protocol is to securely exchange one
or more addresses of the peer address set and to securely set the or more addresses of the peer address set and to securely set the
primary address. If no other protocol is used to securely retrieve primary address. If no other protocol is used to securely retrieve
the IP address and port information allocated by the NAT then it is the IP address and port information allocated by the NAT then it is
not possible to tackle all attacks against MOBIKE. Various solution not possible to tackle all attacks against MOBIKE. Section 6
approaches have been presented: discusses this aspect in more detail. Various approaches to solve
the problem have been presented:
o Securely retrieving IP address and port information allocated by o Securely retrieving IP address and port information allocated by
the NAT using a protocol different from MOBIKE. This approach is the NAT using a protocol different from MOBIKE. This approach is
outside the scope of the MOBIKE working group since other working outside the scope of the MOBIKE working group since other working
groups, such as MIDCOM and NSIS, already deal with this problem. groups, such as MIDCOM and NSIS, already deal with this problem.
The MOBIKE protocol can benefit from the interaction with these The MOBIKE protocol can benefit from the interaction with these
protocols. protocols but the interaction with these protocols it outside the
scope of this document.
o Design a protocol in such a way that NAT boxes are able to inspect o Design a protocol in such a way that NAT boxes are able to inspect
(or even participate) in the protocol exchange. This approach was (or even participate) in the protocol exchange. This approach was
taken with HIP but is not an option for IKEv2 and MOBIKE. taken with the Host Identity Protocol but is not an option for
IKEv2 and MOBIKE since most IKEv2 messages are encrypted with the
established IKE SA. This prevents the NAT from learning required
information from the protocol exchange in a similar fashion as in
HIP.
o Disable NAT-T support by indicating the desire never to use o Disable NAT-T by indicating the desire never to use information
information from the (unauthenticated) header. While this from the (unauthenticated) header. While this approach prevents
approach prevents some problems it effectively disallows the some security problems it effectively disallows the protocol to
protocol to work in certain environments. work in environments with NATs.
There is no way to distinguish the cases where there is NAT along the There is no way to distinguish the whether there is a NAT device
path that modifies the header information in packets or whether an along the path that modifies the header information in packets or an
adversary mounts an attack. If NAT is detected in the IKE SA adversary mounting an attack. If a NAT is detected during the
creation, that should automatically disable the MOBIKE extensions and creation of an IKE SA, that should automatically disable the MOBIKE
use NAT-T. extensions and use NAT-T.
A design question is whether NAT detection capabilities should be A design question is whether NAT detection capabilities should be
enabled only during the initial exchange or even at subsequent enabled only during the initial IKEv2 exchange or also during
message exchanges. If MOBIKE is executed with no NAT along the path subsequent message exchanges. If MOBIKE is executed with no NAT
when the IKE SA was created, then a NAT which appears after moving to along the path when the IKE SA was created, then a NAT which appears
a new network cannot be dealt with if NAT detection is enabled only after moving to a new network cannot be dealt with if NAT detection
during the initial exchange. Hence, it might be desirable to also is enabled only during the initial exchange. Hence, it is desirable
support a scenario where a MOBIKE peer moves from a network which to also support a scenario where a MOBIKE peer moves from a subnet
does not deploy a NAT to a network which uses a private address that is not behind a NAT to a network that is.
space.
A NAT prevention mechanism can be used to make sure that no adversary A NAT prevention mechanism can be used to make sure that no adversary
can interact with the protocol if no NAT is expected between the can interact with the protocol if no NAT is expected between the
Initiator and the Responder. Initiator and the Responder. (reference? Explanation?)
The support for NAT traversal is certainly one of the most important Whether or not MOBIKE should support NAT traversal is one of the most
design decisions with an impact on other protocol aspects. important design decisions.
5.5 Changing addresses or changing the paths 5.5 Changing addresses or changing the paths
A design decision is whether it is enough for the MOBIKE protocol to A design decision is whether it is enough for the MOBIKE protocol to
detect dead address, or does it need to detect also dead paths. Dead detect dead addresses, or it also needs to detect dead paths. Dead
address detection means that we only detect that we cannot get address detection refers to the ability to establish whether or not a
packets through to that remote address by using the local IP address given IP address pair is operational. Dead path detection refers to
given by the local IP-stack (i.e., local address selected normally by the ability to establish whether or not all possible (local/remote)
the routing information). Dead path detection means that we need to address pairs are operational (or at least find one such pair).
try all possible local interfaces/IP addresses for each remote
addresses, i.e., find all possible paths between the hosts and try
them all to see which of them work (or at least find one working
path).
While performing just an address change is simpler, the existence of While performing just one address change is simpler, the existence of
locally operational addresses are not, however, a guarantee that locally operational addresses is not, however, a guarantee that
communications can be established with the peer. A failure in the communications can be established with the peer. A failure in the
routing infrastructure can prevent the sent packets from reaching routing infrastructure can prevent the sent packets from reaching
their destination. Or a failure of an interface on one side can be their destination.
related to the failure of an interface on the other side, making it
necessary to change more than one address at a time.
5.6 Return Routability Tests 5.6 Return Routability Tests
Setting a new preferred address which is subsequently used for Changing the preferred address and subsequently using it for
communication is associated with an authorization decision: Is a peer communication is associated with an authorization decision: Is a peer
allowed to use this address? Does this peer own this address? Two allowed to use this address? Does this peer own this address? Two
mechanisms have been proposed in the past to allow a peer to mechanisms have been proposed in the past to allow a peer to
determine the answer to this question: determine the answer to this question:
o The addresses a peer is using are part of a certificate. o The addresses a peer is using are part of a certificate.
[RFC3554] introduced this approach. If the other peer is, for [RFC3554] which is introduced by this approach. If the other peer
example, a security gateway with a limited set of fixed IP is, for example, a security gateway with a limited set of fixed IP
addresses, then the security gateway may have a certificate with addresses, then the security gateway may have a certificate with
all the IP addresses in the certificate. all the IP addresses appear in the certificate.
o A return routability check is performed before the address is used o A return routability check is performed by the remote peer before
to ensure that the peer is reachable at the indicated address. the address is updated in that peer's Security Association
Database. This is done in order provide a certain degree of
confidence to the remote peer that local peer is reachable at the
indicated address.
Without performing an authorization decision a malicious peer can Without taking an authorization decision a malicious peer can
redirect traffic towards a third party or a blackhole. redirect traffic towards a third party or a blackhole.
An IP address should not be used as a primary address without A MOBIKE peer should not use an IP addressed provided by another
computing the authorization decision. If the addresses are part of MOBIKE peer as a primary address without computing the authorization
the certificate then it is not necessary to execute the weaker return decision. If the addresses are part of the certificate then it is
routability test. If multiple addresses are communicated to another not necessary to execute the weaker return-routability test. The
peer as part of the peer address set then some of these addresses return-routability test is a form of authorization check, although it
might be already verified even if the primary address is still provides weaker guarantees then the inclusion of the IP address as
operational. part of a certificate. If multiple addresses are communicated to the
remote peer then some of these addresses may be already verified even
if the primary address is still operational.
Another option is to use the [I-D.dupont-mipv6-3bombing] approach Another option is to use the [I-D.dupont-mipv6-3bombing] approach
which suggests to do a return routability test only if you have to which suggests to perform a return routability test only when an
send an address update from some other address than the indicated address update needs to be sent from some address other than the
preferred address. indicated preferred address.
Finally it would be possible not to execute return routability checks Finally it would be possible not to execute return routability checks
at all. In case of indirect change notifications then we only move at all. In case of indirect change notifications we only move to the
to the new preferred address after successful dead-peer detection on new preferred address after successful dead-peer detection (i.e., a
the new address, which is already a return routability check. With a response to a DPD test) on the new address, which is already a return
direct notifications the authenticated peer may have provided an routability check. With a direct notification the authenticated peer
authenticated IP address, thus we could simply trust the other end. may have provided an authenticated IP address. Thus it is would be
There is no way external attacker can cause any attacks, but we are possible to simply trust the MOBIKE peer to provide a proper IP
not protected from the internal attacker, i.e. the authenticated address. There is no way an adversary can successfully launch an
peer forwarding its traffic to the new address. On the other hand we attack by injecting faked addresses since it does not know the IKE SA
do know the identity of the peer in that case. and the corresponding keying material.A protection against an
internal attacker, i.e. the authenticated peer forwarding its traffic
to the new address, is not provided. This might be an issue when
extensions are added to IKEv2 that do not require authentication of
end points (e.g., opportunistic security using anonymous Diffie-
Hellman). On the other hand we know the identity of the peer in that
case. The identity of the IKEv2 Initiator and the IKEv2 Responder
can take various forms: IP address, FQDN, DN, email address alike
identifiers, etc.
As such, it seems that there it is also a policy issue when to It seems that there it is also a policy issue when to schedule a
schedule a return routability test. return routability test.
The basic format of the return routability check could be similar to The basic format of the return routability check could be similar to
dead-peer detection, but the problem is that if that fails then the dead-peer detection, but the problem is that if that fails then the
IKEv2 specification requires the IKE SA to be deleted. Because of IKEv2 specification requires the IKE SA to be deleted. Because of
this we might need to do some kind of other exchange. this a different type of exchange is required and thereby avoiding
modifications to the IKEv2 specification.
There are potential attacks if a return routability check does not There are potential attacks if a return routability check does not
include some kind of nonce. In this attack the valid end point sends include some kind of nonce. The valid end point could send an
address update notification for the third party, trying to get all address update notification for a third party, trying to get all the
the traffic to be sent there, causing a denial of service attack. If traffic to be sent there, causing a denial of service attack. If the
the return routability checks does not contain any cookies or other return routability checks does not contain any cookies or other
random information not known by the other end, then that valid node random information not known to the other end, then that valid node
could reply to the return routability checks even when it cannot see could reply to the return routability checks even when it cannot see
the request. This might cause the other end to turn the traffic to the request. This might cause a peer to move the traffic to a
there, even when the true original recipient cannot be reached at location where the original recipient cannot be reached.
this address.
The IKEv2 NAT-T mechanism does not perform any return routability The IKEv2 NAT-T mechanism does not perform return routability checks.
checks. It simply uses the last seen source IP address used by the
other peer as the destination address to send response packets. An It simply uses the last seen source IP address used by the other peer
adversary can change those IP addresses, and can cause the response as the destination address to send response packets. An adversary
packets to be sent to wrong IP address. The situation is self-fixing can change those IP addresses, and can cause the response packets to
when the adversary is no longer able to modify packets and the first be sent to wrong IP address. The situation is self-fixing when the
packet with true IP address reaches the other peer. In a certain adversary is no longer able to modify packets and the first packet
sense mobility handling makes this attack difficult for an adversary with an unmodified IP address reaches the other peer. Mobility
since it needs to be located somewhere along the path where the environments make this attack more difficult for an adversary since
individual paths ({CoA1, ..., CoAn} towards the destination IP it requires the adversary to be located somewhere on the individual
address) have a shared path or if the adversary is located near the paths ({CoA1, ..., CoAn} towards the destination IP address) have a
MOBIKE client then it needs to follow the users mobility patterns. shared path or if the adversary is located near the MOBIKE client
With IKEv2 NAT-T, the genuine client can cause third party bombing by then it needs to follow the user mobility patterns. With IKEv2
NAT-T, the genuine client can cause third party bombing by
redirecting all the traffic pointed to him to third party. As the redirecting all the traffic pointed to him to third party. As the
MOBIKE protocol tries to provide equal or better security than IKEv2 MOBIKE protocol tries to provide equal or better security than IKEv2
NAT-T the MOBIKE protocol should protect against these attacks. NAT-T mechanism it should protect against these attacks.
There might be also return routability information available from the There may be return routability information available from the other
other parts of the system too (as shown in Figure 3), but the checks parts of the system too (as shown in Figure 3), but the checks done
done might have a different quality. There are multiple levels for may have a different quality. There are multiple levels for return
return routability checks: routability checks:
o None, no tests o None, no tests
o A party willing to answer is on the path to the claimed address. o A party willing to answer the return routability check is located
This is the basic form of return routability test. along the path to the claimed address (). This is the basic form
of return routability test.
o There is an answer from the tested address, and that answer was o There is an answer from the tested address, and that answer was
authenticated (including the address) to be from our peer. authenticated, integrity and replay protected.
o There was an authenticated answer from the peer, but it is not o There was an authenticated, integrity and replay protected answer
guaranteed to be from the tested address or path to it (because from the peer, but it is not guaranteed to originate at the tested
the peer can construct a response without seeing the request). address or path to it (because the peer can construct a response
without seeing the request).
The basic return routability checks do not protect against 3rd party The return routability checks do not protect against 3rd party
bombing if the attacker is along the path, as the attacker can bombing if the attacker is along the path, as the attacker can
forward the return routability checks to the real peer (even if those forward the return routability checks to the real peer (even if those
packets are cryptographically authenticated). packets are cryptographically authenticated).
If the address to be tested is inside the MOBIKE packet too, then the If the address to be tested is carried inside the MOBIKE payload,
adversary cannot forward packets, thus it prevents 3rd party then the adversary cannot forward packets. Thus 3rd party bombings
bombings. are prevented.
If the reply packet can be constructed without seeing the request If the reply packet can be constructed without seeing the request
packet (for example, if there is no nonce, challenge or similar packet (for example, if there is no nonce, challenge or similar
mechanism to show liveness), then the genuine peer can cause 3rd mechanism to show liveness), then the genuine peer can cause 3rd
party bombing, by replying to those requests without seeing them at party bombing, by replying to those requests without seeing them at
all. all.
Other levels might only provide information that there is someone at Other levels might only provide a guarantee that there is a node at
the IP address which replied to the request. There might not be an the IP address which replied to the request. There is no indication
indication that the reply was freshly generated or repeated, or the as to whether or not the reply is fresh, and whether or not the
request might have been transmitted from a different source address. request may have been transmitted from a different source address.
Requirements for a MOBIKE protocol for the return routability test
might be able to verify that there is the same (cryptographically)
authenticated node at the other peer and it can now receive packets
from the IP address it claims to have.
5.7 Employing MOBIKE results in other protocols 5.7 Employing MOBIKE results in other protocols
If MOBIKE has learned about new locations or verified the validity of If MOBIKE has learned about new locations or verified the validity of
an address through a return routability test, can this information be a remote address through a return routability check, can this
useful for other protocols? information be useful for other protocols?
When considering the basic MOBIKE VPN scenario, the answer is no. When considering the basic MOBIKE VPN scenario, the answer is no.
Transport and application layer protocols running inside the VPN Transport and application layer protocols running inside the VPN
tunnel have no consideration about the outer addresses or their tunnel are unaware of the outer addresses or their status.
status.
Similarly, IP layer tunnel termination at a gateway rather than a Similarly, IP layer tunnel termination at a gateway rather than a
host endpoint limits the benefits for "other protocols" that could be host endpoint limits the benefits for "other protocols" that could be
informed -- all application protocols at the other side are running informed -- all application protocols at the other side are unaware
in a node that is unaware of IPsec, IKE, or MOBIKE. of IPsec, IKE, or MOBIKE.
However, it is conceivable that future uses or extensions of the However, it is conceivable that future uses or extensions of the
MOBIKE protocol make such information distribution useful. For MOBIKE protocol make such information distribution useful. For
instance, if transport mode MOBIKE and SCTP were made to work instance, if transport mode MOBIKE and SCTP were made to work
together, it would likely be useful for SCTP to learn about the new together, it would potentially be useful for SCTP to learn about the
addresses at the same time as MOBIKE learns them. Similarly, various new addresses at the same time as MOBIKE. Similarly, various IP
IP layer mechanisms might make use of the fact that a return layer mechanisms may make use of the fact that a return routability
routability test of a specific type has already been performed. test of a specific type has been performed. However, care should be
However, in all of these cases careful consideration should be exercised in all these situations .
applied. This consideration should answer to questions such as
whether other alternative sources exist for the information, whether
dependencies are created between parts that prior to this had no
dependencies, and what the impacts in terms of number of messages or
latency are.
[I-D.crocker-celp] discussed the use of common locator information [I-D.crocker-celp] discusses the use of common locator information
pools in IPv6 multihoming context; it assumed that both transport and pools in a IPv6 multi-homing context; it assumed that both transport
IP layer solutions would be used for providing multihoming, and that and IP layer solutions are be used in order to support multi-homing,
it would be beneficial for different protocols to coordinate their and that it would be beneficial for different protocols to coordinate
results in some manner, for instance by sharing experienced their results in some way, for instance by sharing throughput
throughput information for address pairs. This may apply to MOBIKE information of address pairs. This may apply to MOBIKE as well,
as well, assuming it co-exists with non-IPsec protocols that are assuming it co-exists with non-IPsec protocols that are faced with
faced with the same multiaddressing choices. the same or similar multi-homing choices.
Nevertheless, all of this is outside the scope of current MOBIKE base Nevertheless, all of this is outside the scope of current MOBIKE base
protocol design and may be addressed in future work. protocol design and may be addressed in future work. (so why do you
elaborate so much on this stuff?)
5.8 Scope of SA changes 5.8 Scope of SA changes
Most sections of this document discuss design considerations for Most sections of this document discuss design considerations for
updating and maintaining addresses for the IKE-SA. However, changing updating and maintaining addresses in the database entries that
the preferred address also has an impact for IPsec SAs. The outer relate to an IKE-SA. However, changing the preferred address also
tunnel header addresses (source IP and destination IP addresses) need affects the entries of the IPsec SA database. The outer tunnel
to be modified according to the primary path to allow the IPsec header addresses (source and destination IP addresses) need to be
protected data traffic to travel along the same path as the MOBIKE modified according to the primary path to allow the IPsec protected
packets (if we only consider the IP header information). data traffic to travel along the same path as the MOBIKE packets (if
we only consider the IP header information). If the MOBIKE messages
and the IPsec protected data traffic travel along a different path
then NAT handling is severely complicated.
The basic question is then how the IPsec SAs are changed to use the The basic question is then how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling new address pair (the same address pair as the MOBIKE signaling
traffic -- the primary path). One option is that when the IKE SA traffic -- the primary path). One option is that when the IKE SA
address is changed then automatically all IPsec SAs associated with address is changed then automatically all IPsec SAs associated with
it are moved along with it to new address pair. Another option is to it are moved along with it to new address pair. Another option is to
have a separate exchange to move the IPsec SAs separately. have a separate exchange to move the IPsec SAs separately.
If IPsec SAs should be updated separately then a more efficient If IPsec SAs should be updated separately then a more efficient
format than notification payload is needed. A notification payload format than the notification payload is needed to preserve bandwidth.
can only store one SPI per payload. A separate payload which would A notification payload can only store one SPI per payload. A
have list of IPsec SA SPIs and new preferred address. If there are separate payload which would have list of IPsec SA SPIs and new
large number of IPsec SAs, those payloads can be quite large unless preferred address. If there is a large number of IPsec SAs, those
ranges of SPI values are supported. If we automatically move all payloads can be quite large unless ranges of SPI values are
IPsec SAs when the IKE SA moves, then we only need to keep track supported. If we automatically move all IPsec SAs when the IKE SA
which IKE SA was used to create the IPsec SA, and fetch the IP moves, then we only need to keep track which IKE SA was used to
addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires create the IPsec SA, and fetch the IP addresses. Note that IKEv2
implementations to keep track which IPsec SAs are created using which [I-D.ietf-ipsec-ikev2] already requires implementations to keep track
IKE SA. which IPsec SAs are created using which IKE SA.
If we do allow each IPsec SAs address set to be updated separately, If we do allow each IPsec SA address set to be updated separately,
then we can support scenarios, where the machine has fast and/or then we can support scenarios, where the machine has fast and/or
cheap connections and slow and/or expensive connections, and it wants cheap connections and slow and/or expensive connections, and it wants
to allow moving some of the SAs to the slower and/or more expensive to allow moving some of the SAs to the slower and/or more expensive
connection, and prevent the move, for example, of the news video connection, and prevent the move, for example, of the news video
stream from the WLAN to the GPRS link. stream from the WLAN to the GPRS link.
On the other hand, even if we tie the IKE SA update to the IPsec SA On the other hand, even if we tie the IKE SA update to the IPsec SA
update, then we can create separate IKE SAs for this scenario, e.g., update, then we can create separate IKE SAs for this scenario, e.g.,
we create one IKE SA which have both links as endpoints, and it is we create one IKE SA which have both links as endpoints, and it is
used for important traffic, and then we create another IKE SA which used for important traffic, and then we create another IKE SA which
have only the fast and/or cheap connection, which is then used for have only the fast and/or cheap connection, which is then used for
that kind of bulk traffic. that kind of bulk traffic.
5.9 Zero Address Set 5.9 Zero Address Set
One of the features which might be useful would be for the peer to One of the features which is potentially useful is for the peer to
announce the other end that it will now disconnect for some time, announce that it will now disconnect for some time, i.e. it will not
i.e., it will not be reachable at all. For instance, a laptop might be reachable at all. For instance, a laptop might go to suspend
go to suspend mode. In this case the peer could send address mode. In this case the it could send address notification with zero
notification with zero new addresses, which means that it will not new addresses, which means that it will not have any valid addresses
have any valid addresses anymore. The responder of that kind of anymore. The responder of that kind of notification would then
notification would then acknowledge that, and could then temporarily acknowledge that, and could then temporarily disable all SAs and
disable all SAs. If any of the SAs gets any packets they are simply therefore stop sending traffic. If any of the SAs gets any packets
dropped. This could also include some kind of ACK spoofing to keep they are simply dropped. This could also include some kind of ACK
the TCP/IP sessions alive (or simply set the TCP/IP keepalives and spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP
timeouts large enough not to cause problems), or it could simply be keepalives and timeouts large enough not to cause problems), or it
left to the applications, e.g., allow TCP/IP sessions to notice the could simply be left to the applications, e.g. allow TCP/IP sessions
link is broken. to notice the link is broken.
The local policy could then decide how long the peer would allow The local policy could then indicate how long the peer should allow
other peers to be disconnected, e.g., whether this is only allowed remote peers to remain disconnected.
for few minutes, or do they allow users to disconnect Friday evening
and reconnect Monday morning (consuming resources during weekend too,
but on the other hand not more than is normally used during week
days, but we do not need lots of extra resources on the Monday
morning to support all those people connecting back to network).
From a technical point of view this feature addresses two aspects: From a technical point of view this feature addresses two aspects:
o There is no need to transmit IPsec data traffic. IPsec protected o There is no need to transmit IPsec data traffic. IPsec protected
data needs to be dropped which saves bandwidth. This does not data needs to be dropped which saves bandwidth. This does not
provide a functional benefit i.e, nothing breaks if this feature provide a functional benefit, i.e., nothing breaks if this feature
is not provided. is not provided.
o MOBIKE signaling messages are also ignored and need to be o MOBIKE signaling messages are also ignored. The IKE-SA must not
suspended. The IKE-SA must not be deleted and the suspend be deleted and the suspend functionality (realized with the zero
functionality (realized with the zero address set) might require address set) may require the IKE-SA to be tagged with a lifetime
the IKE-SA to be tagged with a lifetime value since the IKE-SA value since the IKE-SA should not be kept in alive for an
will not be kept in memory an arbitrary amount of time. Note that undefined period of time. Note that IKEv2 does not require that
the IKE-SA has no lifetime associated with it. In order to the IKE-SA has a lifetime associated with it. In order to prevent
prevent the IKE-SA to be deleted the dead-peer detection mechanism the IKE-SA from being deleted the dead-peer detection mechanism
needs to be suspended as well. needs to be suspended as well.
Due to the enhanced complexity of this extension a first version of Due to the fact that this extension would be complicated, a first
the MOBIKE protocol will not provide this feature. version of the MOBIKE protocol will not provide this feature.
5.10 IPsec Tunnel or Transport Mode 5.10 IPsec Tunnel or Transport Mode
Current MOBIKE design is focused only on the VPN type usage and Current MOBIKE design is focused only on the VPN type usage and
tunnel mode. Transport mode behaviour would also be useful, but will tunnel mode. Transport mode behaviour would also be useful, but will
be discussed in future documents. be discussed in future documents.
5.11 Message Representation 5.11 Message Representation
The basic IP address change notifications can be sent either via an The IP address change notifications can be sent either via an
informational exchange already specified in the IKEv2, or via a informational exchange already specified in the IKEv2, or via a
MOBIKE specific message exchange. Using informational exchange has MOBIKE specific message exchange. Using informational exchange has
the main advantage that it is already specified in the IKEv2 and the main advantage that it is already specified in the IKEv2 and
implementations incorporated the functionality already. implementations incorporate the functionality already.
Another question is the basic format of the address update Another question is the format of the address update notifications.
notifications. The address update notifications can include multiple The address update notifications can include multiple addresses, of
addresses, which some can be IPv4 and some IPv6 addresses. The which some may be IPv4 and some IPv6 addresses. The number of
number of addresses is most likely going to be quite small (less than addresses is most likely going to be limited in typical environments
10). The format might need to indicate a preference value for each (with less than 10 addresses). The format may need to indicate a
address. Furthermore, one of the addresses in the peer address set preference value for each address. The format could either contain a
must be labeled as the preferred address. The format could either preference number that determines the relative order of the
contain the preference number, giving out the relative order of the addresses, or it could simply be ordered, according to preference,
addresses, or it could simply be ordered list of IP addresses in the list of IP addresses. While two addresses can have the same
order of the most preferred first. While two addresses can have the preference value an ordered list avoids this situation.
same preference value an ordered list avoids this problem.
Even if load balancing is currently outside the scope of MOBIKE, Even if load balancing is currently outside the scope of MOBIKE,
there might be future work to include this feature. The format future work might include. The selected format needs to be flexible
selected needs to be flexible enough to include additional enough to include additional information (e.g. to enable load
information (e.g., to enable load balancing). This might be balancing). This may be realized with an reserved field, which can
something like one reserved field, which can later be used to store later be used to store additional information. As there may arise
additional information. As there is other potential information other information which may have to be tied to an address in the
which might have to be tied to the address in the future, a reserved future, a reserved field seems like a prudent design in any case.
field seems like a prudent design in any case.
There are two basic formats for putting IP address list in to the There are two formats that place IP address lists into a message.
exchange, we can include each IP address as separate payload (where One includes each IP address as separate payload (where the payload
the payload order indicates the preference value, or the payload order indicates the preference value, or the payload itself might
itself might include the preference value), or we can put the IP include the preference value), or we can put the IP address list as
address list as one payload to the exchange, and that one payload one payload to the exchange, and that one payload will then have
will then have internal format which includes the list of IP internal format which includes the list of IP addresses.
addresses.
Having multiple payloads each having one IP address makes the Having multiple payloads with each one having carrying one IP address
protocol probably easier to parse, as we can already use the normal makes the protocol probably easier to parse, as we can already use
IKEv2 payload parsing procedures to get the list out. It also offers the normal IKEv2 payload parsing procedures.. It also offers an easy
easy way for the extensions, as the payload probably contains only way for the extensions, as the payload probably contains only the
the type of the IP address (or the type is encoded to the payload type of the IP address (or the type is encoded to the payload type),
type), and the IP address itself, and as each payload already has and the IP address itself, and as each payload already has length
length associated to it, we can detect if there is any extra data associated to it, we can detect if there is any extra data after the
after the IP address. Some implementations might have problems IP address. Some implementations might have problems parsing IKEv2
parsing too long of a list of IKEv2 payloads, but if the sender sends payloads that are longer than a certain threshold, but if the sender
them in the most preferred first, the other end can simply only take sends them in the most preferred first, the receiver can only use the
the first addresses and use them. first addresses.
Having all IP addresses in one big MOBIKE specified internal format Having all IP addresses in one big MOBIKE specified internal format
provides more compact encoding, and keeps the MOBIKE implementation provides more compact encoding, and keeps the MOBIKE implementation
more concentrated to one module. more concentrated to one module. It also avoids problems of packets
arriving in an order different from what they were sent.
The next choice is which type of payloads to use. IKEv2 already Another choice is which type of payloads to use. IKEv2 already
specifies a notify payload. It includes some extra fields (SPI size, specifies a notify payload. It includes some extra fields (SPI size,
SPI, protocol etc), which gives 4 bytes of the extra overhead, and SPI, protocol etc), which gives 4 bytes of the extra overhead, and
there is the notify data field, which could include the MOBIKE there is the notify data field, which could include the MOBIKE
specific data. specific data.
Another option would be to have a custom payload type, which then Another option would be to have a custom payload type, which then
includes the information needed for the MOBIKE protocol. includes the information needed for the MOBIKE protocol.
MOBIKE might send the full peer address list once one of the IP MOBIKE might send the full peer address list once one of the IP
addresses changes (either addresses are added, removed, the order addresses changes (either addresses are added, removed, the order
skipping to change at page 28, line 8 skipping to change at page 28, line 8
old ones, even if they arrive after the most recent one (IKEv2 old ones, even if they arrive after the most recent one (IKEv2
packets have message id which is incremented for each packet, thus we packets have message id which is incremented for each packet, thus we
know the sending order easily). know the sending order easily).
Note that each peer needs to communicate its peer address set to the Note that each peer needs to communicate its peer address set to the
other peer. other peer.
6. Security Considerations 6. Security Considerations
As all the messages are already authenticated by the IKEv2 there is As all the messages are already authenticated by the IKEv2 there is
no problem that any attackers would modify the actual contents of the no problem that any attackers would modify the contents of the
packets. The IP addresses in IP header of the packets are not packets. The IP addresses in the IP header of the packets are not
authenticated, thus the protocol defined must take care that they are authenticated, thus the protocol defined must take care that they are
only used as an indication that something might be different, they only used as an indication that something might be different, and
should not cause any direct actions. that do not cause any direct actions.
Attacker can also spoof ICMP error messages in an effort to confuse An attacker can also spoof ICMP error messages in an effort to
the peers about which addresses are not working. At worst this confuse the peers about which addresses are not working. At worst
causes denial of service and/or the use of non-preferred addresses, this causes denial of service and/or the use of non-preferred
so it is not that serious. addresses.
One type of attack that needs to be taken care of in the MOBIKE One type of attack that needs to be taken care of in the MOBIKE
protocol is also various flooding attacks. See protocol is the "flooding attack" type. See [I-D.ietf-mip6-ro-sec]
[I-D.ietf-mip6-ro-sec] and [Aur02] for more information about and [Aur02] for more information about flooding attacks.
flooding attacks.
[EDITOR's NOTE: This section needs more work.]
7. IANA Considerations 7. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
8. Acknowledgments 8. Acknowledgments
This document is the result of discussions in the MOBIKE working This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen, group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
Udo Schilcher, Tom Henderson and Maureen Stillman for their input. Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman
for their input.
We would like to particularly thank Pasi Eronen for tracking open We would like to particularly thank Pasi Eronen for tracking open
issues on the MOBIKE mailing list. He helped us to make good issues on the MOBIKE mailing list. He helped us to make good
progress on the document. progress on the document.
9. Open Issues 9. Open Issues
This document is not yet complete, the following open issues need to This document is not yet complete, the following open issues need to
be addressed in a future version: be addressed in a future version:
o Section 4 needs an example to better illustrate the functionality o Section 4 needs an example to better illustrate the functionality
of MOBIKE of MOBIKE
o Section 6 requires a more detailed discussion about the potential o Section 6 requires a more detailed discussion about the potential
security vulnerabilities and their solution. security vulnerabilities and corresponding countermeasures.
o Some text is need to address the implications of unidirectional
o Some text is needed to address the implications of unidirectional
connectivity aspect for MOBIKE (see also issue #19). connectivity aspect for MOBIKE (see also issue #19).
o A discussion about the scalability aspects of connectivity tests o A discussion about the scalability aspects of connectivity tests
would be benefical. would be benefical.
o More details are necessary to describe the implications of NAT o More details are necessary to describe the implications of NAT
traversal for MOBIKE. traversal for MOBIKE.
A complete list of issues is available at TBD. A complete list of issues is available at
http://www.vpnc.org/ietf-mobike/issues.html.
10. References 10. References
10.1 Normative references 10.1 Normative references
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-ipsec-rfc2401bis] [I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December in progress), April 2005.
2004.
10.2 Informative References 10.2 Informative References
[I-D.arkko-multi6dt-failure-detection] [I-D.arkko-multi6dt-failure-detection]
Arkko, J., "Failure Detection and Locator Selection in Arkko, J., "Failure Detection and Locator Selection in
Multi6", Multi6", draft-arkko-multi6dt-failure-detection-00 (work
Internet-Draft draft-arkko-multi6dt-failure-detection-00, in progress), October 2004.
October 2004.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[I-D.dupont-mipv6-3bombing] [I-D.dupont-mipv6-3bombing]
Dupont, F., "A note about 3rd party bombing in Mobile Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", Internet-Draft draft-dupont-mipv6-3bombing-01, IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),
January 2005. June 2005.
[I-D.ietf-mip6-ro-sec] [I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", Security Design Background", draft-ietf-mip6-ro-sec-03
Internet-Draft draft-ietf-mip6-ro-sec-02, October 2004. (work in progress), May 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with Nikander, P., "End-Host Mobility and Multi-Homing with
Host Identity Protocol", Host Identity Protocol", draft-ietf-hip-mm-01 (work in
Internet-Draft draft-ietf-hip-mm-00, October 2004. progress), February 2005.
[I-D.crocker-celp] [I-D.crocker-celp]
Crocker, D., "Framework for Common Endpoint Locator Crocker, D., "Framework for Common Endpoint Locator
Pools", Internet-Draft draft-crocker-celp-00, February Pools", draft-crocker-celp-00 (work in progress),
2004. February 2004.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[I-D.ietf-tsvwg-addip-sctp] [I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP) Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
Internet-Draft draft-ietf-tsvwg-addip-sctp-10, January draft-ietf-tsvwg-addip-sctp-12 (work in progress),
2005. June 2005.
[I-D.dupont-ikev2-addrmgmt] [I-D.dupont-ikev2-addrmgmt]
Dupont, F., "Address Management for IKE version 2", Dupont, F., "Address Management for IKE version 2",
Internet-Draft draft-dupont-ikev2-addrmgmt-06, October draft-dupont-ikev2-addrmgmt-07 (work in progress),
2004. May 2005.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
"On the Use of Stream Control Transmission Protocol (SCTP) Stewart, "On the Use of Stream Control Transmission
with IPsec", RFC 3554, July 2003. Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[I-D.ietf-ipv6-optimistic-dad] [I-D.ietf-ipv6-optimistic-dad]
Moore, N., "Optimistic Duplicate Address Detection for Moore, N., "Optimistic Duplicate Address Detection for
IPv6", Internet-Draft draft-ietf-ipv6-optimistic-dad-05, IPv6", draft-ietf-ipv6-optimistic-dad-05 (work in
February 2005. progress), February 2005.
[I-D.ietf-ipv6-unique-local-addr] [I-D.ietf-ipv6-unique-local-addr]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
Internet-Draft draft-ietf-ipv6-unique-local-addr-09, progress), January 2005.
January 2005.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
API, Version 2", RFC 2367, July 1998. Management API, Version 2", RFC 2367, July 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461,
1998. December 1998.
[Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las Vegas, Security Applications Conference, pages 78-87, Las Vegas,
NV USA, December 2002. NV USA, December 2002.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
Fredrikinkatu 47 Fredrikinkatu 47
HELSINKI FIN-00100 HELSINKI FIN-00100
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/