<?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="info" docName="draft-nam-mptcp-deployment-considerations-01"
     ipr="trust200902">
  <front>
    <title abbrev="Network-Assisted MPTCP">Network-Assisted MPTCP: Use Cases,
    Deployment Scenarios and Operational Considerations</title>

    <author fullname="Mohamed Boucadair" initials="M." role="editor"
            surname="Boucadair">
      <organization>Orange</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." role="editor"
            surname="Jacquenet">
      <organization>Orange</organization>

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

          <city>Rennes</city>

          <region></region>

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

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

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

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

          <city></city>

          <region></region>

          <code></code>

          <country>Belgium</country>
        </postal>

        <phone></phone>

        <email>olivier.bonaventure@tessares.net</email>
      </address>
    </author>

    <author fullname="Wim Henderickx" initials="W." role="editor"
            surname="Henderickx">
      <organization>Nokia/Alcatel-Lucent</organization>

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

          <city></city>

          <region></region>

          <country>Belgium</country>
        </postal>

        <email>wim.henderickx@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Robert Skog" initials="R." role="editor" surname="Skog">
      <organization>Ericsson</organization>

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

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <email>robert.skog@ericsson.com</email>
      </address>
    </author>

    <date />

    <abstract>
      <t>Network-Assisted MPTCP deployment models are designed to facilitate
      the adoption of MPTCP for the establishment of multi-path communications
      without making any assumption about the support of MPTCP by the
      communicating peers. MPTCP Conversion Points (MCPs) located in the
      network are responsible for establishing multi-path communications on
      behalf of endpoints, thereby taking advantage of MPTCP capabilities to
      achieve different goals that include (but are not limited to)
      optimization of resource usage (e.g., bandwidth aggregation), of
      resiliency (e.g., primary/backup communication paths), and traffic
      offload management.</t>

      <t>This document describes Network-Assisted MPTCP uses cases, deployment
      scenarios, and operational considerations.</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>The overall quality of connectivity services can be enhanced by
      combining several access network links for various purposes - resource
      optimization, better resiliency, etc. Some transport protocols, such as
      Multipath TCP, can help achieve such better quality, but failed to be
      massively deployed so far.</t>

      <t>The support of multipath transport capabilities by communicating
      hosts remains a privileged target design so that such hosts can directly
      use the available resources provided by a variety of access networks
      they can connect to. Nevertheless, network operators do not control end
      hosts while the support of MPTCP by content servers remains close to
      zero.</t>

      <t>Network-Assisted MPTCP deployment models are designed to facilitate
      the adoption of MPTCP for the establishment of multi-path communications
      without making any assumption about the support of MPTCP capabilities by
      communicating peers. Network-Assisted MPTCP deployment models rely upon
      MPTCP Conversion Points (MCPs) that act on behalf of hosts so that they
      can take advantage of establishing communications over multiple
      paths.</t>

      <t>Such MCPs can be deployed in CPEs (Customer Premises Equipment), as
      well in the network side. MCPs are responsible for establishing
      multi-path communications on behalf of endpoints.</t>

      <t>This document describes Network-Assisted MPTCP uses cases (<xref
      target="muc"></xref>), deployment scenarios (<xref
      target="dep"></xref>), and operational considerations (<xref
      target="mdc"></xref>).</t>
    </section>

    <section title="Terminology">
      <t>The reader should be familiar with the terminology defined in <xref
      target="RFC6824"></xref>.</t>

      <t>This document makes use of the following terms:<list style="symbols">
          <t>Client: an endhost that initiates transport flows forwarded along
          a single path. Such endhost is not assumed to support multipath
          transport capabilities.</t>

          <t>Server: an endhost that communicates with a client. Such endhost
          is not assumed to support multipath transport capabilities.</t>

          <t>Multipath Client: a Client that supports multipath transport
          capabilities.</t>

          <t>Multipath Server: a Server that supports multipath transport
          capabilities. Both the client and the server can be single-homed or
          multi-homed. However, for the use cases discussed in this document,
          the number of interfaces on the endhosts is not relevant.</t>

          <t>Transport flow: a sequence of packets that belong to a
          unidirectional transport flow and which share at least one common
          characteristic (e.g., the same destination address). TCP and SCTP
          flows are composed of packets that have the same source and
          destination addresses, the same protocol number and the same source
          and destination ports.</t>

          <t>Multipath Conversion Point (MCP): a function that terminates a
          transport flow and relays all data received over it over another
          transport flow. <vspace blankLines="1" />MCP is a function provided
          by the network operator that converts a multipath transport flow and
          relays it over a single path transport flow and vice versa.</t>
        </list></t>
    </section>

    <section anchor="muc" title="Network-Assisted MPTCP Use Cases">
      <t>The first use case is a Multipath Client that interacts with a
      Server. To benefit from the capabilities of its multipath transport
      protocol, the Multipath Client will interact with a Multipath Conversion
      Point (MCP) located in the network as illustrated in <xref
      target="uc1"></xref>.</t>

      <t><figure anchor="uc1"
          title="A Multipath Client interacts with a Server through a Multipath Conversion Point ">
          <artwork><![CDATA[     C <===========>MCP <------------> S
     +<============>+

Legend:
     <===>: MPTCP leg
]]></artwork>
        </figure>A similar approach consists of a Multipath Server that
      leverages its multipath capabilities when interacting with a Client as
      shown in <xref target="uc2"></xref>.</t>

      <t><figure anchor="uc2"
          title="A Client interacts with a Multipath Server through a Multipath Conversion Point ">
          <artwork><![CDATA[     C <---------> MCP <===========> S
                     +<=============>+]]></artwork>
        </figure>The third use case is when a Client interacts with a Server
      and the corresponding communication is deemed eligible to multi-path
      forwarding. In this case, two Multipath Conversion Points are used. The
      upstream MCP converts the (single path) transport flow initiated by the
      Client into a multipath transport flow towards a downstream MCP (called,
      network-located MCP). This downstream MCP converts the multipath
      transport flow received from the upstream MCP in a single path transport
      flow forwarded to the destination Server. The end-to-end transport flow
      between the Client and the Server is thus decomposed into three flows as
      shown in <xref target="uc3"></xref>: A (single path) transport flow
      between the Client and the upstream MCP, a multipath transport flow
      between the upstream and the downstream MCPs, and a single path
      transport flow between the downstream MCP and the Server.</t>

      <t><figure anchor="uc3"
          title="A Client interacts with a Server through two Multipath Conversion Points ">
          <artwork><![CDATA[          Upstream          Downstream
     C <---> MCP <===========> MCP <------------> S
               +<=============>+]]></artwork>
        </figure></t>
    </section>

    <section anchor="dep" title="Deployment Scenarios">
      <t>This section discusses some deployment scenarios related to
      Network-Assisted MPTCP designs.</t>

      <section anchor="mob" title="LTE/WLAN Aggregation">
        <t>This deployment scenario is considered by mobile operators so that
        they can propose their customers to aggregate LTE resources with WLAN
        resources.</t>

        <t>As depicted in <xref target="dep2"></xref>, the mobile terminal
        (UE, User Equipment) is MPTCP-capable. The MCP function is enabled in
        the network to terminate MPTCP connections (e.g., in the PDN Gateway,
        a dedicated service function located at the (S)Gi interface,
        co-located with a TCP proxy, etc.).</t>

        <t>This deployment scenario is an implementation of the use case
        depicted in <xref target="uc1"></xref>.</t>

        <t><figure anchor="dep2"
            title="Network-Assisted MPTCP LTE/WLAN Aggregation (Host-based model)">
            <artwork><![CDATA[
  +------------+        _--------_    +----------------+
  |            |       (    LTE   )   |                |
  |   UE       +=======+          +===+  Backbone      |
  | (MPTCP     |       (_        _)   |   Network      |
  |  Client)   |         (_______)    |+--------------+|
  |            |       IP Network #1  || Concentrator ||------> Internet
  |            |                      ||    (MCP)     ||
  |            |                      |+--------------+|
  |            |       IP Network #2  |                |
  |            |        _--------_    |                |
  |            |       (           )  |                |
  |            +=======+  WLAN     +==+                |
  |            |       (_        _)   |                |
  +------------+        (_______)     +----------------+
]]></artwork>
          </figure></t>

        <t></t>
      </section>

      <section anchor="fixed" title="Fixed/Wireless Access Aggregation">
        <t>One of the promising deployment scenarios for Multipath TCP is to
        enable a CPE that is connected to multiple access networks (e.g., DSL,
        LTE, WLAN) to optimize the usage of such resources. This deployment
        scenario, called Hybrid Access, relies upon MCPs located in both the
        CPE and the network (<xref target="dep1"></xref>). The latter plays
        the role of an MPTCP concentrator. Such concentrator terminates the
        MPTCP sessions established from CPEs, before redirecting traffic into
        legacy TCP sessions.</t>

        <t>This deployment scenario is an implementation of the use case
        depicted in <xref target="uc2"></xref>.</t>

        <t><figure anchor="dep1"
            title="Network-Assisted MPTCP Fixed/Wireless Access Aggregation">
            <artwork><![CDATA[
  +------------+        _--------_    +----------------+
  |            |       (    LTE   )   |                |
  |   CPE      +=======+          +===+  Backbone      |
  |  (MCP)     |       (_        _)   |   Network      |
  |            |         (_______)    |+--------------+|
  |            |       IP Network #1  || Concentrator ||------> Internet
  |            |                      ||    (MCP)     ||
  |            |                      |+--------------+|
  |            |       IP Network #2  |                |
  |            |        _--------_    |                |
  |            |       (    DSL    )  |                |
  |            +=======+           +==+                |
  |            |       (_        _)   |                |
  +-----+------+        (_______)     +----------------+
        |
  ---- LAN ----
        |
    end-nodes
]]></artwork>
          </figure>For mobile operators that provide CPE-based mobile
        broadband services, LTE and WLAN resources can be aggregated by means
        of MPTCP. In such deployment scenario, the MCP function is enabled in
        the CPE and in the network.</t>
      </section>

      <section title="Data Center">
        <t>As discussed in Section 2.1 of <xref
        target="I-D.ietf-mptcp-experience"></xref>, MPTCP is being
        contemplated for deployment within data centers. Such deployments may
        adhere to the use cases defined in <xref target="uc2"></xref> or <xref
        target="uc3"></xref>. One or two MCPs may be enabled at the data
        center segment. The objective is to optimize the resources usage
        within the data center infrastructure.</t>

        <t>The presence of an MCP is transparent to the client side,
        nevertheless the origin client's IP address may be hidden to the
        ultimate server. Enforcing per-host policies at the server's side may
        be problematic if all connections are bound to an MCP's IP address. To
        mitigate this problem, MCPs may insert the TCP Option for Host
        Identification <xref target="RFC7974"></xref>.</t>
      </section>
    </section>

    <section anchor="mdc" title="Deployment &amp; Operational Considerations">
      <t></t>

      <section title="MCP Location">
        <t>The location of MCPs is deployment-specific. Network Providers may
        choose to adopt centralized or distributed designs. Nevertheless, in
        order to take advantage of MPTCP, the location of an MCP should not
        jeopardize packet forwarding performance overall.</t>
      </section>

      <section title="MCP Insertion in a Multipath Communication">
        <t>Two deployment scenarios can be considered for involving an MCP in
        the communication path. These scenarios are described below.</t>

        <section title="Explicit Mode (Off-path)">
          <t>This scenario assumes that the IP reachability information of an
          MCP is explicitly configured on a device, e.g., by means of a
          specific DHCP option <xref target="I-D.boucadair-mptcp-dhc"></xref>.
          A device can be a CPE or a host.</t>

          <t>MPTCP connections are established explicitly using the
          address(es) of the MCP (<xref target="sf1"></xref>). In order to
          forward packets to their ultimate destination, the MCP is provided
          during the connection establishment with the destination IP address
          (and optionally destination port numbers). Typically, this is
          achieved thanks to the use of the MP_CONVERT Information Element
          (IE) defined in <xref
          target="I-D.boucadair-mptcp-plain-mode"></xref>. <xref
          target="sf1"></xref> illustrates the flow exchange to established a
          communication with a legacy server (RM).</t>

          <t><figure align="center" anchor="sf1"
              title="Sample Connection Establishment (Explicit Mode)">
              <artwork><![CDATA[ ___________________
/ Host-based Model  \
\___________________/

+---+                                     +-----+      +--+
|H1 |                                     | MCP |      |RM|
+---+                                     +-----+      +--+
h1@h2@                                      mcp@        rm@
 | |                                         |           |
 | |src:hi@                          dst:mcp@|    dst:rm@|
 | |<=================MPTCP Leg=============>|<---TCP -->|
 | |                                         |           |

 ___________________
/  CPE-based Model  \
\___________________/

          Upstream                       Downstream
+--+      +-----+                         +-----+       +--+
|H1|      | MCP |                         | MCP |       |RM|
+--+      +-----+                         +-----+       +--+
 h1@    uMCP@1 uMCP@2                       dMCP@       rm@
 |           | |                              |           |
 |src:h1@    |src:uMCP@1             dst:dmcp@|           |
 |<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->|
 |    dst:rm@| |                              |    dst:rm@|
 |           | |                              |           |
 |           | |src:uMCP@2           dst:dmcp@|           |
 |           | |<===Secondary MPTCP subflow==>|<---TCP -->|
 |           | |             ...              |    dst:rm@|
 |           | |                              |           |

Legend:
  RM: A remote machine.
]]></artwork>
            </figure></t>

          <t>This scenario aims to avoid any adherence of the Network-Assisted
          MPTCP procedure and the underlying routing and forwarding policies.
          Furthermore, this scenario allows for more flexibility in terms of
          mounting MPTCP subflows as it does not require any specific order in
          the establishment of subflows among available interfaces.</t>

          <t>Because the MCP's reachability information is explicitly
          configured on the device, means to guarantee successful inbound
          MPTCP connections can be enabled in the device to instruct the MCP
          to maintain active bindings so that incoming packets can be
          successfully redirected towards the appropriate device.</t>
        </section>

        <section title="Implicit Mode (On-path)">
          <t>Unlike the explicit mode, the implicit mode assumes that the MCP
          is located on a default forwarding path (primary path). As such, the
          first subflow must always be placed over that primary path so that
          the MCP can intercept MPTCP flows. Once intercepted, the MCP
          advertises its reachability information by means of MPTCP signals
          (MP_JOIN or ADD_ADDR). <xref target="sf2"></xref> illustrates the
          flow exchange to establish a communication with a legacy server
          (RM).</t>

          <t>Note that a standard MPTCP implementation will try to establish
          other subflows using rm@. In order to prevent such behavior, H1 is
          instructed by some means to prevent establishing additional subflows
          to rm@. For example, the MCP may set the C-bit in MP_CAPABLE option
          (<xref target="I-D.ietf-mptcp-rfc6824bis"></xref>) it returns to
          H1.</t>

          <t><figure align="center" anchor="sf2"
              title="Sample Connection Establishment (Implicit Mode)">
              <artwork><![CDATA[ ___________________
/ Host-based Model  \
\___________________/

+----+                                     +-----+      +--+
| H1 |                                     | MCP |      |RM|
+----+                                     +-----+      +--+
h1@h2@                                      mcp@        rm@
 | |                                         |           |
 |src:h1@                             dst:rm@|    dst:rm@|
 |<============Initial MPTCP subflow========>|<---TCP -->|
 | |                       ...               |           |
 | |src:h2@                          dst:mcp@|    dst:rm@|
 | |<=========Secondary MPTCP subflow=======>|<---TCP -->|
 | |                       ...               |           |

 ___________________
/  CPE-based Model  \
\___________________/

          Upstream                       Downstream
+--+      +-----+                         +-----+      +--+
|H1|      | MCP |                         | MCP |      |RM|
+--+      +-----+                         +-----+      +--+
 h1@   uMCP@1 uMCP@2                       dMCP@       rm@
 |           | |                              |           |
 |src:h1@    |src:uMCP@1               dst:rm@|src:uMCP@1 |
 |<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->|
 |    dst:rm@| |                              |    dst:rm@|
 |           | |                              |           |
 |           | |src:uMCP@2            dst:mcp@|src:uMCP@1 |
 |           | |<===Secondary MPTCP subflow==>|<---TCP -->|
 |           | |             ...              |    dst:rm@|
 |           | |                              |           |
]]></artwork>
            </figure></t>

          <t>Subsequent subflows are then sent directly to the MCP (<xref
          target="sf2"></xref>). The handling of these subsequent subflows is
          identical to the one of the explicit mode; only the establishment of
          the initial subflow differs. Concretely, in reference to <xref
          target="fes"></xref>, once the upstream MCP intercepts an initial
          subflow, it adds itself to the MPTCP connection by sending ADD_ADDR
          on the primary subflow. Then, MP_JOIN is sent to the IP address
          conveyed in ADD_ADDR to create the secondary subflow.</t>

          <t><figure anchor="fes"
              title="Secondary Subflow Creation (Host-based Implicit Mode)">
              <artwork><![CDATA[+----+                                     +-----+      +--+
| H1 |                                     | MCP |      |RM|
+----+                                     +-----+      +--+
h1@h2@                                      mcp@        rm@
 | |                                         |           |
 |<==============ADD_ADDR====================|           |
 | | _______________________________________ |           |
 | |/            Secondary subflow          \|           |
 | |================SYN+MP_JOIN=============>|           |
 | |<============SYN/ACK(MPJOIN)=============|           |
 | |============ACK(MP_JOIN)================>|           |
 | |                       ...               |           |]]></artwork>
            </figure></t>

          <t></t>

          <section title="Demux Native MPTCP Flows from Proxied MPTCP Flows">
            <t>If no explicit signal is included in the initial SYN message,
            the MCP cannot distinguish "native" MPTCP connections from
            "proxied" ones. An operator that deploys MCP resources would like
            to control the MPTCP connections it terminate. For example, an
            operator may want to enforce a policy that consists in assisting
            only MPTCP connections that are established by an upstream MCP,
            not those that are established by an MPTCP host located behind a
            CPE.</t>

            <t>Because MPTCP connections are not destined explicitly to an
            MCP, an on-path MCP instance will need extra means to distinguish
            "native" MPTCP connections from "proxied" ones. The subsequent
            risk is that native MPTCP communications will be reverted to TCP
            connections as shown in <xref target="uc1a"></xref> if the MCP is
            instructed to always relay MPTCP connections to TCP ones. In this
            example, we suppose that C2 and S2 are MPTCP-capable, but C1 and
            S1 are not.</t>

            <t><figure align="center" anchor="uc1a"
                title="Example of a Broken E2E MPTCP Connection (On-path)">
                <artwork><![CDATA[          Upstream                     Downstream
+--+      +-----+                         +-----+      +--+
|C1|      | MCP |                         | MCP |      |S1|
+--+      +-----+                         +-----+      +--+
 |           |                              |           |
 |src:c1@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
 |<-TCP Leg->|<========MPTCP Leg===========>|<-TCP Leg->|
 |    dst:s1@|                              |    dst:s1@|
 |           |                              |           |

\_________________SINGLE PATH CLIENT/SERVER_____________/
 _________________MULTIPLE PATH CLIENT/SERVER___________
/                                                       \
             |                              |
 |           |                              |           |
 |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
 |<=MPTCP====|=============================>|<-TCP Leg->|
 |    dst:s2@|                              |    dst:s2@|
 |           |                              |           |
+--+      +-----+                         +-----+      +--+
|C2|      | MCP |                         | MCP |      |S2|
+--+      +-----+                         +-----+      +--+
          Upstream                     Downstream]]></artwork>
              </figure></t>

            <t>To mitigate this, the upstream MCP may be instructed to insert
            a MP_PREFER_PROXY option only for the MPTCP connections it
            establishes <xref target="I-D.boucadair-mptcp-plain-mode"></xref>.
            The absence of MP_PREFER_PROXY option instances is an explicit
            indication that this MPTCP connection is a native one. As such, an
            on-path MCP will not revert this connection into a TCP connection,
            but will forward packets without any modification to the next
            hop.</t>

            <t><xref target="uc1b"></xref> illustrates the results of such
            procedure: native MPTCP connections are established between
            MPTCP-capable client and server, while Network-Assisted MPTCP
            connections are established with the help of MCPs.</t>

            <t>Concretely, if the upstream MCP receives a SYN that includes
            the MP_PREFER_PROXY option, it MAY decide to forward it towards
            its final destination without modifying it. When the downstream
            MCP receives a SYN that does not include an MP_PREFER_PROXY, it
            forwards it towards its final destination.</t>

            <t><figure align="center" anchor="uc1b"
                title="Example of a Successful E2E MPTCP Connection  (On-path)">
                <artwork><![CDATA[          Upstream                       Downstream
+--+      +-----+                         +-----+      +--+
|C1|      | MCP |                         | MCP |      |S1|
+--+      +-----+                         +-----+      +--+
 |           |                              |           |
 |src:c1@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
 |<-TCP Leg->|<========MPTCP Leg(PP)=======>|<-TCP Leg->|
 |    dst:s1@|                              |    dst:s1@|
 |           |                              |           |

\_________________SINGLE PATH CLIENT/SERVER_____________/
 _________________MULTIPLE PATH CLIENT/SERVER___________
/                                                       \
             |                              |
 |           |                              |           |
 |src:c2@    |src:uMCP@1             dst:s1@|src:uMCP@1 |
 |<==========|============MPTCP========================>|
 |    dst:s2@|                              |    dst:s2@|
 |           |                              |           |
+--+      +-----+                         +-----+      +--+
|C2|      | MCP |                         | MCP |      |S2|
+--+      +-----+                         +-----+      +--+
          Upstream                      Downstream


Legend: 
   PP: MP_PREFER_PROXY]]></artwork>
              </figure></t>
          </section>
        </section>
      </section>

      <section title="Authorization">
        <t>The Network Provider that manages the various network attachments
        (including the MCPs) may enforce authentication and authorization
        policies using appropriate mechanisms. For example, a non-exhaustive
        list of methods to achieve authorization is provided hereafter: <list
            style="symbols">
            <t>The network provider may enforce a policy based on the
            International Mobile Subscriber Identity (IMSI) to verify that a
            user is allowed to benefit from the aggregation service. If that
            authorization fails, the Packet Data Protocol (PDP) context
            /bearer will not be mounted. This method does not require any
            interaction with the MCP.</t>

            <t>The network provider may enforce a policy based upon Access
            Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
            to control the CPEs that are authorized to communicate with an
            MCP. These ACLs may be installed as a result of RADIUS exchanges,
            for instance (<xref target="I-D.boucadair-mptcp-radius"></xref>).
            This method does not require any interaction with the MCP.</t>

            <t>The MCP may implement an Ident interface <xref
            target="RFC1413"></xref> to retrieve an identifier that will be
            used to assess whether that client is entitled to make use of the
            aggregation service. Ident exchanges will take place only when
            receiving the first subflow from a given source IP address.</t>

            <t>The device that embeds the MCP may also host a RADIUS client
            that will solicit an AAA server to check whether connections
            received from a given source IP address are authorized or not
            (<xref target="I-D.boucadair-mptcp-radius"></xref>).</t>
          </list></t>

        <t>A first safeguard against the misuse of MCP resources by
        illegitimate users (e.g., users with access networks that are not
        managed by the same service provider that operates the MCP) is to
        reject MPTCP connections received on the Internet-facing interfaces.
        Only MPTCP connections received on the customer-facing interfaces of
        an MCP will be accepted.</t>

        <t>Because only the CPE is entitled to establish MPTCP connections
        with an MCP, ACLs may be installed on the CPE to avoid that internal
        terminals issue MPTCP connections towards one of the MCPs.</t>
      </section>

      <section title="MCP Behaviors">
        <t>The MCP MUST be provided with instructions about the behavior to
        adopt with regards to the processing of source addresses. The
        following sub-sections elaborate on various schemes.</t>

        <section title="Transparent MCP">
          <t>Transparent Network-Assisted MPTCP deployment is a deployment
          where the visible source address of a packet forwarded by an MCP to
          a remote machine located in the Internet is the IP address of the
          endhost, not an address that is provisioned to the MCP. In order to
          intercept incoming traffic, specific IPv4/IPv6 routes are injected
          so that traffic is redirected towards the MCP.</t>

          <t>No dedicated IP address pool is required to the MCP for the
          Network-Assisted MPTCP service.</t>

          <section title="IPv4 Address Preservation">
            <t>The MCP can be tweaked to behave in the IPv4 address
            preservation mode. This is the IPv4 address assigned to the
            endhost (typically, within a mobile deployment context as
            discussed in <xref target="mob"></xref>) or a WAN address of the
            CPE for the wired case (<xref target="fixed"></xref>).</t>
          </section>

          <section title="Source IPv6 Prefix Preservation at Network-located MCP">
            <t>Some IPv6 deployments may require the preservation of the
            source IPv6 prefix (<xref target="addpp"></xref>).</t>

            <t>This model requires the MCP to support ALGs to accommodate
            applications with IPv6 address referrals.</t>

            <t><figure anchor="addpp"
                title="Example of Source IPv6 Prefix Preservation at Network-located MCP (Initial subflow)">
                <artwork><![CDATA[+--+      +-----+                                +---+        +--+
|H1|      | MCP |                                |MCP|        |RM|
+--+      +--+--+                                +---+        +--+
IP@s     IP@1, IP@2                              IP@mcf        IP@d
 |           ||                                     |           |
 |src:IP@s   ||src:IP@1                   dst:IP@mcf|src:IP@1   |
 |---------->||------------------------------------>|---------->|
 |   Dst:IP@d||                                     |   dst:IP@d|
 |           ||                                     |           |
 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--|
 |---ACK---->||----------------ACK----------------->|---ACK---->|
 |           ||                                     |           |

Legend:
  mcf: MCP Customer-facing Interface
]]></artwork>
              </figure></t>
          </section>

          <section title="Source IPv6 Address Preservation at Network-located MCP">
            <t>Some IPv6 deployments may require the preservation of the
            source IPv6 address (<xref target="addp"></xref>).</t>

            <t>This model avoids the need for the MCP to support ALGs to
            accommodate applications with IPv6 address referrals.</t>

            <t><figure anchor="addp"
                title="Example of Outgoing SYN with Source Address Preservation">
                <artwork><![CDATA[+--+      +-----+                                +---+        +--+
|H1|      | MCP |                                |MCP|        |RM|
+--+      +--++-+                                +---+        +--+
IP@s     IP@1, IP@2                              IP@mcf        IP@d
 |           ||                                     |           |
 |src:IP@s   ||src:IP@1                   dst:IP@mcf|src:IP@s   |
 |---------->||------------------------------------>|---------->|
 |   Dst:IP@d||                                     |   dst:IP@d|
 |           ||                                     |           |
 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--|
 |---ACK---->||----------------ACK----------------->|---ACK---->|
 |           ||                                     |           |
 |           ||                                     |           |
]]></artwork>
              </figure></t>
          </section>
        </section>

        <section title="Non-Transparent MCP">
          <t>Unlike the transport mode, this section focuses on deployments
          where a dedicated IP address pool is provisioned to the MCP for the
          Network-Assisted MPTCP service.</t>

          <section title="IPv4 Address Sharing at the at the Network-located MCP">
            <t>Because of global IPv4 address depletion, optimization of the
            IPv4 address usage is mandatory. This obviously includes the IPv4
            addresses that are assigned by the MCP at its Internet-facing
            interfaces (<xref target="addnp"></xref> and <xref
            target="addnp2"></xref>). A pool of global IPv4 addresses is
            provisioned to the MCP along with possible instructions about the
            address sharing ratio to apply (see Appendix B of <xref
            target="RFC6269"></xref>). Adequate forwarding policies are
            enforced so that traffic destined to an address of such pool is
            intercepted by the appropriate MCP.</t>

            <t><figure anchor="addnp"
                title="Example of Outgoing SYN without Source Address Preservation (Single-ended MCP)">
                <artwork><![CDATA[+--+                                            +---+        +--+
|H1|                                            |MCP|        |RM|
+--+                                            +---+        +--+
 ||                                                |           |
 ||src:IP@s        MP_CONVERT(D=0,IP@d)  dst:IP@mcf|src:IP@mif |
 ||-----------------------SYN--------------------->|---SYN---->|
 ||                                                |   dst:IP@d|
 ||                                                |           |
 ||<--------------------SYN/ACK--------------------|<-SYN/ACK--|
 ||-----------------------ACK--------------------->|---ACK---->|
 ||                                                |           |
 
Legend:
  mcf: MCP Customer-facing Interface
  mif: MCP Internet-facing Interface
]]></artwork>
              </figure></t>

            <t><figure anchor="addnp2"
                title="Example of Outgoing SYN without Source Address Preservation (Dual-ended MCPs)">
                <artwork><![CDATA[+--+      +-----+                                +---+        +--+
|H1|      | MCP |                                |MCP|        |RM|
+--+      +--++-+                                +---+        +--+
 |           ||                                     |           |
 |src:IP@s   ||src:IP@1 MP_CONVERT(D=0,IP@d)        |src:IP@mif |
 |---SYN---->||----------------SYN----------------->|---SYN---->|
 |   dst:IP@d||                           dst:IP@mcf|   dst:IP@d|
 |           ||                                     |           |
 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--|
 |---ACK---->||----------------ACK----------------->|---ACK---->|
 |           ||                                     |           |
 
]]></artwork>
              </figure></t>
          </section>

          <section title="IPv4 Address 1:1 Translation at the MCP">
            <t>For networks that do not face global IPv4 address depletion
            yet, the MCP can be configured so that source IPv4 addresses of
            the CPE are replaced with other (public) IPv4 addresses. A pool of
            global IPv4 addresses is then provisioned to the MCP for this
            purpose. Rewriting source IPv4 addresses may be used as a means to
            redirect incoming traffic towards the appropriate MCP.</t>
          </section>

          <section title="IPv6 Prefix Sharing (NPTv6) at the Network-located MCP">
            <t>Rewriting the source IPv6 prefix (<xref
            target="RFC6296"></xref>) may be needed to redirect incoming
            traffic towards the appropriate MCP. A pool of IPv6 prefixes is
            then provisioned to the MCP for this purpose.</t>
          </section>
        </section>
      </section>

      <section title="Address Family Considerations">
        <t>Subflows of a given MPTCP connection can be associated to the same
        address family or may be established with different address families.
        Also, the Network-Assisted MPTCP using MP_CONVERT IE, regardless of
        the addressing scheme enforced by each CPE network attachment. In
        particular, the plain transport mode indifferently accommodates the
        following combinations.</t>

        <texttable align="center" style="headers">
          <ttcol align="center">LAN Leg</ttcol>

          <ttcol align="center">MPTCP Legs</ttcol>

          <ttcol align="center">TCP Leg towards RM</ttcol>

          <c>IPv4</c>

          <c>IPv4</c>

          <c>IPv4</c>

          <c>IPv4</c>

          <c>IPv6</c>

          <c>IPv4</c>

          <c>IPv4</c>

          <c>IPv6 &amp; IPv4</c>

          <c>IPv4</c>

          <c>IPv6</c>

          <c>IPv6</c>

          <c>IPv6</c>

          <c>IPv6</c>

          <c>IPv4</c>

          <c>IPv6</c>

          <c>IPv6</c>

          <c>IPv6 &amp; IPv4</c>

          <c>IPv6</c>
        </texttable>

        <t></t>
      </section>

      <section title="Policies &amp; Configuration Parameters">
        <t></t>

        <section title="Towards End-to-End MPTCP Connections">
          <t>In order to promote the use of MPTCP end-to-end, the MCP MUST NOT
          strip MP_CPABALE from the SYN segments it forwards to their final
          destination (i.e., server). The communication leg between an MCP and
          the server may be placed using MPTCP if that server is
          MPTCP-capable, or falls back to TCP otherwise.</t>

          <t>There may be cases where remote servers will not respond to SYN
          segments with the MP_CAPABLE option, and therefore it is desirable
          to provide a mechanism to disable relaying MP_CAPABLE to some or all
          remote hosts.</t>

          <t>Also, an MCP SHOULD maintain a cache to record the servers that
          are known to cause excessive delays. Any subsequent connection to a
          server that is present in this cache MUST be placed using TCP. Cache
          entries MUST be flushed out after the expiry of a configurable
          timer; this timer is set by default to 24h.</t>

          <t>This default behavior would lead to the establishment of
          end-to-end MPTCP connections if the client and servers are both
          MPTCP-capable with or without the withdrawal of MCPs from the
          communication. Whether an MCP must be maintained in the processing
          of an MPTCP connection that involve MPTCP-capable clients and server
          is a configurable parameter. The default mode MUST be to maintain
          the MCP because its presence may solve several complications that
          may arise in some deployments, such:<list style="numbers">
              <t>The use of private IPv4 addresses in some access networks.
              Typically, additional subflows can not be added to the MPTCP
              connection without the help of an MCP.</t>

              <t>The assignment of IPv6 prefix only by some networks. If the
              server is IPv4-only, subflows that are placed over IPv6 cannot
              be added to an MPTCP connection towards that server.</t>

              <t>Some of the access networks are subject to subscription with
              volume quota. </t>
            </list></t>

          <t><xref target="noMCP"></xref> shows an example of a communication
          with MCP withdrawal. In this example, the MCP tracks the initial
          subflow. Upon receipt of MP_CAPABLE in the SYN/ACK from the server,
          this connection is not tracked any more by the proxy. Subsequent
          subflows are handled directly by the endhost and the server.</t>

          <t>For cases where some access networks are subject to a volume
          quota, it is desirable to support a signal to indicate to a remote
          peer how it must place data into available subflows. </t>

          <t><figure align="center" anchor="noMCP"
              title="Sample Connection Establishment with MCP Withdrawal (Implicit Mode)">
              <artwork><![CDATA[ ___________________
/ Host-based Model  \
\___________________/

+----+                     +-----+                     +--+
| H1 |                     | MCP |                     |RM|
+----+                     +-----+                     +--+
h1@h2@                       mcp@                       rm@
 | |                          |                          |
 | |src:h1             dst:rm@|src:h1             dst:rm@|
 | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>|
 | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===|
 | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>|
 | | __________________________________________________  |
 | |/            Secondary subflow                      \|
 | |=====================SYN+MP_JOIN====================>|
 | |<===================SYN/ACK(MPJOIN)==================|
 | |=====================ACK(MP_JOIN)===================>|
 | |                       ...                           |

]]></artwork>
            </figure></t>

          <t>If the MCP is instructed to be involved in the communication even
          if the server is MPTCP-capable, the flow exchange depicted in <xref
          target="wMCP"></xref> will be observed.</t>

          <t><figure align="center" anchor="wMCP"
              title="Sample Connection Establishment with MCP Withdrawal (Implicit Mode)">
              <artwork><![CDATA[ ___________________
/ Host-based Model  \
\___________________/

+----+                     +-----+                     +--+
| H1 |                     | MCP |                     |RM|
+----+                     +-----+                     +--+
h1@h2@                       mcp@                       rm@
 | |                          |                          |
 |src:h1               dst:rm@|src:h1             dst:rm@|
 |=======SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>|
 |<=======SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===|
 |=======ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>|
 |<==============ADD_ADDR=====|                          |
 | | ________________________ |                          |
 | |/    Secondary subflow   \|                          |
 | |src:h2            dst=mcp@|                          | 
 | |========SYN+MP_JOIN======>|           ....           |
 | |<======SYN/ACK(MPJOIN)====|                          |
 | |======ACK(MP_JOIN)=======>|                          |
 | |            ...           |                          |
]]></artwork>
            </figure></t>
        </section>

        <section title="Traffic Distribution Scheme">
          <t>The logic of traffic distribution over multiple paths is
          deployment-specific. This document does not require nor preclude any
          particular traffic distribution scheme. Nevertheless, MCPs MUST be
          configurable with a parameter to indicate which traffic distribution
          scheme to enable. Indeed, policies can be enforced by an MCP
          instance operated by the Network Provider to manage both upstream
          and downstream traffic. These policies may be subscriber-specific,
          connection-specific, system-wise, or else.</t>
        </section>

        <section title="Flows Eligible to Multipath Service">
          <t>The Multipath Client and MCPs may be provided with a set of
          classification policies to help electing flows for the MPTCP
          service. These policies may be provisioned either statically and
          dynamically (or a combination thereof).</t>

          <t>Also, multiple MCPs may serve a given end-user, as a function of
          the nature of the service or the traffic to be forwarded over MPTCP
          connections. For example, an MCP may be used by a service provider
          to proceed with CPE-targeted maintenance operations, whereas another
          MCP may be configured to service multi-path communications initiated
          by a set of end-users.</t>
        </section>

        <section title="TCP Fragmentation">
          <t>Methods to avoid TCP fragmentation, such as rewriting the TCP
          Maximum Segment Size (MSS) option, must be supported by MCPs.</t>
        </section>

        <section title="DSCP Preservation">
          <t>The MCP MAY be configured to preserve the same DSCP marking or
          enforce DSCP re-marking policies. DSCP preservation MUST be enabled
          by default.</t>
        </section>

        <section title="Supported Transport Protocols">
          <t>The MCP supports TCP by design. Additional transport protocols
          SHOULD be supported. A configuration parameter MUST be supported by
          the MCP to indicate which transport protocols can be relayed into an
          MPTCP connection.</t>

          <t><!--Checksum Adjustment
