[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10

Network Working Group                                  M. Boucadair, Ed.
Internet-Draft                                         C. Jacquenet, Ed.
Intended status: Standards Track                                  Orange
Expires: September 10, 2017                          O. Bonaventure, Ed.
                                                                Tessares
                                                             D. Behaghel
                                                               OneAccess
                                                                S. Secci
                                                                    UPMC
                                                      W. Henderickx, Ed.
                                                    Nokia/Alcatel-Lucent
                                                            R. Skog, Ed.
                                                                Ericsson
                                                           S. Vinapamula
                                                                 Juniper
                                                                  S. Seo
                                                           Korea Telecom
                                                             W. Cloetens
                                                              SoftAtHome
                                                                U. Meyer
                                                                Vodafone
                                                           LM. Contreras
                                                              Telefonica
                                                              B. Peirens
                                                                Proximus
                                                           March 9, 2017


        Extensions for Network-Assisted MPTCP Deployment Models
                  draft-boucadair-mptcp-plain-mode-10

Abstract

   Because of the lack of Multipath TCP (MPTCP) support at the server
   side, some service providers now consider a network-assisted model
   that relies upon the activation of a dedicated function called MPTCP
   Conversion Point (MCP).  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.  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.





Boucadair, et al.      Expires September 10, 2017               [Page 1]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   This document specifies extensions for Network-Assisted MPTCP
   deployment models.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.











Boucadair, et al.      Expires September 10, 2017               [Page 2]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Target Use Cases  . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Multipath Client  . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Multipath CPE . . . . . . . . . . . . . . . . . . . . . .   7
   4.  The MP_PREFER_PROXY MPTCP Option  . . . . . . . . . . . . . .   8
     4.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Option Processing . . . . . . . . . . . . . . . . . . . .   8
   5.  Supplying Data to MCPs  . . . . . . . . . . . . . . . . . . .   9
     5.1.  The MP_CONVERT Information Element  . . . . . . . . . . .   9
     5.2.  Processing an MP_CONVERT Information Element  . . . . . .  11
   6.  MPTCP Connections from a Multipath TCP Client . . . . . . . .  13
     6.1.  Description . . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Theory of Operation . . . . . . . . . . . . . . . . . . .  14
   7.  MPTCP Connections Between Single Path Client and Server . . .  16
     7.1.  Description . . . . . . . . . . . . . . . . . . . . . . .  16
     7.2.  Theory of Operation . . . . . . . . . . . . . . . . . . .  17
       7.2.1.  Downstream MCP  . . . . . . . . . . . . . . . . . . .  17
       7.2.2.  Upstream MCP  . . . . . . . . . . . . . . . . . . . .  17
   8.  Interaction with TFO  . . . . . . . . . . . . . . . . . . . .  19
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  21
     10.1.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . .  21
     10.2.  Denial-of-Service (DoS)  . . . . . . . . . . . . . . . .  21
     10.3.  Illegitimate MCP . . . . . . . . . . . . . . . . . . . .  21
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  22
     12.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   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 [RFC6824], can help achieve such
   better quality, but failed to be massively deployed so far.

   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.




Boucadair, et al.      Expires September 10, 2017               [Page 3]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   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.  MCPs can be deployed in CPEs
   (Customer Premises Equipment), as well as in the provider's network.
   MCPs are responsible for establishing multi-path communications on
   behalf of endpoints.  Further details about the target use cases are
   provided in Section 3.

   Most of the current operational deployments that take advantage of
   multi-interfaced devices rely upon the use of an encapsulation scheme
   (such as [I-D.zhang-gre-tunnel-bonding], [TR-348]).  The use of
   encapsulation is motivated by the need to steer traffic towards the
   concentrator and also to allow the distribution of any kind of
   traffic besides TCP (e.g., UDP) among the available paths without
   requiring any advanced traffic engineering tweaking technique in the
   network to intercept traffic and redirect it towards the appropriate
   MCP.

   Current operational MPTCP deployments by network operators are
   focused on the forwarding of TCP traffic.  The design of such
   deployments sometimes assumes the use of extra signalling provided by
   SOCKS [RFC1928], at the cost of additional management complexity and
   possible service degradation (e.g., up to 6 SOCKS messages may have
   to be exchanged between two MCPs before actual payload data to be
   transferred, thereby yielding several tens of milliseconds of extra
   delay before the connection is established) .

   To avoid the burden of encapsulation and additional signalling
   between MCPs, this document explains how a plain transport mode is
   enabled, so that packets are exchanged between a device and its
   upstream MCP without requiring the activation of any encapsulation
   scheme (e.g., IP-in-IP [RFC2473], GRE [RFC1701]).  This plain
   transport mode also avoids the need for out-of-band signalling,
   unlike the aforementioned SOCKS context.

   The solution described in this document also works properly when NATs
   are present in the communication path between a device and its
   upstream MCP.  In particular, the solution in this document
   accommodates deployments that involve CGN (Carrier Grade NAT)
   upstream the MCP.

   Network-Assisted MPTCP deployment and operational considerations are
   discussed in [I-D.nam-mptcp-deployment-considerations].




Boucadair, et al.      Expires September 10, 2017               [Page 4]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   The plain transport mode is characterized as follows:

   o  0-RTT proxy.
   o  No encapsulation required (no tunnels, whatsoever).
   o  No out-of-band signaling for each MPTCP subflow is required.
   o  Targets both on-path and off-path MCPs.
   o  Avoids interference with native MPTCP connections.
   o  Assists MPTCP connections even if endpoints are MPTCP-capable.
   o  Accommodates various deployment contexts, such as those that
      require the preservation of the source IP address and others
      characterized by an address sharing design.  In particular:

      *  This solution is compatible with IPv4/IPv6.
      *  This solution does not impose any constraint on the addressing
         scheme to be used by the client.
      *  This solution does not require nor exclude the use of distinct
         IP prefix pools for network-assisted MPTCP deployments.
      *  This solution supports both transparent and non-transparent
         operations.

2.  Terminology

   The reader should be familiar with the terminology defined in
   [RFC6824].

   This document makes use of the following terms:

   o  Client: an endhost that initiates transport flows forwarded along
      a single path.  Such endhost is not assumed to support multipath
      transport capabilities.

   o  Server: an endhost that communicates with a client.  Such endhost
      is not assumed to support multipath transport capabilities.

   o  Multipath Client: a Client that supports multipath transport
      capabilities.

   o  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 available at the endhosts is
      not relevant.

   o  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




Boucadair, et al.      Expires September 10, 2017               [Page 5]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


      destination addresses, the same protocol number and the same
      source and destination ports.

   o  Multipath Conversion Point (MCP): a function that terminates a
      transport flow and relays all data carried in the flow into
      another transport flow.

      MCP is a function that converts a multipath transport flow and
      relays it over a single path transport flow and vice versa.

3.  Target Use Cases

   We consider two important use cases in this document.  We briefly
   introduce them in this section and leave the details to Section 6 and
   Section 7.  The first use case is a Multipath Client that interacts
   with a remote Server through a MCP (Section 3.1).  The second use
   case is a multi-homed CPE that includes a MCP and interacts with a
   remote Server through a downstream MCP (Section 3.2).

3.1.  Multipath Client

   In this use case, the Multipath Client would like to take advantage
   of MPTCP even if the Server does not support MPTCP.  A typical
   example is a smartphone that could use both WLAN and LTE access
   networks to reach a server in order to achieve higher bandwidth or
   better resilience.

   +--+                                      +-----+      +--+
   |C |                                      | MCP |      |S |
   +--+                                      +-----+      +--+
    |                                           |           |
    |<==================MPTCP Leg==============>|<---TCP -->|
    |                                           |           |

   Legend:
       C: Client
     MCP: Multipath Conversion Point
       S: Server

            Figure 1: Network-assisted MPTCP (Host-based Model)

   In reference to Figure 1, the MCP terminates the MPTCP connection
   established by the client and binds it to a TCP connection towards
   the remote server.  Two deployments of this use case are possible.

   A first deployment is when the MCP is on the path between the
   Multipath Client and the Server.  In this case, the MCP can terminate
   the MPTCP connection initiated by the Client and binds it to a TCP



Boucadair, et al.      Expires September 10, 2017               [Page 6]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   connection that the MCP establishes with the Server.  When the MCP is
   not located on all default forwarding paths, the MPTCP connection
   must be initiated by using the path where the MCP is located.

   A second deployment is when the MCP is not on the path between the
   Multipath Client and the Server.  In this case, the Client must first
   initiate a connection towards the MCP and request it to initiate a
   TCP connection towards the Server.  This is what the SOCKS protocol
   performs by exchanging control messages to create appropriate
   mappings to handle the connection.  Unfortunately, this requires
   additional round-trip-time that affects the performance of the end-
   to-end data transfer, in particular for short-lived connections.

   This document specifies the MP_CONVERT Information Element that is
   carried in the SYN segment of the initial subflow.  This SYN segment
   is sent towards the MCP.  The MP_CONVERT Information Element contains
   the destination address (and optionally a port number) of the Server.
   Thanks to this information, the MCP can immediately establish the TCP
   connection with the Server without any additional round-trip-time,
   unlike a SOCKS-based MPTCP design.

3.2.  Multipath CPE

   In this use case, neither the Client nor the Server support MPTCP.
   Two MCPs are used as illustrated in Figure 2.  The upstream MCP is
   embedded in the CPE while the downstream MCP is located in the
   provider's network.  The CPE is attached to multiple access networks
   (e.g., xDSL and LTE).  The upstream MCP transparently terminates the
   TCP connections initiated by the Client and converts them into MPTCP
   connections.

                  Upstream                      Downstream
        +--+      +-----+                         +-----+      +--+
        |H1|      | MCP |                         | MCP |      |RM|
        +--+      +-----+                         +-----+      +--+
         |           |                              |           |
         |<---TCP--->|<========MPTCP Leg===========>|<---TCP--->|
         |           |                              |           |

            Figure 2: Network-assisted MPTCP (CPE-based Model)

   The same considerations detailed in Section 3.1 apply for the
   insertion of the downstream MCP in an MPTCP connection.








Boucadair, et al.      Expires September 10, 2017               [Page 7]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


4.  The MP_PREFER_PROXY MPTCP Option

   The implicit mode assumes that the MCP is located on a default
   forwarding path (Section 5.2.2 of
   [I-D.nam-mptcp-deployment-considerations]).  In such mode, 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).

   In order to distinguish native MPTCP connections from proxied ones, a
   new MPTCP option, called MP_PREFER_PROXY, is defined.  This option is
   meant to inform an on-path MCP that the connection should be proxied.
   The absence of the MP_PREFER_PROXY option is an indication that the
   corresponding MPTCP connection is native: an on-path MCP must not be
   involved in such connection.  If no explicit signal is included in
   the initial SYN message, the MCP cannot distinguish "native" MPTCP
   connections from "proxied" ones.

