draft-ietf-mobike-design-06.txt   draft-ietf-mobike-design-07.txt 
IKEv2 Mobility and Multihoming T. Kivinen IKEv2 Mobility and Multihoming T. Kivinen
(mobike) Safenet, Inc. (mobike) Safenet, Inc.
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: July 9, 2006 Siemens Expires: July 31, 2006 Siemens
January 5, 2006 January 27, 2006
Design of the MOBIKE Protocol Design of the MOBIKE Protocol
draft-ietf-mobike-design-06.txt draft-ietf-mobike-design-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 9, 2006. This Internet-Draft will expire on July 31, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the
Internet Key Exchange Protocol version 2 (IKEv2). These extensions Internet Key Exchange Protocol version 2 (IKEv2). These extensions
should enable an efficient management of IKE and IPsec Security should enable an efficient management of IKE and IPsec Security
skipping to change at page 7, line 7 skipping to change at page 7, line 7
We denote the two peers of a MOBIKE session by peer A and peer B. We denote the two peers of a MOBIKE session by peer A and peer B.
A peer address set is the subset of locally operational addresses A peer address set is the subset of locally operational addresses
of peer A that is sent to peer B. A policy available at peer A of peer A that is sent to peer B. A policy available at peer A
indicates which addresses are included in the peer address set. indicates which addresses are included in the peer address set.
Such a policy might be created either manually or automatically Such a policy might be created either manually or automatically
through interaction with other mechanisms that indicate new through interaction with other mechanisms that indicate new
available addresses. available addresses.
Bidirectional address pair Bidirectional address pair
The address pair, where traffic can be sent to the both The address pair, where traffic can be sent to both directions,
directions, simply by reversing the IP addresses. Note, that the simply by reversing the IP addresses. Note, that the path of the
path of the packets going to each direction might be different. packets going to each direction might be different.
Unidirectional address pair Unidirectional address pair
The address pair, where traffic can only be sent in one direction, The address pair, where traffic can only be sent in one direction,
and reversing the IP addresses and sending reply back does not and reversing the IP addresses and sending reply back does not
work. work.
For mobility related terminology (e.g., Make-before-break or Break- For mobility related terminology (e.g., Make-before-break or Break-
before-make) see [RFC3753]. before-make) see [RFC3753].
skipping to change at page 11, line 25 skipping to change at page 11, line 25
The MOBIKE protocol is not trying to be a full mobility protocol; The MOBIKE protocol is not trying to be a full mobility protocol;
there is no support for simultaneous movement or rendezvous there is no support for simultaneous movement or rendezvous
mechanism, and there is no support for route optimization etc. The mechanism, and there is no support for route optimization etc. The
design document focuses on tunnel mode, everything going inside the design document focuses on tunnel mode, everything going inside the
tunnel is unaffected by the changes in the tunnel header IP address, tunnel is unaffected by the changes in the tunnel header IP address,
and this is the mobility feature provided by the MOBIKE, i.e., and this is the mobility feature provided by the MOBIKE, i.e.,
applications running inside the MOBIKE controlled IPsec tunnel might applications running inside the MOBIKE controlled IPsec tunnel might
not detect the movement since their IP addresses remain constant. not detect the movement since their IP addresses remain constant.
The MOBIKE protocol should be able to perform the following The MOBIKE protocol should be able to perform the following
operations: operations (not all of those are done explictly by the current
protocol):
o Inform the other peer about the peer address set o Inform the other peer about the peer address set
o Inform the other peer about the preferred address o Inform the other peer about the preferred address
o Test connectivity along a path and thereby to detect an outage o Test connectivity along a path and thereby to detect an outage
situation situation
o Change the preferred address o Change the preferred address
o Change the peer address set o Change the peer address set
o Ability to deal with Network Address Translation devices o Ability to deal with Network Address Translation devices
Figure 3 shows an example protocol interaction between a pair of Figure 3 shows an example protocol interaction between a pair of
MOBIKE peers. MOBIKE interacts with the IPsec engine using an MOBIKE peers. MOBIKE interacts with the packet processing module of
internal API (such as those based on PF_KEY [RFC2367]). Using this the IPsec implementation using an internal API (such as those based
API, the MOBIKE module can create entries in the Security Association on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create
(SAD) and Security Policy Databases (SPD). The IPsec engine may also entries in the Security Association (SAD) and Security Policy
interact with IKEv2 and MOBIKE module using this API. The content of Databases (SPD). The packet processing module of the IPsec
the Security Policy and Security Association Databases determines implementation may also interact with IKEv2 and MOBIKE module using
what traffic is protected with IPsec in which fashion. MOBIKE, on this API. The content of the Security Policy and Security
the other hand, receives information from a number of sources that Association Databases determines what traffic is protected with IPsec
may run both in kernel-mode and in user-mode. Information relevant in which fashion. MOBIKE, on the other hand, receives information
for MOBIKE might be stored in a database. The content of such a from a number of sources that may run both in kernel-mode and in
database, along with the occurrence of events of which the MOBIKE user-mode. Information relevant for MOBIKE might be stored in a
process is notified, form the basis on which MOBIKE make decisions database. The content of such a database, along with the occurrence
regarding the set of available addresses, the peer address set, and of events of which the MOBIKE process is notified, form the basis on
the preferred address. Policies may also affect the selection which MOBIKE make decisions regarding the set of available addresses,
process. the peer address set, and the preferred address. Policies may also
affect the selection process.
The peer address set and the preferred address needs to be made The peer address set and the preferred address needs to be made
available to the other peer. In order to address certain failure available to the other peer. In order to address certain failure
cases, MOBIKE should perform connectivity tests between the peers cases, MOBIKE should perform connectivity tests between the peers
(potentially over a number of different paths). Although a number of (potentially over a number of different paths). Although a number of
address pairs may be available for such tests, the most important is address pairs may be available for such tests, the most important is
the pair (source address, destination address) of the current path. the pair (source address, destination address) of the current path.
This is because this pair is selected for sending and receiving This is because this pair is selected for sending and receiving
MOBIKE signaling and IPsec traffic. If a problem along this current MOBIKE signaling and IPsec traffic. If a problem along this current
path is detected (e.g., due to a router failure) it is necessary to path is detected (e.g., due to a router failure) it is necessary to
skipping to change at page 18, line 15 skipping to change at page 18, line 15
In case the responder is behind NAPT, then also finding the port In case the responder is behind NAPT, then also finding the port
numbers used by the responder is outside the scope of MOBIKE. numbers used by the responder is outside the scope of MOBIKE.
5.2.5. NAT Prevention 5.2.5. NAT Prevention
One new feature created by MOBIKE is NAT prevention, i.e. if we One new feature created by MOBIKE is NAT prevention, i.e. if we
detect NAT between the peers, we do not allow that address pair to be detect NAT between the peers, we do not allow that address pair to be
used. This can be used to protect IP addresses in cases where it is used. This can be used to protect IP addresses in cases where it is
known by the configuration that there is no NAT between the nodes known by the configuration that there is no NAT between the nodes
(for example IPv6, or fixed site-to-site VPN). This gives extra (for example IPv6, or fixed site-to-site VPN). This avoids any
protection against 3rd party bombing attacks (the attacker cannot possibility of on-path attackers modifying addresses in headers.
divert the traffic to some 3rd party). This feature means that we This feature means that we authenticate the IP-address and detect if
authenticate the IP-address and detect if they were changed. As this they were changed. As this is done on purpose to break the
is done on purpose to break the connectivity if NAT is detected, and connectivity if NAT is detected, and decided by the configuration,
decided by the configuration, there is no need to do UNSAF there is no need to do UNSAF processing.
processing.
5.2.6. Suggested Approach 5.2.6. Suggested Approach
The working group decided that MOBIKE uses NAT-T mechanisms from the The working group decided that MOBIKE uses NAT-T mechanisms from the
IKEv2 protocol as much as possible, but decided to change the dynamic IKEv2 protocol as much as possible, but decided to change the dynamic
address update for IKEv2 packets to MUST NOT (it would break path address update (see [RFC4306] section 2.23 second last paragraph) for
testing using IKEv2 packets, see Section 6.2). The working group IKEv2 packets to MUST NOT (it would break path testing using IKEv2
also decided to only send keepalives to the current address pair. packets, see Section 6.2). The working group also decided to only
send keepalives to the current address pair.
5.3. Scope of SA Changes 5.3. Scope of SA Changes
Most sections of this document discuss design considerations for Most sections of this document discuss design considerations for
updating and maintaining addresses in the database entries that updating and maintaining addresses in the database entries that
relate to an IKE SA. However, changing the preferred address also relate to an IKE SA. However, changing the preferred address also
affects the entries of the IPsec SA database. The outer tunnel affects the entries of the IPsec SA database. The outer tunnel
header addresses (source and destination IP addresses) need to be header addresses (source and destination IP addresses) need to be
modified according to the current path to allow the IPsec protected modified according to the current path to allow the IPsec protected
data traffic to travel along the same path as the MOBIKE packets. If data traffic to travel along the same path as the MOBIKE packets. If
 End of changes. 8 change blocks. 
33 lines changed or deleted 35 lines changed or added

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