draft-ietf-mobike-design-00.txt   draft-ietf-mobike-design-01.txt 
IKEv2 Mobility and Multihoming T. Kivinen IKEv2 Mobility and Multihoming T. Kivinen
(mobike) Safenet, Inc. (mobike) Safenet, Inc.
Internet-Draft H. Tschofenig
Expires: July 1, 2005 Siemens
December 31, 2004
Expires: December 23, 2004 Design of the MOBIKE Protocol
draft-ietf-mobike-design-01.txt
Design of the MOBIKE protocol
draft-ietf-mobike-design-00.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2004. This Internet-Draft will expire on July 1, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document discusses the potential design decisions in the base The MOBIKE (IKEv2 Mobility and Multihoming) working group is
MOBIKE (IKEv2 Mobility and Multihoming) protocol. It also tries to developing protocol extensions to the Internet Key Exchange Protocol
provide some background information about different choices and tries version 2 (IKEv2) to enable its use in the context where there are
to record the decisions made by the working group, so that we do not multiple IP addresses per host or where IP addresses of an IPsec host
need to repeat discussion later. change over time (for example due to mobility).
This document discusses the involved network entities, and the
relationship between IKEv2 signaling and information provided by
other protocols and the rest of the network. Design decisions for
the base MOBIKE protocol, background information and discussions
within the working group are recorded.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Roaming Laptop Scenario . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Multihoming SGW Scenario . . . . . . . . . . . . . . . . . 4 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 6
3. Adopting a new address / multihoming support . . . . . . . . . 6 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 7
3.1 IP-address list or one IP-address . . . . . . . . . . . . 6 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 8
3.2 Indirect or direct indication (issue #1) . . . . . . . . . 7 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Dead peer detection and IKEv2 (issue #11) . . . . . . . . 7 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
4. Simultaneous Movements (issue #2) . . . . . . . . . . . . . . 9 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 12
5. Interaction with NAT-T (issue #3) . . . . . . . . . . . . . . 10 5.2 Changing a Preferred Address and Multihoming Support . . . 12
6. Changing addresses or changing the paths (issue #10, #14) . . 11 5.2.1 Storing a single or multiple addresses . . . . . . . . 13
7. How and When to do Return Routability Checks (issue #6, 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 14
#12, #15) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 15
8. Scope of SA changes (issue #8) . . . . . . . . . . . . . . . . 14 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 16
9. Zero Address Set (issue #5) . . . . . . . . . . . . . . . . . 15 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17
10. What modes we support (issue #7) . . . . . . . . . . . . . . 16 5.5 Changing addresses or changing the paths . . . . . . . . . 18
11. Message representation . . . . . . . . . . . . . . . . . . . 17 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . 19 5.7 Employing MOBIKE results in other protocols . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 23
14.1 Normative references . . . . . . . . . . . . . . . . . . . . 21 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 24
14.2 Non-normative references . . . . . . . . . . . . . . . . . . 21 5.11 Message Representation . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1 Normative references . . . . . . . . . . . . . . . . . . . . 29
9.2 Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 32
1. Introduction 1. Introduction
IKEv2 is used for performing mutual authentication and establishing
and maintaining IPsec security associations (SAs). IKEv2 establishes
both cryptographic state (such as session keys and algorithms) as
well as non-cryptographic information (such as IP addresses).
The current IKEv2 and IPsec documents explicitly say that the IPsec The current IKEv2 and IPsec documents explicitly say that the IPsec
and IKE SAs created implicitly between the IP-addresses used in the and IKE SAs are created implicitly between the IP address pair used
IKEv2 SA. This means that there is only one IP-address pair attached during the protocol execution when establishing the IKEv2 SA. This
for the IKEv2 SA, and the only one IP-address pair used as a gateway means that there is only one IP address pair stored for the IKEv2 SA,
endpoint address for tunnel mode IPsec SAs. Also after the SA is and this single IP address pair is used as an outer endpoint address
created there is no way to change those addresses. for tunnel mode IPsec SAs. After the IKE SA is created there is no
way to change them.
There are scenarios which require that the IP address might change There are scenarios where this IP address might change, even
rapidly. In some cases the problem could be solved by rekeying all frequently. In some cases the problem could be solved by rekeying
the IPsec and IKE SAs after the IP-address has changed. In some all the IPsec and IKE SAs after the IP address has changed. However,
scenarios this might be problematic, as the device might be too slow this can be problematic, as the device might be too slow to rekey the
to rekey the SAs that often, and other scenarios the rekeying and SAs that often, and other scenarios the rekeying and required IKEv2
required IKEv2 authentication might require user interaction (SecurID authentication might require user interaction (SecurID cards etc).
cards etc). Due to these reasons, a mechanism to update the Due to these reasons, a mechanism to update the IP addresses tied to
IP-addresses tied to the IPsec and IKEv2 SAs is needed. the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the
problem of the updating the IP addresses stored with IKE SAs and
IPsec SAs.
The charter of the MOBIKE working group requires IKEv2, and as IKEv2 The charter of the MOBIKE working group requires IKEv2
assumes that the RFC2401bis architecture is used, all protocols [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis
developed will use both IKEv2 and RFC2401bis (issue #9). No effort is architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols
to be made to make protocols for IKEv1 or old RFC2401 architecture. developed will use both IKEv2 and RFC2401bis. No effort is to be
made to make protocols for IKEv1 [RFC2409] or old RFC2401
architecture [RFC2401].
MOBIKE protocol provides solution to the problem of the updating the This document is structured as follows. After introducing some
IP-addresses. The MOBIKE protocol should take care following: important terms in Section 2 we list a few scenarios in Section 3, to
o Notifying the other end of IP-address(es) change illustrate possible deployment environments. MOBIKE depends on
o Update the IKE SA endpoint addresses based on the notifications information from other sources (e.g., detect an address change) which
o Switching to use new IP-address if old one does not work anymore are discussed in Section 4. Finally, Section 5 discusses design
o Updating the tunnel mode IPsec SA tunnel endpoint addresses considerations effecting the MOBIKE protocol. The document concludes
o Ensuring that the given new addresses belong to the peer with security considerations in Section 6.
The MOBIKE protocol can be used in different scenarios. Two such 2. Terminology
scenarios are discussed below.
1.1 Roaming Laptop Scenario This section introduces some terms in useful for a MOBIKE protocol.
In the roaming laptop scenario the device that moves around is Peer:
laptop, which might have several ways to connect to internet. It
might for example have fixed ethernet, WLAN and GPRS access to net,
and some of those can be used in different times. It tries to use the
most efficient connection it has all the time, but that connection
might change. For example user can disconnect himself from the fixed
ethernet, and then use the office WLAN, and then later leave the
office and start using GPRS during the trip to home. In home he might
again use again WLAN (but with different IP-addresses) etc.
The device does not use Mobile IP or anything similar, it simply Within this document we refer to IKEv2 endpoints as peers. A peer
wants to keep the VPN connection to the corporate security gateway implements MOBIKE and therefore IKEv2.
(SGW) up and running all the time. Even if the interface or the
IP-addresses change, the internal addresses used inside the IPsec
tunnel remains same (allocated from the SGW), i.e. the applications
might not detect the changes at all.
1.2 Multihoming SGW Scenario Available address:
Another possible scenario which might use MOBIKE is the SGW of the This definition is reused from
other end of the roaming laptop scenario. The SGW might have multiple [I-D.arkko-multi6dt-failure-detection] and refers to addresses
interfaces to different ISPs, and wants to provide connection even which are available by an peer. A few conditions must hold before
when some of those connections are broken. One of the interface might an address in such a state.
also be the WLAN access point in the office. The SGW will know
beforehand what set of IP-addresses it will use, but it might need to
dynamically send update notifications the clients to tell them which
addresses to use. It might also use this to do some sort of load
balancing, i.e. giving different clients different preferred address,
to utilize all the connections. This kind of load balancing is
completely internal to the SGW (i.e. the clients will simply see that
the preferred IP-address to be used for tunnel endpoint changes, but
they do not know why or how the SGW decided to do that), and the
actual algorithms how to do that is outside the scope of MOBIKE
protocol (i.e. the whole issues is that MOBIKE does not disallow the
SGW to give different sets of IP-addresses in different preference
order to different clients).
Note, that the load-balancing inside the one IKE SA (i.e. one client) Locally Operational Address:
is not handled in the MOBIKE protocol. Each client uses only one of
the IP-addresses given by the SGW at one time.
2. Issues An available address is said to be locally operational when its
use is known to be possible locally. This definition is taken
from [I-D.arkko-multi6dt-failure-detection].
The base protocol needs to perform the following things: Operational address pair:
o Ability to inform the peer about the current or changed
address(es) of the sender
o Ability to inform the peer about the preferred address
o Ability to detect an outage situation and fall back to the use of
another address
o Ability to prevent flooding attacks based on announcing someone
else's address
o Ability to affect both the IKE and IPsec SAs
One of the key issues affecting the MOBIKE protocol is, whether A pair of operational addresses are said to be an operational
MOBIKE protocol needs to recover from the case where packets simply address pair, iff bidirectional connectivity can be shown between
dont get through. If the node can locally detect some problems with the two addresses. Note that sometimes it is necessary to
the interfaces (IP-address change, interface disappearing, link going consider a 5-tuple when connectivity between two endpoints need to
down), it can act based on that and fix the situation. If the packets be tested. This differentiation might be necessary to address
are simply disappearing somewhere in the net, the detection of the load balancers, certain Network Address Translation types or
problem requires noticing that we cannot get packets through. If the specific firewalls. This definition is taken from
protocol only need to fix problems appearing in the local interfaces, [I-D.arkko-multi6dt-failure-detection] and enhanced to fit the
then the protocol is much simpler. MOBIKE context. Although it is possible to further differentiate
unidirectional and bidirectional operational address pairs only
bidirectional connectivity is relevant for this document and
unidirectional connectivity is out of scope.
3. Adopting a new address / multihoming support Path:
From the MOBIKE's point of view the multihoming support is the set of The route taken by the MOBIKE and/or IPsec packets sent via the IP
rules how and when to change to use new IP-address for the other end. address of one peer to a specific destination address of the other
peer. Note that the path might be effected not only by the source
and destination IP addresses but also by the selected transport
protocol and transport protocol identifier. Since MOBIKE and
IPsec packets have a different appearance on the wire they might
be routed along a different path. This definition is taken from
[RFC2960] and modified to fit the MOBIKE context.
3.1 IP-address list or one IP-address Primary Path:
The primary path is the destination and source address that will
be put into a packet outbound to the peer by default. This
definition is taken from [RFC2960] and modified to fit the MOBIKE
context.
Preferred Address:
An address on which a peer prefers to receive MOBIKE messages and
IPsec protected data traffic. A given peer has only one active
preferred address at a given point in time (ignoring the small
time period where it needs to switch from the old preferred
address to a new preferred address). This definition is taken
from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context.
Peer Address Set:
A subset of locally operational addresses that will sent
communicated to another peer. A policy available at the peer
indicates which addresses to include in the peer address set.
Such a policy might be impacted by manual configuration or by
interaction with other protocols which indicate newly available
addresses. Note that the addresses in the peer address set might
change over time.
Preferred Address Pair:
This address pair taken from the peer address set is used for
communication. The preferred address pair is used (1) for MOBIKE
communication where only two IP addresses are used and (2) as the
outer IP addresses (source and destination IP address) of the
IPsec packet in tunnel mode.
Terminology for different NAT types, such as Full Cone, Restricted
Cone, Port Restricted Cone and Symmetric, can be found in Section 5
of [RFC3489]. For mobility related terminology, such as
Make-before-break or Break-before-make see [RFC3753].
3. Scenarios
The MOBIKE protocol can be used in different scenarios. Three of
them are discussed below.
3.1 Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile
node attaches to, for example a wireless LAN, to obtain connectivity
to some security gateway. This security gateway might connect the
mobile node to a corporate network, to a UTMS network or to some
other network. The initial IKEv2 exchange takes place along the path
labeled as 'old path' from the MN using its old IP address via the
old access router (OAR) towards the security gateway (GW). The IPsec
tunnel mode terminates there but the decapsulated data packet will
typically address another destination. Since only MOBIKE is relevant
for this discussion the end-to-end communication between the MN and
some destination server is not shown in Figure 1.
When the MN moves to a new network and obtains a new IP address from
a new access router (NAR) it is the responsibility of MOBIKE to avoid
restarting the IKEv2 exchange from scratch. As a result, some form
of protocol exchange, denoted as 'MOBIKE Address Update', will
perform the necessary state update. The protocol messages will
travel along a new path whereby the old path and the new path will
meet at the cross-over router.
Note that in a break-before-make mobility scenario the MN obtains a
new IP address after reachability to the old IP address has been
lost. MOBIKE is also assumed to work in scenarios where the mobile
node is able to establish connectivity with the new IP address while
still being reachable at the old IP address.
(Initial IKEv2 Exchange)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v
Old IP +--+ +---+ v
address |MN|------> |OAR| -------------V v
+--+ +---+ Old path V v
. +----+ v>>>>> +--+
.move | CR | -------> |GW|
. | | >>>>> | |
v +----+ ^ +--+
+--+ +---+ New path ^ ^
New IP |MN|------> |NAR|--------------^ ^
address +--+ +---+ ^
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^
(MOBIKE Address Update)
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
...> = End host movement
Figure 1: Mobility Scenario
3.2 Multihoming Scenario
Another scenario where MOBIKE might be used is between two peers
equipped with multiple interfaces (and multiple IP addresses).
Figure 2 shows two such multi-homed peers. Peer A has two interface
cards with two IP addresses IP_A1 and IP_A2. Additionally, Peer B
also has two IP addresses, IP_B1 and IP_B2. Each peer selects one of
its IP addresses as the preferred address which will subsequently be
used for communication. Various reasons, such as problems with the
interface card, might require a peer to switch from one IP address to
the other one.
+------------+ +------------+
| Peer A | *~~~~~~~~~* | Peer B |
| |>>>>>>>>>> * Network *>>>>>>>>>>| |
| IP_A1 +-------->+ +--------->+ IP_B1 |
| | | | | |
| IP_A2 +********>+ +*********>+ IP_B2 |
| | * * | |
+------------+ *~~~~~~~~~* +------------+
---> = Path taken by data packets
>>>> = Signaling traffic (IKEv2 and MOBIKE)
***> = Potential future path through the network
(if Peer A and Peer B chance their preferred
address)
Figure 2: Multihoming Scenario
Note, that the load-balancing inside one IKE SA is not provided by
the MOBIKE protocol. Each client uses only one of the available IP
addresses at a given point in time.
3.3 Multihomed Laptop Scenario
In the multihomed laptop scenario we consider a laptop, which has
multiple interface cards and therefore several ways to connect to a
network. It might for example have a fixed Ethernet, WLAN, GPRS,
Bluetooth or USB hardware in order to sent IP packets. Some of these
interfaces might connected to a network over the time depending on a
number of reasons (e.g., cost, availability of certain link layer
technologies, user convenience). For example, the user can
disconnect himself from the fixed Ethernet, and then use the office
WLAN, and then later leave the office and start using GPRS during the
trip to home. At home he might again use again WLAN. At a certain
point in time multiple interfaces might be connected. As such, the
laptop is a multihomed device. In any case, the IP address of the
individual interfaces are subject to change.
The user desires to keep the established IKE-SA and IPsec SAs alive
all time without the need to re-run the initial IKEv2 exchange which
could require user interaction as part of the authentication process.
Furthermore, even if IP addresses change due to interface switching
or mobility, the IP source and destination address obtained via the
configuration payloads within IKEv2 and used inside the IPsec tunnel
remains unaffected, i.e., applications might not detect any change at
all.
4. Framework
Initially, when a MOBIKE peer starts and executes the initial
protocol exchange with its MOBIKE peer it needs to setup a peer
address set based on the available addresses. It might want to make
this peer address set available to the other peer. The Initiator
does not need to explicitly indicate its preferred address since
already using its preferred address. The outgoing IKEv2 and MOBIKE
messages use this preferred address as the source IP address and
expects incoming signaling messages to be addressed to this address.
Interaction with other protocols at the MOBIKE host is required to
build the peer address set and the preferred address. In some cases
the peer address set is available before the initial protocol run and
does not change during the lifetime of the IKE-SA. The preferred
address might change due to policy reasons. In many other cases, as
motivated in Section 3 the peer address set is modified (by adding or
deleting addresses) and the preferred address needs to be changed as
well.
Modifying the peer address set or changing the preferred address is
effected by the host's local policy and by the interaction with other
protocols (such as DHCP or IPv6 Neighbor Discovery).
Figure 3 shows an example protocol interaction at a MOBIKE peer.
MOBIKE interacts with the IPsec engine using the PF_KEY interface to
create entries in the Security Association and Security Policy
Databases. The IPsec engine might also interact with IKEv2 and
MOBIKE. Established state at the IPsec databases has an impact on
the incoming and outgoing data traffic. MOBIKE receives information
from other protocols running in both kernel-mode and user-mode, as
previously mentioned. Information relevant for MOBIKE is stored in a
database, referred as Trigger database which guides MOBIKE in its
decisions regarding the available addresses, peer address set and the
preferred address. Policies might affect the selection process.
Building and maintaining a peer address set and selecting or changing
a preferred address based on locally available information is,
however, insufficient. This information needs to be available to the
other peer and in order to address various failure cases it is
necessary to test connectivity along a path. A number of address
pairs might be available for connectivity tests but most important is
the source and the destination IP address of the preferred address
pair since these addresses are selected for sending and receiving
MOBIKE signaling messages and for sending and receiving IPsec
protected data traffic. If a problem along this primary path is
detected (e.g., due to a router failure) it is necessary to switch to
the new preferred address pair. Testing other paths might also be
useful to notice when a disconnected path is operational again.
+-------------+ +---------+
|User-space | | MOBIKE |
|Protocols | +-->>| Daemon |
|relevant for | | | |
|MOBIKE | | +---------+
+-------------+ | ^
User Space ^ | ^
++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++
Kernel Space v | v
_______ | v
+-------------+ / \ | +--------------+
|Routing | / Trigger \ | | IPsec |
|Protocols |<<-->>| Database |<<-+ +>+ Engine |
| | \ / | | (+Databases) |
+-----+---+---+ \_______/ | +------+-------+
^ ^ ^ | ^
| +---------------+-------------+--------+-----+
| v | | |
| +-------------+ | | |
I | |Kernel-space | | | | I
n | +-------->+Protocols +<----+-----+ | | n
t v v |relevant for | | v v v t
e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e
r | Input | +-------------+ | | Outgoing | r
f | Packet +<--------------------------+ | Interface | f
==a>|Processing|===============================| Processing |=a>
c | | | | c
e +----------+ +------------+ e
s s
===> = IP packets arriving/leaving a MOBIKE node
<-> = control and configuration operations
Figure 3: Framework
Although the interaction with other protocols is important for MOBIKE
to operate correctly the working group is chartered to leave this
aspect outside the scope. The working group will develop a MOBIKE
protocol which needs to perform the following functionality:
o Ability to inform a peer about the peer address set
o Ability to inform a peer about the preferred address
o Ability to test connectivity along a path and thereby to detect an
outage situation in order to fall back to another preferred
address, if necessary, or to change the peer address set
o Ability to deal with Network Address Translation devices
In addition to the above-listed functionality security is important
to the working group. For example, the ability to prevent flooding
attacks based on announcing someone else's address needs to be dealt
with.
Extensions of the PF_KEY interface required by MOBIKE are also within
the scope of the working group. Finally, optimizations in wireless
environment will also be covered.
Note that MOBIKE is somewhat different compared to, for example, SCTP
mobility since both the IKE-SA and the IPsec SA is affected by the
change of addresses.
5. Design Considerations
This section discusses aspects affecting the design of the MOBIKE
protocol.
5.1 Indicating Support for MOBIKE
A node needs to be able to guarantee that its address change messages
are understood by its corresponding peer. Otherwise an address
change may render the connection useless, and it is important that
both sides realize this as early as possible.
Ensuring that the messages are understood can in be arranged either
by marking some IKEv2 payloads critical so that they are either
processed or an error message is returned, by using Vendor ID
payloads or via a Notify.
The first solution approach is to use Vendor ID payloads during the
initial IKEv2 exchange using a specific string denoting MOBIKE to
signal the support of the MOBIKE protocol. This ensures that in all
cases a MOBIKE capable node knows whether its peer supports MOBIKE or
not.
The second solution approach uses the Notify payload which is also
used for NAT detection (via NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP).
Both, a Vendor ID and a Notify payload, might be used to indicate the
support of certain extensions.
Note that the node could also attempt MOBIKE optimistically with the
critical bit set to one when a movement has occurred. The drawback
of this approach is, however, that the an unnecessary MOBIKE message
round is introduced on the first movement.
Although Vendor ID payloads and Notifications are technically
equivalent Notifications are already used in IKEv2 as a capability
negotiation mechanism and is therefore the preferred mechanism.
5.2 Changing a Preferred Address and Multihoming Support
From MOBIKE's point of view multihoming support is integrated by
supporting a peer address set rather than a single address and
protocol mechanisms to change to use a new preferred IP address.
From a protocol point of view each peer needs to learn the preferred
address and the peer address set somehow, implicitly or explicitly.
5.2.1 Storing a single or multiple addresses
One design decision is whether an IKE-SA should store a single IP
address or multiple IP addresses as part of the peer address set.
One option is that the other end can provide a list of addresses One option is that the other end can provide a list of addresses
which can be used as destination addresses, and the local end needs which can be used as destination addresses. MOBIKE does not include
to decide which of them to use. The MOBIKE does not include load balancing, i.e., only one IP address is set to a preferred
load-balancing, i.e. the local end only uses one IP-address at time, address at a time and changing the preferred address typically
and it only changes to use new IP-address after some kind of requires some MOBIKE signaling.
indication.
Another option is to only communicate one address for each end, and Another option is to only communicate one address towards the other
both ends only use that address when communicating. When the peer and both peers only use that address when communicating. If
something changes, the end whose situation changes, sends update this preferred address cannot be used anymore then an address update
notification to the other end, changing that one address. is sent to the other peer changing the primary address.
If the other end provides the full list of possible IP-addresses, If peer A provides a peer address set with multiple IP addresses then
then the other end can recover from the movements on its own, meaning peer B can recover from a failure of the preferred address on its
that when it detects it cannot get packets through it can try another own, meaning that when it detects that the primary path does not work
IP-address. If the other end only provides one IP-address to be used, anymore it can either switch to a new preferred address locally
then the other end has to wait for the new IP-address before the (i.e., causing the source IP address of outgoing MOBIKE messages to
situation is fixed. The good thing about only one IP-address for the have a non-preferred address) or to try an IP address from A's peer
remote host is that it makes retransmission easy, and it also makes address set. If peer B only received a single IP address as the A's
it clear which end should do the recovery (i.e. the end, whose peer address set then peer B can only change its own preferred
IP-address changed, MUST start recovery process and send the new address. The other end has to wait for an address update from peer A
IP-address to the other end). with a new IP address in order to fix the problem. The main
advantage about using a single IP address for the remote host is that
it makes retransmission easy, and it also simplifies the recover
procedure. The peer, whose IP address changed, must start recovery
process and send the new IP address to the other peer. Failures
along the path are not well covered with advertising a single IP
address.
The one IP-address approach will not work if both ends happen to The single IP address approach will not work if both peers happen to
loose their IP-address at the same time (routing problems, which loose their IP address at the same time (due to, say, the failure of
causes the one link between the hosts to go down, thus either end one of the links that both nodes are connected to). It may also
cannot get recovery packets through as the link is down). It also may require the IKEv2 window size to be larger than 1, especially if only
cause the requirement for the IKEv2 window size larger than 1, direct indications are used. This is because the host needs to be
especially if only direct indications are used. This is because the able to send the IP address change notifications before it can switch
host needs to be able to send the IP-address change notifications to another address, and depending on the return routability checks,
before it can switch to another address, and depending on the return retransmissions policies etc, it might be hard to make the protocol
routability checks, retransmissions policies etc, it might be hard to such that it works with window size of 1 too. Furthermore, the
make the protocol such that it works with window size of 1 too (issue single IP address approach does not really benefit much from indirect
#11). Also one IP-address approach does not really benefit much from indications as the peer receiving these indications might not be able
the indirect indications as the end getting those indirect to fix the situation by itself (e.g., even if a peer receives an ICMP
indications cannot often fix the situation by itself (i.e. even if host unreachable message for the old IP address, it cannot try other
the host gets ICMP host unreachable for the old IP-address, it cannot IP addresses, since they are unknown).
try other IP-addresses, as it does not know them).
The problems with IP address list are mostly in its complexity.
The problems with IP-address list are mostly in its complexity.
Notification and recovery processes are more complex, as both end can Notification and recovery processes are more complex, as both end can
recover from the IP-address changes. There is also possibilities that recover from the IP address changes. There is also possibilities
both ends tries to recover at the same time and this must be taken that both ends tries to recover at the same time and this must be
care in the protocol. taken care in the protocol.
3.2 Indirect or direct indication (issue #1) Please note that the discussed aspect is partially different from the
question how many addresses to sent in a single MOBIKE message. A
MOBIKE message might be able to carry more than one IP address (with
the IP address list approach) or a single address only. The latter
approach has the advantage of dealing with NAT traversal in a proper
fashion. A NAT cannot change addresses carried inside the MOBIKE
message but it can change IP address (and transport layer addresses)
in the IP header and Transport Protocol header (if NAT traversal is
enabled). Furthermore, a MOBIKE message carrying the peer address
set could be idempotent (i.e., always resending the full address
list) or does the protocol allow add/delete operations to be
specified. [I-D.dupont-ikev2-addrmgmt], for example, offers an
approach which defines add/delete operations. The same is true for
the dynamic address reconfiguration extension for SCTP
[I-D.ietf-tsvwg-addip-sctp].
The indication that the situation regarding the IP-address has 5.2.2 Indirect or Direct Indication
changed might be either direct or indirect. The direct indication
means that the other end will send specific indication that now
something changed. The indirect indication is something which can be
observed from infrastructure or lack of packets, not directly from
the other end.
The direct indication can be for example the other end IKEv2 sending An indication to change the preferred IP address might be either
authenticated address update notification, which have different direct or indirect.
IP-address(es) than used earlier.
The indirect indication can be many things. One example might be that Direct indication:
the local end notices that suddenly the other ends start using
different source address for the packets than what it used before, or
ICMP message or routing information change.
Another type of indirect information might that there has been no A direct indication means that the other peer will send an message
traffic from the other end for some time (i.e. the current connection with the address change. Such a message can, for example,
might be broken). accomplished by having MOBIKE sending an authenticated address
update notification with a different preferred address.
This kind of indirect information should not directly cause any Indirect indication:
changes to the IP-addresses, but they should be used as indication
that there might be need to do dead-peer-detection for the currently
used address. I.e. when the local end detects that the other end
started to use different source IP-address than which was used
before, it should initiate dead-peer-detection for the address
currently in use. If that dead-peer-detection tells that the
connection is alive, then there is no need to do anything. If local
end does not receive any reply to the dead-peer-detection, then it
should do dead-peer-detection for the other addresses in the list (if
available, in the preferred order). If it can find an address which
works, it will switch to that.
3.3 Dead peer detection and IKEv2 (issue #11) An indirect indication to change the preferred address can be
obtained by observing the environment. An indirect indication
might, for example, be be the receipt of an ICMP message or
information of a link failure. This information should be seen as
a hint and might not directly cause any changes to the preferred
address. Depending on the local policy MOBIKE might decide to
perform a dead-peer detection exchange for the preferred address
pair (or another address pair from the peer address set). When a
peer detects that the other end started to use different source IP
address than before, it might want to authorize the new preferred
address (if not already authorized). A peer might also start a
connectivity test of this particular address.If a bidirectionally
operational address pair is selected then MOBIKE needs to
communicate this new preferred address to its remote peer.
The IKEv2 dead-peer-detection is done by sending empty informational MOBIKE will utilize both mechanisms, direct and indirect indications,
exchange packet to the other end, in which case the other end will to make a more intelligent decision which address pair to select as
acknowledge that. If no acknowledge is received after certain timeout the preferred address. The more information will be available to
(and after couple of retransmissions), the local end should try other MOBIKE the faster a new operational preferred address pair can be
IP-addresses (if available). The packets to other IP-addresses should selected among the available candiates.
use the same message-id as the original dead-peer-detection (i.e.
they are simply retransmissions of the dead-peer-detection packet
using different destination IP-address). If different message-id is
used that violates the IKEv2 constraints on the mandatory ACK for
each message-id, causing the IKEv2 SA to be teared down.
If the local end does not receive acknowledge message back from any 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection
of the IP-addresses, it should mark the IKE SA dead, and delete it
(as mandated by the IKEv2 specification).
Note, that as IKEv2 implementations might have window size of 1, it This section discusses the suitability of the IKEv2 dead-peer
means that while we are doing some other exchange, we cannot initiate detection (DPD) mechanism for connectivity tests between address
dead-peer-detection. This means that all other exchanges should also pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but
receive identical retransmission policy than what is used for the it needs to be investigated whether it can be used for MOBIKE
dead-peer-detection (issue #11). purposes as well.
The dead-peer-detection for the other IP-addresses can also be done The IKEv2 DPD mechanism is done by sending an empty informational
simultaneously, meaning that after the initial timeout of the exchange packet to the other peer, in which case the other end will
preferred address expires, we send packets simultaneously to all respond with an acknowledgement. If no acknowledgement is received
other IP-addresses. The problem here is that we need to distinguish after certain timeout (and after couple of retransmissions), the
from the acknowledge packets which IP-address actually works now other peer is considered to be not reachable. Note that the receipt
(i.e. we will check the acknowledge packets source IP-address, as it of IPsec protected data traffic is also a guarantee that the other
should match the destination IP we sent out). peer is alive.
Also the other end is most likely going to reply only to the first When reusing dead-peer detection in MOBIKE for connectivity tests it
packet it receives, and that first packet might not be the most seems to be reasonable to try other IP addresses (if they are
preferred IP-address. The reason the other end is only responding to available) in case of unsuccessful connectivity test for a given
the first packet it receives, is that implementations should not send address pair. Dead-peer detection messages using a different address
retransmissions if they have just sent out identical retransmissions. pair should use the same message-id as the original dead-peer
This is to protect the packet multiplication problem, which can detection message (i.e. they are simply retransmissions of the
happen if some node in the network queues up packets and then send dead-peer detection packet using different destination IP address).
them to the destination. If destination will reply to all of them If different message-id is used then it violates constraints placed
then the other end will again see multiple packets, and will reply to by the IKEv2 specification on the DPD message with regard to the
all of them etc. mandatory ACK for each message-id, causing the IKEv2 SA to be
deleted.
If MOBIKE strictly follows the guidelines of the dead-peer detection
mechanism in IKEv2 then an IKE-SA should be marked as dead and
deleted if the connectivity test for all address pairs fails. Note
that this is not in-line with the approach used, for example, in SCTP
where a failed connectivity test for an address does not lead to (a)
the IP address or IP address pair to be marked as dead and (b) delete
state. Connectivity tests will be continued for the address pairs in
hope that the problem will recover soon.
Note, that as IKEv2 implementations might have window size of 1,
which prevents to initiate a dead-peer detection exchange while doing
another exchange. As a result all other exchanges experience the
identical retransmission policy as used for the dead-peer detection.
The dead-peer detection for the other IP address pairs can also be
executed simultaneously (with a window size larger than 1), meaning
that after the initial timeout of the preferred address expires, we
send packets simultaneously to all other address pairs. It is
necessary to differentiate individual acknowledgement messages in
order to determine which address pair is operational. Therefore the
source IP address of the acknowledgement should match the destination
IP towards the message was previously sent.
Also the other peer is most likely going to reply only to the first
packet it receives, and that first packet might not be the best (by
whatever criteria) address pair. The reason the other peer is only
responding to the first packet it receives, is that implementations
should not send retransmissions if they have just sent out identical
response message. This is to protect the packet multiplication
problem, which can happen if some node in the network queues up
packets and then send them to the destination. If destination will
reply to all of them then the other end will again see multiple
packets, and will reply to all of them etc.
The protocol should also be nice to the network, meaning, that when The protocol should also be nice to the network, meaning, that when
some core router link goes down, and all those MOBIKE clients notice some core router link goes down, and a large number of MOBIKE clients
that, they should not start sending lots of messages while trying to notice it, they should not start sending a large number of messages
recover from the problem. This might be especially bad if this while trying to recover from the problem. This might be especially
happens because packets are dropped because of the congested network. bad if this happens because packets are dropped because of the
If MOBIKE clients will try simultaneously test all IP-addresses congested network. If MOBIKE clients simultaneously try to test all
sending lots of packets to the net, because they lost one packet possible address pairs by executing connectivity tests then the
because of the congestion, it simply make problem worse. congestion problem only gets worse.
Also note, that IKE dead-peer-detection is not sufficient for the Also note, that the IKEv2 dead-peer detection is not sufficient for
return routability check. See Section 7 for more information. the return routability check. See Section 5.6 for more information.
4. Simultaneous Movements (issue #2) 5.3 Simultaneous Movements
We do not need to solve the simultaneous movement recovery problem, MOBIKE does not aim to provide a full mobility solution which allows
as we are not creating full mobility solution (charter forbids that), simultaneous movements. Instead, the MOBIKE working group focuses on
but are instead concentrating on the VPN style scenarios. In the selected scenarios as described in Section 3. Some of the scenarios
scenarios we assume that the one end (SGW) will have fixed set of assume that one peer has a fixed set of addresses (from which some
addresses (from which some subset might be in use), thus it cannot subset might be in use). Thus it cannot move to the address unknown
move to the address not known by the other end. This means that the to the other peer. Situations where both peers move and the movement
solutions how to recover from cases where both ends move and the notifications cannot reach the other peer, is outside the scope of
movement notifications do not reach other ends, is outside the scope the MOBIKE WG. MOBIKE has not being chartered to deal with the
of the MOBIKE WG. rendezvous problem, or with the introduction of any new entities in
the network.
Note, that if we use only one address per each end, instead of Note, that if only a single address is stored in the peer address set
address list, we might end up in the case where it seems that both (instead of an address list) we might end up in the case where it
ends changed their addresses at the same time. This is something that seems that both peers changed their addresses at the same time. This
the protocol must take care of. is something that the protocol must deal with.
There is three different cases here: Three cases can be differentiated:
Two mobile nodes getting a new address at the same time, and then
being unable to tell each other where they are. This problem is
called the rendevouz problem, and is traditionally solved using
home agents (Mobile IPv6) or forwarding agents (Host Identity
Protocol). Essentially, solving this problem requires the
existence of a stable infrastructure node somewhere. Example:
roaming laptop to another roaming laptop, no SGW involved.
Simultaneous changes to addresses such that at least one of the
new addresses was known by both peers before the change occurred.
The primary problem in first case was not knowing the new
addresses beforehand. Here we know the address so there is no
problem. Example 1: two SGWs failover to another path. Example 2:
roaming laptop gets a new address at the same time as its SGW's
primary interface goes down.
No simultaneous changes at all.
5. Interaction with NAT-T (issue #3) o Two mobile nodes obtain a new address at the same time, and then
being unable to tell each other where they are (in a
break-before-make scenario). This problem is called the
rendezvous problem, and is traditionally solved by introducing
another third entity, for example, the home agents (in Mobile
IPv4/IPv6) or forwarding agents (in Host Identity Protocol).
Essentially, solving this problem requires the existence of a
stable infrastructure node somewhere.
In some way the MOBIKE and NAT-T are not compatible. The NAT-T tries o Simultaneous changes to addresses such that at least one of the
to work regardless of the IP-addresses, i.e. regardless whether new addresses is known to the other peer before the change
someone modifies its IP-address or not. One of the goals in the occurred.
MOBIKE is to AUTHENTICATE the change of the IP-address, i.e. when the
IP-address changes we want to verify that this change is actually o No simultaneous changes at all.
legitimate change done by the other end, not something done by the
attacker along the path. 5.4 NAT Traversal
IKEv2 has support of legacy NAT traversal built-in. This feature is
known as NAT-T which allows IKEv2 to work even if a NAT along the
path between the Initiator and the Responder modified the source and
possibly the destination IP address. With NAPT even the transport
protocol identifiers are modified (which then requires UDP
encapsulation for subsequent IPsec protected data traffic).
Therefore, the required IP address information is taken from the IP
header (if a NAT was detected who rewrote IP header information)
rather than from the protected payload. This problem is not new and
was discovered during the design of mobility protocol where the only
valuable information is IP address information.
One of the goals in the MOBIKE protocol is to securely exchange one
or more addresses of the peer address set and to securely set the
primary address. If not other protocol is used to securely retrieve
the IP address and port information allocated by the NAT then it is
not possible to tackle all attacks against MOBIKE. Various solution
approaches have been presented:
o Securely retrieving IP address and port information allocated by
the NAT using a protocol different from MOBIKE. This approach is
outside the scope of the MOBIKE working group since other working
groups, such as MIDCOM and NSIS, already deal with this problem.
The MOBIKE protocol can benefit from the interaction with these
protocols.
o Design a protocol in such a way that NAT boxes are able to inspect
(or even participate) in the protocol exchange. This approach was
taken with HIP but is not an option for IKEv2 and MOBIKE.
o Disable NAT-T support by indicating the desire never to use
information from the (unauthenticated) header. While this
approach prevents some problems it effectively disallows the
protocol to work in certain environments.
There is no way to distinguish the cases where there is NAT along the There is no way to distinguish the cases where there is NAT along the
path which modifies the packets or if it is an attacker doing that. path which modifies the header information in packets or whether an
If NAT is detected in the IKE SA creation, that should automatically adversary mounts an attack. If NAT is detected in the IKE SA
disable the MOBIKE extensions and use NAT-T. creation, that should automatically disable the MOBIKE extensions and
use NAT-T.
If MOBIKE is enabled for the IKE SA (i.e. no NAT along the path when A design question is whether NAT detection capabilities should be
the IKE SA was created), then if NAT is later added then MOBIKE can enabled only during the initial exchange or even at subsequent
detect that, but it cannot securely do anything for the issue. We can message exchanges. If MOBIKE is executed with no NAT along the path
disable MOBIKE extensions completely at that time and move to use when the IKE SA was created, then a NAT which appears after moving to
NAT-T, but as we loose all the security offered by the MOBIKE, it a new network might cannot be dealt with if NAT detection is enabled
might be better to rekey the IKE SA (if policy allows that) so that only during the initial exchange. Hence, it might be desirable to
we do not use MOBIKE at all and start using normal NAT-T. also support scenario where a MOBIKE peer moves from a network which
does not deploy a NAT to a network which uses a private address
space.
If we start using NAT-T, then there is no defined way to detect that A NAT prevention mechanism can be used to make sure that no adversary
we moved away from the inside of the NAT. Thus we need to modify can interact with the protocol if no NAT is expected between the
NAT-T and add that kind of detection capability there, if we want to Initiator and the Responder.
start using MOBIKE at that point.
As a summary, if the policy accepts the risks caused by enabling The support for NAT traversal is certainly one of the most important
NAT-T, then it can switch to NAT-T when it detects we are behind NAT. design decisions with an impact on other protocol aspects.
Easiest way to do it is to create new IKE SA, as NAT-T can only be
enabled by the initial IKE SA creation, and it cannot be enabled by
rekeys. Moving back from NAT-T to MOBIKE is harder as it requires
changes to NAT-T. On the other hand keeping NAT-T enabled simply adds
few bytes of extra overhead.
If we define some additions and extensions to NAT-T we can probably 5.5 Changing addresses or changing the paths
make it work better with MOBIKE, but there are quite a lot open
issues. One way of seeing this is, that we have few other parameters
we might want to turn on during the address update, i.e. the NAT-T
parameters. Those include turning on or off keepalives, UDP
encapsulation, or automatic address updating.
6. Changing addresses or changing the paths (issue #10, #14) A design decision is whether it is enough for the MOBIKE protocol to
detect dead address, or does it need to detect also dead paths. Dead
address detection means that we only detect that we cannot get
packets through to that remote address by using the local IP address
given by the local IP-stack (i.e., local address selected normally by
the routing information). Dead path detection means that we need to
try all possible local interfaces/IP addresses for each remote
addresses, i.e., find all possible paths between the hosts and try
them all to see which of them work (or at least find one working
path).
The question here is, if it is enough for the MOBIKE to detect the While performing just an address change is simpler, the existence of
dead-address, or do it need to detect also dead-paths. Dead-address locally operational addresses are not, however, a guarantee that
detection means that we only detect that we cannot get packets communications can be established with the peer. A failure in the
through to that remote address by using the local IP-address given by routing infrastructure can prevent the sent packets from reaching
the local IP-stack (i.e. local address selected normally by the their destination. Or a failure of an interface on one side can be
routing information). Dead-path detection means that we need to try related to the failure of an interface on the other side, making it
all possible local interfaces/IP-addresses for each remote addresses, necessary to change more than one address at a time.
i.e. find all possible paths between the hosts and try them all to
see which of them work (or at least find one working path).
Doing the dead-address detection is simpler, and there is less probe 5.6 Return Routability Tests
packets to be sent, thus it does not cause that much stress to the
network. It also is enough for the scenarios where the connection
problems are local (i.e. interfaces going down, WLAN access
disappearing etc). It does not help if some router somewhere along
the path breaks down, in which case rerouting the packets along
another path might get around that broken router. The question is,
whether rerouting around that problem inside the core network is a
problem that MOBIKE needs to solve.
7. How and When to do Return Routability Checks (issue #6, #12, #15) Setting a new preferred address which is subsequently used for
communication is associated with an authorization decision: Is a peer
allowed to use this address? Does this peer own this address? Two
mechanisms have been proposed in the past to allow a peer to compute
the answer to this question:
One of the decisions that needs to be done is when to do return o The addresses a peer is using is part of a certificate. [RFC3554]
routability checks. The simple approach is to do it always. Another introduced this approach. If the other peer is, for example, a
option is to do it every time new IP-address is taken in to use. The security gateway with a limited set of fixed IP addresses, then
basic format of the return routability check could be similar than the security gateway may have a certificate with all the IP
dead-peer-detection, but the problem is that if that fails then the addresses in the certificate.
IKEv2 specification requires the IKE SA to be deleted. Because of
this we might need to do some kind of other exchange.
If the other end is SGW with limited set of fixed IP-addresses, then o A return routability check is performed before the address is used
the SGW may have a certificate having all the IP-addresses in the to ensure that the peer is reachable at the indicated address.
certificate. If the certificate includes all the IP-addresses, it is
no point to do weaker return routability check, the data in the
certificate is already properly authenticated after the IKE SA is
created, so the peer might simply use that and ignore return
routability checks for the addresses of the SGW.
Another option is to use draft-dupont-mipv6-3bombing Without performing an authorization decision a malicious peer can
[I.D.dupont-mipv6-3bombing] approach: do it only if you had to send redirect traffic towards a third party or a blackhole.
the update from some other address than indicated preferred address.
Final option would simply not to do return routability checks at all. An IP address should not be used as a primary address without
If we use indirect change notifications then we only move to the new computing the authorization decision. If the addresses are part of
IP address after successful dead-peer-detection on the new address, the certificate then it is not necessary execute the weaker return
which is already return routability check. In the direct change routability test. If multiple addresses are communicated to another
notifications the authenticated peer have given out authenticated peer as part of the peer address set then some of these addresses
IP-address, thus we could simply trust the other end. There is no way might be already verified even if the primary address is still
external attacker can cause any attacks, but we are not protected by operational.
the internal attacker, i.e. the authenticated peer forwarding its
traffic to the new address. On the other hand we do know the identity
of the peer in that case.
There are some attacks which can be launched unless the return Another option is to use the [I-D.dupont-mipv6-3bombing] approach
routability checks include some kind of nonce (issue #15). In this which suggests to do a return routability test only if you have to
attack the valid end points sends address update notification for the send an address update from some other address than the indicated
third party, trying to get all the traffic to be sent there, causing preferred address.
denial of service attack. If the return routability checks does not
contain any cookies or other random information not known by the
other end, then that valid node could reply to the return routability
checks even when it cannot see the request. This might cause the
other end to turn the traffic to there, even when the real original
recipient isn't at that address.
The IKEv2 NAT-T does not do any return routability checks. It simply Finally it would be possible not to execute return routability checks
uses the last address used by the other end, as and address where to at all. In case of indirect change notifications then we only move
send return packets back. The attacker can change those IP-addresses, to the new preferred address after successful dead-peer detection on
and can cause the return packets to be sent to wrong IP-address. The the new address, which is already a return routability check. With a
situation is fixed immediately when the attacker no longer changes direct notifications the authenticated peer may have provided an
the packets, and the first packet with real IP-address reaches the authenticated IP address, thus we could simply trust the other end.
other end. In IKEv2 NAT-T the valid client can cause third party There is no way external attacker can cause any attacks, but we are
bombing by redirecting all the traffic pointed to him to third party. not protected by the internal attacker, i.e. the authenticated peer
As the MOBIKE tries to provide better security than IKEv2 NAT-T the forwarding its traffic to the new address. On the other hand we do
MOBIKE protocol should protect against those attacks. know the identity of the peer in that case.
As such, it sees that there it is also a policy issue when to
schedule a return routability test.
The basic format of the return routability check could be similar
than dead-peer detection, but the problem is that if that fails then
the IKEv2 specification requires the IKE SA to be deleted. Because
of this we might need to do some kind of other exchange.
There are potential attacks if a return routability checks include
some kind of nonce. In this attack the valid end points sends
address update notification for the third party, trying to get all
the traffic to be sent there, causing denial of service attack. If
the return routability checks does not contain any cookies or other
random information not known by the other end, then that valid node
could reply to the return routability checks even when it cannot see
the request. This might cause the other end to turn the traffic to
there, even when the true original recipient cannot be reached at
this address.
The IKEv2 NAT-T mechanism does not perform any return routability
checks. It simply uses the last seen source IP address used by the
other peer where to send response packets. An adversary can change
those IP addresses, and can cause the response packets to be sent to
wrong IP address. The situation is self-fixing when the adversary is
no longer able to modify packets and the first packet with true IP
address reaches the other peer. In a certain sense mobility handling
makes this attack difficult for an adversary since it needs to be
located somewhere along the path where the individual paths ({CoA1,
..., CoAn} towards the destination IP address) have a shared path or
if the adversary is located near the MOBIKE client then it needs to
follow the users mobility patterns. With IKEv2 NAT-T the genuine
client can cause third party bombing by redirecting all the traffic
pointed to him to third party. As the MOBIKE protocol tries to
provide equal or better security than IKEv2 NAT-T the MOBIKE protocol
should protect against these attacks.
There might be also return routability information available from the There might be also return routability information available from the
other parts of the system too (IP-stack, Mobile IP or so), but the other parts of the system too (as shown in Figure 3), but the checks
checks done might be different (issue #12). There are multiple done might have a different quality. There are multiple levels for
different levels for the return routability checks: return routability checks:
o None, no tests o None, no tests
o A party willing to answer is on the path to the claimed address. o A party willing to answer is on the path to the claimed address.
This is the basic form of return routability test. This is the basic form of return routability test.
o There is an answer from the tested address, and that answer was o There is an answer from the tested address, and that answer was
authenticated (including the address) to be from our peer. authenticated (including the address) to be from our peer.
o There was an authenticated answer from the peer, but it is not o There was an authenticated answer from the peer, but it is not
guaranteed to be from the tested address or path to it (because guaranteed to be from the tested address or path to it (because
the peer can construct a response without seeing the request). the peer can construct a response without seeing the request).
The basic return routability checks do not protect against 3rd party The basic return routability checks do not protect against 3rd party
bombing, if the attacker is along the path, as the attacker can bombing, if the attacker is along the path, as the attacker can
forward the return routability checks to the real peer (even if those forward the return routability checks to the real peer (even if those
packets are cryptographically authenticated) packets are cryptographically authenticated).
If the address to be tested is inside the packet too, then attacker If the address to be tested is inside the MOBIKE packet too, then the
cannot forward packets, thus it prevents 3rd party bombings. adversary cannot forward packets, thus it prevents 3rd party
bombings.
If the reply packet can be constructed without seeing the request If the reply packet can be constructed without seeing the request
packet (i.e. there is no nonce or similar), then the real peer can packet (for example, if there is no nonce, challenge or similar
cause 3rd party bombing, by replying to those requests without seeing mechanism to show liveness), then the genuine peer can cause 3rd
them at all. party bombing, by replying to those requests without seeing them at
all.
Other levels might only return information saying that yes, there is Other levels might only provide information that there is someone at
someone there in the IP-address which replied to my request. Or say the IP address which replied to the request. There might not be an
that I sent request to IP-address and got reply back, but I am not indication that the reply was freshly generated or repeated, or the
sure whether that reply was freshly generated or repeated, or sent request might have been transmitted from a different source address.
from different address. The MOBIKE requirements for the return
routability checks could be to verify that there is same
(cryptographically) authenticated node in the other end and it can
now receive packets from the IP-address it claims to have.
MOBIKE might also want to export the information it has done the Requirements for a MOBIKE protocol for the return routability test
return routability checks to the other modules, like Mobile IP, so might be able to verify that there is same (cryptographically)
Mobile IP does not need to do return routability checks again, if it authenticated node at the other peer and it can now receive packets
is satisfied with the level of checks done by the MOBIKE. from the IP address it claims to have.
8. Scope of SA changes (issue #8) 5.7 Employing MOBIKE results in other protocols
The basic question is that how the IPsec SAs are changed to use new If MOBIKE has learned about new locations or verified the validity of
address. One option is that when the IKE SA address is changed then an address through a return routability test, can this information be
automatically all IPsec SAs associated with it are moved along with useful for other protocols?
it to new address. Another option is to have separate exchange to
move the IPsec SAs separately.
If we want to update each IPsec SA separately, we probably need more When considering the basic MOBIKE VPN scenario, the answer is no.
efficient format than notification payload, as it can only store one Transport and application layer protocols running inside the VPN
SPI per payload. I.e. we want separate payload which have list of tunnel have no consideration about the outer addresses or their
IPsec SA SPIs and new address set for them. If we have lots of IPsec status.
SAs, those payloads can be quite large unless we support ranges in
SPIs or at least have some kind of notation of move those SAs not Similarly, IP layer tunnel termination at a gateway rather than a
moved separately (i.e. rest of the SAs indication). The host endpoint limits the benefits for "other protocols" that could be
implementations need also keep state of IP-addresses per IPsec SA, informed -- all application protocols at the other side are running
not per IKE SA. If we automatically move all IPsec SAs when the IKE in a node that is unaware of IPsec, IKE, or MOBIKE.
SA moves, then we only need to keep track which IKE SA was used to
create the IPsec SA, and fetch the IP-addresses from that (Note, that However, it is conceivable that future uses or extensions of the
IKEv2 [I-D.ietf-ipsec-ikev2] already requires implementations to keep MOBIKE protocol make such information distribution useful. For
track which IPsec SAs are created using which IKE SA). instance, if transport mode MOBIKE and SCTP were made to work
together, it would likely be useful for SCTP to learn about the new
addresses at the same time as MOBIKE learns them. Similarly, various
IP layer mechanisms might make use of the fact that a return
routability test of a specific type has already been performed.
However, in all of these cases careful consideration should be
applied. This consideration should answer to questions such as
whether other alternative sources exist for the information, whether
dependencies are created between parts that prior to this had no
dependencies, and what the impacts in terms of number of messages or
latency are.
[I-D.crocker-celp] discussed the use of common locator information
pools in IPv6 multihoming context; it assumed that both transport and
IP layer solutions would be used for providing multihoming, and that
it would be beneficial for different protocols to coordinate their
results in some manner, for instance by sharing experienced
throughput information for address pairs. This may apply to MOBIKE
as well, assuming it co-exists with non-IPsec protocols that are
faced with the same multiaddressing choices.
Nevertheless, all of this is outside the scope of current MOBIKE base
protocol design and may be addressed in future work.
5.8 Scope of SA changes
Most sections of this document discuss design considers for updating
and maintaining addresses for the IKE-SA. However, changing the
preferred address also has an impact for IPsec SAs. The outer tunnel
header addresses (source IP and destination IP addresses) need to be
modified according to the preferred address pair to allow the IPsec
protected data traffic to travel along the same path as the MOBIKE
packets (if we only consider the IP header information).
The basic question is that how the IPsec SAs are changed to use the
new address pair (the same address pair as the MOBIKE signaling
traffic -- the preferred address pair). One option is that when the
IKE SA address is changed then automatically all IPsec SAs associated
with it are moved along with it to new address pair. Another option
is to have separate exchange to move the IPsec SAs separately.
If IPsec SAs should be updated separately then a more efficient
format than notification payload is needed. A notification payload
can only store one SPI per payload. A separate payload which would
have list of IPsec SA SPIs and new preferred address. If there are
large number of IPsec SAs, those payloads can be quite large unless
ranges of SPI values are supported. If we automatically move all
IPsec SAs when the IKE SA moves, then we only need to keep track
which IKE SA was used to create the IPsec SA, and fetch the IP
addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires
implementations to keep track which IPsec SAs are created using which
IKE SA.
If we do allow each IPsec SAs address sets to be updated separately, If we do allow each IPsec SAs address sets to be updated separately,
then we can support scenarios, where the machine have fast and/or then we can support scenarios, where the machine has fast and/or
cheap connection and slow and/or expensive connection, and it wants cheap connections and slow and/or expensive connections, and it wants
to allow moving some of the SAs to the slower and/or more expensive to allow moving some of the SAs to the slower and/or more expensive
connection, and forbid some SAs to move. I.e. never move the news connection, and prevents to move the news video stream from the WLAN
video stream from the WLAN to the GPRS link. 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, i.e. update, then we can create separate IKE SAs for this scenario, e.g.,
we create one IKE SA which have both links as endpoints, and it is we create one IKE SA which have both links as endpoints, and it is
used for important traffic, and then we create another IKE SA which used for important traffic, and then we create another IKE SA which
have only the fast and/or cheap connection, which is then used for have only the fast and/or cheap connection, which is then used for
that kind of bulk traffic. that kind of bulk traffic.
9. Zero Address Set (issue #5) 5.9 Zero Address Set
One of the features which might be useful would be for the peer to One of the features which might be useful would be for the peer to
announce the other end that it will now disconnect for some time, announce the other end that it will now disconnect for some time,
i.e. it will not be reachable at all. For instance, a laptop might go i.e., it will not be reachable at all. For instance, a laptop might
to suspend mode. In this case the peer could send address go to suspend mode. In this case the peer could send address
notification with zero new addresses, which means that it will not notification with zero new addresses, which means that it will not
have any valid addresses anymore. The responder of that kind of have any valid addresses anymore. The responder of that kind of
notification would then acknowledge that, and could then temporarily notification would then acknowledge that, and could then temporarily
disable all SAs. If any of the SAs gets any packets they are simply disable all SAs. If any of the SAs gets any packets they are simply
dropped. This could also include some kind of ACK spoofing to keep dropped. This could also include some kind of ACK spoofing to keep
the TCP/IP sessions alive (or simply set the TCP/IP keepalives and the TCP/IP sessions alive (or simply set the TCP/IP keepalives and
timeouts large enough not to cause problems), or it could simply be timeouts large enough not to cause problems), or it could simply be
left to the applications, i.e. allow TCP/IP sessions to notice the left to the applications, e.g., allow TCP/IP sessions to notice the
link is broken. link is broken.
The local policy could then decide how long the peer would allow The local policy could then decide how long the peer would allow
other peers to be disconnected, i.e. whether this is only allowed for other peers to be disconnected, e.g., whether this is only allowed
few minutes, or do they allow users to disconnect Friday evening and for few minutes, or do they allow users to disconnect Friday evening
reconnect Monday morning (consuming resources during weekend too, but and reconnect Monday morning (consuming resources during weekend too,
on the other hand not more than is normally used during week days, but on the other hand not more than is normally used during week
but we do not need lots of extra resources on the Monday morning to days, but we do not need lots of extra resources on the Monday
support all those people connecting back to network). morning to support all those people connecting back to network).
10. What modes we support (issue #7) From a technical point of view this features addresses two aspects:
The charter mostly talks about VPN style usage, and all scenarios are o There is no need to transmit IPsec data traffic. IPsec protected
using tunnel mode, so that is where this document mostly data needs to be dropped which saves bandwidth. This does not
concentrates. For transport mode to be used we first need to define provide a functional benefit i.e, nothing breaks if this feature
the scenarios where it is needed. XXX someone needs to write more is not provided.
text here.
11. Message representation o MOBIKE signaling messages are also ignored and need to be
suspended. The IKE-SA must not be deleted and the suspend
functionality (realized with the zero address set) might require
the IKE-SA to be tagged with a lifetime value since the IKE-SA
will not be kept in memory an arbitrary amount of time. Note that
the IKE-SA has no lifetime associated with it. In order to
prevent the IKE-SA to be deleted the dead-peer detection mechanism
needs to be suspended as well.
One of the basic design choices that is needed for the MOBIKE is the Due to the enhanced complexity of this extension a first version of
format of the messages. The IKEv2 offers some formatting alternatives the MOBIKE protocol will not provide this feature.
for the protocol. The basic IP-address change notifications can be
sent either via informational exchange already specified in the
IKEv2, or we could also have our own MOBIKE specific exchange. Using
informational exchange has the main advantage that it is already
specified in the IKEv2 and the implementations should already have
code for those.
One advantage of creation of the new exchange would be that we could 5.10 IPsec Tunnel or Transport Mode
incorporate the return routability checks to the exchange in this
state (i.e. create 3-4 packet exchange). The problem here is that we Current MOBIKE design is focused only on the VPN type usage and
might need to do the return routability checks for each IP-address tunnel mode. Transport mode behaviour would also be useful, but will
separately, thus we might not be able to do it in this phase. be discussed in future documents.
5.11 Message Representation
The basic IP address change notifications can be sent either via an
informational exchange already specified in the IKEv2, or via a
MOBIKE specific message exchange. Using informational exchange has
the main advantage that it is already specified in the IKEv2 and
implementations incorporated the functionality already.
Another question is the basic format of the address update Another question is the basic format of the address update
notifications. The address update notifications can include multiple notifications. The address update notifications can include multiple
addresses, which some can be IPv4 and some IPv6 addresses. The number addresses, which some can be IPv4 and some IPv6 addresses. The
of addresses is most likely going to be quite small (less than 10). number of addresses is most likely going to be quite small (less than
The format might need to give out senders preference of the use of 10). The format might need to indicate a preference value for each
the addresses, i.e. the sender will tell this is the preferred address Furthermore, one of the addresses in the peer address set
address to be used. The format could either contain the preference must be labeled as the preferred address. The format could either
number, giving out the relative order of the addresses, or it could contain the preference number, giving out the relative order of the
simply be ordered list of IP-addresses in the order of the most addresses, or it could simply be ordered list of IP addresses in the
preferred first. Benefits of the ordered list is, that then we do not order of the most preferred first. While two addresses can have the
need to define what happens if the preference numbers are identical, same preference value an ordered list avoids this problem.
and we do not need to reserve space for the numbers. Normally we do
not need any priority values, we simply need an ordered list.
Even when the load-balancing inside the one connection is outside the Even if load balancing is currently outside the scope of MOBIKE,
scope of the MOBIKE, there might be future work to include that. The there might be future work to include this feature. The format
format selected needs to be flexible enough to allow addition of some selected needs to be flexible enough to include additional
kind of extra information for the load-balancing features in the information (e.g., to enable load balancing). This might be
future. This might be something like one reserved field, which can something like one reserved field, which can later be used to store
later be used to store that information. As there is other potential additional information. As there is other potential information
information which might have to be tied to the address in the future, which might have to be tied to the address in the future, a reserved
a reserved field seems like a prudent design in any case. field seems like a prudent design in any case.
There are two basic formats for putting IP-address list in to the There are two basic formats for putting IP address list in to the
exchange, we can include each IP-address as separate payload (where exchange, we can include each IP address as separate payload (where
the payload order indicates the preference value, or the payload the payload order indicates the preference value, or the payload
itself might include the preference value), or we can put the itself might include the preference value), or we can put the IP
IP-address list as one payload to the exchange, and that one payload address list as one payload to the exchange, and that one payload
will then have internal format which includes the list of will then have internal format which includes the list of IP
IP-addresses. addresses.
Having multiple payloads each having one IP-address makes the Having multiple payloads each having one IP address makes the
protocol probably easier to parse, as we can already use the normal protocol probably easier to parse, as we can already use the normal
IKEv2 payload parsing procedures to get the list out. It also offers IKEv2 payload parsing procedures to get the list out. It also offers
easy way for the extensions, as the payload probably contains only easy way for the extensions, as the payload probably contains only
the type of the IP-address (or the type is encoded to the payload the type of the IP address (or the type is encoded to the payload
type), and the IP-address itself, and as each payload already has type), and the IP address itself, and as each payload already has
length associated to it, we can detect if there is any extra data length associated to it, we can detect if there is any extra data
after the IP-address. Some implementations might have problems after the IP address. Some implementations might have problems
parsing too long list of IKEv2 payloads, but if the sender sends them parsing too long list of IKEv2 payloads, but if the sender sends them
in the most preferred first, the other end can simply only take n in the most preferred first, the other end can simply only take n
first addresses and use them. It might loose connection in some cases first addresses and use them.
if all the n first address are not in use anymore, and the other end
hasn't sent new list, but in most cases everything will still work.
Having all IP-addresses in one big payload having MOBIKE specified Having all IP addresses in one big MOBIKE specified internal format
internal format, provides more compact encoding, and keeps the MOBIKE provides more compact encoding, and keeps the MOBIKE implementation
implementation more concentrated to one module. more concentrated to one module.
The next choice is which type of payloads to use. IKEv2 already The next choice is which type of payloads to use. IKEv2 already
specifies a notify payload, which could be used for that. It includes specifies a notify payload. It includes some extra fields (SPI size,
some extra fields (SPI size, SPI, protocol etc), which gives 4 bytes SPI, protocol etc), which gives 4 bytes of the extra overhead, and
of the extra overhead, and there is the notify data field, which there is the notify data field, which could include the MOBIKE
could include the MOBIKE specific data. specific data.
Another option would be to have our own payload type, which then Another option would be to have a custom payload type, which then
include the information needed for the MOBIKE protocol. includes the information needed for the MOBIKE protocol.
The basic protocol is most likely going to be something where we send MOBIKE might send the full peer address list once one of the IP
list of all IP-addresses every time the list changes (either addresses changes (either addresses are added, removed, the order
addresses are added, removed, or the preferred order changes). changes or the preferred address is updated) or an incremental
Another option is that we send some kind of incremental updates to update. Sending incremental updates provides more compact packets
the IP-address list. Sending incremental updates provides more (meaning we can support more IP addresses), but on the other hand
compact packets (meaning we can support more IP-addresses), but on have more problems in the synchronization and packet reordering
the other hand have more problems in the synchronization and packet cases, i.e., the incremental updates must be processed in order, but
reordering cases i.e. the incremental updates must be processed in for full updates we can simply use the most recent one, and ignore
order, but for full updates we can simply use the most recent one, old ones, even if they arrive after the most recent one (IKEv2
and ignore old ones, even if they arrive after the most recent one packets have message id which is incremented for each packet, thus we
(IKEv2 packets have message id which is incremented for each packet, know the sending order easily).
thus we know the sending order easily).
The address update notification protocol is not restricted to only Note that each peer needs to communicate its peer address set to the
one way, i.e. both ends might have multiple IP-addresses and both other peer.
ends might send address updates. Example of that is when the roaming
laptop connects to the multihoming SGW.
12. Security Considerations 6. Security Considerations
As all the messages are already authenticated by the IKEv2 there is As all the messages are already authenticated by the IKEv2 there is
no problem that any attackers would modify the actual contents of the no problem that any attackers would modify the actual contents of the
packets. The IP addresses in IP header of the packets are not packets. The IP addresses in IP header of the packets are not
authenticated, thus the protocol defined must take care that they are authenticated, thus the protocol defined must take care that they are
only used as an indication that something might be different, they only used as an indication that something might be different, they
should not cause any direct actions. should not cause any direct actions.
Attacker can also spoof ICMP error messages in an effort to confuse Attacker can also spoof ICMP error messages in an effort to confuse
the peers about which addresses are not working. At worst this causes the peers about which addresses are not working. At worst this
denial-of-service and/or the use of non-preferred addresses, so it is causes denial of service and/or the use of non-preferred addresses,
not that serious. so it is not that serious.
One type of attacks which needs to be taken care of the MOBIKE One type of attacks which needs to be taken care of the MOBIKE
protocol is also various flooding attacks. See protocol is also various flooding attacks. See
[I-D.nikander-mobileip-v6-ro-sec] and [Aur02] for more information [I-D.ietf-mip6-ro-sec] and [Aur02] for more information about
about flooding attacks. flooding attacks.
13. IANA Considerations 7. IANA Considerations
No IANA assignments are needed. This document does not introduce any IANA considerations.
14. References 8. Acknowledgments
14.1 Normative references This document is the result of discussions in the MOBIKE working
group. The authors would like to thank Jari Arkko, Pasi Eronen,
Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld,
James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol and Joe Touch
for their discussion input.
9. References
9.1 Normative references
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. draft-ietf-ipsec-ikev2-17 (work in progress), October
2004.
[Kiv04] Kivinen, T., "MOBIKE protocol", [I-D.ietf-ipsec-rfc2401bis]
draft-kivinen-mobike-protocol-00 (work in progress), Kent, S. and K. Seo, "Security Architecture for the
February 2004. Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work
in progress), December 2004.
14.2 Non-normative references 9.2 Informative References
[I-D.nikander-mobileip-v6-ro-sec] [I-D.arkko-multi6dt-failure-detection]
Nikander, P., "Mobile IP version 6 Route Optimization Arkko, J., "Failure Detection and Locator Selection in
Security Design Background", Multi6", draft-arkko-multi6dt-failure-detection-00 (work
draft-nikander-mobileip-v6-ro-sec-02 (work in progress), in progress), October 2004.
December 2003.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[I-D.dupont-mipv6-3bombing] [I-D.dupont-mipv6-3bombing]
Dupont, F., "A note about 3rd party bombing in Mobile Dupont, F., "A note about 3rd party bombing in Mobile
IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), IPv6", draft-dupont-mipv6-3bombing-00 (work in progress),
February 2004. February 2004.
[I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", draft-ietf-mip6-ro-sec-02
(work in progress), October 2004.
[I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with
Host Identity Protocol", draft-ietf-hip-mm-00 (work in
progress), October 2004.
[I-D.crocker-celp]
Crocker, D., "Framework for Common Endpoint Locator
Pools", draft-crocker-celp-00 (work in progress), February
2004.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[I-D.ietf-tsvwg-addip-sctp]
Stewart, R., "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration",
draft-ietf-tsvwg-addip-sctp-09 (work in progress), June
2004.
[I-D.dupont-ikev2-addrmgmt]
Dupont, F., "Address Management for IKE version 2",
draft-dupont-ikev2-addrmgmt-06 (work in progress), October
2004.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart,
"On the Use of Stream Control Transmission Protocol (SCTP)
with IPsec", RFC 3554, July 2003.
[Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet
Location Management", In Proc. 18th Annual Computer Location Management", In Proc. 18th Annual Computer
Security Applications Conference, pages 78-87, Las Vegas, Security Applications Conference, pages 78-87, Las Vegas,
NV USA, December 2002. NV USA, December 2002.
Author's Address Authors' Addresses
Tero Kivinen Tero Kivinen
Safenet, Inc. Safenet, Inc.
Fredrikinkatu 47 Fredrikinkatu 47
HELSINKI FIN-00100 HELSINKI FIN-00100
FI FI
EMail: kivinen@safenet-inc.com EMail: kivinen@safenet-inc.com
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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