<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-boucadair-mptcp-natfwfree-profile-00"
     ipr="trust200902">
  <front>
    <title abbrev="Transport Profiles">An MPTCP Profile for NAT- and
    Firewall-Free Networks: Network-Assisted MPTCP Deployments</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="Pierrick Seite" initials="P." surname="Seite">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code></code>

          <country>France</country>
        </postal>

        <phone></phone>

        <email>pierrick.seite@orange.com</email>
      </address>
    </author>

    <author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
      <organization>Tessares</organization>

      <address>
        <postal>
          <street></street>

          <city></city>
        </postal>

        <phone></phone>

        <email>Olivier.Bonaventure@tessares.net</email>

        <uri>http://www.tessares.net</uri>
      </address>
    </author>

    <author fullname="Lingli Deng" initials="L." surname="Deng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>denglingli@chinamobile.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>One of the promising deployment scenarios for Multipath TCP (MPTCP)
      is to enable a Customer Premises Equipment (CPE) that is connected to
      multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of such
      resources, thereby providing better serviceability overall (including
      whenever the CPE fails to connect to one of the access networks). This
      document specifies a MPTCP profile for such deployments in network
      regions that are firewall- and NAT-free.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>One of the promising deployment scenarios for Multipath TCP (MPTCP,
      <xref target="RFC6824"></xref>) is to enable a Customer Premises
      Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE,
      WLAN) to optimize the usage of such resources, see for example <xref
      target="I-D.deng-mptcp-proxy"></xref> or <xref target="RFC4908"></xref>.
      This deployment scenario relies on MPTCP proxies on both the CPE and the
      network sides (<xref target="fig"></xref>). The latter plays the role of
      traffic concentrator. A concentrator terminates the MPTCP sessions, from
      a CPE, before relaying it into a legacy TCP session. </t>

      <t><figure align="center" anchor="fig"
          title="&quot;Network-Assisted&quot; MPTCP Design">
          <artwork><![CDATA[                      IP Network #1                     
 +------------+        _--------_    +------------+   
 |            |       (e.g., LTE )   |            |   
 |   CPE      +======================+            |    
 | (MPTCP     |       (_        _)   |Concentrator|   
 |  Proxy)    |         (_______)    | (MPTCP     |    
 |            |                      |  Proxy)    |------> Internet
 |            |                      |            |
 |            |        IP Network #2 |            |     
 |            |        _--------_    |            |    
 |            |       ( e.g., DSL )  |            |   
 |            +======================+            |
 |            |       (_        _)   |            |
 +-----+------+        (_______)     +------------+
       |
----CPE network----     
       |
    end-nodes
]]></artwork>
        </figure></t>

      <t>Because the paths between the CPE and the concentrator are firewall-
      and NAT-free, the complexity of the MPTCP specification that was
      initially induced by the need to handle the presence of firewalls as
      well as routing asymmetry effects, is not justified anymore. Concretely,
      in the situations where the paths between the CPE and the concentrator
      are firewall- and NAT-free, the MPTCP stack is not required to support
      the dedicated features required to handle the presence of firewalls as
      well as routing asymmetry effects.</t>

      <t>Such context encourages the specification of a dedicated MPTCP
      profile that would in turn foster the adoption of MPTCP. This document
      specifies such MPTCP profile that is adapted to network regions that are
      firewall- and NAT-free.</t>

      <t>The constraint discussed in <xref target="RFC6824"></xref> does not
      apply for such deployments:</t>

      <t><figure>
          <artwork><![CDATA[   "External Constraints:  The protocol must function through the vast
      majority of existing middleboxes such as NATs, firewalls, and
      proxies, and as such must resemble existing TCP as far as possible
      on the wire.  Furthermore, the protocol must not assume the
      segments it sends on the wire arrive unmodified at the
      destination: they may be split or coalesced; TCP options may be
      removed or duplicated."]]></artwork>
        </figure></t>

      <t>NAT is used through this document to refer to any function that
      rewrites a source IP address/prefix to another IP address/prefix within
      the same or distinct address family. NAT is also to refer to any
      function that rewrites port numbers. Typical examples are traditional
      IPv4-IPv4 NAT (<xref target="RFC3022"></xref>), NPTv6 (<xref
      target="RFC6296"></xref>), NAT64 (<xref target="RFC6146"></xref>),
      DS-Lite AFTR (<xref target="RFC6333"></xref>), or Carrier Grade NAT
      (CGN, <xref target="RFC6888"></xref>).</t>

      <t>Lawful intercept and data retention implications due to the use of
      MPTCP are out of the scope of this document.</t>
    </section>

    <section title="Assumptions">
      <t>The following assumptions are made: <?rfc subcompact="yes" ?><list
          style="symbols">
          <t>One or multiple concentrators are deployed on the network side to
          assist MPTCP-enabled hosts to establish MPTCP connections via
          available network attachments.</t>

          <t>On the uplink path, the concentrator terminates the MPTCP
          connections received from its customer-facing interfaces and
          transforms these connections into legacy TCP connections towards
          upstream servers. On the downlink path, the concentrator turns the
          legacy server's TCP connection into MPTCP connections towards its
          customer-facing interfaces.</t>

          <t>Various network attachments are provided to an MPTCP-enabled
          host/CPE; all these network attachments are managed by the same
          administrative entity.</t>

          <t>The CPE implements an MPTCP proxy as well. This MPTCP proxy acts
          as a traffic concentrator from the end-nodes (i.e., hosts attached
          to the CPE) standpoint.</t>

          <t>The network legs between the hosts and a concentrator instance
          are NAT- and firewall-free.</t>

          <t>The logic for mounting network attachments by a host is
          deployment- and implementation-specific that are out of scope of
          this document .</t>

          <t>The Network Provider that manages the various network attachments
          (including the concentrators) can enforce authentication and
          authorization policies using appropriate mechanisms that are out of
          scope of this document.</t>

          <t>Policies can be enforced by a concentrator instance operated by
          the Network Provider to manage both upstream and downstream traffic.
          These policies may be subscriber-specific, connection-specific or
          system-wide.</t>

          <t>The concentrator may be notified about the results of monitoring
          (including probing) the various network legs to service a customer,
          a group of customers, a given region, etc. No assumption is made by
          this document about how these probing operations are executed.</t>

          <t>Ingress filtering (<xref target="RFC2827"></xref>) is implemented
          at the boundaries of the networks to provide anti-spoofing.</t>

          <t>An MPTCP-enabled multiple Interfaces host, that is directly
          connected to one or multiple access networks obtains
          address/prefixes via legacy mechanisms of the various available
          network attachments. The host may be assigned the same or distinct
          IP address/prefixes via the various available network
          attachments.</t>

          <t>The CPE does not alter or strip MPTCP signals received from
          end-nodes.</t>

          <t>The concentrator may behave in a transparent mode (that is, hosts
          are unaware of the presence of the concentrator in the communication
          path(s)) or in a non-transparent mode (i.e., the identity of the
          concentrator is explicitly configured to the hosts).</t>

          <t>A mechanism should be used to make sure the same IP address is
          assigned to the host when transforming an MPTCP connection into a
          TCP connection. No assumption is made about how such mechanism is
          implemented. Network Providers should be aware of the complications
          that may arise if a same IP address/prefix is shared among multiple
          hosts (see <xref target="RFC6967"></xref>). Whether these
          complications apply or not is deployment-specific.</t>

          <t>The location of the concentrator(s) is deployment-specific.
          Network Providers may choose to adopt centralized or distributed
          (even if they may not be present on the different network accesses)
          designs, etc. Nevertheless, in order to take advantage of MPTCP, the
          location of the concentrator should not jeopardize packet forwarding
          performance for traffic sent from or directed to connected
          hosts.</t>
        </list></t>

      <t><?rfc subcompact="no" ?></t>
    </section>

    <section title="Target Use Cases">
      <t>Two main use cases are targeted by this profile:<list style="numbers">
          <t>Multi-homed CPEs (e.g., <xref target="RFC4908"></xref>).</t>

          <t>MPTCP within core networks to achieve load-balancing or bandwidth
          aggregation. This use case assumes that MPTCP connections are
          established between nodes that are managed by the same
          administrative entity.</t>
        </list></t>
    </section>

    <section anchor="profile" title="Relaxing Some Base MPTCP Features">
      <t>The following list is a set of items of the MPTCP specification that
      can be relaxed to facilitate and improve MPTCP operation in firewall-
      and NAT-free regions of the network. A technical justification is
      provided to relax each of these items. The rest of the MPTCP
      specifications that are not mentioned in this section MUST be followed
      even in firewall and NAT-free networks.</t>

      <t><list hangIndent="0" style="format Item %d:">
          <t>Checksum SHOULD be disabled. This behavior implies in particular
          that "A" flag bit must always be set to 0.<vspace
          blankLines="1" />Justification: This is a direct consequence of the
          absence of NATs and firewalls in the network leg between the host
          and a concentrator.</t>

          <t>Section 3.6 of <xref target="RFC6824"></xref> does not
          apply.<vspace blankLines="1" />Justification: The target deployments
          assume that all paths are MPTCP-compliant; once the first subflow is
          established, it is safe to assume that any additional subflow will
          be successfully established over an MPTCP-compliant path. There is
          no need to envision a TCP fallback mechanism except for the first
          subflow.<vspace blankLines="1" />Operators may run tests to assess
          whether available paths are MPTCP-compliant. For example, Operators
          can perform tests with tools like tracebox to validate the absence
          of middleboxes on the network legs that are used. It is out of scope
          of this document to define those tests.</t>

          <t>Endpoints may rely on the source address of a sub-flow
          established by an initiating peer to establish new subflows or
          enforce policies (e.g., rate-limit at the concentrator side).
          <vspace blankLines="1" />Justification: The point about private IP
          addresses discussed in Section of <xref target="RFC6824"></xref>
          does not apply, since there is no NAT in the path between the
          involved MPTCP endpoints.</t>

          <t anchor="item4">Given that the network legs that are used are
          trusted, there is no need to authenticate the establishment of the
          additional subflows with a HMAC in the MP_JOIN. MP_JOIN options are
          still used, but they neither contain random numbers nor truncated
          HMACs. The MP_JOIN option in the SYN has a length of 8 bytes and
          contains the receiver's token. In the SYN+ACK and the third ACK, the
          MP_JOIN options have a length of 4 bytes. <vspace
          blankLines="1" />Justification: The network leg between the
          directly-connected host and a concentrator instance is trusted.
          There is thus no risk of attack on this part of the network. <!--
   Item 4:  Instead of the hash-based function defined in [RFC6824],
            tokens SHOULD be randomly generated by the client.  Tokens
            MUST be locally unique to unambiguously identify an MPTCP
            connection.  Moreover, the Initial Data Sequence Number
            (IDSN) of each host MUST be set to the concatenation of the
            token and the key; the key being set to a value selected by
            the host.  The key does not to be changed on a per
            connection basis.  Authentication validation of an MP_JOIN
            SHOULD be disabled at the receiver's side.

            Justification: The network leg between the directly-
            connected host and a concentrator instance is trusted.
            Furthermore, relaxing this constraint would ease to
            integrate MPTCP features into CPEs with low capacity.  A
            proposal for a low overhead security validation was
            documented in [I-D.paasch-mptcp-lowoverhead].

--></t>

          <t>If the concentrator's reachability information is explicitly
          configured on the MPTCP host, and the concentrator is aware of
          addresses assigned to the MPTCP host, then the ADD_ADDR option
          SHOULD NOT be supported. In such case, the host MUST rely upon the
          provided configuration information to manage an MPTCP connection.
          <vspace blankLines="1" />Justification: A host that is configured
          with the addresses of a concentrator can use these addresses to
          establish one or multiple subflows for a given connection; each
          connection is then bound to an IP address of the concentrator that
          has been "assigned" to the host, as per the concentrator's
          reachability information (a name, an IP address, etc.) provided to
          the host. The locators of the concentrators are likely to be stable.
          A locator can be a name, IPv4/v6 addresses, etc.</t>

          <t>If the MPTCP endpoint is explicitly configured so that it behaves
          in a network-assisted mode, subflows can be created to the remote
          MPTCP concentrator, using a locally configured set of addresses,
          without advertising the available set of addresses. Triggers to
          decide how many sub-flows are to be initiated or when to establish
          additional ones are application-specific. <vspace
          blankLines="1" />Justification: Multiple addresses are configured
          out of band (e.g., using DHCP <xref
          target="I-D.boucadair-mptcp-dhc"></xref>, TR-69, etc.). The use of
          out-of-band configuration mechanism is justified in some deployments
          for engineering purpose (e.g., assign the concentrator to service a
          host based on criteria such as the load of the concentrator,
          geo-proximity, etc.).</t>

          <t>If the concentrator has access to the information about
          address(es) assigned to a directly-connected host and their
          associated leases (e.g., because the concentrator is collocated with
          a DHCP relay or acquires such information by means of an out-of-band
          mechanism), the concentrator SHOULD undertake actions for a better
          quality of experience of MPTCP connections such as: add a new
          sub-flow even if the concentrator is not the initiator of the MPTCP
          connection, migrate flows to another alternate address if the remote
          address is not valid anymore or because its validity timeout will
          expire soon, etc. <vspace blankLines="1" />Justification: This
          approach is meant to anticipate retransmissions that may be induced
          by the invalidity of an IP address. Also, this allows to reduce the
          delay from waiting for a notification from a remote peer. The
          concentrator can also decide to add new subflows for better quality
          of experience based, for example, on local policies.</t>

          <t>Address management MAY not be specific to each active MPTCP
          connection, but MAY be on a per host basis. <vspace
          blankLines="1" />Justification: This is because all the MPTCP
          connections initiated by a host (resp. a concentrator) involve the
          same MPTCP endpoint (concentrator). <vspace blankLines="1" />How
          such address management is actually achieved is
          implementation-specific. Nevertheless, for illustration purposes, a
          dedicated session can be enabled between an MPTCP-enabled host and a
          concentrator for control purposes. This information exchanged in
          this dedicated connection will be used to adjust other (data)
          connections.</t>

          <t>The maximum number of subflows for a given connection SHOULD be
          set by default to 4.<vspace blankLines="1" />Justification: For
          dimensioning purposes, an operator needs to control the number of
          flows to be handled by a concentrator. <vspace blankLines="1" />4
          corresponds to a dual-homed host that is assigned both an IPv4
          address and an IPv6 prefix for each network attachment.<vspace
          blankLines="1" />An MPTCP endpoint that is dimensioned to maintain a
          maximum number of subflows per MPTCP connection may accept to
          maintain more subflows for some connections.<!----><!--A policy can be enforced to prioritize a path on a per interface basis. In such deployments, the support of the MP_PRIO option MAY NOT 
be required.Justification: This can be enforced as a system-wide policy enforced by both the concentrator and a host. 
For example, DSL lines can be preferred over WLAN or 4G links.

--></t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The concentrator may have access to privacy-related information
      (e.g., IMSI, link identifier, subscriber credentials, etc.). The
      concentrator must not leak such sensitive information outside a local
      domain.</t>

      <t>Means to protect the MPTCP concentrator against Denial-of-Service
      (DoS) attacks must be enabled. Such means include the enforcement of
      ingress filtering policies at the boundaries of the network. In order to
      prevent exhausting the resources of the concentrator by creating an
      aggressive number of simultaneous subflows for each MPTCP connection,
      the administrator should limit the number of allowed subflows per host
      for a given connection. This profile recommends this value to be set to
      4.</t>

      <t>Attacks outside the domain can be prevented if ingress filtering is
      enforced. Nevertheless, attacks from within the network between a host
      and a concentrator instance are another yet actual threat. Means to
      ensure that illegitimate nodes cannot connect to a network should be
      implemented.</t>

      <t>Traffic theft can be achieved if an illegitimate concentrator is
      inserted in the path. Indeed, inserting an illegitimate concentrator in
      the forwarding path allows to intercept traffic and therefore have
      access to sensitive data issued by or destined to a host. To mitigate
      this threat, secure means to discover a concentrator (for
      non-transparent modes) should be enabled.</t>

      <t>This document relax checksum validations (Item (1), <xref
      target="profile"></xref>) and MP_JOIN authentication constraints (Item
      (4), <xref target="profile"></xref>) because the networks between two
      MPTCP endpoints is trusted. Furthermore, ingress filtering is enforced
      at these networks for source address validation.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>TBC.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6824'?>

      <?rfc include='reference.RFC.2119'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.deng-mptcp-proxy'?>

      <?rfc include='reference.RFC.4908'?>

      <?rfc include='reference.RFC.3022'?>

      <?rfc include='reference.RFC.6333'?>

      <?rfc include='reference.RFC.2827'?>

      <?rfc include='reference.RFC.6146'?>

      <?rfc include='reference.RFC.6296'?>

      <?rfc include='reference.RFC.6888'?>

      <?rfc include='reference.RFC.6967'?>

      <reference anchor="I-D.boucadair-mptcp-dhc"
                 target="https://datatracker.ietf.org/doc/draft-boucadair-mptcp-dhc/">
        <front>
          <title>IP Flow Information Export (IPFIX) Entities</title>

          <author fullname="Mohamed Boucadair" initials="M."
                  surname="Boucadair">
            <organization>France Telecom</organization>

            <address>
              <postal>
                <street></street>

                <city>Rennes</city>

                <region></region>

                <code>35000</code>

                <country>France</country>
              </postal>

              <email>mohamed.boucadair@orange.com</email>
            </address>
          </author>

          <author fullname="Christian Jacquenet" initials="C."
                  surname="Jacquenet">
            <organization>France Telecom</organization>

            <address>
              <postal>
                <street></street>

                <city>Rennes</city>

                <region></region>

                <country>France</country>
              </postal>

              <email>christian.jacquenet@orange.com</email>
            </address>
          </author>

          <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
            <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

            <address>
              <postal>
                <street>Cessna Business Park, Varthur Hobli</street>

                <street>Sarjapur Marathalli Outer Ring Road</street>

                <city>Bangalore</city>

                <region>Karnataka</region>

                <code>560103</code>

                <country>India</country>
              </postal>

              <email>tireddy@cisco.com</email>
            </address>
          </author>

          <date day="02" month="July" year="2015" />
        </front>
      </reference>
    </references>
  </back>
</rfc>