4.1.  Option Format

   The format of the MP_PREFER_PROXY is shown in Figure 3.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+-------+-----------------------+
       |     Kind      |    Length     |Subtype|         Reserved      |
       +---------------+---------------+-------+-----------------------+


                  Figure 3: MP_PREFER_PROXY MPTCP Option

   o  Kind and Length: are the same as those defined in Section 3 of
      [RFC6824].  The size of this option is 4 bytes.

   o  Subtype: must be allocated by IANA (Section 9).

   o  "Reserved" bits: are reserved bits for future assignment as
      additional flag bits.  These additional flag bits MUST each be set
      to zero and MUST be ignored upon receipt.

4.2.  Option Processing

   The MP_PREFER_PROXY option MUST only appear in the SYN message used
   to create the initial subflow of a Multipath TCP connection.

   If the MP_PREFER_PROXY appears in either a SYN segment that does not
   include the MP_CAPABLE option or a segment whose SYN flag is unset,



Boucadair, et al.      Expires September 10, 2017               [Page 8]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   it MUST be ignored.  An implementation MAY log this event since it
   likely indicates an operational issue.

   The sender inserts the MP_PREFER_PROXY option for MPTCP connections
   that it wants to be proxied by an on-path MCP.  Such insertion is
   possible only when there is enough space left in the dedicated TCP
   option space.

   Upon receipt of a SYN message with an MP_CAPABLE, the MCP MUST check
   whether an MP_PREFER_PROXY option is present:

   o  If no such option is included, the MCP MUST NOT interfere with
      that MPTCP connection (that is, it must not track this MPTCP
      connection).  Processing subsequent subflows of this connection
      will be handled directly by the endpoints.

   o  If the MP_PREFER_PROXY option is present, the MCP MUST track the
      establishment of the connection.  That means that the MCP must be
      prepared to insert itself for the establishment of subsequent
      subflows, in particular.

   Section 5.2.2.1 of [I-D.nam-mptcp-deployment-considerations] details
   the use of the MP_PREFER_PROXY option.

