<?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 RFC7296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml"> <!-- Recent IKEv2 RFC -->
<!ENTITY RFC4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml"> <!--Architecture IPsec -->
<!ENTITY RFC4555 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4555.xml"> <!-- MOBIKE -->
<!ENTITY RFC4494 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4494.xml"> <!-- -->
<!ENTITY RFC3566 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3566.xml"> <!-- -->
<!ENTITY I-D.raza-6lowpan-ipsec PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.raza-6lowpan-ipsec.xml">
]>

<rfc category="std"
     docName="draft-mglt-ipsecme-mobikev2-01.txt"
     ipr="trust200902">
    
    <!-- ++++++ FRONT STARTS ++++++ -->
    <front>
        
        <!-- ++++++ TITLE OF THE DOCUMENT ++++++ -->
        <title abbrev="MOBIKEv2">MOBIKEv2: MOBIKE extension for Transport mode</title>
        
        <!-- ++++++ AUTHORS ++++++ -->
        <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
            <organization>Ericsson</organization>
            <address>
                <postal>
                    <street>8400 boulevard Decarie</street>
                    <city>Montreal, QC H4P 2N2</city>
                    <country>Canada</country>
                </postal>
                <!--<phone>+33 1 45 29 60 52</phone>-->
                <facsimile/>
                <email>mglt.ietf@gmail.com</email>
                <uri/>
            </address>
        </author>

        <author fullname="Daniel Palomares" initials="D." surname="Palomares">
            <organization>Orange/LIP6</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 51 16</phone>
                <facsimile/>
                <email>daniel.palomares@orange.com</email>
                <uri/>
            </address>
        </author>

    <date/>
    <area>INTERNET</area>
    <workgroup>IPSECME</workgroup>
    
    <abstract>
        <t>MOBIKE, the IKEv2 Mobility and Multihoming Protocol is defined only for CHILD_SA using the tunnel mode. This document describes MOBIKEv2 that extends MOBIKE for CHILD_SA using also transport mode.</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="Terminology">
        
    <t>This document uses the following terminology:
        
        <list style="hanging" hangIndent="6">
        <t hangText="- Initiator:">The Initiator is the peer that initiates an exchange. It starts by sending a message towards the Responder. Note that if two peers are connected, the Initiator of one exchange can be the Responder of another exchange. </t>
        <t hangText="- Responder:">The Responder is the peer receiving an exchange. The message is sent from the Initiator.</t>
        <t hangText="- Security Policy (SP):"> is defined in section 4 of <xref target="RFC4301"/>. As mobility or multihoming concerns an already established session, SP mostly designate Security Policy in the SPD cache. The SP contains the processing information like the IPsec mode, the protocol to use as well as encryption and authorization algorithms. SP also contains a binding to the appropriated CHILD_SA. Binding between SP and CHILD_SA is described in section 4.4.2.2 of  <xref target="RFC4301"/> and in annex 1 of <xref target="RFC4555"/>. In most cases the binding is performed using addresses of implementation specific structures.</t>
        <t hangText="- Security Policy Database (SPD):"> is defined is defined in section 4.4.1.2 of <xref target="RFC4301"/>. In this document we are mostly focused on the SPD cache. The SPD contains all SP. SP match for outbound packet is performed through Traffic Selectors usually composed of the IP addresses and ports.</t>
        <t hangText="- Security Association (SA):"> is defined in section 4 of <xref target="RFC4301"/>. SA are stored in the Security Association Database. The SA carries the processing information (cryptographic keys, counters, tunnel IP addresses when the tunnel mode is used), as well as the SPD Traffic Selectors used to check the processed inbound packet matches the SP the SA is derived from. SA are also designated by CHILD_SA in this document</t>
        <t hangText="- Security Associations Database (SAD):"> is defined in section 4.4.1.2 of <xref target="RFC4301"/>. The SAD contains all CHILD_SA. The CHILD_SA is indexed by Selectors (Security Parameters Index (SPI) as well as the IP addresses of the inbound packet).</t>
        <t hangText="- Peer Authorization Database (PAD):"> is defined in section 4.4.3 of <xref target="RFC4301"/>.</t>
        <t hangText="-  MOBIKE:"> designates MOBIKE as described in <xref target="RFC4555"/>.</t>
        <t hangText="-  MOBIKEv2:"> designates the protocol described in this document, that is MOBIKE version 2.</t>
        </list>
        </t>  
    </section> 
    
    <section title="Introduction">

     <t>Currently, MOBIKE <xref target="RFC4555"/> provides mobility and multihoming capabilities only for CHILD_SA using the tunnel mode. On the other hand, a large set of VPN solutions rely on GRE/IP tunnels and IPsec protection of these tunnels uses the transport mode. Similarly, for example when traffic is offloaded from Radio Access Network to public WLAN, IPsec may also be used to secure application.  Some applications, like the DNS, may prefer the transport mode instead of the tunnel mode. In any case, the use of the transport mode prevents these connection to benefit from mobility and multihoming otherwise provided by MOBIKE.</t>

     <t>This document specifies MOBIKEv2 that extends MOBIKE <xref target="RFC4555"/> to the transport mode. By doing so, communication protected with IPsec transport mode can also benefit from multihoming and mobility capabilities.</t>

    <t>The remaining of the document is as follows. <xref target="sec-ike-auth"/> specifies how to negotiate the support of MOBIKEv2 with the creation of an CHILD_SA using the transport mode. <xref target="sec-update"/> describes how updates and additional IP addresses are handled with the transport mode. <xref target="sec-impact-ipsec-database"/> details how IP updates on CHILD_SA impact the databases.</t>
    
        
     <t>We assume the reader is familiar with IPsec <xref target="RFC4301"/>, IKEv2 <xref target="RFC7296"/> and with MOBIKE <xref target="RFC4555"/>.</t>
    </section>

    <section title="Problem Statement">

        <t><xref target="RFC4555"/> section 3.2 states that the use of MOBIKE is indicated with the MOBIKE_SUPPORTED Notify Payload in the IKE_AUTH exchange. <xref target="RFC7296"/> section 1.3.1 states that the use of the transport mode is indicated by the USE_TRANSPORT_MODE Notify Payload in a Create Child exchange. </t>

        <t>MOBIKE <xref target="RFC4555"/> section 1.2 considers outside its scope the use of mobility and multihoming with a CHILD_SA using the transport mode. As result, an Initiator is not supposed to send both an MOBIKE_SUPPORTED and a USE_TRANSPORT_MODE Notify Payload in its IKE_AUTH, and this case is left undefined. In case the Initiator sends these two payloads, possible Responder's behaviors may be:

         <list style="hanging" hangIndent="6">
              <t hangText="- 1)"> The Responder responds with MOBIKE_SUPPORTED and USE_TRANSPORT_MODE. In this case, MOBIKE may only be provided for the IKE_SA, the CHILD_SA is using the transport mode and no mobility or multihoming facilities are provided for the CHILD_SA.</t>
              <t hangText="- 2)"> The Responder responds with MOBIKE_SUPPORTED only, in which case, it indicates it supports MOBIKE and refuses the transport mode for the CHILD_SA. One reason for refusing the transport mode may be that MOBIKE has only been defined for the tunnel mode. Such situation may results from prioritizing extensions.</t>  
              <t hangText="- 3)"> The Responder responds with USE_TRANSPORT_MODE only, in which case it indicates it supports the transport mode for the CHILD_SA, but not MOBIKE. This case may be similar to case 2 with a different prioritization.</t>
              <t hangText="- 4)"> The Responder may ignore both Notify Payloads as this case has not been specified.</t>
         </list>
         </t> 

