<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc7258 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY rfc4301 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY rfc7435 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml">
]>

<rfc category="info" ipr="trust200902" docName="draft-antony-ipsecme-oppo-nat-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

    <front>
        <title abbrev="NAT-T for Opportunistic IPsec">NAT-Traversal support for Opportunistic IPsec</title>
        <author initials='A.' surname="Antony" fullname='Antony Antony'>
            <organization>Phenome Networks</organization>
            <address>
                <email>antony@phenome.org</email>
            </address>
        </author>
        <author initials='J.' surname="Gilmore" fullname='John Gilmore'>
            <address>
                <email>gnu@toad.com</email>
            </address>
        </author>
        <author initials='P.' surname="Wouters" fullname='Paul Wouters'>
            <organization>Red Hat</organization>
            <address>
                <email>pwouters@redhat.com</email>
            </address>
        </author>
        <date/>
        <area>sec</area>
        <workgroup>ipsecme</workgroup>

        <abstract>
        <t>This document specifies how to support NATed IPsec peers for use with Opportunistic IPsec.
        </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction">
            <t>The Internet Key Exchange Protocol version 2 (IKEv2),
            specified in <xref target="RFC7296"/>, provides a way to
            negotiate tunnel mode IPsec SA's for peers behind NAT. It
            does not provide guidance on how to resolve the problem of
            multiple peers using the same pre-NAT IP address.</t>

            <t>Responder assigned IP addresses for NATed peers also do
            not fully resolve the address conflict when the NATed peers
            are deploying opportunistic IPsec to many remote endpoints.
            Additional complexity of configuring many source IP addresses
            on the NATed peers is undesirable.</t>

            <t>This problem is expected to be a significant issue for
            large scale Opportunistic IPsec deployments.</t>

            <t>The goal of this draft is to put the burden of the
            additional effort required for NAT onto the host that is
            NAT'ed. In a hypothetical future with no NAT, no residual
            protocol changes would remain.</t>

            <section title="Conventions Used in This Document">
                <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>

        <section title="The pre-NAT IP address conflict">
            <t>
             A peer that is behind NAT is only aware of its own native
             IP address. While the IKEv2 NATD payloads allow the peer
             to find out it is behind NAT, it either has to use its own
             native IP address or a remote peer assigned IP address to
             build IPsec SA's.
            </t>
            <t>
             Two initiators behind different NAT routers can have the
             same pre-NAT IP address.  When these initiators attempt to
             setup an IPsec SA to the same responder, there will be a
             conflict on the responder. When the first initiator connects,
             the responder will install an IPsec SA for for the specific
             pre-NAT IP. For the second initiator, the responder cannot
             install an IPsec SA with the same source and destination
             selectors without creating a conflict. Even if it could
             install two identical IPsec SAs, it still needs a mechanism
             to decide between these two IPsec SA's. While connection
             tracking might be used to distinguish reply packets, there
             is no method for initiating a connection from the responder
             to one of the initiators without somehow specifying for
             which of the initiators the packet is meant.
             </t>
             <t>
              When initiators behind NAT let the remote peer assign
              their IP to use for building the IPsec SA, the problem
              reverses. Initiators behind NAT can setup many IPsec SA's
              to different remote peers, and those remote peers might
              use the conflicting IP addresses. Additionally, using many
              IP addresses requires that the host or applications need
              to be aware of which source IP to use for which remote peer.
             </t>
        </section>

        <section title="Creating the NAT workaround on the initiator">
            <t>In the below workflow, the following example IP addresses are used:
              <list style="symbls">
               <t>The initiator ("road") has a private IP address of 192.1.3.209</t>
               <t>The NAT router has an internal (private) IP address of 192.1.3.254</t>
               <t>The NAT router has an external (public) IP address of 192.1.2.254</t>
               <t>The responder ("east") has a public IP address of 192.1.2.42</t>
               <t>The responder ("east") has a private IP address pool of 10.1.2.0/24</t>
              </list>
              Tunnel mode is used for all IPsec SA's.
             </t>
               
        <section title="The Initial Exchange">
            <t>In IKEv2, the IKE_INIT exchange allows the initiator and responder to detect the
               presense of a NAT. In this case both "road" and "east" become aware of the NAT in
               front of "road".
            </t>
            <t>In IKEv2, the initiator can signal via the TSi payload that it is willing to receive
               a responder-assigned IP address for use in the IPsec SA. The responder needs to be configured
               with an addresspool from which it assigns unique IP addresses to the connecting initiators.
            </t>
            <t>
              "road" sends a TSi(0.0.0.0/0) and TSr(192.1.2.42/32) request to "east" in the IKE_AUTH Exchange.
            </t>
            <t>
              "east" assigns the first free IP address from its pool - 10.1.2.1 - to this prospective client
              and sends a TSI(10.1.2.1/32) and TSr(192.1.2.42/32) back to "road".
            </t>
            <t>The IKE_AUTH Exchange completes as normal. This could be an authenticated exchange or an
               exchange without authentication using AUTH_NULL as specified in <xref target="IKE-AUTH-NULL"/>.
            </t>
        </section>
        <section title="Handling the NAT problem on the initiator">
            <t>
              "road", upon receiving east's TSi/TSr - and a successfull completion of the IKE_AUTH Exchange -
              two tasks:
              <list style="numbers">
               <t>It installs the negotiated inbound and outbound IPsec SAs (10.1.2.1/32 &lt;=&gt; 192.1.2.42/32)</t>
               <t>It installs a destination based NAT rule for 192.1.3.209 -> 192.1.2.42/32  ==> 10.1.2.1/32 -> 192.1.2.42/32</t>
              </list>
              It ensures that the destination based NAT rule is processed before IPsec processing begins.</t>
        </section>
        <section title="Handling the NAT problem on the responder">
               <t>The responder has no specific handling it needs to perform apart from a willingness to assign IP addresses
                  if an initiator requests one via the special TSi(0.0.0.0/0). If the initiator sends a TSi() that matches the
                  IP address of the IKE message, the responder should agree to use that address instead of assigning one from
                  its addresspool.
               </t>
        </section>
        <section title="Implementation details">
         <t>The NAT rule can be implemented in the Networking subsystem of the host kernel, but this specific IPsec-NAT rule could
            also be implemented as part of the IPsec subsystem.
         </t>
         <t>The initiator host and any application running on the initiator should not need to be aware of this construct. The
            responder assigned IP address does not need to be configured on the host. It only needs to exist in the NAT rule and
            the IPsec SA.
         </t>
        </section>
        </section>
        <section title="Creating the NAT workaround on the responder">
         <t>[placeholder]</t>
        </section>

        <section title="Security Considerations">
            <t>This NAT mapping method MUST only be used for host-to-host IPsec tunnels. It MUST NOT be used for net-to-net IPsec tunnels.
            </t>
            <t>An address from the addresspool should not be re-used quickly to avoid sending traffic meant for one initiator to
               another initiator.
            </t>
        </section>

        <section title="Acknowledgments">
            <t>None so far</t>
        </section>

        <section title="IANA Considerations">
            <t>This Internet Draft includes no request to IANA.</t>
        </section>
    </middle>

    <back>
        <references title='Normative References'>
            &rfc2119;
            &rfc4301;
            &rfc7296;
   <reference anchor='IKE-AUTH-NULL'>
      <front>
      <title>The NULL Authentication Method in IKEv2 Protocol</title>
      <author initials='Valery' surname='Smyslov' fullname='V. Smyslov'>
      <organization>ELVIS-PLUS</organization>
      </author>
      <author initials='Paul' surname='Wouters' fullname='P. Wouters'>
      <organization>Red Hat</organization>
      </author>
      <date month='February' day='20' year='2015' />
      </front>
      <seriesInfo name='Internet-Draft' value='draft-ietf-ipsecme-ikev2-null-auth' />
      <format type='TXT' 
            target='http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-null-auth-04.txt' />
   </reference>
        </references>

        <references title='Informative References'>
            &rfc7258;
            &rfc7435;
        </references>
    </back>
</rfc>