5.  Supplying Data to MCPs

   This section focuses mainly on th explicit mode (Section 5.2.1 of
   [I-D.nam-mptcp-deployment-considerations]) which assumes that the IP
   reachability information of an MCP is explicitly configured on a
   device, e.g., by means of a specific DHCP option
   [I-D.boucadair-mptcp-dhc].

5.1.  The MP_CONVERT Information Element

   In order to avoid extra delays when establishing a proxied MPTCP
   connection, specific information are provided to an MCP during the
   3WHS.  Such information is meant to help the MCP instantiate the
   required states to process the connection upstream.  The supply of
   such information is achieved by means of an object called the
   MP_CONVERT (MC) Information Element (IE).  This information element
   typically carries the source/destination IP addresses and/or port
   numbers of the used by the source and destination endpoints.  Other
   information may also be supplied to an MCP; future extensions may be
   defined.

   The format of the MP_CONVERT Information Element is shown in
   Figure 4.




Boucadair, et al.      Expires September 10, 2017               [Page 9]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------------------------------------------------------+
   |                        Magic Number                           |
   +---------------+---------------+---------------------------+-+-+
   |     Type      |     Length    |         Reserved          |D|M|
   +---------------+---------------+---------------------------+-+-+
   |          Address (IPv4 - 4 octets / IPv6 - 16 octets)         |
   +-------------------------------+-------------------------------+
   |   Port (2 octets, optional)   |
   +-------------------------------+


                 Figure 4: MP_CONVERT Information Element

   The description of the fields is as follows:

   o  Magic Number: This field MUST be set to "0xFAA8 0xFAA8" to
      indicate this is an MP_CONVERT Information Element.  This field is
      meant to unambiguously distinguish any data supplied by an
      application from the one injected by an MCP.  Other magic numbers
      are considered by the authors (e.g., 64 bits that include in
      addition to "0xFAA8 0xFAA8" 32 bits to enclose the RFC number).

   o  Type: This field indicates the type of the MP_CONVERT Information
      Element.  It MUST be set to 0 to indicate this element includes an
      IP address and, eventually, a port number.  Other type values MAY
      be defined in the future.

   o  Length: Indicates, in bytes, the length of MP_CONVERT Information
      Element.  The minimum size of this option is 4 bytes.

   o  "Reserved" bits: are reserved bits for future assignment as
      additional flag bits.  These additional flag bits MUST each be set
      to zero and MUST be ignored upon receipt.

   o  D-bit (Direction bit): this flag indicates whether the enclosed IP
      address (and port number) reflects the source or the destination
      IP address (and port number).  When the D-bit is set, the enclosed
      IP address must be interpreted as the source IP address.  When the
      D-bit is unset, the enclosed IP address must be interpreted as the
      destination IP address.

   o  M-bit (More bit): When the M-bit is unset, it indicates that
      another MP_CONVERT IE is included.  When the M-bit is set, it
      indicates this is the last MP_CONVERT IE included in the payload;
      if any data is placed right after this MP_CONVERT IE, it is
      application data.