<t>As a result, the use MOBIKEv2 with CHILD_SA using the transport mode requires to clarify the combination of the MOBIKE_SUPPORTED and the USE_TRANSPORT_MODE Notify Payload in an IKE_AUTH exchange. This is the purpose of <xref target="sec-ike-auth"/></t>

        <t>MOBIKE updates the IP addresses using an UPDATE_SA_ADDRESSES Notify Payload. At the reception of the UPDATE_SA_ADDRESSES Notify Payload, the Responder identifies the concerned IKE_SA and associated CHILD_SA(s). The IP addresses of the Initiator is replaced in both the IKE_SA and the CHILD_SA(s) with the IP address of the IP header used to carry UPDATE_SA_ADDRESSES Notify Payload. The IKE_SA is actually stored in the IKEv2 application, whereas CHILD_SAs are in the SAD.</t>

        <t>When MOBIKE is activated, the CHILD_SAs are using the tunnel mode of IPsec. Thus, updating the IP address requires the tunnel to be updated within the CHILD_SA as well as the Selectors (SPI, IP addresses) of the CHILD_SA in the SAD. MOBIKEv2 supports CHILD_SA with transport mode. In this case, updating the IP address requires updating the SPD Traffic Selectors within the CHILD_SA as well as the Selectors of the SAD. In addition, the Traffic Selectors of the SPD cache also need to be updated. This is the major change of MOBIKEv2 versus MOBIKE. <xref target="sec-update"/> specifies the protocol details of MOBIKEv2 and  <xref target="sec-impact-ipsec-database"/> clarifies the impact on the various IPsec databases.</t>

    </section>

    <section anchor="sec-ike-auth" title="IKE_AUTH Exchange with MOBIKEv2">
         
    <t>With MOBIKEv2 support of mobility and multihoming for a CHILD_SA using the transport mode results from the combination of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload within the IKE_AUTH exchange in the message containing the SA Payload. Outside of this scope MOBIKE_SUPPORTED Notify Payload is not expected as defined in <xref target="RFC4555"/> section 3.2.</t>

    <t>With MOBIKEv2 the Initiator may initiate an IKE_AUTH exchange with the following combinations of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload. 
         <list style="hanging" hangIndent="6">
              <t hangText="- 1)">The presence of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload indicates a request for both a CHILD_SA with the transport mode and the support for MOBIKEv2 for this CHILD_SA. This support is only provided by MOBIKEv2 and is not specified by MOBIKE <xref target="RFC4555"/>.</t>
              <t hangText="- 2)">The presence of the USE_TRANSPORT_MODE and the absence of the MOBIKE_SUPPORTED Notify Payload indicates a request for a CHILD_SA with the transport mode and no support for MOBIKE. This case is specified in <xref target="RFC7296"/> and MOBIKEv2 leave this specification unchanged.</t>
              <t hangText="- 3)">The absence of the USE_TRANSPORT_MODE and the presence of the MOBIKE_SUPPORTED Notify Payload indicates a request for a CHILD_SA with the tunnel mode and the support for MOBIKEv2. This case is specified in <xref target="RFC4555"/> and MOBIKEv2 leave the specification unchanged.</t>
              <t hangText="- 4)">The absence of both the  USE_TRANSPORT_MODE and the MOBIKE_SUPPORTED Notify Payload indicates a request for a CHILD_SA with the tunnel mode and no support for MOBIKE. This case is specified in <xref target="RFC4555"/> and MOBIKEv2 leave the specification unchanged.</t>
         </list>
         </t> 

    <t>As specified by IKEv2 <xref target="RFC7296"/> in section 1.3.1 and in MOBIKE <xref target="RFC4555"/> section 3.2, the Responder can respond with a USE_TRANSPORT_MODE or MOBIKE_SUPPORTED Notify Payload only if such payload has been previously provided by the Initiator while initiating a CHILD_SA negotiation during the IKE_AUTH exchange. Given these restrictions, with MOBIKEv2 the Responder may respond with the following combination of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload. 
         <list style="hanging" hangIndent="6">
             <t hangText="- 1)">The presence of the USE_TRANSPORT_MODE and MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the transport mode and the support for MOBIKEv2 for this CHILD_SA. This support is only provided by MOBIKEv2 and is not specified by MOBIKE <xref target="RFC4555"/>.</t>
              <t hangText="- 2)">The presence of the USE_TRANSPORT_MODE and the absence of the MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the transport mode and no support for MOBIKE is provided. This case is specified in <xref target="RFC7296"/> and MOBIKEv2 leave this specification unchanged.</t>
              <t hangText="- 3)">The absence of the USE_TRANSPORT_MODE and the presence of the MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the tunnel mode and support for MOBIKEv2 is provided. This case is specified in <xref target="RFC4555"/> and MOBIKEv2 leave the specification unchanged.</t>
              <t hangText="- 4)">The absence of both the  USE_TRANSPORT_MODE and the MOBIKE_SUPPORTED Notify Payload indicates the CHILD_SA uses the tunnel mode and no support for MOBIKE is provided. This case is specified in <xref target="RFC4555"/> and MOBIKEv2 leave the specification unchanged.</t>
         </list>
