<?xml version="1.0" encoding="UTF-8"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY rfc4301 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
 <!ENTITY rfc4555 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml'>
 <!ENTITY rfc5996 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml'>
 <!ENTITY rfc4960 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml'>
 <!ENTITY rfc6182 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6182.xml'>
 <!ENTITY I-D.arora-ipsecme-ikev2-alt-tunnel-addresses PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arora-ipsecme-ikev2-alt-tunnel-addresses.xml'>
]>

<rfc category="std" ipr="trust200902" docName="draft-mglt-mif-security-requirements-03.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>

<front>
  <title abbrev="IPsec MIF Problem Statement">IPsec Multiple Interfaces Problem Statement</title>

  <author fullname='Daniel Migault' initials='D.M' surname="Migault" >
    <organization>Francetelecom - Orange</organization>	
    <address>
      <postal>
        <street>38 rue du General Leclerc</street>
	<city>92794 Issy-les-Moulineaux Cedex 9</city> 
	<country>France</country>
      </postal>		
      <phone>+33 1 45 29 60 52</phone>
      <email>mglt.ietf@gmail.com</email>
    </address>
  </author>

  <author fullname='Carl Williams' initials='C.W' surname="Williams" >
    <organization>MCSR Labs</organization>	
    <address>
      <postal>
        <street></street>
	<city>Philadelphia, PA  19103</city> 
	<country>USA</country>
      </postal>		
      <phone> 650-279-5903</phone>
      <email>carlw@mcsr-labs.org</email>
    </address>
  </author>


  <date month="November" year="2012"/>
  <area>INTERNET</area>
  <workgroup>MIF Working Group</workgroup>
  <abstract>
      <t>IKEv2 is the protocol used to set up and negotiate Security Associations between nodes. IKEv2 has not been designed for nodes with multiple interfaces.</t>
      <t>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.</t>  
</abstract>
</front>


<middle>
<section title="Requirements notation">
	<t>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 <xref target="RFC2119"/>.</t>
</section>

<section title="Introduction" anchor="sec-introduction">


    <t>IPsec protocol suite <xref target="RFC4301"></xref>,<xref target="RFC5996"></xref> is mainly used to:
        <list style="hanging" hangIndent="6">
            <t hangText="- 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.</t>
            <t hangText="- 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.</t>  
        </list>
    </t>

   <t>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.</t>  

  <t>Protocols like SCTP <xref target="RFC4960"/> or MOBIKE <xref target="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.</t>

  <t>However, multihoming does not enable the simultaneous use of multiple interfaces which can provide a better use of the available bandwidth. MPTCP <xref target="RFC6182"/> has been designed for that purpose, and SCTP <xref target="RFC4960"/> can also be used for it. Raiciu and al. <xref target="Raiciu"/> showed how using multiple paths improve the performances and robustness of 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 <xref target="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.</t> 

  <t>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. </t>

  <t>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.</t>
 
  <t> <xref target="sec-uc1"/> considers the specific case of VPN with multiple interfaces. <xref target="sec-uc2"/> extends the previous use case by considering the general case of IPsec protected communications using the Tunnel mode. Finally <xref target="sec-uc3"/> 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</t>

</section>

<section title="Use Case 1: VPN with Multiple Interfaces" anchor="sec-uc1">

    <t>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}).</t>

        <figure>
            <artwork>
               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
              </artwork>
         </figure>


    <section title="Initial MIF IPsec Configuration" anchor="sec-uc1-init">

    <section title="Description" anchor="sec-uc1-init-des">

    <t>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.</t> 

    <t>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. </t>

    <t> 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.</t>

    <t>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.</t> 
    </section>

    <section title="Problem Statement" anchor="sec-uc1-init-pbl">

    <t> This section positions the current IKEv2 specifications toward the scenario described in <xref target="sec-uc1-init-des"/></t>

    <t> 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 <xref target="RFC5996"/>).</t>

    <t>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. <xref target="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 <xref target="sec-uc3"/> the more general case SHOULD consider that both initiator and responder can advertise the available interface when the IKEv2 negotiation is initiated.</t>

    <t>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 <xref target="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.</t>

   <t>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.</t>  

    <t>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.</t>

        <figure>
            <artwork>
               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
              </artwork>
         </figure>
   </section>

   <section title="Requirements" anchor="sec-uc1-init-req">

    <t>In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible:
       <list style="hanging" hangIndent="6">
             <t hangText="- 1. ">To specify the different outer IP addresses for the tunnel mode in the Security Association negotiation.</t>
             <t hangText="- 2. ">Make possible the Responder and Initiator to announce its interfaces.</t>
       </list>
   </t>

    </section>
