draft-ietf-mobike-design-05.txt   draft-ietf-mobike-design-06.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: June 3, 2006 Siemens Expires: July 9, 2006 Siemens
November 30, 2005 January 5, 2006
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-05.txt draft-ietf-mobike-design-06.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 June 3, 2006. This Internet-Draft will expire on July 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) working group is The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the
developing extensions for the Internet Key Exchange Protocol version Internet Key Exchange Protocol version 2 (IKEv2). These extensions
2 (IKEv2). These extensions should enable an efficient management of should enable an efficient management of IKE and IPsec Security
IKE and IPsec Security Associations when a host possesses multiple IP Associations when a host possesses multiple IP addresses and/or where
addresses and/or where IP addresses of an IPsec host change over time IP addresses of an IPsec host change over time (for example, due to
(for example, due to mobility). mobility).
This document discusses the involved network entities, and the This document discusses the involved network entities, and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols. Design decisions for the MOBIKE protocol, other protocols. Design decisions for the MOBIKE protocol,
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
skipping to change at page 3, line 21 skipping to change at page 3, line 21
3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9 3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9
3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . 15
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 a NAT and back . . . . . . . . . . . 16 5.2.3. Moving to behind a NAT and back . . . . . . . . . . . 16
5.2.4. Responder behind a NAT . . . . . . . . . . . . . . . . 17 5.2.4. Responder behind a NAT . . . . . . . . . . . . . . . . 17
5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 18 5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Suggested Approach . . . . . . . . . . . . . . . . . . 18 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 Check . . . . . . . . . . . . . . . . . 20 5.5. Return Routability Check . . . . . . . . . . . . . . . . . 20
5.5.1. Employing MOBIKE Results in other Protocols . . . . . 23 5.5.1. Employing MOBIKE Results in other Protocols . . . . . 22
5.5.2. Return Routability Failures . . . . . . . . . . . . . 23 5.5.2. Return Routability Failures . . . . . . . . . . . . . 23
5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 25 5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 24
5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 26 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Indicating Support for MOBIKE . . . . . . . . . . . . . . 26 6.1. Indicating Support for MOBIKE . . . . . . . . . . . . . . 26
6.2. Path Testing and Window size . . . . . . . . . . . . . . . 27 6.2. Path Testing and Window size . . . . . . . . . . . . . . . 27
6.3. Message presentation . . . . . . . . . . . . . . . . . . . 28 6.3. Message presentation . . . . . . . . . . . . . . . . . . . 28
6.4. Updating address list . . . . . . . . . . . . . . . . . . 29 6.4. Updating address set . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative references . . . . . . . . . . . . . . . . . . . 33 10.1. Normative references . . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . . 33 10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37 Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
skipping to change at page 4, line 21 skipping to change at page 4, line 21
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
information about the traffic that should experience protection. information about the traffic that should experience protection.
IKEv2 assumes that an IKE SA is created implicitly between the IP IKEv2 assumes that an IKE SA is created implicitly between the IP
address pair that is used during the protocol execution when address pair that is used during the protocol execution when
establishing the IKEv2 SA. This means that, in each host, only one establishing the IKEv2 SA. This means that, in each host, only one
IP address pair is stored for the IKEv2 SA as part of a single IKEv2 IP address pair is stored for the IKEv2 SA as part of a single IKEv2
protocol session, and, for tunnel mode SAs, the hosts places this protocol session, and, for tunnel mode SAs, the hosts places this
single pair in the outer IP headers. Existing documents make no single pair in the outer IP headers. Existing IPsec documents make
provision to change this pair after an IKE SA is created. no provision to change this pair after an IKE SA is created (except
for dynamic address update of NAT-T).
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 is a relatively expensive
might be too slow for this task. Moreover, manual user interaction operation, and can be problematic when such changes are frequent.
(for example when using SecurID cards) might be required as part of Moreover, manual user interaction (for example when using human-
the IKEv2 authentication procedure. Therefore, an automatic operated token cards (SecurID)) might be required as part of the
mechanism is needed that updates the IP addresses associated with the IKEv2 authentication procedure. Therefore, an automatic mechanism is
IKE SA and the IPsec SAs. The MOBIKE protocol provides such a needed that updates the IP addresses associated with the IKE SA and
mechanism. the IPsec SAs. The MOBIKE protocol provides such a mechanism.
The work of the MOBIKE working group and therefore this document is The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As
based on the assumption that the mobility and multi-homing extensions IKEv2 is built on the architecture described in RFC2401bis [RFC4301],
are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on
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 RFC4301.
RFC2401bis. This document neither discusses mobility and multi- This document does not discusses mobility and multi-homing support
homing support for IKEv1 [RFC2409] nor the IPsec architecture for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401
described in RFC2401 [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 important terms in Section 2, a number of relevant usage scenarios
are discussed in Section 3. Section 4 describes the scope of the are discussed in Section 3. Section 4 describes the scope of the
MOBIKE protocol. Section 5 discusses design considerations affecting MOBIKE protocol. Section 5 discusses design considerations affecting
the MOBIKE protocol. Section 6 investigates details regarding the the MOBIKE protocol. Section 6 investigates details regarding the
MOBIKE protocol. Finally, this document concludes in Section 7 with MOBIKE protocol. Finally, this document concludes in Section 7 with
security considerations. 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, defined in [I-D.ietf-mobike-protocol]. 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. local-addr]. That is, it is not an IPv6 link-local 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.ietf-shim6-failure-detection]
detection], and adapted to the MOBIKE context (we do allow and adapted for the MOBIKE context.
[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.ietf-shim6-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. This differentiation might be necessary to address endpoints. This differentiation might be necessary to address
certain Network Address Translation types or specific firewalls. certain Network Address Translation types or specific firewalls.
This definition is taken from [I-D.arkko-multi6dt-failure- This definition is taken from [I-D.ietf-shim6-failure-detection]
detection] and adapted for the MOBIKE context. Although it is and adapted for the MOBIKE context. Although it is possible to
possible to further differentiate unidirectional and bidirectional further differentiate unidirectional and bidirectional operational
operational address pairs, only bidirectional connectivity is address pairs, only bidirectional connectivity is relevant to this
relevant to this document and unidirectional connectivity is out document and unidirectional 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 due to load
This definition is taken from [RFC2960] and adapted to the MOBIKE balancing. This definition is taken from [RFC2960] and adapted to
context. the MOBIKE context.
Primary Path: Current 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 Current
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.
Preferred Address: Preferred address
The IP address of a peer to which MOBIKE and IPsec traffic should The IP address of a peer to which MOBIKE and IPsec traffic should
be sent by default. A given peer has only one active preferred be sent by default. A given peer has only one active preferred
address at a given point in time, except for the small time period address at a given point in time, except for the small time period
where it switches from an old to a new preferred address. This where it switches from an old to a new preferred address. This
definition is taken from [I-D.ietf-hip-mm] and adapted to the definition is taken from [I-D.ietf-hip-mm] and adapted to the
MOBIKE context. MOBIKE context.
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.
Bidirectional Address Pair:: Bidirectional address pair
The address pair, where traffic can be sent to the both The address pair, where traffic can be sent to the both
directions, simply by reversing the IP addresses. Note, that the directions, simply by reversing the IP addresses. Note, that the
path of the packets going to each direction might be different. path of the packets going to each direction might be different.
Unidirectional Address Pair:: Unidirectional address pair
The address pair, where traffic can only be sent in one direction, The address pair, where traffic can only be sent in one direction,
and reversing the IP addresses and sending reply back does not and reversing the IP addresses and sending reply back does not
work. work.
Terminology regarding NAT types (e.g., Full Cone, Restricted Cone, For mobility related terminology (e.g., Make-before-break or Break-
Port Restricted Cone and Symmetric), can be found in Section 5 of before-make) see [RFC3753].
[RFC3489]. For mobility related terminology (e.g., Make-before-break
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,
skipping to change at page 9, line 36 skipping to change at page 9, line 36
---> = 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 address pairs 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 used for communication all the time for a number of interfaces are used for communication all the time for a number of
reasons (e.g., cost, network availability, user convenience). The reasons (e.g., cost, network availability, user convenience). The
policies that determine which interfaces are connected to the network policies that determine which interfaces are connected to the network
at any given point in time is outside the scope of the MOBIKE at any given point in time is outside the scope of the MOBIKE
protocol and, as such, this document. However, as the laptop changes protocol and, as such, this document. However, as the laptop changes
its point of attachment to the network, the set of IP addresses under its point of attachment to the network, the set of IP addresses under
which the laptop is reachable, changes too. which the laptop is reachable, changes too.
Even if IP addresses change due to interface switching or mobility, In all of these scenarios, even if IP addresses change due to
the IP address obtained via the configuration payloads within IKEv2 interface switching or mobility, the IP address obtained via the
remain unaffected. The IP address obtained via the IKEv2 configuration payloads within IKEv2 remain unaffected. The IP
configuration payloads allow the configuration of the inner IP address obtained via the IKEv2 configuration payloads allow the
address of the IPsec tunnel. As such, applications might not detect configuration of the inner IP address of the IPsec tunnel. As such,
any change at all. applications might not detect any change at all.
4. Scope of MOBIKE 4. Scope of MOBIKE
Getting mobility and multihoming actually working requires many Getting mobility and multihoming actually working requires many
different components to work together, including coordinating different components to work together, including coordinating
decisions between different layers, different mobility mechanisms, decisions between different layers, different mobility mechanisms,
and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE: and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE:
MOBIKE focuses only on what two peers need to agree at the IKEv2 MOBIKE focuses only on what two peers need to agree at the IKEv2
level (like new message formats and some aspects of their processing) level (like new message formats and some aspects of their processing)
required for interoperability. required for interoperability.
The MOBIKE protocol is not trying to be a full mobility protocol; The MOBIKE protocol is not trying to be a full mobility protocol;
there is no support for simultaneous movement or rendezvous there is no support for simultaneous movement or rendezvous
mechanism, and there is no support for route optimization etc. This mechanism, and there is no support for route optimization etc. The
current design document focuses mainly on tunnel mode, everything design document focuses on tunnel mode, everything going inside the
going inside the tunnel is unaffected by the changes in the tunnel tunnel is unaffected by the changes in the tunnel header IP address,
header IP address, and this is the mobility feature provided by the and this is the mobility feature provided by the MOBIKE, i.e.,
MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec applications running inside the MOBIKE controlled IPsec tunnel might
tunnel might not detect the movement since their IP addresses remain not detect the movement since their IP addresses remain constant.
constant.
The MOBIKE protocol should be able to perform the following The MOBIKE protocol should be able to perform the following
operations: 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 for MOBIKE peers. MOBIKE interacts with the IPsec engine using an
example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon internal API (such as those based on PF_KEY [RFC2367]). Using this
can create entries in the Security Association (SAD) and Security API, the MOBIKE module can create entries in the Security Association
Policy Databases (SPD). The IPsec engine may also interact with (SAD) and Security Policy Databases (SPD). The IPsec engine may also
IKEv2 and MOBIKE daemon using this API. The content of the Security interact with IKEv2 and MOBIKE module using this API. The content of
Policy and Security Association Databases determines what traffic is the Security Policy and Security Association Databases determines
protected with IPsec in which fashion. MOBIKE, on the other hand, what traffic is protected with IPsec in which fashion. MOBIKE, on
receives information from a number of sources that may run both in the other hand, receives information from a number of sources that
kernel-mode and in user-mode. Information relevant for MOBIKE might may run both in kernel-mode and in user-mode. Information relevant
be stored in a database. The content of such a database, along with for MOBIKE might be stored in a database. The content of such a
the occurrence of events of which the MOBIKE process is notified, database, along with the occurrence of events of which the MOBIKE
form the basis on which MOBIKE make decisions regarding the set of process is notified, form the basis on which MOBIKE make decisions
available addresses, the peer address set, and the preferred address. regarding the set of available addresses, the peer address set, and
Policies may also affect the selection process. the preferred address. Policies may also affect the selection
process.
The peer address set and the preferred address needs to be made 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 current 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 current
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 current 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 again. previously disconnected paths that become operational again.
+-------------+ +---------+ +-------------+ +---------+
|User-space | | MOBIKE | |User-space | | MOBIKE |
|Protocols | +-->>| Daemon | |Protocols | +-->>| Module |
|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
_______ | v _______ | v
+-------------+ / \ | +--------------+ +-------------+ / \ | +--------------+
|Routing | / Trigger \ | | IPsec | |Routing | / Trigger \ | | IPsec |
|Protocols |<<-->>| Database |<<-+ +>+ Engine | |Protocols |<<-->>| Database |<<-+ +>+ Engine |
skipping to change at page 13, line 43 skipping to change at page 14, line 5
s s s s
===> = IP packets arriving/leaving a MOBIKE node ===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations <-> = control and configuration operations
Figure 3: Framework Figure 3: Framework
Please note that Figure 3 illustrates an example of how a MOBIKE Please note that Figure 3 illustrates an example of how a MOBIKE
implementation could work. Hence, it serves illustrative purposes implementation could work. Hence, it serves illustrative purposes
only. only.
Extensions of the PF_KEY interface required by MOBIKE are also within
the scope of the working group. Finally, certain optimizations for
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 a 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, and could be forced to be the same by design).
5.1.1. Inputs and Triggers 5.1.1. Inputs and Triggers
How address changes are triggered is largely beyond the scope of How address changes are triggered is largely beyond the scope of
MOBIKE. The triggers can include, changes in the set of addresses, MOBIKE. The triggers can include, changes in the set of addresses,
various link-layer indications, failing dead peer detection, and various link-layer indications, failing dead peer detection, and
changes in preferences and policies. Furthermore, there may be less changes in preferences and policies. Furthermore, there may be less
reliable sources of information (such as lack of IPsec packets and reliable sources of information (such as lack of IPsec packets and
incoming ICMP packets) that do not trigger any changes directly, but incoming ICMP packets) that do not trigger any changes directly, but
rather cause Dead Peer Detection (DPD) to be scheduled earlier and if rather cause Dead Peer Detection (DPD) to be scheduled earlier and if
skipping to change at page 14, line 38 skipping to change at page 14, line 38
These triggers are largely 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 kinds of connectivity "failures": local failures and There can be two kinds of connectivity "failures": local failures and
path failures. Local failures are problems locally at an MOBIKE peer path failures. Local failures are problems locally at an MOBIKE peer
(e.g., an interface error). Path failures are a property of an (e.g., an interface error). Path failures are a property of an
address pair and failures of nodes and links along this path. MOBIKE address pair and failures of nodes and links along this path. MOBIKE
does not support unidirectional address pairs (i.e. where you can does not support unidirectional address pairs. Supporting them would
only send traffic in one direction when using single address pair). require abandoning the principle of sending an IKEv2 reply to the
Supporting them would require abandoning the principle of sending an address the request came from. MOBIKE decided to deal only with
IKEv2 reply to the address the request came from. MOBIKE decided to bidirectional address pairs. It does consider unidirectional address
deal only with bidirectional address pairs. It does consider pairs as broken, and does not use them, but the connection between
unidirectional address pairs as broken, and does not use them, but peers will not break even if unidirectional address pairs are
the connection between peers will not break even if unidirectional present, provided there is at least one bidirectional address pair
address pairs are present, provided there is at least one MOBIKE 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 concerned about the actual path used, it
it cannot even detect if some path is unidirectionally operational if cannot even detect if some path is unidirectionally operational if
the same address pair has some other unidirectional path back. the same address pair has some other unidirectional path back.
Ingress filters might still cause such path pairs to be unusable, and Ingress filters might still cause such path pairs to be unusable, and
in that case MOBIKE will detect that there is no operational address in that case MOBIKE will detect that there is no operational address
pair. pair.
In a sense having both an IPv4 and an IPv6 address is basically a In a sense having both an IPv4 and an IPv6 address is basically a
case of partial connectivity (putting both an IPv4 and an IPv6 case of partial connectivity (putting both an IPv4 and an IPv6
address in the same IP header does not work). The main difference is address in the same IP header does not work). The main difference is
that it is known beforehand, and there is no need to discover that that it is known beforehand, and there is no need to discover that
IPv4/IPv6 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 along the path, the MOBIKE To detect connectivity, the MOBIKE protocol needs to have a mechanism
protocol needs to have a mechanism to test connectivity. If a MOBIKE to test connectivity. If a MOBIKE peer receives a reply it can be
peer receives a reply it can be sure about the existence of a working sure about the existence of a working (bidirectional) address pair.
(bidirectional) address pair. If a MOBIKE peer does not see a reply If a MOBIKE peer does not see a reply after multiple retransmissions
after multiple retransmissions it may assume that the tested address it may assume that the tested address pair is broken.
pair is broken.
The connectivity tests require congestion problems to be taken into The connectivity tests require congestion problems to be taken into
account because the connection failure might be caused by a account because the connection failure might be caused by a
congestion, and the MOBIKE protocol should not make the congestion congestion, and the MOBIKE protocol should not make the congestion
problem worse by sending lots of DPD packets. problem worse by sending many of DPD packets.
5.1.4. Decision Making 5.1.4. Decision Making
One of the main decisions in designing the MOBIKE protocol is who One of the main questions in designing the MOBIKE protocol was who
makes the decisions how to fix situation when failure is detected, makes the decisions how to fix situation when failure is detected,
e.g., symmetry vs. asymmetry in decision making. Symmetric decision e.g., symmetry vs. asymmetry in decision making. Symmetric decision
making (i.e. both peers can make decisions) may cause the different making (i.e. both peers can make decisions) may cause the different
peers to make different decisions, thus causing asymmetric upstream/ peers to make different decisions, thus causing asymmetric upstream/
downstream traffic. In mobility case it is desirable that the mobile downstream traffic. In mobility case it is desirable that the mobile
peer can move both upstream and downstream traffic to some particular peer can move both upstream and downstream traffic to some particular
interface, and this requires asymmetric decision making (i.e. only interface, and this requires asymmetric decision making (i.e. only
one peer makes decisions. one peer makes decisions).
Working with stateful packet filters and NATs is easier if the 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 perform Also in common cases only the peer behind NAT can actually perform
actions to recover from the connectivity problems, as it might be actions to recover from the connectivity problems, as it might be
that the other peer is not able to initiate any connections to the that the other peer is not able to initiate any connections to the
peer behind NAT. peer behind NAT.
5.1.5. Suggested Approach 5.1.5. Suggested Approach
The working group decided to select a method where the initiator will The working group decided to select a method where the initiator will
decide which addresses are used. As a consequence the outcome cannot decide which addresses are used. As a consequence the outcome is
be asymmetric decisions. It also works best with NATs, as the always the same for both parties. It also works best with NATs, as
initiator is most likely the node that is located behind a NAT. the initiator is most likely the node that is located behind a NAT.
5.2. NAT Traversal 5.2. NAT Traversal
5.2.1. Background and Constraints 5.2.1. Background and Constraints
Another core aspect of MOBIKE is the treatment of different NATs and Another core aspect of MOBIKE is the treatment of different NATs and
NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside
the IKEv2 payloads, and thus there is no need to do unilateral self- the IKEv2 payloads, and thus there is no need to do unilateral self-
address fixing (UNSAF). The tunnel header IP addresses are taken address fixing (UNSAF [RFC3424]). The tunnel header IP addresses are
from the outer IP header of the IKE packets, thus they are already taken from the outer IP header of the IKE packets, thus they are
processed by the NAT. already processed by the NAT.
The NAT detection payloads are used to determine whether the The NAT detection payloads are used to determine whether the
addresses in the IP header were modified by a NAT along the path. addresses in the IP header were modified by a NAT along the path.
Detecting a NAT typically requires UDP encapsulation of IPsec ESP Detecting a NAT typically requires UDP encapsulation of IPsec ESP
packets to be enabled, if desired. MOBIKE is not to change how IKEv2 packets to be enabled, if desired. MOBIKE is not to change how IKEv2
NAT-T works, in particular, any kind of UNSAF or explicit interaction NAT-T works, in particular, any kind of UNSAF or explicit interaction
with NATs (e.g., MIDCOM or NSIS NATFW NSLP) are beyond the scope of with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [I-D.ietf-nsis-
MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE nslp-natfw]) are beyond the scope of MOBIKE protocol. The MOBIKE
and NAT-T are used together. 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, as 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 either.
The property of being behind NAT is actually a property of the The property of being behind NAT is actually a property of the
address pair and thereby by the path taken by a packet, thus one peer address pair and thereby by the path taken by a packet, thus one peer
can have multiple IP addresses and some of those might be behind NAT can have multiple IP addresses and some of those might be behind NAT
and some might not. and some might not.
5.2.2. Fundamental Restrictions 5.2.2. Fundamental Restrictions
There are some cases which cannot be carried out within the There are some cases which cannot be carried out within MOBIKE. One
restrictions of the MOBIKE charter. One of those cases is the case of those cases is the case where the party "outside" a symmetric NAT
where the party "outside" a symmetric NAT changes its address to changes its address to something not known by the the other peer (and
something not known by the the other peer (and old address has old address has stopped working). It cannot send a packet containing
stopped working). It cannot send a packet containing the new the new addresses to the peer because the NAT does not contain the
addresses to the peer because the NAT does not contain the necessary necessary state. Furthermore, since the party behind the NAT does
state. Furthermore, since the party behind the NAT does not know the not know the new IP address, it cannot cause the NAT state to be
new IP address, it cannot cause the NAT state to be created. 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 a NAT and back 5.2.3. Moving to behind a NAT and back
The MOBIKE protocol should provide a mechanism where a peer that is The MOBIKE protocol should provide a mechanism where a peer that is
initially not behind a NAT can move behind NAT, when a new preferred initially not behind a NAT can move behind NAT, when a new preferred
address is selected. The same effect might be accomplished with the address is selected. The same effect might be accomplished with the
change of the address pair if more than one path is available (e.g., change of the address pair if more than one path is available (e.g.,
skipping to change at page 17, line 28 skipping to change at page 17, line 26
only to that one address pair. only to that one address pair.
Enabling NAT-T involves a few different things, one is to enable the 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 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 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 unless there is really a NAT between peers, i.e.
UDP encapsulation should only be enabled when we actually detect NAT. UDP encapsulation should only be enabled when we actually detect NAT.
On the other hand, as all implementations supporting NAT-T must be 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 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 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 immediately upon detecting that the other end supports NAT-T. This
way we do not need to start changing ports after we later detected way it is not necessary to change ports after we later detected NAT,
NAT, which would have caused complications to the protocol. which would have caused complications to the protocol.
If we would do the actual changing of the port only after we detect 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 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. SAs immediately after their address is changed to be behind NAT.
Instead it would need to wait for the next packet from the initiator 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 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 its port from 500 to 4500. The responder would also not be able to
send anything to the initiator before the initiator has sent send anything to the initiator before the initiator has sent
something to the responder. If we do the port number changing something to the responder. If we do the port number changing
immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we
skipping to change at page 18, line 5 skipping to change at page 17, line 51
5.2.4. Responder behind a NAT 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 the possible but in that case the initiator needs to know all the possible
addresses where the responder can move to, i.e. the responder cannot addresses where the responder can move to, i.e. the responder cannot
move to an address which is not known by the initiator, in case move to an address which is not known by the initiator, in case
initiator also moves behind NAT. 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 a mapping so the initiator can connect to it. with the NAT to create a mapping so the initiator can connect to it.
Those external hole punching mechanisms are beyond the scope of Those external firewall pinhole opening mechanisms are beyond the
MOBIKE. 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 MOBIKE is NAT prevention, i.e. if we One new feature created by MOBIKE is NAT prevention, i.e. if we
detect NAT between the peers, we do not allow that address pair to be detect NAT between the peers, we do not allow that address pair to be
used. This can be used to protect IP addresses in cases where it is used. This can be used to protect IP addresses in cases where it 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
skipping to change at page 18, line 40 skipping to change at page 18, line 38
testing using IKEv2 packets, see Section 6.2). The working group testing using IKEv2 packets, see Section 6.2). The working group
also decided to only 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 current 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
the MOBIKE messages and the IPsec protected data traffic travel along the MOBIKE messages and the IPsec protected data traffic travel along
a different path then NAT handling is severely complicated. a different path then NAT handling is severely complicated.
The basic question is then how the IPsec SAs are changed to use the The basic question is then how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling new address pair (the same address pair as the MOBIKE signaling
traffic). One option is that when the IKE SA address is changed, traffic). One option is that when the IKE SA address is changed,
then all IPsec SAs associated with it are automatically moved along then all IPsec SAs associated with it are automatically moved along
with it to a 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 Notify payload is needed to preserve bandwidth. A format than the Notify payload is needed to preserve bandwidth. A
Notify payload can only store one SPI per payload. A separate Notify payload can only store one SPI per payload. A separate
payload could have a list of IPsec SA SPIs and the 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 list of ranges of SPI values are supported. If
automatically move all IPsec SAs when the IKE SA moves, then we only we automatically move all IPsec SAs when the IKE SA moves, then we
need to keep track of which IKE SA was used to create the IPsec SA, only need to keep track of which IKE SA was used to create the IPsec
and fetch the IP addresses from the IKE SA, i.e. there is no need to SA, and fetch the IP addresses from the IKE SA, i.e. there is no need
store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec- to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306]
ikev2] already requires the implementations to keep track which IPsec already requires the implementations to keep track which IPsec SAs
SAs are created using which IKE SA. are created using which IKE SA.
If we do allow address set of each IPsec SA 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 cheap then we can support scenarios where the machine has fast and/or cheap
connections and slow and/or expensive connections, and wants to allow connections and slow and/or expensive connections, and wants 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.,
skipping to change at page 20, line 8 skipping to change at page 20, line 5
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 setting the spoofing to keep the TCP/IP sessions alive (or simply setting the
TCP/IP keepalives and timeouts large enough not to cause problems), TCP/IP keepalives and timeouts large enough not to cause problems),
or it could simply be left to the applications, e.g. allow TCP/IP or it could simply be left to the applications, e.g. allow TCP/IP
sessions to notice if 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 issues: From a technical point of view this would provide following two
features:
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 alive for an undefined value since the IKE-SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE-SA period of time. Note that IKEv2 does not require that the IKE-SA
has a lifetime associated with it. In order to prevent the IKE-SA has a lifetime associated with it. In order to prevent the IKE-SA
from being deleted the dead-peer detection mechanism needs to be from being deleted the dead-peer detection mechanism needs to be
suspended as well. suspended as well.
Due to the fact that this extension could be complicated and there Due to its complexity and no clear requirement for it, it was decided
was no clear need for it, a first version of the MOBIKE protocol will that MOBIKE does not support this feature.
not provide this feature.
5.5. Return Routability Check 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 these questions: 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.
skipping to change at page 20, line 52 skipping to change at page 20, line 49
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 current 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 check. The not necessary to execute the return routability check. The return
return routability check is a form of authorization check, although routability check is a form of authorization check, although it
it provides weaker guarantees than the inclusion of the IP address as provides weaker guarantees than the inclusion of the IP address as a
a part of a certificate. If multiple addresses are communicated to part of a certificate. If multiple addresses are communicated to the
the remote peer then some of these addresses may be already verified remote peer then some of these addresses may be already verified.
even if the primary address is still operational.
Another option is to use the [I-D.dupont-mipv6-3bombing] approach
which suggests to perform a return routability check only when an
address update needs to be sent from some address other than the
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 (i.e. something we
new preferred address after successful dead-peer detection (i.e., a notice from the network, not from the peer directly) we only move to
response to a DPD test) on the new address, which is already a return the new preferred address after successful dead-peer detection (i.e.,
routability check. With a direct notification the authenticated peer a response to a DPD test) on the new address, which is already a
may have provided an authenticated IP address (i.e. inside IKE return routability check. With a direct notification (i.e.
encrypted and authenticated payload, see Section 5.2.5). Thus it is notification from the other end directly) the authenticated peer may
would be possible to simply trust the MOBIKE peer to provide a proper have provided an authenticated IP address (i.e. inside IKE encrypted
IP address. In this case A protection against an internal attacker, and authenticated payload, see Section 5.2.5). Thus it is would be
possible to simply trust the MOBIKE peer to provide a proper IP
address. In this case A protection against an internal attacker,
i.e. the authenticated peer forwarding its traffic to the new i.e. the authenticated peer forwarding its traffic to the new
address, would not provided. On the other hand we know the identity address, would not provided. On the other hand we know the identity
of the peer in that case. There might be problems when extensions of the peer in that case. There might be problems when extensions
are added to IKEv2 that do not require authentication of end points are added to IKEv2 that do not require authentication of end points
(e.g., opportunistic security using anonymous Diffie-Hellman). (e.g., opportunistic security using anonymous Diffie-Hellman).
There is also a policy issue of when to schedule a return routability There is also a policy issue of when to schedule a return routability
check. 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
skipping to change at page 24, line 10 skipping to change at page 23, line 50
SA if we are using IKEv2 INFORMATIONAL exchanges to send return SA if we are using IKEv2 INFORMATIONAL exchanges to send return
routability checks. On the other hand return routability check can routability checks. On the other hand return routability check can
only fail permanently if there was an attack by the other end, thus 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. tearing down the IKE SA is a suitable action in that case.
There are some cases where the return routability check temporarily There are some cases where the return routability check temporarily
fails that need to be considered here. In the first case there is no fails that need to be considered here. In the first case there is no
attacker, but the selected address pair stops working immediately attacker, but the selected address pair stops working immediately
after the address update, before the return routability check. after the address update, before the return routability check.
What happens there is that the initiator does the normal address What happens there is that the initiator performs the normal address
update, and that succeeds, and then the responder starts a return update, and that succeeds, and then the responder starts a return
routability check. If the address pair has broken down before that, routability check. If the address pair has broken down before that,
the responder will never get back the reply to the return routability the responder will never get back the reply to the return routability
check. The responder might still be using the old IP address pair, check. The responder might still be using the old IP address pair,
which could still work. which could still work.
The initiator might be still seeing traffic from the responder, but The initiator might be still seeing traffic from the responder, but
using the old address pair. The initiator should detect that this using the old address pair. The initiator should detect that this
traffic is not using the latest address pair, and after a while it traffic is not using the latest address pair, and after a while it
should start dead peer detection on the current address pair. If should start dead peer detection on the current address pair. If
skipping to change at page 24, line 49 skipping to change at page 24, line 41
is now that the dead peer detection started by the initiator will is now that the dead peer detection started by the initiator will
succeed, as the responder will reply to the addresses in the headers, succeed, as the responder will reply to the addresses in the headers,
not the current address pair. The initiator will then detect that not the current address pair. The initiator will then detect that
the NAT mappings are changed, and it will fix the situation by doing the NAT mappings are changed, and it will fix the situation by doing
an address update. an address update.
The important thing for both of these cases is that the initiator The important thing for both of these cases is that the initiator
needs to see that the responder is both alive and synchronized with needs to see that the responder is both alive and synchronized with
initiator address pair updates. I.e. it is not enough that the initiator address pair updates. I.e. it is not enough that the
responder is sending traffic to an initiator, it must be also using responder is sending traffic to an initiator, it must be also using
the correct IP addresses before the initiator can belive it is alive the correct IP addresses before the initiator can believe it is alive
and synchronized. From the implementation point of view this means and synchronized. From the implementation point of view this means
that the initiator must not consider packets having wrong IP that the initiator must not consider packets having wrong IP
addresses as packets that prove the other end being alive, i.e. they addresses as packets that prove the other end being alive, i.e. they
do not reset the dead peer detection timers. do not reset the dead peer detection timers.
5.5.3. Suggested Approach 5.5.3. Suggested Approach
The working group selected to use IKEv2 INFORMATIONAL exchanges as a The working group selected to use IKEv2 INFORMATIONAL exchanges as a
return routability check, but included a random cookie to prevent return routability check, but included a random cookie to prevent
redirections by an authenticated attacker. Return routability checks redirection by an authenticated attacker. Return routability checks
are performed by default before moving the traffic. However these 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 check in MOBIKE is not It is worth noting that the return routability check in MOBIKE is
the same as the return routability check in MIP6: The MIP6 WG decided different from Mobile IPv6 [RFC3775], which does not perform return
that it is not necessary to do return routability checks between the routability operations between the mobile node and its home agent at
mobile node and the home agent at all. 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 Details 6. Protocol Details
6.1. Indicating Support for MOBIKE 6.1. Indicating Support for MOBIKE
skipping to change at page 29, line 25 skipping to change at page 29, line 25
there is the notification 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.
Working group decided to use IKEv2 Notify payloads, and put only one Working group decided to use IKEv2 Notify payloads, and put only one
data item per notify, i.e. there will be one Notify payload for each data item per notify, i.e. there will be one Notify payload for each
item to be sent. item to be sent.
6.4. Updating address list 6.4. Updating address set
Because of the initiator decides all address updates, the initiator Because of the initiator decides all address updates, the initiator
needs to know all the addresses used by the responder. The responder needs to know all the addresses used by the responder. The responder
also needs that list in case it happens to move to an address not also needs that list in case it happens to move to an address not
known by the initiator, and needs to send an address update known by the initiator, and needs to send an address update
notification to the initiator, and it might need to try different notification to the initiator, and it might need to try different
addresses for the initiator. addresses for the initiator.
MOBIKE could send the full peer address list every time any of the IP MOBIKE could send the whole peer address list every time any of the
addresses change (either addresses are added, removed, the order IP 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
this approach has more problems in the synchronization and packet this approach has more problems in the synchronization and packet
reordering cases, i.e., incremental updates must be processed in reordering cases, i.e., incremental updates must be processed in
order, but for full updates we can simply use the most recent one, order, but for full updates we can simply use the most recent one,
and ignore old ones, even if they arrive after the most recent one and ignore old ones, even if they arrive after the most recent one
(IKEv2 packets have a message id which is incremented for each (IKEv2 packets have a message id which is incremented for each
packet, thus it is easy to know the sending order). packet, thus it is easy to know the sending order).
Working group decided to use a protocol format where both ends send a Working group decided to use a protocol format where both ends send a
full list of their addresses to the other end, and that list full list of their addresses to the other end, and that list
overwrites the previous list. To support NAT-T the IP-addresses of overwrites the previous list. To support NAT-T the IP-addresses of
the received packet is added to the list (and they are not present in the received packet are considered as one address of the peer, even
the list). when not present in the list.
7. Security Considerations 7. Security Considerations
As all the messages are already authenticated by IKEv2 there is no As all the packets are already authenticated by IKEv2 there is no
risk that any attackers would modify the contents of the packets. risk that any attackers would modify the contents of the 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, except when doing NAT that do not cause any direct actions, except when doing NAT
Traversal. 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 bombing attack type. See [RFC4225] and [Aur02] for
and [Aur02] for more information about flooding attacks. more information about flooding attacks.
See Security considerations section of [I-D.ietf-mobike-protocol] for
more information about security considerations of the actual
protocol.
8. IANA Considerations 8. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
9. Acknowledgments 9. Acknowledgments
This document is the result of discussions in the MOBIKE working This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen, group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
skipping to change at page 33, line 9 skipping to change at page 33, line 9
for their input. for their input.
We would like to particularly thank Pasi Eronen for tracking open We would like to particularly thank Pasi Eronen for tracking open
issues on the MOBIKE mailing list. He helped us to make good issues on the MOBIKE mailing list. He helped us to make good
progress on the document. progress on the document.
10. References 10. References
10.1. Normative references 10.1. Normative references
[I-D.ietf-ipsec-ikev2] [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-ipsec-rfc2401bis] [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005.
10.2. Informative References 10.2. Informative References
[I-D.arkko-multi6dt-failure-detection] [I-D.ietf-mobike-protocol]
Arkko, J., "Failure Detection and Locator Selection in Eronen, P., "IKEv2 Mobility and Multihoming Protocol
Multi6", draft-arkko-multi6dt-failure-detection-00 (work (MOBIKE)", draft-ietf-mobike-protocol-07 (work in
in progress), October 2004. progress), December 2005.
[I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-03 (work in progress),
December 2005.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[I-D.dupont-mipv6-3bombing] [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Dupont, F., "A note about 3rd party bombing in Mobile Nordmark, "Mobile IP Version 6 Route Optimization Security
IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), Design Background", RFC 4225, December 2005.
June 2005.
[I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", draft-ietf-mip6-ro-sec-03
(work in progress), May 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multihoming with the Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-02 (work in Host Identity Protocol", draft-ietf-hip-mm-02 (work in
progress), July 2005. progress), July 2005.
[I-D.crocker-celp] [I-D.crocker-celp]
Crocker, D., "Framework for Common Endpoint Locator Crocker, D., "Framework for Common Endpoint Locator
Pools", draft-crocker-celp-00 (work in progress), Pools", draft-crocker-celp-00 (work in progress),
February 2004. February 2004.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, 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-13 (work in progress), draft-ietf-tsvwg-addip-sctp-13 (work in progress),
November 2005. November 2005.
[I-D.dupont-ikev2-addrmgmt]
Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-08 (work in progress),
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-07 (work in
progress), September 2005. progress), December 2005.
[I-D.ietf-ipv6-unique-local-addr] [I-D.ietf-ipv6-unique-local-addr]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), January 2005. progress), January 2005.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [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] [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Eronen, P., "IKEv2 Mobility and Multihoming Protocol Self-Address Fixing (UNSAF) Across Network Address
(MOBIKE)", draft-ietf-mobike-protocol-06 (work in Translation", RFC 3424, November 2002.
progress), November 2005.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-08 (work in
progress), October 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.
skipping to change at page 37, line 41 skipping to change at page 37, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 79 change blocks. 
227 lines changed or deleted 212 lines changed or added

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