Boucadair, et al.      Expires September 10, 2017              [Page 10]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   o  Address: includes a source or destination IP address.  The address
      family is determined by the "Length" field.  Concretely, a
      MP_CONVERT Information Element that carries an IPv4 address has a
      Length field of 8 bytes (or 10, if a port number is included).  A
      MP_CONVERT Information Element that carries an IPv6 address has a
      Length of 20 bytes (or 22, if a port number is included).

   o  Port: If the D-bit is set (resp. unset), a source (resp.
      destination) port number may be associated with the IP address.
      This field is valid for protocols that use a 16 bit port number
      (e.g., UDP, TCP, SCTP).  This field is optional.

   If the length of MP_CONVERT Information Element is not a multiple of
   4 bytes, padding MUST be added to preserve 32 bits boundaries.

5.2.  Processing an MP_CONVERT Information Element

   The MP_CONVERT Information Element is a variable length object that
   MUST NOT be used in TCP segments whose SYN flag is unset.  This IE
   can only appear in the TCP control messages with SYN flag set.  The
   information carried in the MP_CONVERT IE is used by an MCP to create
   the initial subflow of a Multipath TCP connection (see the example in
   Figure 5).

   Up to two MP_CONVERT Information Elements with type set to zero can
   appear inside a SYN segment.  If two MP_CONVERT Information Elements
   with type zero are included, these options MUST NOT have the same
   D-bit value.























Boucadair, et al.      Expires September 10, 2017              [Page 11]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


          +----+                              +-----+       +--+
          |  C |                              | MCP |       |S |
          +----+                              +-----+       +--+
           |  | ________________________________|             |
           |  /       Initial subflow           \             |
           |  |========SYN(MP_CAPABLE+MC(S))===>|             |
           |  |                                 |--SYN------->|
           |  |                                 |<--SYN/ACK---|
           |  |<====SYN/ACK(MP_CAPABLE)=========|             |
           |  |             ...                 |             |
           |  \ ________________________________/             |
                           ....                      ....
           |  | ________________________________|             |
           |  /       Additional subflow        \             |
           |  \ ________________________________/             |

          Legend:
               <===>: MPTCP leg
               <--->: TCP leg
                MC(): MP_CONVERT Information Element

           Figure 5: Carrying the MP_CONVERT Information Element

   The MP_CONVERT Information Element MUST be included in the payload of
   a TCP segment whose SYN flag is set.

   If the MP_CONVERT Information Element appears in either a SYN segment
   that does not include the MP_CAPABLE option or a segment whose SYN
   flag is reset, it MUST be ignored.  An implementation MAY log this
   event since it likely indicates an operational issue.

   If the original SYN message contains data in its payload (e.g.,
   [RFC7413]), that data MUST be placed right after the MP_CONVERT IEs
   when generating the SYN in the MPTCP leg.

   An implementation MUST ignore MP_CONVERT Information Elements that
   include multicast, broadcast, and host loopback addresses [RFC6890].
   Concretely, an implementation that receives an MP_CONVERT Information
   Element with such addresses MUST silently tear down the MPTCP
   connection.

   An implementation that supports the MP_CONVERT Information Element
   with type zero MUST echo in the SYN/ACK the instances of the
   MP_CONVERT Information Elements included in a SYN received from the
   sender.  A sender that does not receive in a SYN/ACK a copy of the
   MP_CONVERT Information Elements it included in a SYN message MUST
   terminate the MPTCP connection and falls back to TCP or native MPTCP
   connection.  Furthermore, the sender MUST add an entry to its local