</section>


   <section title="Mobility" anchor="sec-uc1-mob">

   <section title="Description" anchor="sec-uc1-mob-des">

   <t>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.</t>

    <t> 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.</t>

   <t>Figure 3 illustrates the case where EU @IP_outer4 is using the same network hardware interface as EU @IP_outer3. This corresponds to the 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}.</t> 

        <figure>
            <artwork>
               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
              </artwork>
         </figure>

   </section>

   <section title="Problem Statement" anchor="sec-uc1-mob-pbl">

    <t>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 <xref target="sec-uc1-mob-des"/></t>

    <section title="MOBIKE">
    <t>MOBIKE <xref target="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.</t>

    <t> 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.</t>

    <t>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. 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.</t>

    <t>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.</t>

   <t>As a result MOBIKE cannot be used to handle the mobility described in <xref target="sec-uc1-mob-des"/>.</t>
   </section>

   <section title="CREATE_CHILD_SA">

   <t>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 <xref target="RFC5996"/>) to create a new Security Association. Similarly <xref target="sec-uc1-init-pbl"/> 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 <xref target="sec-uc1-mob-des"/>.</t>

   <t>If requirements of <xref target="sec-uc1-init-req"/> 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:
        <list style="hanging" hangIndent="6">
            <t hangText="- 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.</t>
            <t hangText="- 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 a Security Association.</t>
            <t hangText="- 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 <xref target="RFC5996"/>. The Delete Payload specifies the Security Associations to Delete.</t> 
            <t hangText="- 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).</t>
        </list>
   </t>
   </section>

   <section title="One IKE channel per Interface">
  <t>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.</t>
   </section>

   </section>

   <section title="Requirements" anchor="sec-uc1-mob-req">

    <t>In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
       <list style="hanging" hangIndent="6">
             <t hangText="- 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 address is replaced by the new IP address. This consists in extending MOBIKE UPDATE_SA_ADDRESSES exchange.</t>
       </list>
   </t>
   </section>

   </section> <!-- End of mobility section -->

    <section title="Multihoming" anchor="sec-uc1-mul">

    <section title="Description" anchor="sec-uc1-mul-des">
    <t>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.</t>

    <t>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.</t>

    <t>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.</t>

        <figure>
            <artwork>
               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 
                       Multiple Interfaces: EU @IP_outer3 unreachable
              </artwork>
         </figure>
        <figure>
            <artwork>
               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
              </artwork>
         </figure>
   </section>


   <section title="Problem Statement" anchor="sec-uc1-mul-pbl">

     <t>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.</t>

