[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

MIF Working Group                                             D. Migault
Internet-Draft                                    Francetelecom - Orange
Intended status: Standards Track                             C. Williams
Expires: May 7, 2013                                           MCSR Labs
                                                        November 3, 2012


              IPsec Multiple Interfaces Problem Statement
              draft-mglt-mif-security-requirements-03.txt

Abstract

   IKEv2 is the protocol used to set up and negotiate Security
   Associations between nodes.  IKEv2 has not been designed for nodes
   with multiple interfaces.

   This document is focused on IKEv2 ability to set up IPsec protected
   communications between nodes with multiple interfaces.  This document
   states the problems and provides requirements for IKEv2 to ease IPsec
   for multiple interface communication.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 7, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Migault & Williams         Expires May 7, 2013                  [Page 1]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Case 1: VPN with Multiple Interfaces . . . . . . . . . . .  5
     3.1.  Initial MIF IPsec Configuration  . . . . . . . . . . . . .  6
       3.1.1.  Description  . . . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Problem Statement  . . . . . . . . . . . . . . . . . .  6
       3.1.3.  Requirements . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.1.  Description  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Problem Statement  . . . . . . . . . . . . . . . . . .  9
       3.2.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 12
       3.3.1.  Description  . . . . . . . . . . . . . . . . . . . . . 12
       3.3.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 13
       3.3.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 13
     3.4.  Adding an Interface  . . . . . . . . . . . . . . . . . . . 14
       3.4.1.  Description  . . . . . . . . . . . . . . . . . . . . . 14
       3.4.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 17
       3.4.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 18
     3.5.  Deleting an Interface  . . . . . . . . . . . . . . . . . . 18
       3.5.1.  Description  . . . . . . . . . . . . . . . . . . . . . 18
       3.5.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 18
       3.5.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 18
   4.  Use Case 2: MIF applications and IPsec Tunnel mode . . . . . . 19
   5.  Use Case 3: MIF aware applications with Transport mode . . . . 20
     5.1.  Initial MIF IPsec Configuration  . . . . . . . . . . . . . 21
       5.1.1.  Description  . . . . . . . . . . . . . . . . . . . . . 21
       5.1.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 21
       5.1.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 21
     5.2.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 22
       5.2.1.  Description  . . . . . . . . . . . . . . . . . . . . . 22
       5.2.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 23
       5.2.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 24
     5.3.  Multihoming  . . . . . . . . . . . . . . . . . . . . . . . 24
       5.3.1.  Description  . . . . . . . . . . . . . . . . . . . . . 24
       5.3.2.  Problem Statement  . . . . . . . . . . . . . . . . . . 24
       5.3.3.  Requirements . . . . . . . . . . . . . . . . . . . . . 25
     5.4.  Adding an Interface  . . . . . . . . . . . . . . . . . . . 25
     5.5.  Delete an Interface  . . . . . . . . . . . . . . . . . . . 25
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25



Migault & Williams         Expires May 7, 2013                  [Page 2]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informational References . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26













































Migault & Williams         Expires May 7, 2013                  [Page 3]


Internet-Draft         IPsec MIF Problem Statement         November 2012


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

   IPsec protocol suite [RFC4301],[RFC5996] is mainly used to:
   - Extend a trusted domain over an untrusted network:  This typically
         corresponds to the Virtual Private Network (VPN) use case.  A
         Security Gateway is a trusted entry point to a trusted network.
         The end user is connected to an untrusted network and tunnels
         its traffic to the Security Gateway in a encrypted tunnel using
         the IPsec tunnel mode.  The Security Gateway decapsulates the
         traffic and forwards it on the trusted network.  Once the
         traffic is in the trusted network it is usually not encrypted
         anymore.  In other words, the traffic is protected from the end
         user terminal to the Security Gateway, that it to say over the
         untrusted network.
   - Provide end-to-end security:  With end-to-end security, the traffic
         is protected from the source - or the end user in our case - to
         the destination.  The traffic does not require to be tunneled,
         and any segments of the network between the end user and the
         destination is considered as untrusted.  With end-to-end
         security, one does not require encapsulation, and the IPsec
         transport mode can be used.

   Currently most devices have multiple interfaces.  Mobile phones have
   most of the time a Wireless LAN (WLAN) and a Radio Access Network
   (RAN) interface.  Laptop can easily have Ethernet / WLAN / RAN with
   WiMAX interfaces.  Furthermore, USB dongle can be plugged to provide
   additional RAN and WLAN interfaces.  Regular PCs, Servers, or CPEs
   have multiple Ethernet interfaces, with additional WLAN interfaces.

   Protocols like SCTP [RFC4960] or MOBIKE [RFC4555] have been designed
   to use these multiple interfaces for multihoming.  Only a single
   interface is used at a time.  The interface used to carry the IP
   datagrams is called the Primary interface and other interfaces are
   called Secondary or Alternate interfaces.  Alternate interfaces are
   only expected to be used in case the Primary interface fails.

   However, multihoming does not enable the simultaneous use of multiple
   interfaces which can provide a better use of the available bandwidth.
   MPTCP [RFC6182] has been designed for that purpose, and SCTP
   [RFC4960] can also be used for it.  Raiciu and al.  [Raiciu] showed
   how using multiple paths improve the performances and robustness of



Migault & Williams         Expires May 7, 2013                  [Page 4]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   data centers compared to TCP.  Furthermore, a communication may be
   connected simultaneously to different networks with different
   technologies and takes advantage of their different characteristics.
   This is typically the case of Offload when ISPs are offloading their
   RAN communications to a WLAN network.  Motivations for offloading is
   that RAN cannot support all mobile traffic [Cisco].  As a result,
   with a RAN and a WLAN interface, Mobile phones and ISPs may balance
   the communications between an unreliable WLAN with economical
   bandwidth and always connected RAN with expensive bandwidth.

   The document focuses on how applications and services protected with
   IPsec can also take advantage of multiple interfaces.  The
   traditional VPN application with multiple interfaces is the first use
   case we consider.  However, with the offload usage, ISPs are
   offloading unprotected communications, services from a trusted
   network - like the RAN - to an untrusted and unreliable network -
   like the WLAN.  This means that the ISP must protect the
   communications related to these services and applications while being
   offloaded.  IPsec appears to be one way to secure communications
   transparently to the application.

   They are two ways to secure the communications with IPsec.  One way
   is to tunnel the communication to a Security Gateway.  The other is
   to provide end to end security.  The document will consider both
   ways.

   Section 3 considers the specific case of VPN with multiple
   interfaces.  Section 4 extends the previous use case by considering
   the general case of IPsec protected communications using the Tunnel
   mode.  Finally Section 5 considers the case of IPsec protected
   communications with the Transport mode.  For each case, the document
   details different scenarios that take advantage of multiple
   interfaces.  Then it positions IKEv2 toward each of these scenarios
   and points out requirements


3.  Use Case 1: VPN with Multiple Interfaces

   This section describes the VPN scenario with connectivity described
   in figure 1, the End User (EU) has multiple interfaces and figure 1
   represents 3 interfaces bound to 3 IP addresses EU @IP_outer(i), (i
   in {1, 2, 3}).









Migault & Williams         Expires May 7, 2013                  [Page 5]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                  End User                 Security Gateway

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |   EU @IP_inner1---====================---------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |   EU @IP_inner2---====================---------------
          |               EU @IP_outer3   SG @IP_outer3 |
          |   EU @IP_inner3---====================---------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 1: VPN with Multiple Interfaces

3.1.  Initial MIF IPsec Configuration

3.1.1.  Description

   This sections details how the End User with its three interfaces set
   (EU @IP_outer(i), i in{1, 2, 3}) can set an IPsec configuration as
   represented in figure 1.  We consider the IPsec configuration is set
   using IKEv2, and that the End User uses only a single IKEv2 channel.
   In other words, each interface MUST NOT be be considered
   independently from each other with its own IKEv2 channel an own
   Security Associations.

   One of these End User IP addresses is used to set the IKEv2 channel.
   This IP address is used to set the IKE_SA as well as for all IKEv2
   exchanges.  Suppose EU @IP_outer1 is used for the IKE_SA.

   Using the IKEv2 channel, the End User requests the inner IP addresses
   EU @IP_inner(i), i in {1, 2, 3}.  If the Security Gateway has
   multiple interfaces, it advertises the End User, what are the
   available interfaces.

   Once the End User has inner and outer IP addresses, it starts
   negotiating via the IKEv2 channel the different Security
   Associations.  For each Security Association, the End User and the
   Security Gateway SHOULD be able to agree on the Traffic Selectors
   (i.e. the inner IP addresses) as well as the outer IP addresses used
   for the Tunnel.

3.1.2.  Problem Statement

   This section positions the current IKEv2 specifications toward the
   scenario described in Section 3.1.1




Migault & Williams         Expires May 7, 2013                  [Page 6]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   To request multiple inner IP addresses, the End User can use the
   IKEv2 with multiple INTERNAL_IP*_ADDRESS Configuration Attributes in
   the CFG Payload (Section 3.15 [RFC5996]).

   Currently IKEv2 does not provide ways for the Security Gateway to
   announce the End User the available outer IP addresses - SG
   @IP_outer1, SG @IP_outer2 and SG @IP_outer3.
   [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] details how this could
   be mitigated.  Note that in the VPN use case, the initiator - that is
   to say the End User - is more likely to request the Security Gateway
   outer IP addresses, then the reverse.  In other words, there seems
   very few interest for the responder to know the different outer IP
   addresses of the End User.  However, as detailed in Section 5 the
   more general case SHOULD consider that both initiator and responder
   can advertise the available interface when the IKEv2 negotiation is
   initiated.

   IKEv2 makes possible the negotiation of the Security Associations
   associated to each of the EU @IP_inner(i) IP addresses using a
   Traffic Selector Payload with one or multiple Traffic Selectors
   (section 3.13 [RFC5996]).  IKEv2 even enables the simultaneous
   negotiation of Security Associations.  However, currently the
   Security Association negotiation does not specify the outer IP
   addresses.  The outer IP addresses are those used for the IKEv2
   channel.  In other words, current IKEv2 only considers a single
   working IP address for both the End User and the Security Gateway.
   Figure 2 illustrates current IKEv2 capabilities in the VPN use case
   with different Traffic Selectors associated to a single outer IP
   address.  While negotiating a Security Association, IKEv2 SHOULD be
   able to specify the source and destination IP addresses.

   Note that the benefits of specifying the outer IP addresses provides
   the End User or Initiator the ability to use simultaneously multiple
   interfaces.  In the specific case of figure 1, the Security Gateway
   will most likely have a single IP outer IP address.  We considered
   multiple IP addresses on the Security Gateway for the more general
   case.

   Currently, IKEv2 does not provide the ability to negotiate the outer
   IP addresses of the Tunnel.  By default, the outer IP addresses of
   the Child Security Associations are those used for the IKEv2 channel.
   This results in the configuration as represented in figure 2.  The
   configuration of figure 1 does not result from an IKEv2 negotiation.








Migault & Williams         Expires May 7, 2013                  [Page 7]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                  End User                 Security Gateway

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |   EU @IP_inner1---====================---------------
          |     EU @IP_outer2 ^^          SG @IP_outer2 |
          |   EU @IP_inner2---vv
          |     EU @IP_outer3  ^          SG @IP_outer3 |
          |   EU @IP_inner3--- v
          |                     |            |          |
          +---------------------+            +----------+

                Figure 2: VPN with Multiple Interfaces
                          Current IKEv2 negotiation

3.1.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible:
   - 1.  To specify the different outer IP addresses for the tunnel mode
         in the Security Association negotiation.
   - 2.  Make possible the Responder and Initiator to announce its
         interfaces.

3.2.  Mobility

3.2.1.  Description

   This section considers how a node with multiple interfaces can modify
   the value of the outer IP address.  In the Tunnel mode, changing the
   outer IP address results in a mobility, however this should be seen
   as updating a parameter of the Security Association.  Figure 3
   illustrates a mobility where EU @IP_outer3 in Figure 1 is updated by
   EU @IP_outer4.

   In fact, the Security Association associated to EU @IP_inner3
   includes the outer IP address of the tunnel.  The End User and the
   Security Gateway MUST change this outer IP address from EU
   @IP_outer3.  The End User MUST modify its Security Association so
   that packets sent to the Security Gateway are using a valid IP
   address.  Similarly, the Security Gateway MUST update its Security
   Association so that it can send packets to a reachable destination IP
   address.  The notification of the update is performed using the IKEv2
   channel, that is to say in our case EU @IP_outer1.

   Figure 3 illustrates the case where EU @IP_outer4 is using the same
   network hardware interface as EU @IP_outer3.  This corresponds to the



Migault & Williams         Expires May 7, 2013                  [Page 8]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   case where, for example, the End User decides to use EU @IP_outer4
   instead of EU @IP_outer3 on the same hardware network interface.
   Other mobility use cases may also consider the EU @IP_outer4 may be
   associated to a different network hardware, including the one
   associated to EU @IP_outer(i), i in {1, 2}.  Then, EU @IP_outer4 is
   different from EU @IP_outer3 but may be one of the EU @IP_outer(i), i
   in {1, 2}.

                  End User                 Security Gateway

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |   EU @IP_inner1---====================---------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |   EU @IP_inner2---====================---------------
          |               EU @IP_outer4   SG @IP_outer3 |
          |   EU @IP_inner3---====================---------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 3: VPN Mobility

3.2.2.  Problem Statement

   Currently IKEv2 proposes different alternative to update a Security
   Association, and modify the outer IP address of the Tunnel.  However
   none of them really address the description provided in Section 3.2.1

3.2.2.1.  MOBIKE

   MOBIKE [RFC4555] provides an UPDATE_SA_ADDRESSES exchange that
   updates the outer IP address of the tunnel.  As explained in this
   section MOBIKE cannot be used in the general case described in figure
   3 because the updated IP address is necessarily the one associated to
   the IKEv2 channel.  This limitation is due to the fact that MOBIKE
   has been designed for a single interface.

   MOBIKE does not explicitly specify in its message the IP address that
   has to be updated and the new value for this IP address.  The IP
   address to be updated is the one used by the IKEv2 channel, and the
   new IP address to consider is the IP address used in the IP header of
   the UPDATE_SA_ADDRESSES message.

   If EU @IP_outer1 is equal to to EU @IP_outer3, then sending an
   UPDATE_SA_ADDRESSES would update the outer tunnel IP address of the
   Security Associations using the IP address of the IKEv2 channel, that
   is at least EU @IP_outer1 and EU @IP_outer3, with EU @IP_outer4.



Migault & Williams         Expires May 7, 2013                  [Page 9]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   This case is only a specific case and is not applicable when the
   outer IP address to update is different from the IP address used for
   the IKEv2 channel.

   If EU @IP_outer3 is different from EU @IP_outer1, then, the only way
   to use MOBIKE is to move the IKEv2 channel to EU @IP_outer3, that is
   updating EU @IP_outer1 by EU @IP_outer3, and then updating EU
   @IP_outer3 by EU @IP_outer4.  This is not convenient because all
   traffic on EU @IP_outer1 has been transferred to EU @IP_outer3, and
   then to EU @IP_outer4.  Furthermore, it is only possible for managed
   mobility, because we need EU @IP_outer3 to be a valid interface until
   IKEv2 uses EU @IP_outer3.  In other words, if EU @IP_outer3 fails
   suddenly, moving the IKEv2 channel to EU @IP_outer3 is not possible
   anymore.

   As a result MOBIKE cannot be used to handle the mobility described in
   Section 3.2.1.

3.2.2.2.  CREATE_CHILD_SA

   A second alternative is to renegotiates a new Security Association
   between the End User and the Security Gateway.  IKEv2 provides the
   CREATE_CHILD_SA Exchange (Section 1.3 [RFC5996]) to create a new
   Security Association.  Similarly Section 3.1.2 this exchange does not
   specify the outer IP address of the Tunnel.  By default, the outer IP
   address of the Tunnel is the IP address used for the IKEv2 channel.
   This does not address the use case described in Section 3.2.1.

   If requirements of Section 3.1.3 were fulfilled, that is to say even
   if the CREATE_CHILD_SA would enable to negotiate the outer IP
   addresses of the Tunnel, then, using the CREATE_CHILD_SA exchange
   would be an alternative.  However, this alternative would still
   suffer from several drawbacks:
   - Not Mandatory:  The CREATE_CHILD_SA is not a mandatory IKEv2
         feature, especially for light implementations.  For these
         implementation, an non reachable interface would require re-
         negotiating both the IKE_SA and the new Security Association.
         Furthermore, there is currently no way to advertise whether the
         implementation supports or not this exchange.
   - Resource Consuming Exchange:  The CREATE_CHILD exchange creates a
         Security Association from scratch and requires all parameters
         of the Security Association to be specified.  This results in a
         quite complex exchange, which does not take advantage of the
         already negotiated parameters, like nonces, Keys, Traffic
         Selectors, Nonces, SPIs.  Instead it requires all these
         parameters to be renegotiated, generation of nonces, keys, as
         well as multiple interactions with IPsec databases which
         requires more resources than updating a single parameter within



Migault & Williams         Expires May 7, 2013                 [Page 10]


Internet-Draft         IPsec MIF Problem Statement         November 2012


         a Security Association.
   - Two-Successive Exchange:  The CREATE_CHILD exchange creates a new
         Security Association, however, the previously used Security
         Association has not been removed from the IPsec databases.  As
         a result, once the new Security Association has been created, a
         new exchange SHOULD be performed to delete the previous
         Security Association with the Delete Payload (Section 3.11
         [RFC5996].  The Delete Payload specifies the Security
         Associations to Delete.
   - Per Security Association Exchange:  The CREATE_CHILD_SA exchange
         creates a specific Security Association, which means that there
         are as many CREATE_CHILD_SA exchanges as Security Association
         to update.  In our case, multiple Security Associations may be
         bound to a single interface, so the Security Association
         granularity is not convenient for interface management.
         Updating an interface implies that all Security Association
         bound to this interface MUST be updated.  In the use case
         illustrated by figure 3, the End User a single Security
         Association per interface, so interface and Security
         Association management have similar granularity.  On the other
         end, for the Security Gateway with a single interface, i.e.
         (all SG @IP_outer(i), i in{1, 2, 3} are the same), interface an
         Security Association do not have the same granularity.  Note
         that with a single interface the Security Gateway would be able
         to use MOBIKE, but not with two interface (i.e. is SG
         @IP_outer2 and SG @IP_outer3 would be the same).

3.2.2.3.  One IKE channel per Interface

   A fourth alternative consists renegotiating an complete independent
   IKEv2 channel and a new Security Association.  This is out of the
   scope of this document.  This may result as having a IKEv2 channel
   per interface.  Furthermore, independent IKEv2 channels may not
   simplify IPsec configuration and may result in multiple Security
   Associations matching a given Traffic Selector, which may cause
   trouble at least for outbound traffic.  Furthermore, in this case,
   the End User and the Security Gateway must proceed to an
   authentication.

3.2.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 3, IKEv2 SHOULD make possible:
   - 1.  To update the outer IP address of the tunnel with a IP address
         that differs from those used for the IKEv2 channel.  The Update
         is not a per security Association negotiation but SHOULD
         replace all Security Association associated to the old IP
         address.  For all these Security Associations, the old IP



Migault & Williams         Expires May 7, 2013                 [Page 11]


Internet-Draft         IPsec MIF Problem Statement         November 2012


         address is replaced by the new IP address.  This consists in
         extending MOBIKE UPDATE_SA_ADDRESSES exchange.

3.3.  Multihoming

3.3.1.  Description

   This section considers how a node can take advantage of multiple
   interfaces with multihoming.  In case one of these interface fails,
   then another interface can be used instead.  Moving the traffic from
   one interface to the other is called mobility.  This section deals
   with multihoming, that is the two peers agree that in case an
   interface fails, a mobility should be triggered on the agreed
   interface.

   Suppose, as represented in figure 4, EU @IP_outer3 is not reachable
   anymore.  Applications that are multiple interfaces aware, and also
   bound to the others EU @IP_inner(i) (i in {1, 2}) IP addresses may
   handle EU @IP_outer3 non reachability.  On the other hand non
   multiple interfaces aware applications (like regular TCP connections)
   bound to EU @IP_outer3 are stalled and cannot use the other
   interfaces.

   One way to recover the EU @IP_inner3 unreachability is to reconfigure
   the Security Association and replace EU @IP_outer3 by EU @IP_outer(i)
   (i in {1, 2}).  Figure 5 shows that EU @IP_outer3 is replaced by EU
   @IP_outer2.  EU @IP_outer2 has been provided as an Alternate IP
   address of EU @IP_outer3.  This means that when one or the other peer
   notice EU @IP_outer3 is down, it can trigger a mobility with the
   appropriated outer IP address.  More specifically, the Security
   Gateway can overcome the failure of EU @IP_outer3, if it detects the
   failure before the End User.  The End User and the Security Gateway
   can also agree on an ordered list of Alternate IP addresses.

                  End User                 Security Gateway

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |   EU @IP_inner1---====================---------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |   EU @IP_inner2---====================---------------
          |                               SG @IP_outer3 |
          |   EU @IP_inner3---                    ---------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 4: VPN with Mobility/Multihoming between



Migault & Williams         Expires May 7, 2013                 [Page 12]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                          Multiple Interfaces: EU @IP_outer3 unreachable


                  End User                 Security Gateway

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |   EU @IP_inner1---====================---------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |   EU @IP_inner2---====================---------------
          |                  |v|      |^| SG @IP_outer3 |
          |   EU @IP_inner3---v        ^==========---------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 5: VPN with Mobility/Multihoming between
                          Multiple Interfaces: EU @IP_outer2
                          replaces EU @IP_outer3

3.3.2.  Problem Statement

   Currently Multihoming is handled by MOBIKE with the
   ADDITIONAL_IP*_ADDRESS Notify Payloads.  As with mobility, these
   payloads are only provided for the interface used by the IKEv2
   channel.  The main reason is that MOBIKE has been designed for a
   single interface.  In our cas,e MOBIKE would only make possible to
   provide Alternate IP addresses to EU @IP_outer1.

   What happens to packets when the Security Gateway performs
   Multihoming and the End User has not updated its Security
   Association?  Both End User and Security Gateway Security
   Associations are configured to use the EU @IP_outer3 IP address.
   When the Security Gateway notices EU @IP_outer3 is not reachable it
   updates its Security Association, triggers a mobility exchange and
   may start sending packets to EU @IP_outer2 before the End User has
   proceeded to the update of its Security Associations.  The End User
   receives this packet and performs a Security Association match.
   Outer IP addresses will not performed a match, and the match occurs
   with the Security Policy Index (SPI).  The packet is checked against
   the Security Policy Databases Selectors.  These selectors are based
   on the inner IP addresses and have not been modified.  As a result,
   packets will not be discarded.

3.3.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 3, IKEv2 SHOULD make possible:



Migault & Williams         Expires May 7, 2013                 [Page 13]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   - 1.  To provide Alternate IP addresses for IP addresses that are
         different from the one used by the IKEv2 channel.  This extends
         the Multihoming features of MOBIKE to multiple interfaces.
   - 2.  Reduce the complexity of Multihoming.  Although a node MUST be
         able to provide Alternate IP address for a given IP address, it
         should also be able to provide all its interfaces, and if
         multihoming is supported on both side, a multihoming rule
         should be derived by default from this list.

3.4.  Adding an Interface

3.4.1.  Description

   Nodes with multiple interfaces may have some interfaces supporting
   the VPN whereas other interfaces have not been assigned an IP
   address.  When this interface has been assigned an IP address, the
   current VPN communication may take advantage of this newly available
   interface.  This section is concerned on how a given communication
   can take advantage of a newly available interface and set its IPsec
   settings in an optimal way.

   Figure 6 represents the End User with multiple interfaces connected
   to the Security Gateway.  We only represented a single interface for
   the Security Gateway but more interfaces may be also considered.  In
   figure 7, the Security Gateway has an additional interface that
   becomes active, it advertises the End User this interface is
   available.  The End User may perform some latency and Round Trip Time
   measurements and decide to use it.  In the figure 7, the End User
   moves the traffic associated to its interface EU @IP_outer3 to the
   newly available interface SG @IP_outer2 of the Security Gateway.
   Moving the traffic is performed through a mobility operation as
   described in Section 3.2.

                  End User                 Security Gateway

          +---------------------+            +-------------+
          |                     |            |             |
          |               EU @IP_outer1      |             |
          |   EU @IP_inner1---========== ^|  |             |
          |               EU @IP_outer2 |v|  SG @IP_outer1 |
          |   EU @IP_inner2---====================---------------
          |               EU @IP_outer3 |^|  |             |
          |   EU @IP_inner3---========== v|  |             |
          |                     |            |             |
          +---------------------+            +-------------+

                Figure 6: Security Gateway with a single Interface




Migault & Williams         Expires May 7, 2013                 [Page 14]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                  End User                 Security Gateway

          +---------------------+            +-------------+
          |                     |            |             |
          |               EU @IP_outer1      |             |
          |   EU @IP_inner1---========== ^|  |             |
          |               EU @IP_outer2 |v|  SG @IP_outer1 |
          |   EU @IP_inner2---====================---------------
          |               EU @IP_outer3      SG @IP_outer2 |
          |   EU @IP_inner3---====================---------------
          |                     |            |             |
          +---------------------+            +-------------+

                Figure 7: Security Gateway adding an Interface
                          New Interface used by the EU @IP_outer3

   Figure 6 and 7 illustrated the case, where the Security Gateway has
   an additional active interface.  In this case, the Security Gateway
   let the End User decide which interface they prefer to use.  By
   announcing the newly available interfaces no new Security
   Associations are created.  On the other hand, the End User may also
   want that any service using the other interfaces can use this newly
   available interface.  This requires to derive the Security
   Associations associated to the new interface from those associated to
   the already established interfaces.  The Security Associations
   derived for the newly active interface are not created from scratch
   with a complete negotiation.  This case is illustrated by figure 8
   and 9.

                  End User                 Security Gateway

          +---------------------+            +-------------+
          |                     |            |             |
          |               EU @IP_outer1      |             |
          |   EU @IP_inner1---========== ^|  |             |
          |               EU @IP_outer2 |v|  SG @IP_outer1 |
          |   EU @IP_inner2---====================---------------
          |                                  |             |
          |   EU @IP_inner3---               |             |
          |                     |            |             |
          +---------------------+            +-------------+

                Figure 7: End User with an inactive interface








Migault & Williams         Expires May 7, 2013                 [Page 15]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                  End User                 Security Gateway

          +---------------------+            +-------------+
          |                     |            |             |
          |               EU @IP_outer1      |             |
          |   EU @IP_inner1---========== ^|  |             |
          |               EU @IP_outer2 |v|  SG @IP_outer1 |
          |   EU @IP_inner2---====================---------------
          |               EU @IP_outer3 |^|  |             |
          |   EU @IP_inner3---===========v   |             |
          |                     |            |             |
          +---------------------+            +-------------+

                Figure 8: End User with a newly active interface
                          EU @IP_outer3. All traffic associated to
                          EU @IP_outer1 and EU @IP_outer2 is able to
                          use EU @IP_outer3

   In our case, the End User already had a specific inner IP address
   associated to the newly available interface EU @IP_outer3.  This
   makes possible the End User to generate the new IPsec Security
   Associations and new Security Policies associated to EU @IP_outer3.
   When the Security Gateway receives the request to add the newly
   available interface, it may set the newly Security Policies and
   Security Associations.  However, the End User may not have an inner
   IP address EU @IP_inner3, and may combine the request to the Security
   Gateway to add the new interface, with a request for a EU @IP_inner3
   address.  In that case, the Security Gateway first sets the IPsec
   databases, and the End User sets the IPsec databases when it receives
   the inner IP address.

   When an interface is added, unless otherwise specified, the End User
   wants that all services, except IKEv2 using the available outer IP
   addresses (EU @IP_outer1 and @IP_outer2 addresses) may also be
   configured to use the newly available IP address EU @IP_outer3.  By
   adding an interface the End User is not using a finer granularity
   than the interface granularity.  In other words, it does not want to
   specify how Security Associations are derived.  They should be
   derived in an automatic way.  In return, deriving Security
   Associations and Security Policies is expect to optimize their
   creation as opposed to using CREATE_CHILD_SA.

   In the example of figure 7 and 8, the End User is likely to create
   Security Associations derived from those established with the
   interfaces EU @IP_outer1 and EU @IP_outer2.  All services using EU
   @IP_outer1 or EU @IP_outer2 will be able to use EU @IP_outer3 with
   the inner IP address EU @IP_inner3.




Migault & Williams         Expires May 7, 2013                 [Page 16]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   The idea is to copy the Security Association associated with EU
   @IP_outer1 replace EU @IP_outer1 by EU @IP_outer3 and EU @IP_inner1
   by EU @IP_inner3.  SPIs MUST also be changed since there are unique
   for the Security Association.  Then we perform the same with EU
   @IP_outer2.

   Note that it is important to specify an ordered list of EU @IP_outer
   address from which the new SAs are derived, so to guarantee that
   these new Security Associations are derived the same way on both
   peers.  Then the new Security Association MUST be created only if
   there are no already existing matching SPD selectors.

   In the most basic case of VPN, we only have one Security Association
   per interface.  All services using EU @IP_inner(i) are tunneled to EU
   @IP_outer(i) i in{1,2}.  Adding EU @IP_outer3 only requires to derive
   Security Association from one interface EU @IP_outer1 and EU
   @IP_outer2.  Then, the End User needs to specify the inner and outer
   IP addresses EU @IP_inner3, EU @IP_outer3 and in the specific case
   represented on figure 7 the outer IP address of the Security Gateway
   SG @IP_outer3.  The resulting exchange may look something like the
   exchange represented in figure 10.  The mandatory parameters are the
   IP address used for the traffic selectors, and the outer IP address
   for the Tunnel on the End User.  The destination outer IP address of
   the Tunnel is optional and, if not specified may be the one used by
   the IKEv2 channel.  The list of interfaces from which are derived the
   Security Associations and the Security Policies may also be optional.
   A default value for this list may be the ordered list of associated
   outer IP addresses of the End User.  The nonce may be used to create
   SPIs.

                  End User                 Security Gateway

      request    Add Interface (EU @IP_inner3, --->
                 EU @IP_outer3, [outer-destination]
                 [interface-list] [nonce])

      normal case                       <--- N()

      error case                        <--- N(error)

               Figure 10: Principle of the Adding Interface
                         exchange

3.4.2.  Problem Statement

   Currently IPsec does not provide any means for a peer to advertise a
   new interface is available.  MOBIKE makes possible to advertise a
   Alternate IP address is available.  However Alternate IP addresses



Migault & Williams         Expires May 7, 2013                 [Page 17]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   are only intended to be use in case the Primary Interface is down.
   In our case, the interface is ready for use.  This issue is similar
   to the one detailed in Section 3.1.2.  However, here the announcement
   corresponds to a dynamic changes, and the list of available IP
   address does not occurs during the IKE_INIT exchange, but in a
   regular information exchange.

   Currently the only way IKEv2 provides to create new Security
   Associations is the CREATE_CHILD_SA exchange.  Disadvantages of this
   exchange have been described in Section 3.2.2.  The key advantage of
   adding an interface is to provide an optimized interface management
   exchange instead of a Security Association management exchange.

3.4.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible:
   - 1.  Make possible the Responder and Initiator to announce its
         interfaces outside the IKE_INIT exchange.  This requirements is
         similar to the one of Section 3.1.3
   - 1.  Make possible the Responder and Initiator to automatically
         derive Security Associations and Security Policies from the
         existing interface.

3.5.  Deleting an Interface

3.5.1.  Description

   Nodes with multiple interfaces in dynamic environment may have
   interfaces that are not reachable anymore.  This may trigger mobility
   or multihoming actions.  However, the node may also want to delete
   the Security Associations bound to this interface either as a Tunnel
   outer IP address or as a Traffic Selector.

3.5.2.  Problem Statement

   Currently IKEv2 does not make possible to delete an interface from
   multiple Security Associations.  IKEv2 provides a Delete Payload
   (Section 3.11 [RFC5996] that deletes one or multiple specific
   Security Associations, identified by their SPI.

3.5.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 3, IKEv2 SHOULD make possible:






Migault & Williams         Expires May 7, 2013                 [Page 18]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   - 1.  Delete an interface, that is to say all Security Associations
         associated to that interface.


4.  Use Case 2: MIF applications and IPsec Tunnel mode

   This section considers applications that can deal with multiple
   interfaces.  This ability can be done with transport layer protocols
   like MPTCP or SCTP or with applications using one or multiple UDP /
   TCP connections over the various interfaces, and that manages how to
   send the data.

   The difference between multiple interfaces aware applications and the
   VPN use case is that the tunnels are established per services,
   whereas the VPN tunnel all traffic is tunneled to a unique Security
   Gateway.  This may increase the number of Security Associations
   between the End User and the Security Gateway.  This section details
   motivation for using the IPsec Tunnel mode with multiple interfaces
   aware applications and position it to the VPN use case of Section 3.

   Applications may use the tunnel mode for end-to-end security and to
   benefit from the Mobility features provided by the Tunnel mode.  More
   specifically, using the Tunnel mode provides Mobility without
   breaking the connectivity, if upper layer is not mobility aware.

   Other motivations for using the Security Gateway is that the End User
   chose not to tunnel all its traffic to the Security Gateway, but only
   the traffic that worth being protected.  For example, an End User may
   chose not to tunnel its "youtube" traffic, as well as some of its
   "https" traffic (as well as it application layer protected traffic).
   On the other hand, it may want to tunnel all non-protected "http" (as
   well as other non protected communications).

   If each service proposes different Security Gateways, the use case is
   very similar to the VPN use case, for each service.  The main
   difference is that Security Association are established with
   different Traffic Selectors.

   If multiple services are using the same Security Gateway, this will
   result for each interface, in multiple Security Associations
   established with the same Security Gateway - one per service.  This
   case is very similar to the VPN use case but with multiple Security
   Associations.  If "s" is the number of Services connected on the
   Security Gateway the number of Security Associations is at least "s"
   5services are considered independent).  If some applications are
   using multiple flows, then this number may be even larger.  In that
   case, adding an interface results in at least negotiating "s" new
   Security Associations.  Using the CREATE_CHILD_SA exchange may



Migault & Williams         Expires May 7, 2013                 [Page 19]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   require "s" exchanges whereas using the Adding interface exchange
   requires only one exchange.  This use case is represented in figure
   11.

                  End User                 Security Gateway

          +----------------------+            +----------+
          | Services: S1 - Ss    |            |          |
          |                EU @IP_outer1   SG @IP_outer1 |
          | P  EU @IP_inner1 ---====================---------------
          | o              EU @IP_outer2   SG @IP_outer2 |
          | r  EU @IP_inner2 ---====================---------------
          | t              EU @IP_outer3   SG @IP_outer3 |
          | s  EU @IP_inner3 ---====================---------------
          |                      |            |          |
          +----------------------+            +----------+

                Figure 11: MIF aware applications

   Requirements of this use case have already been mentioned in the VPN
   use case.


5.  Use Case 3: MIF aware applications with Transport mode

   This Use Case is very similar to the Use Case 2 except that the
   Transport mode is used instead of the Tunnel mode.  The Use Case is
   illustrated with figure 12.

   Unlike in the VPN use case in Section 3 or for multiple interfaces
   aware applications described in Section 4 using IPsec tunnel mode,
   the IPsec Transport mode does not involves inner IP addresses.

   With Transport mode, we may consider two types of applications.  The
   applications that can handle multiple interfaces.  This can be done
   with transport protocols like MPTCP or SCTP or with a connection
   manager at the application layer.  These applications may have
   Security Associations on all interfaces.  Other Applications with a
   single using TCP/UDP and without specific connection managers may
   only deal with a single interface and may only have an Security
   Association associated to this interface.










Migault & Williams         Expires May 7, 2013                 [Page 20]


Internet-Draft         IPsec MIF Problem Statement         November 2012


                  End User                   Server

          +---------------------+            +----------+
          |   Applications      |            |          |
          |               EU @IP_outer1    S @IP_outer1 |
          |   MPTCP/TCP   --------------------------------------
          |               EU @IP_outer2    S @IP_outer2 |
          |               --------------------------------------
          |               EU @IP_outer3    S @IP_outer3 |
          |               --------------------------------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 12: MIF aware applications with the
                           Transport mode

5.1.  Initial MIF IPsec Configuration

5.1.1.  Description

   In Figure 12, the End User initiates an IKEv2 negotiation using EU
   @IP_outer1 and S @IP_outer1.  The Server provides the End User the
   available interfaces (S @IP_outer1 i in {1, 2, 3}).  Then the End
   User negotiates Security Associations between the EU @IP_outer(i) and
   S @IP_outer(i) i in{1,2,3} using different Traffic Selectors.

5.1.2.  Problem Statement

   Currently IKEv2 does not make possible a node to announce its
   available interfaces.

   The Transport mode, does not involve tunnel outer IP addresses.
   Current Security Association exchange enables Traffic Selectors
   negotiation.  These Traffic Selectors are used both for the Security
   Policy Index (Traffic Selectors) for outgoing traffic and for the
   Security Association Index for incoming traffic.  Current IKEv2
   specification enables to set IPsec as described in figure 11.

5.1.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible
   - 1.  Make possible the Responder and Initiator to announce its
         interfaces.  This requirement is similar to the requirements
         for VPNs.






Migault & Williams         Expires May 7, 2013                 [Page 21]


Internet-Draft         IPsec MIF Problem Statement         November 2012


5.2.  Mobility

   With regular TCP connection a change of the IP address breaks the
   connection.  Applications may use mobility with the Transport mode
   with transport protocols that handles with multiple interfaces (like
   MPTCP or SCTP for example), with multiple independent TCP/UDP
   connections on the different interfaces.  The application manages its
   connections at the application layer.

   Mobility with Transport mode MUST be understood as updating an
   existing Security Association.  The purpose of the IPsec Mobility and
   the Transport mode is to avoid to create a new Security Association
   when the IP address of an interface is changing.  IPsec configures
   the layer so that the application can securely go on with its
   communications.  TCP connections are restarted, since changing the IP
   address will most likely break the existing connection.  UDP will
   start sending on the other interface.  Mobility is intended to reduce
   the time IPsec requires to configure its Security Associations.

   With the Tunnel mode, IPsec was in charge of securing and
   transporting IP datagrams.  With the Transport mode, IPsec only
   secures the communication.  Transport of the IP datagrams is shared
   between the application and the transport layer.  Application and
   IPsec layers are independent and have their own way to handle with
   mobility.  Synchronization between these two layers MUST be performed
   to avoid that the application moves the traffic on an interface
   whereas IPsec DISCARD this traffic.  Although we do not intend to
   provide a complete list of how to synchronize these two layers, the
   list below provides some example where these two layers are
   synchronized:
   - 1.  For End Users with two interfaces.  In that case, the interface
         the application may use s determined.
   - 2.  For applications that are configured with two interfaces.
   - 3.  For applications that we know the interface they will choose.
         Like those setting priority to interfaces.  This could be set
         by using Multihoming and ordering the Alternate IP addresses.
   - 4.  If the Mobility exchange is triggered by the new socket, new
         packet sent.  This case reduces the latency over a
         CREATE_CHILD_SA exchange, but does not anticipate the decision
         of the application.

5.2.1.  Description

   The mobility scenario we consider in this section is an application
   using a single interface EU @IP_outer3 for example.  As represented
   in figure 13, this interface is down.  Then the End User get assigned
   a new IP address EU @IP_outer4 and uses this interface as represented
   in figure 14.  Both End User and Server MUST update Security Policies



Migault & Williams         Expires May 7, 2013                 [Page 22]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   and Security Associations that used EU @IP_outer3 and replace the
   value with EU @IP_outer4.  Unlike the Tunnel mode, Traffic Selectors
   also need to be updated.

                  End User                   Server

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |                --------------------------------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |                --------------------------------------
          |                               SG @IP_outer3 |
          |    Application ---x                   ---------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 13: Mobility with Transport mode and
                           Multiple Interfaces: EU @IP_outer3
                           unreachable.


                  End User                   Server

          +---------------------+            +----------+
          |                     |            |          |
          |               EU @IP_outer1   SG @IP_outer1 |
          |                --------------------------------------
          |               EU @IP_outer2   SG @IP_outer2 |
          |                --------------------------------------
          |               EU @IP_outer4   SG @IP_outer3 |
          |    Application --------------------------------------
          |                     |            |          |
          +---------------------+            +----------+

                Figure 14: Mobility with Transport mode and
                           Multiple Interfaces: EU @IP_outer4
                           replaces EU @IP_outer3.

5.2.2.  Problem Statement

   Currently IKEv2 does not provide extension that perform any mobility
   operation.

   MOBIKE has only been designed for the Tunnel mode.

   The CREATE_CHILD_SA suffers for limitations exposed in Section 3.2.2:
   It is not mandatory in IKEv2 implementation, the exchange requires



Migault & Williams         Expires May 7, 2013                 [Page 23]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   much resources as updating the Security associations.  Most of the
   time, it requires an addition Delete exchange and is a per Security
   Association exchange.  However, because no tunnel IP address requires
   to be negotiated, the CREATE_CHILD_SA can set the Security
   Associations and Policies as described in figure 14.

5.2.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible
   - 1.  Extend MOBIKE to the Transport mode
   - 2.  Extend MOBIKE with Transport mode to multiple interfaces
         requirements described in Section 3.2.3.

5.3.  Multihoming

   Multihoming consists in providing Alternate Interfaces in case a
   running interface is down, so peers are aware of the parameters to
   update.  Multihoming can be seen as pre-configuring an mobility
   operation.

5.3.1.  Description

   With Multihoming, when the End User sets its IPsec configuration as
   illustrated in figure 12, the End User also specifies for each
   interface the corresponding Alternate IP address.  Although this an
   be done on a per interface value, we suggest that when multiple
   interfaces are provided, Alternate IP addresses can be derived
   automatically and assigned to each interface without being explicitly
   mentioned.  Suppose that in the case of figure 13, for example EU
   @IP_outer2 is provisioned as the Alternate IP address of EU
   @IP_outer3.

   When EU @IP_outer3 is down, then the End User or the Server triggers
   a mobility exchange as described in section Section 5.2.1.

5.3.2.  Problem Statement

   Currently IKEv2 does not make possible to provision Alternate IP
   addresses for the Transport mode.  MOBIKE has only been designed for
   the Tunnel mode, then as mentioned in Section 3.3.2, MOBIKE only
   assigns the Alternate IP address for the IP address used by the IKEv2
   channel.  This is because MOBIKE has been designed for a single
   interface.

   Note that with the Transport mode, the Alternate Address is provided
   to the outer IP address that is also used as a Traffic Selector,
   whereas in the Tunnel mode, the Alternate IP address is provided for



Migault & Williams         Expires May 7, 2013                 [Page 24]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   the tunnel outer IP address.

   Note also that the IKEv2 channel is a special case where Alternate
   Address is associated to the Transport mode.  In fact the IKEv2
   channel uses Transport mode, not the Tunnel mode.

5.3.3.  Requirements

   In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible to:
   - 1.  Extend MOBIKE Multihoming to the Transport mode
   - 2.  Extend MOBIKE with Transport mode to multiple interfaces
         requirements described in Section 3.3.3.  Alternate IP address
         should be assigned to any interface and can be automatically be
         derived.  Alternate IP address concerns Traffic Selectors and
         Security Association Indexes.

5.4.  Adding an Interface

   Adding an interface works exactly as described in Section 3.4.  The
   only difference is that when an interface is added with the Transport
   mode, Traffic Selectors will automatically be associated to this
   newly added interface, which was not necessarily the case with the
   Tunnel mode.

5.5.  Delete an Interface

   Similarly to the addition of a new interface, Deleting an interface
   works exactly as described in Section 3.5.  The only difference is
   that with the Transport mode, Security Associations and Security
   Policies to delete are these where the specified interface appears as
   a Traffic Selector rather than as an outer tunnel IP address.


6.  Security Considerations

   The whole document sets MIF requirements for a security protocol.


7.  IANA Considerations

   There is no IANA consideration here.


8.  Acknowledgment

   We would like to thank Daniel Palomares, Pierrick Seite, Brian
   Carpenter, Hui Deng, Jong-Hyouk Lee, Juan Carlos Zuniga and



Migault & Williams         Expires May 7, 2013                 [Page 25]


Internet-Draft         IPsec MIF Problem Statement         November 2012


   Konstantinos Pentikousis for their useful comments.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

9.2.  Informational References

   [Cisco]    "Cisco Visual Networking Index: Global Mobile Data Traffic
              Forecast Update, 2010-2015", February 2011.

   [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses]
              Arora, J. and P. Kumar, "Alternate Tunnel Addresses for
              IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00
              (work in progress), April 2010.

   [RFC6182]  Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
              Iyengar, "Architectural Guidelines for Multipath TCP
              Development", RFC 6182, March 2011.

   [Raiciu]   Arora, C., Barre, S., Plunkte, C., Greenhalgh, A.,
              Wischik, D., and M. Handley, "Improving datacenter
              performance and robustness with multipath TCP", SIGCOMM
              2011 Toronto, Canada, August 2011.










Migault & Williams         Expires May 7, 2013                 [Page 26]


Internet-Draft         IPsec MIF Problem Statement         November 2012


Authors' Addresses

   Daniel Migault
   Francetelecom - Orange
   38 rue du General Leclerc
   92794 Issy-les-Moulineaux Cedex 9
   France

   Phone: +33 1 45 29 60 52
   Email: mglt.ietf@gmail.com


   Carl Williams
   MCSR Labs
   Philadelphia, PA  19103
   USA

   Phone: 650-279-5903
   Email: carlw@mcsr-labs.org
































Migault & Williams         Expires May 7, 2013                 [Page 27]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/