| Network Working Group | M. Boucadair, Ed. |
| Internet-Draft | C. Jacquenet, Ed. |
| Intended status: Informational | Orange |
| Expires: June 10, 2017 | O. Bonaventure, Ed. |
| Tessares | |
| W. Henderickx, Ed. | |
| Nokia/Alcatel-Lucent | |
| R. Skog, Ed. | |
| Ericsson | |
| December 7, 2016 |
Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational Considerations
draft-nam-mptcp-deployment-considerations-01
Network-Assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. MPTCP Conversion Points (MCPs) located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management.
This document describes Network-Assisted MPTCP uses cases, deployment scenarios, and operational considerations.
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 June 10, 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.
The overall quality of connectivity services can be enhanced by combining several access network links for various purposes - resource optimization, better resiliency, etc. Some transport protocols, such as Multipath TCP, can help achieve such better quality, but failed to be massively deployed so far.
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 on behalf of hosts so that they can take advantage of establishing communications over multiple paths.
Such MCPs can be deployed in CPEs (Customer Premises Equipment), as well in the network side. MCPs are responsible for establishing multi-path communications on behalf of endpoints.
This document describes Network-Assisted MPTCP uses cases (Section 3), deployment scenarios (Section 4), and operational considerations (Section 5).
The reader should be familiar with the terminology defined in [RFC6824].
This document makes use of the following terms:
The first use case is a Multipath Client that interacts with a Server. To benefit from the capabilities of its multipath transport protocol, the Multipath Client will interact with a Multipath Conversion Point (MCP) located in the network as illustrated in Figure 1.
C <===========>MCP <------------> S
+<============>+
Legend:
<===>: MPTCP leg
Figure 1: A Multipath Client interacts with a Server through a Multipath Conversion Point
C <---------> MCP <===========> S
+<=============>+
Figure 2: A Client interacts with a Multipath Server through a Multipath Conversion Point
Figure 3: A (single path) transport flow between the Client and the upstream MCP, a multipath transport flow between the upstream and the downstream MCPs, and a single path transport flow between the downstream MCP and the Server.
Upstream Downstream
C <---> MCP <===========> MCP <------------> S
+<=============>+
Figure 3: A Client interacts with a Server through two Multipath Conversion Points
This section discusses some deployment scenarios related to Network-Assisted MPTCP designs.
This deployment scenario is considered by mobile operators so that they can propose their customers to aggregate LTE resources with WLAN resources.
As depicted in Figure 4, the mobile terminal (UE, User Equipment) is MPTCP-capable. The MCP function is enabled in the network to terminate MPTCP connections (e.g., in the PDN Gateway, a dedicated service function located at the (S)Gi interface, co-located with a TCP proxy, etc.).
This deployment scenario is an implementation of the use case depicted in Figure 1.
+------------+ _--------_ +----------------+ | | ( LTE ) | | | UE +=======+ +===+ Backbone | | (MPTCP | (_ _) | Network | | Client) | (_______) |+--------------+| | | IP Network #1 || Concentrator ||------> Internet | | || (MCP) || | | |+--------------+| | | IP Network #2 | | | | _--------_ | | | | ( ) | | | +=======+ WLAN +==+ | | | (_ _) | | +------------+ (_______) +----------------+
Figure 4: Network-Assisted MPTCP LTE/WLAN Aggregation (Host-based model)
One of the promising deployment scenarios for Multipath TCP is to enable a CPE that is connected to multiple access networks (e.g., DSL, LTE, WLAN) to optimize the usage of such resources. This deployment scenario, called Hybrid Access, relies upon MCPs located in both the CPE and the network (Figure 5). 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.
This deployment scenario is an implementation of the use case depicted in Figure 2.
+------------+ _--------_ +----------------+
| | ( LTE ) | |
| CPE +=======+ +===+ Backbone |
| (MCP) | (_ _) | Network |
| | (_______) |+--------------+|
| | IP Network #1 || Concentrator ||------> Internet
| | || (MCP) ||
| | |+--------------+|
| | IP Network #2 | |
| | _--------_ | |
| | ( DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +----------------+
|
---- LAN ----
|
end-nodes
Figure 5: Network-Assisted MPTCP Fixed/Wireless Access Aggregation
As discussed in Section 2.1 of [I-D.ietf-mptcp-experience], MPTCP is being contemplated for deployment within data centers. Such deployments may adhere to the use cases defined in Figure 2 or Figure 3. One or two MCPs may be enabled at the data center segment. The objective is to optimize the resources usage within the data center infrastructure.
The presence of an MCP is transparent to the client side, nevertheless the origin client's IP address may be hidden to the ultimate server. Enforcing per-host policies at the server's side may be problematic if all connections are bound to an MCP's IP address. To mitigate this problem, MCPs may insert the TCP Option for Host Identification [RFC7974].
The location of MCPs is deployment-specific. Network Providers may choose to adopt centralized or distributed designs. Nevertheless, in order to take advantage of MPTCP, the location of an MCP should not jeopardize packet forwarding performance overall.
Two deployment scenarios can be considered for involving an MCP in the communication path. These scenarios are described below.
This scenario assumes that the IP reachability information of an MCP is explicitly configured on a device, e.g., by means of a specific DHCP option [I-D.boucadair-mptcp-dhc]. A device can be a CPE or a host.
MPTCP connections are established explicitly using the address(es) of the MCP (Figure 6). In order to forward packets to their ultimate destination, the MCP is provided during the connection establishment with the destination IP address (and optionally destination port numbers). Typically, this is achieved thanks to the use of the MP_CONVERT Information Element (IE) defined in [I-D.boucadair-mptcp-plain-mode]. Figure 6 illustrates the flow exchange to established a communication with a legacy server (RM).
___________________
/ Host-based Model \
\___________________/
+---+ +-----+ +--+
|H1 | | MCP | |RM|
+---+ +-----+ +--+
h1@h2@ mcp@ rm@
| | | |
| |src:hi@ dst:mcp@| dst:rm@|
| |<=================MPTCP Leg=============>|<---TCP -->|
| | | |
___________________
/ CPE-based Model \
\___________________/
Upstream Downstream
+--+ +-----+ +-----+ +--+
|H1| | MCP | | MCP | |RM|
+--+ +-----+ +-----+ +--+
h1@ uMCP@1 uMCP@2 dMCP@ rm@
| | | | |
|src:h1@ |src:uMCP@1 dst:dmcp@| |
|<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->|
| dst:rm@| | | dst:rm@|
| | | | |
| | |src:uMCP@2 dst:dmcp@| |
| | |<===Secondary MPTCP subflow==>|<---TCP -->|
| | | ... | dst:rm@|
| | | | |
Legend:
RM: A remote machine.
Figure 6: Sample Connection Establishment (Explicit Mode)
This scenario aims to avoid any adherence of the Network-Assisted MPTCP procedure and the underlying routing and forwarding policies. Furthermore, this scenario allows for more flexibility in terms of mounting MPTCP subflows as it does not require any specific order in the establishment of subflows among available interfaces.
Because the MCP's reachability information is explicitly configured on the device, means to guarantee successful inbound MPTCP connections can be enabled in the device to instruct the MCP to maintain active bindings so that incoming packets can be successfully redirected towards the appropriate device.
Unlike the explicit mode, the implicit mode assumes that the MCP is located on a default forwarding path (primary path). As such, the first subflow must always be placed over that primary path so that the MCP can intercept MPTCP flows. Once intercepted, the MCP advertises its reachability information by means of MPTCP signals (MP_JOIN or ADD_ADDR). Figure 7 illustrates the flow exchange to establish a communication with a legacy server (RM).
Note that a standard MPTCP implementation will try to establish other subflows using rm@. In order to prevent such behavior, H1 is instructed by some means to prevent establishing additional subflows to rm@. For example, the MCP may set the C-bit in MP_CAPABLE option ([I-D.ietf-mptcp-rfc6824bis]) it returns to H1.
___________________
/ Host-based Model \
\___________________/
+----+ +-----+ +--+
| H1 | | MCP | |RM|
+----+ +-----+ +--+
h1@h2@ mcp@ rm@
| | | |
|src:h1@ dst:rm@| dst:rm@|
|<============Initial MPTCP subflow========>|<---TCP -->|
| | ... | |
| |src:h2@ dst:mcp@| dst:rm@|
| |<=========Secondary MPTCP subflow=======>|<---TCP -->|
| | ... | |
___________________
/ CPE-based Model \
\___________________/
Upstream Downstream
+--+ +-----+ +-----+ +--+
|H1| | MCP | | MCP | |RM|
+--+ +-----+ +-----+ +--+
h1@ uMCP@1 uMCP@2 dMCP@ rm@
| | | | |
|src:h1@ |src:uMCP@1 dst:rm@|src:uMCP@1 |
|<-TCP Leg->|<=========MPTCP Leg============>|<-TCP Leg->|
| dst:rm@| | | dst:rm@|
| | | | |
| | |src:uMCP@2 dst:mcp@|src:uMCP@1 |
| | |<===Secondary MPTCP subflow==>|<---TCP -->|
| | | ... | dst:rm@|
| | | | |
Figure 7: Sample Connection Establishment (Implicit Mode)
Subsequent subflows are then sent directly to the MCP (Figure 7). The handling of these subsequent subflows is identical to the one of the explicit mode; only the establishment of the initial subflow differs. Concretely, in reference to Figure 8, once the upstream MCP intercepts an initial subflow, it adds itself to the MPTCP connection by sending ADD_ADDR on the primary subflow. Then, MP_JOIN is sent to the IP address conveyed in ADD_ADDR to create the secondary subflow.
+----+ +-----+ +--+ | H1 | | MCP | |RM| +----+ +-----+ +--+ h1@h2@ mcp@ rm@ | | | | |<==============ADD_ADDR====================| | | | _______________________________________ | | | |/ Secondary subflow \| | | |================SYN+MP_JOIN=============>| | | |<============SYN/ACK(MPJOIN)=============| | | |============ACK(MP_JOIN)================>| | | | ... | |
Figure 8: Secondary Subflow Creation (Host-based Implicit Mode)
If no explicit signal is included in the initial SYN message, the MCP cannot distinguish "native" MPTCP connections from "proxied" ones. An operator that deploys MCP resources would like to control the MPTCP connections it terminate. For example, an operator may want to enforce a policy that consists in assisting only MPTCP connections that are established by an upstream MCP, not those that are established by an MPTCP host located behind a CPE.
Because MPTCP connections are not destined explicitly to an MCP, an on-path MCP instance will need extra means to distinguish "native" MPTCP connections from "proxied" ones. The subsequent risk is that native MPTCP communications will be reverted to TCP connections as shown in Figure 9 if the MCP is instructed to always relay MPTCP connections to TCP ones. In this example, we suppose that C2 and S2 are MPTCP-capable, but C1 and S1 are not.
Upstream Downstream
+--+ +-----+ +-----+ +--+
|C1| | MCP | | MCP | |S1|
+--+ +-----+ +-----+ +--+
| | | |
|src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<-TCP Leg->|<========MPTCP Leg===========>|<-TCP Leg->|
| dst:s1@| | dst:s1@|
| | | |
\_________________SINGLE PATH CLIENT/SERVER_____________/
_________________MULTIPLE PATH CLIENT/SERVER___________
/ \
| |
| | | |
|src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<=MPTCP====|=============================>|<-TCP Leg->|
| dst:s2@| | dst:s2@|
| | | |
+--+ +-----+ +-----+ +--+
|C2| | MCP | | MCP | |S2|
+--+ +-----+ +-----+ +--+
Upstream Downstream
Figure 9: Example of a Broken E2E MPTCP Connection (On-path)
To mitigate this, the upstream MCP may be instructed to insert a MP_PREFER_PROXY option only for the MPTCP connections it establishes [I-D.boucadair-mptcp-plain-mode]. The absence of MP_PREFER_PROXY option instances is an explicit indication that this MPTCP connection is a native one. As such, an on-path MCP will not revert this connection into a TCP connection, but will forward packets without any modification to the next hop.
Figure 10 illustrates the results of such procedure: native MPTCP connections are established between MPTCP-capable client and server, while Network-Assisted MPTCP connections are established with the help of MCPs.
Concretely, if the upstream MCP receives a SYN that includes the MP_PREFER_PROXY option, it MAY decide to forward it towards its final destination without modifying it. When the downstream MCP receives a SYN that does not include an MP_PREFER_PROXY, it forwards it towards its final destination.
Upstream Downstream
+--+ +-----+ +-----+ +--+
|C1| | MCP | | MCP | |S1|
+--+ +-----+ +-----+ +--+
| | | |
|src:c1@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<-TCP Leg->|<========MPTCP Leg(PP)=======>|<-TCP Leg->|
| dst:s1@| | dst:s1@|
| | | |
\_________________SINGLE PATH CLIENT/SERVER_____________/
_________________MULTIPLE PATH CLIENT/SERVER___________
/ \
| |
| | | |
|src:c2@ |src:uMCP@1 dst:s1@|src:uMCP@1 |
|<==========|============MPTCP========================>|
| dst:s2@| | dst:s2@|
| | | |
+--+ +-----+ +-----+ +--+
|C2| | MCP | | MCP | |S2|
+--+ +-----+ +-----+ +--+
Upstream Downstream
Legend:
PP: MP_PREFER_PROXY
Figure 10: Example of a Successful E2E MPTCP Connection (On-path)
The Network Provider that manages the various network attachments (including the MCPs) may enforce authentication and authorization policies using appropriate mechanisms. For example, a non-exhaustive list of methods to achieve authorization is provided hereafter:
A first safeguard against the misuse of MCP resources by illegitimate users (e.g., users with access networks that are not managed by the same service provider that operates the MCP) is to reject MPTCP connections received on the Internet-facing interfaces. Only MPTCP connections received on the customer-facing interfaces of an MCP will be accepted.
Because only the CPE is entitled to establish MPTCP connections with an MCP, ACLs may be installed on the CPE to avoid that internal terminals issue MPTCP connections towards one of the MCPs.
The MCP MUST be provided with instructions about the behavior to adopt with regards to the processing of source addresses. The following sub-sections elaborate on various schemes.
Transparent Network-Assisted MPTCP deployment is a deployment where the visible source address of a packet forwarded by an MCP to a remote machine located in the Internet is the IP address of the endhost, not an address that is provisioned to the MCP. In order to intercept incoming traffic, specific IPv4/IPv6 routes are injected so that traffic is redirected towards the MCP.
No dedicated IP address pool is required to the MCP for the Network-Assisted MPTCP service.
The MCP can be tweaked to behave in the IPv4 address preservation mode. This is the IPv4 address assigned to the endhost (typically, within a mobile deployment context as discussed in Section 4.1) or a WAN address of the CPE for the wired case (Section 4.2).
Some IPv6 deployments may require the preservation of the source IPv6 prefix (Figure 11).
This model requires the MCP to support ALGs to accommodate applications with IPv6 address referrals.
+--+ +-----+ +---+ +--+ |H1| | MCP | |MCP| |RM| +--+ +--+--+ +---+ +--+ IP@s IP@1, IP@2 IP@mcf IP@d | || | | |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@1 | |---------->||------------------------------------>|---------->| | Dst:IP@d|| | dst:IP@d| | || | | |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| |---ACK---->||----------------ACK----------------->|---ACK---->| | || | | Legend: mcf: MCP Customer-facing Interface
Figure 11: Example of Source IPv6 Prefix Preservation at Network-located MCP (Initial subflow)
Some IPv6 deployments may require the preservation of the source IPv6 address (Figure 12).
This model avoids the need for the MCP to support ALGs to accommodate applications with IPv6 address referrals.
+--+ +-----+ +---+ +--+ |H1| | MCP | |MCP| |RM| +--+ +--++-+ +---+ +--+ IP@s IP@1, IP@2 IP@mcf IP@d | || | | |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@s | |---------->||------------------------------------>|---------->| | Dst:IP@d|| | dst:IP@d| | || | | |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| |---ACK---->||----------------ACK----------------->|---ACK---->| | || | | | || | |
Figure 12: Example of Outgoing SYN with Source Address Preservation
Unlike the transport mode, this section focuses on deployments where a dedicated IP address pool is provisioned to the MCP for the Network-Assisted MPTCP service.
Because of global IPv4 address depletion, optimization of the IPv4 address usage is mandatory. This obviously includes the IPv4 addresses that are assigned by the MCP at its Internet-facing interfaces (Figure 13 and Figure 14). A pool of global IPv4 addresses is provisioned to the MCP along with possible instructions about the address sharing ratio to apply (see Appendix B of [RFC6269]). Adequate forwarding policies are enforced so that traffic destined to an address of such pool is intercepted by the appropriate MCP.
+--+ +---+ +--+ |H1| |MCP| |RM| +--+ +---+ +--+ || | | ||src:IP@s MP_CONVERT(D=0,IP@d) dst:IP@mcf|src:IP@mif | ||-----------------------SYN--------------------->|---SYN---->| || | dst:IP@d| || | | ||<--------------------SYN/ACK--------------------|<-SYN/ACK--| ||-----------------------ACK--------------------->|---ACK---->| || | | Legend: mcf: MCP Customer-facing Interface mif: MCP Internet-facing Interface
Figure 13: Example of Outgoing SYN without Source Address Preservation (Single-ended MCP)
+--+ +-----+ +---+ +--+ |H1| | MCP | |MCP| |RM| +--+ +--++-+ +---+ +--+ | || | | |src:IP@s ||src:IP@1 MP_CONVERT(D=0,IP@d) |src:IP@mif | |---SYN---->||----------------SYN----------------->|---SYN---->| | dst:IP@d|| dst:IP@mcf| dst:IP@d| | || | | |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| |---ACK---->||----------------ACK----------------->|---ACK---->| | || | |
Figure 14: Example of Outgoing SYN without Source Address Preservation (Dual-ended MCPs)
For networks that do not face global IPv4 address depletion yet, the MCP can be configured so that source IPv4 addresses of the CPE are replaced with other (public) IPv4 addresses. A pool of global IPv4 addresses is then provisioned to the MCP for this purpose. Rewriting source IPv4 addresses may be used as a means to redirect incoming traffic towards the appropriate MCP.
Rewriting the source IPv6 prefix ([RFC6296]) may be needed to redirect incoming traffic towards the appropriate MCP. A pool of IPv6 prefixes is then provisioned to the MCP for this purpose.
Subflows of a given MPTCP connection can be associated to the same address family or may be established with different address families. Also, the Network-Assisted MPTCP using MP_CONVERT IE, regardless of the addressing scheme enforced by each CPE network attachment. In particular, the plain transport mode indifferently accommodates the following combinations.
| LAN Leg | MPTCP Legs | TCP Leg towards RM |
|---|---|---|
| IPv4 | IPv4 | IPv4 |
| IPv4 | IPv6 | IPv4 |
| IPv4 | IPv6 & IPv4 | IPv4 |
| IPv6 | IPv6 | IPv6 |
| IPv6 | IPv4 | IPv6 |
| IPv6 | IPv6 & IPv4 | IPv6 |
In order to promote the use of MPTCP end-to-end, the MCP MUST NOT strip MP_CPABALE from the SYN segments it forwards to their final destination (i.e., server). The communication leg between an MCP and the server may be placed using MPTCP if that server is MPTCP-capable, or falls back to TCP otherwise.
There may be cases where remote servers will not respond to SYN segments with the MP_CAPABLE option, and therefore it is desirable to provide a mechanism to disable relaying MP_CAPABLE to some or all remote hosts.
Also, an MCP SHOULD maintain a cache to record the servers that are known to cause excessive delays. Any subsequent connection to a server that is present in this cache MUST be placed using TCP. Cache entries MUST be flushed out after the expiry of a configurable timer; this timer is set by default to 24h.
This default behavior would lead to the establishment of end-to-end MPTCP connections if the client and servers are both MPTCP-capable with or without the withdrawal of MCPs from the communication. Whether an MCP must be maintained in the processing of an MPTCP connection that involve MPTCP-capable clients and server is a configurable parameter. The default mode MUST be to maintain the MCP because its presence may solve several complications that may arise in some deployments, such:
Figure 15 shows an example of a communication with MCP withdrawal. In this example, the MCP tracks the initial subflow. Upon receipt of MP_CAPABLE in the SYN/ACK from the server, this connection is not tracked any more by the proxy. Subsequent subflows are handled directly by the endhost and the server.
For cases where some access networks are subject to a volume quota, it is desirable to support a signal to indicate to a remote peer how it must place data into available subflows.
___________________ / Host-based Model \ \___________________/ +----+ +-----+ +--+ | H1 | | MCP | |RM| +----+ +-----+ +--+ h1@h2@ mcp@ rm@ | | | | | |src:h1 dst:rm@|src:h1 dst:rm@| | |=====SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>| | |<=====SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===| | |=====ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>| | | __________________________________________________ | | |/ Secondary subflow \| | |=====================SYN+MP_JOIN====================>| | |<===================SYN/ACK(MPJOIN)==================| | |=====================ACK(MP_JOIN)===================>| | | ... |
Figure 15: Sample Connection Establishment with MCP Withdrawal (Implicit Mode)
If the MCP is instructed to be involved in the communication even if the server is MPTCP-capable, the flow exchange depicted in Figure 16 will be observed.
___________________ / Host-based Model \ \___________________/ +----+ +-----+ +--+ | H1 | | MCP | |RM| +----+ +-----+ +--+ h1@h2@ mcp@ rm@ | | | | |src:h1 dst:rm@|src:h1 dst:rm@| |=======SYN+MP_CAPABLE======>|====SYN+MP_CAPABLE=======>| |<=======SYN/ACK+MP_CAPABLE==|<====SYN/ACK+MP_CAPABLE===| |=======ACK+MP_CAPABLE======>|====ACK+MP_CAPABLE=======>| |<==============ADD_ADDR=====| | | | ________________________ | | | |/ Secondary subflow \| | | |src:h2 dst=mcp@| | | |========SYN+MP_JOIN======>| .... | | |<======SYN/ACK(MPJOIN)====| | | |======ACK(MP_JOIN)=======>| | | | ... | |
Figure 16: Sample Connection Establishment with MCP Withdrawal (Implicit Mode)
The logic of traffic distribution over multiple paths is deployment-specific. This document does not require nor preclude any particular traffic distribution scheme. Nevertheless, MCPs MUST be configurable with a parameter to indicate which traffic distribution scheme to enable. Indeed, policies can be enforced by an MCP instance operated by the Network Provider to manage both upstream and downstream traffic. These policies may be subscriber-specific, connection-specific, system-wise, or else.
The Multipath Client and MCPs may be provided with a set of classification policies to help electing flows for the MPTCP service. These policies may be provisioned either statically and dynamically (or a combination thereof).
Also, multiple MCPs may serve a given end-user, as a function of the nature of the service or the traffic to be forwarded over MPTCP connections. For example, an MCP may be used by a service provider to proceed with CPE-targeted maintenance operations, whereas another MCP may be configured to service multi-path communications initiated by a set of end-users.
Methods to avoid TCP fragmentation, such as rewriting the TCP Maximum Segment Size (MSS) option, must be supported by MCPs.
The MCP MAY be configured to preserve the same DSCP marking or enforce DSCP re-marking policies. DSCP preservation MUST be enabled by default.
The MCP supports TCP by design. Additional transport protocols SHOULD be supported. A configuration parameter MUST be supported by the MCP to indicate which transport protocols can be relayed into an MPTCP connection.
If the MCP 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]. A configuration parameter should be supported to enable/disable the logging function.
This document does not request any action from IANA.
MPTCP-related security threats are discussed in [RFC6181] and [RFC6824]. Additional considerations are discussed in the following sub-sections.
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.
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's resources by establishing a large number of simultaneous subflows for each MPTCP connection, the MCP administrator SHOULD limit the number of allowed subflows per CPE for a given connection. Means to protect against SYN flooding attacks MUST also be enabled ([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.
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.
The MCP may perform packet reassembly. Some security-related issues are discussed in [RFC4963][RFC1858][RFC3128].
The following individuals contributed to this document:
Denis Behaghel OneAccess Email: Denis.Behaghel@oneaccess-net.com Stefano Secci Universite Pierre et Marie Curie Paris France Email: stefano.secci@lip6.fr Suresh Vinapamula Juniper 1137 Innovation Way Sunnyvale, CA 94089 USA Email: Sureshk@juniper.net SungHoon Seo Korea Telecom Seoul Korea Email: sh.seo@kt.com Wouter Cloetens SoftAtHome Vaartdijk 3 701 3018 Wijgmaal Belgium Email: wouter.cloetens@softathome.com Ullrich Meyer Vodafone Germany Email: ullrich.meyer@vodafone.com Luis M. Contreras Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Bart Peirens Proximus Email: bart.peirens@proximus.com
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 held during the IETF#95 meeting.
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.
| [I-D.boucadair-mptcp-plain-mode] | 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, "An MPTCP Option for Network-Assisted MPTCP", Internet-Draft draft-boucadair-mptcp-plain-mode-09, October 2016. |
| [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. |