<t>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.</t>

   </section>

   <section title="Requirements" anchor="sec-uc1-mul-req">

    <t>In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
       <list style="hanging" hangIndent="6">
          <t hangText="- 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.</t>
          <t hangText="- 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.</t>
       </list>
 </t>
   </section>
   </section> <!-- End of section Multihoming -->
 
   <section title="Adding an Interface" anchor="sec-uc1-add">
  
   <section title="Description" anchor="sec-uc1-add-des">
   <t>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.</t>

   <t>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 <xref target="sec-uc1-mob"/>.</t> 

 
   <figure>
            <artwork>
               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
              </artwork>
         </figure>

        <figure>
            <artwork>
               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
              </artwork>
         </figure>

   <t>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.</t>

   <figure>
            <artwork>
               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
              </artwork>
         </figure>

        <figure>
            <artwork>
               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
              </artwork>
         </figure>



   <t>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.</t>

   <t>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.</t>

   <t>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. </t>

   <t> 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.</t>

   <t>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.</t>  

   <t>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.</t>

        <figure>
            <artwork>
               End User                 Security Gateway

   request    Add Interface (EU @IP_inner3, ---&gt;
              EU @IP_outer3, [outer-destination]
              [interface-list] [nonce])

   normal case                       &lt;--- N()

   error case                        &lt;--- N(error)

            Figure 10: Principle of the Adding Interface 
                      exchange                             
            </artwork>
       </figure>
   </section>

   <section title="Problem Statement" anchor="sec-uc1-add-pbl">

   <t>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 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 <xref target="sec-uc1-init-pbl"/>. 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.</t>

   <t>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 <xref target="sec-uc1-mob-pbl"/>. The key advantage of adding an interface is to provide an optimized interface management exchange instead of a Security Association management exchange.</t>
   </section>

   <section title="Requirements" anchor="sec-uc1-add-req">
    <t>In order to make the End User set its IPsec configuration as represented in figure 1, IKEv2 SHOULD make possible:
       <list style="hanging" hangIndent="6">
             <t hangText="- 1. ">Make possible the Responder and Initiator to announce its interfaces outside the IKE_INIT exchange. This requirements is similar to the one of <xref target="sec-uc1-init-req"/></t>
             <t hangText="- 1. ">Make possible the Responder and Initiator to automatically derive Security Associations and Security Policies from the existing interface.</t>
       </list>
   </t>
   </section>
   </section> <!-- end of adding -->
   

   <section title="Deleting an Interface" anchor="sec-uc1-del">

   <section title="Description">
   <t>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.</t>
   </section>

   <section title="Problem Statement">
   <t> Currently IKEv2 does not make possible to delete an interface from multiple Security Associations. IKEv2 provides a Delete Payload (Section 3.11 <xref target="RFC5996"/> that deletes one or multiple specific Security Associations, identified by their SPI.</t> 
   </section>

   <section title="Requirements">
    <t>In order to make the End User set its IPsec configuration as represented in figure 3, IKEv2 SHOULD make possible:
       <list style="hanging" hangIndent="6">
         <t hangText="- 1. ">Delete an interface, that is to say all Security Associations associated to that interface. </t>
      </list>
      </t>
   </section>
   </section> <!-- End of section for Delete -->

</section> <!-- End of section use case -->

<section title="Use Case 2: MIF applications and IPsec Tunnel mode" anchor="sec-uc2">

     <t>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.</t>

   <t>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 <xref target="sec-uc1"/>.</t>

    <t>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.</t>

    <t>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).</t>

   <t>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.</t>

   <t>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 require "s" exchanges whereas using the Adding interface exchange requires only one exchange. This use case is represented in figure 11.</t> 


        <figure>
            <artwork>
               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
              </artwork>
         </figure>

   <t>Requirements of this use case have already been mentioned in the VPN use case.</t>
 
</section>

