One document matched: draft-boucadair-mptcp-plain-mode-05.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-05"
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>
<author fullname="Stefano Secci" initials="S." surname="Secci">
<organization>Universite Pierre et Marie Curie (UPMC)</organization>
<address>
<postal>
<street></street>
<city>Paris</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>stefano.secci@lip6.fr</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country>Belgium</country>
</postal>
<email>wim.henderickx@alcatel-lucent.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 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.</t>
<t>This document specifies an MPTCP option that is used to avoid 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.<!--
Pour le cas UDP: option UDP: draft-touch-tsvwg-udp-options
Pourquoi pas une option IP: TCP/UDP?
discussion: SOCKS:
--></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 models are considered to steer traffic
towards an MPTCP Concentrator. This document focuses on the explicit
model 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 <xref
target="RFC2473"></xref>, GRE <xref target="RFC1701"></xref>, SOCKS
<xref target="RFC1928"></xref>, 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 solution in this document does not require the modification of
the binding information base (BIB) structure maintained by both the CPE
and the Concentrator. Likewise, this 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 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>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<list style="symbols">
<t>Customer-facing interface: is an interface of the MPTCP
Concentrator that is visible to a CPE and which is used for
communication purposes between a CPE and the MPTCP Concentrator.</t>
<t>MPTCP Proxy: is a software module that is responsible for
transforming a TCP connection into an MPTCP connection, and vice
versa. Typically, an MPTCP proxy can be embedded in a CPE and/or a
Concentrator.</t>
<t>MPTCP leg: Refers to a network segment on which MPTCP is used to
establish TCP connections.</t>
<t>MPTCP Concentrator (or concentrator): refers to a functional
element that is responsible for aggregating the traffic of a group
of CPEs. This element is located upstream in the network. One or
multiple concentrators can be deployed in the network side to assist
MPTCP-enabled CPEs to establish MPTCP connections via available
network attachments. <vspace blankLines="1" />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. <vspace
blankLines="1" />On the downlink path, the concentrator turns the
legacy server's TCP connection into MPTCP connections towards its
customer-facing interfaces.</t>
</list></t>
</section>
<section anchor="assumptions" title="Assumptions">
<t>The following assumptions are made: <?rfc subcompact="yes" ?><list
style="symbols">
<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 title="Introducing the MPTCP Plain Transport Mode">
<t></t>
<section title="An Alternative to Encapsulation">
<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 approach that relies upon plain
transport mode between the CPE and the Concentrator.</t>
<t>The use of a plain transport mode does not require the upgrade of
any intermediate function (security, TCP optimizer, etc.) that may be
located on-path. Thus, the introduction of MPTCP concentrators in
operational networks to operate plain mode does not add any extra
complexity as far as the operation of possible intermediate functions
is concerned.</t>
</section>
<section anchor="plain" title="Plain Mode MPTCP Option">
<t>The format of the Plain Mode MPTCP option is shown in <xref
target="pm"></xref>.</t>
<t><figure align="center" anchor="pm" title="Plain Mode MPTCP Option">
<artwork><![CDATA[ 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="spec" title="Theory of Operation">
<t>Plain mode operation is as follows:</t>
<t><list style="format (%d)">
<t>The CPE is provisioned with the reachability information of one
or several Concentrators (e.g., <xref
target="I-D.boucadair-mptcp-dhc"></xref>).</t>
<t>Outgoing TCP packets that can be forwarded by a CPE along MPTCP
subflows are transformed into TCP packets carried over a MPTCP
connection. 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 address 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 prevent any spoofing attack.<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>. As a reminder, <xref
target="I-D.touch-tcpm-tcp-syn-ext-opt"></xref> specifies a
proposal for TCP SYN extended option space. <vspace
blankLines="1" />A binding entry must be maintained by the CPE for
that outgoing packet. This binding entry is instantiated by the
NAT and/or the firewall functions embedded in the CPE.</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.<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>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></t>
</section>
<section title="Flow Example">
<t>A typical flow exchange is shown in <xref target="ex"></xref>.</t>
<t>This example assumes no NAT is located between the CPE and the
concentrator.</t>
<t>Because the remote server is not MPTCP-aware, the Concentrator is
responsible for preserving the same IP address (conc_@, in the
example) for the same CPE even if distinct IP addresses (cpe_@1 and
cpe_@2, in the example) 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_@
....
Legend:
* "--Plain Mode MPTCP Option()->" indicates the packet is sent
in a plain mode, i.e., without any encapsulation hander,
and that "Plain Mode MPTCP Option" is carried in the packet.
]]></artwork>
</figure></t>
</section>
</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. UDP datagrams are therefore transformed into TCP-formatted
packets.</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>. Both the CPE and the Concentrator MAY be
configured to disable some features (e.g., reordering). Enabling these
features is deployment and implementation-specific.</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>
<t>A flow example is shown in <xref target="ex1"></xref>.</t>
<t><figure anchor="ex1"
title="Distributing UDP packets over multiple paths">
<artwork align="center"><![CDATA[ +--------+ +------------+
| CPE | |Concentrator|
+--------+ +------------+
| /------------------------------------------\ |
|| Dedicated MPTCP SubFlows for UDP ||
| \------------------------------------------/ |
| |
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|---------------------TCP--------------------->|---UDP-->
dst=d_@| Plain Mode MPTCP Option(U,d_@) |dst=d_@
....
src=s_@|src=cpe_@2 dst=conc_@2|src=conc_@
---UDP-->|---------------------TCP--------------------->|---UDP-->
dst=d_@| Plain Mode MPTCP Option(U,d_@) |dst=d_@
| |
....
src=s_@|src=cpe_@1 dst=conc_@1|src=conc_@
---UDP-->|---------------------TCP--------------------->|---UDP-->
dst=d1_@| Plain Mode MPTCP Option(U,d_@) |dst=d1_@
| |
src=s_@|src=cpe_@1 dst=conc_@2|src=conc_@
---UDP-->|---------------------TCP--------------------->|---UDP-->
dst=d1_@| Plain Mode MPTCP Option(U,d_@) |dst=d1_@
| |
]]></artwork>
</figure></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 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-tcpm-tcp-edo'?>
<?rfc include='reference.RFC.4908'?>
<?rfc include='reference.RFC.1928'?>
<?rfc include='reference.RFC.2473'?>
<?rfc include='reference.RFC.1701'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.I-D.touch-tcpm-tcp-syn-ext-opt'?>
<?rfc include='reference.RFC.6967'?>
<?rfc include='reference.I-D.boucadair-mptcp-dhc'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:34 |