Network Working Group M. Boucadair, Ed. Internet-Draft C. Jacquenet, Ed. Intended status: Standards Track Orange Expires: April 30, 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 October 27, 2016 An MPTCP Option for Network-Assisted MPTCP draft-boucadair-mptcp-plain-mode-09 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 April 30, 2017 [Page 1] Internet-Draft Plain MPTCP Transport Mode October 2016 This document specifies an MPTCP option that is used in the context of Network-Assisted MPTCP: MP_CONVERT. 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 April 30, 2017. Copyright Notice Copyright (c) 2016 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 April 30, 2017 [Page 2] Internet-Draft Plain MPTCP Transport Mode October 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Target Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Multipath Client . . . . . . . . . . . . . . . . . . . . 6 3.2. Multipath CPE . . . . . . . . . . . . . . . . . . . . . . 7 4. MP_CONVERT Option . . . . . . . . . . . . . . . . . . . . . . 7 5. MPTCP Connections from a Multipath TCP Client . . . . . . . . 10 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 11 6. MPTCP Connections Between Single Path Client and Server . . . 13 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 14 6.2.1. Downstream MCP . . . . . . . . . . . . . . . . . . . 14 6.2.2. Upstream MCP . . . . . . . . . . . . . . . . . . . . 14 7. Demux Native MPTCP Connections From Proxied MPTCP Connections 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . 19 9.3. Illegitimate MCP . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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. 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 Boucadair, et al. Expires April 30, 2017 [Page 3] Internet-Draft Plain MPTCP Transport Mode October 2016 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 8 SOCKS messages may have to be exchanged between two MCPs before an MPTCP connection is established, 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]. The plain transport mode is characterized as follows: o No encapsulation required (no tunnels, whatsoever). o No out-of-band signaling for each MPTCP subflow is required. o Carries any protocol for the benefit of massive MPTCP adoption. Boucadair, et al. Expires April 30, 2017 [Page 4] Internet-Draft Plain MPTCP Transport Mode October 2016 o Avoids interference with native MPTCP connections. o Targets both on-path and off-path MCPs. 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. 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 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 5 and Section 6. The first use case is a Multipath Client that interacts Boucadair, et al. Expires April 30, 2017 [Page 5] Internet-Draft Plain MPTCP Transport Mode October 2016 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. +--+ +-----+ +--+ |H1| | MCP | |RM| +--+ +-----+ +--+ | | | |<==================MPTCP Leg==============>|<---TCP -->| | | | Legend: H1: Host 1 MCP: Multipath Conversion Point RM: Remote Machine 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 connection that the MCP establishes with the Server. Because 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 proposes the MP_CONVERT option which is carried in the SYN segment of the initial subflow. This SYN segment is sent towards the MCP. The MP_CONVERT option contains the destination address (and Boucadair, et al. Expires April 30, 2017 [Page 6] Internet-Draft Plain MPTCP Transport Mode October 2016 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 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. 4. MP_CONVERT Option The MP_CONVERT (MC) option carries the source/destination IP addresses and/or port numbers of the origin source and destination nodes. It is also used to indicate whether the data carried in the packet is relayed from a native TCP connection or refers to the use of another transport protocol. The format of the option is shown in Figure 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|D|Flags| Protocol | +---------------+---------------+-------+-+-----+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | +-------------------------------+ Figure 3: MP_CONVERT Option Boucadair, et al. Expires April 30, 2017 [Page 7] Internet-Draft Plain MPTCP Transport Mode October 2016 The description of the fields is as follows: o Kind and Length: are the same as those defined in Section 3 of [RFC6824]. The minimum size of this option is 4 bytes. o Subtype: to be defined by IANA (Section 8). Implementations may use the "0xe" subtype encoding for early deployment purposes in managed networks. 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 "Flags" 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 Protocol: conveys the protocol number as assigned by IANA [proto_numbers]. o Address: includes a source or destination IP address. The address family is determined by the "Length" field. Concretely, a MP_CONVERT option that carries an IPv4 address has a Length field of 8 bytes (or 10, if a port number is included). A MP_CONVERT option that carries an IPv6 address has a Length of 20 bytes (or 22, if a port number is included). This field is optional. 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. The MP_CONVERT option is a variable length MPTCP option that MUST NOT be used in TCP segments whose SYN flag is reset. This option can only appear in the SYN used to create the initial subflow of a Multipath TCP connection (see the example in Figure 4). Up to two MP_CONVERT options can appear inside a SYN segment. If two MP_CONVERT options are included, these options MUST NOT have the same D-bit value. Boucadair, et al. Expires April 30, 2017 [Page 8] Internet-Draft Plain MPTCP Transport Mode October 2016 +----+ +-----+ +--+ | C | | MCP | |S | +----+ +-----+ +--+ | | ________________________________| | | / Initial subflow \ | | |========SYN(MP_CAPABLE+MC(S))===>| | | | |--SYN------->| | | |<--SYN/ACK---| | |<====SYN/ACK(MP_CAPABLE)=========| | | | ... | | | \ ________________________________/ | .... .... | | ________________________________| | | / Additional subflow \ | | \ ________________________________/ | Legend: <===>: MPTCP leg <--->: TCP leg Figure 4: Carrying the MP_CONVERT Option The MP_CONVERT option MUST be included in the SYN payload. NOTE 1: Given the length of the MP_CONVERT option, especially when IPv6 addresses are used, and the set of TCP options that are likely to be included in a SYN message, it will not always be possible to place the MP_CONVERT option inside the dedicated TCP option space. NOTE 2: Including data in a SYN payload is allowed as per Section 3.4 of [RFC0793]. NOTE 3: Stateless approaches that rely on inserting the MP_CONVERT option in all packets are out of scope. DISCUSSION NOTE: ADD DETAILS ABOUT THE NEED FOR AN EXPLICIT SIGNAL THAT MPTCP OPTIONS ARE INCLUDED IN THE SYN PAYLOAD? If the MP_CONVERT option 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 and "End of Options List" (EOL) options when generating the SYN in the MPTCP leg. The EOL option serves as a marker to delineate the end of Boucadair, et al. Expires April 30, 2017 [Page 9] Internet-Draft Plain MPTCP Transport Mode October 2016 the TCP options and the beginning of the data included in the original SYN . An implementation MUST ignore MP_CONVERT options that include multicast, broadcast, and host loopback addresses [RFC6890]. Concretely, an implementation that receives an MP_CONVERT option with such addresses MUST silently tear down the MPTCP connection. When an MCP creates an MPTCP connection triggered by an incoming packet, it MUST copy in the 'Protocol' field of the MP_CONVERT option the value of the 'Protocol' field (resp. type of the transport header) of the IPv4 (resp. IPv6) header of this incoming packet. The MCP may be configured to enable traffic aggregation for some transport protocols because of the nature of the service they relate to. By default, the 'Protocol' field MUST be set to 6 (TCP). 5. MPTCP Connections from a Multipath TCP Client 5.1. Description The simplest usage of the MP_CONVERT option 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 5. 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 April 30, 2017 [Page 10] Internet-Draft Plain MPTCP Transport Mode October 2016 C <===========>MCP <------------> S +<============>+ Legend: <===>: subflows of the upstream MPTCP connection <--->: downstream TCP connection Figure 5: A Multipath TCP Client interacts with a Server through a Multipath Conversion Point 5.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 option described in Figure 3. The destination address of the SYN segment is the IP address of the MCP. The MP_CONVERT option included in the SYN contains the IP address and optionally the destination port of the Server (see Figure 6). Boucadair, et al. Expires April 30, 2017 [Page 11] Internet-Draft Plain MPTCP Transport Mode October 2016 +----+ +-----+ +--+ | 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 6: 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 option (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 option 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. At this point, there are two established connections. The endpoints of the upstream Multipath TCP connection are the Multipath TCP Client and the MCP. The endpoints of the downstream TCP connection are the MCP and the Server. These two connections are bound by the MCP. Boucadair, et al. Expires April 30, 2017 [Page 12] Internet-Draft Plain MPTCP Transport Mode October 2016 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 [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. 6. MPTCP Connections Between Single Path Client and Server 6.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 this case, as illustrated in Figure 7, 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 Boucadair, et al. Expires April 30, 2017 [Page 13] Internet-Draft Plain MPTCP Transport Mode October 2016 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 7: A Client interacts with a Server through an upstream and a downstream Multipath Conversion Points 6.2. Theory of Operation 6.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 5.2. If the downstream MCP is deployed on-path, it only terminates MPTCP connections that carry an empty MP_CONVERT 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_CONVERT option, it MUST forward the SYN to its final destination without any modification. 6.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_CONVERT option that carries no IP address. 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@. 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. Boucadair, et al. Expires April 30, 2017 [Page 14] Internet-Draft Plain MPTCP Transport Mode October 2016 To initiate a connection with a remote server S, the Client sends a SYN segment that is intercepted by the upstream MCP which in turns initiates an MPTCP connection towards its downstream MCP that includes the MP_CONVERT option described in Figure 3. The destination address of the SYN segment is the IP address of the downstream MCP. The MP_CONVERT option 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 option. 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 8. Boucadair, et al. Expires April 30, 2017 [Page 15] Internet-Draft Plain MPTCP Transport Mode October 2016 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)========| | ||<========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 Figure 9: Example of a Broken E2E MPTCP Connection (On-path) To mitigate this, the upstream MCP may be instructed to insert a MP_CONVERT option only for the MPTCP connections it establishes. The absence of MP_CONVERT 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. Figure 10 illustrates the results of such procedure: native MPTCP connections are established between MPTCP-compliant client and server, while Networok-Assisted MPTCP connections are established with the help of MCPs. Concretely, if the upstream MCP receives a SYN that includes the MP_CAPABLE 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_CONVERT option, it forwards it towards its final destination. Boucadair, et al. Expires April 30, 2017 [Page 17] Internet-Draft Plain MPTCP Transport Mode October 2016 Upstream Downstream +--+ +-----+ +-----+ +--+ |C1| | MCP | | MCP | |S1| +--+ +-----+ +-----+ +--+ | | | | |src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 | |<-TCP Leg->|<========MPTCP Leg(MC)=======>|<-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 Figure 10: Example of a Successful E2E MPTCP Connection (On-path) 8. IANA Considerations This document requests an MPTCP subtype code for this option: o MP_CONVERT option NOTE: Implementations may use "0xe" subtype encoding for early deployment purposes in managed networks. 9. Security Considerations MPTCP-related security threats are discussed in [RFC6181] and [RFC6824]. Additional considerations are discussed in the following sub-sections. 9.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. Boucadair, et al. Expires April 30, 2017 [Page 18] Internet-Draft Plain MPTCP Transport Mode October 2016 9.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. 9.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. 10. 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). 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. 11. References Boucadair, et al. Expires April 30, 2017 [Page 19] Internet-Draft Plain MPTCP Transport Mode October 2016 11.1. Normative References [proto_numbers] http://www.iana.org/assignments/protocol-numbers, "Protocol Numbers". [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . 11.2. Informative References [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., Behaghel, D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Contreras, L., and B. Peirens, "Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational Considerations", draft-nam-mptcp-deployment- considerations-00 (work in progress), October 2016. [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-03 (work in progress), May 2016. Boucadair, et al. Expires April 30, 2017 [Page 20] Internet-Draft Plain MPTCP Transport Mode October 2016 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, DOI 10.17487/RFC1701, October 1994, . [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, . [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, . [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, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [TR-348] BBF, "Hybrid Access Broadband Network Architecture", July 2016. Authors' Addresses Mohamed Boucadair (editor) Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Boucadair, et al. Expires April 30, 2017 [Page 21] Internet-Draft Plain MPTCP Transport Mode October 2016 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 Suresh Vinapamula Juniper 1137 Innovation Way Sunnyvale, CA 94089 USA Email: Sureshk@juniper.net Boucadair, et al. Expires April 30, 2017 [Page 22] Internet-Draft Plain MPTCP Transport Mode October 2016 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 April 30, 2017 [Page 23]