</t>

    <t>In case the response does not satisfy the Initiator, it MUST delete the CHILD_SA as specified in <xref target="RFC7296"/> section 1.3.1.</t>
        </section>
        
        <section anchor="sec-update" title="Updating IP addresses with MOBIKEv2">
                <t>CHILD_SAs may be updated when a UPDATE_SA_ADDRESSES Notify Payload is received or when the other peer become unreachable, in which case, the newly assigned IP address has been provided by an ADDITIONAL_*_ADDRESS Notify Payload. This section details how CHILD_SA MUST be updated when the CHILD_SA uses the transport mode.</t>
                <t>Updating the IP address of the CHILD_SA using the transport mode impacts the SPD cache. As a result, IP address MUST be checked against the SPD and the PAD before performing any update of the CHILD_SA, or before communication the IP address as an alternate IP address. More specifically:
         <list style="hanging" hangIndent="6">
             <t hangText="- 1)">The Initiator MUST NOT send an UPDATE_SA_ADDRESSES if the newly acquired IP does not match the SPD and the PAD.</t>
             <t hangText="- 2)">The Initiator MUST NOT send an IP address in an ADDITIONAL_*_ADDRESS if the IP address does not match the SPD and the PAD.</t>
             <t hangText="- 3)">The Initiator and Responder MUST check an IP address match the SPD and the PAD before updating the CHILD_SA.</t> 
             <t hangText="- 4)">The Responder MUST send an UNACCEPTABLE_ADDRESS Notify Payload described in section 4.1.1 of <xref target="RFC4555"/> if the IP address does not match the SPD and the PAD.</t>
         </list>
