One document matched: draft-boucadair-mptcp-plain-mode-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-boucadair-mptcp-plain-mode-02"
ipr="trust200902">
<front>
<title abbrev="Plain MPTCP Transport Mode">An MPTCP Option for
Network-Assisted MPTCP Deployments: Plain Transport Mode</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Denis Behaghel" initials="D." surname="Behaghel">
<organization>OneAccess</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>Denis.Behaghel@oneaccess-net.com</email>
</address>
</author>
<date />
<abstract>
<t>One of the promising deployment scenarios for Multipath TCP (MPTCP)
is to enable a Customer Premises Equipment (CPE) that is connected to
multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
network attachments. Because of the lack of MPTCP support at the server
side, some service providers now consider a “network-assisted
mode” 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.</t>
<t>This document specifies an MPTCP option that is used to get rid of an
encapsulation scheme between the CPE and the MPTCP Concentrator. Also,
this document specifies how UDP traffic can be distributed among
available paths without requiring any encapsulation scheme.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>One of the promising deployment scenarios for Multipath TCP (MPTCP,
<xref target="RFC6824"></xref>) 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, see for example <xref
target="I-D.deng-mptcp-proxy"></xref> or <xref target="RFC4908"></xref>.
This deployment scenario relies on MPTCP proxies located on both the CPE
and network sides (<xref target="fig"></xref>). The latter plays the
role of traffic concentrator. A concentrator terminates the MPTCP
sessions established from a CPE, before redirecting traffic into a
legacy TCP session.</t>
<t><figure align="center" anchor="fig"
title=""Network-Assisted" MPTCP Design">
<artwork><![CDATA[ IP Network #1
+------------+ _--------_ +------------+
| | (e.g., LTE ) | |
| CPE +=======+ +===+ |
| (MPTCP | (_ _) |Concentrator|
| Proxy) | (_______) | (MPTCP |
| | | Proxy) |------> Internet
| | | |
| | IP Network #2 | |
| | _--------_ | |
| | ( e.g., DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +------------+
|
----CPE network----
|
end-nodes
]]></artwork>
</figure></t>
<t>Both implicit and explicit modes are considered to steer traffic
towards an MPTCP Concentrator. This document focuses on the explicit
mode that consists in configuring explicitly the reachability
information of the MPTCP concentrator on a host (e.g., <xref
target="I-D.boucadair-mptcp-dhc"></xref>).</t>
<t>This specification assumes an MPTCP Concentrator is reachable through
one or multiple IP addresses. Also, it assumes the various network
attachments provided to an MPTCP-enabled CPE are managed by the same
administrative entity. Additional assumptions are listed in <xref
target="assumptions"></xref>.</t>
<t>This document explains how a plain transport mode, where packets are
exchanged between the CPE and the concentrator without requiring the
activation of any encapsulation scheme (e.g., IP-in-IP, GRE, etc.), can
be enabled.</t>
<t>Also, this document investigates an alternate track where UDP flows
can be distributed among available paths without requiring any
encapsulation scheme.</t>
<t>The proposed solution does not require changing the structure of the
binding information base maintained by both the CPE and the
Concentrator. Likewise, the proposed approach does not infer any
modification of the Network Address Translator (NAT) functions that may
reside in both the CPE and the device that embeds the concentrator.</t>
<t>The proposed solution also works properly when NATs are present in
the network between the CPE and the Concentrator, unlike solutions that
rely upon GRE tunneling. Likewise, the solution accommodates deployments
that involve CGN (Carrier Grade NAT) upstream the Concentrator.</t>
<t>The applicability of the proposed solution to applications such as
RTP is out of scope. These applications may rely on specific solutions
such as <xref target="I-D.ietf-avtcore-mprtp"></xref>.</t>
</section>
<section anchor="assumptions" title="Assumptions">
<t>The following assumptions are made: <?rfc subcompact="yes" ?><list
style="symbols">
<t>One or multiple concentrators are deployed on the network side to
assist MPTCP-enabled hosts to establish MPTCP connections via
available network attachments.</t>
<t>On the uplink path, the concentrator terminates the MPTCP
connections received from its customer-facing interfaces and
transforms these connections into legacy TCP connections towards
upstream servers. On the downlink path, the concentrator turns the
legacy server's TCP connection into MPTCP connections towards its
customer-facing interfaces.</t>
<t>Various network attachments are provided to an MPTCP-enabled
host/CPE; all these network attachments are managed by the same
administrative entity.</t>
<t>The CPE implements an MPTCP proxy. This MPTCP proxy acts as a
traffic concentrator from the end-nodes (i.e., hosts attached to the
CPE) standpoint.</t>
<t>The logic for mounting network attachments by a host is
deployment- and implementation-specific and is out of scope of this
document.</t>
<t>The Network Provider that manages the various network attachments
(including the concentrators) can enforce authentication and
authorization policies using appropriate mechanisms that are out of
scope of this document.</t>
<t>Policies can be enforced by a concentrator instance operated by
the Network Provider to manage both upstream and downstream traffic.
These policies may be subscriber-specific, connection-specific or
system-wide.</t>
<t>The concentrator may be notified about the results of monitoring
(including probing) the various network legs to service a customer,
a group of customers, a given region, etc. No assumption is made by
this document about how these monitoring (including probing)
operations are executed.</t>
<t>An MPTCP-enabled, multi-interfaced host that is directly
connected to one or multiple access networks is allocated
addresses/prefixes via legacy mechanisms (e.g., DHCP) supported by
the various available network attachments. The host may be assigned
the same or distinct IP address/prefix via the various available
network attachments.</t>
<t>The location of the concentrator(s) is deployment-specific.
Network Providers may choose to adopt centralized or distributed
(even if they may not be present on the different network accesses)
designs, etc. Nevertheless, in order to take advantage of MPTCP, the
location of the concentrator should not jeopardize packet forwarding
performance for traffic sent from or directed to connected
hosts.</t>
</list></t>
<t><?rfc subcompact="no" ?></t>
</section>
<section anchor="spec" title="Encapsulation Mode vs. Plain Mode">
<t>The design option for aggregating various network accesses often
relies upon the use of an encapsulation scheme (such as GRE) between the
CPE and the Concentrator. The use of encapsulation is motivated by the
need to steer traffic through the concentrator and also to allow the
distribution of UDP flows 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.</t>
<t>This document specifies another, presumably more efficient, approach
that relies upon plain transport modes between the CPE and the
concentrator. The proposed approach is characterized as follows:<list
style="symbols">
<t>The CPE is provisioned with the reachability information of its
Concentrator (e.g., <xref
target="I-D.boucadair-mptcp-dhc"></xref>).</t>
<t>Outgoing TCP packets that can be forwarded along MPTCP subflows
are transformed into MPTCP packets. The decision-making process to
decide whether a flow should be MPTCP-tagged or not is local to the
Concentrator and the CPE. It depends on the policies provisioned by
the network provider. As such, the decision-making process is
policy-driven, implementation- and deployment-specific.</t>
<t>MPTCP packets are sent using a plain transport mode (i.e.,
without any encapsulation header). <vspace blankLines="1" />The
source IP address and source port number are those assigned locally
by the CPE. Because multiple IP addresses may be available to the
CPE, the one used to rewrite the source IP address for an outgoing
packet forwarded through a given network attachment (typically, a
WAN interface) must be associated with that network attachment. It
is assumed that ingress filtering (<xref target="RFC2827"></xref>)
is implemented at the boundaries of the networks to provide
anti-spoofing.<vspace blankLines="1" />The destination IP address is
replaced by the CPE with one of the IP addresses of the
Concentrator. <vspace blankLines="1" />The destination port number
may be maintained as initially set by the host or altered by the
CPE. <vspace blankLines="1" />The original destination IP address is
copied into a dedicated MPTCP option called "Plain Mode MPTCP"
Option (see <xref target="plain"></xref>). Because of the limited
TCP option space, it is RECOMMENDED to implement the solution
specified in <xref target="I-D.ietf-tcpm-tcp-edo"></xref>.<vspace
blankLines="1" />A binding entry must be maintained by the CPE for
that outgoing packet. <vspace blankLines="1" />The concentrator may
be configured to behave as either a 1:1 address translator or a N:1
translator where the same address is shared among multiple CPEs.
Network Providers should be aware of the complications that may
arise if a given IP address/prefix is shared among multiple hosts
(see <xref target="RFC6967"></xref>). Whether these complications
apply or not is deployment-specific. <vspace blankLines="1" />The
Concentrator should preserve the same IP address that was assigned
to a given CPE for all its outgoing connections when transforming an
MPTCP connection into a TCP connection.</t>
<t>Upon receipt of the packet on the MPTCP leg, the Concentrator
extracts the IP address included in the Plain Mode MPTCP Option that
it uses as the destination IP address of the packet generated in the
TCP leg towards its ultimate destination. <vspace
blankLines="1" />The source IP address and port are those of the
Concentrators. A binding entry is instantiated by the Concentrator
to record the state.</t>
<t>For incoming TCP packets that need to be forwarded to a CPE, the
Concentrator records the source IP address in a Plain Mode MPTCP
Option. <vspace blankLines="1" />The source IP address is replaced
with one of the IP addresses listed in the aforementioned binding
information base maintained by the Concentrator (if such a state
entry exists) or with one of the Concentrator's IP addresses.
<vspace blankLines="1" />The destination IP address is replaced with
the CPE's IP address (if the corresponding state entry is found in
the Concentrator's binding table) or with one of the CPE's IP
addresses (that are known by the concentrator using some means that
are out of the scope of the document).</t>
</list></t>
<t>A typical flow exchange is shown in <xref target="ex"></xref>. This
example assumes no NAT is located between the CPE and the concentrator.
Because the remote host is not MPTCP-aware, the Concentrator is
responsible for preserving the same IP address for the same CPE even if
distinct IP addresses are used by the CPE to establish subflows with the
Concentrator.</t>
<t><figure anchor="ex"
title="Flow Example: No NAT between the CPE and the Concentrator">
<artwork align="center"><![CDATA[ +-------+
|DNS |
+--------+ |System | +------------+
| CPE | +-------+ |Concentrator|
+--------+ | +------------+
| | |
DNS | | |
-------->| DNS Query | |
Query |------------------------->| |
| DNS Reply | |
|<-------------------------| |
| |
| |
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
-------->|--------Plain Mode MPTCP Option(d_@)--------->|-------->
dst=d_@| |dst=d_@
....
| |
src=d_@|dst=cpe_@1 src=conc_@1|src=d_@
<--------|<-------Plain Mode MPTCP Option(d_@)----------|<-------
dst=s_@| |dst=conc_@
....
src=s_@|src=cpe_@2 dst=conc_@1|src=conc_@
-------->|--------Plain Mode MPTCP Option(d_@)--------->|-------->
dst=d_@| |dst=d_@
....
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="plain" title="Plain Mode MPTCP Option">
<t>The format of the Plain Mode MPTCP Option is shown in <xref
target="plain"></xref>.</t>
<t><figure align="center" anchor="pm" title="Plain Mode MPTCP Option">
<artwork><![CDATA[ 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |SubType|D|U| Flag Bits |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) |
+-------------------------------+
]]></artwork>
</figure>The description of the fields is as follows:</t>
<t><list style="symbols">
<t>Kind and Length: are the same as in <xref
target="RFC6824"></xref>.</t>
<t>Subtype: to be defined by IANA (<xref target="IANA"></xref>).</t>
<t>D-bit (direction bit): This flag indicates whether the enclosed
IP address (and a port number) reflects the source or destination IP
address (and port). 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.</t>
<t>U-bit (UDP-bit): The use of this flag is detailed in <xref
target="udp"></xref>.</t>
<t>The "Flag" 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.</t>
<t>Address: Includes a source or destination IP address. The address
family is determined by the "Length" field.</t>
<t>Port: May be used to carry a port number.</t>
</list></t>
<t></t>
</section>
<section anchor="udp" title="UDP Traffic">
<t>From an application standpoint, there may be a value to distribute
UDP datagrams among available network attachments for the sake of
network resource optimisation, for example.</t>
<t>Unlike existing proposals that rely upon encapsulation schemes such
as IP-in-IP or GRE, this document suggests the use of MPTCP features to
control how UDP datagrams are distributed among existing network
attachments. The data included in UDP datagrams are transported in MPTCP
packets as shown in <xref target="ex1"></xref>.</t>
<t><figure anchor="ex1" title="UDP over TCP: Flow Example">
<artwork align="center"><![CDATA[ +--------+ +------------+
| CPE | |Concentrator|
+--------+ +------------+
| /-------------------------------------------\ |
|| Dedicated MPTCP SubFlows for UDP ||
| \-------------------------------------------/ |
| |
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|--------Plain Mode MPTCP Option(U,d_@)------->|---UDP-->
dst=d_@| |dst=d_@
....
src=s_@|src=cpe_@2 dst=conc_@2|src=conc_@
---UDP-->|--------Plain Mode MPTCP Option(U,d_@)------->|---UDP-->
dst=d_@| |dst=d_@
| |
....
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|--------Plain Mode MPTCP Option(U,d1_@)------>|---UDP-->
dst=d1_@| |dst=d1_@
| |
src=s_@|src=cpe_@1 dst=conc_@2|src=conc_@
---UDP-->|--------Plain Mode MPTCP Option(U,d1_@)------>|---UDP-->
dst=d1_@| |dst=d1_@
]]></artwork>
</figure></t>
<t>The CPE and the Concentrator MUST establish a set of subflows that
are maintained alive. These subflows are used to transport UDP datagrams
that are distributed among existent subflows. TCP session tracking is
not enabled for the set of subflows that are dedicated to transport UDP
traffic. The establishment of these subflows is not conditioned by the
receipt of UDP packets; instead, these subflows are initiated upon CPE
reboot or when network conditions change (e.g;, whenever a new
Concentrator is discovered or a new IP address is assigned to the
Concentrator).</t>
<t>When the CPE (or the Concentrator) transforms a UDP packet into a TCP
one, it MUST insert the Plain Mode MPTCP Option with the U-bit set. When
setting the source IP address, the destination IP address, and the IP
address enclosed in the Plain Mode MPTCP Option, the same considerations
specified in <xref target="spec"></xref> MUST be followed.</t>
<t>In addition, the CPE (or the Concentrator) MUST replace the UDP
header with a TCP header. Upon receipt of the packet with the U-bit set,
the Concentrator (or the CPE) transforms the packet into a UDP packet
and follows the same considerations specified in <xref
target="spec"></xref>.</t>
<t>Relaying UDP packets is not conditioned by TCP session establishment
because the required subflows that are dedicated to transport UDP
traffic are already in place (either at the CPE or the
Concentrator).</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests an MPTCP subtype code for this option:<list
style="symbols">
<t>Plain Mode MPTCP Option</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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 boundaries of the network. In order to
prevent exhausting the resources of the concentrator by creating an
aggressive number of simultaneous subflows for each MPTCP connection,
the administrator should limit the number of allowed subflows per host
for a given connection.</t>
<t>Attacks outside the domain can be prevented if ingress filtering is
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.</t>
<t>Traffic theft is also a risk if an illegitimate concentrator is
inserted in the path. Indeed, inserting an illegitimate concentrator in
the forwarding path allows to intercept traffic 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 (for
non-transparent modes) should be enabled.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Stefano Secci, Chi Dung Phung, and Mingui Zhang for
the comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6824'?>
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.deng-mptcp-proxy'?>
<?rfc include='reference.I-D.ietf-avtcore-mprtp'?>
<?rfc include='reference.I-D.ietf-tcpm-tcp-edo'?>
<?rfc include='reference.RFC.4908'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.6967'?>
<?rfc include='reference.I-D.boucadair-mptcp-dhc'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:17 |