Boucadair, et al.      Expires September 10, 2017              [Page 12]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   cache to record the MCPs that do not support the MP_CONVERT
   Information Element.  This cache MUST be flushed out under the
   following conditions: a new network attachment is detected by the
   host, a new MCP is configured, the host gets a new IP address/prefix,
   or a TTL has expired.  Subsequent connections to an MCP in the cache
   MUST NOT be placed using the explicit proxy mode.  This procedure is
   denoted as MCP capability discovery.

   In the following sections, MP_CONVERT Information Element is used to
   refer to the MP_CONVERT Information Element with the type field set
   to zero.  Future documents will specify the exact behavior of
   processing MP_CONVERT Information Elements with a non zero type
   field.

6.  MPTCP Connections from a Multipath TCP Client

6.1.  Description

   The simplest usage of the MP_CONVERT Information Element is when a
   Multipath TCP Client wants to use MPTCP to efficiently utilise
   different network paths (e.g., WLAN and LTE from a smartphone) to
   reach a server that does not support Multipath TCP.  The basic
   operation is illustrated in Figure 6.

   To use its multipath capabilities to establish an MPTCP connection
   over the available networks, the Client splits its end-to-end
   connection towards the TCP Server into two:

   (1)  An MPTCP connection, that typically relies upon the
        establishment of one subflow per network path, is established
        between the client and the MCP.

   (2)  A TCP connection that is established by the MCP with the server.

   Any data that is eligible to be transported over the MPTCP connection
   is sent by the Client towards the MCP over the MPTCP connection.  The
   MCP then forwards these data over the regular TCP connection until
   they reach the server.  The same forwarding principle applies for the
   data sent by the Server over the TCP connection with the MCP.












Boucadair, et al.      Expires September 10, 2017              [Page 13]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


        C <===========>MCP <------------> S
        +<============>+

   Legend:
     <===>: subflows of the upstream MPTCP connection
     <--->: downstream TCP connection

    Figure 6: A Multipath TCP Client interacts with a Server through a
                        Multipath Conversion Point

6.2.  Theory of Operation

   We assume in this section that the Multipath TCP Client has been
   configured with the IP address of one or more MCPs which convert the
   Multipath TCP connection into a regular TCP connection.  The address
   of such MCPs can be statically configured on the Client, dynamically
   provisioned to the MPTCP Client by means of a DHCP option
   [I-D.boucadair-mptcp-dhc], or by any other means that are outside the
   scope of this document.

   Conceptually, the MCP acts as a relay between an upstream MPTCP
   connection and a downstream TCP connection.  The MCP has at least a
   single IP address that is reachable from the Multipath TCP Client.
   It may be assigned other IP addresses.  For the sake of simplicity,
   we assume in this section that the MCP has a single IP address
   denoted MCP@. Similarly, we assume that the client has two addresses
   C@1 and C@2 while address S@ is assigned to the server.

   The MCP maps an upstream MPTCP connection (and its associated
   subflows) onto a downstream TCP connection.  On the MCP, an
   established Multipath TCP connection can be identified by the local
   Token that was assigned upon reception of the SYN segment.

   This Token is guaranteed to be unique on the MCP (provided that it
   has a single IP address) during the entire lifetime of the MPTCP
   connection.  The 4-tuple (IP src, IP dst, Port src, Port dst) is used
   to identify the downstream TCP connection.

   To initiate a connection to a remote server S, the Multipath TCP
   Client sends a SYN segment towards the MCP that includes the
   MP_CONVERT Information Element described in Figure 4.  The
   destination address of the SYN segment is the IP address of the MCP.
   The MP_CONVERT Information Element included in the SYN contains the
   IP address and optionally the destination port of the Server (see
   Figure 7).






Boucadair, et al.      Expires September 10, 2017              [Page 14]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


            +----+                              +-----+    +--+
            |  C |                              | MCP |    |S |
            +----+                              +-----+    +--+
            C@1 C@2                              MCP@       S@
             |  | ________________________________|          |
             |  /       Initial subflow           \          |
             |  |=======SYN(MP_CAPABLE+MC(S@))===>|          |
             |  |                                 |--SYN---->|
             |  |                                 |<-SYN/ACK-|
             |  |<====SYN/ACK(MP_CAPABLE)=========|          |
             |  |             ...                 |          |
             |  \ ________________________________/          |
                             ....                    ....
             |  |________________________________ |          |
             | /       Additional subflow        \|          |
             | \ ________________________________/           |

            Legend:
                 <===>: MPTCP leg
                 <--->: TCP leg

                  Figure 7: Single-ended MCP Flow Example

   The MCP processes this SYN segment as follows.  First, it generates
   the local key and a unique Token for the Multipath TCP connection.
   This Token identifies the MPTCP connection.  It is passed to the MCP
   together with the contents of the MP_CONVERT Information Element
   (i.e., the address of the destination server) and the destination
   port.

   The MCP then establishes a TCP connection with the destination
   server.  If the received MP_CONVERT Information Element contains a
   port number, it is used as the destination port of the outgoing TCP
   connection that is being established by the MCP.  Otherwise, the
   destination port of the upstream MPTCP connection is used as the
   destination port of the downstream TCP connection.  The MCP creates a
   flow entry for the downstream TCP connection and maps the upstream
   MPTCP connection onto the downstream TCP connection.

   The downstream TCP connection is considered to be active upon
   reception of the SYN/ACK segment sent by the destination server.  The
   reception of this segment triggers the MCP that confirms the
   establishment of the upstream MPTCP connection by sending a SYN/ACK
   segment towards the Multipath TCP Client (including MP_Convert).

   At this point, there are two established connections.  The endpoints
   of the upstream Multipath TCP connection are the Multipath TCP Client




