<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1876 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1876.xml">
<!ENTITY rfc4555 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml">
<!ENTITY rfc5389 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY rfc5768 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5768.xml">
<!ENTITY rfc5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY rfc4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc6027 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6027.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">
<!ENTITY I-D.mglt-ipsecme-security-gateway-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-security-gateway-discovery.xml">
<!ENTITY I-D.mglt-mif-security-requirements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mglt-mif-security-requirements.xml">
]>
<rfc category="std"
     docName="draft-mglt-ipsecme-alternate-outer-address-00.txt"
     ipr="trust200902">
  <front>
    <title abbrev="Alternate Outer IP Address Extension">IKEv2 Alternate Outer IP Address Extension</title>

    <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
      <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>

    <date month="February" year="2013"/>

    <area>SECURITY</area>

    <workgroup>IPSECME</workgroup>

    <abstract>
      <t>Current IKEv2 protocol has been designed to establish VPNs with the same outer IP addresses as those used for the IKEv2 channel. This describes the alternate outer IP address extension, and IKEv2 extension that enables the VPN End User to negotiate a VPN on different interfaces as those used for the IKEv2 channel.</t>
      <t>Thus, this extension makes possible a VPN End User with multiple interfaces to set an IPsec tunnel on each interface with a Security Gateway by using a single IKEv2 channel instead of using an IKEv2 channel per interface. Similarly, for distributed Security Gateways, it also makes possible to split the IKEv2 and IPsec traffic on different interfaces.</t> 

    <!-- <t>While VPN End Users and Security Gateways only have a single interface, there were no need to negotiate outer IP addresses other than the ones used by the IKEv2 channel. However, it becomes very common that VPN End Users and Security Gateways have multiple interfaces. This configuration of outer IP address prevents to take fully advantage of the multiple interfaces and multi paths facilities. In fact currently the only way to deal with interface or path selection is to establish as many IKEv2 channel as there are paths between the VPN End User and the Security Gateway</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">
        <t>When a VPN End User establishes a VPN with a Security Gateway, it starts by establishing an authenticated channel for IKEv2. Then the VPN Security Associations <xref target="RFC4301"/> are negotiated via the IKEv2 <xref target="RFC5996"/> channel. Once the peers agree on the Security Associations, the VPN can be used.</t>

        <t>Currently, IKEv2 does not negotiate the outer IP addresses of the VPN. The security Association  set these VPN outer IP addresses as the IP addresses used by the IKEv2 channel.</t>

        <t>These implicit values are perfect for VPN End Users with a single interface. This was the case for a long time, making them unnecessary to be negotiated. However, today's VPN End Users and Security Gateways have multiple interfaces. Relying on the default value of the VPN outer IP addresses makes it hard, - or at least in a non optimal way - to take advantage of multiple interfaces. This document specifies how alternate outer IP addresses can be negotiated during the Security Association negotiation. This involves new signaling, thus the document also specify how the VPN End User and the Security Gateway can optionally inform each other they support the alternate outer IP address extension.</t>

        <t>The remaining of this document is as follows. <xref target="sec-terminology"/> defines the terminology used in this document. <xref target="sec-scenario"/> provides scenarios that motivate this alternate outer IP address extension. <xref target="sec-overview"/> describes the new protocol, as well as the new involved entities and <xref target="sec-payload-formats"/> describes the payload format defined for the protocol. In this document, we assumed that no NAT are between the VPN End User and the Security Gateway, however, <xref target="sec-nat-considerations"/> provides some considerations when NAT is used.</t> 

<t>The alternate outer IP address extension provides VPN End Users and Security Gateway a way to take advantage of multiple interfaces for a VPN service.</t>

    </section>


    <section title="Terminology"
             anchor="sec-terminology">
        <t>This section defines terms and acronyms used in this document.
          <list hangIndent="6" style="hanging">
              <t hangText="- VPN End User: "> designates the End User that initiates the VPN with a Security Gateway. This End User may be mobile and moves its VPN from on Security Gateway to the other.</t>

              <t hangText="- Security Gateway: "> designates a point of attachment for the VPN service. In this document, the VPN service is provided by multiple Security Gateways. Each Security Gateway may be considered as a specific hardware. </t>
              <t hangText="- Security Association (SA): ">The Security Association is defined in <xref target="RFC4301"/>.</t>
          </list>
      </t>

    </section>


    <section title="Alternate outer address scenarios"
             anchor="sec-scenario">

        <t>This section provides scenarios where a VPN End User and a Security Gateways share more than one VPN. For each scenario, the document describes the alternatives that currently exist, their limitations and the motivations for the alternate outer IP address extension. The scenarios herein are a subset of the scenarios described in <xref target="I-D.mglt-mif-security-requirements"/>.</t>
 
        <section title="VPN End User with Multiple Interfaces"
                 anchor="sec-scenario-eu-mif">
        <t> More and more terminals have multiple interfaces, and a VPN End User may take advantage of these multiple interfaces by setting multiple tunnels with its Security Gateways as represented in figure 1. A typical example would be a VPN End User attached to its Radio Access Network via Interface_0 and attached to a WLAN access point via Interface_1. The VPN End User may use one or the other interface according to the Quality of Service or the fees associated to each network. In figure 1. the VPN End User has established two distinct VPNs, one on each of its interfaces. Both VPNs are attached to the same Security Gateway interface. A packet can be sent or received from either one or the other VPN.</t>

             <figure>
                 <artwork>
