< draft-ietf-mobike-design-01.txt   draft-ietf-mobike-design-02.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: July 1, 2005 Siemens Expires: August 24, 2005 Siemens
December 31, 2004 February 20, 2005
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-01.txt draft-ietf-mobike-design-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 1, 2005. This Internet-Draft will expire on August 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) working group is The MOBIKE (IKEv2 Mobility and Multihoming) working group is
developing protocol extensions to the Internet Key Exchange Protocol developing protocol extensions to the Internet Key Exchange Protocol
version 2 (IKEv2) to enable its use in the context where there are version 2 (IKEv2) to enable its use in the context where there are
multiple IP addresses per host or where IP addresses of an IPsec host multiple IP addresses per host or where IP addresses of an IPsec host
change over time (for example due to mobility). change over time (for example, due to mobility).
This document discusses the involved network entities, and the This document discusses the involved network entities, and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols and the rest of the network. Design decisions for other protocols and the rest of the network. Design decisions for
the base MOBIKE protocol, background information and discussions the base MOBIKE protocol, background information and discussions
within the working group are recorded. within the working group are recorded.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 6 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7
3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 7 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8
3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 8 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13
5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 12 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13
5.2 Changing a Preferred Address and Multihoming Support . . . 12 5.2 Changing a Preferred Address and Multihoming Support . . . 13
5.2.1 Storing a single or multiple addresses . . . . . . . . 13 5.2.1 Storing a single or multiple addresses . . . . . . . . 14
5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 14 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 15 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16
5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 16 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17
5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Changing addresses or changing the paths . . . . . . . . . 18 5.5 Changing addresses or changing the paths . . . . . . . . . 19
5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 19 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20
5.7 Employing MOBIKE results in other protocols . . . . . . . 21 5.7 Employing MOBIKE results in other protocols . . . . . . . 22
5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 22 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 23
5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 23 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 24
5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 24 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25
5.11 Message Representation . . . . . . . . . . . . . . . . . . 24 5.11 Message Representation . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1 Normative references . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2 Informative References . . . . . . . . . . . . . . . . . . . 29 10.1 Normative references . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 10.2 Informative References . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35
1. Introduction 1. Introduction
IKEv2 is used for performing mutual authentication and establishing IKEv2 is used for performing mutual authentication and establishing
and maintaining IPsec security associations (SAs). IKEv2 establishes and maintaining IPsec security associations (SAs). IKEv2 establishes
both cryptographic state (such as session keys and algorithms) as both cryptographic state (such as session keys and algorithms) as
well as non-cryptographic information (such as IP addresses). well as non-cryptographic information (such as IP addresses).
The current IKEv2 and IPsec documents explicitly say that the IPsec The current IKEv2 and IPsec documents explicitly say that the IPsec
and IKE SAs are created implicitly between the IP address pair used and IKE SAs are created implicitly between the IP address pair used
skipping to change at page 3, line 34 skipping to change at page 3, line 34
SAs that often, and other scenarios the rekeying and required IKEv2 SAs that often, and other scenarios the rekeying and required IKEv2
authentication might require user interaction (SecurID cards etc). authentication might require user interaction (SecurID cards etc).
Due to these reasons, a mechanism to update the IP addresses tied to Due to these reasons, a mechanism to update the IP addresses tied to
the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the
problem of the updating the IP addresses stored with IKE SAs and problem of the updating the IP addresses stored with IKE SAs and
IPsec SAs. IPsec SAs.
The charter of the MOBIKE working group requires IKEv2 The charter of the MOBIKE working group requires IKEv2
[I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis
architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols
developed will use both IKEv2 and RFC2401bis. No effort is to be developed will use both IKEv2 and RFC2401bis. MOBIKE does not
made to make protocols for IKEv1 [RFC2409] or old RFC2401 support IKEv1 [RFC2409] or the old RFC2401 architecture [RFC2401].
architecture [RFC2401].
This document is structured as follows. After introducing some This document is structured as follows. After introducing some
important terms in Section 2 we list a few scenarios in Section 3, to important terms in Section 2 we list a few scenarios in Section 3, to
illustrate possible deployment environments. MOBIKE depends on illustrate possible deployment environments. MOBIKE depends on
information from other sources (e.g., detect an address change) which information from other sources (e.g., detect an address change) which
are discussed in Section 4. Finally, Section 5 discusses design are discussed in Section 4. Finally, Section 5 discusses design
considerations effecting the MOBIKE protocol. The document concludes considerations effecting the MOBIKE protocol. The document concludes
with security considerations in Section 6. with security considerations in Section 6.
2. Terminology 2. Terminology
This section introduces some terms in useful for a MOBIKE protocol. This section introduces some useful terms for a MOBIKE protocol.
Peer: Peer:
Within this document we refer to IKEv2 endpoints as peers. A peer Within this document we refer to IKEv2 endpoints as peers. A peer
implements MOBIKE and therefore IKEv2. implements MOBIKE and therefore IKEv2.
Available address: Available address:
An address is said to be available if the following conditions are
fulfilled:
* The address has been assigned to an interface of the node.
* If the address is an IPv6 address, we additionally require that
(a) the address is valid in the sense of RFC 2461 [RFC2461],
and that (b) the address is not tentative in the sense of RFC
2462 [RFC2462]. In other words, the address assignment is
complete so that communications can be started.
Note this explicitly allows an address to be optimistic in the
sense of [I-D.ietf-ipv6-optimistic-dad] even though
implementations are probably better off using other addresses
as long as there is an alternative.
* The address is a global unicast or unique site-local address
[I-D.ietf-ipv6-unique-local-addr]. That is, it is not an IPv6
link-local or site-local address. Where IPv4 is considered, it
is not an RFC 1918 [RFC1918] address.
* The address and interface is acceptable for use according to a
local policy.
This definition is reused from This definition is reused from
[I-D.arkko-multi6dt-failure-detection] and refers to addresses [I-D.arkko-multi6dt-failure-detection]
which are available by an peer. A few conditions must hold before
an address in such a state.
.
Locally Operational Address: Locally Operational Address:
An available address is said to be locally operational when its An available address is said to be locally operational when its
use is known to be possible locally. This definition is taken use is known to be possible locally. This definition is taken
from [I-D.arkko-multi6dt-failure-detection]. from [I-D.arkko-multi6dt-failure-detection].
Operational address pair: Operational address pair:
A pair of operational addresses are said to be an operational A pair of operational addresses are said to be an operational
address pair, iff bidirectional connectivity can be shown between address pair, iff bidirectional connectivity can be shown between
skipping to change at page 5, line 23 skipping to change at page 5, line 40
An address on which a peer prefers to receive MOBIKE messages and An address on which a peer prefers to receive MOBIKE messages and
IPsec protected data traffic. A given peer has only one active IPsec protected data traffic. A given peer has only one active
preferred address at a given point in time (ignoring the small preferred address at a given point in time (ignoring the small
time period where it needs to switch from the old preferred time period where it needs to switch from the old preferred
address to a new preferred address). This definition is taken address to a new preferred address). This definition is taken
from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context. from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context.
Peer Address Set: Peer Address Set:
A subset of locally operational addresses that will sent We denote the two peers in this Mobike session by peer A and peer
communicated to another peer. A policy available at the peer B. A peer address set is a subset of locally operational
indicates which addresses to include in the peer address set. addresses of peer A that are sent to peer B. A policy available
Such a policy might be impacted by manual configuration or by at peer A indicates which addresses to include in the peer address
interaction with other protocols which indicate newly available set. Such a policy might be impacted by manual configuration or
addresses. Note that the addresses in the peer address set might by interaction with other protocols that indicate new available
change over time. addresses.
Preferred Address Pair:
This address pair taken from the peer address set is used for
communication. The preferred address pair is used (1) for MOBIKE
communication where only two IP addresses are used and (2) as the
outer IP addresses (source and destination IP address) of the
IPsec packet in tunnel mode.
Terminology for different NAT types, such as Full Cone, Restricted Terminology for different NAT types, such as Full Cone, Restricted
Cone, Port Restricted Cone and Symmetric, can be found in Section 5 Cone, Port Restricted Cone and Symmetric, can be found in Section 5
of [RFC3489]. For mobility related terminology, such as of [RFC3489]. For mobility related terminology, such as
Make-before-break or Break-before-make see [RFC3753]. Make-before-break or Break-before-make see [RFC3753].
3. Scenarios 3. Scenarios
The MOBIKE protocol can be used in different scenarios. Three of The MOBIKE protocol can be used in different scenarios. Three of
them are discussed below. them are discussed below.
3.1 Mobility Scenario 3.1 Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile Figure 1 shows a break-before-make mobility scenario where a mobile
node attaches to, for example a wireless LAN, to obtain connectivity node attaches to, for example a wireless LAN, to obtain connectivity
to some security gateway. This security gateway might connect the to some security gateway. This security gateway might connect the
mobile node to a corporate network, to a UTMS network or to some mobile node to a corporate network, to a 3G network or to some other
other network. The initial IKEv2 exchange takes place along the path network. The initial IKEv2 exchange takes place along the path
labeled as 'old path' from the MN using its old IP address via the labeled as 'old path' from the MN using its old IP address via the
old access router (OAR) towards the security gateway (GW). The IPsec old access router (OAR) towards the security gateway (GW). The IPsec
tunnel mode terminates there but the decapsulated data packet will tunnel mode terminates there but the decapsulated data packet will
typically address another destination. Since only MOBIKE is relevant typically address another destination. Since only MOBIKE
for this discussion the end-to-end communication between the MN and communication from the MN to the gateway is relevant for this
some destination server is not shown in Figure 1. discussion the end-to-end communication between the MN and some
destination is not shown in Figure 1.
When the MN moves to a new network and obtains a new IP address from When the MN moves to a new network and obtains a new IP address from
a new access router (NAR) it is the responsibility of MOBIKE to avoid a new access router (NAR) it is the responsibility of MOBIKE to avoid
restarting the IKEv2 exchange from scratch. As a result, some form restarting the IKEv2 exchange from scratch. As a result, a protocol
of protocol exchange, denoted as 'MOBIKE Address Update', will exchange, denoted by 'MOBIKE Address Update' , will perform the
perform the necessary state update. The protocol messages will necessary state update.
travel along a new path whereby the old path and the new path will
meet at the cross-over router.
Note that in a break-before-make mobility scenario the MN obtains a Note that in a break-before-make mobility scenario the MN obtains a
new IP address after reachability to the old IP address has been new IP address after reachability to the old IP address has been
lost. MOBIKE is also assumed to work in scenarios where the mobile lost. MOBIKE is also assumed to work in scenarios where the mobile
node is able to establish connectivity with the new IP address while node is able to establish connectivity with the new IP address while
still being reachable at the old IP address. still being reachable at the old IP address.
(Initial IKEv2 Exchange) (Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v +--+ +---+ Old path V v
. +----+ v>>>>> +--+ . +----+ v>>>>> +--+
.move | CR | -------> |GW| .move | R | -------> |GW|
. | | >>>>> | | . | | >>>>> | |
v +----+ ^ +--+ v +----+ ^ +--+
+--+ +---+ New path ^ ^ +--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^ New IP |MN|------> |NAR|--------------^ ^
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)
skipping to change at page 8, line 17 skipping to change at page 9, line 17
| |>>>>>>>>>> * Network *>>>>>>>>>>| | | |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 | | IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | | | | | | | |
| 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 chance their preferred (if Peer A and Peer B change their preferred
address) address)
Figure 2: Multihoming Scenario Figure 2: Multihoming Scenario
Note, that the load-balancing inside one IKE SA is not provided by Note that MOBIKE does not support load balancing between multiple IP
the MOBIKE protocol. Each client uses only one of the available IP addresses. That is, each peer uses only one of the available IP
addresses at a given point in time. addresses at a given point in time.
3.3 Multihomed Laptop Scenario 3.3 Multihomed Laptop Scenario
In the multihomed laptop scenario we consider a laptop, which has In the multihomed laptop scenario we consider a laptop, which has
multiple interface cards and therefore several ways to connect to a multiple interface cards and therefore several ways to connect to a
network. It might for example have a fixed Ethernet, WLAN, GPRS, network. It might for example have a fixed Ethernet, WLAN, GPRS,
Bluetooth or USB hardware in order to sent IP packets. Some of these Bluetooth or USB hardware in order to send IP packets. A number of
interfaces might connected to a network over the time depending on a interfaces might connected to a network over time depending on a
number of reasons (e.g., cost, availability of certain link layer number of reasons (e.g., cost, availability of certain link layer
technologies, user convenience). For example, the user can technologies, user convenience). Note that a policy for selecting a
disconnect himself from the fixed Ethernet, and then use the office network interface based on cost, etc. is out of scope for MOBIKE.
WLAN, and then later leave the office and start using GPRS during the For example, the user can disconnect himself from the fixed Ethernet,
trip to home. At home he might again use again WLAN. At a certain use the office WLAN, and then later leave the office and start using
GPRS during the trip home. At home he might use WLAN. At a certain
point in time multiple interfaces might be connected. As such, the point in time multiple interfaces might be connected. As such, the
laptop is a multihomed device. In any case, the IP address of the laptop is a multihomed device. In any case, the IP address of the
individual interfaces are subject to change. individual interfaces are subject to change.
The user desires to keep the established IKE-SA and IPsec SAs alive The user desires to keep the established IKE-SA and IPsec SAs alive
all time without the need to re-run the initial IKEv2 exchange which all the time without the need to re-run the initial IKEv2 exchange
could require user interaction as part of the authentication process. which could require user interaction as part of the authentication
Furthermore, even if IP addresses change due to interface switching process. Furthermore, even if IP addresses change due to interface
or mobility, the IP source and destination address obtained via the switching or mobility, the IP source and destination address obtained
configuration payloads within IKEv2 and used inside the IPsec tunnel via the configuration payloads within IKEv2 and used inside the IPsec
remains unaffected, i.e., applications might not detect any change at tunnel remains unaffected, i.e., applications might not detect any
all. change at all.
4. Framework 4. Framework
Initially, when a MOBIKE peer starts and executes the initial The working group will develop a MOBIKE protocol which needs to
protocol exchange with its MOBIKE peer it needs to setup a peer perform the following functionality:
address set based on the available addresses. It might want to make o Ability to inform the other peer about the peer address set
this peer address set available to the other peer. The Initiator o Ability to inform the other peer about the preferred address
does not need to explicitly indicate its preferred address since o Ability to test connectivity along a path and thereby to detect an
already using its preferred address. The outgoing IKEv2 and MOBIKE outage situation
messages use this preferred address as the source IP address and o Ability to change the preferred address
expects incoming signaling messages to be addressed to this address. o Ability to change the peer address set
o Ability to deal with Network Address Translation devices
Interaction with other protocols at the MOBIKE host is required to The technical details of these functions are discussed below.
build the peer address set and the preferred address. In some cases Although the interaction with other protocols is important for MOBIKE
the peer address set is available before the initial protocol run and to operate correctly the working group is chartered to leave this
aspect outside the scope.
When a MOBIKE peer initiates a protocol exchange with its MOBIKE peer
it needs to define a peer address set based on the available
addresses. It might want to make this peer address set available to
the other peer. The Initiator does not need to explicitly indicate
its preferred address since it is already using its preferred
address. The outgoing IKEv2 and MOBIKE messages use this preferred
address as the source IP address and the MOBIKE peer expects incoming
signaling messages to be sent to this address. Interaction with
other protocols at the MOBIKE host is required to build the peer
address set and the preferred address. In some cases the peer
address set is available before the initial protocol exchange and
does not change during the lifetime of the IKE-SA. The preferred does not change during the lifetime of the IKE-SA. The preferred
address might change due to policy reasons. In many other cases, as address might change due to policy reasons. Section 3 describes
motivated in Section 3 the peer address set is modified (by adding or three scenarios in which the peer address set is modified (by adding
deleting addresses) and the preferred address needs to be changed as or deleting addresses). In these scenarios the preferred address
well. needs to be changed as well.
Modifying the peer address set or changing the preferred address is Modifying the peer address set or changing the preferred address is
effected by the host's local policy and by the interaction with other effected by the host's local policy and by the interaction with other
protocols (such as DHCP or IPv6 Neighbor Discovery). protocols (such as DHCP or IPv6 Neighbor Discovery).
Figure 3 shows an example protocol interaction at a MOBIKE peer. Figure 3 shows an example protocol interaction at a MOBIKE peer.
MOBIKE interacts with the IPsec engine using the PF_KEY interface to MOBIKE interacts with the IPsec engine using the PF_KEY interface
create entries in the Security Association and Security Policy [RFC2367] to create entries in the Security Association and Security
Databases. The IPsec engine might also interact with IKEv2 and Policy Databases. The IPsec engine might also interact with IKEv2
MOBIKE. Established state at the IPsec databases has an impact on and MOBIKE. Established state at the IPsec databases has an impact
the incoming and outgoing data traffic. MOBIKE receives information on the incoming and outgoing data traffic. MOBIKE receives
from other protocols running in both kernel-mode and user-mode, as information from other protocols running in both kernel-mode and
previously mentioned. Information relevant for MOBIKE is stored in a user-mode, as previously mentioned. Information relevant for MOBIKE
database, referred as Trigger database which guides MOBIKE in its is stored in a database, referred as Trigger database, that guides
decisions regarding the available addresses, peer address set and the MOBIKE in its decisions regarding the available addresses, peer
preferred address. Policies might affect the selection process. address set, and the preferred address. Policies might affect the
selection process.
Building and maintaining a peer address set and selecting or changing Building and maintaining a peer address set and selecting or changing
a preferred address based on locally available information is, a preferred address based on locally available information is,
however, insufficient. This information needs to be available to the however, insufficient. This information needs to be available to the
other peer and in order to address various failure cases it is other peer and in order to address various failure cases it is
necessary to test connectivity along a path. A number of address necessary to test connectivity along a path. A number of address
pairs might be available for connectivity tests but most important is pairs might be available for connectivity tests but most important
the source and the destination IP address of the preferred address are the source and the destination IP address of the primary path
pair since these addresses are selected for sending and receiving since these addresses are selected for sending and receiving MOBIKE
MOBIKE signaling messages and for sending and receiving IPsec signaling messages and for sending and receiving IPsec protected data
protected data traffic. If a problem along this primary path is traffic. If a problem along this primary path is detected (e.g., due
detected (e.g., due to a router failure) it is necessary to switch to to a router failure) it is necessary to switch to the new primary
the new preferred address pair. Testing other paths might also be path. Optionally, periodic testing of other paths might be useful to
useful to notice when a disconnected path is operational again. determine when a disconnected path becomes operational.
+-------------+ +---------+ +-------------+ +---------+
|User-space | | MOBIKE | |User-space | | MOBIKE |
|Protocols | +-->>| Daemon | |Protocols | +-->>| Daemon |
|relevant for | | | | |relevant for | | | |
|MOBIKE | | +---------+ |MOBIKE | | +---------+
+-------------+ | ^ +-------------+ | ^
User Space ^ | ^ User Space ^ | ^
++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
Kernel Space v | v Kernel Space v | v
skipping to change at page 10, line 35 skipping to change at page 12, line 34
I | |Kernel-space | | | | I I | |Kernel-space | | | | I
n | +-------->+Protocols +<----+-----+ | | n n | +-------->+Protocols +<----+-----+ | | n
t v v |relevant for | | v v v t t v v |relevant for | | v v v t
e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e
r | Input | +-------------+ | | Outgoing | r r | Input | +-------------+ | | Outgoing | r
f | Packet +<--------------------------+ | Interface | f f | Packet +<--------------------------+ | Interface | f
==a>|Processing|===============================| Processing |=a> ==a>|Processing|===============================| Processing |=a>
c | | | | c c | | | | c
e +----------+ +------------+ e e +----------+ +------------+ e
s s s s
===> = IP packets arriving/leaving a MOBIKE node ===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations <-> = control and configuration operations
Figure 3: Framework Figure 3: Framework
Although the interaction with other protocols is important for MOBIKE Please note that Figure 3 is only one way of implementing MOBIKE.
to operate correctly the working group is chartered to leave this Hence, it serves illustrative purposes only.
aspect outside the scope. The working group will develop a MOBIKE
protocol which needs to perform the following functionality:
o Ability to inform a peer about the peer address set
o Ability to inform a peer about the preferred address
o Ability to test connectivity along a path and thereby to detect an
outage situation in order to fall back to another preferred
address, if necessary, or to change the peer address set
o Ability to deal with Network Address Translation devices
In addition to the above-listed functionality security is important
to the working group. For example, the ability to prevent flooding
attacks based on announcing someone else's address needs to be dealt
with.
Extensions of the PF_KEY interface required by MOBIKE are also within Extensions of the PF_KEY interface required by MOBIKE are also within
the scope of the working group. Finally, optimizations in wireless the scope of the working group. Finally, optimizations in wireless
environment will also be covered. environment will also be covered.
Note that MOBIKE is somewhat different compared to, for example, SCTP
mobility since both the IKE-SA and the IPsec SA is affected by the
change of addresses.
5. Design Considerations 5. Design Considerations
This section discusses aspects affecting the design of the MOBIKE This section discusses aspects affecting the design of the MOBIKE
protocol. protocol.
5.1 Indicating Support for MOBIKE 5.1 Indicating Support for MOBIKE
A node needs to be able to guarantee that its address change messages In order for MOBIKE to function correctly, both peers must implement
are understood by its corresponding peer. Otherwise an address this extension. We propose extensions to IKEv2 described below for
change may render the connection useless, and it is important that MOBIKE support. If only one peer supports MOBIKE, then the peers
both sides realize this as early as possible. will just run IKEv2. Specifically, a node needs to be able to
guarantee that its address change messages are understood by its
corresponding peer. Otherwise an address change may render the
connection useless, and it is important that both sides realize this
as early as possible.
Ensuring that the messages are understood can in be arranged either Ensuring that the messages are understood can in be arranged either
by marking some IKEv2 payloads critical so that they are either by marking some IKEv2 payloads critical so that they are either
processed or an error message is returned, by using Vendor ID processed or an error message is returned, by using Vendor ID
payloads or via a Notify. payloads or via a Notify.
The first solution approach is to use Vendor ID payloads during the The first solution approach is to use Vendor ID payloads during the
initial IKEv2 exchange using a specific string denoting MOBIKE to initial IKEv2 exchange using a specific string denoting MOBIKE to
signal the support of the MOBIKE protocol. This ensures that in all signal the support of the MOBIKE protocol. This ensures that in all
cases a MOBIKE capable node knows whether its peer supports MOBIKE or cases a MOBIKE capable node knows whether its peer supports MOBIKE or
not. not.
The second solution approach uses the Notify payload which is also The second solution approach uses the Notify payload which is also
used for NAT detection (via NAT_DETECTION_SOURCE_IP and used for NAT detection (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP). NAT_DETECTION_DESTINATION_IP).
Both, a Vendor ID and a Notify payload, might be used to indicate the Both a Vendor ID and a Notify payload might be used to indicate the
support of certain extensions. support of certain extensions.
Note that the node could also attempt MOBIKE optimistically with the Note that the node could also attempt MOBIKE opportunistically with
critical bit set to one when a movement has occurred. The drawback the critical bit set when an address change has occurred. The
of this approach is, however, that the an unnecessary MOBIKE message drawback of this approach is, however, that the an unnecessary MOBIKE
round is introduced on the first movement. message exchange is introduced.
Although Vendor ID payloads and Notifications are technically Although Vendor ID payloads and Notifications are technically
equivalent Notifications are already used in IKEv2 as a capability equivalent Notifications are already used in IKEv2 as a capability
negotiation mechanism and is therefore the preferred mechanism. negotiation mechanism and is therefore the preferred mechanism.
5.2 Changing a Preferred Address and Multihoming Support 5.2 Changing a Preferred Address and Multihoming Support
From MOBIKE's point of view multihoming support is integrated by From MOBIKE's point of view multihoming support is integrated by
supporting a peer address set rather than a single address and supporting a peer address set rather than a single address and
protocol mechanisms to change to use a new preferred IP address. protocol mechanisms to change to use a new preferred IP address.
skipping to change at page 12, line 49 skipping to change at page 14, line 4
Although Vendor ID payloads and Notifications are technically Although Vendor ID payloads and Notifications are technically
equivalent Notifications are already used in IKEv2 as a capability equivalent Notifications are already used in IKEv2 as a capability
negotiation mechanism and is therefore the preferred mechanism. negotiation mechanism and is therefore the preferred mechanism.
5.2 Changing a Preferred Address and Multihoming Support 5.2 Changing a Preferred Address and Multihoming Support
From MOBIKE's point of view multihoming support is integrated by From MOBIKE's point of view multihoming support is integrated by
supporting a peer address set rather than a single address and supporting a peer address set rather than a single address and
protocol mechanisms to change to use a new preferred IP address. protocol mechanisms to change to use a new preferred IP address.
From a protocol point of view each peer needs to learn the preferred From a protocol point of view each peer needs to learn the preferred
address and the peer address set somehow, implicitly or explicitly. address and the peer address set either implicitly or explicitly.
5.2.1 Storing a single or multiple addresses 5.2.1 Storing a single or multiple addresses
One design decision is whether an IKE-SA should store a single IP One design decision is whether an IKE-SA should store a single IP
address or multiple IP addresses as part of the peer address set. address or multiple IP addresses as part of the peer address set.
One option is that the other end can provide a list of addresses One option is that the other end can provide a list of addresses
which can be used as destination addresses. MOBIKE does not include which can be used as destination addresses. MOBIKE does not support
load balancing, i.e., only one IP address is set to a preferred load balancing, i.e., only one IP address is set to a preferred
address at a time and changing the preferred address typically address at a time and changing the preferred address typically
requires some MOBIKE signaling. requires some MOBIKE signaling.
Another option is to only communicate one address towards the other Another option is to only communicate one address to the other peer
peer and both peers only use that address when communicating. If and both peers only use that address when communicating. If this
this preferred address cannot be used anymore then an address update preferred address cannot be used anymore then an address update is
is sent to the other peer changing the primary address. sent to the other peer changing the preferred address.
If peer A provides a peer address set with multiple IP addresses then If peer A provides a peer address set with multiple IP addresses then
peer B can recover from a failure of the preferred address on its peer B can recover from a failure of the preferred address on its
own, meaning that when it detects that the primary path does not work own, meaning that when it detects that the primary path does not work
anymore it can either switch to a new preferred address locally anymore it can either switch to a new preferred address locally
(i.e., causing the source IP address of outgoing MOBIKE messages to (i.e., causing the source IP address of outgoing MOBIKE messages to
have a non-preferred address) or to try an IP address from A's peer have a non-preferred address) or try an IP address from A's peer
address set. If peer B only received a single IP address as the A's address set. If peer B only received a single IP address as the A's
peer address set then peer B can only change its own preferred peer address set then peer B can only change its own preferred
address. The other end has to wait for an address update from peer A address. The other end has to wait for an address update from peer A
with a new IP address in order to fix the problem. The main with a new IP address in order to fix the problem. The main
advantage about using a single IP address for the remote host is that advantage about using a single IP address for the remote host is that
it makes retransmission easy, and it also simplifies the recover it makes retransmission easy, and it also simplifies the recovery
procedure. The peer, whose IP address changed, must start recovery procedure. The peer, whose IP address changed, must start the
process and send the new IP address to the other peer. Failures recovery process and send the new IP address to the other peer.
along the path are not well covered with advertising a single IP Failures along the path are not well covered with advertising a
address. single IP address.
The single IP address approach will not work if both peers happen to The single IP address approach will not work if both peers happen to
loose their IP address at the same time (due to, say, the failure of loose their IP address at the same time (due to, say, the failure of
one of the links that both nodes are connected to). It may also one of the links that both nodes are connected to). It may also
require the IKEv2 window size to be larger than 1, especially if only require the IKEv2 window size to be larger than 1, especially if only
direct indications are used. This is because the host needs to be direct indications are used. This is because the host needs to be
able to send the IP address change notifications before it can switch able to send the IP address change notifications before it can switch
to another address, and depending on the return routability checks, to another address, and depending on the return routability checks,
retransmissions policies etc, it might be hard to make the protocol retransmissions policies etc, it might be hard to make the protocol
such that it works with window size of 1 too. Furthermore, the such that it works with window size of 1 too. Furthermore, the
single IP address approach does not really benefit much from indirect single IP address approach does not really benefit much from indirect
indications as the peer receiving these indications might not be able 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 to fix the situation by itself (e.g., even if a peer receives an ICMP
host unreachable message for the old IP address, it cannot try other host unreachable message for the old IP address, it cannot try other
IP addresses, since they are unknown). IP addresses, since they are unknown).
The problems with IP address list are mostly in its complexity. The problems with IP address lists are mostly in its complexity.
Notification and recovery processes are more complex. Both ends can
Notification and recovery processes are more complex, as both end can recover from the IP address changes. However, both peers should not
recover from the IP address changes. There is also possibilities attempt to recover at the same time or nearly the same time as it
that both ends tries to recover at the same time and this must be could cause them to lose connectivity. The MOBIKE protocol is
taken care in the protocol. required to prevent this.
Please note that the discussed aspect is partially different from the The previous discussion is independent of the question of how many
question how many addresses to sent in a single MOBIKE message. A addresses to send in a single MOBIKE message. A MOBIKE message might
MOBIKE message might be able to carry more than one IP address (with be able to carry more than one IP address (with the IP address list
the IP address list approach) or a single address only. The latter approach) or a single address only. The latter approach has the
approach has the advantage of dealing with NAT traversal in a proper advantage of dealing with NAT traversal in a proper fashion. A NAT
fashion. A NAT cannot change addresses carried inside the MOBIKE cannot change addresses carried inside the MOBIKE message but it can
message but it can change IP address (and transport layer addresses) change IP address (and transport layer addresses) in the IP header
in the IP header and Transport Protocol header (if NAT traversal is and Transport Protocol header (if NAT traversal is enabled).
enabled). Furthermore, a MOBIKE message carrying the peer address Furthermore, a MOBIKE message carrying the peer address set could be
set could be idempotent (i.e., always resending the full address idempotent (i.e., always resending the full address list) or the
list) or does the protocol allow add/delete operations to be protocol may allow add/delete operations to be specified.
specified. [I-D.dupont-ikev2-addrmgmt], for example, offers an [I-D.dupont-ikev2-addrmgmt], for example, offers an approach which
approach which defines add/delete operations. The same is true for defines add/delete operations. The same is true for the dynamic
the dynamic address reconfiguration extension for SCTP address reconfiguration extension for SCTP
[I-D.ietf-tsvwg-addip-sctp]. [I-D.ietf-tsvwg-addip-sctp].
5.2.2 Indirect or Direct Indication 5.2.2 Indirect or Direct Indication
An indication to change the preferred IP address might be either An indication to change the preferred IP address might be either
direct or indirect. direct or indirect.
Direct indication: Direct indication:
A direct indication means that the other peer will send an message A direct indication means that the other peer will send an message
skipping to change at page 14, line 48 skipping to change at page 15, line 51
Indirect indication: Indirect indication:
An indirect indication to change the preferred address can be An indirect indication to change the preferred address can be
obtained by observing the environment. An indirect indication obtained by observing the environment. An indirect indication
might, for example, be be the receipt of an ICMP message or might, for example, be be the receipt of an ICMP message or
information of a link failure. This information should be seen as information of a link failure. This information should be seen as
a hint and might not directly cause any changes to the preferred a hint and might not directly cause any changes to the preferred
address. Depending on the local policy MOBIKE might decide to address. Depending on the local policy MOBIKE might decide to
perform a dead-peer detection exchange for the preferred address perform a dead-peer detection exchange for the preferred address
pair (or another address pair from the peer address set). When a pair (or another address pair from the peer address set). When a
peer detects that the other end started to use different source IP peer detects that the other end started to use a different source
address than before, it might want to authorize the new preferred IP address than before, it might want to authorize the new
address (if not already authorized). A peer might also start a preferred address (if not already authorized). A peer might also
connectivity test of this particular address.If a bidirectionally start a connectivity test of this particular address. If a
operational address pair is selected then MOBIKE needs to bidirectionally operational address pair is selected then MOBIKE
communicate this new preferred address to its remote peer. needs to communicate this new preferred address to its remote
peer.
MOBIKE will utilize both mechanisms, direct and indirect indications, MOBIKE will utilize both mechanisms, direct and indirect indications,
to make a more intelligent decision which address pair to select as to make a more intelligent decision which address pair to select as
the preferred address. The more information will be available to the preferred address. The more information will be available to
MOBIKE the faster a new operational preferred address pair can be MOBIKE the faster a new primary path can be selected among the
selected among the available candiates. available candiates.
5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection
This section discusses the suitability of the IKEv2 dead-peer This section discusses the suitability of the IKEv2 dead-peer
detection (DPD) mechanism for connectivity tests between address detection (DPD) mechanism for connectivity tests between address
pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but
it needs to be investigated whether it can be used for MOBIKE it needs to be investigated whether it can be used for MOBIKE
purposes as well. purposes as well.
The IKEv2 DPD mechanism is done by sending an empty informational The IKEv2 DPD mechanism is done by sending an empty informational
exchange packet to the other peer, in which case the other end will exchange packet to the other peer, in which case the other end will
respond with an acknowledgement. If no acknowledgement is received respond with an acknowledgement. If no acknowledgement is received
after certain timeout (and after couple of retransmissions), the after a certain timeout (and after couple of retransmissions), the
other peer is considered to be not reachable. Note that the receipt other peer is considered to be not reachable. Note that the receipt
of IPsec protected data traffic is also a guarantee that the other of IPsec protected data traffic is also a guarantee that the other
peer is alive. peer is alive.
When reusing dead-peer detection in MOBIKE for connectivity tests it When reusing dead-peer detection in MOBIKE for connectivity tests it
seems to be reasonable to try other IP addresses (if they are seems to be reasonable to try other IP addresses (if they are
available) in case of unsuccessful connectivity test for a given available) in case of an unsuccessful connectivity test for a given
address pair. Dead-peer detection messages using a different address address pair. Dead-peer detection messages using a different address
pair should use the same message-id as the original dead-peer pair should use the same message-id as the original dead-peer
detection message (i.e. they are simply retransmissions of the detection message (i.e. they are simply retransmissions of the
dead-peer detection packet using different destination IP address). dead-peer detection packet using different destination IP address).
If different message-id is used then it violates constraints placed If different message-id is used then it violates constraints placed
by the IKEv2 specification on the DPD message with regard to the by the IKEv2 specification on the DPD message with regard to the
mandatory ACK for each message-id, causing the IKEv2 SA to be mandatory ACK for each message-id, causing the IKEv2 SA to be
deleted. deleted.
If MOBIKE strictly follows the guidelines of the dead-peer detection If MOBIKE strictly follows the guidelines of the dead-peer detection
mechanism in IKEv2 then an IKE-SA should be marked as dead and mechanism in IKEv2 then an IKE-SA should be marked as dead and
deleted if the connectivity test for all address pairs fails. Note deleted if the connectivity test for all address pairs fails. Note
that this is not in-line with the approach used, for example, in SCTP that this is not in-line with the approach used, for example, in SCTP
where a failed connectivity test for an address does not lead to (a) where a failed connectivity test for an address does not lead to (a)
the IP address or IP address pair to be marked as dead and (b) delete 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 state. Connectivity tests will be continued for the address pairs in
hope that the problem will recover soon. hope that the problem will recover soon.
Note, that as IKEv2 implementations might have window size of 1, Note that as IKEv2 implementations might have window size of 1, which
which prevents to initiate a dead-peer detection exchange while doing prevents it from initiating a dead-peer detection exchange while
another exchange. As a result all other exchanges experience the doing another exchange. As a result, all other exchanges experience
identical retransmission policy as used for the dead-peer detection. the identical retransmission policy as used for the dead-peer
detection.
The dead-peer detection for the other IP address pairs can also be The dead-peer detection for the other IP address pairs can also be
executed simultaneously (with a window size larger than 1), meaning executed simultaneously (with a window size larger than 1), meaning
that after the initial timeout of the preferred address expires, we that after the initial timeout of the preferred address expires, we
send packets simultaneously to all other address pairs. It is send packets simultaneously to all other address pairs. It is
necessary to differentiate individual acknowledgement messages in necessary to differentiate individual acknowledgement messages in
order to determine which address pair is operational. Therefore the order to determine which address pair is operational. Therefore the
source IP address of the acknowledgement should match the destination source IP address of the acknowledgement should match the destination
IP towards the message was previously sent. IP towards the message that was previously sent.
Also the other peer is most likely going to reply only to the first Also the other peer is most likely going to reply only to the first
packet it receives, and that first packet might not be the best (by packet it receives, and that first packet might not be the best (by
whatever criteria) address pair. The reason the other peer is only whatever criteria) address pair. The reason the other peer is only
responding to the first packet it receives, is that implementations responding to the first packet it receives is that implementations
should not send retransmissions if they have just sent out identical should not send retransmissions if they have just sent out an
response message. This is to protect the packet multiplication identical response message. This is to protect the packet
problem, which can happen if some node in the network queues up multiplication problem, which can happen if some node in the network
packets and then send them to the destination. If destination will queues up packets and then sends them to the destination. If the
reply to all of them then the other end will again see multiple destination were to reply to all of them then the other end will
packets, and will reply to all of them etc. again see multiple packets, and will reply to all of them, etc.
The protocol should also be nice to the network, meaning, that when The protocol should also be nice to the network, meaning, that when
some core router link goes down, and a large number of MOBIKE clients some core router link goes down, and a large number of MOBIKE clients
notice it, they should not start sending a large number of messages notice it, they should not start sending a large number of messages
while trying to recover from the problem. This might be especially while trying to recover from the problem. This might be especially
bad if this happens because packets are dropped because of the bad because packets are dropped because of the congested network. If
congested network. If MOBIKE clients simultaneously try to test all MOBIKE clients simultaneously try to test all possible address pairs
possible address pairs by executing connectivity tests then the by executing connectivity tests then the congestion problem only gets
congestion problem only gets worse. worse.
Also note, that the IKEv2 dead-peer detection is not sufficient for Also note that the IKEv2 dead-peer detection is not sufficient for
the return routability check. See Section 5.6 for more information. the return routability check. See Section 5.6 for more information.
5.3 Simultaneous Movements 5.3 Simultaneous Movements
MOBIKE does not aim to provide a full mobility solution which allows MOBIKE does not aim to provide a full mobility solution which allows
simultaneous movements. Instead, the MOBIKE working group focuses on simultaneous movements. Instead, the MOBIKE working group focuses on
selected scenarios as described in Section 3. Some of the scenarios selected scenarios as described in Section 3. Some of the scenarios
assume that one peer has a fixed set of addresses (from which some assume that one peer has a fixed set of addresses (from which some
subset might be in use). Thus it cannot move to the address unknown subset might be in use). Thus it cannot move to the address unknown
to the other peer. Situations where both peers move and the movement to the other peer. Situations in which both peers move and the
notifications cannot reach the other peer, is outside the scope of movement notifications cannot reach the other peer are outside the
the MOBIKE WG. MOBIKE has not being chartered to deal with the scope of the MOBIKE WG. MOBIKE has not being chartered to deal with
rendezvous problem, or with the introduction of any new entities in the rendezvous problem, or with the introduction of any new entities
the network. in the network.
Note, that if only a single address is stored in the peer address set Note that if only a single address is stored in the peer address set
(instead of an address list) we might end up in the case where it (instead of an address list) we might end up in the case where it
seems that both peers changed their addresses at the same time. This seems that both peers changed their addresses at the same time. This
is something that the protocol must deal with. is something that the protocol must deal with.
Three cases can be differentiated: Three cases can be differentiated:
o Two mobile nodes obtain a new address at the same time, and then o Two mobile nodes obtain a new address at the same time, and then
being unable to tell each other where they are (in a being unable to tell each other where they are (in a
break-before-make scenario). This problem is called the break-before-make scenario). This problem is called the
rendezvous problem, and is traditionally solved by introducing rendezvous problem, and is traditionally solved by introducing
skipping to change at page 17, line 41 skipping to change at page 18, line 47
protocol identifiers are modified (which then requires UDP protocol identifiers are modified (which then requires UDP
encapsulation for subsequent IPsec protected data traffic). encapsulation for subsequent IPsec protected data traffic).
Therefore, the required IP address information is taken from the IP Therefore, the required IP address information is taken from the IP
header (if a NAT was detected who rewrote IP header information) header (if a NAT was detected who rewrote IP header information)
rather than from the protected payload. This problem is not new and rather than from the protected payload. This problem is not new and
was discovered during the design of mobility protocol where the only was discovered during the design of mobility protocol where the only
valuable information is IP address information. valuable information is IP address information.
One of the goals in the MOBIKE protocol is to securely exchange one One of the goals in the MOBIKE protocol is to securely exchange one
or more addresses of the peer address set and to securely set the or more addresses of the peer address set and to securely set the
primary address. If not other protocol is used to securely retrieve primary address. If no other protocol is used to securely retrieve
the IP address and port information allocated by the NAT then it is the IP address and port information allocated by the NAT then it is
not possible to tackle all attacks against MOBIKE. Various solution not possible to tackle all attacks against MOBIKE. Various solution
approaches have been presented: approaches have been presented:
o Securely retrieving IP address and port information allocated by o Securely retrieving IP address and port information allocated by
the NAT using a protocol different from MOBIKE. This approach is the NAT using a protocol different from MOBIKE. This approach is
outside the scope of the MOBIKE working group since other working outside the scope of the MOBIKE working group since other working
groups, such as MIDCOM and NSIS, already deal with this problem. groups, such as MIDCOM and NSIS, already deal with this problem.
The MOBIKE protocol can benefit from the interaction with these The MOBIKE protocol can benefit from the interaction with these
protocols. protocols.
skipping to change at page 18, line 15 skipping to change at page 19, line 22
o Design a protocol in such a way that NAT boxes are able to inspect o Design a protocol in such a way that NAT boxes are able to inspect
(or even participate) in the protocol exchange. This approach was (or even participate) in the protocol exchange. This approach was
taken with HIP but is not an option for IKEv2 and MOBIKE. taken with HIP but is not an option for IKEv2 and MOBIKE.
o Disable NAT-T support by indicating the desire never to use o Disable NAT-T support by indicating the desire never to use
information from the (unauthenticated) header. While this information from the (unauthenticated) header. While this
approach prevents some problems it effectively disallows the approach prevents some problems it effectively disallows the
protocol to work in certain environments. protocol to work in certain environments.
There is no way to distinguish the cases where there is NAT along the There is no way to distinguish the cases where there is NAT along the
path which modifies the header information in packets or whether an path that modifies the header information in packets or whether an
adversary mounts an attack. If NAT is detected in the IKE SA adversary mounts an attack. If NAT is detected in the IKE SA
creation, that should automatically disable the MOBIKE extensions and creation, that should automatically disable the MOBIKE extensions and
use NAT-T. use NAT-T.
A design question is whether NAT detection capabilities should be A design question is whether NAT detection capabilities should be
enabled only during the initial exchange or even at subsequent enabled only during the initial exchange or even at subsequent
message exchanges. If MOBIKE is executed with no NAT along the path message exchanges. If MOBIKE is executed with no NAT along the path
when the IKE SA was created, then a NAT which appears after moving to when the IKE SA was created, then a NAT which appears after moving to
a new network might cannot be dealt with if NAT detection is enabled a new network cannot be dealt with if NAT detection is enabled only
only during the initial exchange. Hence, it might be desirable to during the initial exchange. Hence, it might be desirable to also
also support scenario where a MOBIKE peer moves from a network which support a scenario where a MOBIKE peer moves from a network which
does not deploy a NAT to a network which uses a private address does not deploy a NAT to a network which uses a private address
space. space.
A NAT prevention mechanism can be used to make sure that no adversary A NAT prevention mechanism can be used to make sure that no adversary
can interact with the protocol if no NAT is expected between the can interact with the protocol if no NAT is expected between the
Initiator and the Responder. Initiator and the Responder.
The support for NAT traversal is certainly one of the most important The support for NAT traversal is certainly one of the most important
design decisions with an impact on other protocol aspects. design decisions with an impact on other protocol aspects.
skipping to change at page 19, line 12 skipping to change at page 20, line 21
routing infrastructure can prevent the sent packets from reaching routing infrastructure can prevent the sent packets from reaching
their destination. Or a failure of an interface on one side can be their destination. Or a failure of an interface on one side can be
related to the failure of an interface on the other side, making it related to the failure of an interface on the other side, making it
necessary to change more than one address at a time. necessary to change more than one address at a time.
5.6 Return Routability Tests 5.6 Return Routability Tests
Setting a new preferred address which is subsequently used for Setting a new preferred address which is subsequently used 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 compute mechanisms have been proposed in the past to allow a peer to
the answer to this question: determine the answer to this question:
o The addresses a peer is using is part of a certificate. [RFC3554] o The addresses a peer is using are part of a certificate.
introduced this approach. If the other peer is, for example, a [RFC3554] introduced this approach. If the other peer is, for
security gateway with a limited set of fixed IP addresses, then example, a security gateway with a limited set of fixed IP
the security gateway may have a certificate with all the IP addresses, then the security gateway may have a certificate with
addresses in the certificate. all the IP addresses in the certificate.
o A return routability check is performed before the address is used o A return routability check is performed before the address is used
to ensure that the peer is reachable at the indicated address. to ensure that the peer is reachable at the indicated address.
Without performing an authorization decision a malicious peer can Without performing an authorization decision a malicious peer can
redirect traffic towards a third party or a blackhole. redirect traffic towards a third party or a blackhole.
An IP address should not be used as a primary address without An IP address should not be used as a primary address without
computing the authorization decision. If the addresses are part of computing the authorization decision. If the addresses are part of
the certificate then it is not necessary execute the weaker return the certificate then it is not necessary to execute the weaker return
routability test. If multiple addresses are communicated to another routability test. If multiple addresses are communicated to another
peer as part of the peer address set then some of these addresses peer as part of the peer address set then some of these addresses
might be already verified even if the primary address is still might be already verified even if the primary address is still
operational. operational.
Another option is to use the [I-D.dupont-mipv6-3bombing] approach Another option is to use the [I-D.dupont-mipv6-3bombing] approach
which suggests to do a return routability test only if you have to which suggests to do a return routability test only if you have to
send an address update from some other address than the indicated send an address update from some other address than the indicated
preferred address. preferred address.
Finally it would be possible not to execute return routability checks Finally it would be possible not to execute return routability checks
at all. In case of indirect change notifications then we only move at all. In case of indirect change notifications then we only move
to the new preferred address after successful dead-peer detection on to the new preferred address after successful dead-peer detection on
the new address, which is already a return routability check. With a the new address, which is already a return routability check. With a
direct notifications the authenticated peer may have provided an direct notifications the authenticated peer may have provided an
authenticated IP address, thus we could simply trust the other end. authenticated IP address, thus we could simply trust the other end.
There is no way external attacker can cause any attacks, but we are There is no way external attacker can cause any attacks, but we are
not protected by the internal attacker, i.e. the authenticated peer not protected from the internal attacker, i.e. the authenticated
forwarding its traffic to the new address. On the other hand we do peer forwarding its traffic to the new address. On the other hand we
know the identity of the peer in that case. do know the identity of the peer in that case.
As such, it sees that there it is also a policy issue when to As such, it seems that there it is also a policy issue when to
schedule a return routability test. schedule a return routability test.
The basic format of the return routability check could be similar The basic format of the return routability check could be similar to
than dead-peer detection, but the problem is that if that fails then dead-peer detection, but the problem is that if that fails then the
the IKEv2 specification requires the IKE SA to be deleted. Because IKEv2 specification requires the IKE SA to be deleted. Because of
of this we might need to do some kind of other exchange. this we might need to do some kind of other exchange.
There are potential attacks if a return routability checks include There are potential attacks if a return routability check does not
some kind of nonce. In this attack the valid end points sends include some kind of nonce. In this attack the valid end point sends
address update notification for the third party, trying to get all address update notification for the third party, trying to get all
the traffic to be sent there, causing denial of service attack. If the traffic to be sent there, causing a denial of service attack. If
the return routability checks does not contain any cookies or other the return routability checks does not contain any cookies or other
random information not known by the other end, then that valid node random information not known by the other end, then that valid node
could reply to the return routability checks even when it cannot see could reply to the return routability checks even when it cannot see
the request. This might cause the other end to turn the traffic to the request. This might cause the other end to turn the traffic to
there, even when the true original recipient cannot be reached at there, even when the true original recipient cannot be reached at
this address. this address.
The IKEv2 NAT-T mechanism does not perform any return routability The IKEv2 NAT-T mechanism does not perform any return routability
checks. It simply uses the last seen source IP address used by the checks. It simply uses the last seen source IP address used by the
other peer where to send response packets. An adversary can change other peer as the destination address to send response packets. An
those IP addresses, and can cause the response packets to be sent to adversary can change those IP addresses, and can cause the response
wrong IP address. The situation is self-fixing when the adversary is packets to be sent to wrong IP address. The situation is self-fixing
no longer able to modify packets and the first packet with true IP when the adversary is no longer able to modify packets and the first
address reaches the other peer. In a certain sense mobility handling packet with true IP address reaches the other peer. In a certain
makes this attack difficult for an adversary since it needs to be sense mobility handling makes this attack difficult for an adversary
located somewhere along the path where the individual paths ({CoA1, since it needs to be located somewhere along the path where the
..., CoAn} towards the destination IP address) have a shared path or individual paths ({CoA1, ..., CoAn} towards the destination IP
if the adversary is located near the MOBIKE client then it needs to address) have a shared path or if the adversary is located near the
follow the users mobility patterns. With IKEv2 NAT-T the genuine MOBIKE client then it needs to follow the users mobility patterns.
client can cause third party bombing by redirecting all the traffic With IKEv2 NAT-T, the genuine client can cause third party bombing by
pointed to him to third party. As the MOBIKE protocol tries to redirecting all the traffic pointed to him to third party. As the
provide equal or better security than IKEv2 NAT-T the MOBIKE protocol MOBIKE protocol tries to provide equal or better security than IKEv2
should protect against these attacks. NAT-T the MOBIKE protocol should protect against these attacks.
There might be also return routability information available from the There might be also return routability information available from the
other parts of the system too (as shown in Figure 3), but the checks other parts of the system too (as shown in Figure 3), but the checks
done might have a different quality. There are multiple levels for done might have a different quality. There are multiple levels for
return routability checks: return routability checks:
o None, no tests o None, no tests
o A party willing to answer is on the path to the claimed address. o A party willing to answer is on the path to the claimed address.
This is the basic form of return routability test. This is the basic form of return routability test.
o There is an answer from the tested address, and that answer was o There is an answer from the tested address, and that answer was
authenticated (including the address) to be from our peer. authenticated (including the address) to be from our peer.
o There was an authenticated answer from the peer, but it is not o There was an authenticated answer from the peer, but it is not
guaranteed to be from the tested address or path to it (because guaranteed to be from the tested address or path to it (because
the peer can construct a response without seeing the request). the peer can construct a response without seeing the request).
The basic return routability checks do not protect against 3rd party The basic return routability checks do not protect against 3rd party
bombing, if the attacker is along the path, as the attacker can bombing if the attacker is along the path, as the attacker can
forward the return routability checks to the real peer (even if those forward the return routability checks to the real peer (even if those
packets are cryptographically authenticated). packets are cryptographically authenticated).
If the address to be tested is inside the MOBIKE packet too, then the If the address to be tested is inside the MOBIKE packet too, then the
adversary cannot forward packets, thus it prevents 3rd party adversary cannot forward packets, thus it prevents 3rd party
bombings. bombings.
If the reply packet can be constructed without seeing the request If the reply packet can be constructed without seeing the request
packet (for example, if there is no nonce, challenge or similar packet (for example, if there is no nonce, challenge or similar
mechanism to show liveness), then the genuine peer can cause 3rd mechanism to show liveness), then the genuine peer can cause 3rd
party bombing, by replying to those requests without seeing them at party bombing, by replying to those requests without seeing them at
all. all.
Other levels might only provide information that there is someone at Other levels might only provide information that there is someone at
the IP address which replied to the request. There might not be an the IP address which replied to the request. There might not be an
indication that the reply was freshly generated or repeated, or the indication that the reply was freshly generated or repeated, or the
request might have been transmitted from a different source address. request might have been transmitted from a different source address.
Requirements for a MOBIKE protocol for the return routability test Requirements for a MOBIKE protocol for the return routability test
might be able to verify that there is same (cryptographically) might be able to verify that there is the same (cryptographically)
authenticated node at the other peer and it can now receive packets authenticated node at the other peer and it can now receive packets
from the IP address it claims to have. from the IP address it claims to have.
5.7 Employing MOBIKE results in other protocols 5.7 Employing MOBIKE results in other protocols
If MOBIKE has learned about new locations or verified the validity of If MOBIKE has learned about new locations or verified the validity of
an address through a return routability test, can this information be an address through a return routability test, can this information be
useful for other protocols? 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.
skipping to change at page 22, line 29 skipping to change at page 23, line 35
results in some manner, for instance by sharing experienced results in some manner, for instance by sharing experienced
throughput information for address pairs. This may apply to MOBIKE throughput information for address pairs. This may apply to MOBIKE
as well, assuming it co-exists with non-IPsec protocols that are as well, assuming it co-exists with non-IPsec protocols that are
faced with the same multiaddressing choices. faced with the same multiaddressing choices.
Nevertheless, all of this is outside the scope of current MOBIKE base Nevertheless, all of this is outside the scope of current MOBIKE base
protocol design and may be addressed in future work. protocol design and may be addressed in future work.
5.8 Scope of SA changes 5.8 Scope of SA changes
Most sections of this document discuss design considers for updating Most sections of this document discuss design considerations for
and maintaining addresses for the IKE-SA. However, changing the updating and maintaining addresses for the IKE-SA. However, changing
preferred address also has an impact for IPsec SAs. The outer tunnel the preferred address also has an impact for IPsec SAs. The outer
header addresses (source IP and destination IP addresses) need to be tunnel header addresses (source IP and destination IP addresses) need
modified according to the preferred address pair to allow the IPsec to be modified according to the primary path to allow the IPsec
protected data traffic to travel along the same path as the MOBIKE protected data traffic to travel along the same path as the MOBIKE
packets (if we only consider the IP header information). packets (if we only consider the IP header information).
The basic question is that how the IPsec SAs are changed to use the The basic question is then how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling new address pair (the same address pair as the MOBIKE signaling
traffic -- the preferred address pair). One option is that when the traffic -- the primary path). One option is that when the IKE SA
IKE SA address is changed then automatically all IPsec SAs associated address is changed then automatically all IPsec SAs associated with
with it are moved along with it to new address pair. Another option it are moved along with it to new address pair. Another option is to
is to have separate exchange to move the IPsec SAs separately. have a separate exchange to move the IPsec SAs separately.
If IPsec SAs should be updated separately then a more efficient If IPsec SAs should be updated separately then a more efficient
format than notification payload is needed. A notification payload format than notification payload is needed. A notification payload
can only store one SPI per payload. A separate payload which would can only store one SPI per payload. A separate payload which would
have list of IPsec SA SPIs and new preferred address. If there are have list of IPsec SA SPIs and new preferred address. If there are
large number of IPsec SAs, those payloads can be quite large unless large number of IPsec SAs, those payloads can be quite large unless
ranges of SPI values are supported. If we automatically move all 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 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 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 addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires
implementations to keep track which IPsec SAs are created using which implementations to keep track which IPsec SAs are created using which
IKE SA. IKE SA.
If we do allow each IPsec SAs address sets to be updated separately, If we do allow each IPsec SAs address set to be updated separately,
then we can support scenarios, where the machine has fast and/or then we can support scenarios, where the machine has fast and/or
cheap connections and slow and/or expensive connections, and it wants cheap connections and slow and/or expensive connections, and it wants
to allow moving some of the SAs to the slower and/or more expensive to allow moving some of the SAs to the slower and/or more expensive
connection, and prevents to move the news video stream from the WLAN connection, and prevent the move, for example, of the news video
to the GPRS link. stream from the WLAN to the GPRS link.
On the other hand, even if we tie the IKE SA update to the IPsec SA On the other hand, even if we tie the IKE SA update to the IPsec SA
update, then we can create separate IKE SAs for this scenario, e.g., update, then we can create separate IKE SAs for this scenario, e.g.,
we create one IKE SA which have both links as endpoints, and it is we create one IKE SA which have both links as endpoints, and it is
used for important traffic, and then we create another IKE SA which used for important traffic, and then we create another IKE SA which
have only the fast and/or cheap connection, which is then used for have only the fast and/or cheap connection, which is then used for
that kind of bulk traffic. that kind of bulk traffic.
5.9 Zero Address Set 5.9 Zero Address Set
skipping to change at page 23, line 46 skipping to change at page 25, line 5
link is broken. link is broken.
The local policy could then decide how long the peer would allow The local policy could then decide how long the peer would allow
other peers to be disconnected, e.g., whether this is only allowed other peers to be disconnected, e.g., whether this is only allowed
for few minutes, or do they allow users to disconnect Friday evening for few minutes, or do they allow users to disconnect Friday evening
and reconnect Monday morning (consuming resources during weekend too, and reconnect Monday morning (consuming resources during weekend too,
but on the other hand not more than is normally used during week but on the other hand not more than is normally used during week
days, but we do not need lots of extra resources on the Monday days, but we do not need lots of extra resources on the Monday
morning to support all those people connecting back to network). morning to support all those people connecting back to network).
From a technical point of view this features addresses two aspects: From a technical point of view this feature addresses two aspects:
o There is no need to transmit IPsec data traffic. IPsec protected o There is no need to transmit IPsec data traffic. IPsec protected
data needs to be dropped which saves bandwidth. This does not data needs to be dropped which saves bandwidth. This does not
provide a functional benefit i.e, nothing breaks if this feature provide a functional benefit i.e, nothing breaks if this feature
is not provided. is not provided.
o MOBIKE signaling messages are also ignored and need to be o MOBIKE signaling messages are also ignored and need to be
suspended. The IKE-SA must not be deleted and the suspend suspended. The IKE-SA must not be deleted and the suspend
functionality (realized with the zero address set) might require functionality (realized with the zero address set) might require
the IKE-SA to be tagged with a lifetime value since the IKE-SA the IKE-SA to be tagged with a lifetime value since the IKE-SA
skipping to change at page 24, line 36 skipping to change at page 25, line 43
informational exchange already specified in the IKEv2, or via a informational exchange already specified in the IKEv2, or via a
MOBIKE specific message exchange. Using informational exchange has MOBIKE specific message exchange. Using informational exchange has
the main advantage that it is already specified in the IKEv2 and the main advantage that it is already specified in the IKEv2 and
implementations incorporated the functionality already. implementations incorporated the functionality already.
Another question is the basic format of the address update Another question is the basic format of the address update
notifications. The address update notifications can include multiple notifications. The address update notifications can include multiple
addresses, which some can be IPv4 and some IPv6 addresses. The addresses, which some can be IPv4 and some IPv6 addresses. The
number of addresses is most likely going to be quite small (less than number of addresses is most likely going to be quite small (less than
10). The format might need to indicate a preference value for each 10). The format might need to indicate a preference value for each
address Furthermore, one of the addresses in the peer address set address. Furthermore, one of the addresses in the peer address set
must be labeled as the preferred address. The format could either must be labeled as the preferred address. The format could either
contain the preference number, giving out the relative order of the contain the preference number, giving out the relative order of the
addresses, or it could simply be ordered list of IP addresses in the addresses, or it could simply be ordered list of IP addresses in the
order of the most preferred first. While two addresses can have the order of the most preferred first. While two addresses can have the
same preference value an ordered list avoids this problem. same preference value an ordered list avoids this problem.
Even if load balancing is currently outside the scope of MOBIKE, Even if load balancing is currently outside the scope of MOBIKE,
there might be future work to include this feature. The format there might be future work to include this feature. The format
selected needs to be flexible enough to include additional selected needs to be flexible enough to include additional
information (e.g., to enable load balancing). This might be information (e.g., to enable load balancing). This might be
skipping to change at page 25, line 17 skipping to change at page 26, line 26
addresses. addresses.
Having multiple payloads each having one IP address makes the Having multiple payloads each having one IP address makes the
protocol probably easier to parse, as we can already use the normal protocol probably easier to parse, as we can already use the normal
IKEv2 payload parsing procedures to get the list out. It also offers IKEv2 payload parsing procedures to get the list out. It also offers
easy way for the extensions, as the payload probably contains only easy way for the extensions, as the payload probably contains only
the type of the IP address (or the type is encoded to the payload the 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 type), and the IP address itself, and as each payload already has
length associated to it, we can detect if there is any extra data length associated to it, we can detect if there is any extra data
after the IP address. Some implementations might have problems after the IP address. Some implementations might have problems
parsing too long list of IKEv2 payloads, but if the sender sends them parsing too long of a list of IKEv2 payloads, but if the sender sends
in the most preferred first, the other end can simply only take n them in the most preferred first, the other end can simply only take
first addresses and use them. the first addresses and use them.
Having all IP addresses in one big MOBIKE specified internal format Having all IP addresses in one big MOBIKE specified internal format
provides more compact encoding, and keeps the MOBIKE implementation provides more compact encoding, and keeps the MOBIKE implementation
more concentrated to one module. more concentrated to one module.
The next choice is which type of payloads to use. IKEv2 already The next 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.
skipping to change at page 26, line 19 skipping to change at page 28, line 19
packets. The IP addresses in IP header of the packets are not packets. The IP addresses in IP header of the packets are not
authenticated, thus the protocol defined must take care that they are authenticated, thus the protocol defined must take care that they are
only used as an indication that something might be different, they only used as an indication that something might be different, they
should not cause any direct actions. should not cause any direct actions.
Attacker can also spoof ICMP error messages in an effort to confuse Attacker can also spoof ICMP error messages in an effort to confuse
the peers about which addresses are not working. At worst this the peers about which addresses are not working. At worst this
causes denial of service and/or the use of non-preferred addresses, causes denial of service and/or the use of non-preferred addresses,
so it is not that serious. so it is not that serious.
One type of attacks which needs to be taken care of the MOBIKE One type of attack that needs to be taken care of in the MOBIKE
protocol is also various flooding attacks. See protocol is also various flooding attacks. See
[I-D.ietf-mip6-ro-sec] and [Aur02] for more information about [I-D.ietf-mip6-ro-sec] and [Aur02] for more information about
flooding attacks. flooding attacks.
[EDITOR's NOTE: This section needs more work.]
7. IANA Considerations 7. IANA Considerations
This document does not introduce any IANA considerations. This document does not introduce any IANA considerations.
8. Acknowledgments 8. Acknowledgments
This document is the result of discussions in the MOBIKE working This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen, group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol and Joe Touch James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
for their discussion input. Udo Schilcher, Tom Henderson and Maureen Stillman for their input.
9. References We would like to particularly thank Pasi Eronen for tracking open
issues on the MOBIKE mailing list. He helped us to make good
progress on the document.
9.1 Normative references 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 their solution.
o Some text is need 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 TBD.
10. 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), October Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.
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-05 (work Internet Protocol",
in progress), December 2004. Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December
2004.
9.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",
in progress), October 2004. Internet-Draft draft-arkko-multi6dt-failure-detection-00,
October 2004.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[I-D.dupont-mipv6-3bombing] [I-D.dupont-mipv6-3bombing]
Dupont, F., "A note about 3rd party bombing in Mobile Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), IPv6", Internet-Draft draft-dupont-mipv6-3bombing-01,
February 2004. January 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-02 Security Design Background",
(work in progress), October 2004. Internet-Draft draft-ietf-mip6-ro-sec-02, October 2004.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with Nikander, P., "End-Host Mobility and Multi-Homing with
Host Identity Protocol", draft-ietf-hip-mm-00 (work in Host Identity Protocol",
progress), October 2004. Internet-Draft draft-ietf-hip-mm-00, October 2004.
[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), February Pools", Internet-Draft draft-crocker-celp-00, February
2004. 2004.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[I-D.ietf-tsvwg-addip-sctp] [I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP) Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-09 (work in progress), June Internet-Draft draft-ietf-tsvwg-addip-sctp-10, January
2004. 2005.
[I-D.dupont-ikev2-addrmgmt] [I-D.dupont-ikev2-addrmgmt]
Dupont, F., "Address Management for IKE version 2", Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-06 (work in progress), October Internet-Draft draft-dupont-ikev2-addrmgmt-06, October
2004. 2004.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart,
"On the Use of Stream Control Transmission Protocol (SCTP) "On the Use of Stream Control Transmission Protocol (SCTP)
with IPsec", RFC 3554, July 2003. with IPsec", RFC 3554, July 2003.
[I-D.ietf-ipv6-optimistic-dad]
Moore, N., "Optimistic Duplicate Address Detection for
IPv6", Internet-Draft draft-ietf-ipv6-optimistic-dad-05,
February 2005.
[I-D.ietf-ipv6-unique-local-addr]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses",
Internet-Draft draft-ietf-ipv6-unique-local-addr-09,
January 2005.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management
API, Version 2", RFC 2367, July 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las Vegas, Security Applications Conference, pages 78-87, Las Vegas,
NV USA, December 2002. NV USA, December 2002.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
Fredrikinkatu 47 Fredrikinkatu 47
HELSINKI FIN-00100 HELSINKI FIN-00100
FI FI
EMail: kivinen@safenet-inc.com Email: kivinen@safenet-inc.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
EMail: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 32, line 41 skipping to change at page 35, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 93 change blocks. 
295 lines changed or deleted 358 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/