Boucadair, et al.      Expires September 10, 2017              [Page 15]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   and the MCP.  The endpoints of the downstream TCP connection are the
   MCP and the Server.  These two connections are bound by the MCP.

   All the techniques defined in [RFC6824] can be used by the upstream
   Multipath TCP connection.  In particular, the subflows established
   over the different network paths can be controlled by either the
   Multipath TCP Client or the MCP.  It is likely that the network
   operators that deploy MCPs will define policies for the utilisation
   of the MCP.  These policies are discussed in Section 5.6 of
   [I-D.nam-mptcp-deployment-considerations].

   Any data received by the MCP on the upstream Multipath TCP connection
   will be forwarded by the MCP over the bound downstream TCP
   connection.  The same applies for data received over the downstream
   TCP connection which will be forwarded by the MCP over the upstream
   Multipath TCP connection.

   One of the functions of the MCP is to maintain the binding between
   the upstream Multipath TCP connection and the downstream TCP
   connection.  If the downstream TCP connection fails for some reason
   (excessive retransmissions, reception of a RST segment, etc.), then
   the MCP SHOULD force the teardown of the upstream Multipath TCP
   connection by transmitting a FASTCLOSE.  Similarly, if the upstream
   Multipath TCP connection fails for some reason (e.g., reception of a
   FASTCLOSE), the MCP SHOULD tear the downstream TCP connection down
   and remove the flow entries.

   The same reasoning applies when the upstream Multipath TCP connection
   ends with the transmission of DATA_FINs.  In this case, the MCP
   SHOULD also terminate the bound downstream TCP connection by using
   FIN segments.  If the downstream TCP connection terminates with the
   exchange of FIN segments, the MCP SHOULD initiate a graceful
   termination of the bound upstream Multipath TCP connection.

   An MCP SHOULD associate a lifetime with the Multipath TCP and TCP
   flow entries.  In this case, it SHOULD use the same lifetime for each
   pair of bounded connections.

7.  MPTCP Connections Between Single Path Client and Server

7.1.  Description

   There are situations where neither the client nor the server can use
   multipath transport protocols albeit network providers would want to
   optimize network resource usage by means of multi-path communication
   techniques.  Hybrid access service offerings are typical business
   incentives for such situations, where network operators combine a
   fixed network (e.g., xDSL) with a wireless network (e.g., LTE).  In



Boucadair, et al.      Expires September 10, 2017              [Page 16]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   this case, as illustrated in Figure 8, two MCPs are used for each
   flow.  The first MCP, located downstream of the client, converts the
   single path TCP connection originated from the client into a
   Multipath TCP connection established with a second MCP.  The latter
   will then establish a TCP connection with the destination server.

             Upstream        Downstream
        C <---> MCP <===========> MCP <------------> S
                  +<=============>+

   Legend:
        <===>: MPTCP leg
        <--->: TCP leg

   Figure 8: A Client interacts with a Server through an upstream and a
                  downstream Multipath Conversion Points

7.2.  Theory of Operation

7.2.1.  Downstream MCP

   The downstream MCP can be deployed on-path or off-path.  If the
   downstream MCP is deployed off-path, its behavior is described in
   Section 6.2.

   If the downstream MCP is deployed on-path, it only terminates MPTCP
   connections that carry an empty MP_PREFER_PROXY option inside their
   SYN (i.e., no address is conveyed).  If the MCP receives a SYN
   segment that contains the MP_CAPABLE option but no MP_PREFER_PROXY,
   it MUST forward the SYN to its final destination without any
   modification.

7.2.2.  Upstream MCP

   The upstream and downstream MCPs cooperate.  The upstream MCP may be
   configured with the addresses of downstream MCPs.  If the downstream
   MCP is deployed on-path, the upstream MCP inserts an MP_PREFER_PROXY
   option.

   In this section, we assume that the upstream MCP has been configured
   with one address of the downstream MCP.  This address can be
   configured statically, dynamically distributed by means of a DHCP
   option [I-D.boucadair-mptcp-dhc], or by any other means that are
   outside the scope of this document.

   We assume that the upstream MCP has two addresses uMCP@1 and uMCP@2
   while the downstream MCP is assigned a single IP address dMCP@.