+------------+                                +------------+
|            | Interface_0 : VPN_0            |            |
|            ===================              |  Security  |
|    VPN     |                  v             |  Gateway   |
|  End User  |                   ==============            |
|            ========================^        |            |
|            | Interface_1 : VPN_1            |            |
+------------+                                +------------+

            Figure 1:  VPN End User with Multiple Interfaces 
                 </artwork>
             </figure>

        <t>SAs negotiated for the VPN_0 and VPN_1 have the same network configuration except that the outer interface of VPN_0 on the End User side is Interface_0 whereas VPN_1 has Interface_1. More specifically, these SAs have the same Selectors.</t>

        <t> <xref target="RFC4301"/> section 4.1 states that parallel SAs are compliant with the IPsec architecture, and that traffic may be sent to one or the other VPN, for example, according to the Differentiated Services Code Point (DSCP). DSCP is called a "classifier" which differs from the Selector. How the End User chooses which interface to use is beyond the scope of this document.</t>

        <t>As mentioned in <xref target="RFC5996"/> the VPN uses the IP addresses of the IKEv2 channel as outer IP addresses. One way to establish these two VPNs is to create an IKEv2 channel for each interface. This results in unnecessary IKE negotiations with multiple authentications Nbr(EU_interfaces) X Nbr(SG_interface) X Nbr(Flows). This number rapidly grows with the number of involved interfaces both on the Security Gateway and on the End User.</t>

        <t><xref target="RFC6027"/> section 3.8 mentions that peers using different IP addresses for the VPN and the IKEv2 channel SHOULD be modified unless they may drop the packets. The alternate outer IP address described in this document is described so that any VPN End User can interact with any Security Gateway.</t>

        <t><xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> addresses this issue. The End User VPN indicates during the SA negotiation the outer IP address it wants, and in return the Security Gateway indicates the outer IP address of the Security Gateway. Motivations for <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> is a cluster of Security Gateways that splits the IKEv2 traffic and the VPN traffic, so that the VPN traffic avoids overloading some equipments like firewalls or load balancers for example.</t>
        <t> <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> would also address the case of figure 1 because the the path used by the VPN is defined by the interface used by the VPN End User VPN. This results from the fact that the Security Gateway has only one interface. However, <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> would need slight modifications in order to address the more general case where VPN End User and the Security Gateways have multiple interfaces. In that case, a path would be defined not by a single interface (as in figure 1), but by a pair of interface. </t>
        <t> In addition to path negotiation, <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> uses a Notify Payload that is not bound to a SA Proposal, thus making multiple SA Proposals with different outer IP address difficult. Again this case is very specific to multiple interfaces. Even though the protocol described in this document address these limitations, it remains very closed to <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/>.</t>
        </section>

        <section title="Security Gateway with Multiple Interfaces"
                 anchor="sec-scenario-sg-mif">

        <t>In the scenario presented in figure 2, the VPN End User has two interfaces and the VPN End User has a single interface. Like the VPN End User with multiple interfaces presented in <xref target="sec-scenario-eu-mif"/>, we suppose that the VPNs are established by the VPN End User with the Security Gateway. Unlike the scenarios of <xref target="sec-scenario-eu-mif"/>, motivations for choosing VPN_0 or VPN_1 are not associated to the interface used by the VPN End User, but the path taken by the packets. As a result, the VPN End User cares about both source and destination outer IP addresses that defines the path. </t>   
         
             <figure>
                 <artwork>
