IPSECME Working Group D. Migault
Internet-Draft Orange Labs R&D
Intended status: Standards Track Sep 2009
Expires: March 5, 2010
IPsec mobility and multihoming requirements : Problem statement
draft-mglt-ipsec-mm-requirements-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Currently IPsec mobility is the purpose of MOBIKE [RFC4555] which is
the IKEv2 multihoming and mobility extension. More specifically,
MOBIKE mobility support provides the ability to change the outer IP
Migault Expires March 5, 2010 [Page 1]
Internet-Draft IPsec with mobility and multihoming Sep 2009
address of a tunnel mode Security Association. On the other hand
MOBIKE multihoming support provides the ability of a peer to inform
its correspondent that alternate IP addresses may be used if the
current IP address does not work any more. This draft presents
requirements to extend mobility and multihoming facilities. This
includes the use of simultaneous IP addresses as well as other IPsec
mode like transport mode.
Migault Expires March 5, 2010 [Page 2]
Internet-Draft IPsec with mobility and multihoming Sep 2009
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobility Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Move and Re-connect Scenario . . . . . . . . . . . . . . . 6
4.2. Pre-connect and Move Scenario . . . . . . . . . . . . . . 6
5. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 7
5.1. Different Multihoming, Different Layers . . . . . . . . . 7
5.2. Asymmetric Communications . . . . . . . . . . . . . . . . 8
5.3. Multihoming Scenario : Simultaneous IP Addresses . . . . . 9
5.4. Multihoming Scenario : Alternate IP addresses . . . . . . 11
6. The Case of IKEv2 . . . . . . . . . . . . . . . . . . . . . . 11
7. Multihoming for Mobility actions . . . . . . . . . . . . . . . 13
8. Mobility and Multihoming : complementary actions . . . . . . . 13
9. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.4. MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.5. MIPv6 and MOBIKE . . . . . . . . . . . . . . . . . . . . . 20
9.6. SHIM6 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.7. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.8. mtcp . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.9. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Mobility / Multihoming with IKEv2/IPsec mechanisms . . . . . . 23
10.1. Possible Mobility Scenarios . . . . . . . . . . . . . . . 23
10.1.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 23
10.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 24
10.2. Possible Multihoming Scenarios . . . . . . . . . . . . . . 24
10.2.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 24
10.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 25
10.3. MOBIKE and our Scenarios . . . . . . . . . . . . . . . . . 25
10.3.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 25
10.3.2. Requirements . . . . . . . . . . . . . . . . . . . . 26
11. Mobility Rejected by the Responder? . . . . . . . . . . . . . 27
12. Scope and Restrictions . . . . . . . . . . . . . . . . . . . . 28
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
14. Security Considerations . . . . . . . . . . . . . . . . . . . 30
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Migault Expires March 5, 2010 [Page 3]
Internet-Draft IPsec with mobility and multihoming Sep 2009
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
This draft presents the scenarios we consider. For sake of
simplicity, we spitted the scenarios into three different categories
by considering mobility-only scenarios with non multihomed peers,
multihoming-only scenarios without mobility, and then scenarios were
mobility and multihoming are combined together. The latter category
is in fact more a discussion on interaction between mobility and
multihoming.
Secondly, we present a state of the art of different protocols
related to IPsec, mobility and multihoming. This section presents
briefly the protocols, and specific points related either to
mobility, multihoming or IPsec. This section should be considered
more like a key note section then a normative section.
At last, we derive the requirements to fit our scenarios. From the
scenarios section and the state of the art section, we present the
existing mechanisms that best match our scenarios, and figure out
what is required to match them completely. Thus we consider the
mobility scenarios, then the multihoming scenarios, and for each of
them derive requirements. We added a special section with MOBIKE
[RFC4555]. In fact the scenarios of this draft are using the IPsec
transport mode, and MOBIKE [RFC4555] is the IKEv2 [RFC4306] extension
that deals with mobility and multihoming with the tunnel mode. We
point out how MOBIKE is related and what lakes to MOBIKE so that it
matches our scenarios.
We assume the reader is familiar with IPsec [RFC4301], IKEv2
[RFC4306] and with MOBIKE [RFC4555].
3. Terminology
- Mobile Node (MN) : In this draft the Mobile Node is the peer that
performs the mobility action. The Mobile Node does not have to
be understood as in MIPv6.
Migault Expires March 5, 2010 [Page 4]
Internet-Draft IPsec with mobility and multihoming Sep 2009
- Initiator : The Initiator is the peer that initiates the
exchange. It sends a message to the Responder. It is
important to note that if two peers are connected, the
Initiator of one exchange can be the Responder of another
exchange. When a mobility action is performed then the
Initiator is also the Mobile Node.
- Responder : The Responder is the peer receiving a message. The
message is sent from the Initiator.
- Alternate IP Address : The alternate IP address of a peer is the
IP address a peer is not currently using but that might be used
latter. An alternate IP address should used only if the
current IP address does not work anymore.
4. Mobility Scenarios
This section shows mobility scenarios that motivated this draft.
They consider two peers directly connected between each other. The
communication is protected using IPsec with a transport mode -- the
tunnel mode has already be considered in [RFC4555].
Mobility scenarios with transport mode do not provide seamless
mobility -- at least without multihoming considerations -- and so is
not transparent to the application. Thus it should not be used with
any applications. In fact, we consider two peers directly connected
with a single IP address -- i.e. not multihomed -- and their
connection is protected by an IPsec Security Association using the
transport mode. A mobility action requires the Mobile Node (MN) to
change its IP address, to inform the other peer so that the already
negotiation can still be used with the new IP address. This
interrupts the communication and data lost might occurs. This kind
of mobility can then only apply to certain use cases.
Typical examples can be UDP connections protected via IPsec. The
peer decides to move, and packets that do not reach their destination
are lost. The faster the connection is reestablished the fewer
packets we loose. Another example can be TCP connections with very
few packets transfer compared to the connection time. Web surfing is
a good example for this case. Suppose an end user is connected, for
example to a web server, and the communication is protected by IPsec
using the transport mode. The time between sending a request and
receiving the web page is very low compared to the time the end user
spend on the web server to read the data. Furthermore end users are
used to reload a web page when the download is not performed
correctly. When the peer decides to move, if a web page is being
downloaded, the connection is broken, and once mobility is performed,
the user reloads the page. On the other hand, if the peer moves
while the end user reads a web page, than the end user does not even
Migault Expires March 5, 2010 [Page 5]
Internet-Draft IPsec with mobility and multihoming Sep 2009
notice the mobility. Of course this mobility can be used if mobility
actions are not too frequent, and if the peer changes its IP address
every second then it is highly probable the end user will be affected
by the mobility. In other words, walking speed is probably the
considered speed for mobile and non-multihomed peers.
End users connected for example to a ftp server for heavy file
transfer is not a use case that matches the mobile and non multihomed
peer. In that specific case, unless the application deals with
connection interruption, the transfer needs to be restarted each time
a the peer change its IP address.
4.1. Move and Re-connect Scenario
This scenario considers two peers connected via an IPsec Security
Association using transport mode, and using only one IP address. One
peer loses its connectivity, manages to attach on another network, to
get a new IP address, and send inform the other peer the
communication can go on a new IP address. Signaling messages are
sent via the IKEv2 protected channel, since this channel has already
been negotiated. The MN updates its Security Associations before
sending the message to the other peer. When the other peer receives
the message, it checks the new IP address matches the local policies,
the IPsec Security Policies, eventually performs some Return
Routability Check before updating the Security Association Database.
Once the SAD are updated on both peers, the communication can go on.
The previously negotiated IPsec / IKEv2 security parameters remain
the same. Particularly, authentication do not need to be replayed.
In this scenario, the MN has no guarantee that the new IP address
will match either the Security Policies or the local policies of the
peer. If the new IP address is not accepted, a CREATE_CHILD_SA or an
IKE_INIT exchange MAY be performed.
4.2. Pre-connect and Move Scenario
This scenario considers two peers connected via an IPsec Security
Association using transport mode. Each peer only uses one IP
address. Unlike in the previous scenario, the Mobile Node (MN) knows
the IP address it will use before performing the mobility action.
How the MN knows the IP address is beyond the scope of this paper,
and we call it the new IP address as opposed to the current IP
address. The MN checks with the other peer if a mobility action can
be performed with this new IP address. This involves checking the
local policies, the Security Policy Database.
As mentioned in the multihoming section, the MN may eventually,
before moving, informs the other peer that the new IP address is an
Migault Expires March 5, 2010 [Page 6]
Internet-Draft IPsec with mobility and multihoming Sep 2009
alternate IP address. If the MN is multihomed checking the new IP
address can eventually include reachability test with the Return
Routability Check exchange. In this scenario this test cannot be
performed since the MN has only one interface.
The MN moves as described in the previous scenario. It informs the
Responder it has changed its IP address.
Motivation for preparing the mobility action are :
- Helps the MN to choose the next IP address to use : The Responder
can check the IP address matches the local policies and send an
error message if the IP address does not match the local
policies. With an error message, the MN knows that using this
IP address will require to re-negotiate an IPsec Security
Association. If the MN can choose between a set of IP address
then it might choose an IP address that does not require
negotiating a new IPsec Security Association.
- Fasten Mobility action : When the MN moves, it can either send a
message with the old IP address or the new IP address. If the
MN knows the new IP address does not matches local policies of
the Responder, than it might directly initiate an IKEv2
negotiation. If the MN knows the IP address matches the
Responder's local policies, then it might avoid such a
negotiation.
5. Multihoming Scenarios
5.1. Different Multihoming, Different Layers
Multihoming is the ability of a peer to handle with more than one IP
address. It can have different meanings, and this section defines
the different multihoming we consider in this paper. Multihoming
depends on the layer that deals with multihoming. We consider two
layers in this paper the Networks or the Application layers.
Networks Layers are all layers below the application layer.
Multihoming can also consider different strategies. We consider the
use of Simultaneous IP Addresses (SM) as opposed to the use of
Alternate IP Addresses (AM). Alternate IP address SHOULD NOT be used
unless the current IP address does not work anymore.
- Multihomed Application : An application is multihomed if it can
take advantage of multiple IP addresses. If the application
considers SM, then the peer has to deal with multiple IP
addresses, for example by having multiple interfaces. If the
application considers AM, then the peer can be singled homed.
If application deals directly with multihoming, there MUST be a
Migault Expires March 5, 2010 [Page 7]
Internet-Draft IPsec with mobility and multihoming Sep 2009
channel between the two applications that enables one peer to
provide multihoming information to the other peer. This
channel can be established by the application itself, but
application can also decide to use an already existing channel,
or protocol. In fact an application could use the IKEv2
channel to carry multihoming information. This would require
in that case a communication channel between IKEv2 and the
application.
- Multihomed Networks Layer : Multihoming can also be transparent to
the application. SHIM6 [RFC5533] or HIP [RFC4423], [RFC5201]
are protocols that provide an additional layer between the IP
and the application layer. As a result the application only
sees one fix IP address. This IP address might be a non
routable IP address, and application packets can be routed
using different IP addresses. In those cases, the networks
layers deals with multihoming. We say Network(s) to include
the transport layer. In fact it is still not clear which layer
should consider multihoming, and multipath tcp are looking at
the transport layer. So do SCTP. Unless the application
requires a specific multihoming strategy, Multihomed Networks
Layer brings simplicity for application developers. On the
other hand the application completely relies on the network
layer multihoming management facilities.
- Simultaneous IP addresses Multihoming (SM): We call Simultaneous
IP Addresses Multihoming (SM) the ability to use more than one
IP address. This means that an application sends / receives
data from / to multiple IP addresses. If Multihoming is
considered at the Network layer, then it means a peer receives
/ sends data from two distinct IP addresses. Of course we mean
routable IP addresses! Usual motivations for SM are bandwidth
aggregation, data duplication, traffic engineering, interface
selection...
- Alternate IP addresses Multihoming (AM): We call Alternate IP
Address Multihoming (AM) the ability to have alternate IP
addresses, that is to say IP addresses that SHOULD be used only
if the current IP address is not working anymore. The main
motivation for using the AM mode is to enhance reachability.
Providing multiple alternate IP addresses also enhance
connectivity. If the peer provides more than one IP address,
and the connection is lost, then the other peer can choose the
best IP address.
5.2. Asymmetric Communications
This section considers use cases when peers communication benefit
from multihoming. We need to consider the following definitions :
Migault Expires March 5, 2010 [Page 8]
Internet-Draft IPsec with mobility and multihoming Sep 2009
- A peer is multihomed : if it has multiple IP addresses.
- A peer supports multihoming : if it has all multihoming
facilities, that is to say if has the ability to deal with
different IP address at the "network layer" -- that is to say
network or transport layer.
- An application supports multihoming : if the application handles
multihoming properly. We assume in this paper that when an
application handles with multihoming, network layer multihoming
abilities are skipped.
When an application supports multihoming and one of the host is
multihomed, then the communication can take advantage of multihoming
capabilities. When an application does not support multihoming, to
take advantage of the multihoming, both peers network layer MUST
support multihoming and one of the host MUST be multihomed. For
simplicity, we also assume that applications do not follow the client
server model with BYPASS security policy. The table below sums up
cases when the communication between applications can take advantage
of multihoming.
+------------------------------------------------------------+
| Multihoming supported layer |
+----------------------------+----------------+--------------+
| | Peer A | Peer B | Benefit |
+-----------+---------+------+---------+------+ from |
|Application| Network | Host | Network | Host | multihoming |
+-----------+---------+------+---------+------+--------------+
| X * X * * X |
| X * * * X X |
| X * - * - - |
| - X - X - - |
| - X * X X X |
| - X X X * X |
| - * * - * - |
| - - * * * - |
+------------------------------------------------------------+
When do we benefit from Multihoming
5.3. Multihoming Scenario : Simultaneous IP Addresses
The purpose of using simultaneous IP addresses is to associate a peer
with a pool of IP addresses. Each IP address of the pool can be used
to reach that peer, and peer A can use simultaneous IP addresses
while communication with peer B.
How to choose the IP addresses, how to split the different flows
Migault Expires March 5, 2010 [Page 9]
Internet-Draft IPsec with mobility and multihoming Sep 2009
among the different IP addresses is beyond the scope of the draft.
This draft considers that if peer A decides to use simultaneously
multiple IP addresses, then Security Associations between peer A and
peer B MUST be set so that traffic can use both of those IP
addresses. In the same perspective, if peer A changes its pool of IP
address Security Association between peer A and B MUST be updated.
Thus the use case to consider here, is peer A and peer B are
communicating, and their communication is protected by a transport
mode Security Association. Peer A has multiple interfaces and
proceeds to an attachment procedure on different networks. Once the
attachment procedure is over, peer A has multiple IP addresses, and
wants to benefit from them in its communication with peer B. We
assume that this communication can take advantage of the multihoming
facilities, and that peer A and peer B set their IPsec Security
Associations.
In our case, setting the IPsec Association means that the already
configured SA is being associated multiple IP addresses. Multihoming
action consists then to add or remove IP addresses associated to that
specific Security Association.
When a peer adds an IP address to a given Security Association, it
sends a message to inform the other peer. If the IP address matches
the local and Security Policies, then it is added to specified SA(s).
If the IP address does not match either the local policies or the
Security Policies, or both of them, then an error is returned. One
can notice that there is no need to check that the IP address matches
the local policies or the Security Policies before proceeding to the
multihoming action. Event if the IP address is refused, the
communication is not affected. This was not the case with mobility.
When a peer wants to remove an IP address from an existing SA, it
sends a message to the other peer. The other peer updates its IPsec
databases.
Note : On an IPsec point of view, adding or removing one IP address
from Security Associations does not present any difficulties.
Nevertheless one should consider its consequences on the IP traffic.
Adding an IP address to a given SA do not affect the traffic. On the
other hand removing one IP address from an SA might affect the
communication between the peers. For now, ULP handle multihoming
without any considerations of IPsec -- except for HIP. Once the
transport or the 3.5 layer agrees on removing the IP address, then
IPsec databases can be updated, and the IP address removed from the
SA(s). One possibility is to initiate an IKEv2 exchange. Another
possibility is the ULP proceed directly to the IPsec update without
proceeding the IKEv2 exchange. This would at least avoid one
Migault Expires March 5, 2010 [Page 10]
Internet-Draft IPsec with mobility and multihoming Sep 2009
exchange. There is also another way to consider how the different
layers can interact between each other. We can consider that
mobility and multihoming signalization should be protected and uses
an IKEv2 channel. In that case, the multihoming or mobility action
could be transmitted to the upper layers.
5.4. Multihoming Scenario : Alternate IP addresses
A peer provides an Alternate IP Address to the other peer so that if
the peer is not anymore reachable on one of the currently used IP
addresses, than it might still be reachable on one of the Alternate
IP Address. An Alternate IP Address should not be used in addition
to the currently IP addresses.
Suppose peer B reaches peer A through 2 IP addresses, and peer A has
provided a pool of Alternate IP Addresses to peer B. Peer A happens
not to be reachable on one of the IP address. Peer B can still reach
peer A through one IP address. It is up to peer B's local policies
to define whether or not it should add and use an Alternate IP
Address.
The IPsec layer does not deal directly with reachability statement.
This means that Alternate IP Addresses MUST be provided either to the
application, or the entity that is in charge of the multihoming.
Thus Alternate IP Addresses are useful for IKEv2 as an application or
if IKEv2 is used as a channel to carry multihoming information that
are provided to the Upper Layer Protocol.
The Alternate IP Address mechanism for the IKEv2 application is
described in MOBIKE [RFC4555].
6. The Case of IKEv2
IKEv2 is a special case. On the one hand that is a regular
application and it has its own strategy to handle multihoming. On
the other hand IKEv2 is the application we consider to carry mobility
and multihoming information. Most of the time this information is
expected to affect other applications connections then IKEv2's
connections. In other words, IKEv2 is to be considered as a secure
channel that is used to carry signaling information.
This paper is not especially focused on how IKEv2, as an application
deals with mobility and multihoming. The scope of this paper is to
elaborate on how peers can deal with mobility and multihoming. In
that sense peers need to exchange messages which affect the Security
Associations of their communications. Such messages are exchanged
via the IKEv2 channel. Thus we MUST define what kind of message need
Migault Expires March 5, 2010 [Page 11]
Internet-Draft IPsec with mobility and multihoming Sep 2009
to be exchanged. On the other hand, to be exchanged, we need to
provide mechanisms so that the IKEv2 channel can also survive to
mobility and multihoming actions. In that sense we MUST also specify
how IKEv2 deals with mobility and multihoming.
As an application IKEv2 has specific IPsec security policies.
Packets are not filtered and are sent by the network layer to the
IKEv2 application. IKEv2 binds the message to its IKE_SA thanks to
the SPI. This means that by using different IP addresses, one peer
SHOULD be able to reach the other. The way IKEv2 works allows the
Initiator to use multiple IP addresses, it will receive the answer
from the Responder on the same IP address used for the query.
Nevertheless we cannot say IKEv2 is using the Simultaneous IP Address
Multihoming. IKEv2 works like a server and send the response to
source IP address of the query. In that sense peer A can use various
IP addresses to send IKEv2 message to peer B. But peer B will always
use the IP address associated to the IKE_SA to reach peer B.
For now, IKEv2 even with the MOBIKE extension associates only one IP
address to the IKE_SA. So IKEv2 even with the MOBIKE extension do
not consider Simultaneous IP Addresses Multihoming. If it would,
then it would mean that peer A and peer B could have been associated
a pool of IP address. Each time one of the peer want to reach the
other it would be able to choose one the IP address of the pool.
More specifically, this is different from receiving one packet on one
IP address and sending the response on another IP address.
Considering the previous example, where peer A uses different IP
addresses that are not associated to the IKE_SA. Automatically
adding those IP address to the IKE_SA is a bad idea. In fact it
would note consider that peer A may use IP address it may be not or
it does not want to be reach with. This means that multihoming and
IKEv2 SHOULD NOT be performed automatically.
If one peer changes its IP address, it MUST explicitly inform the
IKEv2 application. MOBIKE [RFC4555] deals with this by sending an
UPDATE_SA_ADDRESSES message, that indicates the IP address of the
sender has changed. This is want mobility occurs, but for now IKEv2
uses only one IP address, so adding or removing an IP address is not
considered.
The way IKEv2 considers multihoming is described in MOBIKE [RFC4555],
and uses the Alternate IP address Multihoming. Alternate IP
addresses are sent from one peer to the other by using
ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS Notify Payloads.
Migault Expires March 5, 2010 [Page 12]
Internet-Draft IPsec with mobility and multihoming Sep 2009
7. Multihoming for Mobility actions
Until now, mobility and multihoming have been treated as different
actions, but one can easily see that multihoming can also be used for
a seamless mobility. This section analyzes when mobility is
performed with multihoming actions.
Multihoming provides the ability to perform a smooth transition from
one IP address to another IP address without interrupting the
traffic. One peer is connected to the other via a pool of IP
addresses. When the peer moves, it can get a new pool of IP
addresses. If the intersection between the two pools is not void,
then a smooth transition can occur by using both multihoming and
eventually mobility mechanisms.
Suppose peer A and peer B are communicating using a pool of IP
addresses. Peer A moves and is attached to other different networks.
It proceeds to a multihoming add action and add all new IP addresses.
When some of the old IP addresses become less reliable -- less power
on the signal for example -- then peer A decides to remove them from
the communication. To perform this action peer A has two
possibilities. It can use a multihoming remove action or proceed to
a mobility action replacing the IP address to be removed by newly
acquired IP address.
On a cross layer point of view, as long as it is coordinated, it does
not make any difference whereas the peer update or remove IP
addresses. This means that ULP MUST be involved. In fact, ULP can
proceed to the IKEv2 exchanges once the multihoming actions has been
performed at the IP and transport layer. On the other hand, IPsec
multihoming signalization can also be forwarded to ULP. In both
cases, proceeding to mobility or multihoming remove message does not
change anything.
On IPsec point of view it is recommended to perform multihoming
remove action. In fact multihoming remove message are expected to be
shorter than mobility message. Mobility action may need to specify
the replacing and the replaced IP address whereas multihoming remove
message only require the IP address to be removed.
8. Mobility and Multihoming : complementary actions
The actions we consider in this paper are Mobility and
Multihoming(s). The previous section exposes how mobility can be
performed with multihoming actions. So why do we need mobility?
This section exposes the differences between mobility and
multihoming.
Migault Expires March 5, 2010 [Page 13]
Internet-Draft IPsec with mobility and multihoming Sep 2009
Some of the different uses between Multihoming and Mobility are
listed below :
- Mobility (or update) action can, in some cases, be replaced by
two Multihoming actions (add followed by a delete). Thus the
main advantage of Mobility is that only one request is required
whereas two are required with the use of Multihoming action.
- Multihoming can be used to perform mobility action.
Considering the IPsec layer only is not the most efficient way,
but nothing can prevent a peer from doing it. On a cross layer
point of view, this might require the peer or the application
supports multihoming.
- Multihoming does not necessarily affect the current
communication. An application can communicate via one pair of
IP address and make independent tests with another pair to
check for example if the new IP address matches the local
policies, or is still reachable. Such tests can be useful
before proceeding to a Mobility action for example. The
Mobility has a best effort approach. It changes the IP
address, if that's possible. If that is not possible, and the
peer has to change its IP address, than the connection is
interrupted. This best effort approach can be mitigated with
the mobility checks.
- If an IPsec connection is broken, Mobility has a specific
mechanism to re-establish this connection. This can happen
when a host has to move, initiates a Mobility action that
fails. It then has to wait to get a new IP address that
enables the Mobility action. Multihoming SHOULD NOT be used
for a Security Association that is not in an active state. In
fact implementations might refuse to add an IP address to an
non-active SA. This is beyond the scope of IPsec management,
since IPsec databases are independent of the transport layer,
and thus does not have any state regarding to the transport
layer. Nevertheless, with Multihoming and Mobility, we believe
mobility / multihoming / IPsec management will occur at the
same level, and thus IPsec will be handled in conjunction of
connections states.
- Mobility is very Initiator-centric. The Initiator informs the
Responder that an IP address is no more in use and another one
MUST be used instead. Multihoming can be used to check an IP
address matches a connection without affecting the current
connection, it can also provide an IP address that MAY be used
by the Responder. The Initiator can send a set of IP addresses
to inform the Responder that in case the current connection
fails. This is the purpose of Alternate IP Addresses. The
Responder MUST only use them when at least one of the current
IP address does not work. The Responder can then choose which
IP address it prefers to use. How the Responder choose the IP
Migault Expires March 5, 2010 [Page 14]
Internet-Draft IPsec with mobility and multihoming Sep 2009
addresses to reach the Initiator is beyond the scope of this
document, but the decision can be based on Responders local
policies as well as information provided by the Initiator on
the IP addresses (like preferences for example.).
9. Related work
This section is not normative and only stands here for clarification.
9.1. IPsec
[RFC4301] describes the IPsec architecture and the three associated
databases : the Security Association Database (SAD), the Security
Policy Database (SPD) et the Peer Authorization Database (PAD).
Section 5.1 describes how outbound packets MUST be processed. For
any outbound packet, a SPD lookup occurs first, then a SPD-Cache
lookup is performed. The SPD-Cache defines whereas the packet should
be BYPASS, DISCARD or PROTECT with the associated index of the SAD.
The packet is then sent to a forwarding function that sends the
packet on the wire or performs a loop back to the protected interface
in the case of nested SA.
Section 5.2 describes how inbound packets are handled. If packet are
not IPsec protected, then a SPD-I lookup is performed and the SPD-I
defines whether the packet should be DISCARD or BYPASS. If the
inbound packet seems to be IPsec protected with protocol AH or ESP,
then an SAD lookup is performed. The ESP/ AH process is done
according to the SAD entry. Once performed, traffic selector MUST
match the packet header's. If no match is found, then the packet
MUST be discarded. After ESP/AH process, checking the traffic
selectors can be performed by a SPD lookup. [RFC4301] mentions on
p.61.
"This processing includes using the packet's SPI, etc., to look
up the SA in the SAD, which forms a cache of the SPD for
inbound packets (except for cases noted in Sections 4.4.2 and
5)."
The SA contains all security material to perform the IPsec
processing. The SPD lookup is required to check that SAD are
coherent with the SPD, that defines the Security Policy of the
system, and can be changed.
SAD lookup is defined in section 4.1 and MUST consider the longest
match. The lookup considers then a match with the SPI, source and
destination address, if no match occurs then a match for SPI and
Migault Expires March 5, 2010 [Page 15]
Internet-Draft IPsec with mobility and multihoming Sep 2009
destination address is considered. If no match occurs, then only the
SPI match is considered.
Section 4.4.3 provides a description and interaction between the PAD
and other IPsec databases. The PAD is involved during the IKE_AUTH
exchange, and provides instruction on which IKE_ID have to be
considered and how IKE_ID should be authenticated. During the
CREATE_CHILD_SA, the peers are authenticated but the PAD provides
instruction on how the SPD should be lookup, that is to say either
considering the IKE_ID or the Traffic Selector as an entry to the
SPD. An interesting thread provides clarification on the PAD
http://www.nabble.com/PAD-and-IKEv2-td13123521.html#a13130457
"The PAD is an artifact of the description of the processing
model, but implementations will need something like it, because
the SPD by itself does not provide enough information to IKE
(one possible implementation might be to augment the SPD with
data that would belong in the PAD in the nominal model). The
PAD does two crucial things: it describes how to authenticate
peers, and it specifies constraints on the traffic selectors
that peers will be allowed in their child SA proposals. --Nico"
"The PAD gives a mapping/relation/binding between certain
pieces of information. It's a local matter how this mapping/
relation/binding is realized. I'm aware of at least one
implementation, where the PAD is implemented as a table/
database. -- Christian"
Section 6 provides a description on how ICMP interacts with IPsec.
When ICMP message are not protected, it is recommended for network
administration purpose to accept and response to them.
In our case, during mobility or multihoming action, a Security
Association is derived from an existing Security Association. We
MUST first check with the PAD is the selector can be used by the ID,
then check what Security Policy of the system requires for this new
IP address associated to this Identity. If the current SA matches
the security policy, then the new SA can be derived. Otherwise, a
new SA MAY be negotiated.
9.2. IKEv2
[RFC4306] defines IKEv2 and [RFC4718] provides clarification mainly
for implementation purposes. When an IKE negotiation is initiated,
it starts with an IKE_INIT exchange. The IKE_INIT exchange aims at
defining a secure channel for IKE negotiation and management of SA.
All actions such as creating a child SA, rekeying an IKE SA, rekeying
child SA is performed through the CREATE_CHILD_SA exchange. The
IKE_INIT exchange is a four packets exchange that can be spitted into
Migault Expires March 5, 2010 [Page 16]
Internet-Draft IPsec with mobility and multihoming Sep 2009
two exchanges : the IKE_SA_INIT that establish an IKE_SA, and the
IKE_AUTH which authenticates the peers. The IKE_AUTH exchange is
also used to create the first CHILD_SA. This is mainly to avoid
another exchange that would introduce more network latency. When an
SA is created either via the IKE_AUTH or CREATE_IKE_SA exchange,
Traffic Selectors (TS) are specified. Such selectors are used to
match the SPD to negotiate and create the SA(s). TS range can be
narrowed by the Responder. The Responder can also accept for the
given SA some subsets of the TSi. There are some situations were two
different SA SHOULD be created rather then a single SA. In that
case, the Responder should send a NOTIFY message with
ADDITIONAL_TS_POSSIBLE. It indicates that additional selectors would
be accepted but would required a separate SA (section 2.9 and section
3.10.1 RFC4306).
COOKIES exchange can be used as a way to test return routability
verification. COOKIES are sent in Notify Payloads. Routing
verification can be done at two different levels. COOKIE can check
the IKE_SA is still valid, and the host is still reachable with the
new IP address. When the peer changes its IP address, a successful
COOKIE exchange means peers are still reachable and the IKE_SA is
still valid. If ICMP should not be used to check reachability,
combination of the two tests can lead to the following conclusion :
peers are not IP reachable, peers have no more valid IKE_SA, peers
are IP reachable with valid IKE_SA channel. Peer can have no more
valid IKE_SA channel when for example, the new network filters IKE
traffic.
CREATE_CHILD_SA exchange is used to rekey an existing SA, rekey an
IKE_SA, rekey a CHILD_SA, or create new CHILD_SA. As specified in
section 2.8 of [RFC4306], CREATE_CHILD_SA exchange is optional and
implementations MUST NOT support this exchange. [RFC4718] describes
the exchanged payloads in the following cases :
We provides the exchanges only for illustration purposes, and
complete description are provided in [RFC4718].
Initiator Responder
----------- -----------
HDR, SK {SA, Ni, [KEi]} -->
<-- HDR, SK {SA, Nr, [KEr]}
Rekeying IKE_SA
Migault Expires March 5, 2010 [Page 17]
Internet-Draft IPsec with mobility and multihoming Sep 2009
Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA), [N+], SA,
Ni, [KEi], TSi, TSr} -->
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
Rekeying CHILD_SA
Initiator Responder
----------- -----------
HDR, SK {[N+], SA, Ni, [KEi],
TSi, TSr} -->
<-- HDR, SK {[N+], SA, Nr,
[KEr], TSi, TSr}
Creating New CHILD_SA
Section 3.11 in [RFC4306] describes a DELETE payload that enables to
delete SA. SA are identified by their SPI.
Reauthentication without generating a new CHILD_SA is described in
[RFC4478].
IKEv2 is the negotiation protocol peers use to setup Security
Associations. This application needs to check coherence between the
IPsec databases. The negotiation protocol is designed in a query /
response manner, and it allows extensions such as MOBIKE [RFC4555].
9.3. MOBIKE
MOBIKE is defined in [RFC4555]. It provides an extension of IKEv2
for mobility and multihoming. MOBIKE considers mobility and
multihoming in one specific scenario : peer is connected to its home
network using a IPsec tunnel mode, the peer is using only one
interface, and the peer changes the address of the tunnel. MOBIKE
also considers some cases of NAT, and it is recommended to run MOBIKE
on port 4555.
The mobility initiative is performed by the client. This is the only
case the peer can try to reach the other peer without being notified
of any mobility action, is when the peers cannot reach each other.
Since only one IP address is used at a time, this active IP address
is always the one in the IKEv2 message header.
The main messages involved in MOBIKE are the MOBIKE_SUPPORTED Notify
message to indicate the peer supports MOBIKE. The
Migault Expires March 5, 2010 [Page 18]
Internet-Draft IPsec with mobility and multihoming Sep 2009
ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify message
enable an Initiator to provide the Responder the IP addresses that he
might be used. The Responder does not have the ability to choose
which IP address is going too be used to reach the Initiator except
if the Initiator cannot be reached with its former IP address. In
that specific case, the Responder can try addresses from the list.
By providing different IP addresses, the Responder has the
possibility to choose which IP address fits best its local policies
to reach the Initiator.
On the other hand, the Initiator can also get a list of IP address
and choose which one best fits its local policies. The mechanisms
used to select the IP addresses are beyond the scope of MOBIKE, but
MOBIKE provides means for the Initiator to redirect the traffic to
another IP address. Mobility is performed with the
UPDATE_SA_ADDRESSES Notify payload. Since only one IP address is
used at a time, the address to be considered is the one inside the
IKEv2 IP header. There is no need to provision the IP address before
performing the mobility. MOBIKE also provides a COOKIE2 Notify
payload that provides return routability check. Whether this check
should be performed or not and when it is defined by local policies.
9.4. MIPv6
MIPv6 is described in [RFC3775] or in [I-D.ietf-mext-rfc3775bis], and
the tunneling technique is specified in [RFC2473]. Its main purpose
is to provide a permanent IP address, which is usually hosted in the
DNS : the Home of Address (HoA). When the Mobile Node (MN) cannot
have its HoA as its active IP address, it uses a Care of Address
(CoA) and sets up a tunnel between the MN and the Home Agent (HA)
with the CoA and the IP address of the HA. This tunnel enables
packets with HoA as IP destination to be routed to the HA and
tunneled to the MN. In return, the HA routes packets with HoA as a
source address to the CN. Mobile IP requires IPsec to secure the
messages between the MN and the HA. IPsec and MIPv6 is specified in
[RFC3776] and in [RFC4877]. The Security Association are negotiated
between the HoA and the HA. Signaling messages with MIPv6 are
identified by the protocol selector. To match the SAD, a special
action MUST be performed for inbound and outbound Binding Update (BU)
packets : lookup in SPD and SAD MUST be done by replacing the CoA by
the HoA, which is mentioned in the routing header extension. This is
to make the SA independent of the CoA. On the other hand the IKE_SA
is negotiated with the CoA. When changing CoA, one can indicate with
the K bit, that the used IP address in the header is a new CoA and
the IKE_SA MUST be updated.
Routing optimization is described in [RFC3775], and enables message
to be directly routed to the CN rather then going through the HA.
Migault Expires March 5, 2010 [Page 19]
Internet-Draft IPsec with mobility and multihoming Sep 2009
9.5. MIPv6 and MOBIKE
The purpose of MIPv6 is to provide the MN a permanent IP address. A
tunnel is created between the MN and the HoA. When the CoA changes,
a Binding Update (BU) with a K bit asks the Tunnel to be updated.
There are different flows to consider : The tunnel between the CoA
and the HA, the MIPv6 signaling channel, and the IPsec signaling
channel. The tunnel between the CoA and the HA might be secured with
IPsec, but this is not required. The MIPv6 signaling channel is
secured with IPsec in transport mode. The associated Security
Associations are based on the HoA and the HA IP address. The IPsec
signaling channel (IKEv2) is secured by the IKE_SA. This is the
value that is updated with the K bit. The new IP address to be used
is provided by the BU message.
MOBIKE uses the UPDATE_SA_ADDRESSES message as an update request.
The new IP address to consider is found in the IKE message. Since
MOBIKE works only in tunnel mode, updating the SA requires changing
not its selector, but one parameter of the SA, that is to say the
outer IP address of the tunnel. The IKE_SA is also the SA that needs
to be updated by changing the traffic selectors. The
UPDATE_SA_ADDRESSES is sent with the new IP address, which means even
with a new unknown IP address the packet will be analyzed.
9.6. SHIM6
To be done.
9.7. SCTP
To be done.
9.8. mtcp
To be done.
9.9. HIP
Host Identity Protocol (HIP) is defined in [RFC4423] and [RFC5533].
The mobility and multihoming extension is described in [RFC5206].
HIP is taking advantage of the separation of Host Identifier (HI) and
the locator (LOC). This means that that the application are
presented a Host Identity Tag (HIT) which is independent from the IP
addresses. HIP requires an ESP Security Association between the
HITs, and [RFC5202] describes how the ESP association is established
and maintained. Security Association are negotiated between HIs or
HITs, packets are sent using IP addresses that are respectively bound
to HITs. [RFC5202] provides two examples on how the ESP processing
Migault Expires March 5, 2010 [Page 20]
Internet-Draft IPsec with mobility and multihoming Sep 2009
of HIP packet can rely on standards compliant IPsec implementations.
- Transport : The processing is represented by figure "ESP
processing : Transport". In that case, the HIP layer maintains
the SAD and SPD with IP addresses that are associated with the
different HITs. The HIP layer proceeds to replacement of HITs
by IP addresses.
- Tunnel : The ESP processing is representing by figure "ESP
processing : Tunnel". The tunnel mode refers to the BEET mode
described in [I-D.nikander-esp-beet-mode]. It works like in
the tunnel mode except that the inner header is removed.
+-------------+ +
| Application | | HIT_s - HIT_d
+-------------+ o
| u
+-------------+ t
| ULP | b HIT_s - HIT_d
+-------------+ o checksum(HIT)
| u
+-------------+ n HIT_s -> IP_s HIP <-> {IP1, IPi, IPn}
| HIP | d HIT_d -> IP_d
+-------------+ |
| p SAD, SPD based on IP addresses
+-------------+ a
| IPsec | c
+-------------+ k ESP processing
| e
+-------------+ t send IP packet
| IP | | on wire
+-------------+ v
ESP processing : Transport
Migault Expires March 5, 2010 [Page 21]
Internet-Draft IPsec with mobility and multihoming Sep 2009
+-------------+ + ^
| Application | | HIT_s - HIT_d |
+-------------+ o |
| u i
+-------------+ t n
| ULP | b HIT_s - HIT_d b
+-------------+ o checksum(HIT) o
| u u
+-------------+ n n
| IPsec | d SAD SPD based on HITs d Check IP, tunnel header
| | | ESP processing | ESP processing
| BEET mode | p HIT_s -> IP_s p IP_s -> HIT_s
| | a HIT_d -> IP_d a IP_d -> HIT_d
| | c c
+-------------+ k k
| e e
+-------------+ t send IP packet t
| IP | | on wire |
+-------------+ v |
ESP processing : Tunnel
HIP provides mobility and multihoming facilities. Security
association are negotiated between HIT, and the HIP layer binds the
HIT with the corresponding IP address table and more specifically
updates the corresponding SAD and SPD.
HIP Provides the transport mode facilities MOBIKE is missing. In
fact a HIP communication involves a IPsec transport mode, and
signaling messages to add or change IP addresses. Nevertheless, the
goal of this paper is to provide IPsec facilities for Multihoming and
mobility so that an host can rely on an IPsec security. This means
that the IPsec layer should support any possible IPsec configuration
due to mobility and multihoming scenarios. More precisely, we expect
that mobility and multihoming can be performed by an IPsec host using
the IPsec tunnel mode or the IPsec transport mode. Furthermore we
would like IPsec to keep the IP granularity. This means that a
multihomed host can have different Security Association depending on
the path. In other words, we are looking for finer granularity then
HIP, and Security Association should still be negotiated by peers on
a per "selector" base. With HIP Security Associations are negotiated
between HITs. Although next versions of HIP might supports those
facilities, we are looking to extend the already existing mobility
and multihoming IKEv2 extension. Developments SHOULD consider
providing a neat API that might be used by other Upper Layer
Protocols
Migault Expires March 5, 2010 [Page 22]
Internet-Draft IPsec with mobility and multihoming Sep 2009
10. Mobility / Multihoming with IKEv2/IPsec mechanisms
This section describes how mobility and multihoming can be considered
with IPsec and IKEv2 mechanisms, how they differ from mechanisms
exposed in the Scenarios description, as well as how those
differences impact mobility and multihoming. In this section we only
consider transport mode between the Initiator and the Responder.
10.1. Possible Mobility Scenarios
10.1.1. Analyze
The move and reconnect scenario consists of the Initiator changing
its IP address, creating the corresponding Security Association, and
deleting the previous one.
Section 1.3, 1.17 and 1.18 of [RFC4306] provide descriptions of
rekeying exchanges. Different configurations include creation of a
new SA, rekeying an already existing SA and rekeying an IKE_SA. In
our case, the Initiator wants to notify the IP address has changed.
We do not rekey an already existing SA since the traffic selectors
are changed. The required action is to create a new CHILD_SA with
the corresponding traffic selectors. The Initiator rekey request
MUST omit the REKEY_SA Notify Payloads that identifies the SA to be
rekeyed. Once the new SA has been created, then the Initiator MUST
delete the old CHILD_SA, which is done thanks to the Delete Notify
Payload described in section 3.11 of [RFC4555].
Current IPsec / IKEv2 do not provide any mechanisms so that the
Initiator can check if an IP address matches SPD and local policies
of the peer. Reachability tests can be provided through the Return
Routability Check mechanism of MOBIKE described in [RFC4555], but the
test requires that the tested IP address is used to send the Notify
Payload. In other words, this mechanism can only be useful if the
Initiator is Multihomed.
As a conclusion :
For a single homed Initiator : The only scenario to be considered
is the "Move and Reconnect". The Initiator proceeds to a
CREATE_CHILD_SA, followed by a DELETE exchange. This means
that the mobility action requires two message exchanges to be
performed.
For a multi homed Initiator : The "Move and Reconnect" scenario can
be considered similarly as for a singled homed Initiator. The
multihomed Initiator can proceed to the "Preconnect and Move"
scenario, in the sense that it can check reachability with the
COOKIE2 mechanism.
Migault Expires March 5, 2010 [Page 23]
Internet-Draft IPsec with mobility and multihoming Sep 2009
10.1.2. Requirements
Requirements on the Mobility and Multihoming extension are :
- The Initiator MUST be able to UPDATE a Security Association,
that is to say, change the IP address of an SA.
- The Initiator MUST be able to check before the mobility action
is performed whether or not the new IP address matches the SPD
or the local policies. This means the tested IP address for
the mobility can be specified as an argument and MUST NOT be in
the Initiator IP address of the IP header.
- When a Responder receives a request to check the validity of a
mobility action it MUST be able to provide the Initiator
relevant pieces of information why the IP address is not
accepted. Possible reasons might be the IP address does not
match the local policies, or the SPD.
- Mobility MUST be performed with a single message exchange.
10.2. Possible Multihoming Scenarios
At the current time, multihoming is only considered with MOBIKE
[RFC4555]. Multihoming is considered for the IKEv2 application,
which means that IKEv2 supports multihoming. Furthermore IKEv2
supports multihoming means that the Initiator provides the Responder
a range of IP address the Responder might use if the current IP
address happens to be unreachable.
This section does not deal on how IKEv2 deals with multihoming. This
paper exposes how IKEv2 can deal with multihoming of Security
Association. More specifically, how an Initiator can assigned one or
more IP address to a given Security Association, and how can it
removes one or more IP address of a Security Association.
10.2.1. Analyze
As in the "Possible Mobility Scenarios", current IPsec suite
mechanisms provides the Initiator the ability to create new
independent Security Association. With Multihoming this would mean
that the number IKE context would be extremely high. If the
Initiator has m IP addresses, and the Responder n IP addresses, this
would lead to the creating of 2mn CHILD_SA. With the possibility to
add and remove IP address to an already existing Security
Association, the number of IKEv2 CHILD_SA is 2.
As mentioned in the definition section of multihoming, ADD or REMOVE
an IP address is only one aspect of Multihoming. The other aspect is
to provide alternate IP address to a given Security Association.
This means that the Initiator SHOULD be able to inform the Responder
Migault Expires March 5, 2010 [Page 24]
Internet-Draft IPsec with mobility and multihoming Sep 2009
of alternate IP address that should be used if the Initiator is not
reachable with the current IP addresses.
10.2.2. Requirements
Requirements on the Mobility and Multihoming extension are :
- The Initiator MUST be able to ADD an IP address to a given
Security Association.
- The Initiator MUST be able to REMOVE an IP address to a given
Security Association.
- For REMOVE or ADD action the Initiator MUST be able to check if
the action is possible on the Responder side. This means that
Responder MUST be able to provides information whether or not
the action can be performed or not. If the action cannot be
performed, then, the Responder MUST send information such as
the IP address does not match the SPD or the local policies.
- The Initiator MUST be able to provide alternate IP addresses
for a given Security Association.
10.3. MOBIKE and our Scenarios
MOBIKE is already designed to deal with mobility and multihoming.
The purpose of this section is to list the functionalities that
MOBIKE already has and those that MOBIKE is missing. This section
points out MOBIKE properties and how there should be expanded to
match our requirements
10.3.1. Analyze
- Transport mode : Mobility extension for transport mode requires
changes between IKEv2 and IPsec. MOBIKE is already proposing
one solution for tunnel mode mobility. The main difference
with transport and tunnel mode is that in the tunnel mode the
SPD is defined according to the inner IP addresses, when the
outer addresses are changed, only the SAD is changed. In the
transport mode, SAD AND SPD MUST be changed. The PAD MUST also
be checked to see if new SA can be created.
- Multiple addresses : MOBIKE considers only one IP address can be
used at a time. The peer has established an IKE_SA to secure
IKE transactions. Sending an UPDATE_SA_ADDRESSES requires some
checks, and then creating new SAD entries, checking Return
Routability before deleting the old ones. Since peers are
using only one IP addresses, mobility parameters are not
explicitly mentioned. In fact, the address to be replaced is
the one the Initiator used to have to carry the tunneled
packets. The replacing IP address is the address located in
the IP header of the IKE message. With a multihomed Initiator,
Migault Expires March 5, 2010 [Page 25]
Internet-Draft IPsec with mobility and multihoming Sep 2009
the Initiator MUST have the ability to explicitly specify the
new IP address and the IP address to be changed. The Initiator
MUST also have ways to specify which SA or IKE_SA the change
applies.
- Alternate IP addresses : MOBIKE already provides a mechanism to
provide alternate IP addresses to the Responder. Those
alternate IP addresses only concerns the IKEv2 application, and
does not apply to the CHILD_SAs. The Initiator SHOULD be able
to specify alternate IP addresses to the different Security
Associations. The main motivation for such functionalities is
to provide IKEv2 the ability to communicate any information
related to mobility or multihoming to Upper Layer Protocols.
- NAT : MOBIKE deals with NAT, and we would like to take advantage
of this work, even though we do not consider NAT.
- Who decides the mobility or multihoming action : MOBIKE actions
concerns only the client IP addresses. This means that the
owner of the different IP address can choose to proceed to
change the IP address. The only situation that excepts this
rule is when a peer is not reachable, in that case, the other
peer may try to use alternate IP address provided previously by
the peer. We keep using this philosophy, the concerned peer
should be the only one that should proceed to a mobility
action.
- The IP the be used : MOBIKE is using only one single IP address
at a time. When sending an UPDATE_SA_ADDRESSES, MOBIKE does
not specify the address to be used. The considered address is
the one provided in the IKE packet header. As explained in the
multiple address bullet, this rule cannot be applied anymore
when more then one IP address is being used.
10.3.2. Requirements
Requirements on the Mobility and Multihoming extension are :
- Mobility and Multihoming MUST be done with IPsec in transport
and in tunnel mode.
- Mobility and Multihoming action, i.e. UPDATE, REMOVE, ADD
action can explicitly specifies which IP address is to be
ADDed, REMOVEd, UPADTEd, and which IP address MUST replaced.
Replacing IP address SHOULD NOT be necessary the one in the IP
header, and the replaced IP address cannot be the "one"
previously used by the Initiator.
- The Initiator MUST be able to provide alternate IP addresses
associated to specific SA
Migault Expires March 5, 2010 [Page 26]
Internet-Draft IPsec with mobility and multihoming Sep 2009
- Ways MUST be provided to the Initiator so that it can
explicitly specifies the SA or IKE_SA the action applies to.
The IKE_SA and CHILD_SA is not the only value.
11. Mobility Rejected by the Responder?
This section describes when a Mobility request might be rejected.
When do the new IP address might be rejected by the local policies or
SPD?
When one peer moves from one public network to another public
network, we believe in most cases the Security Policy will remain the
same on both IP addresses. This means that Security Policies might
change when one a peer moves private IP address to a public IP
address. This leads to consider the following three cases :
- Case 1 : Both peers are on the private network. Peers have
established a connection within a private network, and one peer
moves to the public network.
- Case 2 : One peer is in the public network, the other in the
private network, one peer moves from the public network to the
private network.
- Case 3 : One peer is in the public network, the other peer is in
the private network and the peer moves from the private to the
public network.
For topological reasons, if the peers are both within the private
network and one of the peer wants to move and use a public IP address
instead, specific mechanisms must be used to enable the reachability
between the two hosts. Such mechanisms SHOULD involve a security
gateway or a Home Agent. MIPv6 for example provides means not to
break the communication and establish a tunnel between the Care of
Address and the Home Agent [RFC3775]. Although MIPv6 enables the
connection not to be broken, MIPv6 negotiations are required to set
up the tunnel. Using MIPv6 does not change the Security Association
between the peers, the Security Association is established between
the private IP addresses (eventually HoA). In most cases private
networks are considered as trusted network, and no Security
Association will be established between the two private IP addresses.
The Security Association will be negotiated between the new public IP
address and the gateway to setup a secure tunnel. Since aside
mechanisms MUST be provided to provide reachability of the peers,
this case does not match the Move-and-reconnect scenario as specified
in this section.
Case 2 and case 3 suppose that one peer is in a public network, the
other peer is in a private network, and a connection is established
Migault Expires March 5, 2010 [Page 27]
Internet-Draft IPsec with mobility and multihoming Sep 2009
between them. Reachability between the two different networks can by
provided by NAT, MIPv6, or different proxy / gateway MUST be used.
We can then suppose there is an IKEv2 and a communication channel
established between those two peers. Case 2 and cases 3 differs from
case 1 because the connection between the peers is already
established between heterogeneous networks. Case 2 supposes the peer
on the public network is moving to the private network. It is highly
possible that the Security Association across public and private
network will be "more secured" than required Security Association set
for communications within the private network. Unless internal
network policy for example discards encrypted packets, it is highly
possible that the mobility action can occur. After the moving action
has occurred, the communication between the peers in the private
network will be most probably "over protected", and the renegotiation
of this Security Association might occur. Mobility action is of no
use if the communication between the peers within the private network
does not require any authentication nor protection at any layer.
Even though private networks are considered as trusted networks, most
communication should still be protected by security mechanisms such
as TLS [RFC5246], WESP [I-D.grewal-ipsec-traffic-visibility]... Case
3 considers the other way around, that is to say a peer going from
the private network to the public network. In that case local policy
on the public new IP address might requires first to upgrade security
policies before moving, otherwise the connection will be broken since
security policies do not match.
Note that in this example we considered the private and public
network as two networks that for a peer might have different Security
Policies. We can extend this scenario to any networks A and network
B with different security policies.
The mobility action is independent of the IP protocol. Connectivity
can use IPv6 or IPv4. With one or the other IP version we should use
the proper added mechanism ( MIPv6 [RFC3775]).
12. Scope and Restrictions
Scenarios described in this paper requires extensions of MOBIKE
facilities, and more specifically simultaneous use of IP addresses,
and the use of transport mode.
Nevertheless, one should be aware that this does not represent a
complete solution for mobility, and identified restrictions are
presented below. Some of them are related to the use of transport
mode and upper layer protocols.
Migault Expires March 5, 2010 [Page 28]
Internet-Draft IPsec with mobility and multihoming Sep 2009
- Application : Applications that can take advantage of the use of
mobility and the transport mode must have been designed for in
some ways. First the application should be designed with
multiple short and fast query/responses. In that sense heavy
download application based on one connection should not be
considered. Then the application should be able to easily deal
with non working connections. A typical application that
matches those two requirements is a web browsing application.
A web browser sends a GET message and receives a HTTP/1.1 200
OK response [RFC2616]. Browser are also used to handle with
non reachable server by selecting randomly the IP address from
the DNS response, and that end users are used to retry when it
does not work on the first click. Changing IP address while
browsing the Internet has very few impacts, page downloading
are not requested so continuously, the response should be quite
fast, and if by chance, the mobility occurs while downloading
the page, the user will re-send its request. In the next
future other IP architectures involving 3.5 layers HIP
[RFC4423] , LISP [I-D.farinacci-lisp], SHIM6 [RFC5533] might
overcome some of the restrictions, by avoiding breaking a
connection while changing the IP address...
- Transport : The draft only considers modification of the IPsec
and IP layer. In that sense, changes do not consider
interactions with the transport layer. This means that TCP
connections will be broken when a change of the IP address is
occurring. The application is expected to re-initiate a
connection. In other words no mechanisms are provided in this
draft so to make the mobility transparent to the transport
layer.
- Mobility : This scenario does not consider simultaneous mobility
from the MN and the CN peer. Full mobility management is the
purpose of the MIPv6 [RFC3775]. This draft considers a one end
mobility. The mobility considered in this draft is similar as
the one considered in MOBIKE [RFC4555], except that we provide
mobility for transport mode. The mobility considered in this
draft, with those restrictions, might be better called
"opportunistic mobility" or "nomadism".
13. Acknowledgments
Daniel Migault is partly funded by 3MING, a research project
supported by the French 'National Research Agency'(ANR). We also
thanks for their comments Pierrick Seite, Daniel Palomares and Jean
Michel Combes.
Migault Expires March 5, 2010 [Page 29]
Internet-Draft IPsec with mobility and multihoming Sep 2009
14. Security Considerations
The whole draft is about security.
15. IANA Considerations
There is no IANA consideration here.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Migault Expires March 5, 2010 [Page 30]
Internet-Draft IPsec with mobility and multihoming Sep 2009
Shim Protocol for IPv6", RFC 5533, June 2009.
16.2. Informative References
[I-D.farinacci-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12 (work in progress), March 2009.
[I-D.grewal-ipsec-traffic-visibility]
Grewal, K., "XESP for Traffic Visibility",
draft-grewal-ipsec-traffic-visibility-02 (work in
progress), June 2008.
[I-D.ietf-mext-rfc3775bis]
Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", draft-ietf-mext-rfc3775bis-04 (work in
progress), July 2009.
[I-D.nikander-esp-beet-mode]
Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-09
(work in progress), August 2008.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
Migault Expires March 5, 2010 [Page 31]
Internet-Draft IPsec with mobility and multihoming Sep 2009
Author's Address
Daniel Migault
Orange Labs R&D
38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9
France
Phone: +33 1 45 29 60 52
Email: mglt.ietf@gmail.com
Migault Expires March 5, 2010 [Page 32]