Boucadair, et al.      Expires September 10, 2017              [Page 17]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   The upstream MCP maps an upstream TCP connection onto a downstream
   MPTCP connection (and its associated subflows) . On the upstream MCP,
   an established MPTCP connection can be identified by the local Token
   that was assigned upon reception of the SYN segment from the Client.

   The Client sends a SYN segment addressed to the Server and it is
   intercepted by the upstream MCP which in turns initiates an MPTCP
   connection towards its downstream MCP that includes the MP_CONVERT
   Information Element described in Figure 4.  The destination address
   of the SYN segment is the IP address of the downstream MCP.  The
   MP_CONVERT Information Element included in the SYN contains the IP
   address and optionally the destination port of the Server; this
   information is extracted from the SYN message received over the
   upstream TCP connection.

   Concretely, the upstream MCP processes the SYN segment received from
   the Client as follows.

   First, it generates the local key and a unique Token for the
   Multipath TCP connection to identify the MPTCP connection.  It
   extracts the destination IP address and, optionally, the destination
   port that will then be carried in a MP_CONVERT Information Element.
   The upstream MCP establishes an MPTCP connection with the downstream
   MCP.  The upstream MCP creates a flow entry for the downstream MPTCP
   connection and maps the upstream TCP connection onto the downstream
   MPTCP connection.

   The downstream MPTCP connection is considered to be active upon
   reception of the SYN+ACK segment from the downstream MCP.  The
   reception of this segment triggers the upstream MCP that confirms the
   establishment of the upstream TCP connection by sending a SYN+ACK
   segment towards the TCP Client.

   At this point, there are two established connections maintained by
   the upstream MCP:

   (1)  The endpoints of the upstream TCP connection are the Client and
        the upstream MCP.

   (2)  The endpoints of the downstream MPTCP connection are the
        upstream MCP and the downstream MCP.

   These two connections are bound by the upstream MCP.  An example is
   shown in Figure 9.







Boucadair, et al.      Expires September 10, 2017              [Page 18]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


             Upstream                     Downstream
   +--+      +-----+                        +-----+      +--+
   |C1|      | MCP |                        | MCP |      |S1|
   +--+      +-----+                        +-----+      +--+
    C@1   uMCP@1 uMCP@2                       dMCP@       S@
     |         | |______________________________|          |
     |--SYN--->|/       Initial subflow         \          |
     |         |=======SYN(MP_CAPABLE+MC(S@))==>|          |
     |         |                                |--SYN---->|
     |         |                                |<-SYN/ACK-|
     |         |<====SYN/ACK(MP_CAPABLE)========|          |
     |<SYN/ACK-|              ...               |          |
     |          \ ______________________________/          |
                            ....                    ....
     |         | | ____________________________ |          |
     |         | |/       Additional subflow   \|          |
     |         | |\ ___________________________/|          |
                                ....

                   Figure 9: Dual-Ended MCP Flow Example

   All the techniques defined in [RFC6824] can be used by the MPTCP
   connection.  In particular, the utilisation of the different network
   paths can be controlled by one MCP or the other.

   Any data received by the upstream MCP over the upstream TCP
   connection will be forwarded by the MCP over the bound downstream
   MPTCP connection, assuming such data are eligible to MPTCP transport.
   The same applies for data received over the downstream MPTCP
   connection which will be forwarded by the upstream MCP over the
   upstream TCP connection.

   The same considerations as in Section 6.2 apply for the maintenance
   of the connections by the upstream MCP.

8.  Interaction with TFO

   This section discusses the implications of using MP_CONVERT
   Information Elements with TCP Fast Open (TFO).  We distinguish
   between TFO negotiation (i.e., a Fast Open option with an empty
   cookie field to request a cookie) and TFO data (i.e., SYN with data
   and the cookie in the Fast Open option).

   This section focuses on the implications of using MP_CONVERT
   Information Element on TFO efficiency.  Implications related to MPTCP
   options and TFO negotiation are not specific to this document; the
   reader may refer to [I-D.barre-mptcp-tfo].




Boucadair, et al.      Expires September 10, 2017              [Page 19]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   Distinct implications are assessed depending whether TFO negotiation
   and usage occurs before MCP capability discovery phase is completed
   or not (Section 5.2).  Concretely, the following cases are discussed:

   1.  MCP capability discovery was already completed prior to receiving
       a message with TFO negotiation or TFO data: For this case, the
       host has already contacted its MCP in the context of a prior
       connection.  The outcome of such connections is used to determine
       the capabilities of its MCP (Section 5.2).

       A.  The MCP supports MP_CONVERT Information Element: Any
           information provided to an MCP to facilitate MPTCP operation
           is unambiguously distinguished from TFO data that are also
           included in the SYN payload.  An upstream MCP will remove the
           MP_CONVERT Information Elements before relaying the SYN
           message (with TFO data) to the next hop.

       B.  The MCP does not support MP_CONVERT Information Element: No
           additional issue is raised for obvious reasons.

   2.  MCP capability discovery is not completed prior to receiving a
       message with TFO negotiation or TFO data.

       A.  If the same message is used to negotiate TFO and to retrieve
           the capabilities of the MCP, extra delay may be observed
           before negotiating TFO if the MCP does not support the
           MP_CONVERT Information Element.  Obviously, no concern is
           raised when the MCP supports the MP_CONVERT Information
           Element.

       B.  If the same message includes TFO data and is used to retrieve
           the capabilities of the MCP, extra delay may be observed
           before negotiating TFO if the MCP does not support the
           MP_CONVERT Information Element.  Obviously, no concern is
           raised when the MCP supports the MP_CONVERT Information
           Element.

   To mitigate cases where extra delays are experienced when TFO is
   present, it is RECOMMENDED to not proxy connections with TFO before
   the MCP capability discovery procedure is completed.