+------------+                                +------------+
|            |            Interface_0 : VPN_0 |            |
|            |                    =============  Security  |
|    VPN     |                   v            |  Gateway   |
|  End User  ===================              |            |
|            |                   ^ ============            |
|            |            Interface_1 : VPN_1 |            |
+------------+                                +------------+

            Figure 2:  Security Gateway with Multiple Interfaces 
                 </artwork>
             </figure>

            <t>Comments of <xref target="sec-scenario-eu-mif"/> also applies to this scenario, but this scenario stresses that the choice of the VPN outer IP addresses SHOULD result from a negotiation between the two peers, and both outer IP addresses SHOULD be negotiated.</t>

            <t>Note that the scenario described in figure 2, considers that all interfaces are used to setup all different VPNs. As described in <xref target="sec-scenario-eu-mif"/>, if VPN End Users and Security Gateways have both multiple interfaces, setting up all possible tunnels may be unnecessarily heavy. As a result, the VPN End User SHOULD be able to negotiate both outer IP addresses of its VPN.</t> 

            <t>Note that if the VPN End User negotiates the outer IP address used by the Security Gateway, the VPN End User may know in advance what interfaces are available. It is beyond the scope of this document to define how the VPN End User may know this information. MOBIKE <xref target="RFC4555"/> defines the ADDITIONAL_IP*_ADDRESSES Notify Payload, and <xref target="I-D.mglt-ipsecme-security-gateway-discovery"/> defines how these pieces of information may be provided by other Security Gateways.</t>
        </section>
 
        <section title="Distributed Security Gateways">
             <t>The scenario described in figure 3 considers a distributed Security Gateway. The IKEv2 channel and the VPNs are handled by different nodes. As a result the VPN does not uses the same outer IP addresses as the IKEv2 channel.</t>

             <figure>
                 <artwork>