Given that both TCP and UDP checksums RFC0793 cover the pseudo-header that contains the source and destination IP addresses, the checksum should be updated to reflect the change of these addresses.
For the particular case of an UDP/TCP conversion, the UDP checksum can be computed from the TCP one and vice versa.--></t>
        </section>

        <section title="Logging">
          <t>If the MCP is used in global IPv4 address sharing environments,
          the logging recommendations discussed in Section 4 of <xref
          target="RFC6888"></xref> need to be considered. Security-related
          issues encountered in address sharing environments are documented in
          Section 13 of <xref target="RFC6269"></xref>. A configuration
          parameter should be supported to enable/disable the logging
          function.</t>
        </section>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not request any action from IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>MPTCP-related security threats are discussed in <xref
      target="RFC6181"></xref> and <xref target="RFC6824"></xref>. Additional
      considerations are discussed in the following sub-sections.</t>

      <section title="Privacy">
        <t>The MCP may have access to privacy-related information (e.g., IMSI,
        link identifier, subscriber credentials, etc.). The MCP MUST NOT leak
        such sensitive information outside a local domain.</t>
      </section>

      <section title="Denial-of-Service (DoS) ">
        <t>Means to protect the MCP against Denial-of-Service (DoS) attacks
        MUST be enabled. Such means include the enforcement of ingress
        filtering policies at the network boundaries <xref
        target="RFC2827"></xref>.</t>

        <t>In order to prevent the exhaustion of MCP's resources by
        establishing a large number of simultaneous subflows for each MPTCP
        connection, the MCP administrator SHOULD limit the number of allowed
        subflows per CPE for a given connection. Means to protect against SYN
        flooding attacks MUST also be enabled (<xref
        target="RFC4987"></xref>).</t>

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

      <section title="Illegitimate MCP">
        <t>Traffic theft is a risk if an illegitimate MCP is inserted in the
        path. Indeed, inserting an illegitimate MCP in the forwarding path
        allows traffic intercept and can therefore provide access to sensitive
        data issued by or destined to a host. To mitigate this threat, secure
        means to discover an MCP should be enabled.</t>
      </section>

      <section title="High Rate Reassembly">
        <t>The MCP may perform packet reassembly. Some security-related issues
        are discussed in <xref target="RFC4963"></xref><xref
        target="RFC1858"></xref><xref target="RFC3128"></xref>.</t>
      </section>
    </section>

    <section title="Contributors">
      <t>The following individuals contributed to this document:</t>

      <t><figure>
          <artwork><![CDATA[   Denis Behaghel
   OneAccess

   Email: Denis.Behaghel@oneaccess-net.com


   Stefano Secci
   Universite Pierre et Marie Curie
   Paris
   France

   Email: stefano.secci@lip6.fr


   Suresh Vinapamula
   Juniper
   1137 Innovation Way
   Sunnyvale, CA  94089
   USA

   Email: Sureshk@juniper.net


   SungHoon Seo
   Korea Telecom
   Seoul
   Korea

   Email: sh.seo@kt.com


   Wouter Cloetens
   SoftAtHome
   Vaartdijk 3 701
   3018 Wijgmaal
   Belgium

   Email: wouter.cloetens@softathome.com


   Ullrich Meyer
   Vodafone
   Germany

   Email: ullrich.meyer@vodafone.com


   Luis M. Contreras
   Telefonica
   Spain

   Email: luismiguel.contrerasmurillo@telefonica.com


   Bart Peirens
   Proximus

   Email: bart.peirens@proximus.com]]></artwork>
        </figure></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
      Nishida, and Christoph Paasch for the comments.</t>

      <t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
      Sri Gundavelli for the fruitful discussions held during the IETF#95
      meeting.</t>

      <t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
      Xavier Grall for their valuable comments.</t>

      <t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
      Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
      Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
      Srinivasan, and Raghavendra Mallya for the discussion.</t>
    </section>
  </middle>

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

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

      <?rfc include='reference.I-D.boucadair-mptcp-plain-mode'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.6888'?>

      <?rfc include='reference.I-D.boucadair-mptcp-radius'?>

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

      <?rfc include='reference.I-D.boucadair-mptcp-dhc'?>

      <?rfc include='reference.I-D.ietf-mptcp-experience'?>

      <?rfc include='reference.I-D.ietf-mptcp-rfc6824bis'?>

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

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

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

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

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

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

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

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

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