| Network Working Group | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Experimental | Orange |
| Expires: January 5, 2017 | D. Behaghel |
| OneAccess | |
| S. Secci | |
| UPMC | |
| W. Henderickx | |
| Nokia/Alcatel-Lucent | |
| R. Skog | |
| Ericsson | |
| O. Bonaventure | |
| Tessares | |
| S. Vinapamula | |
| Juniper | |
| S. Seo | |
| Korea Telecom | |
| W. Cloetens | |
| SoftAtHome | |
| U. Meyer | |
| Vodafone | |
| LM. Contreras | |
| Telefonica | |
| July 4, 2016 |
An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport Mode
draft-boucadair-mptcp-plain-mode-08
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 concentrator. This document focuses on a deployment scheme where the identity of the MPTCP concentrator(s) is explicitly configured on connected hosts.
This document specifies an MPTCP option that is used to avoid the encapsulation of packets and out-of-band signaling between the CPE and the MPTCP concentrator. Also, this document specifies how UDP traffic, in particular, can be distributed among available paths by leveraging MPTCP capabilities.
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].
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 January 5, 2017.
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.
One of the promising deployment scenarios for Multipath TCP (MPTCP, [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of such resources. This deployment scenario is called a network-assisted MPTCP model, and relies upon MPTCP proxies located on both the CPE and network sides (Figure 1). The latter plays the role of an MPTCP concentrator. Such concentrator terminates the MPTCP sessions established from CPEs, before redirecting traffic into legacy TCP sessions.
+------------+ _--------_ +----------------+
| | (e.g., LTE ) | |
| CPE +=======+ +===+ Backbone |
| (MPTCP | (_ _) | Network |
| Proxy) | (_______) |+--------------+|
| | IP Network #1 || Concentrator ||------> Internet
| | || (MPTCP proxy)||
| | |+--------------+|
| | IP Network #2 | |
| | _--------_ | |
| | ( e.g., DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +----------------+
|
---- LAN ----
|
end-nodes
Figure 1: "Network-Assisted" MPTCP Design
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. Thus, MPTCP proxies deployed in CPEs and in concentrators located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to optimize resource usage to achieve different goals that include (but are not limited to) bandwidth aggregation, primary/backup communication paths, and traffic offload management. Figure 2 depicts the various TCP connection legs in network-assisted MPTCP deployment models.
+--+ +-----+ +------------+ +--+ |H1| | CPE | |Concentrator| |RM| +--+ +--+--+ +------+-----+ +--+ | | | | |<=TCP Leg=>|<============MPTCP Leg==============>|<=TCP Leg=>| | | | | Legend: H1: Host 1 RM: Remote Machine
Figure 2: Connection Legs (CPE-based Model)
There are also MPTCP deployments to assist hosts that are directly connected to multiple networks to establish multi-path communications. The communication legs that are involved in such deployments are shown in Figure 2.
+--+ +------------+ +--+ |H1| |Concentrator| |RM| +--+ +------+-----+ +--+ | | | |<==================MPTCP Leg====================>|<=TCP Leg=>| | | |
Figure 3: Connection Legs (Host-based Model)
Most of the current operational deployments that take advantage of multi-interfaced devices rely upon the use of an encapsulation scheme (such as GRE [I-D.zhang-gre-tunnel-bonding]). 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 side to intercept traffic and redirect it towards the appropriate concentrator.
This specification assumes an MPTCP concentrator is reachable by means of one or multiple IP addresses. Also, it assumes the various network attachments provided to an MPTCP-enabled device (CPE or host) are managed by the same administrative entity. The IP reachability information of an MPTCP concentrator can be explicitly configured on a device, e.g., by means of a specific DHCP option [I-D.boucadair-mptcp-dhc]. This document assumes such explicit configuration. Additional assumptions are listed in Section 3.
Current operational MPTCP deployments by network operators are focused on the forwarding of TCP traffic. In addition, 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 need to be exchanged between two MPTCP proxies 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 MPTCP proxies, this document explains how a plain transport mode is enabled, so that packets are exchanged between the CPE and the concentrator 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.
The solution described in this document also works properly when NATs are present in the communication path between the CPE and the concentrator, unlike solutions that rely upon GRE tunneling. In particular, the solution proposed in this document accommodates deployments that involve CGN (Carrier Grade NAT) upstream the concentrator.
The plain transport mode is characterized as follows:
The reader should be familiar with the terminology defined in [RFC6824].
This document makes use of the following terms:
The following assumptions are made:
It is out of the scope of this document to discuss criteria for selecting traffic to be eligible to MPTCP service. It is out of scope of the document to specify how a CPE selects its concentrator(s), too.
Likewise, methods to avoid TCP fragmentation, such as rewriting the TCP Maximum Segment Size (MSS) option, are out of scope for this document.
This document focuses on the CPE-based model (i.e., the CPE embeds a MPTCP proxy that behaves on behalf of terminal devices), but plain transport mode can also apply to host-based models.
TCP/MPTCP session tracking by the MPTCP proxy is implementation-specific. Readers may refer to Section 2 of [RFC7857].
This specifications focuses on TCP and UDP. Future documents may specify the exact behavior for transporting other protocols over MPTCP connections.
Also, this specification focuses on a stateful design; stateless approaches that rely on including the Plain Mode option in all packets are out of scope.
As shown in Figure 2, TCP connections initiated by a host are converted by the CPE into MPTCP connections towards the concentrator. Then, the concentrator converts these connections into legacy TCP connections towards the final destinations. Since the concentrator can be located anywhere in the operator's network, Section 4.1 introduces a new TCP option to supply the concentrator with required information to forward the traffic to its final destination. When a CPE receives a SYN segment from a host of the LAN, it rewrites the destination address of that segment to an address of the concentrator, and places the original destination (and possibly source) addresses in this TCP option. Further details are specified in the following sub-sections.
Specific UDP processing is discussed in Section 5.
The Plain Mode (PM) 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 4.
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 4: Plain Mode MPTCP Option
When using an MPTCP connection to forward traffic (whether it's TCP traffic or any other traffic), the CPE (resp. the concentrator) MUST insert a Plain Mode option in a SYN packet sent to the concentrator (resp. the CPE). The Plain Mode option MUST be included in the SYN payload.
If the original SYN message contains data in its payload (e.g., [RFC7413]), that data MUST be placed right after PM 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 the TCP options and the beginning of the data included in the original SYN .
The Plain Mode option MUST only appear in SYN segments that contain the MP_CAPABLE option. SYN messages to create subsequent subflows of a given MPTCP connection MUST NOT include any PM option (Figure 5).
+-----+ +------------+ | CPE | |Concentrator| +-+-+-+ +------+-----+ | | | | | (Initial connection setup) | |------------------(PM)-------------->| |<------------------------------------| | | | | | (Additional subflow setup) | | |/---------------------------------\| | |\---------------------------------/| | | |
Figure 5: Carrying the Plain Mode Option (Focus on the MPTCP Leg)
By default, source IP address preservation is assumed for IPv6 while global address sharing is assumed for IPv4. This means that, by default, two plain mode option instances MUST be included in a SYN segment for IPv6 (both source and destination) and one instance MUST be present for IPv4 (either the source or the destination). The CPE and the concentrator MUST support a configurable parameter to modify this default behavior to accommodate alternate deployment models (see Section 6).
An implementation MUST ignore PM options that include multicast, broadcast, and host loopback addresses [RFC6890].
The 'Protocol' field of the PM option MUST be copied from the 'Protocol' field of the IPv4 header or set to the type of the transport header of the IPv6 packet that will be forwarded along MPTCP subflows. The CPE and the concentrator MAY be configured to disable traffic aggregation for some transport protocols because of the nature of the service they relate to (e.g., IP multicast traffic typically specific of live TV broadcasting services). By default, TCP and UDP traffic bonding MUST be enabled.
Because the source IP and/or destination IP addresses are communicated only during the SYN exchange of the initial subflow, the CPE and the concentrator MUST maintain a state that binds the MPTCP transport coordinates to the destination/source IP address, ports, and protocol. This specification discusses the external behavior of this stateful design; the internal behavior for maintaining that state is implementation-specific.
This document uses 'Internal transport session identifier' to identify a particular transport session on the LAN side of the CPE and 'External transport session identifier' to identify a particular transport session on the Internet-facing Interface of the concentrator. An implementation could use the classical 4-tuple (source and destination addresses and ports) as such an identifier.
An MPTCP proxy also needs to identify a particular MPTCP connection. We refer to it as the 'MPTCP transport coordinates'. An implementation could, for example, use the token assigned to a specific connection to identify an MPTCP connection. The 4-tuple of each subflow that belong to an MPTCP connection can also be part of the MPTCP transport coordinates.
Binding entries can be created as a result of a packet or be configured directly on the CPE or the concentrator.
An implementation may maintain distinct binding tables, each for a given transport protocol, or maintain one single binding table to handle all supported transport protocols.
Subflows can be added or deleted during the lifetime of an MPTCP connection based on triggers that are local to the CPE/concentrator, based on signals received from the concentrator/CPE, or as a result of processing a packet. These triggers are outside the scope of this specification.
The CPE must maintain a binding entry that allows to associate the internal transport address (IP address, port number) with one or a set of external IP transport addresses, that are assigned in the WAN interfaces of the CPE in the context of a given MPTCP connection. Each of the external transport addresses points to a subflow that is created between the CPE and the concentrator. For each binding entry, one or multiple transport session entries are maintained by the CPE and the concentrator. These session entries are meant to store the information that is required for rewriting packets. A session entry is created as a result of handling a packet.
A session entry maintained by the CPE may be structured as follows:
For example:
The structure of a session entry maintained by the concentrator may be as follows:
For example:
A configurable parameter MAY be supported by the CPE and the concentrator to terminate MPTCP connections with the FASTCLOSE procedure (Section 3.5 of [RFC6824]) when a binding entry expires.
If there is no binding state that matches a received non-SYN segment, the CPE/concentrator SHOULD reply with a RST segment. This behavior aims to synchronize the binding tables between the CPE and the concentrator by clearing bindings that are present either in the CPE or in the concentrator.
The configurable parameter is set by default to 'Disable'.
PM option usage for an outgoing TCP SYN (i.e., from the CPE to the concentrator) is as follows:
In order to appropriately handle incoming SYN packets, the concentrator (resp. CPE) are supposed to be configured with instructions that allows to redirect the traffic to the appropriate CPE (resp. Internal host).
Plain transport mode operation for an incoming TCP SYN (i.e., when traffic is forwarded from the concentrator towards the CPE) is as follows:
The required information to rewrite non-SYN packets that match an existing binding entry, is retrieved from the Binding Information Bases (BIB) maintained by the CPE and the concentrator (see Section 4.3). The MPTCP proxy may decide at any time to create or terminate subflows associated to an MPTCP connection. When a packet arrives, its content is transported over one of the subflows of a bound MPTCP connection.
Non-SYN messages exchanged in the context of an existing subflow and all messages for non-initial subflows do not include the PM option.
RST messages may be received from the LAN side of the CPE or by the concentrator in its Internet-facing interface. When the CPE or the concentrator receive a TCP RST matching an existing entry, it MUST apply the FASTCLOSE procedure defined in Section 3.5 of [RFC6824]) to terminate the MPTCP connection and the associated subflows. The transport coordinates of the FASTCLOSE messages are set according to the information maintained in the binding table.
The CPE and the concentrator SHOULD wait for 4 minutes before deleting the session and removing any state associated with it if no packets are received during that 4-minute timeout [RFC7857].
This document leverages the ability to create MPTCP connections on the CPE/concentrator to also carry data conveyed in UDP datagrams. A UDP flow can be defined as a series of UDP packets that have the same source and destination address and ports. Upon receipt of the first packet of such a flow, a binding entry (Section 4.3) is created to map this flow onto an MPTCP connection between the CPE and the concentrator. All the subsequent UDP segments of this UDP flow are transported over that MPTCP connection. The MPTCP connection is released when no traffic is exchanged for this flow (Section 5.1.3).
From an application standpoint, there may be a value to distribute UDP datagrams among available network attachments for the sake of network resource optimization, for example. This document uses MPTCP features to control how UDP datagrams are distributed among existing network attachments. The data carried in UDP datagrams belonging to a given UDP flow are therefore transported in an MPTCP connection. An MPTCP connection is bound to one UDP flow. New MPTCP connections are created in order to handle additional UDP flows.
The management of MPTCP connections that are triggered by UDP datagrams follows the guidelines documented in [RFC6824].
The following sub-sections exclusively focus on the external behavior to achieve UDP to TCP conversion (Section 5.1.1), and vice versa (Section 5.1.2).
This function is applied to UDP traffic received by the CPE from the LAN, and to UDP traffic received by the concentrator from one of its Internet-facing interfaces.
When the CPE (or the concentrator) receives a UDP datagram to be distributed over MPTCP subflows, it MUST check whether the packet matches an existing binding entry (Section 4.3).
If an entry is found, and the packet is to be placed on an existing subflow, the packet is processed according to the corresponding session entry. If an entry is found, but the packet should be placed on a new subflow, a session entry MUST be instantiated by the CPE for that outgoing packet. The information about the transport protocol (UDP, in this case) MUST also be included in this binding entry. In both cases, the CPE (or the concentrator) MUST proceed as follows:
UDP packets that are received by the concentrator, but do not match an existing binding, MUST be silently dropped.
UDP packets that are received by the CPE, but do not match an existing binding, MUST be proceed as follows:
When setting the source IP address, the destination IP address, and the IP address enclosed in the Plain Mode MPTCP option of the corresponding TCP packet, the same considerations as specified in Section 4.3 MUST be applied.
Whether one or multiple UDP payloads are included in the same TCP segment is implementation- and deployment-specific.
Upon receipt of a SYN segment containing the PM option specifying the UDP protocol, the concentrator MUST proceed as follows:
Upon receipt of a SYN segment containing the PM option specifying the UDP protocol, the CPE MUST proceed as follows:
Upon receipt of data over an MPTCP connection that is bound to a UDP flow, the 'Length' field is used to extract the UDP payloads from the bytestream and generates the corresponding UDP datagrams.
The concentrator (or the CPE) MUST follow the same procedure as mentioned in Section 4.3 for address and port rewriting purposes.
UDP-triggered subflows SHOULD be terminated by an MPTCP endpoint (CPE or concentrator) if no UDP packet matching the corresponding binding entry is received for at least 5 minutes (see Section 4.3 of [RFC4787]). Consequently, the procedure in Section 4.4.4 MUST be followed to terminate the MPTCP connection and the associated subflows. The transport coordinates of the FASTCLOSE messages are set according to the information maintained in the binding table.
+--------+ +------------+
| CPE | |Concentrator|
+--------+ +------------+
| |
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
dst=d_@| PM(D=0;Protocol=17;d_@) |dst=d_@
|<-----------------TCP SYN/ACK-----------------|
|---------------------TCP ACK----------------->|
src=s_@| |src=conc_@
---UDP-->|---------------------TCP Data---------------->|---UDP-->
dst=d_@| |dst=d_@
| |
....
src=s_@|src=cpe_@2 dst=conc_@1|src=conc_@
---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
dst=d_@| |dst=d_@
| |
|<-----------------TCP SYN/ACK-----------------|
|---------------------TCP ACK----------------->|
| |
....
Figure 6: Distributing UDP packets over multiple paths (1)
A flow example is shown in Figure 6 to illustrate how TCP packets are generated to relay UDP datagrams using several subflows. Non-SYN messages that belong to a given subflow do not include any PM option. Also, this example shows how subsequent UDP datagrams of this flow are transported over the existing subflow or how a new subflow is created. In this example, the SYN segment issued to add a new subflow also includes data received in the original UDP datagram.
Figure 7 shows an example of UDP datagrams that are transported over MPTCP subflows. Unlike the previous example, additional subflows to transport UDP datagrams of the same flow are established in advance between the CPE and the concentrator.
+--------+ +------------+
| CPE | |Concentrator|
+--------+ +------------+
| |
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|----------------TCP SYN (Data)--------------->|---UDP-->
dst=d_@| PM(D=0;Protocol=17;d_@) |dst=d_@
|<-----------------TCP SYN/ACK-----------------|
|---------------------TCP ACK----------------->|
src=s_@| |src=conc_@
---UDP-->|---------------------TCP Data---------------->|---UDP-->
dst=d_@| |dst=d_@
| |
....
| (Additional subflow setup) |
|src=cpe_@2 dst=conc_@1|
|--------------------TCP SYN------------------>|
|<-----------------TCP SYN/ACK-----------------|
|---------------------TCP ACK----------------->|
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|---------------------TCP Data---------------->|---UDP-->
dst=d_@| |dst=d_@
| |
....
src=s_@|src=cpe_@2 dst=conc_@1|src=conc_@
---UDP-->|---------------------TCP Data---------------->|---UDP-->
dst=d_@| |dst=d_@
| |
....
Figure 7: Distributing UDP packets over multiple paths (2)
The subsequent UDP/TCP header swapping introduced in Section 5.1 represents an overhead that is equal to the difference between TCP and UDP header sizes. To avoid fragmentation when processing large UDP datagrams, it is RECOMMENDED to increase the MTU of all links between the CPE and the concentrator to accommodate this overhead.
Nevertheless, in deployments where increasing the MTU of all links is not possible for some reason, the CPE and the concentrator SHOULD be configurable to enable/disable fragmentation and reassembly of UDP datagrams. The decision to enable or disable this parameter is deployment-specific. This parameter is set to 'Disabled' by default.
If this configurable parameter is set to 'Disabled', large UDP datagrams that may thus be fragmented MUST NOT be forwarded along the MPTCP connection, i.e., the bonding service MUST NOT be applied to such large packets.
If this configurable parameter is set to 'Enabled', the CPE and the concentrator MUST perform IPv4 fragmentation and reassembly for packets that exceed the link MTU. Concretely, IPv4 fragmentation MUST be performed once UDP/TCP header swapping is completed. Packet reassembly MUST occur before TCP/UDP header swapping. The behavior to adopt whenever the swapping of UDP/TCP headers leads to IPv4 fragmentation is as follows:
The remote MPTCP endpoint (CPE or concentrator) then adopts the following behavior:
In order to protect the CPE and the concentrator and minimize the risk of degrading the overall bonding service performance, dedicated resources SHOULD be reserved for handling fragments (e.g., by limiting the amount of resources to process out-of-order packets).
The forwarding of an IPv4 packet received on the Internet-facing interface of the concentrator requires the IPv4 destination address and the transport-protocol destination port for binding lookup purposes. If the first packet received contains the transport-protocol information, the concentrator uses a cache and forwards the fragments unchanged (i.e., without reassembly). A description of such a caching algorithm is outside the scope of this document. If subsequent fragments arrive before the first fragment, the concentrator SHOULD queue these fragments till the first fragment is received.
The processing of the first fragment MUST follow the same procedure as in Section 5.1.1. The rewriting of the IP addresses of subsequent fragments MUST follow the instructions maintained in the binding table and the fragmentation cache. The MF (More Fragments) bit and 'Fragment offset' field MUST NOT be modified by the concentrator.
If the first packet received contains the transport-protocol information, the CPE uses a cache and forwards the fragments unchanged (i.e., without reassembly). If subsequent fragments arrive before the first fragment, the concentrator SHOULD queue these fragments till the first fragment is received.
The processing of the first fragment MUST follow the same procedure as in Section 5.1.2. The rewriting of the IP addresses of subsequent fragments MUST follow the instructions maintained in the binding table and the fragmentation cache. The MF bit and 'Fragment offset' field MUST NOT be modified by the CPE.
If distinct address families are used in the UDP and MPTCP legs, fragmentation SHOULD be handled as described in Sections 4 and 5 of [RFC7915].
The Plain Transport Mode accommodates various deployment contexts such as:
+--+ +-----+ +------------+ +--+ |H1| | CPE | |Concentrator| |RM| +--+ +--+--+ +------+-----+ +--+ | | | | |Src:IP@s |Src:IP@cpe1 PM(D=0,IP@d) Dst:IP@ccf|Src:IP@cif | |---SYN---->|----------------SYN----------------->|---SYN---->| | Dst:IP@d| | Dst:IP@d| | | | | |<--SYN/ACK-|<---------------SYN/ACK--------------|<-SYN/ACK--| |---ACK---->|----------------ACK----------------->|---ACK---->| | | | | Legend: ccf: Concentrator Customer-facing Interface cif: Concentrator Internet-facing Interface
Figure 8: Example of Outgoing SYN without Source Address Preservation
+--+ +-----+ +------------+ +--+ |H1| | CPE | |Concentrator| |RM| +--+ +--+--+ +------+-----+ +--+ | | | | |Src:IP@s |Src:IP@cpe1 PM(D=0,IP@d) Dst:IP@ccf|Src:IP@s | |---------->|------------------------------------>|---------->| | Dst:IP@d| PM(D=1,IP@s) | Dst:IP@d| | | | | |<--SYN/ACK-|<---------------SYN/ACK--------------|<-SYN/ACK--| |---ACK---->|----------------ACK----------------->|---ACK---->| | | | |
Figure 9: Example of Outgoing SYN with Source Address Preservation
Subflows of a given MPTCP connection can be associated to the same address family or may be established with different address families. Also, the plain transport mode applies regardless of the addressing scheme enforced by each CPE network attachment. In particular, the plain transport mode indifferently accommodates the following combinations.
| LAN Leg | CPE-Concentrator Legs | Concentrator-RM Leg |
|---|---|---|
| IPv4 | IPv4 | IPv4 |
| IPv4 | IPv6 | IPv4 |
| IPv4 | IPv6 & IPv4 | IPv4 |
| IPv6 | IPv6 | IPv6 |
| IPv6 | IPv4 | IPv6 |
| IPv6 | IPv6 & IPv4 | IPv6 |
Also, the CPE and the concentrator may be configured to preserve the same DSCP marking or enforce DSCP re-marking policies, and the plain transport mode described in this document fully respects these DSCP marking policies. Those considerations are deployment-specific.
The Network Provider that manages the various network attachments (including the concentrators) may enforce authentication and authorization policies using appropriate mechanisms. For example, a non-exhaustive list of methods to achieve authorization is provided hereafter:
A first safeguard against the misuse of the concentrator resources by illegitimate users (e.g., users with access networks that are not managed by the same operator owning the concentrator) is to reject MPTCP connections received on the Internet-facing interfaces. Only MPTCP connections received on the customer-facing interfaces of a concentrator will be accepted.
Because only the CPE is entitled to establish MPTCP connections with a concentrator, ACLs may be installed on the CPE to avoid that internal terminals issue MPTCP connections towards one of the concentrators.
Given that the TCP and UDP checksum covers the pseudo-header that contains the source and destination IP addresses, the checksum should be updated to reflect the change of these addresses. For the particular case of UDP/TCP conversion (Section 5), the UDP checksum can be computed from the TCP one and vice versa.
If the concentrator is used in global IPv4 address sharing environments, the logging recommendations discussed in Section 4 of [RFC6888] need to be considered. Security-related issues encountered in address sharing environments are documented in Section 13 of [RFC6269].
The use of the Plain Transport Mode option is primarily meant for MPTCP designs that involve access networks managed by the same operator. Appropriate setup is required before MPTCP with the Plain Transport Mode option is activated, so that possible middleboxes located in these access networks do not strip MPTCP signals, nor remove data contained in the SYN payload.
The plain transport mode may be deployed at large but some complications may arise, e.g., if an in-path middlebox removes the MPTCP option or data from the SYN payload. These complications not specific to the Plain Mode, and are encountered whenever MPTCP is deployed.
In case that one of MPTCP subflow between CPE and concentrator includes mobile (e.g., LTE, 3G, etc), billing and accounting of the traffic may be considered per subflow, per subscriber, or else. Since packets generated from/to the subscriber (CPE) are destined/sourced to/from the concentrator, the EPC nodes may need to inspect, in some deployments, the destination/source address and/or port included in the plain mode option to check and make billing and accounting actions. Alternate deployment approaches may be adopted to avoid inspecting L3/4 information (e.g., rely on application-based filters, correlate flow characteristics retrieved using Policy and Charging Control (PCC) interfaces, etc.).
It is out of the scope of this document to make any recommendation in that area.
This document requests an MPTCP subtype code for this option:
MPTCP-related security threats are discussed in [RFC6181] and [RFC6824]. Additional considerations are discussed in the following sub-sections.
The concentrator may have access to privacy-related information (e.g., IMSI, link identifier, subscriber credentials, etc.). The concentrator MUST NOT leak such sensitive information outside a local domain.
Means to protect the MPTCP concentrator against Denial-of-Service (DoS) attacks MUST be enabled. Such means include the enforcement of ingress filtering policies at the network boundaries [RFC2827].
In order to prevent the exhaustion of concentrator's resources, by establishing a large number of simultaneous subflows for each MPTCP connection, the 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 a concentrator instance are yet another actual threat. Means to ensure that illegitimate nodes cannot connect to a network should be implemented.
Traffic theft is a risk if an illegitimate concentrator is inserted in the path. Indeed, inserting an illegitimate concentrator 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 a concentrator should be enabled.
The CPE and the concentrator may perform packet reassembly. Some security-related issues are discussed in [RFC4963][RFC1858][RFC3128].
Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi Nishida, and Christoph Paasch for the 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 valuable comments.
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.