draft-ietf-mobike-design-04.txt   draft-ietf-mobike-design-05.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: April 24, 2006 Siemens Expires: June 3, 2006 Siemens
October 21, 2005 November 30, 2005
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-04.txt draft-ietf-mobike-design-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 24, 2006. This Internet-Draft will expire on June 3, 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 extensions for the Internet Key Exchange Protocol version developing extensions for the Internet Key Exchange Protocol version
2 (IKEv2). These extensions should enable an efficient management of 2 (IKEv2). These extensions should enable an efficient management of
skipping to change at page 2, line 18 skipping to change at page 3, line 12
background information and discussions within the working group are background information and discussions within the working group are
recorded. recorded.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Mobility Scenario . . . . . . . . . . . . . . . . . . . . 8 3.1. Mobility Scenario . . . . . . . . . . . . . . . . . . . . 8
3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9 3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9
3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 10 3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9
4. Scope of MOBIKE . . . . . . . . . . . . . . . . . . . . . . . 11 4. Scope of MOBIKE . . . . . . . . . . . . . . . . . . . . . . . 11
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
5.1. Choosing addresses . . . . . . . . . . . . . . . . . . . . 14 5.1. Choosing Addresses . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Inputs and triggers . . . . . . . . . . . . . . . . . 14 5.1.1. Inputs and Triggers . . . . . . . . . . . . . . . . . 14
5.1.2. Connectivity . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Connectivity . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Discovering connectivity . . . . . . . . . . . . . . . 15 5.1.3. Discovering Connectivity . . . . . . . . . . . . . . . 15
5.1.4. Decision making . . . . . . . . . . . . . . . . . . . 15 5.1.4. Decision Making . . . . . . . . . . . . . . . . . . . 15
5.1.5. Suggested approach . . . . . . . . . . . . . . . . . . 15 5.1.5. Suggested Approach . . . . . . . . . . . . . . . . . . 15
5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Background and constraints . . . . . . . . . . . . . . 16 5.2.1. Background and Constraints . . . . . . . . . . . . . . 16
5.2.2. Fundamental restrictions . . . . . . . . . . . . . . . 16 5.2.2. Fundamental Restrictions . . . . . . . . . . . . . . . 16
5.2.3. Moving to behind NAT and back . . . . . . . . . . . . 16 5.2.3. Moving to behind a NAT and back . . . . . . . . . . . 16
5.2.4. Responder behind NAT . . . . . . . . . . . . . . . . . 17 5.2.4. Responder behind a NAT . . . . . . . . . . . . . . . . 17
5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 17 5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Suggested approach . . . . . . . . . . . . . . . . . . 17 5.2.6. Suggested Approach . . . . . . . . . . . . . . . . . . 18
5.3. Scope of SA changes . . . . . . . . . . . . . . . . . . . 18 5.3. Scope of SA Changes . . . . . . . . . . . . . . . . . . . 18
5.4. Zero address set functionality . . . . . . . . . . . . . . 19 5.4. Zero Address Set Functionality . . . . . . . . . . . . . . 19
5.5. Return routability test . . . . . . . . . . . . . . . . . 19 5.5. Return Routability Check . . . . . . . . . . . . . . . . . 20
5.5.1. Employing MOBIKE results in other protocols . . . . . 22 5.5.1. Employing MOBIKE Results in other Protocols . . . . . 23
5.5.2. Suggested approach . . . . . . . . . . . . . . . . . . 23 5.5.2. Return Routability Failures . . . . . . . . . . . . . 23
5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 23 5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 25
6. Protocol detail issues . . . . . . . . . . . . . . . . . . . . 24 5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25
6.1. Indicating support for mobike . . . . . . . . . . . . . . 24 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Path Testing and Window size . . . . . . . . . . . . . . . 25 6.1. Indicating Support for MOBIKE . . . . . . . . . . . . . . 26
6.3. Message presentation . . . . . . . . . . . . . . . . . . . 26 6.2. Path Testing and Window size . . . . . . . . . . . . . . . 27
6.4. Updating address list . . . . . . . . . . . . . . . . . . 27 6.3. Message presentation . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6.4. Updating address list . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Normative references . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 31 10.1. Normative references . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
The purpose of IKEv2 is to mutually authenticate two hosts, establish The purpose of IKEv2 is to mutually authenticate two hosts, establish
one or more IPsec Security Associations (SAs) between them, and one or more IPsec Security Associations (SAs) between them, and
subsequently manage these SAs (for example, by rekeying or deleting). subsequently manage these SAs (for example, by rekeying or deleting).
IKEv2 enables the hosts to share information that is relevant to both IKEv2 enables the hosts to share information that is relevant to both
the usage of the cryptographic algorithms that should be employed the usage of the cryptographic algorithms that should be employed
(e.g., parameters required by cryptographic algorithms and session (e.g., parameters required by cryptographic algorithms and session
keys) and to the usage of local security policies, such as keys) and to the usage of local security policies, such as
skipping to change at page 4, line 31 skipping to change at page 4, line 31
single pair in the outer IP headers. Existing documents make no single pair in the outer IP headers. Existing documents make no
provision to change this pair after an IKE SA is created. provision to change this pair after an IKE SA is created.
There are scenarios where one or both of the IP addresses of this There are scenarios where one or both of the IP addresses of this
pair may change during an IPsec session. In principle, the IKE SA pair may change during an IPsec session. In principle, the IKE SA
and all corresponding IPsec SAs could be re-established after the IP and all corresponding IPsec SAs could be re-established after the IP
address has changed. However, this can be problematic, as the device address has changed. However, this can be problematic, as the device
might be too slow for this task. Moreover, manual user interaction might be too slow for this task. Moreover, manual user interaction
(for example when using SecurID cards) might be required as part of (for example when using SecurID cards) might be required as part of
the IKEv2 authentication procedure. Therefore, an automatic the IKEv2 authentication procedure. Therefore, an automatic
mechanism is need that updates the IP addresses associated with the mechanism is needed that updates the IP addresses associated with the
IKE SA and the IPsec SAs. MOBIKE provides such a mechanism. IKE SA and the IPsec SAs. The MOBIKE protocol provides such a
mechanism.
The work of the MOBIKE working group and therefore this document is The work of the MOBIKE working group and therefore this document is
based on the assumption that the mobility and multi-homing extensions based on the assumption that the mobility and multi-homing extensions
are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on
the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis], the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis],
all protocols developed within the MOBIKE working group must be all protocols developed within the MOBIKE working group must be
compatible with both IKEv2 and the architecture described in compatible with both IKEv2 and the architecture described in
RFC2401bis. The document does not aim to neither provide support RFC2401bis. This document neither discusses mobility and multi-
IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401]. homing support for IKEv1 [RFC2409] nor the IPsec 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 a number of relevant usage scenarios are important terms in Section 2, a number of relevant usage scenarios
discussed in Section 3. The next section Section 4 will describe the are discussed in Section 3. Section 4 describes the scope of the
scope of the MOBIKE protocol. Finally, Section 5 discusses design MOBIKE protocol. Section 5 discusses design considerations affecting
considerations affecting the MOBIKE protocol. The document concludes the MOBIKE protocol. Section 6 investigates details regarding the
in Section 7 with security considerations. MOBIKE protocol. Finally, this document concludes in Section 7 with
security considerations.
2. Terminology 2. Terminology
This section introduces the terminology that is used in this This section introduces the terminology that is used in this
document. document.
Peer: Peer:
A peer is an IKEv2 endpoint. In addition, a peer implements the A peer is an IKEv2 endpoint. In addition, a peer implements the
MOBIKE extensions, as defined in this and related documents. MOBIKE extensions, defined in [I-D.ietf-mobike-protocol].
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
met: met:
* The address has been assigned to an interface. * The address has been assigned to an interface.
* If the address is an IPv6 address, we additionally require (a) * If the address is an IPv6 address, we additionally require (a)
that the address is valid as defined in RFC 2461 [RFC2461], and that the address is valid as defined in RFC 2461 [RFC2461], and
(b) that the address is not tentative as defined in RFC 2462 (b) that the address is not tentative as defined in RFC 2462
[RFC2462]. In other words, we require the address assignment [RFC2462]. In other words, we require the address assignment
to be complete. to be complete.
Note that this explicitly allows an address to be optimistic as Note that this explicitly allows an address to be optimistic as
defined in [I-D.ietf-ipv6-optimistic-dad]. defined in [I-D.ietf-ipv6-optimistic-dad].
* If the address is an IPv6 address, it is a global unicast or * 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- unique site-local address, as defined in [I-D.ietf-ipv6-unique-
local-addr]. That is, it is not an IPv6 link-local. Where local-addr]. That is, it is not an IPv6 link-local.
IPv4 is considered, it is not an RFC 1918 [RFC1918] address.
* The address and interface is acceptable for sending and * The address and interface is acceptable for sending and
receiving traffic according to a local policy. receiving traffic according to a local policy.
This definition is taken from [I-D.arkko-multi6dt-failure- This definition is taken from [I-D.arkko-multi6dt-failure-
detection]. detection], and adapted to the MOBIKE context (we do allow
[RFC1918] addresses here, they are very common addresses used
inside NATs).
Locally Operational Address: Locally Operational Address:
An address is said to be locally operational if it is available An address is said to be locally operational if it is available
and its use is locally known to be possible and permitted. This and its use is locally known to be possible and permitted. This
definition is taken 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, if and only if bidirectional connectivity can be address pair, if and only if bidirectional connectivity can be
shown between the two addresses. Note that sometimes it is shown between the two addresses. Note that sometimes it is
necessary to consider connectivity on a per-flow level between two necessary to consider connectivity on a per-flow level between two
endpoints needs to be tested. This differentiation might be endpoints. This differentiation might be necessary to address
necessary to address certain Network Address Translation types or certain Network Address Translation types or specific firewalls.
specific firewalls. This definition is taken from [I-D.arkko- This definition is taken from [I-D.arkko-multi6dt-failure-
multi6dt-failure-detection] and adapted for the MOBIKE context. detection] and adapted for the MOBIKE context. Although it is
Although it is possible to further differentiate unidirectional possible to further differentiate unidirectional and bidirectional
and bidirectional operational address pairs, only bidirectional operational address pairs, only bidirectional connectivity is
connectivity is relevant to this document and unidirectional relevant to this document and unidirectional connectivity is out
connectivity is out of scope. of scope.
Path: Path:
The sequence of routers traversed by the MOBIKE and IPsec packets The sequence of routers traversed by the MOBIKE and IPsec packets
exchanged between the two peers. Note that this path may be exchanged between the two peers. Note that this path may be
affected not only by the involved source and destination IP affected not only by the involved source and destination IP
addresses, but also by the transport protocol. Since MOBIKE and addresses, but also by the transport protocol. 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, for example by load balancers. be routed along a different path, for example by load balancers.
This definition is taken from [RFC2960] and adapted to the MOBIKE This definition is taken from [RFC2960] and adapted to the MOBIKE
context. context.
Primary Path: Primary Path:
The sequence of routers traversed by an IP packet that carries the The sequence of routers traversed by an IP packet that carries the
default source and destination addresses is said to be the Primary default source and destination addresses is said to be the Primary
Path. This definition is taken from [RFC2960] and adapted to the Path. This definition is taken from [RFC2960] and adapted to the
MOBIKE context. MOBIKE context.
skipping to change at page 6, line 51 skipping to change at page 7, line 5
Peer Address Set: Peer Address Set:
We denote the two peers of a MOBIKE session by peer A and peer B. We denote the two peers of a MOBIKE session by peer A and peer B.
A peer address set is the subset of locally operational addresses A peer address set is the subset of locally operational addresses
of peer A that is sent to peer B. A policy available at peer A of peer A that is sent to peer B. A policy available at peer A
indicates which addresses are included in the peer address set. indicates which addresses are included in the peer address set.
Such a policy might be created either manually or automatically Such a policy might be created either manually or automatically
through interaction with other mechanisms that indicate new through interaction with other mechanisms that indicate new
available addresses. available addresses.
Terminology regarding NAT types (e.g. Full Cone, Restricted Cone, Bidirectional Address Pair::
The address pair, where traffic can be sent to the both
directions, simply by reversing the IP addresses. Note, that the
path of the packets going to each direction might be different.
Unidirectional Address Pair::
The address pair, where traffic can only be sent in one direction,
and reversing the IP addresses and sending reply back does not
work.
Terminology regarding NAT types (e.g., Full Cone, Restricted Cone,
Port Restricted Cone and Symmetric), can be found in Section 5 of Port Restricted Cone and Symmetric), can be found in Section 5 of
[RFC3489]. For mobility related terminology (e.g. Make-before-break [RFC3489]. For mobility related terminology (e.g., Make-before-break
or Break-before-make) see [RFC3753]. or Break-before-make) see [RFC3753].
3. Scenarios 3. Scenarios
In this section we discuss three typical usage scenarios for the In this section we discuss three typical usage scenarios for the
MOBIKE protocol. 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 changes its point of network attachment. Prior to the change, node changes its point of network attachment. Prior to the change,
the mobile node had established an IPsec connection with a security the mobile node had established an IPsec connection with a security
gateway which offered, for example, access to a corporate network. gateway which offered, for example, access to a corporate network.
The IKEv2 exchange that facilitated the set up of the IPsec SA(s) The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took
took place over the path labeled as 'old path'. The involved packets place over the path labeled as 'old path'. The involved packets
carried the MN's "old" IP address and were forwarded by the "old" carried the MN's "old" IP address and were forwarded by the "old"
access router (OAR) to the security gateway (GW). access router (OAR) to the security gateway (GW).
When the MN changes its point of network attachment, it obtains a new When the MN changes its point of network attachment, it obtains a new
IP address using stateful address configuration techniques or via the IP address using stateful or stateless address configuration. The
stateless address autoconfiguration mechanism. The goal of MOBIKE, goal of MOBIKE, in this scenario, is to enable the MN and the GW to
in this scenario, is to enable the MN and the GW to continue using continue using the existing SAs and to avoid setting up a new IKE SA.
the existing SAs and to avoid setting up a new IKE SA. A protocol A protocol exchange, denoted by 'MOBIKE Address Update', enables the
exchange, denoted by 'MOBIKE Address Update', enables the peers to peers to update their state as necessary.
update their state as necessary.
Note that in a break-before-make scenario the MN obtains the new IP Note that in a break-before-make scenario the MN obtains the new IP
address after it can no longer be reached at the old IP address. In address after it can no longer be reached at the old IP address. In
a make-before-break scenario, the MN is, for a given period of time, a make-before-break scenario, the MN is, for a given period of time,
reachable at both the old and the new IP address. MOBIKE should work reachable at both the old and the new IP address. MOBIKE should work
in both the above scenarios. in both of 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 9, line 34 skipping to change at page 9, line 14
Figure 1: Mobility Scenario Figure 1: Mobility Scenario
3.2. Multihoming Scenario 3.2. Multihoming Scenario
Another MOBIKE usage scenario is depicted in Figure 2. In this Another MOBIKE usage scenario is depicted in Figure 2. In this
scenario, the MOBIKE peers are equipped with multiple interfaces (and scenario, the MOBIKE peers are equipped with multiple interfaces (and
multiple IP addresses). Peer A has two interface cards with two IP multiple IP addresses). Peer A has two interface cards with two IP
addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
and IP_B2. Each peer selects one of its IP addresses as the and IP_B2. Each peer selects one of its IP addresses as the
preferred address which is used for subsequent communication. preferred address which is used for subsequent communication.
Various reasons, (e.g hardware or network link failures), may require Various reasons (e.g., hardware or network link failures), may
a peer to switch from one interface to another. require a peer to switch from one interface to another.
+------------+ +------------+ +------------+ +------------+
| 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 10, line 4 skipping to change at page 9, line 33
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
---> = 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 aim to support load balancing between Note that MOBIKE does not aim to support load balancing between
multiple IP addresses. That is, each peer uses only one of the multiple IP addresses. That is, each peer uses only one of the
available IP 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
The third scenario we consider is about a laptop, which has multiple The third scenario we consider is about a laptop, which has multiple
interface cards and therefore several ways to connect to the network. interface cards and therefore several ways to connect to the network.
It may for example have a fixed Ethernet card, a WLAN interface, a It may, for example, have a fixed Ethernet card, a WLAN interface, a
GPRS adaptor, a Bluetooth interface or USB hardware. Not all GPRS adaptor, a Bluetooth interface or USB hardware. Not all
interfaces are connected to the network at all times for a number of interfaces are used for communication all the time for a number of
reasons (e.g., cost, availability of certain link layer technologies, reasons (e.g., cost, network availability, user convenience). The
user convenience). The mechanism that determines which interfaces policies that determine which interfaces are connected to the network
are connected to the network at any given point in time is outside at any given point in time is outside the scope of the MOBIKE
the scope of the MOBIKE protocol and, as such, this document. protocol and, as such, this document. However, as the laptop changes
However, as the laptop changes its point of attachment to the its point of attachment to the network, the set of IP addresses under
network, the set of IP addresses under which the laptop is reachable, which the laptop is reachable, changes too.
changes too.
Even if IP addresses change due to interface switching or mobility, Even if IP addresses change due to interface switching or mobility,
the IP address obtained via the configuration payloads within IKEv2 the IP address obtained via the configuration payloads within IKEv2
remain unaffected. The IP address obtained via the IKEv2 remain unaffected. The IP address obtained via the IKEv2
configuration payloads allow the configuration of the inner IP configuration payloads allow the configuration of the inner IP
address of the IPsec tunnel. As such, applications might not detect address of the IPsec tunnel. As such, applications might not detect
any change at all. any change at all.
4. Scope of MOBIKE 4. Scope of MOBIKE
Getting mobility and multihoming actually working requires lots of Getting mobility and multihoming actually working requires many
different components working together, including coordinating things different components to work together, including coordinating
and making consistent decisions in several link layers, the IP decisions between different layers, different mobility mechanisms,
layers, different mobility mechanisms in those layers, and IPsec/IKE. and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE:
Most of those aspects are beyond the scope of MOBIKE: The MOBIKE MOBIKE focuses only on what two peers need to agree at the IKEv2
focuses on what two peers need to agree in IKEv2 level (like new level (like new message formats and some aspects of their processing)
message formats and some aspects of their processing) for required for interoperability.
interoperability.
The MOBIKE is not trying to be full mobility protocol; there is no The MOBIKE protocol is not trying to be a full mobility protocol;
support for simultaneous movement or rendezvous mechanism, and there there is no support for simultaneous movement or rendezvous
is no support for route optimization etc. This current design mechanism, and there is no support for route optimization etc. This
document focuses mainly on the tunnel mode, everything going inside current design document focuses mainly on tunnel mode, everything
the tunnel is unaffected by the changes in the tunnel header IP going inside the tunnel is unaffected by the changes in the tunnel
address, and this is the mobility feature provided by the MOBIKE. header IP address, and this is the mobility feature provided by the
I.e. the applications running through the MOBIKE IPsec tunnel cannot MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec
even detect the movement, their IP address etc stay constant. tunnel might not detect the movement since their IP addresses remain
constant.
A MOBIKE protocol should be able to perform the following operations: The MOBIKE protocol should be able to perform the following
operations:
o inform the other peer about the peer address set o Inform the other peer about the peer address set
o inform the other peer about the preferred address o Inform the other peer about the preferred address
o test connectivity along a path and thereby to detect an outage o Test connectivity along a path and thereby to detect an outage
situation situation
o change the preferred address o Change the preferred address
o change the peer address set o Change the peer address set
o Ability to deal with Network Address Translation devices o Ability to deal with Network Address Translation devices
Figure 3 shows an example protocol interaction between a pair of Figure 3 shows an example protocol interaction between a pair of
MOBIKE peers. MOBIKE interacts with the IPsec engine using the MOBIKE peers. MOBIKE interacts with the IPsec engine using for
PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon
entries in the Security Association (SAD) and Security Policy can create entries in the Security Association (SAD) and Security
Databases (SPD). The IPsec engine may also interact with IKEv2 and Policy Databases (SPD). The IPsec engine may also interact with
MOBIKE daemon using this API. The content of the Security Policy and IKEv2 and MOBIKE daemon using this API. The content of the Security
Security Association Databases determines what traffic is protected Policy and Security Association Databases determines what traffic is
with IPsec in which fashion. MOBIKE, on the other hand, receives protected with IPsec in which fashion. MOBIKE, on the other hand,
information from a number of sources that may run both in kernel-mode receives information from a number of sources that may run both in
and in user-mode. Information relevant for MOBIKE might be stored in kernel-mode and in user-mode. Information relevant for MOBIKE might
a database. The contents of such a database, along with the be stored in a database. The content of such a database, along with
occurrence of events of which the MOBIKE process is notified, form the occurrence of events of which the MOBIKE process is notified,
the basis on which MOBIKE decides regarding the set of available form the basis on which MOBIKE make decisions regarding the set of
addresses, the peer address set, and the preferred address. Policies available addresses, the peer address set, and the preferred address.
may also affect the selection process. Policies may also affect the selection process.
The a peer address set and the preferred address needs to be The peer address set and the preferred address needs to be made
available to the other peer. In order to address certain failure available to the other peer. In order to address certain failure
cases, MOBIKE should perform connectivity tests between the peers cases, MOBIKE should perform connectivity tests between the peers
(potentially over a number of different paths). Although a number of (potentially over a number of different paths). Although a number of
address pairs may be available for such tests, the most important is address pairs may be available for such tests, the most important is
the pair (source address, destination address) of the primary path. the pair (source address, destination address) of the primary path.
This is because this pair is selected for sending and receiving This is because this pair is selected for sending and receiving
MOBIKE signaling and IPsec traffic. If a problem along this primary MOBIKE signaling and IPsec traffic. If a problem along this primary
path is detected (e.g., due to a router failure) it is necessary to path is detected (e.g., due to a router failure) it is necessary to
switch to a new primary path. In order to be able to do so quickly, switch to a new primary path. In order to be able to do so quickly,
it may be helpful to perform connectivity tests of other paths it may be helpful to perform connectivity tests of other paths
periodically. Such a technique would also help in identifying periodically. Such a technique would also help in identifying
previously disconnected paths that become operational. previously disconnected paths that become operational again.
+-------------+ +---------+ +-------------+ +---------+
|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 14, line 10 skipping to change at page 14, line 10
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, certain optimizations for the scope of the working group. Finally, certain optimizations for
wireless environments are also 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. Choosing addresses 5.1. Choosing Addresses
One of the core aspects of the MOBIKE protocol is the selection of One of the core aspects of the MOBIKE protocol is the selection of
the address for the IPsec packets we send. Choosing addresses for the address for the IPsec packets we send. Choosing addresses for
the IKEv2 request is somewhat separate problem: in many cases, they the IKEv2 request is a somewhat separate problem: in many cases, they
will be the same (and in some design choice they will always be the will be the same (and in some design choice they will always be the
same). same).
5.1.1. Inputs and triggers 5.1.1. Inputs and Triggers
How the address changes are triggered are largerly beyond the scope How address changes are triggered is largely beyond the scope of
of MOBIKE. The triggers can include e.g. changes in the set of MOBIKE. The triggers can include, changes in the set of addresses,
addresses, various link-layer indications, failing dead peer various link-layer indications, failing dead peer detection, and
detection, and changes in preferences and policies. Furthermore, changes in preferences and policies. Furthermore, there may be less
there may be less reliable sources of information (such as lack of reliable sources of information (such as lack of IPsec packets and
IPsec packets and ICMP packets) that do not trigger any changes incoming ICMP packets) that do not trigger any changes directly, but
directly, but rather cause DPD to be performed sooner than it rather cause Dead Peer Detection (DPD) to be scheduled earlier and if
otherwise would have been (and if that DPD fails, that may trigger it fails it might cause a change of the preferred address.
changing of addresses).
These triggers are largerly the same as for, e.g. Mobile IP, and are These triggers are largely the same as for, e.g., Mobile IP, and are
beyond the scope of MOBIKE. beyond the scope of MOBIKE.
5.1.2. Connectivity 5.1.2. Connectivity
There can be two kind of "failures" in the connectivity; local or There can be two kinds of connectivity "failures": local failures and
middle. Local failure is a property of an address (interface), while path failures. Local failures are problems locally at an MOBIKE peer
the failures in the middle is property of address pair. MOBIKE does (e.g., an interface error). Path failures are a property of an
not assume full connectivity, but it does not try to use address pair and failures of nodes and links along this path. MOBIKE
unidirectional address pairs (multi6 has discussed about how to deal does not support unidirectional address pairs (i.e. where you can
with unidirectional paths). Unidirectional address pairs is only send traffic in one direction when using single address pair).
complicated issue, and supporting it would require abandoning the Supporting them would require abandoning the principle of sending an
principle that you always send the IKEv2 reply to the address the IKEv2 reply to the address the request came from. MOBIKE decided to
request came from. Because of that MOBIKE decided to deal only with deal only with bidirectional address pairs. It does consider
bidirectional address pairs. It does consider unidirectional address unidirectional address pairs as broken, and does not use them, but
pairs as broken, and not use them, but the connection will not break the connection between peers will not break even if unidirectional
even if unidirectional address pairs are present, provided there is address pairs are present, provided there is at least one
at least one bidirectional address pair it can use. bidirectional address pair MOBIKE can use.
Note, that MOBIKE is not really concerned about the actual path used, Note that MOBIKE is not really concerned about the actual path used,
it cannot even detect if some path is unidirectional, if the same it cannot even detect if some path is unidirectionally operational if
address pair has some other unidirectional path back. Ingress the same address pair has some other unidirectional path back.
filters might still cause such path pairs to be unusable, and in that Ingress filters might still cause such path pairs to be unusable, and
case MOBIKE will detect that there is no connection between address in that case MOBIKE will detect that there is no operational address
pair. pair.
In a sense having both IPv4 and IPv6 address is basically a case of In a sense having both an IPv4 and an IPv6 address is basically a
partial connectivity (putting both IPv4 and IPv6 address in the same case of partial connectivity (putting both an IPv4 and an IPv6
IP header does not work). The main difference is that it is known address in the same IP header does not work). The main difference is
beforehand, and there is no need to discover that IPv4/IPv6 that it is known beforehand, and there is no need to discover that
combination does not work. IPv4/IPv6 combination does not work.
5.1.3. Discovering connectivity 5.1.3. Discovering Connectivity
To detect connectivity, i.e failures in the middle, MOBIKE needs to To detect connectivity, i.e., failures along the path, the MOBIKE
have some kind of probe which it can send to the other end and get a protocol needs to have a mechanism to test connectivity. If a MOBIKE
reply back to that. If it will see the reply it knows the connection peer receives a reply it can be sure about the existence of a working
works, if it does not see the reply after multiple retransmissions it (bidirectional) address pair. If a MOBIKE peer does not see a reply
may assume that the address pair tested is broken. after multiple retransmissions it may assume that the tested address
pair is broken.
The connectivity tests do require to take in to account the The connectivity tests require congestion problems to be taken into
congestion problems, because the connection failure might be because account because the connection failure might be caused by a
of congestion, and the MOBIKE should not make it worse by sending congestion, and the MOBIKE protocol should not make the congestion
lots of probe packets. problem worse by sending lots of DPD packets.
5.1.4. Decision making 5.1.4. Decision Making
One of the core decisions to the MOBIKE protocol is to who makes the One of the main decisions in designing the MOBIKE protocol is who
decisions to fix situations, i.e. symmetry in decision making vs. makes the decisions how to fix situation when failure is detected,
asymmetry in decisions. Symmetric decision making may cause the e.g., symmetry vs. asymmetry in decision making. Symmetric decision
different peers to make different decisions, thus causing asymmetric making (i.e. both peers can make decisions) may cause the different
upstream/downstream traffic. In mobility case it is desirable that peers to make different decisions, thus causing asymmetric upstream/
the mobile peer can move both upstream and downstream traffic to some downstream traffic. In mobility case it is desirable that the mobile
particular interface, and this requires asymmetric decision making. peer can move both upstream and downstream traffic to some particular
interface, and this requires asymmetric decision making (i.e. only
one peer makes decisions.
Working with stateful packet filters and NATs is easier if same Working with stateful packet filters and NATs is easier if the same
address pair is used in both upstream and downstream directions. address pair is used in both upstream and downstream directions.
Also in common cases only the peer behind NAT can actually do actions Also in common cases only the peer behind NAT can actually perform
to recover from the connectivity problems, as it might be that the actions to recover from the connectivity problems, as it might be
other peer is not able to initiate any connections to the peer behind that the other peer is not able to initiate any connections to the
NAT. peer behind NAT.
5.1.5. Suggested approach 5.1.5. Suggested Approach
Because of those issues listed above, the MOBIKE protocol decided to The working group decided to select a method where the initiator will
select method where the initiator will decide which addresses are decide which addresses are used. As a consequence the outcome cannot
used. This has the benefits that it makes one peer to decide, thus be asymmetric decisions. It also works best with NATs, as the
we cannot end up in the asymmetric decisions, and it also works best initiator is most likely the node that is located behind a NAT.
with NATs, as the initiator is the most common peer to be behind NAT,
and thus is the only peer which can recover in those cases.
5.2. NAT Traversal 5.2. NAT Traversal
5.2.1. Background and constraints 5.2.1. Background and Constraints
Another core aspect of the MOBIKE was the co-operation and working Another core aspect of MOBIKE is the treatment of different NATs and
with NATs. In IKEv2 the tunnel header IP addresses are not sent NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside
inside the IKEv2 payloads, and thus there is no need to do unilateral the IKEv2 payloads, and thus there is no need to do unilateral self-
self-address fixing (UNSAF). The tunnel header IP addresses are address fixing (UNSAF). The tunnel header IP addresses are taken
taken from the outer IP header of the IKE packets, thus they are from the outer IP header of the IKE packets, thus they are already
already processed by the NAT. processed by the NAT.
The NAT detection payloads are used to detect if the addresses in the The NAT detection payloads are used to determine whether the
IP header were modified by a NAT between the peers, and that enables addresses in the IP header were modified by a NAT along the path.
UDP encapsulation of ESP packets if needed. MOBIKE is not to change Detecting a NAT typically requires UDP encapsulation of IPsec ESP
how IKEv2 NAT-T works, in particular, any kind of UNSAF or explicit packets to be enabled, if desired. MOBIKE is not to change how IKEv2
interaction with NATs (e.g. midcom or nsis natfw) are beyond the NAT-T works, in particular, any kind of UNSAF or explicit interaction
scope. The MOBIKE will need to define how MOBIKE and NAT-T are used with NATs (e.g., MIDCOM or NSIS NATFW NSLP) are beyond the scope of
together. MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE
and NAT-T are used together.
The NAT-T support should also be optional, i.e. if the IKEv2 The NAT-T support should also be optional, i.e., if the IKEv2
implementation does not implement NAT-T, since it is not required in implementation does not implement NAT-T, as it is not required in
some particular environment, implementing MOBIKE should not require some particular environment, implementing MOBIKE should not require
adding support for NAT-T as well. adding support for NAT-T as well.
The property of being behind NAT is actually property of the address The property of being behind NAT is actually a property of the
pair, thus one peer can have multiple IP-addresses and some of those address pair and thereby by the path taken by a packet, thus one peer
might be behind NAT and some might not be behind NAT. can have multiple IP addresses and some of those might be behind NAT
and some might not.
5.2.2. Fundamental restrictions 5.2.2. Fundamental Restrictions
There are some cases which cannot be made work with the restrictions There are some cases which cannot be carried out within the
provided by the MOBIKE charter. One of those cases is the case where restrictions of the MOBIKE charter. One of those cases is the case
the party "outside" a symmetric NAT changes its address to something where the party "outside" a symmetric NAT changes its address to
not known by the the other peer (and old address has stopped something not known by the the other peer (and old address has
working). It cannot send a packet containing the new addresses to stopped working). It cannot send a packet containing the new
the peer, because the NAT does not contain the necessary state. addresses to the peer because the NAT does not contain the necessary
Furthermore, since the party behind the NAT does not know the new IP state. Furthermore, since the party behind the NAT does not know the
address, it cannot cause the NAT state to be created. new IP address, it cannot cause the NAT state to be created.
This case could be solved using some rendezvous mechanism outside This case could be solved using some rendezvous mechanism outside
IKEv2, but that is beyond the scope of MOBIKE. IKEv2, but that is beyond the scope of MOBIKE.
5.2.3. Moving to behind NAT and back 5.2.3. Moving to behind a NAT and back
MOBIKE provides mechanism where peer not initially behind the NAT, The MOBIKE protocol should provide a mechanism where a peer that is
can move to behind NAT, when new address pair is selected. MOBIKE initially not behind a NAT can move behind NAT, when a new preferred
does not need to detect when someone attach NAT to the currently address is selected. The same effect might be accomplished with the
working address pair, i.e. the NAT detection is only done when MOBIKE change of the address pair if more than one path is available (e.g.,
changes the address pair used. in case of a multi-homed host). An impact for the MOBIKE protocol is
only caused when the currently selected address pair causes MOBIKE
packets to traverse a NAT.
Similarly the MOBIKE provides mechanism to move from the address pair Similarly the MOBIKE protocol provides a mechanism to detect when a
having NAT to the address pair not having NAT. NATed path is changed to a non-NATed path with the change of the
addressed pair.
As we only use one address pair at time, effectively MOBIKE peer is As we only use one address pair at time, effectively the MOBIKE peer
either behind NAT or not behind NAT, but each address change can is either behind NAT or not behind NAT, but each address change can
change the situation. Because of this and because initiator always change this situation. Because of this and because the initiator
chooses the addresses it is enough to send keepalive packets only to always chooses the addresses it is enough to send keepalive packets
that one address pair. only to that one address pair.
5.2.4. Responder behind NAT Enabling NAT-T involves a few different things, one is to enable the
UDP encapsulation of ESP packets. Another is to change the IKE SA
ports from port 500 to port 4500. We do not want to do unnecessary
UDP encapsulation unless there is really a NAT between peers, i.e.
UDP encapsulation should only be enabled when we actually detect NAT.
On the other hand, as all implementations supporting NAT-T must be
able to respond to port 4500 all the time, it is simpler from the
protocol point of view to change the port numbers from 500 to 4500
immediately when we detect that the other end supports NAT-T. This
way we do not need to start changing ports after we later detected
NAT, which would have caused complications to the protocol.
If we would do the actual changing of the port only after we detect
NAT, then the responder would not be able to use the IKE and IPsec
SAs immediately after their address is changed to be behind NAT.
Instead it would need to wait for the next packet from the initiator
to see what IP and port numbers are used after the initiator changed
its port from 500 to 4500. The responder would also not be able to
send anything to the initiator before the initiator has sent
something to the responder. If we do the port number changing
immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we
get the rid of this problem.
5.2.4. Responder behind a NAT
MOBIKE can work in cases where the responder is behind static NAT, MOBIKE can work in cases where the responder is behind static NAT,
but in that case the initiator needs to know all possible addresses but in that case the initiator needs to know all the possible
where the responder can move to, i.e. responder cannot move to the addresses where the responder can move to, i.e. the responder cannot
address which is not known by the initiator. move to an address which is not known by the initiator, in case
initiator also moves behind NAT.
If the responder is behind NAPT then it might need to communicate If the responder is behind NAPT then it might need to communicate
with the NAT to create mapping so initiator can connect to it. Those with the NAT to create a mapping so the initiator can connect to it.
external hole punching mechanisms are beyond the scope of MOBIKE. Those external hole punching mechanisms are beyond the scope of
MOBIKE.
In case the responder is behind NAPT then also finding the port In case the responder is behind NAPT, then also finding the port
numbers used by the responder, is outside the scope of MOBIKE. numbers used by the responder is outside the scope of MOBIKE.
5.2.5. NAT Prevention 5.2.5. NAT Prevention
One new feature created by the MOBIKE, is the NAT prevention, i.e. if One new feature created by MOBIKE is NAT prevention, i.e. if we
we detect NAT between the peers, we do not allow that address pair to detect NAT between the peers, we do not allow that address pair to be
be used. This can be used to protect IP-addresses in cases where it used. This can be used to protect IP addresses in cases where it is
is known by the configuration that there is no NAT between the nodes known by the configuration that there is no NAT between the nodes
(for example IPv6, or fixed site-to-site VPN). This gives extra (for example IPv6, or fixed site-to-site VPN). This gives extra
protection against 3rd party bombing attacks (attacker cannot divert protection against 3rd party bombing attacks (the attacker cannot
the traffic to some 3rd party). This feature means that we divert the traffic to some 3rd party). This feature means that we
authenticate the IP-address and detect if they were changed. As this authenticate the IP-address and detect if they were changed. As this
is done on purpose to break the connectivity if NAT is detect, and is done on purpose to break the connectivity if NAT is detected, and
decided by the configuration, there is no need to do UNSAF decided by the configuration, there is no need to do UNSAF
processing. processing.
5.2.6. Suggested approach 5.2.6. Suggested Approach
The working group decided that MOBIKE uses NAT-T mechanisms from the The working group decided that MOBIKE uses NAT-T mechanisms from the
IKEv2 protocol as much as possible, but decided to change the dynamic IKEv2 protocol as much as possible, but decided to change the dynamic
address update for IKEv2 packets to MUST NOT (it would break path address update for IKEv2 packets to MUST NOT (it would break path
testing using IKEv2 packets). Working group also decided to only testing using IKEv2 packets, see Section 6.2). The working group
send keepalives to the current address pair. also decided to only send keepalives to the current address pair.
5.3. Scope of SA changes 5.3. 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 in the database entries that updating and maintaining addresses in the database entries that
relate to an IKE-SA. However, changing the preferred address also relate to an IKE SA. However, changing the preferred address also
affects the entries of the IPsec SA database. The outer tunnel affects the entries of the IPsec SA database. The outer tunnel
header addresses (source and destination IP addresses) need to be header addresses (source and destination IP addresses) need to be
modified according to the primary path to allow the IPsec protected modified according to the primary path to allow the IPsec protected
data traffic to travel along the same path as the MOBIKE packets (if data traffic to travel along the same path as the MOBIKE packets. If
we only consider the IP header information). If the MOBIKE messages the MOBIKE messages and the IPsec protected data traffic travel along
and the IPsec protected data traffic travel along a different path a different path then NAT handling is severely complicated.
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). One option is that when the IKE SA address is changed then traffic). One option is that when the IKE SA address is changed,
automatically all IPsec SAs associated with it are moved along with then all IPsec SAs associated with it are automatically moved along
it to new address pair. Another option is to have a separate with it to a new address pair. Another option is to have a separate
exchange to move the IPsec SAs separately. 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 the notification payload is needed to preserve bandwidth. format than the Notify payload is needed to preserve bandwidth. A
A notification payload can only store one SPI per payload. A Notify payload can only store one SPI per payload. A separate
separate payload could have list of IPsec SA SPIs and new preferred payload could have a list of IPsec SA SPIs and the new preferred
address. If there is a large number of IPsec SAs, those payloads can address. If there is a large number of IPsec SAs, those payloads can
be quite large unless ranges of SPI values are supported. If we be quite large unless ranges of SPI values are supported. If we
automatically move all IPsec SAs when the IKE SA moves, then we only automatically move all IPsec SAs when the IKE SA moves, then we only
need to keep track which IKE SA was used to create the IPsec SA, and need to keep track of which IKE SA was used to create the IPsec SA,
fetch the IP addresses from IKE SA, i.e. no need to store IP and fetch the IP addresses from the IKE SA, i.e. there is no need to
addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-ikev2] store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-
already requires implementations to keep track which IPsec SAs are ikev2] already requires the implementations to keep track which IPsec
created using which IKE SA. SAs are created using which IKE SA.
If we do allow each IPsec SA address set to be updated separately, If we do allow address set of each IPsec SA 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
cheap connections and slow and/or expensive connections, and it wants connections and slow and/or expensive connections, and wants to allow
to allow moving some of the SAs to the slower and/or more expensive 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 has 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 has only the fast and/or cheap connection, which is then used for
that kind of bulk traffic. that kind of bulk traffic.
MOBIKE protocol decided to move all IPsec SAs implicitly when the IKE The working group decided to move all IPsec SAs implicitly when the
SA address pair changes. If more granular handling of the IPsec SA IKE SA address pair changes. If more granular handling of the IPsec
is required, then multiple IKE SAs can be created one for each set of SA is required, then multiple IKE SAs can be created one for each set
IPsec SAs needed. of IPsec SAs needed.
5.4. Zero address set functionality 5.4. Zero Address Set Functionality
One of the features which is potentially useful is for the peer to One of the features which is potentially useful is for the peer to
announce that it will now disconnect for some time, i.e. it will not announce that it will now disconnect for some time, i.e. it will not
be reachable at all. For instance, a laptop might go to suspend be reachable at all. For instance, a laptop might go to suspend
mode. In this case the it could send address notification with zero mode. In this case it could send address notification with zero new
new addresses, which means that it will not have any valid addresses addresses, which would mean that it will not have any valid addresses
anymore. The responder of that kind of notification would then anymore. The responder of that kind of notification would then
acknowledge that, and could then temporarily disable all SAs and acknowledge that, and could then temporarily disable all SAs and
therefore stop sending traffic. If any of the SAs gets any packets therefore stop sending traffic. If any of the SAs gets any packets
they are simply dropped. This could also include some kind of ACK they are simply dropped. This could also include some kind of ACK
spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP spoofing to keep the TCP/IP sessions alive (or simply setting the
keepalives and timeouts large enough not to cause problems), or it TCP/IP keepalives and timeouts large enough not to cause problems),
could simply be left to the applications, e.g. allow TCP/IP sessions or it could simply be left to the applications, e.g. allow TCP/IP
to notice the link is broken. sessions to notice if the link is broken.
The local policy could then indicate how long the peer should allow The local policy could then indicate how long the peer should allow
remote peers to remain disconnected. remote peers to remain disconnected.
From a technical point of view this feature addresses two aspects: From a technical point of view this feature addresses two issues:
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 can be dropped which saves bandwidth. This does not provide data can be dropped which saves bandwidth. This does not provide
a functional benefit, i.e., nothing breaks if this feature is not a functional benefit, i.e., nothing breaks if this feature is not
provided. provided.
o MOBIKE signaling messages are also ignored. The IKE-SA must not o MOBIKE signaling messages are also ignored. The IKE-SA must not
be deleted and the suspend functionality (realized with the zero be deleted and the suspend functionality (realized with the zero
address set) may require the IKE-SA to be tagged with a lifetime address set) may require the IKE-SA to be tagged with a lifetime
value since the IKE-SA should not be kept in alive for an value since the IKE-SA should not be kept alive for an undefined
undefined period of time. Note that IKEv2 does not require that period of time. Note that IKEv2 does not require that the IKE-SA
the IKE-SA has a lifetime associated with it. In order to prevent has a lifetime associated with it. In order to prevent the IKE-SA
the IKE-SA from being deleted the dead-peer detection mechanism from being deleted the dead-peer detection mechanism needs to be
needs to be suspended as well. suspended as well.
Due to the fact that this extension could be complicated and there Due to the fact that this extension could be complicated and there
was no clear need for it, a first version of the MOBIKE protocol will was no clear need for it, a first version of the MOBIKE protocol will
not provide this feature. not provide this feature.
5.5. Return routability test 5.5. Return Routability Check
Changing the preferred address and subsequently using it 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 these questions:
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] introduced this approach. If the other peer is, for
example, a security gateway with a limited set of fixed IP 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 appear in the certificate. all the IP addresses appearing in the certificate.
o A return routability check is performed by the remote peer before o A return routability check is performed by the remote peer before
the address is updated in that peer's Security Association the address is updated in that peer's Security Association
Database. This is done in order provide a certain degree of Database. This is done in order provide a certain degree of
confidence to the remote peer that local peer is reachable at the confidence to the remote peer that local peer is reachable at the
indicated address. indicated address.
Without taking 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.
A MOBIKE peer should not use an IP addressed provided by another A MOBIKE peer should not use an IP addressed provided by another
MOBIKE peer as a primary address without computing the authorization MOBIKE peer as a primary address without computing the authorization
decision. If the addresses are part of the certificate then it is decision. If the addresses are part of the certificate then it is
not necessary to execute the weaker return-routability test. The not necessary to execute the weaker return routability check. The
return-routability test is a form of authorization check, although it return routability check is a form of authorization check, although
provides weaker guarantees then the inclusion of the IP address as it provides weaker guarantees than the inclusion of the IP address as
part of a certificate. If multiple addresses are communicated to the a part of a certificate. If multiple addresses are communicated to
remote peer then some of these addresses may be already verified even the remote peer then some of these addresses may be already verified
if the primary address is still operational. 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 perform a return routability test only when an which suggests to perform a return routability check only when an
address update needs to be sent from some address other than the address update needs to be sent from some address other than the
indicated 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 we only move to the at all. In case of indirect change notifications we only move to the
new preferred address after successful dead-peer detection (i.e., a new preferred address after successful dead-peer detection (i.e., a
response to a DPD test) on the new address, which is already a return response to a DPD test) on the new address, which is already a return
routability check. With a direct notification the authenticated peer routability check. With a direct notification the authenticated peer
may have provided an authenticated IP address. Thus it is would be may have provided an authenticated IP address (i.e. inside IKE
possible to simply trust the MOBIKE peer to provide a proper IP encrypted and authenticated payload, see Section 5.2.5). Thus it is
address. There is no way an adversary can successfully launch an would be possible to simply trust the MOBIKE peer to provide a proper
attack by injecting faked addresses since it does not know the IKE SA IP address. In this case A protection against an internal attacker,
and the corresponding keying material. A protection against an i.e. the authenticated peer forwarding its traffic to the new
internal attacker, i.e. the authenticated peer forwarding its traffic address, would not provided. On the other hand we know the identity
to the new address, is not provided. This might be an issue when of the peer in that case. There might be problems when extensions
extensions are added to IKEv2 that do not require authentication of are added to IKEv2 that do not require authentication of end points
end points (e.g., opportunistic security using anonymous Diffie- (e.g., opportunistic security using anonymous Diffie-Hellman).
Hellman). On the other hand we know the identity of the peer in that
case.
There is also a policy issue when to schedule a return routability There is also a policy issue of when to schedule a return routability
test. Before moving traffic? After moving traffic? check. Before moving traffic? After moving traffic?
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. There are potential attacks if a return dead-peer detection, but potential attacks are possible if a return
routability check does not include some kind of nonce. The valid end routability check does not include some kind of a nonce. In these
point could send an address update notification for a third party, attacks the valid end point could send an address update notification
trying to get all the traffic to be sent there, causing a denial of for a third party, trying to get all the traffic to be sent there,
service attack. If the return routability checks does not contain causing a denial of service attack. If the return routability check
any cookies or other random information not known to the other end, does not contain any nonce or other random information not known to
then that valid node could reply to the return routability checks the other peer, then other peer could reply to the return routability
even when it cannot see the request. This might cause a peer to move checks even when it cannot see the request. This might cause a peer
the traffic to a location where the original recipient cannot be to move the traffic to a location where the original recipient cannot
reached. be reached.
The IKEv2 NAT-T mechanism does not perform return routability checks. The IKEv2 NAT-T mechanism does not perform return routability checks.
It simply uses the last seen source IP address used by the other peer It simply uses the last seen source IP address used by the other peer
as the destination address to send response packets. An adversary as the destination address to send response packets. An adversary
can change those IP addresses, and can cause the response packets to can change those IP addresses, and can cause the response packets to
be sent to wrong IP address. The situation is self-fixing when the be sent to a wrong IP address. The situation is self-fixing when the
adversary is no longer able to modify packets and the first packet adversary is no longer able to modify packets and the first packet
with an unmodified IP address reaches the other peer. Mobility with an unmodified IP address reaches the other peer. Mobility
environments make this attack more difficult for an adversary since environments make this attack more difficult for an adversary since
it requires the adversary to be located somewhere on the individual the attack requires the adversary to be located somewhere on the
paths ({CoA1, ..., CoAn} towards the destination IP address) have a individual paths ({CoA1, ..., CoAn} towards the destination IP
shared path or if the adversary is located near the MOBIKE client address), have a shared path or, if the adversary is located near the
then it needs to follow the user mobility patterns. With IKEv2 MOBIKE client then it needs to follow the user mobility patterns.
NAT-T, the genuine client can cause third party bombing by 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 a 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 mechanism it should protect against these attacks. NAT-T mechanism it should protect against these attacks.
There may be return routability information available from the other There may be return routability information available from the other
parts of the system too (as shown in Figure 3), but the checks done parts of the system too (as shown in Figure 3), but the checks done
may have a different quality. There are multiple levels for return may have a different quality. There are multiple levels for return
routability checks: routability checks:
o None, no tests o None, no tests
o A party willing to answer the return routability check is located o A party willing to answer the return routability check is located
along the path to the claimed address. This is the basic form of along the path to the claimed address. This is the basic form of
return routability test. return routability check.
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, integrity and replay protected. authenticated, integrity and replay protected.
o There was an authenticated, integrity and replay protected answer o There was an authenticated, integrity and replay protected answer
from the peer, but it is not guaranteed to originate at the tested from the peer, but it is not guaranteed to originate at the tested
address or path to it (because the peer can construct a response address or path to it (because the peer can construct a response
without seeing the request). without seeing the request).
The 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 carried inside the MOBIKE payload, If the address to be tested is carried inside the MOBIKE payload,
then the adversary cannot forward packets. Thus 3rd party bombings then the adversary cannot forward packets. Thus 3rd party bombings
are prevented. are prevented (see Section 5.2.5).
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 a guarantee that there is a node at Other levels might only provide a guarantee that there is a node at
the IP address which replied to the request. There is no indication the IP address which replied to the request. There is no indication
as to whether or not the reply is fresh, and whether or not the as to whether or not the reply is fresh, and whether or not the
request may have been transmitted from a different source address. request may have been transmitted from a different source address.
5.5.1. Employing MOBIKE results in other protocols 5.5.1. 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
a remote address through a return routability check, can this a remote address through a return routability check, can this
information be 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 are unaware of the outer addresses or their status. tunnel are unaware of the outer addresses or their 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 unaware informed -- all application protocols at the other side are 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 potentially be useful for SCTP to learn about the together, it would potentially be useful for SCTP dynamic address
new addresses at the same time as MOBIKE. Similarly, various IP reconfiguration [I-D.ietf-tsvwg-addip-sctp] to learn about the new
layer mechanisms may make use of the fact that a return routability addresses at the same time as MOBIKE. Similarly, various IP layer
test of a specific type has been performed. However, care should be mechanisms may make use of the fact that a return routability check
of a specific type has been performed. However, care should be
exercised in all these situations. exercised in all these situations.
[I-D.crocker-celp] discusses the use of common locator information [I-D.crocker-celp] discusses the use of common locator information
pools in a IPv6 multi-homing context; it assumed that both transport pools in a IPv6 multi-homing context; it assumed that both transport
and IP layer solutions are be used in order to support multi-homing, and IP layer solutions are used in order to support multi-homing, and
and that it would be beneficial for different protocols to coordinate that it would be beneficial for different protocols to coordinate
their results in some way, for instance by sharing throughput their results in some way, for instance by sharing throughput
information of address pairs. This may apply to MOBIKE as well, information of address pairs. This may apply to MOBIKE as well,
assuming it co-exists with non-IPsec protocols that are faced with assuming it co-exists with non-IPsec protocols that are faced with
the same or similar multi-homing 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.
5.5.2. Suggested approach 5.5.2. Return Routability Failures
MOBIKE protocol selected to use IKEv2 INFORMATIONAL exchanges as a If the return routability check fails, we need to tear down the IKE
return routability tests, but added random cookie there to prevent SA if we are using IKEv2 INFORMATIONAL exchanges to send return
redirections done by authenticated attacker. Return routability routability checks. On the other hand return routability check can
tests are done by default before moving the traffic. However these only fail permanently if there was an attack by the other end, thus
tearing down the IKE SA is a suitable action in that case.
There are some cases where the return routability check temporarily
fails that need to be considered here. In the first case there is no
attacker, but the selected address pair stops working immediately
after the address update, before the return routability check.
What happens there is that the initiator does the normal address
update, and that succeeds, and then the responder starts a return
routability check. If the address pair has broken down before that,
the responder will never get back the reply to the return routability
check. The responder might still be using the old IP address pair,
which could still work.
The initiator might be still seeing traffic from the responder, but
using the old address pair. The initiator should detect that this
traffic is not using the latest address pair, and after a while it
should start dead peer detection on the current address pair. If
that fails, then it should find a new working address pair, and
update addresses to that. The responder should notice that the
address pair was updated after the return routability check was
started, and change the ongoing return routability check to use the
new address pair. The result of that return routability check needs
to be discarded as it cannot be trusted as the packets were
retransmitted to a different IP address. So normally the responder
starts a new return routability check after that with the new address
pair.
The second case is where there is an attacker along the path
modifying the IP addresses. The peers will detect this as NAT and
will enable NAT-T recovery of changes in the NAT mappings. If the
attacker is along the path long enough for the return routability
check to succeed, then the normal recovery of changes in the NAT
mappings will take care of the problem. If the attacker disappears
before return routability check is finished, but after the update we
have almost a similar case than last time. Now the only difference
is now that the dead peer detection started by the initiator will
succeed, as the responder will reply to the addresses in the headers,
not the current address pair. The initiator will then detect that
the NAT mappings are changed, and it will fix the situation by doing
an address update.
The important thing for both of these cases is that the initiator
needs to see that the responder is both alive and synchronized with
initiator address pair updates. I.e. it is not enough that the
responder is sending traffic to an initiator, it must be also using
the correct IP addresses before the initiator can belive it is alive
and synchronized. From the implementation point of view this means
that the initiator must not consider packets having wrong IP
addresses as packets that prove the other end being alive, i.e. they
do not reset the dead peer detection timers.
5.5.3. Suggested Approach
The working group selected to use IKEv2 INFORMATIONAL exchanges as a
return routability check, but included a random cookie to prevent
redirections by an authenticated attacker. Return routability checks
are performed by default before moving the traffic. However these
tests are optional. Nodes MAY also perform these tests upon their tests are optional. Nodes MAY also perform these tests upon their
own initiative at other times. own initiative at other times.
It is worth noting that the return routability test in MOBIKE is not It is worth noting that the return routability check in MOBIKE is not
he same as return routability test in MIP6: The MIP6 WG decided that the same as the return routability check in MIP6: The MIP6 WG decided
it is not necessary to do return routability tests between the mobile that it is not necessary to do return routability checks between the
node and the home agent at all. mobile node and the home agent at all.
5.6. IPsec Tunnel or Transport Mode 5.6. 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 behavior would also be useful, but will tunnel mode. Transport mode behavior would also be useful, but will
be discussed in future documents. be discussed in future documents.
6. Protocol detail issues 6. Protocol Details
6.1. Indicating support for mobike 6.1. Indicating Support for MOBIKE
In order for MOBIKE to function, both peers must implement the MOBIKE In order for MOBIKE to function, both peers must implement the MOBIKE
extension of IKEv2. If one or none of the peers supports MOBIKE, extension of IKEv2. If one of the peers does not support MOBIKE,
then, whenever an IP address changes, IKEv2 will have to be re-run in then, whenever an IP address changes, IKEv2 will have to be re-run in
order to create a new IKE SA and the respective IPsec SAs. In order to create a new IKE SA and the respective IPsec SAs. In
MOBIKE, a peer needs to be confident that its address change messages MOBIKE, a peer needs to be confident that its address change messages
are understood by the other peer. If these messages are not are understood by the other peer. If these messages are not
understood, it is possible that connectivity between the peers is understood, it is possible that connectivity between the peers is
lost. lost.
One way to ensure that a peer receives feedback on whether or not its One way to ensure that a peer receives feedback on whether its
messages are understood by the other peer, is by using IKEv2 messages are understood by the other peer, is by using IKEv2
messaging for MOBIKE and to mark some messages as "critical". messaging for MOBIKE and to mark some messages as "critical".
According to the IKEv2 specification, such messages either have to be According to the IKEv2 specification, such messages either have to be
understood by the receiver, or an error message has to be returned to understood by the receiver, or an error message has to be returned to
the sender. the sender.
A second way to ensure receipt of the above-mentioned feedback is by A second way to ensure receipt of the above-mentioned feedback is by
using Vendor ID payloads that are exchanged during the initial IKEv2 using Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a given exchange. These payloads would then indicate whether or not a given
peer supports the MOBIKE protocol. peer supports the MOBIKE protocol.
A third approach would use the Notify payload which is also used for A third approach would use the Notify payload to indicate support of
NAT detection (via NAT_DETECTION_SOURCE_IP and MOBIKE extension, such Notify payloads are also used for indicating
NAT traversal support (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP payloads). NAT_DETECTION_DESTINATION_IP payloads).
Both a Vendor ID and a Notify payload may 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 a MOBIKE peer could also attempt to execute MOBIKE Note that a MOBIKE peer could also attempt to execute MOBIKE
opportunistically with the critical bit set when an address change opportunistically with the critical bit set when an address change
has occurred. The drawback of this approach is, however, that an has occurred. The drawback of this approach is, however, that an
unnecessary message exchange is introduced. unnecessary message exchange is introduced.
Although Vendor ID payloads and Notifications are technically Although Vendor ID payloads and Notify payloads are technically
equivalent, Notifications are already used in IKEv2 as a capability equivalent, Notify payloads are already used in IKEv2 as a capability
negotiation mechanism. Hence, notification payloads are used in the negotiation mechanism. Hence, Notify payloads are used in MOBIKE to
MOBIKE to indicate support of it. indicate support of MOBIKE protocol.
Also as the information of the support of the MOBIKE is not needed Also, as the information of the support of MOBIKE is not needed
during the IKE_SA_INIT exchange, the indication of the support is during the IKE_SA_INIT exchange, the indication of the support is
done inside the IKE_AUTH exchange. The reason for this is to need to done inside the IKE_AUTH exchange. The reason for this is the need
keep the IKE_SA_INIT messages as small as possible, so they do not to keep the IKE_SA_INIT messages as small as possible so that they do
get fragmented. The idea is that responder can do stateless not get fragmented. IKEv2 allows that the responder can do stateless
processing of the first IKE_SA_INIT packet, and request cookie from processing of the first IKE_SA_INIT packet, and request a cookie from
the other end if it is under attack. To mandate responder to be able the other end if it is under attack. To mandate the responder to be
to reassemble initial IKE_SA_INIT packets would not allow fully able to reassemble initial IKE_SA_INIT packets would not allow fully
stateless processing of the initial IKE_SA_INIT packets. stateless processing of the initial IKE_SA_INIT packets.
6.2. Path Testing and Window size 6.2. Path Testing and Window size
As the IKEv2 has the window of outgoing messages, and the sender is As IKEv2 has a window of outgoing messages, and the sender is not
not allowed to violate that window (meaning, that if the window is allowed to violate that window (meaning, that if the window is full,
full, then he cannot send packets), it do cause some complications to then the sender cannot send packets), it can cause some complications
the path testing. The another complication created by IKEv2 is that to path testing. Another complication created by IKEv2 is that once
once the message is first time sent to the other end, it cannot be the message is created and sent to the other end, it cannot be
modified in its future retransmissions. This makes it impossible to modified in its future retransmissions. This makes it impossible to
know what packet actually reached first to the other end. We cannot know what packet actually reached the other end first. We cannot use
use IP headers to find out which packet reached the other end first, IP headers to find out which packet reached the other end first, as
as if responder gets retransmissions of the packet it has already if the responder gets retransmissions of the packet it has already
replied (and those replies might have been lost due unidirectional processed and replied to (and those replies might have been lost due
address pair), it will retransmit the previous reply using the new unidirectional address pair), it will retransmit the previous reply
address pair of the request. Because of this it might be possible using the new address pair of the request. Because of this it might
that the responder has already used the IP-address information from be possible that the responder has already used the IP address
the header of the packet, and the reply packet ending up to the information from the header of the previous packet, and the reply
initiator has different address pair. packet ending up to the initiator has a different address pair.
Another complication comes from the NAT-T. The current IKEv2 Another complication comes from NAT-T. The current IKEv2 document
document says that if NAT-T is enabled the node not behind NAT SHOULD says that if NAT-T is enabled the node not behind NAT SHOULD detect
detect if the IP-address changes in the incoming authenticated if the IP-address changes in the incoming authenticated packets, and
packets, and update the remote peers addresses accordingly. This update the remote peers' addresses accordingly. This works fine with
works fine with the NAT-T, but it causes some complications in the NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs
MOBIKE, as it needs an ability to probe the another address pairs, the ability to probe another address pairs without breaking the old
without breaking the old one. one.
One approach to fix those would be to add completely new protocol One approach to fix this would be to add a completely new protocol
that is outside the IKE SA message id limitations (window code), that is outside the IKE SA message id limitations (window code),
outside identical retransmission requirements, and outside the outside identical retransmission requirements, and outside the
dynamic address updating of the NAT-T. dynamic address updating of NAT-T.
Another approach is to make the protocol so that it does not violate Another approach is to make the protocol so that it does not violate
window restrictions and does not require changing the packet is sent, window restrictions and does not require changing the packet on
and change the dynamic address updating of NAT-T to MUST NOT in case retransmissions, and change the dynamic address updating of NAT-T to
MOBIKE is used. To not to violate window restrictions, it means that MUST NOT for IKE SA packets if MOBIKE is used. In order to not
the addresses of the currently ongoing exchange needs to be changed, violate window restrictions, the addresses of the currently ongoing
to test different paths. To not to require changing the packet after exchange need to be changed to test different paths. In order to not
it is first sent, requires that the protocol needs to restart from require changing the packet after it is first sent requires that the
the beginning in case packet was retransmitted to different addresses protocol needs to restart from the beginning in case the packet was
(so sender does not know which packet was the one that responder got retransmitted to different addresses (because the sender does not
first, i.e. which IP-addresses it used). know which packet was the one that responder got first, i.e. which
IP-addresses it used).
MOBIKE protocol decided to use normal IKEv2 exchanges for the path Working group decided to use normal IKEv2 exchanges for path testing,
testing, and decided to change the dynamic address updating of NAT-T and decided to change the dynamic address updating of NAT-T to MUST
to MUST NOT. NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not
adopted.
6.3. Message presentation 6.3. Message presentation
The 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 IKEv2, or via a MOBIKE-
MOBIKE specific message exchange. Using informational exchange has specific message exchange. Using an informational exchange has the
the main advantage that it is already specified in the IKEv2 and main advantage that it is already specified in the IKEv2 protocol and
implementations incorporate the functionality already. implementations can already incorporate the functionality.
Another question is the format of the address update notifications. Another question is the format of the address update notifications.
The address update notifications can include multiple addresses, of The address update notifications can include multiple addresses, of
which some may be IPv4 and some IPv6 addresses. The number of which some may be IPv4 and some IPv6 addresses. The number of
addresses is most likely going to be limited in typical environments addresses is most likely going to be limited in typical environments
(with less than 10 addresses). The format may need to indicate a (with less than 10 addresses). The format may need to indicate a
preference value for each address. The format could either contain a preference value for each address. The format could either contain a
preference number that determines the relative order of the preference number that determines the relative order of the
addresses, or it could simply be ordered, according to preference, addresses, or it could simply be an ordered list of IP addresses. If
list of IP addresses. While two addresses can have the same using preference numbers, then two addresses can have the same
preference value an ordered list avoids this situation. preference value, an ordered list avoids this situation.
Even if load balancing is currently outside the scope of MOBIKE, Load balancing is currently outside the scope of MOBIKE, however
future work might include support for it. The selected format needs future work might include support for it. The selected format needs
to be flexible enough to include additional information (e.g. to to be flexible enough to include additional information in future
enable load balancing). This may be realized with an reserved field, versions of the protocol (e.g. to enable load balancing). This may
which can later be used to store additional information. As there be realized with an reserved field, which can later be used to store
may arise other information which may have to be tied to an address additional information. As there may arise other information which
in the future, a reserved field seems like a prudent design in any may have to be tied to an address in the future, a reserved field
case. seems like a prudent design in any case.
There are two formats that place IP address lists into a message. There are two basic formats that place IP address lists into a
One includes each IP address as separate payload (where the payload message. One includes each IP address as separate payload (where the
order indicates the preference value, or the payload itself might payload order indicates the preference order, or the payload itself
include the preference value), or we can put the IP address list as might include the preference number), or we can put the IP address
one payload to the exchange, and that one payload will then have list as one payload to the exchange, and that one payload will then
internal format which includes the list of IP addresses. have an internal format which includes the list of IP addresses.
Having multiple payloads with each one having carrying one IP address Having multiple payloads with each one carrying one IP address makes
makes the protocol probably easier to parse, as we can already use the protocol probably easier to parse, as we can already use the
the normal IKEv2 payload parsing procedures. It also offers an easy normal IKEv2 payload parsing procedures. It also offers an easy way
way for the extensions, as the payload probably contains only the for the extensions, as the payload probably contains only the type of
type of the IP address (or the type is encoded to the payload type), the IP address (or the type is encoded to the payload type), and the
and the IP address itself, and as each payload already has length IP address itself, and as each payload already has a length field
associated to it, we can detect if there is any extra data after the associated to it, we can detect if there is any extra data after the
IP address. Some implementations might have problems parsing IKEv2 IP address. Some implementations might have problems parsing more
payloads that are longer than a certain threshold, but if the sender than certain number of IKEv2 payloads, but if the sender sends them
sends them in the most preferred first, the receiver can only use the in the most preferred first, the receiver can only use the first
first addresses. addresses, it was willing to parse.
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. It also avoids problems of packets more concentrated to one module.
arriving in an order different from what they were sent.
Another 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 notification 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 decided to use IKEv2 NOTIFY payloads, and put only one data Working group decided to use IKEv2 Notify payloads, and put only one
item per notify, i.e. there will be one NOTIFY payload for each item data item per notify, i.e. there will be one Notify payload for each
to be sent. item to be sent.
6.4. Updating address list 6.4. Updating address list
Because of the initiator decides, the initiator needs to know all the Because of the initiator decides all address updates, the initiator
addresses used by the responder. The responder needs also that list needs to know all the addresses used by the responder. The responder
in case it happens move to the address unknown by the initiator, and also needs that list in case it happens to move to an address not
needs to send address update notify to the initiator, and it might known by the initiator, and needs to send an address update
need to try different addresses for the initiator. notification to the initiator, and it might need to try different
addresses for the initiator.
MOBIKE could send the full peer address list every time any of the IP MOBIKE could send the full peer address list every time any of the IP
addresses changes (either addresses are added, removed, the order addresses change (either addresses are added, removed, the order
changes or the preferred address is updated) or an incremental changes or the preferred address is updated) or an incremental
update. Sending incremental updates provides more compact packets update. Sending incremental updates provides more compact packets
(meaning we can support more IP addresses), but on the other hand (meaning we can support more IP addresses), but on the other hand
have more problems in the synchronization and packet reordering this approach has more problems in the synchronization and packet
cases, i.e., the incremental updates must be processed in order, but reordering cases, i.e., incremental updates must be processed in
for full updates we can simply use the most recent one, and ignore order, but for full updates we can simply use the most recent one,
old ones, even if they arrive after the most recent one (IKEv2 and ignore old ones, even if they arrive after the most recent one
packets have message id which is incremented for each packet, thus we (IKEv2 packets have a message id which is incremented for each
know the sending order easily). packet, thus it is easy to know the sending order).
MOBIKE decided to use protocol format, where both ends can send full Working group decided to use a protocol format where both ends send a
list of their addresses to the other end, and that list overwrites full list of their addresses to the other end, and that list
the previous list. To support NAT-T the IP-addresses of the received overwrites the previous list. To support NAT-T the IP-addresses of
packet is added to the list (and they are not present in the list). the received packet is added to the list (and they are not present in
the list).
7. Security Considerations 7. Security Considerations
As all the messages are already authenticated by the IKEv2 there is As all the messages are already authenticated by IKEv2 there is no
no problem that any attackers would modify the contents of the risk that any attackers would modify the contents of the packets.
packets. The IP addresses in the IP header of the packets are not 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, and only used as an indication that something might be different, and
that do not cause any direct actions. that do not cause any direct actions, except when doing NAT
Traversal.
An attacker can also spoof ICMP error messages in an effort to An attacker can also spoof ICMP error messages in an effort to
confuse the peers about which addresses are not working. At worst confuse the peers about which addresses are not working. At worst
this causes denial of service and/or the use of non-preferred this causes denial of service and/or the use of non-preferred
addresses. 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 the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec] protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec]
and [Aur02] for more information about flooding attacks. and [Aur02] for more information about flooding attacks.
skipping to change at page 32, line 19 skipping to change at page 34, line 19
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",
draft-ietf-tsvwg-addip-sctp-12 (work in progress), draft-ietf-tsvwg-addip-sctp-13 (work in progress),
June 2005. November 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",
draft-dupont-ikev2-addrmgmt-07 (work in progress), draft-dupont-ikev2-addrmgmt-08 (work in progress),
May 2005. November 2005.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) 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", draft-ietf-ipv6-optimistic-dad-06 (work in IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in
progress), September 2005. progress), September 2005.
skipping to change at page 33, line 7 skipping to change at page 35, line 7
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management 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, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-06 (work in
progress), November 2005.
[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 FI-00100
FI FI
Email: kivinen@safenet-inc.com Email: kivinen@safenet-inc.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
 End of changes. 141 change blocks. 
455 lines changed or deleted 568 lines changed or added

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