<section title="Use Case 3: MIF aware applications with Transport mode" anchor="sec-uc3">

   <t>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.</t>
   <t>Unlike in the VPN use case in <xref target="sec-uc1"/> or for multiple interfaces aware applications described in <xref target="sec-uc2"/> using IPsec tunnel mode, the IPsec Transport mode does not involves inner IP addresses.</t>
   <t>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.</t>

        <figure>
            <artwork>
               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
              </artwork>
         </figure>

   <section title="Initial MIF IPsec Configuration" anchor="sec-uc3-init">

   <section title="Description" anchor="sec-uc3-init-des">
      <t>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.</t>
  </section> 

  <section title="Problem Statement" anchor="sec-uc3-pbl">
      <t>Currently IKEv2 does not make possible a node to announce its available interfaces.</t>
      <t>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.</t>
   </section>

   <section title="Requirements" anchor="sec-uc3-req">
      <t>In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible
       <list style="hanging" hangIndent="6">
             <t hangText="- 1. ">Make possible the Responder and Initiator to announce its interfaces. This requirement is similar to the requirements for VPNs.</t>
       </list>
   </t>

   </section>
   </section> <!-- End of init -->

   <section title="Mobility" anchor="sec-uc3-mob">
   
        <t>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.</t>

        <t>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.</t>

        <t>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: 
            <list style="hanging" hangIndent="6">
               <t hangText="- 1. ">For End Users with two interfaces. In that case, the interface the application may use s determined. </t>
               <t hangText="- 2. ">For applications that are configured with two interfaces.</t>
               <t hangText="- 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.</t>
               <t hangText="- 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.</t>
            </list>
        </t>

   <section title="Description" anchor="sec-uc3-mob-des">

   <t>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 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.</t>

        <figure>
            <artwork>
               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.
              </artwork>
         </figure>

        <figure>
            <artwork>
               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.
              </artwork>
         </figure>


   </section>
   <section title="Problem Statement" anchor="sec-uc3-mob-pbl">
   <t>Currently IKEv2 does not provide extension that perform any mobility operation.</t>

   <t>MOBIKE has only been designed for the Tunnel mode.</t>

   <t>The CREATE_CHILD_SA suffers for limitations exposed in <xref target="sec-uc1-mob-pbl"/>: It is not mandatory in IKEv2 implementation, the exchange requires 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.</t>
   </section>
   <section title="Requirements" anchor="sec-uc3-mob-req">
      <t>In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible
       <list style="hanging" hangIndent="6">
             <t hangText="- 1. ">Extend MOBIKE to the Transport mode</t>
             <t hangText="- 2. ">Extend MOBIKE with Transport mode to multiple interfaces requirements described in <xref target="sec-uc1-mob-req"/>.</t>
       </list>
   </t>

   </section>
   </section> <!-- end of mobility section -->

   <section title="Multihoming" anchor="sec-uc3-mul">

   <t>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.</t>

   <section title="Description" anchor="sec-uc3-mul-des"> 

   <t>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.</t>

   <t>When EU @IP_outer3 is down, then the End User or the Server triggers a mobility exchange as described in section <xref target="sec-uc3-mob-des"/>.</t>
   </section>

   <section title="Problem Statement" anchor="sec-uc3-mul-pbl">

   <t>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 <xref target="sec-uc1-mul-pbl"/>, 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.</t>

<t>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 the tunnel outer IP address. </t>

<t>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.</t>
   </section>

   <section title="Requirements" anchor="sec-uc3-mul-req">
      <t>In order to make the End User set its IPsec configuration as
   represented in figure 1, IKEv2 SHOULD make possible to:
       <list style="hanging" hangIndent="6">
             <t hangText="- 1. ">Extend MOBIKE Multihoming to the Transport mode</t>
             <t hangText="- 2. ">Extend MOBIKE with Transport mode to multiple interfaces requirements described in <xref target="sec-uc1-mul-req"/>. 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.</t>
       </list>
   </t>
   </section>
   </section><!-- End of Multihoming -->

   <section title="Adding an Interface" anchor="sec-uc3-add">
   <t>Adding an interface works exactly as described in <xref target="sec-uc1-add"/>. 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.</t>  
   </section> <!-- End of Add -->

   <section title="Delete an Interface" anchor="sec-uc3-del">
   <t>Similarly to the addition of a new interface, Deleting an interface works exactly as described in <xref target="sec-uc1-del"/>. 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.</t>
   </section><!-- End of Delete -->

   </section> <!-- End of UC3 -->
