draft-ietf-mobike-design-08.txt   rfc4621.txt 
IKEv2 Mobility and Multihoming T. Kivinen Network Working Group T. Kivinen
(mobike) Safenet, Inc. Request for Comments: 4621 Safenet, Inc.
Internet-Draft H. Tschofenig Category: Informational H. Tschofenig
Expires: September 4, 2006 Siemens Siemens
March 3, 2006 August 2006
Design of the MOBIKE Protocol
draft-ietf-mobike-design-08.txt
Status of this Memo
By submitting this Internet-Draft, each 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2006. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension
Internet Key Exchange Protocol version 2 (IKEv2). These extensions of the Internet Key Exchange Protocol version 2 (IKEv2). These
should enable an efficient management of IKE and IPsec Security extensions should enable an efficient management of IKE and IPsec
Associations when a host possesses multiple IP addresses and/or where Security Associations when a host possesses multiple IP addresses
IP addresses of an IPsec host change over time (for example, due to and/or where IP addresses of an IPsec host change over time (for
mobility). example, due to mobility).
This document discusses the involved network entities, and the This document discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by relationship between IKEv2 signaling and information provided by
other protocols. Design decisions for the MOBIKE protocol, other protocols. Design decisions for the MOBIKE protocol,
background information and discussions within the working group are background information, and discussions within the working group are
recorded. recorded.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Scenarios .......................................................6
3.1. Mobility Scenario . . . . . . . . . . . . . . . . . . . . 8 3.1. Mobility Scenario ..........................................6
3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9 3.2. Multihoming Scenario .......................................7
3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 3.3. Multihomed Laptop Scenario .................................8
4. Scope of MOBIKE . . . . . . . . . . . . . . . . . . . . . . . 11 4. Scope of MOBIKE .................................................8
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 5. Design Considerations ..........................................10
5.1. Choosing Addresses . . . . . . . . . . . . . . . . . . . . 14 5.1. Choosing Addresses ........................................10
5.1.1. Inputs and Triggers . . . . . . . . . . . . . . . . . 14 5.1.1. Inputs and Triggers ................................11
5.1.2. Connectivity . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Connectivity .......................................11
5.1.3. Discovering Connectivity . . . . . . . . . . . . . . . 15 5.1.3. Discovering Connectivity ...........................12
5.1.4. Decision Making . . . . . . . . . . . . . . . . . . . 15 5.1.4. Decision Making ....................................12
5.1.5. Suggested Approach . . . . . . . . . . . . . . . . . . 15 5.1.5. Suggested Approach .................................12
5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 5.2. NAT Traversal (NAT-T) .....................................12
5.2.1. Background and Constraints . . . . . . . . . . . . . . 16 5.2.1. Background and Constraints .........................12
5.2.2. Fundamental Restrictions . . . . . . . . . . . . . . . 16 5.2.2. Fundamental Restrictions ...........................13
5.2.3. Moving to behind a NAT and back . . . . . . . . . . . 16 5.2.3. Moving behind a NAT and Back .......................13
5.2.4. Responder behind a NAT . . . . . . . . . . . . . . . . 17 5.2.4. Responder behind a NAT .............................14
5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 18 5.2.5. NAT Prevention .....................................15
5.2.6. Suggested Approach . . . . . . . . . . . . . . . . . . 18 5.2.6. Suggested Approach .................................15
5.3. Scope of SA Changes . . . . . . . . . . . . . . . . . . . 18 5.3. Scope of SA Changes .......................................15
5.4. Zero Address Set Functionality . . . . . . . . . . . . . . 19 5.4. Zero Address Set Functionality ............................16
5.5. Return Routability Check . . . . . . . . . . . . . . . . . 20 5.5. Return Routability Check ..................................17
5.5.1. Employing MOBIKE Results in other Protocols . . . . . 22 5.5.1. Employing MOBIKE Results in Other Protocols ........19
5.5.2. Return Routability Failures . . . . . . . . . . . . . 23 5.5.2. Return Routability Failures ........................20
5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 24 5.5.3. Suggested Approach .................................21
5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 5.6. IPsec Tunnel or Transport Mode ............................22
6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 26 6. Protocol Details ...............................................22
6.1. Indicating Support for MOBIKE . . . . . . . . . . . . . . 26 6.1. Indicating Support for MOBIKE .............................22
6.2. Path Testing and Window size . . . . . . . . . . . . . . . 27 6.2. Path Testing and Window size ..............................23
6.3. Message presentation . . . . . . . . . . . . . . . . . . . 28 6.3. Message Presentation ......................................24
6.4. Updating address set . . . . . . . . . . . . . . . . . . . 29 6.4. Updating Address Set ......................................25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations ........................................26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements ...............................................26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. References .....................................................27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Normative references ......................................27
10.1. Normative references . . . . . . . . . . . . . . . . . . . 33 9.2. Informative References ....................................27
10.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
The purpose of IKEv2 is to mutually authenticate two hosts, establish The purpose of IKEv2 is to mutually authenticate two hosts, to
one or more IPsec Security Associations (SAs) between them, and establish one or more IPsec Security Associations (SAs) between them,
subsequently manage these SAs (for example, by rekeying or deleting). and subsequently to manage these SAs (for example, by rekeying or
IKEv2 enables the hosts to share information that is relevant to both deleting). IKEv2 enables the hosts to share information that is
the usage of the cryptographic algorithms that should be employed relevant to both the usage of the cryptographic algorithms that
(e.g., parameters required by cryptographic algorithms and session should be employed (e.g., parameters required by cryptographic
keys) and to the usage of local security policies, such as algorithms and session keys) and to the usage of local security
information about the traffic that should experience protection. policies, such as information about the traffic that should
experience protection.
IKEv2 assumes that an IKE SA is created implicitly between the IP IKEv2 assumes that an IKE SA is created implicitly between the IP
address pair that is used during the protocol execution when address pair that is used during the protocol execution when
establishing the IKEv2 SA. This means that, in each host, only one establishing the IKEv2 SA. This means that, in each host, only one
IP address pair is stored for the IKEv2 SA as part of a single IKEv2 IP address pair is stored for the IKEv2 SA as part of a single IKEv2
protocol session, and, for tunnel mode SAs, the hosts places this protocol session, and, for tunnel mode SAs, the host places this
single pair in the outer IP headers. Existing IPsec documents make single pair in the outer IP headers. Existing IPsec documents make
no provision to change this pair after an IKE SA is created (except no provision to change this pair after an IKE SA is created (except
for dynamic address update of NAT-T). for dynamic address update of Network Address Translation Traversal
(NAT-T)).
There are scenarios where one or both of the IP addresses of this There are scenarios where one or both of the IP addresses of this
pair may change during an IPsec session. In principle, the IKE SA pair may change during an IPsec session. In principle, the IKE SA
and all corresponding IPsec SAs could be re-established after the IP and all corresponding IPsec SAs could be re-established after the IP
address has changed. However, this is a relatively expensive address has changed. However, this is a relatively expensive
operation, and can be problematic when such changes are frequent. operation, and it can be problematic when such changes are frequent.
Moreover, manual user interaction (for example when using human- Moreover, manual user interaction (for example, when using human-
operated token cards (SecurID)) might be required as part of the operated token cards (SecurID)) might be required as part of the
IKEv2 authentication procedure. Therefore, an automatic mechanism is IKEv2 authentication procedure. Therefore, an automatic mechanism is
needed that updates the IP addresses associated with the IKE SA and needed that updates the IP addresses associated with the IKE SA and
the IPsec SAs. The MOBIKE protocol provides such a mechanism. the IPsec SAs. The MOBIKE protocol provides such a mechanism.
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As
IKEv2 is built on the architecture described in RFC2401bis [RFC4301], IKEv2 is built on the IPsec architecture [RFC4301], all protocols
all protocols developed within the MOBIKE working group must be developed within the MOBIKE working group must be compatible with
compatible with both IKEv2 and the architecture described in RFC4301. both IKEv2 and the architecture described in RFC 4301. This document
This document does not discusses mobility and multi-homing support does not discuss mobility and multi-homing support for IKEv1
for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401 [RFC2409] or the obsoleted IPsec architecture described in RFC 2401
[RFC2401]. [RFC2401].
This document is structured as follows: After introducing some This document is structured as follows: After some important terms
important terms in Section 2, a number of relevant usage scenarios are introduced in Section 2, a number of relevant usage scenarios are
are discussed in Section 3. Section 4 describes the scope of the discussed in Section 3. Section 4 describes the scope of the MOBIKE
MOBIKE protocol. Section 5 discusses design considerations affecting protocol. Section 5 discusses design considerations affecting the
the MOBIKE protocol. Section 6 investigates details regarding the MOBIKE protocol. Section 6 investigates details regarding the MOBIKE
MOBIKE protocol. Finally, this document concludes in Section 7 with protocol. Finally, this document concludes in Section 7 with
security considerations. security considerations.
2. Terminology 2. Terminology
This section introduces the terminology that is used in this This section introduces the terminology that is used in this
document. document.
Peer Peer
A peer is an IKEv2 endpoint. In addition, a peer implements the A peer is an IKEv2 endpoint. In addition, a peer implements the
MOBIKE extensions, defined in [I-D.ietf-mobike-protocol]. MOBIKE extensions, defined in [RFC4555].
Available address Available address
An address is said to be available if the following conditions are An address is said to be available if the following conditions are
met: met:
* The address has been assigned to an interface. * The address has been assigned to an interface.
* If the address is an IPv6 address, we additionally require (a) * If the address is an IPv6 address, we additionally require (a)
that the address is valid as defined in RFC 2461 [RFC2461], and that the address is valid as defined in RFC 2461 [RFC2461], and
(b) that the address is not tentative as defined in RFC 2462 (b) that the address is not tentative as defined in RFC 2462
[RFC2462]. In other words, we require the address assignment [RFC2462]. In other words, we require the address assignment
to be complete. to be complete.
Note that this explicitly allows an address to be optimistic as Note that this explicitly allows an address to be optimistic as
defined in [I-D.ietf-ipv6-optimistic-dad]. defined in [RFC4429].
* If the address is an IPv6 address, it is a global unicast or * If the address is an IPv6 address, it is a global unicast or
unique site-local address, as defined in [I-D.ietf-ipv6-unique- unique site-local address, as defined in [RFC4193]. That is,
local-addr]. That is, it is not an IPv6 link-local address. it is not an IPv6 link-local address.
* The address and interface is acceptable for sending and * The address and interface is acceptable for sending and
receiving traffic according to a local policy. receiving traffic according to a local policy.
This definition is taken from [I-D.ietf-shim6-failure-detection] This definition is taken from [WIP-Ark06] and adapted for the
and adapted for the MOBIKE context. MOBIKE context.
Locally operational address Locally operational address
An address is said to be locally operational if it is available An address is said to be locally operational if it is available
and its use is locally known to be possible and permitted. This and its use is locally known to be possible and permitted. This
definition is taken from [I-D.ietf-shim6-failure-detection]. definition is taken from [WIP-Ark06].
Operational address pair Operational address pair
A pair of operational addresses are said to be an operational A pair of operational addresses are said to be an operational
address pair, if and only if bidirectional connectivity can be address pair if and only if bidirectional connectivity can be
shown between the two addresses. Note that sometimes it is shown between the two addresses. Note that sometimes it is
necessary to consider connectivity on a per-flow level between two necessary to consider connectivity on a per-flow level between two
endpoints. This differentiation might be necessary to address endpoints. This differentiation might be necessary to address
certain Network Address Translation types or specific firewalls. certain Network Address Translation types or specific firewalls.
This definition is taken from [I-D.ietf-shim6-failure-detection] This definition is taken from [WIP-Ark06] and adapted for the
and adapted for the MOBIKE context. Although it is possible to MOBIKE context. Although it is possible to further differentiate
further differentiate unidirectional and bidirectional operational unidirectional and bidirectional operational address pairs, only
address pairs, only bidirectional connectivity is relevant to this bidirectional connectivity is relevant to this document, and
document and unidirectional connectivity is out of scope. unidirectional connectivity is out of scope.
Path Path
The sequence of routers traversed by the MOBIKE and IPsec packets The sequence of routers traversed by the MOBIKE and IPsec packets
exchanged between the two peers. Note that this path may be exchanged between the two peers. Note that this path may be
affected not only by the involved source and destination IP affected not only by the involved source and destination IP
addresses, but also by the transport protocol. Since MOBIKE and addresses, but also by the transport protocol. Since MOBIKE and
IPsec packets have a different appearance on the wire, they might IPsec packets have a different appearance on the wire, they might
be routed along a different path, for example due to load be routed along a different path, for example, due to load
balancing. This definition is taken from [RFC2960] and adapted to balancing. This definition is taken from [RFC2960] and adapted to
the MOBIKE context. the MOBIKE context.
Current path Current path
The sequence of routers traversed by an IP packet that carries the The sequence of routers traversed by an IP packet that carries the
default source and destination addresses is said to be the Current default source and destination addresses is said to be the Current
Path. This definition is taken from [RFC2960] and adapted to the Path. This definition is taken from [RFC2960] and adapted to the
MOBIKE context. MOBIKE context.
Preferred address Preferred address
The IP address of a peer to which MOBIKE and IPsec traffic should The IP address of a peer to which MOBIKE and IPsec traffic should
be sent by default. A given peer has only one active preferred be sent by default. A given peer has only one active preferred
address at a given point in time, except for the small time period address at a given point in time, except for the small time period
where it switches from an old to a new preferred address. This where it switches from an old to a new preferred address. This
definition is taken from [I-D.ietf-hip-mm] and adapted to the definition is taken from [WIP-Nik06] and adapted to the MOBIKE
MOBIKE context. context.
Peer address set Peer address set
We denote the two peers of a MOBIKE session by peer A and peer B. We denote the two peers of a MOBIKE session by peer A and peer B.
A peer address set is the subset of locally operational addresses A peer address set is the subset of locally operational addresses
of peer A that is sent to peer B. A policy available at peer A of peer A that is sent to peer B. A policy available at peer A
indicates which addresses are included in the peer address set. indicates which addresses are included in the peer address set.
Such a policy might be created either manually or automatically Such a policy might be created either manually or automatically
through interaction with other mechanisms that indicate new through interaction with other mechanisms that indicate new
available addresses. available addresses.
Bidirectional address pair Bidirectional address pair
The address pair, where traffic can be sent to both directions, The address pair, where traffic can be sent to both directions,
simply by reversing the IP addresses. Note, that the path of the simply by reversing the IP addresses. Note that the path of the
packets going to each direction might be different. packets going to each direction might be different.
Unidirectional address pair Unidirectional address pair
The address pair, where traffic can only be sent in one direction, The address pair, where traffic can only be sent in one direction,
and reversing the IP addresses and sending reply back does not and reversing the IP addresses and sending reply back does not
work. work.
For mobility related terminology (e.g., Make-before-break or Break- For mobility-related terminology (e.g., Make-before-break or Break-
before-make) see [RFC3753]. before-make), see [RFC3753].
3. Scenarios 3. Scenarios
In this section we discuss three typical usage scenarios for the In this section, we discuss three typical usage scenarios for the
MOBIKE protocol. MOBIKE protocol.
3.1. Mobility Scenario 3.1. Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile Figure 1 shows a break-before-make mobility scenario where a mobile
node changes its point of network attachment. Prior to the change, node (MN) changes its point of network attachment. Prior to the
the mobile node had established an IPsec connection with a security change, the mobile node had established an IPsec connection with a
gateway which offered, for example, access to a corporate network. security gateway that offered, for example, access to a corporate
The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took network. The IKEv2 exchange that facilitated the setup of the IPsec
place over the path labeled as 'old path'. The involved packets SA(s) took place over the path labeled as 'old path'. The involved
carried the MN's "old" IP address and were forwarded by the "old" packets carried the MN's "old" IP address and were forwarded by the
access router (OAR) to the security gateway (GW). "old" access router (OAR) to the security gateway (GW).
When the MN changes its point of network attachment, it obtains a new When the MN changes its point of network attachment, it obtains a new
IP address using stateful or stateless address configuration. The IP address using stateful or stateless address configuration. The
goal of MOBIKE, in this scenario, is to enable the MN and the GW to goal of MOBIKE, in this scenario, is to enable the MN and the GW to
continue using the existing SAs and to avoid setting up a new IKE SA. continue using the existing SAs and to avoid setting up a new IKE SA.
A protocol exchange, denoted by 'MOBIKE Address Update', enables the A protocol exchange, denoted by 'MOBIKE Address Update', enables the
peers to update their state as necessary. peers to update their state as necessary.
Note that in a break-before-make scenario the MN obtains the new IP Note that in a break-before-make scenario the MN obtains the new IP
address after it can no longer be reached at the old IP address. In address after it can no longer be reached at the old IP address. In
skipping to change at page 9, line 4 skipping to change at page 7, line 23
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)
...> = End host movement ...> = End host movement
Figure 1: Mobility Scenario Figure 1: Mobility Scenario
3.2. Multihoming Scenario 3.2. Multihoming Scenario
Another MOBIKE usage scenario is depicted in Figure 2. In this Another MOBIKE usage scenario is depicted in Figure 2. In this
scenario, the MOBIKE peers are equipped with multiple interfaces (and scenario, the MOBIKE peers are equipped with multiple interfaces (and
multiple IP addresses). Peer A has two interface cards with two IP multiple IP addresses). Peer A has two interface cards with two IP
addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
and IP_B2. Each peer selects one of its IP addresses as the and IP_B2. Each peer selects one of its IP addresses as the
preferred address which is used for subsequent communication. preferred address, which is used for subsequent communication.
Various reasons (e.g., hardware or network link failures), may Various reasons (e.g., hardware or network link failures) may require
require a peer to switch from one interface to another. a peer to switch from one interface to another.
+------------+ +------------+ +------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B | | Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| | | |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 | | IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | | | | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 | | IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
skipping to change at page 9, line 33 skipping to change at page 8, line 4
| | * * | | | | * * | |
+------------+ *~~~~~~~~~* +------------+ +------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets ---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE) >>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network ***> = Potential future path through the network
(if Peer A and Peer B change their preferred (if Peer A and Peer B change their preferred
address) address)
Figure 2: Multihoming Scenario Figure 2: Multihoming Scenario
Note that MOBIKE does not aim to support load balancing between Note that MOBIKE does not aim to support load balancing between
multiple IP addresses. That is, each peer uses only one of the multiple IP addresses. That is, each peer uses only one of the
available address pairs at a given point in time. available address pairs at a given point in time.
3.3. Multihomed Laptop Scenario 3.3. Multihomed Laptop Scenario
The third scenario we consider is about a laptop, which has multiple The third scenario we consider is about a laptop that has multiple
interface cards and therefore several ways to connect to the network. interface cards and therefore several ways to connect to the network.
It may, for example, have a fixed Ethernet card, a WLAN interface, a It may, for example, have a fixed Ethernet card, a WLAN interface, a
GPRS adaptor, a Bluetooth interface or USB hardware. Not all General Packet Radio Service (GPRS) adaptor, a Bluetooth interface,
interfaces are used for communication all the time for a number of or USB hardware. Not all interfaces are used for communication all
reasons (e.g., cost, network availability, user convenience). The the time for a number of reasons (e.g., cost, network availability,
policies that determine which interfaces are connected to the network user convenience). The policies that determine which interfaces are
at any given point in time is outside the scope of the MOBIKE connected to the network at any given point in time is outside the
protocol and, as such, this document. However, as the laptop changes scope of the MOBIKE protocol and, as such, this document. However,
its point of attachment to the network, the set of IP addresses under as the laptop changes its point of attachment to the network, the set
which the laptop is reachable, changes too. of IP addresses under which the laptop is reachable changes too.
In all of these scenarios, even if IP addresses change due to In all of these scenarios, even if IP addresses change due to
interface switching or mobility, the IP address obtained via the interface switching or mobility, the IP address obtained via the
configuration payloads within IKEv2 remain unaffected. The IP configuration payloads within IKEv2 remain unaffected. The IP
address obtained via the IKEv2 configuration payloads allow the address obtained via the IKEv2 configuration payloads allow the
configuration of the inner IP address of the IPsec tunnel. As such, configuration of the inner IP address of the IPsec tunnel. As such,
applications might not detect any change at all. applications might not detect any change at all.
4. Scope of MOBIKE 4. Scope of MOBIKE
Getting mobility and multihoming actually working requires many Getting mobility and multihoming actually working requires many
different components to work together, including coordinating different components to work together, including coordinating
decisions between different layers, different mobility mechanisms, decisions between different layers, different mobility mechanisms,
and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE: and IPsec/IKEv2. Most of those aspects are beyond the scope of
MOBIKE focuses only on what two peers need to agree at the IKEv2 MOBIKE: MOBIKE focuses only on what two peers need in order to agree
level (like new message formats and some aspects of their processing) at the IKEv2 level (like new message formats and some aspects of
required for interoperability. their processing) required for interoperability.
The MOBIKE protocol is not trying to be a full mobility protocol; The MOBIKE protocol is not trying to be a full mobility protocol;
there is no support for simultaneous movement or rendezvous there is no support for simultaneous movement or rendezvous
mechanism, and there is no support for route optimization etc. The mechanism, and there is no support for route optimization, etc. The
design document focuses on tunnel mode, everything going inside the design document focuses on tunnel mode; everything going inside the
tunnel is unaffected by the changes in the tunnel header IP address, tunnel is unaffected by the changes in the tunnel header IP address,
and this is the mobility feature provided by the MOBIKE, i.e., and this is the mobility feature provided by the MOBIKE. That is,
applications running inside the MOBIKE controlled IPsec tunnel might applications running inside the MOBIKE-controlled IPsec tunnel might
not detect the movement since their IP addresses remain constant. not detect the movement since their IP addresses remain constant.
The MOBIKE protocol should be able to perform the following The MOBIKE protocol should be able to perform the following
operations (not all of those are done explictly by the current operations (not all of which are done explicitly by the current
protocol): protocol):
o Inform the other peer about the peer address set o Inform the other peer about the peer address set
o Inform the other peer about the preferred address o Inform the other peer about the preferred address
o Test connectivity along a path and there by to detect an outage o Test connectivity along a path and thereby detect an outage
situation situation
o Change the preferred address o Change the preferred address
o Change the peer address set o Change the peer address set
o Ability to deal with Network Address Translation devices o Ability to deal with Network Address Translation devices
Figure 3 shows an example protocol interaction between a pair of Figure 3 shows an example protocol interaction between a pair of
MOBIKE peers. MOBIKE interacts with the packet processing module of MOBIKE peers. MOBIKE interacts with the packet processing module of
the IPsec implementation using an internal API (such as those based the IPsec implementation using an internal API (such as those based
on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create
entries in the Security Association (SAD) and Security Policy entries in the Security Association (SAD) and Security Policy
Databases (SPD). The packet processing module of the IPsec Databases (SPD). The packet processing module of the IPsec
implementation may also interact with IKEv2 and MOBIKE module using implementation may also interact with IKEv2 and MOBIKE module using
this API. The content of the Security Policy and Security this API. The content of the Security Policy and Security
Association Databases determines what traffic is protected with IPsec Association Databases determines what traffic is protected with IPsec
in which fashion. MOBIKE, on the other hand, receives information in which fashion. MOBIKE, on the other hand, receives information
from a number of sources that may run both in kernel-mode and in from a number of sources that may run both in kernel-mode and in
user-mode. These sources form the basis on which MOBIKE make user-mode. These sources form the basis on which MOBIKE makes
decisions regarding the set of available addresses, the peer address decisions regarding the set of available addresses, the peer address
set, and the preferred address. Policies may also affect the set, and the preferred address. Policies may also affect the
selection process. selection process.
The peer address set and the preferred address needs to be made The peer address set and the preferred address needs to be made
available to the other peer. In order to address certain failure available to the other peer. In order to address certain failure
cases, MOBIKE should perform connectivity tests between the peers cases, MOBIKE should perform connectivity tests between the peers
(potentially over a number of different paths). Although a number of (potentially over a number of different paths). Although a number of
address pairs may be available for such tests, the most important is address pairs may be available for such tests, the most important is
the pair (source address, destination address) of the current path. the pair (source address, destination address) of the current path.
This is because this pair is selected for sending and receiving This is because this pair is selected for sending and receiving
MOBIKE signaling and IPsec traffic. If a problem along this current MOBIKE signaling and IPsec traffic. If a problem along this current
path is detected (e.g., due to a router failure) it is necessary to path is detected (e.g., due to a router failure), it is necessary to
switch to a new current path. In order to be able to do so quickly, switch to a new current path. In order to be able to do so quickly,
it may be helpful to perform connectivity tests of other paths it may be helpful to perform connectivity tests of other paths
periodically. Such a technique would also help in identifying periodically. Such a technique would also help identify previously
previously disconnected paths that become operational again. disconnected paths that become operational again.
+---------------------+ +----------------+ +---------------------+ +----------------+
| User-space | | | | User-space | | |
| Protocols and | | MOBIKE and | | Protocols and | | MOBIKE and |
| Functions Relevant |<---------->| IKEv2 Module | | Functions Relevant |<---------->| IKEv2 Module |
| MOBIKE (e.g., DHCP, | | | | MOBIKE (e.g., DHCP, | | |
| policies) | +----------------+ | policies) | +----------------+
+---------------------+ ^ +---------------------+ ^
^ | ^ |
| | User space | | User space
skipping to change at page 13, line 39 skipping to change at page 10, line 39
faces <=====================|input and output| faces <=====================|input and output|
| | | |
+----------------+ +----------------+
===> = IP packets arriving/leaving a MOBIKE node ===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations <-> = control and configuration operations
Figure 3: Framework Figure 3: Framework
Please note that Figure 3 illustrates an example of how a MOBIKE Please note that Figure 3 illustrates an example of how a MOBIKE
implementation could work. Hence, it serves illustrative purposes implementation could work. It serves illustrative purposes only.
only.
5. Design Considerations 5. Design Considerations
This section discusses aspects affecting the design of the MOBIKE This section discusses aspects affecting the design of the MOBIKE
protocol. protocol.
5.1. Choosing Addresses 5.1. Choosing Addresses
One of the core aspects of the MOBIKE protocol is the selection of One of the core aspects of the MOBIKE protocol is the selection of
the address for the IPsec packets we send. Choosing addresses for the address for the IPsec packets we send. Choosing addresses for
the IKEv2 request is a somewhat separate problem: in many cases, they the IKEv2 request is a somewhat separate problem. In many cases,
will be the same (and in some design choice they will always be the they will be the same (and in some design choice they will always be
same, and could be forced to be the same by design). the same and could be forced to be the same by design).
5.1.1. Inputs and Triggers 5.1.1. Inputs and Triggers
How address changes are triggered is largely beyond the scope of How address changes are triggered is largely beyond the scope of
MOBIKE. The triggers can include, changes in the set of addresses, MOBIKE. The triggers can include changes in the set of addresses,
various link-layer indications, failing dead peer detection, and various link-layer indications, failing dead peer detection, and
changes in preferences and policies. Furthermore, there may be less changes in preferences and policies. Furthermore, there may be less
reliable sources of information (such as lack of IPsec packets and reliable sources of information (such as lack of IPsec packets and
incoming ICMP packets) that do not trigger any changes directly, but incoming ICMP packets) that do not trigger any changes directly, but
rather cause Dead Peer Detection (DPD) to be scheduled earlier and if rather cause Dead Peer Detection (DPD) to be scheduled earlier and,
it fails it might cause a change of the preferred address. if it fails, it might cause a change of the preferred address.
These triggers are largely the same as for, e.g., Mobile IP, and are These triggers are largely the same as for other mobility protocols
beyond the scope of MOBIKE. such as Mobile IP, and they are beyond the scope of MOBIKE.
5.1.2. Connectivity 5.1.2. Connectivity
There can be two kinds of connectivity "failures": local failures and There can be two kinds of connectivity "failures": local failures and
path failures. Local failures are problems locally at an MOBIKE peer path failures. Local failures are problems locally at a MOBIKE peer
(e.g., an interface error). Path failures are a property of an (e.g., an interface error). Path failures are a property of an
address pair and failures of nodes and links along this path. MOBIKE address pair and failures of nodes and links along this path. MOBIKE
does not support unidirectional address pairs. Supporting them would does not support unidirectional address pairs. Supporting them would
require abandoning the principle of sending an IKEv2 reply to the require abandoning the principle of sending an IKEv2 reply to the
address the request came from. MOBIKE decided to deal only with address from which the request came. MOBIKE decided to deal only
bidirectional address pairs. It does consider unidirectional address with bidirectional address pairs. It does consider unidirectional
pairs as broken, and does not use them, but the connection between address pairs as broken and does not use them, but the connection
peers will not break even if unidirectional address pairs are between peers will not break even if unidirectional address pairs are
present, provided there is at least one bidirectional address pair present, provided there is at least one bidirectional address pair
MOBIKE can use. MOBIKE can use.
Note that MOBIKE is not concerned about the actual path used, it Note that MOBIKE is not concerned about the actual path used; it
cannot even detect if some path is unidirectionally operational if cannot even detect if some path is unidirectionally operational if
the same address pair has some other unidirectional path back. the same address pair has some other unidirectional path back.
Ingress filters might still cause such path pairs to be unusable, and Ingress filters might still cause such path pairs to be unusable, and
in that case MOBIKE will detect that there is no operational address in that case MOBIKE will detect that there is no operational address
pair. pair.
In a sense having both an IPv4 and an IPv6 address is basically a In a sense having both an IPv4 and an IPv6 address is basically a
case of partial connectivity (putting both an IPv4 and an IPv6 case of partial connectivity (putting both an IPv4 and an IPv6
address in the same IP header does not work). The main difference is address in the same IP header does not work). The main difference is
that it is known beforehand, and there is no need to discover that that it is known beforehand; there is no need to discover that an
IPv4/IPv6 combination does not work. IPv4/IPv6 combination does not work.
5.1.3. Discovering Connectivity 5.1.3. Discovering Connectivity
To detect connectivity, the MOBIKE protocol needs to have a mechanism To detect connectivity, the MOBIKE protocol needs to have a mechanism
to test connectivity. If a MOBIKE peer receives a reply it can be to test connectivity. If a MOBIKE peer receives a reply, it can be
sure about the existence of a working (bidirectional) address pair. sure about the existence of a working (bidirectional) address pair.
If a MOBIKE peer does not see a reply after multiple retransmissions If a MOBIKE peer does not see a reply after multiple retransmissions,
it may assume that the tested address pair is broken. it may assume that the tested address pair is broken.
The connectivity tests require congestion problems to be taken into The connectivity tests require congestion problems to be taken into
account because the connection failure might be caused by a account because the connection failure might be caused by congestion.
congestion, and the MOBIKE protocol should not make the congestion The MOBIKE protocol should not make the congestion problem worse by
problem worse by sending many of DPD packets. sending many DPD packets.
5.1.4. Decision Making 5.1.4. Decision Making
One of the main questions in designing the MOBIKE protocol was who One of the main questions in designing the MOBIKE protocol was who
makes the decisions how to fix situation when failure is detected, makes the decisions how to fix a situation when failure is detected,
e.g., symmetry vs. asymmetry in decision making. Symmetric decision e.g., symmetry vs. asymmetry in decision making. Symmetric decision
making (i.e. both peers can make decisions) may cause the different making (i.e., both peers can make decisions) may cause the different
peers to make different decisions, thus causing asymmetric upstream/ peers to make different decisions, thus causing asymmetric upstream/
downstream traffic. In mobility case it is desirable that the mobile downstream traffic. In the mobility case, it is desirable that the
peer can move both upstream and downstream traffic to some particular mobile peer can move both upstream and downstream traffic to some
interface, and this requires asymmetric decision making (i.e. only particular interface, and this requires asymmetric decision making
one peer makes decisions). (i.e. only one peer makes decisions).
Working with stateful packet filters and NATs is easier if the same Working with stateful packet filters and NATs is easier if the same
address pair is used in both upstream and downstream directions. address pair is used in both upstream and downstream directions.
Also in common cases only the peer behind NAT can actually perform Also, in common cases, only the peer behind NAT can actually perform
actions to recover from the connectivity problems, as it might be actions to recover from the connectivity problems, as the other peer
that the other peer is not able to initiate any connections to the might not be able to initiate any connections to the peer behind NAT.
peer behind NAT.
5.1.5. Suggested Approach 5.1.5. Suggested Approach
The working group decided to select a method where the initiator will The working group decided to select a method whereby the initiator
decide which addresses are used. As a consequence the outcome is will decide which addresses are used. As a consequence, the outcome
always the same for both parties. It also works best with NATs, as is always the same for both parties. It also works best with NATs,
the initiator is most likely the node that is located behind a NAT. as the initiator is most likely the node that is located behind a
NAT.
5.2. NAT Traversal 5.2. NAT Traversal (NAT-T)
5.2.1. Background and Constraints 5.2.1. Background and Constraints
Another core aspect of MOBIKE is the treatment of different NATs and Another core aspect of MOBIKE is the treatment of different NATs and
NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside Network Address Port Translations (NAPTs). In IKEv2 the tunnel
the IKEv2 payloads, and thus there is no need to do unilateral self- header IP addresses are not sent inside the IKEv2 payloads, and thus
address fixing (UNSAF [RFC3424]). The tunnel header IP addresses are there is no need to do unilateral self-address fixing (UNSAF
taken from the outer IP header of the IKE packets, thus they are [RFC3424]). The tunnel header IP addresses are taken from the outer
already processed by the NAT. IP header of the IKE packets; thus, they are already processed by the
NAT.
The NAT detection payloads are used to determine whether the The NAT detection payloads are used to determine whether the
addresses in the IP header were modified by a NAT along the path. addresses in the IP header were modified by a NAT along the path.
Detecting a NAT typically requires UDP encapsulation of IPsec ESP Detecting a NAT typically requires UDP encapsulation of IPsec ESP
packets to be enabled, if desired. MOBIKE is not to change how IKEv2 packets to be enabled, if desired. MOBIKE is not to change how IKEv2
NAT-T works, in particular, any kind of UNSAF or explicit interaction NAT-T works in particular, any kind of UNSAF or explicit interaction
with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [I-D.ietf-nsis- with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [WIP-Sti06]) is
nslp-natfw]) are beyond the scope of MOBIKE protocol. The MOBIKE beyond the scope of the MOBIKE protocol. The MOBIKE protocol will
protocol will need to define how MOBIKE and NAT-T are used together. need to define how MOBIKE and NAT-T are used together.
The NAT-T support should also be optional, i.e., if the IKEv2 The NAT-T support should also be optional. If the IKEv2
implementation does not implement NAT-T, as it is not required in implementation does not implement NAT-T, as it is not required in
some particular environment, implementing MOBIKE should not require some particular environment, implementing MOBIKE should not require
adding support for NAT-T either. adding support for NAT-T either.
The property of being behind NAT is actually a property of the The property of being behind NAT is actually a property of the
address pair and thereby by the path taken by a packet, thus one peer address pair and thereby of the path taken by a packet. Thus, one
can have multiple IP addresses and some of those might be behind NAT peer can have multiple IP addresses, and some of those might be
and some might not. behind NAT and some might not.
5.2.2. Fundamental Restrictions 5.2.2. Fundamental Restrictions
There are some cases which cannot be carried out within MOBIKE. One There are some cases that cannot be carried out within MOBIKE. One
of those cases is the case where the party "outside" a symmetric NAT of those cases is when the party "outside" a symmetric NAT changes
changes its address to something not known by the the other peer (and its address to something not known by the other peer (and the old
old address has stopped working). It cannot send a packet containing address has stopped working). It cannot send a packet containing the
the new addresses to the peer because the NAT does not contain the new addresses to the peer because the NAT does not contain the
necessary state. Furthermore, since the party behind the NAT does necessary state. Furthermore, since the party behind the NAT does
not know the new IP address, it cannot cause the NAT state to be not know the new IP address, it cannot cause the NAT state to be
created. created.
This case could be solved using some rendezvous mechanism outside This case could be solved using some rendezvous mechanism outside
IKEv2, but that is beyond the scope of MOBIKE. IKEv2, but that is beyond the scope of MOBIKE.
5.2.3. Moving to behind a NAT and back 5.2.3. Moving behind a NAT and Back
The MOBIKE protocol should provide a mechanism where a peer that is The MOBIKE protocol should provide a mechanism whereby a peer that is
initially not behind a NAT can move behind NAT, when a new preferred initially not behind a NAT can move behind NAT when a new preferred
address is selected. The same effect might be accomplished with the address is selected. The same effect might be accomplished with the
change of the address pair if more than one path is available (e.g., change of the address pair if more than one path is available (e.g.,
in case of a multi-homed host). An impact for the MOBIKE protocol is in the case of a multi-homed host). An impact for the MOBIKE
only caused when the currently selected address pair causes MOBIKE protocol is only caused when the currently selected address pair
packets to traverse a NAT. causes MOBIKE packets to traverse a NAT.
Similarly the MOBIKE protocol provides a mechanism to detect when a Similarly, the MOBIKE protocol provides a mechanism to detect when a
NATed path is changed to a non-NATed path with the change of the NATed path is changed to a non-NATed path with the change of the
addressed pair. address pair.
As we only use one address pair at time, effectively the MOBIKE peer As we only use one address pair at time, effectively the MOBIKE peer
is either behind NAT or not behind NAT, but each address change can is either behind NAT or not behind NAT, but each address change can
change this situation. Because of this and because the initiator change this situation. Because of this, and because the initiator
always chooses the addresses it is enough to send keepalive packets always chooses the addresses, it is enough to send keepalive packets
only to that one address pair. only to that one address pair.
Enabling NAT-T involves a few different things, one is to enable the Enabling NAT-T involves a few different things. One is to enable the
UDP encapsulation of ESP packets. Another is to change the IKE SA UDP encapsulation of ESP packets. Another is to change the IKE SA
ports from port 500 to port 4500. We do not want to do unnecessary ports from port 500 to port 4500. We do not want to do unnecessary
UDP encapsulation unless there is really a NAT between peers, i.e. UDP encapsulation unless there is really a NAT between peers, i.e.,
UDP encapsulation should only be enabled when we actually detect NAT. UDP encapsulation should only be enabled when we actually detect NAT.
On the other hand, as all implementations supporting NAT-T must be On the other hand, as all implementations supporting NAT-T must be
able to respond to port 4500 all the time, it is simpler from the able to respond to port 4500 all the time, it is simpler from the
protocol point of view to change the port numbers from 500 to 4500 protocol point of view to change the port numbers from 500 to 4500
immediately upon detecting that the other end supports NAT-T. This immediately upon detecting that the other end supports NAT-T. This
way it is not necessary to change ports after we later detected NAT, way it is not necessary to change ports after we later detected NAT,
which would have caused complications to the protocol. which would have caused complications to the protocol.
If we would do the actual changing of the port only after we detect If we changed the port only after we detected NAT, then the responder
NAT, then the responder would not be able to use the IKE and IPsec would not be able to use the IKE and IPsec SAs immediately after
SAs immediately after their address is changed to be behind NAT. their address is changed to be behind NAT. Instead, it would need to
Instead it would need to wait for the next packet from the initiator wait for the next packet from the initiator to see what IP and port
to see what IP and port numbers are used after the initiator changed numbers are used after the initiator changed its port from 500 to
its port from 500 to 4500. The responder would also not be able to 4500. The responder would also not be able to send anything to the
send anything to the initiator before the initiator has sent initiator before the initiator sent something to the responder. If
something to the responder. If we do the port number changing we do the port number changing immediately after the IKE_SA_INIT and
immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we before IKE_AUTH phase, then we get the rid of this problem.
get the rid of this problem.
5.2.4. Responder behind a NAT 5.2.4. Responder behind a NAT
MOBIKE can work in cases where the responder is behind static NAT, MOBIKE can work in cases where the responder is behind a static NAT,
but in that case the initiator needs to know all the possible but the initiator would need to know all the possible addresses to
addresses where the responder can move to, i.e. the responder cannot which the responder can move. That is, the responder cannot move to
move to an address which is not known by the initiator, in case an address which is not known by the initiator, in case initiator
initiator also moves behind NAT. also moves behind NAT.
If the responder is behind NAPT then it might need to communicate If the responder is behind a NAPT, then it might need to communicate
with the NAT to create a mapping so the initiator can connect to it. with the NAT to create a mapping so the initiator can connect to it.
Those external firewall pinhole opening mechanisms are beyond the Those external firewall pinhole opening mechanisms are beyond the
scope of MOBIKE. scope of MOBIKE.
In case the responder is behind NAPT, then also finding the port In case the responder is behind NAPT, then finding the port numbers
numbers used by the responder is outside the scope of MOBIKE. used by the responder is outside the scope of MOBIKE.
5.2.5. NAT Prevention 5.2.5. NAT Prevention
One new feature created by MOBIKE is NAT prevention, i.e. if we One new feature created by MOBIKE is NAT prevention. If we detect
detect NAT between the peers, we do not allow that address pair to be NAT between the peers, we do not allow that address pair to be used.
used. This can be used to protect IP addresses in cases where it is This can be used to protect IP addresses in cases where the
known by the configuration that there is no NAT between the nodes configuration knows that there is no NAT between the nodes (for
(for example IPv6, or fixed site-to-site VPN). This avoids any example IPv6, or fixed site-to-site VPN). This avoids any
possibility of on-path attackers modifying addresses in headers. possibility of on-path attackers modifying addresses in headers.
This feature means that we authenticate the IP-address and detect if This feature means that we authenticate the IP address and detect if
they were changed. As this is done on purpose to break the they were changed. As this is done on purpose to break the
connectivity if NAT is detected, and decided by the configuration, connectivity if NAT is detected, and decided by the configuration,
there is no need to do UNSAF processing. there is no need to do UNSAF processing.
5.2.6. Suggested Approach 5.2.6. Suggested Approach
The working group decided that MOBIKE uses NAT-T mechanisms from the The working group decided that MOBIKE uses NAT-T mechanisms from the
IKEv2 protocol as much as possible, but decided to change the dynamic IKEv2 protocol as much as possible, but decided to change the dynamic
address update (see [RFC4306] section 2.23 second last paragraph) for address update (see [RFC4306], Section 2.23, second to last
IKEv2 packets to MUST NOT (it would break path testing using IKEv2 paragraph) for IKEv2 packets to "MUST NOT" (it would break path
packets, see Section 6.2). The working group also decided to only testing using IKEv2 packets; see Section 6.2). The working group
send keepalives to the current address pair. also decided only to send keepalives to the current address pair.
5.3. Scope of SA Changes 5.3. Scope of SA Changes
Most sections of this document discuss design considerations for Most sections of this document discuss design considerations for
updating and maintaining addresses in the database entries that updating and maintaining addresses in the database entries that
relate to an IKE SA. However, changing the preferred address also relate to an IKE SA. However, changing the preferred address also
affects the entries of the IPsec SA database. The outer tunnel affects the entries of the IPsec SA database. The outer tunnel
header addresses (source and destination IP addresses) need to be header addresses (source and destination IP addresses) need to be
modified according to the current path to allow the IPsec protected modified according to the current path to allow the IPsec protected
data traffic to travel along the same path as the MOBIKE packets. If data traffic to travel along the same path as the MOBIKE packets. If
the MOBIKE messages and the IPsec protected data traffic travel along the MOBIKE messages and the IPsec protected data traffic travel along
a different path then NAT handling is severely complicated. a different path, then NAT handling is severely complicated.
The basic question is then how the IPsec SAs are changed to use the The basic question is then how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling new address pair (the same address pair as the MOBIKE signaling
traffic). One option is that when the IKE SA address is changed, traffic). One option is that when the IKE SA address is changed, all
then all IPsec SAs associated with it are automatically moved along IPsec SAs associated with it are automatically moved along with it to
with it to a new address pair. Another option is to have a separate a new address pair. Another option is to have a separate exchange to
exchange to move the IPsec SAs separately. move the IPsec SAs separately.
If IPsec SAs should be updated separately then a more efficient If IPsec SAs should be updated separately, then a more efficient
format than the Notify payload is needed to preserve bandwidth. A format than the Notify payload is needed to preserve bandwidth. A
Notify payload can only store one SPI per payload. A separate Notify payload can only store one Security Parameter Index (SPI) per
payload could have a list of IPsec SA SPIs and the new preferred payload. A separate payload could have a list of IPsec SA SPIs and
address. If there is a large number of IPsec SAs, those payloads can the new preferred address. If there is a large number of IPsec SAs,
be quite large unless list of ranges of SPI values are supported. If those payloads can be quite large unless list of ranges of SPI values
we automatically move all IPsec SAs when the IKE SA moves, then we are supported. If we automatically move all IPsec SAs when the IKE
only need to keep track of which IKE SA was used to create the IPsec SA moves, then we only need to keep track of which IKE SA was used to
SA, and fetch the IP addresses from the IKE SA, i.e. there is no need create the IPsec SA, and fetch the IP addresses from the IKE SA,
to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306] i.e., there is no need to store IP addresses per IPsec SA. Note that
already requires the implementations to keep track which IPsec SAs IKEv2 [RFC4306] already requires the implementations to keep track of
are created using which IKE SA. which IPsec SAs are created using which IKE SA.
If we do allow address set of each IPsec SA to be updated separately, If we do allow the address set of each IPsec SA to be updated
then we can support scenarios where the machine has fast and/or cheap separately, then we can support scenarios where the machine has fast
connections and slow and/or expensive connections, and wants to allow and/or cheap connections and slow and/or expensive connections and
moving some of the SAs to the slower and/or more expensive wants to allow moving some of the SAs to the slower and/or more
connection, and prevent the move, for example, of the news video expensive connection, and prevent the move, for example, of the news
stream from the WLAN to the GPRS link. video stream from the WLAN to the GPRS link.
On the other hand, even if we tie the IKE SA update to the IPsec SA 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, we can create separate IKE SAs for this scenario. For
we create one IKE SA which has both links as endpoints, and it is example, we create one IKE SA that has both links as endpoints, and
used for important traffic, and then we create another IKE SA which it is used for important traffic; then we create another IKE SA which
has only the fast and/or cheap connection, which is then used for has only the fast and/or cheap connection, which is used for that
that kind of bulk traffic. kind of bulk traffic.
The working group decided to move all IPsec SAs implicitly when the The working group decided to move all IPsec SAs implicitly when the
IKE SA address pair changes. If more granular handling of the IPsec IKE SA address pair changes. If more granular handling of the IPsec
SA is required, then multiple IKE SAs can be created one for each set SA is required, then multiple IKE SAs can be created one for each set
of IPsec SAs needed. of IPsec SAs needed.
5.4. Zero Address Set Functionality 5.4. Zero Address Set Functionality
One of the features which is potentially useful is for the peer to One of the features that is potentially useful is for the peer to
announce that it will now disconnect for some time, i.e. it will not announce that it will now disconnect for some time, i.e., it will not
be reachable at all. For instance, a laptop might go to suspend be reachable at all. For instance, a laptop might go to suspend
mode. In this case it could send address notification with zero new mode. In this case, it could send address notification with zero new
addresses, which would mean that it will not have any valid addresses addresses, which would mean that it will not have any valid addresses
anymore. The responder of that kind of notification would then anymore. The responder would then acknowledge that notification and
acknowledge that, and could then temporarily disable all SAs and could then temporarily disable all SAs and therefore stop sending
therefore stop sending traffic. If any of the SAs gets any packets traffic. If any of the SAs get any packets, they are simply dropped.
they are simply dropped. This could also include some kind of ACK This could also include some kind of ACK spoofing to keep the TCP/IP
spoofing to keep the TCP/IP sessions alive (or simply setting the sessions alive (or simply setting the TCP/IP keepalives and timeouts
TCP/IP keepalives and timeouts large enough not to cause problems), large enough not to cause problems), or it could simply be left to
or it could simply be left to the applications, e.g. allow TCP/IP the applications, e.g., allow TCP/IP sessions to notice if the link
sessions to notice if the link is broken. is broken.
The local policy could then indicate how long the peer should allow The local policy could then indicate how long the peer should allow
remote peers to remain disconnected. remote peers to remain disconnected.
From a technical point of view this would provide following two From a technical point of view, this would provide following two
features: features:
o There is no need to transmit IPsec data traffic. IPsec protected o There is no need to transmit IPsec data traffic. IPsec-protected
data can be dropped which saves bandwidth. This does not provide data can be dropped, which saves bandwidth. This does not provide
a functional benefit, i.e., nothing breaks if this feature is not a functional benefit, i.e., nothing breaks if this feature is not
provided. provided.
o MOBIKE signaling messages are also ignored. The IKE-SA must not o MOBIKE signaling messages are also ignored. The IKE SA must not
be deleted and the suspend functionality (realized with the zero be deleted, and the suspend functionality (realized with the zero
address set) may require the IKE-SA to be tagged with a lifetime address set) may require the IKE SA to be tagged with a lifetime
value since the IKE-SA should not be kept alive for an undefined value since the IKE SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE-SA period of time. Note that IKEv2 does not require that the IKE SA
has a lifetime associated with it. In order to prevent the IKE-SA has a lifetime associated with it. In order to prevent the IKE SA
from being deleted the dead-peer detection mechanism needs to be from being deleted, the dead-peer detection mechanism needs to be
suspended as well. suspended as well.
Due to its complexity and no clear requirement for it, it was decided Due to its complexity and no clear requirement for it, it was decided
that MOBIKE does not support this feature. that MOBIKE does not support this feature.
5.5. Return Routability Check 5.5. Return Routability Check
Changing the preferred address and subsequently using it for Changing the preferred address and subsequently using it for
communication is associated with an authorization decision: Is a peer communication is associated with an authorization decision: Is a peer
allowed to use this address? Does this peer own this address? Two allowed to use this address? Does this peer own this address? Two
skipping to change at page 20, line 41 skipping to change at page 17, line 38
determine the answer to these questions: determine the answer to these questions:
o The addresses a peer is using are part of a certificate. o The addresses a peer is using are part of a certificate.
[RFC3554] introduced this approach. If the other peer is, for [RFC3554] introduced this approach. If the other peer is, for
example, a security gateway with a limited set of fixed IP example, a security gateway with a limited set of fixed IP
addresses, then the security gateway may have a certificate with addresses, then the security gateway may have a certificate with
all the IP addresses appearing in the certificate. all the IP addresses appearing in the certificate.
o A return routability check is performed by the remote peer before o A return routability check is performed by the remote peer before
the address is updated in that peer's Security Association the address is updated in that peer's Security Association
Database. This is done in order provide a certain degree of Database. This is done in order to provide a certain degree of
confidence to the remote peer that local peer is reachable at the confidence to the remote peer that the local peer is reachable at
indicated address. the indicated address.
Without taking an authorization decision a malicious peer can Without taking an authorization decision, a malicious peer can
redirect traffic towards a third party or a blackhole. redirect traffic towards a third party or a blackhole.
A MOBIKE peer should not use an IP addressed provided by another A MOBIKE peer should not use an IP address provided by another MOBIKE
MOBIKE peer as a current address without computing the authorization peer as a current address without computing the authorization
decision. If the addresses are part of the certificate then it is decision. If the addresses are part of the certificate, then it is
not necessary to execute the return routability check. The return not necessary to execute the return routability check. The return
routability check is a form of authorization check, although it routability check is a form of authorization check, although it
provides weaker guarantees than the inclusion of the IP address as a provides weaker guarantees than the inclusion of the IP address as a
part of a certificate. If multiple addresses are communicated to the part of a certificate. If multiple addresses are communicated to the
remote peer then some of these addresses may be already verified. remote peer, then some of these addresses may be already verified.
Finally it would be possible not to execute return routability checks Finally, it would be possible not to execute return routability
at all. In case of indirect change notifications (i.e. something we checks at all. In case of indirect change notifications (i.e.,
notice from the network, not from the peer directly) we only move to something we notice from the network, not from the peer directly), we
the new preferred address after successful dead-peer detection (i.e., only move to the new preferred address after successful dead-peer
a response to a DPD test) on the new address, which is already a detection (i.e., a response to a DPD test) on the new address, which
return routability check. With a direct notification (i.e. is already a return routability check. With a direct notification
notification from the other end directly) the authenticated peer may (i.e., notification from the other end directly) the authenticated
have provided an authenticated IP address (i.e. inside IKE encrypted peer may have provided an authenticated IP address (i.e., inside IKE
and authenticated payload, see Section 5.2.5). Thus it is would be encrypted and authenticated payload; see Section 5.2.5). Thus, it is
possible to simply trust the MOBIKE peer to provide a proper IP would be possible simply to trust the MOBIKE peer to provide a proper
address. In this case A protection against an internal attacker, IP address. In this case, a protection against an internal attacker
i.e. the authenticated peer forwarding its traffic to the new (i.e., the authenticated peer forwarding its traffic to the new
address, would not provided. On the other hand we know the identity address) would not provided. On the other hand, we know the identity
of the peer in that case. There might be problems when extensions of the peer in that case. There might be problems when extensions
are added to IKEv2 that do not require authentication of end points are added to IKEv2 that do not require authentication of end points
(e.g., opportunistic security using anonymous Diffie-Hellman). (e.g., opportunistic security using anonymous Diffie-Hellman).
There is also a policy issue of when to schedule a return routability There is also a policy issue of when to schedule a return routability
check. Before moving traffic? After moving traffic? check. Before moving traffic? After moving traffic?
The basic format of the return routability check could be similar to The basic format of the return routability check could be similar to
dead-peer detection, but potential attacks are possible if a return dead-peer detection, but potential attacks are possible if a return
routability check does not include some kind of a nonce. In these routability check does not include some kind of a nonce. In these
attacks the valid end point could send an address update notification attacks, the valid end point could send an address update
for a third party, trying to get all the traffic to be sent there, notification for a third party, trying to get all the traffic to be
causing a denial of service attack. If the return routability check sent there, causing a denial-of-service attack. If the return
does not contain any nonce or other random information not known to routability check does not contain any nonce or other random
the other peer, then other peer could reply to the return routability information not known to the other peer, then the other peer could
checks even when it cannot see the request. This might cause a peer reply to the return routability checks even when it cannot see the
to move the traffic to a location where the original recipient cannot request. This might cause a peer to move the traffic to a location
be reached. where the original recipient cannot be reached.
The IKEv2 NAT-T mechanism does not perform return routability checks. The IKEv2 NAT-T mechanism does not perform return routability checks.
It simply uses the last seen source IP address used by the other peer It simply uses the last seen source IP address used by the other peer
as the destination address to send response packets. An adversary as the destination address to which response packets are to be sent.
can change those IP addresses, and can cause the response packets to An adversary can change those IP addresses and can cause the response
be sent to a wrong IP address. The situation is self-fixing when the packets to be sent to a wrong IP address. The situation is self-
adversary is no longer able to modify packets and the first packet fixing when the adversary is no longer able to modify packets and the
with an unmodified IP address reaches the other peer. Mobility first packet with an unmodified IP address reaches the other peer.
environments make this attack more difficult for an adversary since Mobility environments make this attack more difficult for an
the attack requires the adversary to be located somewhere on the adversary since the attack requires the adversary to be located
individual paths ({CoA1, ..., CoAn} towards the destination IP somewhere on the individual paths ({CoA1, ..., CoAn} towards the
address), have a shared path or, if the adversary is located near the destination IP address), to have a shared path, or, if the adversary
MOBIKE client then it needs to follow the user mobility patterns. is located near the MOBIKE client, to follow the user mobility
patterns. With IKEv2 NAT-T, the genuine client can cause third-party
With IKEv2 NAT-T, the genuine client can cause third party bombing by bombing by redirecting all the traffic pointed to him to a third
redirecting all the traffic pointed to him to a third party. As the party. As the MOBIKE protocol tries to provide equal or better
MOBIKE protocol tries to provide equal or better security than IKEv2 security than IKEv2 NAT-T mechanism, it should protect against these
NAT-T mechanism it should protect against these attacks. attacks.
There may be return routability information available from the other There may be return routability information available from the other
parts of the system too (as shown in Figure 3), but the checks done parts of the system too (as shown in Figure 3), but the checks done
may have a different quality. There are multiple levels for return may have a different quality. There are multiple levels for return
routability checks: routability checks:
o None, no tests o None; no tests.
o A party willing to answer the return routability check is located o A party willing to answer the return routability check is located
along the path to the claimed address. This is the basic form of along the path to the claimed address. This is the basic form of
return routability check. return routability check.
o There is an answer from the tested address, and that answer was o There is an answer from the tested address, and that answer was
authenticated, integrity and replay protected. authenticated and integrity- and replay-protected.
o There was an authenticated, integrity and replay protected answer o There was an authenticated and integrity- and replay-protected
from the peer, but it is not guaranteed to originate at the tested answer from the peer, but it is not guaranteed to originate at the
address or path to it (because the peer can construct a response tested address or path to it (because the peer can construct a
without seeing the request). response without seeing the request).
The return routability checks do not protect against 3rd party The return routability checks do not protect against third-party
bombing if the attacker is along the path, as the attacker can bombing if the attacker is along the path, as the attacker can
forward the return routability checks to the real peer (even if those forward the return routability checks to the real peer (even if those
packets are cryptographically authenticated). packets are cryptographically authenticated).
If the address to be tested is carried inside the MOBIKE payload, If the address to be tested is carried inside the MOBIKE payload,
then the adversary cannot forward packets. Thus 3rd party bombings then the adversary cannot forward packets. Thus, third-party
are prevented (see Section 5.2.5). bombings are prevented (see Section 5.2.5).
If the reply packet can be constructed without seeing the request If the reply packet can be constructed without seeing the request
packet (for example, if there is no nonce, challenge or similar packet (for example, if there is no nonce, challenge, or similar
mechanism to show liveness), then the genuine peer can cause 3rd mechanism to show liveness), then the genuine peer can cause third-
party bombing, by replying to those requests without seeing them at party bombing, by replying to those requests without seeing them at
all. all.
Other levels might only provide a guarantee that there is a node at Other levels might only provide a guarantee that there is a node at
the IP address which replied to the request. There is no indication the IP address that replied to the request. There is no indication
as to whether or not the reply is fresh, and whether or not the as to whether or not the reply is fresh or whether or not the request
request may have been transmitted from a different source address. may have been transmitted from a different source address.
5.5.1. Employing MOBIKE Results in other Protocols 5.5.1. Employing MOBIKE Results in Other Protocols
If MOBIKE has learned about new locations or verified the validity of If MOBIKE has learned about new locations or verified the validity of
a remote address through a return routability check, can this a remote address through a return routability check, can this
information be useful for other protocols? information be useful for other protocols?
When the basic MOBIKE VPN scenario is considered, the answer is no.
When considering the basic MOBIKE VPN scenario, the answer is no.
Transport and application layer protocols running inside the VPN Transport and application layer protocols running inside the VPN
tunnel are unaware of the outer addresses or their status. tunnel are unaware of the outer addresses or their status.
Similarly, IP layer tunnel termination at a gateway rather than a Similarly, IP-layer tunnel termination at a gateway rather than a
host endpoint limits the benefits for "other protocols" that could be host endpoint limits the benefits for "other protocols" that could be
informed -- all application protocols at the other side are unaware informed -- all application protocols at the other side are unaware
of IPsec, IKE, or MOBIKE. of IPsec, IKE, or MOBIKE.
However, it is conceivable that future uses or extensions of the However, it is conceivable that future uses or extensions of the
MOBIKE protocol make such information distribution useful. For MOBIKE protocol make such information distribution useful. For
instance, if transport mode MOBIKE and SCTP were made to work instance, if transport mode MOBIKE and SCTP were made to work
together, it would potentially be useful for SCTP dynamic address together, it would potentially be useful for SCTP dynamic address
reconfiguration [I-D.ietf-tsvwg-addip-sctp] to learn about the new reconfiguration [WIP-Ste06] to learn about the new addresses at the
addresses at the same time as MOBIKE. Similarly, various IP layer same time as MOBIKE. Similarly, various IP-layer mechanisms may make
mechanisms may make use of the fact that a return routability check use of the fact that a return routability check of a specific type
of a specific type has been performed. However, care should be has been performed. However, care should be exercised in all these
exercised in all these situations. situations.
[I-D.crocker-celp] discusses the use of common locator information [WIP-Cro04] discusses the use of common locator information pools in
pools in a IPv6 multi-homing context; it assumed that both transport a IPv6 multi-homing context; it assumes that both transport and IP-
and IP layer solutions are used in order to support multi-homing, and layer solutions are used in order to support multi-homing, and that
that it would be beneficial for different protocols to coordinate it would be beneficial for different protocols to coordinate their
their results in some way, for instance by sharing throughput results in some way, for instance, by sharing throughput information
information of address pairs. This may apply to MOBIKE as well, of address pairs. This may apply to MOBIKE as well, assuming it
assuming it co-exists with non-IPsec protocols that are faced with coexists with non-IPsec protocols that are faced with the same or
the same or similar multi-homing choices. similar multi-homing choices.
Nevertheless, all of this is outside the scope of current MOBIKE base Nevertheless, all of this is outside the scope of the current MOBIKE
protocol design and may be addressed in future work. base protocol design and may be addressed in future work.
5.5.2. Return Routability Failures 5.5.2. Return Routability Failures
If the return routability check fails, we need to tear down the IKE If the return routability check fails, we need to tear down the IKE
SA if we are using IKEv2 INFORMATIONAL exchanges to send return SA if we are using IKEv2 INFORMATIONAL exchanges to send return
routability checks. On the other hand return routability check can routability checks. On the other hand, return routability checks can
only fail permanently if there was an attack by the other end, thus only fail permanently if there was an attack by the other end; thus,
tearing down the IKE SA is a suitable action in that case. tearing down the IKE SA is a suitable action in that case.
There are some cases where the return routability check temporarily There are some cases, where the return routability check temporarily
fails that need to be considered here. In the first case there is no fails, that need to be considered here. In the first case, there is
attacker, but the selected address pair stops working immediately no attacker, but the selected address pair stops working immediately
after the address update, before the return routability check. after the address update, before the return routability check.
What happens there is that the initiator performs the normal address What happens is that the initiator performs the normal address
update, and that succeeds, and then the responder starts a return update; it succeeds, and then the responder starts a return
routability check. If the address pair has broken down before that, routability check. If the address pair has broken down before that,
the responder will never get back the reply to the return routability the responder will never get back the reply to the return routability
check. The responder might still be using the old IP address pair, check. The responder might still be using the old IP address pair,
which could still work. which could still work.
The initiator might be still seeing traffic from the responder, but The initiator might be still seeing traffic from the responder, but
using the old address pair. The initiator should detect that this using the old address pair. The initiator should detect that this
traffic is not using the latest address pair, and after a while it traffic is not using the latest address pair, and after a while it
should start dead peer detection on the current address pair. If should start dead peer detection on the current address pair. If
that fails, then it should find a new working address pair, and that fails, then it should find a new working address pair and update
update addresses to that. The responder should notice that the addresses to that. The responder should notice that the address pair
address pair was updated after the return routability check was was updated after the return routability check was started and change
started, and change the ongoing return routability check to use the the ongoing return routability check to use the new address pair.
new address pair. The result of that return routability check needs The result of that return routability check needs to be discarded as
to be discarded as it cannot be trusted as the packets were it cannot be trusted; the packets were retransmitted to a different
retransmitted to a different IP address. So normally the responder IP address. So normally the responder starts a new return
starts a new return routability check after that with the new address routability check afterward with the new address pair.
pair.
The second case is where there is an attacker along the path The second case is where there is an attacker along the path
modifying the IP addresses. The peers will detect this as NAT and modifying the IP addresses. The peers will detect this as NAT and
will enable NAT-T recovery of changes in the NAT mappings. If the will enable NAT-T recovery of changes in the NAT mappings. If the
attacker is along the path long enough for the return routability attacker is along the path long enough for the return routability
check to succeed, then the normal recovery of changes in the NAT check to succeed, then the normal recovery of changes in the NAT
mappings will take care of the problem. If the attacker disappears mappings will take care of the problem. If the attacker disappears
before return routability check is finished, but after the update we before return routability check is finished, but after the update, we
have almost a similar case than last time. Now the only difference have a case similar to the last. The only difference is that now the
is now that the dead peer detection started by the initiator will dead peer detection started by the initiator will succeed because the
succeed, as the responder will reply to the addresses in the headers, responder will reply to the addresses in the headers, not the current
not the current address pair. The initiator will then detect that address pair. The initiator will then detect that the NAT mappings
the NAT mappings are changed, and it will fix the situation by doing are changed, and it will fix the situation by doing an address
an address update. update.
The important thing for both of these cases is that the initiator The important thing for both of these cases is that the initiator
needs to see that the responder is both alive and synchronized with needs to see that the responder is both alive and synchronized with
initiator address pair updates. I.e. it is not enough that the initiator address pair updates. That is, it is not enough that the
responder is sending traffic to an initiator, it must be also using responder is sending traffic to an initiator; it must also be using
the correct IP addresses before the initiator can believe it is alive the correct IP addresses before the initiator can believe it is alive
and synchronized. From the implementation point of view this means and synchronized. From the implementation point of view, this means
that the initiator must not consider packets having wrong IP that the initiator must not consider packets having wrong IP
addresses as packets that prove the other end being alive, i.e. they addresses as packets that prove the other end is alive, i.e., they do
do not reset the dead peer detection timers. not reset the dead peer detection timers.
5.5.3. Suggested Approach 5.5.3. Suggested Approach
The working group selected to use IKEv2 INFORMATIONAL exchanges as a The working group selected to use IKEv2 INFORMATIONAL exchanges as a
return routability check, but included a random cookie to prevent return routability check, but included a random cookie to prevent
redirection by an authenticated attacker. Return routability checks redirection by an authenticated attacker. Return routability checks
are performed by default before moving the traffic. However these are performed by default before moving the traffic. However, these
tests are optional. Nodes MAY also perform these tests upon their tests are optional. Nodes may also perform these tests upon their
own initiative at other times. own initiative at other times.
It is worth noting that the return routability check in MOBIKE is It is worth noting that the return routability check in MOBIKE is
different from Mobile IPv6 [RFC3775], which does not perform return different from Mobile IPv6 [RFC3775], which does not perform return
routability operations between the mobile node and its home agent at routability operations between the mobile node and its home agent at
all. all.
5.6. IPsec Tunnel or Transport Mode 5.6. IPsec Tunnel or Transport Mode
Current MOBIKE design is focused only on the VPN type usage and The current MOBIKE design is focused only on the VPN type usage and
tunnel mode. Transport mode behavior would also be useful, but will tunnel mode. Transport mode behavior would also be useful and might
be discussed in future documents. be discussed in future documents.
6. Protocol Details 6. Protocol Details
6.1. Indicating Support for MOBIKE 6.1. Indicating Support for MOBIKE
In order for MOBIKE to function, both peers must implement the MOBIKE In order for MOBIKE to function, both peers must implement the MOBIKE
extension of IKEv2. If one of the peers does not support MOBIKE, extension of IKEv2. If one of the peers does not support MOBIKE,
then, whenever an IP address changes, IKEv2 will have to be re-run in then, whenever an IP address changes, IKEv2 will have to be re-run in
order to create a new IKE SA and the respective IPsec SAs. In order to create a new IKE SA and the respective IPsec SAs. In
MOBIKE, a peer needs to be confident that its address change messages MOBIKE, a peer needs to be confident that its address change messages
are understood by the other peer. If these messages are not are understood by the other peer. If these messages are not
understood, it is possible that connectivity between the peers is understood, it is possible that connectivity between the peers is
lost. lost.
One way to ensure that a peer receives feedback on whether its One way to ensure that a peer receives feedback on whether its
messages are understood by the other peer, is by using IKEv2 messages are understood by the other peer is to use IKEv2 messaging
messaging for MOBIKE and to mark some messages as "critical". for MOBIKE and to mark some messages as "critical". According to the
According to the IKEv2 specification, such messages either have to be IKEv2 specification, either such messages have to be understood by
understood by the receiver, or an error message has to be returned to the receiver, or an error message has to be returned to the sender.
the sender.
A second way to ensure receipt of the above-mentioned feedback is by A second way to ensure receipt of the above-mentioned feedback is by
using Vendor ID payloads that are exchanged during the initial IKEv2 using Vendor ID payloads that are exchanged during the initial IKEv2
exchange. These payloads would then indicate whether or not a given exchange. These payloads would then indicate whether or not a given
peer supports the MOBIKE protocol. peer supports the MOBIKE protocol.
A third approach would use the Notify payload to indicate support of A third approach would use the Notify payload to indicate support of
MOBIKE extension, such Notify payloads are also used for indicating MOBIKE extension. Such Notify payloads are also used for indicating
NAT traversal support (via NAT_DETECTION_SOURCE_IP and NAT traversal support (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP payloads). NAT_DETECTION_DESTINATION_IP payloads).
Both a Vendor ID and a Notify payload may be used to indicate the Both a Vendor ID and a Notify payload may be used to indicate the
support of certain extensions. support of certain extensions.
Note that a MOBIKE peer could also attempt to execute MOBIKE Note that a MOBIKE peer could also attempt to execute MOBIKE
opportunistically with the critical bit set when an address change opportunistically with the critical bit set when an address change
has occurred. The drawback of this approach is, however, that an has occurred. The drawback of this approach is, however, that an
unnecessary message exchange is introduced. unnecessary message exchange is introduced.
skipping to change at page 27, line 4 skipping to change at page 23, line 15
Although Vendor ID payloads and Notify payloads are technically Although Vendor ID payloads and Notify payloads are technically
equivalent, Notify payloads are already used in IKEv2 as a capability equivalent, Notify payloads are already used in IKEv2 as a capability
negotiation mechanism. Hence, Notify payloads are used in MOBIKE to negotiation mechanism. Hence, Notify payloads are used in MOBIKE to
indicate support of MOBIKE protocol. indicate support of MOBIKE protocol.
Also, as the information of the support of MOBIKE is not needed Also, as the information of the support of MOBIKE is not needed
during the IKE_SA_INIT exchange, the indication of the support is during the IKE_SA_INIT exchange, the indication of the support is
done inside the IKE_AUTH exchange. The reason for this is the need done inside the IKE_AUTH exchange. The reason for this is the need
to keep the IKE_SA_INIT messages as small as possible so that they do to keep the IKE_SA_INIT messages as small as possible so that they do
not get fragmented. IKEv2 allows that the responder can do stateless not get fragmented. IKEv2 allows that the responder can do stateless
processing of the first IKE_SA_INIT packet, and request a cookie from processing of the first IKE_SA_INIT packet and request a cookie from
the other end if it is under attack. To mandate the responder to be the other end if it is under attack. To mandate the responder to be
able to reassemble initial IKE_SA_INIT packets would not allow fully able to reassemble initial IKE_SA_INIT packets would not allow fully
stateless processing of the initial IKE_SA_INIT packets. stateless processing of the initial IKE_SA_INIT packets.
6.2. Path Testing and Window size 6.2. Path Testing and Window size
As IKEv2 has a window of outgoing messages, and the sender is not As IKEv2 has a window of outgoing messages, and the sender is not
allowed to violate that window (meaning, that if the window is full, allowed to violate that window (meaning that if the window is full,
then the sender cannot send packets), it can cause some complications then the sender cannot send packets), it can cause some complications
to path testing. Another complication created by IKEv2 is that once to path testing. Another complication created by IKEv2 is that once
the message is created and sent to the other end, it cannot be the message is created and sent to the other end, it cannot be
modified in its future retransmissions. This makes it impossible to modified in its future retransmissions. This makes it impossible to
know what packet actually reached the other end first. We cannot use know what packet actually reached the other end first. We cannot use
IP headers to find out which packet reached the other end first, as IP headers to find out which packet reached the other end first
if the responder gets retransmissions of the packet it has already because if the responder gets retransmissions of the packet it has
processed and replied to (and those replies might have been lost due already processed and replied to (and those replies might have been
unidirectional address pair), it will retransmit the previous reply lost due unidirectional address pair), it will retransmit the
using the new address pair of the request. Because of this it might previous reply using the new address pair of the request. Because of
be possible that the responder has already used the IP address this, it might be possible that the responder has already used the IP
information from the header of the previous packet, and the reply address information from the header of the previous packet, and the
packet ending up to the initiator has a different address pair. reply packet ending up at the initiator has a different address pair.
Another complication comes from NAT-T. The current IKEv2 document Another complication comes from NAT-T. The current IKEv2 document
says that if NAT-T is enabled the node not behind NAT SHOULD detect says that if NAT-T is enabled, the node not behind NAT SHOULD detect
if the IP-address changes in the incoming authenticated packets, and if the IP address changes in the incoming authenticated packets and
update the remote peers' addresses accordingly. This works fine with update the remote peers' addresses accordingly. This works fine with
NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs
the ability to probe another address pairs without breaking the old the ability to probe other address pairs without breaking the old
one. one.
One approach to fix this would be to add a completely new protocol One approach to fix this would be to add a completely new protocol
that is outside the IKE SA message id limitations (window code), that is outside the IKE SA message id limitations (window code),
outside identical retransmission requirements, and outside the outside identical retransmission requirements, and outside the
dynamic address updating of NAT-T. dynamic address updating of NAT-T.
Another approach is to make the protocol so that it does not violate Another approach is to make the protocol so that it does not violate
window restrictions and does not require changing the packet on window restrictions and does not require changing the packet on
retransmissions, and change the dynamic address updating of NAT-T to retransmissions, and change the dynamic address updating of NAT-T to
MUST NOT for IKE SA packets if MOBIKE is used. In order to not "MUST NOT" for IKE SA packets if MOBIKE is used. In order not to
violate window restrictions, the addresses of the currently ongoing violate window restrictions, the addresses of the currently ongoing
exchange need to be changed to test different paths. In order to not exchange need to be changed to test different paths. In order not to
require changing the packet after it is first sent requires that the require that the packet be changed after it is first sent requires
protocol needs to restart from the beginning in case the packet was that the protocol restart from the beginning in case the packet was
retransmitted to different addresses (because the sender does not retransmitted to different addresses (because the sender does not
know which packet was the one that responder got first, i.e. which know which packet the responder got first, i.e., which IP addresses
IP-addresses it used). it used).
Working group decided to use normal IKEv2 exchanges for path testing, The working group decided to use normal IKEv2 exchanges for path
and decided to change the dynamic address updating of NAT-T to MUST testing and decided to change the dynamic address updating of NAT-T
NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not to MUST NOT for IKE SA packets; a new protocol outside of IKEv2 was
adopted. not adopted.
6.3. Message presentation 6.3. Message Presentation
The IP address change notifications can be sent either via an The IP address change notifications can be sent either via an
informational exchange already specified in IKEv2, or via a MOBIKE- informational exchange already specified in IKEv2, or via a MOBIKE-
specific message exchange. Using an informational exchange has the specific message exchange. Using an informational exchange has the
main advantage that it is already specified in the IKEv2 protocol and main advantage that it is already specified in the IKEv2 protocol and
implementations can already incorporate the functionality. implementations can already incorporate the functionality.
Another question is the format of the address update notifications. Another question is the format of the address update notifications.
The address update notifications can include multiple addresses, of The address update notifications can include multiple addresses, of
which some may be IPv4 and some IPv6 addresses. The number of which some may be IPv4 and some IPv6 addresses. The number of
addresses is most likely going to be limited in typical environments addresses is most likely going to be limited in typical environments
(with less than 10 addresses). The format may need to indicate a (with less than 10 addresses). The format may need to indicate a
preference value for each address. The format could either contain a preference value for each address. The format could either contain a
preference number that determines the relative order of the preference number that determines the relative order of the addresses
addresses, or it could simply be an ordered list of IP addresses. If or could simply be an ordered list of IP addresses. If using
using preference numbers, then two addresses can have the same preference numbers, then two addresses can have the same preference
preference value, an ordered list avoids this situation. value; an ordered list avoids this situation.
Load balancing is currently outside the scope of MOBIKE, however Load balancing is currently outside the scope of MOBIKE; however,
future work might include support for it. The selected format needs future work might include support for it. The selected format needs
to be flexible enough to include additional information in future to be flexible enough to include additional information in future
versions of the protocol (e.g. to enable load balancing). This may versions of the protocol (e.g., to enable load balancing). This may
be realized with an reserved field, which can later be used to store be realized with an reserved field, which can later be used to store
additional information. As there may arise other information which additional information. As other information may arise that may have
may have to be tied to an address in the future, a reserved field to be tied to an address in the future, a reserved field seems like a
seems like a prudent design in any case. prudent design in any case.
There are two basic formats that place IP address lists into a There are two basic formats that place IP address lists into a
message. One includes each IP address as separate payload (where the message. One includes each IP address as separate payload (where the
payload order indicates the preference order, or the payload itself payload order indicates the preference order, or the payload itself
might include the preference number), or we can put the IP address might include the preference number). Alternatively, we can put the
list as one payload to the exchange, and that one payload will then IP address list as one payload to the exchange, and that one payload
have an internal format which includes the list of IP addresses. will then have an internal format that includes the list of IP
addresses.
Having multiple payloads with each one carrying one IP address makes Having multiple payloads, each one carrying one IP address, makes the
the protocol probably easier to parse, as we can already use the protocol probably easier to parse, as we can already use the normal
normal IKEv2 payload parsing procedures. It also offers an easy way IKEv2 payload parsing procedures. It also offers an easy way for the
for the extensions, as the payload probably contains only the type of extensions, as the payload probably contains only the type of the IP
the IP address (or the type is encoded to the payload type), and the address (or the type is encoded to the payload type), and the IP
IP address itself, and as each payload already has a length field address itself. As each payload already has a length field
associated to it, we can detect if there is any extra data after the associated to it, we can detect if there is any extra data after the
IP address. Some implementations might have problems parsing more IP address. Some implementations might have problems parsing more
than certain number of IKEv2 payloads, but if the sender sends them than a certain number of IKEv2 payloads, but if the sender sends them
in the most preferred first, the receiver can only use the first in the most preferred first, the receiver can only use the first
addresses, it was willing to parse. addresses it was willing to parse.
Having all IP addresses in one big MOBIKE specified internal format Having all IP addresses in one big MOBIKE-specified internal format
provides more compact encoding, and keeps the MOBIKE implementation provides more compact encoding and keeps the MOBIKE implementation
more concentrated to one module. more concentrated to one module.
Another choice is which type of payloads to use. IKEv2 already Another choice is which type of payloads to use. IKEv2 already
specifies a Notify payload. It includes some extra fields (SPI size, specifies a Notify payload. It includes some extra fields (SPI size,
SPI, protocol etc), which gives 4 bytes of the extra overhead, and SPI, protocol, etc.), which gives 4 bytes of the extra overhead, and
there is the notification data field, which could include the MOBIKE there is the notification data field, which could include the
specific data. MOBIKE-specific data.
Another option would be to have a custom payload type, which then Another option would be to have a custom payload type, which would
includes the information needed for the MOBIKE protocol. then include the information needed for the MOBIKE protocol.
Working group decided to use IKEv2 Notify payloads, and put only one The working group decided to use IKEv2 Notify payloads, and put only
data item per notify, i.e. there will be one Notify payload for each one data item per notify. There will be one Notify payload for each
item to be sent. item to be sent.
6.4. Updating address set 6.4. Updating Address Set
Because of the initiator decides all address updates, the initiator Because the initiator decides all address updates, the initiator
needs to know all the addresses used by the responder. The responder needs to know all the addresses used by the responder. The responder
also needs that list in case it happens to move to an address not also needs that list in case it happens to move to an address not
known by the initiator, and needs to send an address update known by the initiator, and it needs to send an address update
notification to the initiator, and it might need to try different notification to the initiator. It might need to try different
addresses for the initiator. addresses for the initiator.
MOBIKE could send the whole peer address list every time any of the MOBIKE could send the whole peer address list every time any of the
IP addresses change (either addresses are added, removed, the order IP addresses change (addresses are added or removed, the order
changes or the preferred address is updated) or an incremental changes, or the preferred address is updated) or an incremental
update. Sending incremental updates provides more compact packets update. Sending incremental updates provides more compact packets
(meaning we can support more IP addresses), but on the other hand (meaning we can support more IP addresses), but on the other hand
this approach has more problems in the synchronization and packet this approach has more problems in the synchronization and packet
reordering cases, i.e., incremental updates must be processed in reordering cases. That is, incremental updates must be processed in
order, but for full updates we can simply use the most recent one, order, but for full updates we can simply use the most recent one and
and ignore old ones, even if they arrive after the most recent one ignore old ones, even if they arrive after the most recent one (IKEv2
(IKEv2 packets have a message id which is incremented for each packets have a message ID that is incremented for each packet; thus,
packet, thus it is easy to know the sending order). it is easy to know the sending order).
Working group decided to use a protocol format where both ends send a The working group decided to use a protocol format where both ends
full list of their addresses to the other end, and that list send a full list of their addresses to the other end, and that list
overwrites the previous list. To support NAT-T the IP-addresses of overwrites the previous list. To support NAT-T, the IP addresses of
the received packet are considered as one address of the peer, even the received packet are considered as one address of the peer, even
when not present in the list. when they are not present in the list.
7. Security Considerations 7. Security Considerations
As all the packets are already authenticated by IKEv2 there is no As all the packets are already authenticated by IKEv2, there is no
risk that any attackers would modify the contents of the packets. risk that any attackers would undetectedly modify the contents of the
The IP addresses in the IP header of the packets are not packets. The IP addresses in the IP header of the packets are not
authenticated, thus the protocol defined must take care that they are authenticated; thus, the protocol defined must take care that they
only used as an indication that something might be different, and are only used as an indication that something might be different, and
that do not cause any direct actions, except when doing NAT that they do not cause any direct actions, except when doing NAT
Traversal. traversal.
An attacker can also spoof ICMP error messages in an effort to An attacker can also spoof ICMP error messages in an effort to
confuse the peers about which addresses are not working. At worst confuse the peers about which addresses are not working. At worst,
this causes denial of service and/or the use of non-preferred this causes denial of service and/or the use of non-preferred
addresses. addresses.
One type of attack that needs to be taken care of in the MOBIKE One type of attack that needs to be taken care of in the MOBIKE
protocol is the bombing attack type. See [RFC4225] and [Aur02] for protocol is the bombing attack type. See [RFC4225] and [Aur02] for
more information about flooding attacks. more information about flooding attacks.
See Security considerations section of [I-D.ietf-mobike-protocol] for See the security considerations section of [RFC4555] for more
more information about security considerations of the actual information about security considerations of the actual protocol.
protocol.
8. IANA Considerations
This document does not introduce any IANA considerations.
9. Acknowledgments 8. Acknowledgements
This document is the result of discussions in the MOBIKE working This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen, group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch,
Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman Udo Schilcher, Tom Henderson, Andreas Pashalidis, and Maureen
for their input. Stillman for their input.
We would like to particularly thank Pasi Eronen for tracking open We would like to particularly thank Pasi Eronen for tracking open
issues on the MOBIKE mailing list. He helped us to make good issues on the MOBIKE mailing list. He helped us make good progress
progress on the document. on the document.
10. References
10.1. Normative references 9. References
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 9.1. Normative references
RFC 4306, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
10.2. Informative References [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[I-D.ietf-mobike-protocol] 9.2. Informative References
Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-08 (work in
progress), February 2006.
[I-D.ietf-shim6-failure-detection] [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet
Arkko, J. and I. Beijnum, "Failure Detection and Locator Location Management", In Proc. 18th Annual Computer
Pair Exploration Protocol for IPv6 Multihoming", Security Applications Conference, pages 78-87, Las
draft-ietf-shim6-failure-detection-03 (work in progress), Vegas, NV USA, December 2002.
December 2005.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
(IKE)", RFC 2409, November 1998. Management API, Version 2", RFC 2367, July 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.
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
Nordmark, "Mobile IP Version 6 Route Optimization Security (IKE)", RFC 2409, November 1998.
Design Background", RFC 4225, December 2005.
[I-D.ietf-hip-mm] [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Nikander, P., "End-Host Mobility and Multihoming with the Discovery for IP Version 6 (IPv6)", RFC 2461,
Host Identity Protocol", draft-ietf-hip-mm-03 (work in December 1998.
progress), March 2006.
[I-D.crocker-celp] [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Crocker, D., "Framework for Common Endpoint Locator Autoconfiguration", RFC 2462, December 1998.
Pools", draft-crocker-celp-00 (work in progress),
February 2004.
[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", [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
RFC 3753, June 2004. and A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.ietf-tsvwg-addip-sctp] [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Stewart, R., "Stream Control Transmission Protocol (SCTP) Self-Address Fixing (UNSAF) Across Network Address
Dynamic Address Reconfiguration", Translation", RFC 3424, November 2002.
draft-ietf-tsvwg-addip-sctp-13 (work in progress),
November 2005.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003. Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[I-D.ietf-ipv6-optimistic-dad] [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
Moore, N., "Optimistic Duplicate Address Detection for RFC 3753, June 2004.
IPv6", draft-ietf-ipv6-optimistic-dad-07 (work in
progress), December 2005.
[I-D.ietf-ipv6-unique-local-addr] [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Support in IPv6", RFC 3775, June 2004.
Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
progress), January 2005.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
E. Lear, "Address Allocation for Private Internets", Addresses", RFC 4193, October 2005.
BCP 5, RFC 1918, February 1996.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
Management API, Version 2", RFC 2367, July 1998. E. Nordmark, "Mobile IP Version 6 Route Optimization
Security Design Background", RFC 4225, December 2005.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
Autoconfiguration", RFC 2462, December 1998. for IPv6", RFC 4429, April 2006.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
Discovery for IP Version 6 (IPv6)", RFC 2461, (MOBIKE)", RFC 4555, June 2006.
December 1998.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator
Self-Address Fixing (UNSAF) Across Network Address Pair Exploration Protocol for IPv6 Multihoming", Work in
Translation", RFC 3424, November 2002. Progress, June 2006.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and [WIP-Cro04] Crocker, D., "Framework for Common Endpoint Locator
A. Rayhan, "Middlebox communication architecture and Pools", Work in Progress, February 2004.
framework", RFC 3303, August 2002.
[I-D.ietf-nsis-nslp-natfw] [WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer the Host Identity Protocol", Work in Progress,
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in June 2006.
progress), February 2006.
[Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet [WIP-Ste06] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Location Management", In Proc. 18th Annual Computer Conrad, "Stream Control Transmission Protocol (SCTP)
Security Applications Conference, pages 78-87, Las Vegas, Dynamic Address Reconfiguration", Work in Progress,
NV USA, December 2002. June 2006.
[WIP-Sti06] Stiemerling, M., Tschofenig, H., Aoun, C., and E.
Davies, "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", Work in Progress, June 2006.
Authors' Addresses Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
Fredrikinkatu 47 Fredrikinkatu 47
HELSINKI FI-00100 HELSINKI FI-00100
FI FI
Email: kivinen@safenet-inc.com EMail: kivinen@safenet-inc.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 37, line 29 skipping to change at page 30, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 183 change blocks. 
592 lines changed or deleted 546 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/