9.  IANA Considerations

   This document requests an MPTCP subtype code for this option:

   o  MP_PREFER_PROXY





Boucadair, et al.      Expires September 10, 2017              [Page 20]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


10.  Security Considerations

   MPTCP-related security threats are discussed in [RFC6181] and
   [RFC6824].  Additional considerations are discussed in the following
   sub-sections.

10.1.  Privacy

   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.

10.2.  Denial-of-Service (DoS)

   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 [RFC2827].

   In order to prevent the exhaustion of MCP resources by establishing a
   great 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 ([RFC4987]).

   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.

10.3.  Illegitimate MCP

   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.

11.  Acknowledgements

   Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
   Nishida, and Christoph Paasch for their valuable comments.

   Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
   Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
   Aires).





Boucadair, et al.      Expires September 10, 2017              [Page 21]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
   Xavier Grall for their inputs.

   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.

   The design approach adopted in -10 is the outcome of fruitful
   discussions with Alan Ford.  Many thanks Alan.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
              <http://www.rfc-editor.org/info/rfc6824>.

   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
              "Special-Purpose IP Address Registries", BCP 153,
              RFC 6890, DOI 10.17487/RFC6890, April 2013,
              <http://www.rfc-editor.org/info/rfc6890>.

12.2.  Informative References

   [I-D.barre-mptcp-tfo]
              Barre, S., Detal, G., and O. Bonaventure, "TFO support for
              Multipath TCP", draft-barre-mptcp-tfo-01 (work in
              progress), January 2015.

   [I-D.boucadair-mptcp-dhc]
              Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options
              for Network-Assisted Multipath TCP (MPTCP)", draft-
              boucadair-mptcp-dhc-06 (work in progress), October 2016.

   [I-D.nam-mptcp-deployment-considerations]
              Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx,
              W., and R. Skog, "Network-Assisted MPTCP: Use Cases,
              Deployment Scenarios and Operational Considerations",
              draft-nam-mptcp-deployment-considerations-01 (work in
              progress), December 2016.



Boucadair, et al.      Expires September 10, 2017              [Page 22]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   [I-D.zhang-gre-tunnel-bonding]
              Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and
              M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", draft-
              zhang-gre-tunnel-bonding-05 (work in progress), December
              2016.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701,
              DOI 10.17487/RFC1701, October 1994,
              <http://www.rfc-editor.org/info/rfc1701>.

   [RFC1928]  Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
              L. Jones, "SOCKS Protocol Version 5", RFC 1928,
              DOI 10.17487/RFC1928, March 1996,
              <http://www.rfc-editor.org/info/rfc1928>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <http://www.rfc-editor.org/info/rfc2473>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <http://www.rfc-editor.org/info/rfc2827>.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
              <http://www.rfc-editor.org/info/rfc4987>.

   [RFC6181]  Bagnulo, M., "Threat Analysis for TCP Extensions for
              Multipath Operation with Multiple Addresses", RFC 6181,
              DOI 10.17487/RFC6181, March 2011,
              <http://www.rfc-editor.org/info/rfc6181>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <http://www.rfc-editor.org/info/rfc7413>.

   [TR-348]   BBF, "Hybrid Access Broadband Network Architecture", July
              2016.

Authors' Addresses









Boucadair, et al.      Expires September 10, 2017              [Page 23]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   Mohamed Boucadair (editor)
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com


   Christian Jacquenet (editor)
   Orange
   Rennes
   France

   Email: christian.jacquenet@orange.com


   Olivier Bonaventure (editor)
   Tessares
   Belgium

   Email: olivier.bonaventure@tessares.net


   Denis Behaghel
   OneAccess

   Email: Denis.Behaghel@oneaccess-net.com


   Stefano Secci
   UPMC

   Email: stefano.secci@lip6.fr


   Wim Henderickx (editor)
   Nokia/Alcatel-Lucent
   Belgium

   Email: wim.henderickx@alcatel-lucent.com


   Robert Skog (editor)
   Ericsson

   Email: robert.skog@ericsson.com





Boucadair, et al.      Expires September 10, 2017              [Page 24]


Internet-Draft         Plain MPTCP Transport Mode             March 2017


   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







Boucadair, et al.      Expires September 10, 2017              [Page 25]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/