<!--
   <section title="CREATE_CHILD_SA" anchor="sec-create-child-sa">

   <t>The current IKEv2 exchange used to create a Security Association is the CREATE_CHILD_SA exchange described in <xref target="RFC5996"/> Section C4, also represented in figure 8.</t>
        <figure>
            <artwork>

  request             ++&gt; [N(REKEY_SA)],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Ni, [KEi], TSi, TSr
                           [V+][N+]

   normal              &lt;++ [CP(CFG_REPLY)],
   response                [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Nr, [KEr], TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)]
                           [V+][N+]

   error case          &lt;++ N(error)

   different Diffie-   &lt;++ N(INVALID_KE_PAYLOAD),
   Hellman group           [V+][N+]
   wanted

              Figure 15 Detail of the CREATE_CHILD_SA (from RFC5996 C.4)
              </artwork>
         </figure>

   <t>In our case, we are not rekeying as Security Association, but creating it. The REKEY_SA Notify Payload is not expected. Then, we assumed that the End User already had the EU @IP_inner3 address, so the End User doe not needs to request an IP address to the Security Gateway: The Configuration Payload is not expected. Depending if the End User wants to use IPCompression, one or multiple IPComp Notify Payloads MUST be mentionned. In the case of VPN, the IPsec Tunnel mode is used so the Notity USE_TRANSPORT_MODE is not expected. We can reasonably beleive that TFC padding is supported, so the ESP_TFC_PADDING_NOT_SUPPORTED notify payload is not expected. In order to deal with fragmentation, the NON_FIRST_FRAGMENTS_ALSO is expected. We can also reasonably suppose that the Diffie Hellman is not re-generated so the KEi KEr Payloads are not expected. Finally, SA, Ni, TSi, TSr are mandatory. As a result, the expected CREATE_CHILD_SA in our VPN case is represented in figure 9.</t>
        <figure>
            <artwork>

  request             ++&gt;[N(NON_FIRST_FRAGMENTS_ALSO)],
                            [N(USE_TRANSPORT_MODE)],
                           SA, Ni, TSi, TSr

   normal              &lt;++ [N(NON_FIRST_FRAGMENTS_ALSO)],
   response                   SA, Nr, TSi, TSr 

   error case          &lt;++ N(error)

   different Diffie-   &lt;++ N(INVALID_KE_PAYLOAD),
   Hellman group           [V+][N+]
   wanted

              Figure 16 Detail of the CREATE_CHILD_SA (from RFC5996 C.4)
              </artwork>
         </figure>

 
   </section> <!++ create-child-sa ++>
-->
<section title="Security Considerations">
<t>The whole document sets MIF requirements for a security protocol.</t>
</section>

<section title="IANA Considerations">
<t>There is no IANA consideration here.</t>
</section>

<section title="Acknowledgment">
<t>We would like to thank Daniel Palomares, Pierrick Seite, Brian Carpenter, Hui Deng, Jong-Hyouk Lee, Juan Carlos Zuniga and Konstantinos Pentikousis for their useful comments.</t>
</section>

</middle>


<back>

<references title='Normative References'>
 &rfc2119;
 &rfc4301;
 &rfc4555;
 &rfc4960;
 &rfc5996;
</references>
<references title='Informational References'>
 &rfc6182; 
 &I-D.arora-ipsecme-ikev2-alt-tunnel-addresses;
<reference anchor="Cisco">
    <front>
        <title>Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2010-2015</title>
        <author fullname="Cisco">
        <organization/></author>
        <date month="February" year="2011"/>
     </front>
    <format type="HTML" target="http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.html"/>
</reference>

<reference anchor="Raiciu">
    <front>
        <title>Improving datacenter performance and robustness with multipath TCP</title>
        <author initials="C" surname="Arora" fullname="C. Raiciu">
        <organization/></author>
        <author initials="S" surname="Barre" fullname="S. Barre">
        <organization/></author>
        <author initials="C" surname="Plunkte" fullname="C. Plunkte">
        <organization/></author>
        <author initials="A" surname="Greenhalgh" fullname="A. Greenhalgh">
        <organization/></author>
        <author initials="D" surname="Wischik" fullname="D. Wischik">
        <organization/></author>
        <author initials="M" surname="Handley" fullname="M. Handley">
        <organization/></author>
        
       <date month="August" year="2011"/>
    </front><seriesInfo name="SIGCOMM 2011" value="Toronto, Canada"/>
</reference>

</references>
</back>
</rfc>