+------------+                                +------------+
|            |                    Interface_0 |  IKE       |
|            |  IKEv2 channel    ^-------------  Security  |
|    VPN     ------------------- ^            |  Gateway   |
|  End User  =================== v            +------------+
|            |  VPN channel      v            +------------+
|            |                   v Interface_1| VPN        |
+------------+                   v============= Security   |
                                              | Gateway    | 
                                              +------------+
                                                   ...
                                              +------------+
                                   Interface_i| VPN        |
                                  ============= Security   |
                                              | Gateway    | 
                                              +------------+

            Figure 3: Distributed Security Gateways 
                 </artwork>
             </figure>
            <t>This scenario is addressed by <xref target="I-D.arora-ipsecme-ikev2-alt-tunnel-addresses"/> where each part can choose the interface it will use as the outer IP address for the VPN. As mentioned in <xref target="sec-scenario-eu-mif"/>, being able to specify a single interface is not sufficient to select a path. More specifically, in figure 3, this would not provide the possibility for the VPN End User to choose between Interface_1 and Interface_i.</t>
        </section>

    </section> <!--end of scenario section -->

 

    <section title="Protocol Overview"
             anchor="sec-overview">

        <t>The alternate outer IP address extension, makes possible two peers to negotiate and agree on alternate IP addresses for their VPN. We consider the outer IP addresses as parameters of the Security Association. (Tunnel header IP source and destination address as described in <xref target="RFC4301"/>). As a consequence, the negotiation of these parameters occurs during the negotiation of the Security Association, that is during the IKE_INIT exchange or the CREATE_CHILD_SA exchange as described in <xref target="RFC5996"/>.</t>

        <t>VPN SA negotiation can be initiated by either VPN End User or the Security Gateway, so in the remaining of the document we simply use initiator and responder, as the peer initiating the negotiation.</t>

        <t>Note that these negotiations makes possible that any peer can negotiate one, or both outer IP address, that is to say, the outer IP address source and destination.</t>

        <t><xref target="sec-alternate-outer-ip-address-transform"/> briefly reminds how the Security Association' parameters are negotiated with IKEv2, and then proposes the new involved payloads to negotiate the outer IP addresses. Basically a new Alternate Outer Address Transform  (OADD) and a new IP Attribute are defined. <xref target="sec-init-sending-oadd"/> and <xref target="sec-resp-receiving-oadd"/> and <xref target="sec-reject-oadd"/> are focused on the exchanged when both peers support the alternate outer IP address extension. <xref target="sec-init-sending-oadd"/> describes how the initiator builds a SA Proposal and  <xref target="sec-resp-receiving-oadd"/> defines how the responder handles it. <xref target="sec-reject-oadd"/> defines the case where the Proposal MUST be discarded. Although not mandatory, there MAY be an advantage that peers are informed whether the alternate outer IP address is supported or not before sending Proposals. <xref target="sec-supporting-alternate-outer-ip-address"/> presents how peers can inform each other the support this extension. At last, <xref target="sec-basic-exchange"/> illustrates the different exchanged described in the document.</t>
 
        <section title="Alternate outer IP addresses Transform"
                 anchor="sec-alternate-outer-ip-address-transform">

        <t>This section does not intend to explain how SAs are negotiated, and the reader is expected to refer to  <xref target="RFC5996"/> section 3.3. This section briefly sums up the different type of payload involved in order to clarify our purpose. Figure 4 is copied from <xref target="RFC5996"/> to illustrate concepts involved in the Security Association negotiation.</t>

             <figure>
                 <artwork>
   SA Payload
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 transforms,      SPI = 0x052357bb )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 128 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 192 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 256 )
      |     |
      |     +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Transform ESN ( Name = ESNs )
      |     +-- Transform ESN ( Name = No ESNs )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
            |            4 transforms,      SPI = 0x35a1d6f2 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 128 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 256 )
            |
            +-- Transform ESN ( Name = ESNs )
            +-- Transform ESN ( Name = No ESNs )

            Figure 4: Security Association Payload Structure 
                 </artwork>
             </figure>
  
        <t>A Security Association is defined by various parameters such as Encryption (ENCR) or Integrity (INTEG), Pseudorandom Function (PRF), Diffie-Hellman group (D-H) or Extended Sequence Numbers (ESN). These parameters are defined through Transforms and each parameter is a Transform Type.</t>  
        <t>A Security Association is negotiated through the SA Payload which contains one or more Proposals Payloads. Each Proposal contains one or multiple acceptable "values" for each Transformed Type. These "values" can be seen as an OR. The Proposal is accepted if for each Transform Type one of the proposed "value" is accepted by the responder. If the responder cannot choose an acceptable "value" for each Transform Type, the proposition is rejected. A "value" is composed of a Transform ID, like the name of the encryption algorithm, and eventually one or more Attributes, like the key length for example.</t>

        <t>In our case, we consider a new Transform Type OADD. This Transform Type has two Transform ID (INIT or RESP) that designates the initiator outer IP address (INIT) or the responder outer IP address (RESP). The Attributes associated to each Transform ID is the IP Attribute that can be an IPv4 address, an IPv6 address or a specific value.</t>
       </section>
 
        <section title="Initiator: Sending OADD Transforms in Proposals"
                 anchor="sec-init-sending-oadd">

        <t>In <xref target="sec-init-sending-oadd"/> and <xref target="sec-resp-receiving-oadd"/> we suppose that both the initiator and the responder support the alternate outer IP address extension, that no USE_TRANSPORT_MODE Notify Payload is sent in conjunction of the SA Payload, and that the Proposal Payload as defined in  <xref target="RFC5996"/> Section 3.3.1 has its Protocol ID set to AH or ESP. Other cases are discussed in <xref target="sec-reject-oadd"/></t>

        <t>If the initiator wants to propose the Security Gateway to choose among a set of the initiator's interfaces IP_init_0, ..., IP_init_k for the VPN outer IP address, it MUST include k+1 Transforms with Transform Type OADD and Transform ID set to INIT. The Transform is associated to the Attribute of Type IP. Transform Attributes are defined in <xref target="RFC5996"/> 3.3.5.</t>
       <t>Similarly, if the initiator wants to select on the Security Gateway one interface among a set of interface IP_resp_0, ..., IP_resp_l, it MUST include l+1 OADD Transform with Transform ID set to RESP, and an Attribute of Type IP.</t>

        <t>If the initiator does not know the interface that the responder may choose, it may indicate the responder to define the most appropriated interface with a OADD Transform with Transform ID set to RESP and an Attribute of Type with the specific value ANY_IP.</t>

        <t>If no OADD Transform with Transform ID set to INIT (Respectively RESP) are provided in the Proposal, the default value for the outer IP address is the one used by the IKEv2 channel. More specifically, if the initiator considers the interface used for the IKEv2 channel as an alternative to other IP addresses, a OADD Transform with this IP address MUST explicitly be in the Proposal.</t>

        <t>Note that a Proposal does not need to have both OADD Transform with Transform ID INIT and RESP. The initiator can choose to have only OADD Transforms with Transform ID INIT (respectively RESP).</t>
        </section>

        <section title="Responder: Receiving OADD Transforms in Proposals"
                 anchor="sec-resp-receiving-oadd">
        <t>As mentioned in <xref target="sec-init-sending-oadd"/>, we suppose the responder supports the alternate outer IP address extension. If a Proposal contains one or multiple OADD with a Transform ID set to INIT (respectively RESP), the responder choose one of these. If selected OADD Transform (INIT or RESP) with an IP Attribute, the responder returns the Transform without modification. Otherwise, if selected OADD Transform is with an ANY_IP Attribute, the responder returns a IP Attribute with the correct value.</t>

        <t>If the responder has no OADD Transform with Transform ID INIT (respectively RESP), then by default the outer IP address of the VPN is equal to the IP address used by the IKEv2 channel.</t> 

        </section>  

       <section title="Incompatible Proposal with OADD Transforms"
                anchor="sec-reject-oadd"> 
       <t>The alternate outer IP address extension only makes sense for the IPsec tunnel mode. The SA Payload with Proposals that contains one or more OADD Transforms MUST NOT be used with a USE_TRANSPORT_MODE Notify Payload. Responder MUST reject these Proposals.</t>

       <t>Similarly, Proposals with a Protocol other than AH or ESP, (that is to say IKE), MUST NOT be used with OADD Transforms. Responder MUST reject these Proposals.</t>

       <t>As mentioned in <xref target="RFC5996"/> Section 3.3.6, a responder that does not support the alternate outer IP address extension MUST reject any Proposal that contains a Transform with a  Transform Type OADD. If the responder rejects all Proposals, it MUST send a NO_PROPOSAL_CHOSEN Notify Payload.</t>   
       </section>


        
        <section title="Supporting alternate outer IP address exchange"
                 anchor="sec-supporting-alternate-outer-ip-address">

        <t>This section describes an  informational exchange where each peer informs the other that it supports the alternate outer IP address extension. This exchange is not mandatory, but is recommended as it MAY ease to format the Proposals for the Security Association negotiation.</t>

        <t>In fact the negotiation of the alternate outer IP address is included in SA negotiation. As described in <xref target="sec-alternate-outer-ip-address-transform"/>, this introduces new Transform Type and new Attributes. <xref target="RFC5996"/> Section 3.3.6 mentions that a peer does not understand the new Transform Type or the new Attributes, it MUST reject the Proposal. As a result, if the initiator does not know if the responder supports the alternate outer IP address extension, it SHOULD include proposals without the associated Transform Type and Attributes to avoid that all Proposals are rejected by the responder and receives a NO_PROPOSAL_CHOSEN Notify Payload.</t>
 
        <t>To limit the number of proposals to be sent by the initiator during the SA negotiation, we define the supporting alternate outer IP address exchange where the initiator can advertise it supports the alternate outer IP address extension by sending a ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload. When a node receives this Notify Payload and support the alternate outer IP address extension, it MUST send back the same Notify Payload.</t>
       </section>

       <section title="Basic Exchange"
                anchor="sec-basic-exchange">
    
       <t>Figure 5 provides a basic exchange. The initiator and the responder agree on supporting the alternate outer IP address extension. This exchange is optional but recommended. In Figure 5 this exchange occurs during the IKE_INIT exchange, but it MAY occur anytime.</t>
        <t>The SA negotiation consists in sending multiple Proposals. In figure 5, the OADD Transform specify the initiator and responder's IP address. The responder choose one of the proposed transformed.</t> 
             <figure>
                 <artwork><![CDATA[
   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni      -->
   N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED)
   N(NAT_DETECTION_SOURCE_IP),
   N(NAT_DETECTION_DESTINATION_IP)  
                          <--  HDR, SAr1, KEr, Nr, [CERTREQ]
                               N(ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED)
                               N(NAT_DETECTION_SOURCE_IP),
                               N(NAT_DETECTION_DESTINATION_IP)

   ====   From this exchange:
             - the Initiator and the Responder support the alternate 
               outer IP address extension 
             - no NAT has been detected       =====

   HDR, SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH,  TSi, TSr
        SAi2( Proposal(ENCR, INTEG, ESN,    < proposes IP1, IP2 for   
                  OADD(INIT, IP1),            the init., ANY IP for
                  OADD(INIT, IP2),            the resp.  
                  OADD(RESP, ANY_IP))          
              Proposal(ENCR, INTEG, ESN)))  < proposes to use IKEv2 IP
           }               -->                for the VPN outer IP   
           

                           <--  HDR, SK {IDr, [CERT,] AUTH, TSi, TSr, 
                                     SAr2(Proposal(ENCR, INTEG, ESN,
                                          OADD(INIT, IP1), 
                                          OADD(RESP, IPr)))
                                         }


            Figure 5: Basic Exchange for VPN alternate outer 
                      IP addresses negotiation 
                 ]]></artwork>
             </figure>
        </section>

    </section>

   <section title="Payload Formats"
            anchor="sec-payload-formats">

   <t>As mentioned in <xref target="sec-overview"/> this document introduces  a new Transform of Transform Type OADD. The associated Transform ID are INIT for the initiator outer IP address and RESP for the responder's IP address. These Transforms are associated a Attributes that are either carrying an IP address (IPv4 or IPv6) or associated to a specific value like ANY_IP.</t>

   <t>This document also introduces the ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED Notify Payload, so peers can inform the other they support the alternate outer IP address extension.</t>

   <t>This section describes the format of all new payload introduced for the outer IP address extension.</t>

       <section title="Outer IP address Transform OADD">

           <t>This section specifies the Transform structure as defined in <xref target="RFC5996"/> Section 3.3.2.</t>
             <figure>
                 <artwork><![CDATA[

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0 (last) or 3 |   RESERVED    |        Transform Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transform Type |   RESERVED    |          Transform ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Transform Attributes                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 6:  OADD Transform Substructure
                 ]]></artwork>
             </figure>
             <t>
                 <list hangIndent="6" style="hanging">
                     <t hangText="- 0 (last) or 3 (more) (1 octet):"> Specifies whether this is the last Transform Substructure in the Proposal.</t>
                     <t hangText="- RESERVED (1 octet): "> MUST be sent as zero; MUST be ignored on receipt. </t>
                     <t hangText="- Transform Length (2 octets): "> The length (in octets) of the Transform Substructure including Header and Attributes.</t>
                     <t hangText="- Transform Type (2 octets): "> The type of transform being specified in this transform. Set to OADD in this document.</t>
                     <t hangText="- Transform ID (2 octets): "> he specific instance of the Transform Type being proposed. Set to INIT or RESP in this document.</t>
                     <t hangText="- Transform Attributes (variable length): ">The IP Attribute in this document.</t>
                </list>
            </t>

       </section>

       <section title="IP Attribute with IP addresses">
           <t>This section specifies the Attribute structure as defined in <xref target="RFC5996"/> Section 3.3.5.</t>
             <figure>
                 <artwork><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|       Attribute Type        |    AF=0  Attribute Length     |
   |F|                             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           IP Address                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7: IP Attribute with IP address
                 ]]></artwork>
             </figure>
             <t>
                 <list hangIndent="6" style="hanging">
                     <t hangText="- Attribute Format (AF) (1 bit): "> Set to 0, indicating a TLV format.</t>
                     <t hangText="- Attribute Type (15 bits): "> Set to IP in this document.</t>
                     <t hangText="- Attribute Length (16 bits): "> The length is either 8 to designate the length of an IPv4 or 20 to designate the length of on IPv6 address. The length includes the headers of 4 octets.</t>
                </list>
            </t>

       </section>

       <section title="IP Attribute indicating ANY_IP">
           <t>This section specifies the Attribute structure as defined in <xref target="RFC5996"/> Section 3.3.5.</t>
             <figure>
                 <artwork><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|       Attribute Type        |     AF=1 Attribute Value      |
   |F|                             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8: IP Attribute set to ANY_ IP
                 ]]></artwork>
             </figure>
             <t>
                 <list hangIndent="6" style="hanging">
                     <t hangText="- Attribute Format (AF) (1 bit): "> Set to 1, Attribute Value.</t>
                     <t hangText="- Attribute Value (15 bits): "> Set to ANY_IP in this document.</t>
                </list>
            </t>
       </section>

       <section title="Alternate Outer IP Address Notify Payload">
           <t>This section presents the Notify Payload as defined in <xref target="RFC5996"/> Section 3.10.</t> 
             <figure>
                 <artwork><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |  SPI Size = 0 |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 9: Alternate Outer IP Address Notify Payload 
                 ]]></artwork>
             </figure>
             <t>
                 <list hangIndent="6" style="hanging">
                     <t hangText="- Next Payload (1 octet): ">Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.</t>
                     <t hangText="- Critical (1 bit):"> MUST be set to zero for payload types defined in this document.</t>
                     <t hangText="- RESERVED (7 bits):"> MUST be sent as zero; MUST be ignored on receipt.</t> 
                     <t hangText="- Payload Length (2 octets, unsigned integer):">Length in octets of the current payload, including the generic payload header. Set to 16 in this document.</t>
                     <t hangText="- Protocol ID (1 octet): "> This field MUST be sent as zero and MUST be ignored on receipt.</t>
                     <t hangText="- Notify Message Type (2 octets): "> Set to ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED in this document.</t>
                </list>
            </t>
       </section>

   </section>

    <section anchor="sec-nat-considerations" title="NAT considerations">

        <t>In the document we assumed that there were no NAT between the VPN End User and the Security Gateway. This means that the VPN End User and the Security Gateway know 1) the interface they are receiving data on is the interface used as a destination by the other peer and 2) the interface set as destination is the interface used by the other peer to receive the data. As a result, if the VPN End User (respectively the Security Gateway) is behind a NAT, the VPN End User may be seen by the Security Gateway (respectively the VPN End User) with another IP address unknown to the VPN End User (respectively the Security Gateway).</t>

        <t>NATs impact the alternate outer IP address extensions in two ways:
                 <list hangIndent="6" style="hanging">
                     <t hangText="- IPsec configuration: "> The alternate outer IP addresses the two peers are negotiating may not be the ones in the Security Associations. More specifically, suppose the VPN End User and the Security Gateway depicted in figure 10 have negotiated the alternate outer IP addresses src_0, dst_1. src_0 is NATted with NAT_0, and may be unreachable, the outer IP address in the Security Gateway SA should be src_nat_0 instead.</t>
                     <t hangText="- NAT traversal: ">NATs may make an IP address behind it reachable only if this IP address has initiated a connection. More specifically, suppose the VPN End User and the Security Gateway depicted in figure 10 have established an IKEv2 channel between src_0 and dst_1 and are MOBIKE enabled. Suppose the VPN End User sends the Security Gateway an ADDITIONAL_IP*_ADDRESS with src_1 or eventually with src_nat_1. Unless NAT_1 has been configured to forward the traffic from the Security Gateway to the VPN End User, this traffic will most likely be discarded by NAT_1. Similarly, if the Security Gateway moves the VPN from dst_0 to dst_1, the VPN may be broken. Note that we use MOBIKE to illustrate the problems of reachability through NATs, but these operations are discussed more in depth in <xref target ="RFC4555"/>.</t>
                 </list>
        </t>

       <t>This section does not intend to discussed all NATs configuration as described in <xref target="RFC5389"/>. Instead the only NAT scenario we consider is a single NAT and the VPN End User behind that NAT initiates the alternate outer IP address exchange. The architecture this section considers is depicted in figure 10. Furthermore, this section does not consider the NAT traversal aspect. We assume that the VPN End User is NAT aware and perform the necessary actions to make/configure the NATs so that they do not block the traffic.</t>

      <t><xref target="sec-prohibiting"/> defines how the End User MAY prohibit the alternate outer IP address extension if a NAT is detected. Then, in <xref target="sec-nat-detection"/> how the VPN End User can detect the presence of NAT. <xref target="sec-unknown-nat-ip"/> discusses the case where the VPN End User does not know the values of the NATted IP addresses and <xref target="sec-known-nat-ip"/> discusses the case where the VPN End User knows all NATted IP addresses values.</t> 


             <figure>
                 <artwork><![CDATA[
                                          +---+
+------------+                            | I |       +------------+
|            | src_0  +-------+ src_nat_0 | N | dst_0 |            |
|            =========| NAT_0 |===========| T |=======|  Security  |
|    VPN     |        +-------+           | E |       |  Gateway   |
|  End User  | src_1  +-------+ src_nat_1 | R | dst_1 |            |
|            =========| NAT_1 |===========| N |=======|            |
|            |        +-------+           | E |       |            |
+------------+                            | T |       +------------+
                                          +---+
            Figure 10: VPN End User behind a NAT scenario
                 ]]></artwork>
             </figure>

        <section anchor="sec-prohibiting" title="Prohibiting NAT">
        <t>This section considers that the VPN End User does not want to use the alternate outer IP address extension if a NAT is detected. This section differs from the NAT detection because it both detects the existence of a NAT and provide an indication that some supported functionalities like MOBIKE SHOULD NOT be used if a NAT is detected.</t>
       
        <t>The NO_NATS_ALLOWED Notify Payload is defined in <xref target="RFC4555"/>. If the VPN End User supports MOBIKE, it MAY send a NO_NATS_ALLOWED Notify Payload with the original IP addresses and ports. When the Notify Payload is received by the Security Gateway, it checks the IP addresses values in the IP header and in the Payload, in case of mismatch, a UNEXPECTED_NAT_DETECTED Notify Payload is returned.</t>

        <t>In our case, the NO_NATS_ALLOWED MAY be used by the VPN End User if both the VPN End User and the Security Gateway support MOBIKE. When the Security Gateway receives the NO_NATS_ALLOWED Notify Payload, it MUST NOT use MOBIKE and SHOULD NOT use the alternate outer IP address extension.</t> 
       
        <t>There are corner cases that are not considered by this policy. First, a VPN End User or a Security Gateway that do not support MOBIKE cannot use the NO_NATS_ALLOWED Notify Payload. However, it seems hardly possible that peers supporting the alternate outer IP address extension support MOBIKE. Second, a VPN End User using the NO_NATS_ALLOWED applies the same policy for MOBIKE and the alternate outer address extension. Here again, it seems unlikely that NAT policies differ. Furthermore, the NO_NATS_ALLOWED exchange only prevent the Security Gateway to initiate a MOBIKE or alternate outer IP address negotiation. The VPN End User can still use one or the other extension. From our experience, this constraint seems acceptable.</t>  
         
        </section>

        <section anchor="sec-nat-detection" title="NAT detection">
        <t>This section details how NAT can be detailed with IKEv2 extensions. We do not consider here other mechanisms like ICE described in <xref target="RFC5768"/> or STUN <xref target="RFC5389"/>.</t>

        <t>The VPN End User can detect the NAT  by using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP Notify Payload as described in <xref target="RFC5996"/>. These Notify Payloads carry the SHA-1 of the source (respectively the destination) IP address. At the reception, the Security Gateway can compare their contend with the SHA-1 of the IP addresses in the IP header. A mismatch between the two values indicates the presence of a NAT, but do not provide the value of the original IP address. Usually, this exchange is performed during the IKE_INIT exchange to decide whether or not IKEv2 should proceed to UDP encapsulation.</t>
       
        <t> Note that with the NAT detection exchange, the NAT is detected on the IKEv2 channel. If the IKEv2 channel is using src_0, the NAT detection exchange will detect NAT_0. To detect NAT_1 using IKEv2, the VPN End User SHOULD move the IKEv2 channel on src_1 with MOBIKE for example. Since the UPDATE_SA Notify Payload is initiated by the VPN End User, NAT_1 is expected to accept the traffic from the Security Gateway.  Note also that the NAT detection exchange does not provide the value of the src_nat* IP addresses.</t>
        </section>


        
        <section anchor="sec-unknown-nat-ip" title="The VPN End User does not know the NATted IP addresses">
        <t>This section analyses how the alternate outer IP address extension can be used when the VPN End User does not know the values of the NATted IP addresses, i.e. src_nat_0 and src_nat_1.</t>

        <t>In that case, the VPN End User MAY only select the destination outer IP address corresponding to the Security Gateway IP addresses. How the VPN End User gets these IP addresses is out of scope of the document, however, if the VPN End User and the Security Gateway support MOBIKE, the MOBIKE ADDITIONAL_IP*_ADDRESS Notify Payload MAY be used for that purpose. It is recommended that the VPN End User does not provide the outer source IP, in which case, the one from the IKEv2 channel will be considered by default. More specifically, the VPN End User cannot provide the Security Gateway its alternate IP addresses.</t>

        <t>The VPN End User MAY use the ANY_IP IP Attribute for the source outer IP address. This would enable the Security Gateway to select an alternate IP address that differs from the one used by the IKEv2 channel. In order to select the IP addresses associated to the VPN End User, the Security Gateway has to be aware of the NATted IP addresses depicted as src_nat_0 and src_nat_1. One possibility is that the Security Gateway log the IP addresses used by the VPN End User when it moves from src_0 to src_1. This also means that the VPN is being negotiated with a CREATE_CHILD_SA exchange after the initial IKE_INIT exchange.</t>
        </section>

        <section anchor="sec-known-nat-ip" title="The VPN End User does know the NATted IP addresses">
        <t> In this section the VPN End User knows the NATted IP addresses src_nat_0 and src_nat_1. How the End User get these values is out of scope of the document. This case should be considered only if the VPN End User exactly know what it is doing.</t> 
          
        <t>In this case, the VPN End User can proceed as if no NAT exist. The VPN End User  considers in the alternate outer IP address negotiation that its IP addresses are the NATted IP addresses that is src_nat_0 and src_nat_1. On the other hand, the VPN End User MUST configure properly its SAs with src_0 if src_nat_0 is selected or with src_1 if src_nat_1 is selected.</t>
        <t>The VPN End User is also responsible to make the NAT Traversal possible.</t> 

        </section>
    </section>

    <section title="IANA Considerations">
        <t>The new fields and number are the following:</t>
        <figure>
            <artwork>
    IKEv2 Notify Message Types - Status Types
    -----------------------------------------
    ALTERNATE_OUTER_IP_ADDRESS_SUPPORTED  TBD


    Transform Attribute Types
    -------------------------
    OADD                  TBD

    Transform Type OADD IDs 
    -----------------------
    INIT                TBD
    RESP                TBD

    Attribute Type
    --------------
    IP         TBD

    IP Attribute Type Values
    ------------------------
    ANY_IP               TBD
                 </artwork>
             </figure>
     
    </section>

    <section title="Security Considerations">
      <t>The exchange described in this document is protected by the IKEv2 channel. </t>
    </section>

    <section title="Acknowledgment">
      <t>The author would like to thank Yoav Nir for its helpful comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
        &rfc2119;
        &rfc4301;
        &rfc4555;
        &rfc5389;
        &rfc5768;
        &rfc5996;
        &rfc6027;
    </references>
    <references title="Informational References">
        &I-D.arora-ipsecme-ikev2-alt-tunnel-addresses;
        &I-D.mglt-mif-security-requirements;
        &I-D.mglt-ipsecme-security-gateway-discovery;
    </references>
    <section title="Document Change Log">
      <t>[RFC Editor: This section is to be removed before publication]</t>

      <t>-00: First version published.</t>
    </section>
  </back>
</rfc>
