draft-ietf-mobike-design-03.txt   draft-ietf-mobike-design-04.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: January 19, 2006 Siemens Expires: April 24, 2006 Siemens
July 18, 2005 October 21, 2005
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-03.txt draft-ietf-mobike-design-04.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 January 19, 2006. This Internet-Draft will expire on April 24, 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 13 skipping to change at page 2, line 13
(for example, due to mobility). (for example, due to mobility).
This document discusses the involved network entities, and the This document discusses the involved network entities, and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7 3.1. Mobility Scenario . . . . . . . . . . . . . . . . . . . . 8
3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8 3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9
3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 10
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Scope of MOBIKE . . . . . . . . . . . . . . . . . . . . . . . 11
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 14
5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13 5.1. Choosing addresses . . . . . . . . . . . . . . . . . . . . 14
5.2 Changing a Preferred Address and Multi-homing Support . . 13 5.1.1. Inputs and triggers . . . . . . . . . . . . . . . . . 14
5.2.1 Storing a single or multiple addresses . . . . . . . . 14 5.1.2. Connectivity . . . . . . . . . . . . . . . . . . . . . 14
5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15 5.1.3. Discovering connectivity . . . . . . . . . . . . . . . 15
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16 5.1.4. Decision making . . . . . . . . . . . . . . . . . . . 15
5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17 5.1.5. Suggested approach . . . . . . . . . . . . . . . . . . 15
5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 16
5.5 Changing addresses or changing the paths . . . . . . . . . 20 5.2.1. Background and constraints . . . . . . . . . . . . . . 16
5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20 5.2.2. Fundamental restrictions . . . . . . . . . . . . . . . 16
5.7 Employing MOBIKE results in other protocols . . . . . . . 23 5.2.3. Moving to behind NAT and back . . . . . . . . . . . . 16
5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 24 5.2.4. Responder behind NAT . . . . . . . . . . . . . . . . . 17
5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 25 5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 17
5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 5.2.6. Suggested approach . . . . . . . . . . . . . . . . . . 17
5.11 Message Representation . . . . . . . . . . . . . . . . . . 26 5.3. Scope of SA changes . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 5.4. Zero address set functionality . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5.5. Return routability test . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 5.5.1. Employing MOBIKE results in other protocols . . . . . 22
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5.2. Suggested approach . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 23
10.1 Normative references . . . . . . . . . . . . . . . . . . . 32 6. Protocol detail issues . . . . . . . . . . . . . . . . . . . . 24
10.2 Informative References . . . . . . . . . . . . . . . . . . 32 6.1. Indicating support for mobike . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 6.2. Path Testing and Window size . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 35 6.3. Message presentation . . . . . . . . . . . . . . . . . . . 26
6.4. Updating address list . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Normative references . . . . . . . . . . . . . . . . . . . 31
10.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
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 3, 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 neeed that updates the IP addresses associated with the mechanism is need 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. MOBIKE 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. The document does not aim to neither provide support
IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401]. IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401].
This document is structured as follows. After introducing some This document is structured as follows. After introducing some
important terms in Section 2 a number of relevant usage scenarios are important terms in Section 2 a number of relevant usage scenarios are
discussed in Section 3. Section 4 discusses the interoperation of discussed in Section 3. The next section Section 4 will describe the
MOBIKE with other protocols and processes that may run in the local scope of the MOBIKE protocol. Finally, Section 5 discusses design
machine. Finally, Section 5 discusses design considerations considerations affecting the MOBIKE protocol. The document concludes
affecting the MOBIKE protocol. The document concludes in Section 6 in Section 7 with security considerations.
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, as defined in this and related documents.
skipping to change at page 4, line 40 skipping to change at page 5, line 40
* 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. Where
IPv4 is considered, it is not an RFC 1918 [RFC1918] address. 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].
.
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
skipping to change at page 7, line 10 skipping to change at page 8, line 10
Terminology regarding NAT types (e.g. Full Cone, Restricted Cone, 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 set up of the IPsec SA(s)
took place over the path labeled as 'old path'. The involved packets took place over the path labeled as 'old path'. The involved packets
carried the MN's "old" IP address and were forwarded by the "old" 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 statefu address configuration techniques or via the IP address using stateful address configuration techniques or via the
stateless address autoconfiguration mechanism. The goal of MOBIKE, stateless address autoconfiguration mechanism. The goal of MOBIKE,
in this scenario, is to enable the MN and the GW to continue using in this scenario, is to enable the MN and the GW to continue using
the existing SAs and to avoid setting up a new IKE SA. A protocol the existing SAs and to avoid setting up a new IKE SA. A protocol
exchange, denoted by 'MOBIKE Address Update', enables the peers to exchange, denoted by 'MOBIKE Address Update', enables the 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
skipping to change at page 8, line 26 skipping to change at page 9, line 26
address +--+ +---+ ^ address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update) (MOBIKE Address Update)
---> = Path taken by data packets ---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE) >>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement ...> = End host movement
Figure 1: Mobility Scenario Figure 1: Mobility Scenario
3.2 Multihoming Scenario 3.2. Multihoming Scenario
Another 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 require
a peer to switch from one interface to another. a peer to switch from one interface to another.
skipping to change at page 9, line 4 skipping to change at page 9, line 51
| | | | | | | | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 | | IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets ---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE) >>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network ***> = Potential future path through the network
(if Peer A and Peer B change their preferred (if Peer A and Peer B change their preferred
address) address)
Figure 2: Multihoming Scenario
Figure 2: Multihoming Scenario
Note that MOBIKE does not 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 connected to the network at all times for a number of
reasons (e.g., cost, availability of certain link layer technologies, reasons (e.g., cost, availability of certain link layer technologies,
user convenience). The mechanism that determines which interfaces user convenience). The mechanism that determines which interfaces
are connected to the network at any given point in time is outside are connected to the network at any given point in time is outside
the scope of the MOBIKE protocol and, as such, this document. the scope of the MOBIKE protocol and, as such, this document.
skipping to change at page 10, line 5 skipping to change at page 11, line 5
network, the set of IP addresses under which the laptop is reachable, network, the set of IP addresses under 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. Framework 4. Scope of MOBIKE
The working group will develop a MOBIKE protocol which needs to Getting mobility and multihoming actually working requires lots of
perform the following operations: different components working together, including coordinating things
and making consistent decisions in several link layers, the IP
layers, different mobility mechanisms in those layers, and IPsec/IKE.
Most of those aspects are beyond the scope of MOBIKE: The MOBIKE
focuses on what two peers need to agree in IKEv2 level (like new
message formats and some aspects of their processing) for
interoperability.
The MOBIKE is not trying to be full mobility protocol; there is no
support for simultaneous movement or rendezvous mechanism, and there
is no support for route optimization etc. This current design
document focuses mainly on the tunnel mode, everything going inside
the tunnel is unaffected by the changes in the tunnel header IP
address, and this is the mobility feature provided by the MOBIKE.
I.e. the applications running through the MOBIKE IPsec tunnel cannot
even detect the movement, their IP address etc stay constant.
A 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
The technical details of these functions are discussed below.
Although MOBIKE will have to interact with other mechanisms, the
working group is chartered to leave this aspect outside the scope.
When a MOBIKE peer initiates a protocol exchange it needs to define a
peer address set based on the IP addresses available to it. The peer
may want to make this set available to the other peer. The IKEv2
Initiator does not need to indicate which of the addresses in the
peer address set is its preferred address. This is because the
Initiator has to place its preferred address into the source IP
address field of the IP header with the initial message exchange.
Additionally, the Initiator expects incoming signaling messages to
arrive at this address. The peer address set and the preferred
address are defined based on interaction with other components within
a host. In some cases, the peer address set may be available before
the initial protocol exchange and does not change during the lifetime
of the IKE-SA. The preferred address might change due to policy
reasons. Section 3 describes three scenarios in which the peer
address set is modified (by adding or deleting addresses). In these
scenarios the preferred address may change as well.
A modification of the peer address set or a change of the preferred
address typically is the result of the MOBIKE peer's local policy and
by the interaction with other protocols (such as DHCP or IPv6
Neighbor Discovery).
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 the
PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create
entries in the Security Association (SAD) and Security Policy entries in the Security Association (SAD) and Security Policy
Databases (SPD). The IPsec engine may also interact with IKEv2 and Databases (SPD). The IPsec engine may also interact with IKEv2 and
MOBIKE daemon using this API. The content of the Security Policy and MOBIKE daemon using this API. The content of the Security Policy and
Security Association Databases determines what traffic is protected Security Association Databases determines what traffic is protected
with IPsec in which fashion. MOBIKE, on the other hand, receives with IPsec in which fashion. MOBIKE, on the other hand, receives
information from a number of sources that may run both in kernel-mode information from a number of sources that may run both in kernel-mode
and in user-mode. Information relevant for MOBIKE might be stored in and in user-mode. Information relevant for MOBIKE might be stored in
skipping to change at page 13, 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 Indicating Support for MOBIKE 5.1. Choosing addresses
In order for MOBIKE to function, both peers must implement the MOBIKE
extension of IKEv2. If one or none of the peers supports MOBIKE,
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
MOBIKE, a peer needs to be confident that its address change messages
are understood by the other peer. If these messages are not
understood, it is possible that connectivity between the peers is
lost.
One way to ensure that a peer receives feedback on whether or not its
messages are understood by the other peer, is by using IKEv2
messaging for MOBIKE and to mark some messages as "critical".
According to the IKEv2 specification, such messages either have to be
understood by the receiver, or an error message has to be returned to
the sender.
A second way to ensure receipt of the above-mentioned feedback is by
using Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a given
peer supports the MOBIKE protocol.
A third approach would use the Notify payload which is also used for One of the core aspects of the MOBIKE protocol is the selection of
NAT detection (via NAT_DETECTION_SOURCE_IP and the address for the IPsec packets we send. Choosing addresses for
NAT_DETECTION_DESTINATION_IP payloads). the IKEv2 request is somewhat separate problem: in many cases, they
will be the same (and in some design choice they will always be the
same).
Both a Vendor ID and a Notify payload may be used to indicate the 5.1.1. Inputs and triggers
support of certain extensions.
Note that a MOBIKE peer could also attempt to execute MOBIKE How the address changes are triggered are largerly beyond the scope
opportunistically with the critical bit set when an address change of MOBIKE. The triggers can include e.g. changes in the set of
has occurred. The drawback of this approach is, however, that an addresses, various link-layer indications, failing dead peer
unnecessary MOBIKE message exchange is introduced. detection, and changes in preferences and policies. Furthermore,
there may be less reliable sources of information (such as lack of
IPsec packets and ICMP packets) that do not trigger any changes
directly, but rather cause DPD to be performed sooner than it
otherwise would have been (and if that DPD fails, that may trigger
changing of addresses).
Although Vendor ID payloads and Notifications are technically These triggers are largerly the same as for, e.g. Mobile IP, and are
equivalent, Notifications are already used in IKEv2 as a capability beyond the scope of MOBIKE.
negotiation mechanism. Hence, Notifications and Vendor ID payloads
are the preferred mechanisms.
5.2 Changing a Preferred Address and Multi-homing Support 5.1.2. Connectivity
From MOBIKE's point of view, support for multi-homing is inherently There can be two kind of "failures" in the connectivity; local or
provided by the fact that it manages a set of peer addresses, rather middle. Local failure is a property of an address (interface), while
than a single address. Further, MOBIKE provides mechanisms to change the failures in the middle is property of address pair. MOBIKE does
a peer's preferred IP address. Each peer needs to learn the not assume full connectivity, but it does not try to use
preferred address and the peer address set. unidirectional address pairs (multi6 has discussed about how to deal
with unidirectional paths). Unidirectional address pairs is
complicated issue, and supporting it would require abandoning the
principle that you always send the IKEv2 reply to the address the
request came from. Because of that MOBIKE decided to deal only with
bidirectional address pairs. It does consider unidirectional address
pairs as broken, and not use them, but the connection will not break
even if unidirectional address pairs are present, provided there is
at least one bidirectional address pair it can use.
5.2.1 Storing a single or multiple addresses Note, that MOBIKE is not really concerned about the actual path used,
it cannot even detect if some path is unidirectional, if the same
address pair has some other unidirectional path back. Ingress
filters might still cause such path pairs to be unusable, and in that
case MOBIKE will detect that there is no connection between address
pair.
One design decision is whether an IKE-SA should be associated with a In a sense having both IPv4 and IPv6 address is basically a case of
single IP address or multiple IP addresses. One option is that a partial connectivity (putting both IPv4 and IPv6 address in the same
peer can provide a list of addresses to its counterpart which can IP header does not work). The main difference is that it is known
then be used as destination addresses. beforehand, and there is no need to discover that IPv4/IPv6
combination does not work.
Note that MOBIKE does not support load balancing, i.e., only one IP 5.1.3. Discovering connectivity
address is set to a preferred address at a time and changing the
preferred address typically requires some MOBIKE signaling.
Another option is to only communicate one address to the other peer To detect connectivity, i.e failures in the middle, MOBIKE needs to
and both peers only use that address when communicating. If this have some kind of probe which it can send to the other end and get a
address cannot be used anymore then an address update is sent to the reply back to that. If it will see the reply it knows the connection
other peer that changes the preferred address. works, if it does not see the reply after multiple retransmissions it
may assume that the address pair tested is broken.
Alternatively, if peer A, for example,provides a peer address set The connectivity tests do require to take in to account the
with multiple IP addresses then peer B can recover from a failure of congestion problems, because the connection failure might be because
the preferred address without further communication with peer A. That of congestion, and the MOBIKE should not make it worse by sending
is, if it detects that the primary path does not work anymore it can lots of probe packets.
either switch to a new preferred address locally (i.e., changing the
source IP address of outgoing MOBIKE messages) or to try an IP
address from A's peer address set (i.e., changing the destination
address). If peer B only received a single IP address from peer A
for A then peer B can only change its own preferred address. Peer B
would have to wait for an address update from peer A with a new IP
address in order to fix the problem.
The main advantage of storing only a single IP address for the remote 5.1.4. Decision making
peer is that it makes retransmission handling easier. Moreover, it
simplifies the recovery procedure. The peer whose IP address changed
must start the recovery process and send the new IP address to the
other peer. However, connectivity failures along the path are not
well addressed with advertising a single IP address.
The single IP address approach does not work if both peers change One of the core decisions to the MOBIKE protocol is to who makes the
their IP addresses at the same time, for example if both hosts move decisions to fix situations, i.e. symmetry in decision making vs.
simultaneously, even though multiple addresses are available to the asymmetry in decisions. Symmetric decision making may cause the
two peers. The IKEv2 implementation might also require window size different peers to make different decisions, thus causing asymmetric
to be larger than 1 because the MOBIKE peer needs to be able to send upstream/downstream traffic. In mobility case it is desirable that
the IP address change notifications before it switches to another the mobile peer can move both upstream and downstream traffic to some
address. Depending on the occurrence of return routability checks, particular interface, and this requires asymmetric decision making.
retransmissions policies and similar message exchanges a window size
larger than 1 might be required to deal with more than one pending
response at the same time. Furthermore, the single IP address
approach does not really benefit much from indirect indications as
the peer receiving these indications might not be able to fix the
situation by itself (e.g., even if a peer receives an ICMP host
unreachable message for the old IP address, it cannot try another IP
address, since it does not know any).
The problems with IP address lists lie mostly in their complexity. Working with stateful packet filters and NATs is easier if same
Notification and recovery processes are more complicated. Both ends address pair is used in both upstream and downstream directions.
can recover from the IP address changes. However, both peers should Also in common cases only the peer behind NAT can actually do actions
not attempt to recover at the same time or nearly the same time as to recover from the connectivity problems, as it might be that the
this could cause them to lose connectivity. The MOBIKE protocol is other peer is not able to initiate any connections to the peer behind
required to prevent this. NAT.
The previous discussion is independent of the question of how many 5.1.5. Suggested approach
addresses to send in a single MOBIKE message. A MOBIKE message might
be able to carry more than one IP address (with the IP address list
approach) or a single address only. A NAT does not change addresses
carried inside the MOBIKE message but it can change IP address (and
transport layer addresses) in the IP header and Transport Protocol
header (if NAT traversal is enabled as part of configuration or
dynamically through the NAT discovery mechanism. Furthermore, a
MOBIKE message carrying the peer address set could be idempotent
(i.e., always resending the full address list) or the protocol may
allow add/delete operations to be specified. [I-D.dupont-ikev2-
addrmgmt], for example, offers an approach which defines add/delete
operations. The same is true for the dynamic address reconfiguration
extension for SCTP [I-D.ietf-tsvwg-addip-sctp].
5.2.2 Indirect or Direct Indication Because of those issues listed above, the MOBIKE protocol decided to
select method where the initiator will decide which addresses are
used. This has the benefits that it makes one peer to decide, thus
we cannot end up in the asymmetric decisions, and it also works best
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.
An indication to change the preferred IP address might be either 5.2. NAT Traversal
direct or indirect.
Direct indication: 5.2.1. Background and constraints
A direct indication means that the other peer will send an message Another core aspect of the MOBIKE was the co-operation and working
with the address change. This can, for example, be accomplished with NATs. In IKEv2 the tunnel header IP addresses are not sent
by having MOBIKE sending an authenticated address update inside the IKEv2 payloads, and thus there is no need to do unilateral
notification with a different preferred address. self-address fixing (UNSAF). The tunnel header IP addresses are
taken from the outer IP header of the IKE packets, thus they are
already processed by the NAT.
Indirect indication: The NAT detection payloads are used to detect if the addresses in the
IP header were modified by a NAT between the peers, and that enables
UDP encapsulation of ESP packets if needed. MOBIKE is not to change
how IKEv2 NAT-T works, in particular, any kind of UNSAF or explicit
interaction with NATs (e.g. midcom or nsis natfw) are beyond the
scope. The MOBIKE will need to define how MOBIKE and NAT-T are used
together.
An indirect indication to change the preferred address can be The NAT-T support should also be optional, i.e. if the IKEv2
obtained by observing the environment. An indirect indication implementation does not implement NAT-T, since it is not required in
might, for example, be the receipt of an ICMP message or some particular environment, implementing MOBIKE should not require
information about a link failure. This information should be seen adding support for NAT-T as well.
as a hint and should not cause a change of the remote peer's
preferred address. Depending on the local policy, MOBIKE may
decide to perform a dead-peer detection exchange for the preferred
address pair (or another address pair from the peer address set).
When a peer detects that the other end started to use a different
source IP address than before, it might want to authorize the new
preferred address (if not already authorized). Authorization aims
to ensure that a particular peer is allowed to use the indicated
address. Claiming to be at an arbitrary address without
performing a return-routability test or without verifying that the
IP address is listed within a certificate opens the door for
various denial of service attacks. Hence a peer may also start a
connectivity test of this particular address.
If more information is available to the MOBIKE daemon then a more The property of being behind NAT is actually property of the address
intelligent decision regarding the selection of a new primary path pair, thus one peer can have multiple IP-addresses and some of those
can be made. might be behind NAT and some might not be behind NAT.
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection 5.2.2. Fundamental restrictions
This section discusses the suitability of the IKEv2 dead-peer There are some cases which cannot be made work with the restrictions
detection (DPD) mechanism for connectivity tests between address provided by the MOBIKE charter. One of those cases is the case where
pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but the party "outside" a symmetric NAT changes its address to something
it needs to be investigated whether it can be used for MOBIKE not known by the the other peer (and old address has stopped
purposes as well. working). It cannot send a packet containing the new addresses to
the peer, because the NAT does not contain the necessary state.
Furthermore, since the party behind the NAT does not know the new IP
address, it cannot cause the NAT state to be created.
The IKEv2 DPD mechanism involves sending an empty informational This case could be solved using some rendezvous mechanism outside
exchange packet to a given address of the remote peer. On receipt, IKEv2, but that is beyond the scope of MOBIKE.
the remote peer responds with an acknowledgement. If no
acknowledgement is received after a certain timeout period (and after
couple of retransmissions), the remote peer is considered to be not
reachable at the address in question. On the other hand, receipt of
IPsec protected acknowledgement is a guarantee that the other peer is
reachable at the address in question.
When reusing dead-peer detection in MOBIKE for connectivity tests it 5.2.3. Moving to behind NAT and back
seems to be reasonable to try other IP addresses (if they are
available) in case of an unsuccessful connectivity test for a given
address pair. Dead-peer detection messages using a different address
pair should use the same message-id as the original dead-peer
detection message (i.e. they are simply retransmissions of the dead-
peer detection packet using different destination IP address). If
different message-id is used then it violates constraints placed by
the IKEv2 specification on the DPD message with regard to the
mandatory ACK for each message-id, causing the IKEv2 SA to be
deleted.
If MOBIKE strictly follows the guidelines of the dead-peer detection MOBIKE provides mechanism where peer not initially behind the NAT,
mechanism in IKEv2 then an IKE-SA should be marked as dead and can move to behind NAT, when new address pair is selected. MOBIKE
deleted if the connectivity test for all available address pairs does not need to detect when someone attach NAT to the currently
fails. Note that this is not in-line with the approach used, for working address pair, i.e. the NAT detection is only done when MOBIKE
example, in SCTP where a failed connectivity test for an address does changes the address pair used.
not lead to (a) the IP address or IP address pair to be marked as
dead and (b) delete state. Connectivity tests will be continued for
the address pairs in hope that the problem will recover soon. This
comparison with SCTP aims to point at another IETF protocol that aims
to address the multi-homing problem (although with a different scope
and a different layer).
Note that IKEv2 implementations may have a window size of 1, and Similarly the MOBIKE provides mechanism to move from the address pair
therefore be unable to initiate a dead-peer detection exchange while having NAT to the address pair not having NAT.
another exchange is pending. As a result, all other exchanges are
subject to an identical retransmission policy as used for the dead-
peer detection. To use a different policy for different message
types seems to be reasonable.
The dead-peer detection mechanism for the other IP address pairs can As we only use one address pair at time, effectively MOBIKE peer is
also be executed simultaneously if the window size larger than 1, either behind NAT or not behind NAT, but each address change can
meaning that after the initial timeout period of the preferred change the situation. Because of this and because initiator always
address expires, DPD packets are sent simultaneously to all other chooses the addresses it is enough to send keepalive packets only to
address pairs. It is necessary to differentiate acknowledgement that one address pair.
messages in order to determine which address pair is operational.
The source IP address of the acknowledgement can be used for this
purpose.
The protocol should also be nice to the network, meaning, that when 5.2.4. Responder behind NAT
some core link goes down, and a large number of MOBIKE clients notice
this, they should not start sending a large number of messages while
trying to recover from the problem. This may be particularly
unfortunate because packets may be dropped because of congestion in
the first place. If MOBIKE clients simultaneously try to test all
possible address pairs by executing connectivity tests then the
congestion problem only gets worse.
Also note that the IKEv2 dead-peer detection is not sufficient for MOBIKE can work in cases where the responder is behind static NAT,
the return routability check. See Section 5.6 for more information. but in that case the initiator needs to know all possible addresses
where the responder can move to, i.e. responder cannot move to the
address which is not known by the initiator.
5.3 Simultaneous Movements 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
external hole punching mechanisms are beyond the scope of MOBIKE.
MOBIKE does not aim to provide a mobility solution that allows In case the responder is behind NAPT then also finding the port
simultaneous movements. Instead, the MOBIKE working group focuses on numbers used by the responder, is outside the scope of MOBIKE.
selected scenarios as described in Section 3. Some of the scenarios
assume that one peer has a fixed set of addresses (from which some
subset might be in use). Thus it cannot move to an address that is
unknown to the other peer. Situations in which both peers move
simultaneously are outside the scope of the MOBIKE WG. MOBIKE has
not been chartered to deal with the rendezvous problem, or with the
introduction of new entities in the network.
Note that if only a single address is stored in the peer address set 5.2.5. NAT Prevention
(instead of an address list) we might end up in the case where it
seems that both peers changed their addresses at the same time (e.g.,
if both nodes change their addresses at the same time). This is
something that the MOBIKE protocol must deal with.
Three cases can be differentiated: One new feature created by the MOBIKE, is the NAT prevention, i.e. if
we 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 known by the configuration that there is no NAT between the nodes
(for example IPv6, or fixed site-to-site VPN). This gives extra
protection against 3rd party bombing attacks (attacker cannot divert
the traffic to some 3rd party). This feature means that we
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
decided by the configuration, there is no need to do UNSAF
processing.
o Two mobile nodes obtain a new address at the same time, and then 5.2.6. Suggested approach
being unable to tell each other where they are (in a break-before-
make scenario). This problem is called the rendezvous problem,
and is traditionally solved by introducing another third entity,
for example, the home agents (in Mobile IPv4/IPv6) or forwarding
agents (in the Host Identity Protocol). Essentially, solving this
problem requires the existence of additional infrastructure nodes.
o Simultaneous changes to addresses such that at least one of the The working group decided that MOBIKE uses NAT-T mechanisms from the
new addresses is known to the other peer before the change IKEv2 protocol as much as possible, but decided to change the dynamic
occurred. address update for IKEv2 packets to MUST NOT (it would break path
testing using IKEv2 packets). Working group also decided to only
send keepalives to the current address pair.
o No simultaneous changes at all. 5.3. Scope of SA changes
5.4 NAT Traversal Most sections of this document discuss design considerations for
updating and maintaining addresses in the database entries that
relate to an IKE-SA. However, changing the preferred address also
affects the entries of the IPsec SA database. The outer tunnel
header addresses (source and destination IP addresses) need to be
modified according to the primary path to allow the IPsec protected
data traffic to travel along the same path as the MOBIKE packets (if
we only consider the IP header information). If the MOBIKE messages
and the IPsec protected data traffic travel along a different path
then NAT handling is severely complicated.
IKEv2 supports legacy NAT traversal. This feature is known as NAT-T The basic question is then how the IPsec SAs are changed to use the
which allows IKEv2 to work even if a NAT along the path between the new address pair (the same address pair as the MOBIKE signaling
Initiator and the Responder modifies the source and possibly the traffic). One option is that when the IKE SA address is changed then
destination IP address. With NAPT even the transport protocol automatically all IPsec SAs associated with it are moved along with
identifiers are modified (which then requires UDP encapsulation for it to new address pair. Another option is to have a separate
exchanged IPsec protected data traffic). Therefore, the MOBIKE exchange to move the IPsec SAs separately.
daemon needs to obtain to required IP address informationfrom the IP
header (if a NAT was detected that modified the IP header) rather
than from the protected payload. This problem is not new and is an
issues of every mobility protocol where the most important
information exchanged is the IP address .
One of the goals in the MOBIKE protocol is to securely exchange one If IPsec SAs should be updated separately then a more efficient
or more addresses of the peer address set and to securely set the format than the notification payload is needed to preserve bandwidth.
primary address. If no other protocol is used to securely retrieve A notification payload can only store one SPI per payload. A
the IP address and port information allocated by the NAT then it is separate payload could have list of IPsec SA SPIs and new preferred
not possible to tackle all attacks against MOBIKE. Section 6 address. If there is a large number of IPsec SAs, those payloads can
discusses this aspect in more detail. Various approaches to solve be quite large unless ranges of SPI values are supported. If we
the problem have been presented: 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
fetch the IP addresses from IKE SA, i.e. no need to store IP
addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-ikev2]
already requires implementations to keep track which IPsec SAs are
created using which IKE SA.
o Securely retrieving IP address and port information allocated by If we do allow each IPsec SA address set to be updated separately,
the NAT using a protocol different from MOBIKE. This approach is then we can support scenarios, where the machine has fast and/or
outside the scope of the MOBIKE working group since other working cheap connections and slow and/or expensive connections, and it wants
groups, such as MIDCOM and NSIS, already deal with this problem. to allow moving some of the SAs to the slower and/or more expensive
The MOBIKE protocol can benefit from the interaction with these connection, and prevent the move, for example, of the news video
protocols but the interaction with these protocols it outside the stream from the WLAN to the GPRS link.
scope of this document.
o Design a protocol in such a way that NAT boxes are able to inspect On the other hand, even if we tie the IKE SA update to the IPsec SA
(or even participate) in the protocol exchange. This approach was update, then we can create separate IKE SAs for this scenario, e.g.,
taken with the Host Identity Protocol but is not an option for we create one IKE SA which have both links as endpoints, and it is
IKEv2 and MOBIKE since most IKEv2 messages are encrypted with the used for important traffic, and then we create another IKE SA which
established IKE SA. This prevents the NAT from learning required have only the fast and/or cheap connection, which is then used for
information from the protocol exchange in a similar fashion as in that kind of bulk traffic.
HIP.
o Disable NAT-T by indicating the desire never to use information MOBIKE protocol decided to move all IPsec SAs implicitly when the IKE
from the (unauthenticated) header. While this approach prevents SA address pair changes. If more granular handling of the IPsec SA
some security problems it effectively disallows the protocol to is required, then multiple IKE SAs can be created one for each set of
work in environments with NATs. IPsec SAs needed.
There is no way to distinguish the whether there is a NAT device 5.4. Zero address set functionality
along the path that modifies the header information in packets or an
adversary mounting an attack. If a NAT is detected during the
creation of an IKE SA, that should automatically disable the MOBIKE
extensions and use NAT-T.
A design question is whether NAT detection capabilities should be One of the features which is potentially useful is for the peer to
enabled only during the initial IKEv2 exchange or also during announce that it will now disconnect for some time, i.e. it will not
subsequent message exchanges. If MOBIKE is executed with no NAT be reachable at all. For instance, a laptop might go to suspend
along the path when the IKE SA was created, then a NAT which appears mode. In this case the it could send address notification with zero
after moving to a new network cannot be dealt with if NAT detection new addresses, which means that it will not have any valid addresses
is enabled only during the initial exchange. Hence, it is desirable anymore. The responder of that kind of notification would then
to also support a scenario where a MOBIKE peer moves from a subnet acknowledge that, and could then temporarily disable all SAs and
that is not behind a NAT to a network that is. therefore stop sending traffic. If any of the SAs gets any packets
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
keepalives and timeouts large enough not to cause problems), or it
could simply be left to the applications, e.g. allow TCP/IP sessions
to notice the link is broken.
A NAT prevention mechanism can be used to make sure that no adversary The local policy could then indicate how long the peer should allow
can interact with the protocol if no NAT is expected between the remote peers to remain disconnected.
Initiator and the Responder. (reference? Explanation?)
Whether or not MOBIKE should support NAT traversal is one of the most From a technical point of view this feature addresses two aspects:
important design decisions.
5.5 Changing addresses or changing the paths o There is no need to transmit IPsec data traffic. IPsec protected
data can be dropped which saves bandwidth. This does not provide
a functional benefit, i.e., nothing breaks if this feature is not
provided.
A design decision is whether it is enough for the MOBIKE protocol to o MOBIKE signaling messages are also ignored. The IKE-SA must not
detect dead addresses, or it also needs to detect dead paths. Dead be deleted and the suspend functionality (realized with the zero
address detection refers to the ability to establish whether or not a address set) may require the IKE-SA to be tagged with a lifetime
given IP address pair is operational. Dead path detection refers to value since the IKE-SA should not be kept in alive for an
the ability to establish whether or not all possible (local/remote) undefined period of time. Note that IKEv2 does not require that
address pairs are operational (or at least find one such pair). 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 suspended as well.
While performing just one address change is simpler, the existence of Due to the fact that this extension could be complicated and there
locally operational addresses is not, however, a guarantee that was no clear need for it, a first version of the MOBIKE protocol will
communications can be established with the peer. A failure in the not provide this feature.
routing infrastructure can prevent the sent packets from reaching
their destination.
5.6 Return Routability Tests 5.5. Return routability test
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 this question:
o The addresses a peer is using are part of a certificate. o The addresses a peer is using are part of a certificate.
[RFC3554] which is introduced by this approach. If the other peer [RFC3554] introduced this approach. If the other peer is, for
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 appear 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
skipping to change at page 21, line 28 skipping to change at page 21, line 4
may have provided an authenticated IP address. Thus it is would be may have provided an authenticated IP address. Thus it is would be
possible to simply trust the MOBIKE peer to provide a proper IP possible to simply trust the MOBIKE peer to provide a proper IP
address. There is no way an adversary can successfully launch an address. There is no way an adversary can successfully launch an
attack by injecting faked addresses since it does not know the IKE SA attack by injecting faked addresses since it does not know the IKE SA
and the corresponding keying material.A protection against an and the corresponding keying material.A protection against an
internal attacker, i.e. the authenticated peer forwarding its traffic internal attacker, i.e. the authenticated peer forwarding its traffic
to the new address, is not provided. This might be an issue when to the new address, is not provided. This might be an issue when
extensions are added to IKEv2 that do not require authentication of extensions are added to IKEv2 that do not require authentication of
end points (e.g., opportunistic security using anonymous Diffie- end points (e.g., opportunistic security using anonymous Diffie-
Hellman). On the other hand we know the identity of the peer in that Hellman). On the other hand we know the identity of the peer in that
case. The identity of the IKEv2 Initiator and the IKEv2 Responder case.
can take various forms: IP address, FQDN, DN, email address alike
identifiers, etc.
It seems that there it is also a policy issue when to schedule a There is also a policy issue when to schedule a return routability
return routability test. test. 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, but the problem is that if that fails then the dead-peer detection. There are potential attacks if a return
IKEv2 specification requires the IKE SA to be deleted. Because of routability check does not include some kind of nonce. The valid end
this a different type of exchange is required and thereby avoiding point could send an address update notification for a third party,
modifications to the IKEv2 specification. trying to get all the traffic to be sent there, causing a denial of
service attack. If the return routability checks does not contain
There are potential attacks if a return routability check does not any cookies or other random information not known to the other end,
include some kind of nonce. The valid end point could send an then that valid node could reply to the return routability checks
address update notification for a third party, trying to get all the even when it cannot see the request. This might cause a peer to move
traffic to be sent there, causing a denial of service attack. If the the traffic to a location where the original recipient cannot be
return routability checks does not contain any cookies or other reached.
random information not known to the other end, then that valid node
could reply to the return routability checks even when it cannot see
the request. This might cause a peer to move the traffic to a
location where the original recipient cannot 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 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 it requires the adversary to be located somewhere on the individual
paths ({CoA1, ..., CoAn} towards the destination IP address) have a paths ({CoA1, ..., CoAn} towards the destination IP address) have a
shared path or if the adversary is located near the MOBIKE client shared path or if the adversary is located near the MOBIKE client
skipping to change at page 22, line 29 skipping to change at page 21, line 46
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 along the path to the claimed address. This is the basic form of
of return routability test. return routability test.
o There is an answer from the tested address, and that answer was o There is an answer from the tested address, and that answer was
authenticated, 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
skipping to change at page 23, line 16 skipping to change at page 22, line 30
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.7 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
skipping to change at page 23, line 50 skipping to change at page 23, line 15
[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 be used in order to support multi-homing,
and that it would be beneficial for different protocols to coordinate and 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. (so why do you protocol design and may be addressed in future work.
elaborate so much on this stuff?)
5.8 Scope of SA changes 5.5.2. Suggested approach
Most sections of this document discuss design considerations for MOBIKE protocol selected to use IKEv2 INFORMATIONAL exchanges as a
updating and maintaining addresses in the database entries that return routability tests, but added random cookie there to prevent
relate to an IKE-SA. However, changing the preferred address also redirections done by authenticated attacker. Return routability
affects the entries of the IPsec SA database. The outer tunnel tests are done by default before moving the traffic. However these
header addresses (source and destination IP addresses) need to be tests are optional. Nodes MAY also perform these tests upon their
modified according to the primary path to allow the IPsec protected own initiative at other times.
data traffic to travel along the same path as the MOBIKE packets (if
we only consider the IP header information). If the MOBIKE messages
and the IPsec protected data traffic travel along a different path
then NAT handling is severely complicated.
The basic question is then how the IPsec SAs are changed to use the It is worth noting that the return routability test in MOBIKE is not
new address pair (the same address pair as the MOBIKE signaling he same as return routability test in MIP6: The MIP6 WG decided that
traffic -- the primary path). One option is that when the IKE SA it is not necessary to do return routability tests between the mobile
address is changed then automatically all IPsec SAs associated with node and the home agent at all.
it are moved along with it to new address pair. Another option is to
have a separate exchange to move the IPsec SAs separately.
If IPsec SAs should be updated separately then a more efficient 5.6. IPsec Tunnel or Transport Mode
format than the notification payload is needed to preserve bandwidth.
A notification payload can only store one SPI per payload. A
separate payload which would have list of IPsec SA SPIs and new
preferred 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 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 fetch the IP addresses. Note that IKEv2
[I-D.ietf-ipsec-ikev2] already requires implementations to keep track
which IPsec SAs are created using which IKE SA.
If we do allow each IPsec SA address set to be updated separately, Current MOBIKE design is focused only on the VPN type usage and
then we can support scenarios, where the machine has fast and/or tunnel mode. Transport mode behavior would also be useful, but will
cheap connections and slow and/or expensive connections, and it wants be discussed in future documents.
to allow moving some of the SAs to the slower and/or more expensive
connection, and prevent the move, for example, of the news video
stream from the WLAN to the GPRS link.
On the other hand, even if we tie the IKE SA update to the IPsec SA 6. Protocol detail issues
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
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
that kind of bulk traffic.
5.9 Zero Address Set 6.1. Indicating support for mobike
One of the features which is potentially useful is for the peer to In order for MOBIKE to function, both peers must implement the MOBIKE
announce that it will now disconnect for some time, i.e. it will not extension of IKEv2. If one or none of the peers supports MOBIKE,
be reachable at all. For instance, a laptop might go to suspend then, whenever an IP address changes, IKEv2 will have to be re-run in
mode. In this case the it could send address notification with zero order to create a new IKE SA and the respective IPsec SAs. In
new addresses, which means that it will not have any valid addresses MOBIKE, a peer needs to be confident that its address change messages
anymore. The responder of that kind of notification would then are understood by the other peer. If these messages are not
acknowledge that, and could then temporarily disable all SAs and understood, it is possible that connectivity between the peers is
therefore stop sending traffic. If any of the SAs gets any packets lost.
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
keepalives and timeouts large enough not to cause problems), or it
could simply be left to the applications, e.g. allow TCP/IP sessions
to notice the link is broken.
The local policy could then indicate how long the peer should allow One way to ensure that a peer receives feedback on whether or not its
remote peers to remain disconnected. messages are understood by the other peer, is by using IKEv2
messaging for MOBIKE and to mark some messages as "critical".
According to the IKEv2 specification, such messages either have to be
understood by the receiver, or an error message has to be returned to
the sender.
From a technical point of view this feature addresses two aspects: A second way to ensure receipt of the above-mentioned feedback is by
using Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a given
peer supports the MOBIKE protocol.
o There is no need to transmit IPsec data traffic. IPsec protected A third approach would use the Notify payload which is also used for
data needs to be dropped which saves bandwidth. This does not NAT detection (via NAT_DETECTION_SOURCE_IP and
provide a functional benefit, i.e., nothing breaks if this feature NAT_DETECTION_DESTINATION_IP payloads).
is not provided.
o MOBIKE signaling messages are also ignored. The IKE-SA must not Both a Vendor ID and a Notify payload may be used to indicate the
be deleted and the suspend functionality (realized with the zero support of certain extensions.
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
undefined 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 from being deleted the dead-peer detection mechanism
needs to be suspended as well.
Due to the fact that this extension would be complicated, a first Note that a MOBIKE peer could also attempt to execute MOBIKE
version of the MOBIKE protocol will not provide this feature. opportunistically with the critical bit set when an address change
has occurred. The drawback of this approach is, however, that an
unnecessary message exchange is introduced.
5.10 IPsec Tunnel or Transport Mode Although Vendor ID payloads and Notifications are technically
equivalent, Notifications are already used in IKEv2 as a capability
negotiation mechanism. Hence, notification payloads are used in the
MOBIKE to indicate support of it.
Current MOBIKE design is focused only on the VPN type usage and Also as the information of the support of the MOBIKE is not needed
tunnel mode. Transport mode behaviour would also be useful, but will during the IKE_SA_INIT exchange, the indication of the support is
be discussed in future documents. done inside the IKE_AUTH exchange. The reason for this is to need to
keep the IKE_SA_INIT messages as small as possible, so they do not
get fragmented. The idea is that responder can do stateless
processing of the first IKE_SA_INIT packet, and request cookie from
the other end if it is under attack. To mandate responder to be able
to reassemble initial IKE_SA_INIT packets would not allow fully
stateless processing of the initial IKE_SA_INIT packets.
5.11 Message Representation 6.2. Path Testing and Window size
As the IKEv2 has the window of outgoing messages, and the sender is
not allowed to violate that window (meaning, that if the window is
full, then he cannot send packets), it do cause some complications to
the path testing. The another complication created by IKEv2 is that
once the message is first time sent to the other end, it cannot be
modified in its future retransmissions. This makes it impossible to
know what packet actually reached first to the other end. We cannot
use IP headers to find out which packet reached the other end first,
as if responder gets retransmissions of the packet it has already
replied (and those replies might have been lost due unidirectional
address pair), it will retransmit the previous reply using the new
address pair of the request. Because of this it might be possible
that the responder has already used the IP-address information from
the header of the packet, and the reply packet ending up to the
initiator has different address pair.
Another complication comes from the NAT-T. The current IKEv2
document says that if NAT-T is enabled the node not behind NAT SHOULD
detect if the IP-address changes in the incoming authenticated
packets, and update the remote peers addresses accordingly. This
works fine with the NAT-T, but it causes some complications in the
MOBIKE, as it needs an ability to probe the another address pairs,
without breaking the old one.
One approach to fix those would be to add completely new protocol
that is outside the IKE SA message id limitations (window code),
outside identical retransmission requirements, and outside the
dynamic address updating of the NAT-T.
Another approach is to make the protocol so that it does not violate
window restrictions and does not require changing the packet is sent,
and change the dynamic address updating of NAT-T to MUST NOT in case
MOBIKE is used. To not to violate window restrictions, it means that
the addresses of the currently ongoing exchange needs to be changed,
to test different paths. To not to require changing the packet after
it is first sent, requires that the protocol needs to restart from
the beginning in case packet was retransmitted to different addresses
(so sender does not 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
testing, and decided to change the dynamic address updating of NAT-T
to MUST NOT.
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 the IKEv2, or via a
MOBIKE specific message exchange. Using informational exchange has MOBIKE specific message exchange. Using informational exchange has
the main advantage that it is already specified in the IKEv2 and the main advantage that it is already specified in the IKEv2 and
implementations incorporate the functionality already. implementations incorporate the functionality already.
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 ordered, according to preference,
list of IP addresses. While two addresses can have the same list of IP addresses. While 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, Even if load balancing is currently outside the scope of MOBIKE,
future work might include. The selected format needs to be flexible future work might include support for it. The selected format needs
enough to include additional information (e.g. to enable load to be flexible enough to include additional information (e.g. to
balancing). This may be realized with an reserved field, which can enable load balancing). This may be realized with an reserved field,
later be used to store additional information. As there may arise which can later be used to store additional information. As there
other information which may have to be tied to an address in the may arise other information which may have to be tied to an address
future, a reserved field seems like a prudent design in any case. in the future, a reserved field seems like a prudent design in any
case.
There are two formats that place IP address lists into a message. There are two formats that place IP address lists into a message.
One includes each IP address as separate payload (where the payload One includes each IP address as separate payload (where the payload
order indicates the preference value, or the payload itself might order indicates the preference value, or the payload itself might
include the preference value), or we can put the IP address list as include the preference value), or we can put the IP address list as
one payload to the exchange, and that one payload will then have one payload to the exchange, and that one payload will then have
internal format which includes the list of IP addresses. 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 having carrying one IP address
makes the protocol probably easier to parse, as we can already use makes the protocol probably easier to parse, as we can already use
the normal IKEv2 payload parsing procedures.. It also offers an easy the normal IKEv2 payload parsing procedures. It also offers an easy
way for the extensions, as the payload probably contains only the way for the extensions, as the payload probably contains only the
type of the IP address (or the type is encoded to the payload type), type of the IP address (or the type is encoded to the payload type),
and the IP address itself, and as each payload already has length and the IP address itself, and as each payload already has length
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 IKEv2
payloads that are longer than a certain threshold, but if the sender payloads that are longer than a certain threshold, but if the sender
sends them in the most preferred first, the receiver can only use the sends them in the most preferred first, the receiver can only use the
first addresses. first addresses.
Having all IP addresses in one big MOBIKE specified internal format Having all IP addresses in one big MOBIKE specified internal format
skipping to change at page 27, line 16 skipping to change at page 27, line 19
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 notify data field, which could include the MOBIKE
specific data. specific data.
Another option would be to have a custom payload type, which then Another option would be to have a custom payload type, which then
includes the information needed for the MOBIKE protocol. includes the information needed for the MOBIKE protocol.
MOBIKE might send the full peer address list once one of the IP MOBIKE decided to use IKEv2 NOTIFY payloads, and put only one data
item per notify, i.e. there will be one NOTIFY payload for each item
to be sent.
6.4. Updating address list
Because of the initiator decides, the initiator needs to know all the
addresses used by the responder. The responder needs also that list
in case it happens move to the address unknown by the initiator, and
needs to send address update notify 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
addresses changes (either addresses are added, removed, the order addresses changes (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 have more problems in the synchronization and packet reordering
cases, i.e., the incremental updates must be processed in order, but cases, i.e., the incremental updates must be processed in order, but
for full updates we can simply use the most recent one, and ignore for full updates we can simply use the most recent one, and ignore
old ones, even if they arrive after the most recent one (IKEv2 old ones, even if they arrive after the most recent one (IKEv2
packets have message id which is incremented for each packet, thus we packets have message id which is incremented for each packet, thus we
know the sending order easily). know the sending order easily).
Note that each peer needs to communicate its peer address set to the MOBIKE decided to use protocol format, where both ends can send full
other peer. list of their addresses to the other end, and that list 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 list).
6. 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 the IKEv2 there is
no problem that any attackers would modify the contents of the no problem that any attackers would modify the contents of the
packets. The IP addresses in the IP header of the packets are not packets. The IP addresses in the IP header of the packets are not
authenticated, thus the protocol defined must take care that they are authenticated, thus the protocol defined must take care that they are
only used as an indication that something might be different, 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.
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.
7. IANA Considerations 8. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
8. 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,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman
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.
9. Open Issues
This document is not yet complete, the following open issues need to
be addressed in a future version:
o Section 4 needs an example to better illustrate the functionality
of MOBIKE
o Section 6 requires a more detailed discussion about the potential
security vulnerabilities and corresponding countermeasures.
o Some text is needed to address the implications of unidirectional
connectivity aspect for MOBIKE (see also issue #19).
o A discussion about the scalability aspects of connectivity tests
would be benefical.
o More details are necessary to describe the implications of NAT
traversal for MOBIKE.
A complete list of issues is available at
http://www.vpnc.org/ietf-mobike/issues.html.
10. References 10. References
10.1 Normative references 10.1. Normative references
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004. October 2004.
[I-D.ietf-ipsec-rfc2401bis] [I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005. in progress), April 2005.
10.2 Informative References 10.2. Informative References
[I-D.arkko-multi6dt-failure-detection] [I-D.arkko-multi6dt-failure-detection]
Arkko, J., "Failure Detection and Locator Selection in Arkko, J., "Failure Detection and Locator Selection in
Multi6", draft-arkko-multi6dt-failure-detection-00 (work Multi6", draft-arkko-multi6dt-failure-detection-00 (work
in progress), October 2004. in progress), October 2004.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
skipping to change at page 32, line 43 skipping to change at page 31, line 43
Dupont, F., "A note about 3rd party bombing in Mobile Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), IPv6", draft-dupont-mipv6-3bombing-02 (work in progress),
June 2005. June 2005.
[I-D.ietf-mip6-ro-sec] [I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", draft-ietf-mip6-ro-sec-03 Security Design Background", draft-ietf-mip6-ro-sec-03
(work in progress), May 2005. (work in progress), May 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-01 (work in Host Identity Protocol", draft-ietf-hip-mm-02 (work in
progress), February 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, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
skipping to change at page 33, line 33 skipping to change at page 32, line 33
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-07 (work in progress),
May 2005. May 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-05 (work in IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in
progress), February 2005. progress), September 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.
 End of changes. 106 change blocks. 
514 lines changed or deleted 460 lines changed or added

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