</t>
               <t>Similarly to MOBIKE, the appropriated IP address is the newly acquired IP address considered by the Initiator (either when a mobility occurs or when an additional IP address is used). This IP address is provided by the Initiator to the Responder via the IP header of the UPDATE_SA_ADDRESSES Notify Payload.</t>    

                <t>Updating a CHILD_SA using the transport mode with a new IP address involves updating:
         <list style="hanging" hangIndent="6">
                <t hangText="- 1)">SPD Traffic Selectors in the CHILD_SA. Note that with the tunnel mode these selectors remain unchanged so this update is specific to the transport mode.</t>
                <t hangText="- 2)">SA Selectors in the SAD. This update is similar as with MOBIKE except that the IP address is not the one of the tunnel.</t> 
                <t hangText="- 3)">Traffic Selectors of the SPD cache MUST also be updated with the appropriated IP address. Note that with the tunnel mode these selectors remain unchanged so this update is specific to the transport mode.</t>
         </list>
               </t>
        </section>

    <section anchor="sec-impact-ipsec-database" title="IPsec Databases Impacts">

        <t>This section discusses the impact of MOBIKEv2 on the IPsec databases. Since implementation vary widely, we do not discuss how these updates MUST be performed.</t>

        <section title="Security Policy Database (SPD)">

        <t>The SPD MUST NOT be modified. Only the SPD cache needs to be modified. MOBIKE did not necessarily require update on the SDP cache, mostly because the Traffic Selectors are left unchanged with the tunnel mode. In fact, SPD Cache also have the outer IP addresses in its processing information (cf. section 4.1.2 of <xref target="RFC4301"/>). This information MAY be also defined in conjunction of the PAD, and eventually MAY be derived from the IP header of the IKE_INIT. However, this information is mostly used to negotiate the corresponding CHILD_SA, and for this reason, does not necessarily require to be updated. On the other hand as discussed in Appendix A.1 of  <xref target="RFC4555"/>, if this information is used to link the SPD cache entry to the CHILD_SA, then this information MUST be updated properly.</t>

        <t>With MOBIKEv2 for CHILD_SA using the transport mode, the SPD Traffic Selectors MUST be updated, and as such, the SPD MUST be updated. For this reason the IP address MUST match the SPD and PAD before performing the update.</t>  
        </section>

        <section title="Security Association Database (SAD)">
        <t>MOBIKE requires to update the Selector of the CHILD_SA as well as the content of the CHILD_SA (the Tunnel outer IP addresses). With MOBIKEv2 for CHILD_SA using the transport mode, there is no tunnel outer IP addresses to update. Instead the SDP Selectors in the CHILD_SA as well as the Selector of the CHILD_SA MUST be updated.</t>
        </section>

        <section title="Peer Authentication Database (PAD)">
        <t>The PAD MUST NOT be updated.</t>
        </section>  

    </section>
            
    
    <section title="Security Considerations">
          <t>Security Considerations regarding mobility and multihoming have already been expressed in <xref target="RFC4555"/>.</t>
          <t>The use of the transport mode makes visible and unprotected the IP header of the carried IP packet. This. This discloses privacy related information as the IP header indicates the end points communicating. This could be avoided with the tunnel mode as the end point was the Security Gateway.</t>
    </section>
    
    <section title="IANA Considerations">
          <t>They is no IANA consideration. The signaling provided by MOBIKE is sufficient.</t>
          
    </section>

    </middle>
    
    <back>
        
        <references title="Normative References">
            &RFC2119;
            &RFC4301;
            &RFC4555;
            &RFC7296;
        </references>
        
        
    </back>
    </rfc>
