One document matched: draft-boucadair-mptcp-plain-mode-07.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-07"
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>Orange</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>Orange</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>UPMC</organization>
<address>
<postal>
<street>Universite Pierre et Marie Curie</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>Nokia/Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<country>Belgium</country>
</postal>
<email>wim.henderickx@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Robert Skog" initials="R." surname="Skog">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>robert.skog@ericsson.com</email>
</address>
</author>
<author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
<organization>Tessares</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>Belgium</country>
</postal>
<phone></phone>
<email>olivier.bonaventure@tessares.net</email>
</address>
</author>
<author fullname="Suresh Vinapamula " initials="S." surname="Vinapamula">
<organization>Juniper</organization>
<address>
<postal>
<street>1137 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>Sureshk@juniper.net</email>
<uri></uri>
</address>
</author>
<author fullname="SungHoon Seo" initials="S." surname="Seo">
<organization>Korea Telecom</organization>
<address>
<postal>
<street></street>
<city>Seoul</city>
<region></region>
<code></code>
<country>Korea</country>
</postal>
<phone></phone>
<email>sh.seo@kt.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 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.</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. This deployment scenario
is called a network-assisted MPTCP model, and relies upon MPTCP proxies
located on both the CPE and network sides (<xref target="fig"></xref>).
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.</t>
<t><figure align="center" anchor="fig"
title=""Network-Assisted" MPTCP Design">
<artwork><![CDATA[+------------+ _--------_ +----------------+
| | (e.g., LTE ) | |
| CPE +=======+ +===+ Backbone |
| (MPTCP | (_ _) | Network |
| Proxy) | (_______) |+--------------+|
| | IP Network #1 || Concentrator ||------> Internet
| | || (MPTCP proxy)||
| | |+--------------+|
| | IP Network #2 | |
| | _--------_ | |
| | ( e.g., DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +----------------+
|
---- LAN ----
|
end-nodes
]]></artwork>
</figure></t>
<t>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. <xref target="legs"></xref> depicts the various TCP
connection legs in a network-assisted MPTCP deployment model.</t>
<t><figure align="center" anchor="legs" title="Connection Legs">
<artwork align="center"><![CDATA[+--+ +-----+ +------------+ +--+
|H1| | CPE | |Concentrator| |RM|
+--+ +--+--+ +------+-----+ +--+
| | | |
|<===TCP===>|<============MPTCP Leg==============>|<===TCP===>|
| | | |]]></artwork>
</figure></t>
<t>Most of the current operational deployments that take advantage of
multi-interfaced CPEs rely upon the use of an encapsulation scheme (such
as GRE <xref target="I-D.zhang-gre-tunnel-bonding"></xref>) between the
CPE and the concentrator. 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.</t>
<t>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 CPE are managed by the
same administrative entity. The IP reachability information of an MPTCP
concentrator can be explicitly configured on a CPE, e.g., by means of a
specific DHCP option <xref target="I-D.boucadair-mptcp-dhc"></xref>.
This document assumes such explicit configuration. Additional
assumptions are listed in <xref target="assumptions"></xref>.</t>
<t>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 <xref target="RFC1928"></xref>, 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) .</t>
<t>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 <xref target="RFC2473"></xref>, GRE <xref
target="RFC1701"></xref>). This plain transport mode also avoids the
need for out-of-band signalling.</t>
<t>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.</t>
<t>The plain transport mode is characterized as follows:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>No encapsulation required (no tunnels, whatsoever).</t>
<t>No out-of-band signaling for each MPTCP subflow required.</t>
<t>Carries any protocol (incl. UDP) for the benefit of massive MPTCP
adoption (<xref target="udp"></xref>). </t>
<t>Accommodates various deployment contexts (<xref
target="dep"></xref>).<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terminology defined in <xref
target="RFC6824"></xref>.</t>
<t>This document makes use of the following terms:<list style="hanging">
<t hangText="Customer-facing interface: ">is an interface of the
MPTCP concentrator that is visible to a CPE or a host directly
connected to the operator's network, and which is used for
communication purposes between a CPE/host and the MPTCP
concentrator.</t>
<t hangText="Internet-facing interface: ">is an interface of the
MPTCP concentrator that is visible to a remote host on the
Internet.</t>
<t hangText="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 is embedded in a CPE and a
concentrator.</t>
<t hangText="MPTCP leg: ">refers to a network segment where MPTCP is
used to establish TCP connections (see <xref target="legs"></xref>).
</t>
<t hangText="MPTCP concentrator (or concentrator):">refers to a
functional element that is responsible for aggregating traffic
pertaining to a group of CPEs. This element is typically located
upstream in the network, e.g., beyond a Broadband Remote Access
Server (BRAS) or a PDN Gateway (PGW) in wired and wireless access
network environments, respectively. One or multiple concentrators
can be deployed in the network to help MPTCP-enabled CPEs 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 converts the legacy server's TCP connections into MPTCP
connections towards its customer-facing interfaces.</t>
</list></t>
</section>
<section anchor="assumptions" title="Assumptions & Scope">
<t>The following assumptions are made: <list style="symbols">
<t>The logic for mounting network attachments by a CPE (or a host
directly connected to the operator's network) is deployment- and
implementation-specific and is 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,
system-wide, or else.</t>
<t>The concentrator may be notified about monitoring results (e.g.,
provided by passive or active probes) that detail the status of the
various network legs available to service a customer, a group of
customers, a whole region, etc. No assumption is made in this
document about how these monitoring operations are executed.</t>
<t>An MPTCP-enabled, multi-interfaced CPE or 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 CPE/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
designs. Nevertheless, in order to take advantage of MPTCP, the
location of the concentrator should not jeopardize packet forwarding
performance overall.</t>
<t>The logic of traffic distribution over multiple paths is
deployment-specific. This document does not require nor preclude any
particular traffic distribution schemes.</t>
<t>No assumption is made whether one single or multiple IP
addresses/prefixes are assigned to host connected to a CPE.</t>
</list></t>
<t>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.</t>
<t>Likewise, methods to avoid TCP fragmentation, such as rewriting the
TCP Maximum Segment Size (MSS) option, are out of scope for this
document.</t>
<t>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.</t>
<t>TCP/MPTCP session tracking by the MPTCP proxy is
implementation-specific. Readers may refer to Section 2 of <xref
target="RFC7857"></xref>.</t>
<t>This specifications focuses on TCP and UDP. Future documents may
specify the exact behavior for transporting other protocols over MPTCP
connections. </t>
<t>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.</t>
</section>
<section anchor="behavior" title="Plain Transport Mode Behavior">
<t>As shown in <xref target="legs"></xref>, 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, <xref
target="plain"></xref> 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
<xref target="udp"></xref>.</t>
<section anchor="plain" title="Plain Mode MPTCP Option">
<t>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 <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|Flags| Protocol |
+---------------+---------------+-------+-+-----+---------------+
| 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 Section 3 of <xref
target="RFC6824"></xref>.</t>
<t>Subtype: to be defined by IANA (<xref target="IANA"></xref>).
Implementations may use "Oxe" subtype encoding for early
deployment purposes in managed networks.</t>
<t>D-bit (direction bit): this flag indicates whether the enclosed
IP address (and 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>"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>Protocol: conveys the protocol number as assigned by IANA <xref
target="proto_numbers"></xref>. For example, this field is set to
17 for UDP traffic, or 6 for TCP. The processing of UDP flows is
further discussed in <xref target="udp"></xref>.</t>
<t>Address: includes a source or destination IP address. The
address family is determined by the "Length" field. Concretely, a
PM option containing an IPv4 address has a Length field of 8 bytes
(or 10 if a port number is included). A PM option containing an
IPv6 address has a Length of 20 bytes (or 22 if a port number is
included). </t>
<t>Port: If the D-bit is set (resp. unset), a source (resp.
destination) port number may be associated with the IP address.
This field is valid for protocols that use a 16 bit port number
(e.g., UDP, TCP, SCTP).</t>
</list></t>
<t></t>
</section>
<section anchor="syn" title="Carrying the Plain Mode Option">
<t>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. <list style="empty">
<t>Note: Given the length of the PM option, especially when IPv6
addresses are used, and the set of TCP options that are likely to
be included in a SYN message, it will not always be possible to
place the PM option inside the dedicated TCP option space. Given
that this option is designed to be used in a controlled
environment, this specification recommends to always place the PM
options inside the payload of a SYN segment. Including data in a
SYN payload is allowed as per Section 3.4 of <xref
target="RFC0793"></xref>. </t>
</list></t>
<t>If the original SYN message contains data in its payload (e.g.,
<xref target="RFC7413"></xref>), 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 . </t>
<t>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 (<xref
target="pmf"></xref>).</t>
<t><figure align="center" anchor="pmf"
title="Carrying the Plain Mode Option (Focus on the MPTCP Leg)">
<artwork align="center"><![CDATA[ +-----+ +------------+
| CPE | |Concentrator|
+-+-+-+ +------+-----+
| | |
| | (Initial connection setup) |
|------------------(PM)-------------->|
|<------------------------------------|
| | |
| | (Additional subflow setup) |
| |/---------------------------------\|
| |\---------------------------------/|
| | |
]]></artwork>
</figure></t>
<t>By default, source IP address preservation is assumed for IPv6
while global address sharing is assumed for IPv4. This means that 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 <xref
target="dep"></xref>).</t>
<t>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.</t>
</section>
<section anchor="bib" title="Binding Tables">
<t></t>
<section title="On the Need to Maintain a State">
<t>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.</t>
<t>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 four tuple
(source and destination addresses and ports) as such an identifier.
</t>
<t>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 four-tuple
of each subflow that belong to an MPTCP connection can also be part
of the MPTCP transport coordinates. </t>
<t>Binding entries can be created as a result of a packet or be
configured directly on the CPE or the concentrator.</t>
</section>
<section title="Binding & Transport Session Entries">
<t>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.</t>
<t>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.</t>
<t>A session entry maintained by the CPE may be structured as
follows:</t>
<t><list style="symbols">
<t>Internal transport session identifier: This information
typically include the source IP transport address (IPl, Pl) and
the destination IP transport address (IPd, Pd) of the
connection. </t>
<t>MPTCP transport coordinates: These coordinates include
information about the subflows that compose this MPTCP
connection. When a packet matches an existing binding entry, the
CPE may decide whether existing subflows can be used to forward
the packet, or whether a new subflow is to be created. <vspace
blankLines="1" />The following information is maintained for
each MPTCP subflow: <list style="symbols">
<t>(IPwi, Pwi): The source IP address and port for this
subflow.</t>
<t>(IPci, Pci): IPci is one of the concentrator's IP
addresses, while Pci is a port number selected to establish
this subflow. This information is used as the destination IP
address and port of a packet matching this entry.</t>
</list></t>
<t>Transport protocol: This information is typically retrieved
from the outgoing packet that will be placed in MPTCP
connections. The transport protocol specifies the protocol that
is used in the LAN side.</t>
<t>Lifetime: This information indicates the remaining validity
lifetime for the session entry. When the lifetime expires, this
session entry is deleted from the table. If all sessions bound
to a given binding entry expired, that binding entry must be
deleted. Recommendations for setting this parameter are defined
in <xref target="RFC7857"></xref><xref
target="RFC5382"></xref><xref target="RFC4787"></xref>.</t>
</list></t>
<t>For example:<list style="symbols">
<t>An outgoing packet {src=(IPl, Pl); dst=(IPd,Pd)} will be
transformed by the CPE to {src=(IPwi,Pwi); dst=(IPci,Pci)}.</t>
<t>An incoming packet {src=(IPci,Pci); dst=(IPwi,Pwi) will be
transformed by the CPE to {src=(IPd, Pd); dst=(IPl,Pl)};</t>
</list></t>
<t>The structure of a session entry maintained by the concentrator
may be as follows:<list style="symbols">
<t>External transport session identifier: This information
typically include the external IP transport address (IPe, Pe)
and the destination IP transport address (IPd, Pd) of the
connection. The external IP transport address is set to the
(IPl, Pl) if and only if the concentrator is configured to
preserve the source IP address and port. In such case, this
information is retrieved from the PM option included in a SYN
packet. Otherwise, the external IP address and port are selected
by the concentrator from a local pool.</t>
<t>MPTCP transport coordinates: These coordinates include
information about the subflows that compose this MPTCP
connection. When a packet matches an existing binding entry, the
concentrator may decide whether existing subflows can be used to
forward the packet, or whether a new subflow is to be created.
<vspace blankLines="1" />The following information is maintained
for each MPTCP subflow: <list style="symbols">
<t>(IPwi, Pwi): The source IP address and port for this
subflow.</t>
<t>(IPci, Pci): The destination IP address and port for this
subflow. It can be set by the CPE or selected by the
concentrator.</t>
</list></t>
<t>Transport protocol: This information is retrieved from the PM
option included in a SYN packet. The transport protocol
specifies the protocol that must be used when sending the packet
through the Internet-facing interface.</t>
<t>Lifetime: This information indicates the remaining validity
lifetime for the session entry. When the lifetime expires, this
session entry is deleted from the table. If all sessions bound
to a given binding entry expired, that binding entry must be
deleted. Recommendations for setting this parameter are defined
in <xref target="RFC7857"></xref><xref
target="RFC5382"></xref><xref target="RFC4787"></xref>.</t>
</list></t>
<t>For example:<list style="symbols">
<t>An outgoing packet {src=(IPwi,Pwi); dst=(IPci,Pci)} will be
transformed by the concentrator to {src=(IPe,Pe);
dst=(IPd,Pd)}.</t>
<t>An incoming packet {src=(IPd,Pd); dst=(IPe,Pe) will be
transformed by the concentrator to {src=(IPd, Pd);
dst=(IPci,Pci)}.</t>
</list></t>
<t></t>
</section>
<section title="Expiration of a Binding Entry">
<t>A configurable parameter MAY be supported by the CPE and the
concentrator to terminate MPTCP connections with the FASTCLOSE
procedure (Section 3.5 of <xref target="RFC6824"></xref>) 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. </t>
<t>The configurable parameter is set by default to 'Disable'.</t>
</section>
</section>
<section anchor="spec" title="Theory of Operation: Focus on TCP">
<t></t>
<section title="Processing an Outgoing SYN">
<t>Plain Mode option usage for an outgoing TCP SYN (i.e., from the
CPE to the concentrator) is as follows:</t>
<t><list style="format (%d)">
<t>Outgoing TCP SYNs that can be forwarded by a CPE along MPTCP
subflows are transformed by the CPE into TCP packets carried
over an MPTCP connection. The decision-making process to decide
whether a given flow should be MPTCP-serviced or not is local to
the CPE, and reflects the service-inferred policies as defined
by the bonding service provider. As such, the decision-making
process is policy-driven, implementation- and
deployment-specific.</t>
<t>As a result, SYNs packets are sent over an MPTCP connection
according to the plain transport mode (i.e., without any
encapsulation header), and the related instructions carried in
the PM option. <vspace blankLines="1" />The source IP address
and port number are those assigned to one of the CPE WAN
interfaces. 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 traffic filtering
policies (<xref target="RFC2827"></xref>) are enforced at the
network boundaries 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 and/or source IP
address are copied into Plain Mode options. The option is
inserted as per the guidelines documented in <xref
target="syn"></xref>.<vspace blankLines="1" />A session entry
(including the protocol) MUST be maintained by the CPE for that
outgoing packet (<xref target="bib"></xref>). A timeout is
associated with this entry as per the recommendations in <xref
target="RFC5382"></xref>.</t>
<t>Upon receipt of a SYN packet on its MPTCP leg, the
concentrator extracts the IP address(es) included in the Plain
Mode option and uses it as the destination (and possibly the
source) IP address of the corresponding SYN packet that it will
forward towards its final destination. The 'Protocol' field of
the PM option indicates the transport protocol that must be used
when sending the packet through the Internet-facing interface.
<vspace blankLines="1" />The source IP address and port belong
to a pool that is configured to the concentrators if address or
prefix rewriting is enabled (see <xref target="dep"></xref>). A
session entry MUST be instantiated by the concentrator to record
the state (see <xref target="bib"></xref>).<vspace
blankLines="1" />The concentrator may be configured to behave as
either a 1:1 IPv4 address translator or a N:1 IPv4 address
translator where a given global IPv4 address is therefore shared
by multiple CPEs. Network Providers should be aware of the
complications that may arise if a given IP address/prefix is
shared by multiple customers (see <xref
target="RFC6269"></xref><xref target="RFC6967"></xref>). Whether
these complications apply or not to a network-assisted MPTCP
environment is deployment-specific. <vspace blankLines="1" />The
concentrator should preserve the same external IP address that
was assigned to a given CPE for all its outgoing connections
when forwarding traffic from an MPTCP connection to the
Internet.</t>
</list></t>
<t></t>
</section>
<section anchor="in" title="Processing an Incoming SYN">
<t>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). </t>
<t>Plain transport mode operation for an incoming TCP SYN (i.e.,
when traffic is forwarded from the concentrator towards the CPE) is
as follows:</t>
<t><list style="format (%d)">
<t>If the incoming TCP SYN matches a binding entry (<xref
target="bib"></xref>), the concentrator rewrites some of the
packet's fields according to the information maintained in this
entry. In addition, the concentrator records the source IP
address and port in the PM option. Also, the 'Protocol' field of
the PM option is set according to the guidelines in <xref
target="syn"></xref>.<vspace blankLines="1" />The source IP
address is replaced with one of the IP addresses listed in the
binding information base maintained by the concentrator. <vspace
blankLines="1" />The destination IP address is replaced with one
of the CPE's IP addresses.<vspace blankLines="1" />A session
entry is instantiated to record the transport-related
information to rewrite the packet.</t>
<t>Upon receipt of the TCP SYN by the CPE, it extracts the IP
address included in the Plain Mode option and uses it as the
source IP address of the packet that the CPE will forward
through its LAN interface until the packet reaches its final
destination. <vspace blankLines="1" />The destination IP
address, port, and protocol are retrieved from a binding entry
maintained by the CPE.</t>
</list></t>
<t></t>
</section>
<section title="Processing Subsequent Outgoing/Incoming Non-SYNs">
<t>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 <xref
target="bib"></xref>). 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. </t>
<t>Non-SYN messages exchanged in the context of an existing subflow
and all messages for non-initial subflows do not include the PM
option.</t>
</section>
<section anchor="rst" title="Handling TCP RST Messages">
<t>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 <xref
target="RFC6824"></xref>) 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.</t>
<t>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 <xref
target="RFC7857"></xref>.</t>
</section>
</section>
</section>
<section anchor="udp" title="Processing UDP Traffic">
<t>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 (<xref target="bib"></xref>) 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 the MPTCP connection. The MPTCP connection is released
when no traffic is exchanged for this flow (<xref
target="uter"></xref>). </t>
<section anchor="beh" title="Behavior">
<t>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. </t>
<t>The management of MPTCP connections that are triggered by UDP
datagrams follows the guidelines documented in <xref
target="RFC6824"></xref>. </t>
<t>The following sub-sections exclusively focus on the external
behavior to achieve UDP to TCP conversion ( <xref
target="ut"></xref>), and vice versa (<xref target="tu"></xref>).</t>
<section anchor="ut" title="UDP to TCP Conversion">
<t>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 (<xref target="bib"></xref>).</t>
<t>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:<list style="numbers">
<t>Extract the payload and its length from the UDP datagram.</t>
<t>Send the length (as a 16 bits field in network byte order)
followed by the payload of the UDP datagram over the bound MPTCP
connection. </t>
</list></t>
<t>UDP packets that are received by the concentrator, but do not
match an existing binding, MUST be silently dropped. </t>
<t>UDP packets that are received by the CPE, but do not match an
existing binding, MUST be proceed as follows:<list style="numbers">
<t>Instantiate a new binding entry for this outgoing packet. The
information about the transport protocol (UDP, in this case)
MUST also be included in this binding entry.</t>
<t>Initiate the MPTCP connection that will be used to carry the
UDP datagrams of this flow towards the chosen concentrator. For
this, the CPE MUST create a SYN segment containing the following
information : <list style="symbols">
<t>The MP_CAPABLE option and possibly other TCP options.</t>
<t>The payload contains the following information (in this
order):<list style="symbols">
<t>A PM option indicating the original source address
and port if source address preservation is enabled.</t>
<t>A PM option indicating the original destination
address and port.</t>
<t>The EOL TCP option.</t>
<t>The Length of the UDP payload in network byte
order.</t>
<t>The payload of the UDP datagram.</t>
</list></t>
</list></t>
</list></t>
<t>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
<xref target="bib"></xref> MUST be applied.</t>
<t>Packets that match an entry MUST NOT be forwarded to the remote
endpoint if the corresponding MPTCP connection has not been
established. These packets, that are queued locally, MUST be
transmitted to the remote peer once at least one subflow is
established.</t>
<t>Whether one or multiple UDP payloads are included in the same TCP
segment is implementation- and deployment-specific.</t>
</section>
<section anchor="tu" title="TCP to UDP Conversion">
<t>Upon receipt of a SYN segment containing the PM option specifying
the UDP protocol, the concentrator MUST proceed as follows: <list
style="symbols">
<t>Create a binding entry to map this MPTCP connection to a UDP
flow (<xref target="bib"></xref>).</t>
<t>Extract the destination, and possibly source, transport
addresses from the PM option and complete the session entry with
this information.</t>
<t>Extract the UDP payload.</t>
<t>Generate a UDP datagram with the corresponding IP addresses
and ports and the UDP payload. </t>
</list></t>
<t>Upon receipt of a SYN segment containing the PM option specifying
the UDP protocol, the CPE MUST proceed as follows: <list
style="symbols">
<t>If no binding is found, the packet MUST be silently dropped.
</t>
<t>If a binding is found:<list style="symbols">
<t>Extract the source (optionally, destination) transport
addresses from the PM option.</t>
<t>Create a session entry to map this MPTCP connection to a
UDP flow (<xref target="bib"></xref>).</t>
<t>Extract the UDP payload.</t>
<t>Generate a UDP datagram with the corresponding IP
addresses and ports and the UDP payload.</t>
</list></t>
</list>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. </t>
<t>The concentrator (or the CPE) MUST follow the same procedure as
mentioned in <xref target="bib"></xref> for address and port
rewriting purposes.</t>
</section>
<section anchor="uter" title="Terminating UDP-Triggered Subflows">
<t>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
<xref target="RFC4787"></xref>). Consequently, the procedure in
<xref target="rst"></xref> 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.</t>
</section>
</section>
<section title=" Examples">
<t>A flow example is shown in <xref target="ex1"></xref> 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 a UDP datagram.
<figure anchor="ex1"
title="Distributing UDP packets over multiple paths (1)">
<artwork align="center"><![CDATA[ +--------+ +------------+
| 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----------------->|
| |
....
]]></artwork>
</figure></t>
<t><xref target="ex2"></xref> 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.</t>
<t><figure anchor="ex2"
title="Distributing UDP packets over multiple paths (2)">
<artwork align="center"><![CDATA[ +--------+ +------------+
| 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_@
| |
....
]]></artwork>
</figure></t>
</section>
<section title="Fragmentation & Reassembly Considerations">
<t><list style="empty">
<t>EDITOR NOTE: This section is still under discussion among the
authors.</t>
</list>The subsequent UDP/TCP header swapping introduced in <xref
target="beh"></xref> 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.</t>
<t>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.</t>
<t>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 fragmented packets.</t>
<t>If this configurable parameter is set to 'Enabled', the CPE and the
concentrator MUST perform fragmentation and reassembly for packets
that exceed the link MTU. Concretely, 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 fragmentation is as follows:
<list style="symbols">
<t>Swap the header (UDP to TCP),</t>
<t>Fragment the transformed packet, and then forward the
fragments.</t>
</list></t>
<t>The remote MPTCP endpoint (CPE or concentrator) then adopts the
following behavior:<list style="symbols">
<t>Reassemble the packet,</t>
<t>Present the packet to the MPTCP proxy as per <xref
target="tu"></xref>.</t>
<t>Extract the corresponding UDP packet, and then forward it.</t>
</list></t>
<t>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).</t>
</section>
</section>
<section anchor="dep" title="Deployment Scenarios">
<t>The Plain Transport Mode accommodates various deployment contexts
such as:</t>
<t><list style="hanging">
<t hangText="IPv4 address sharing:">Because of global IPv4 address
depletion, optimization of the IPv4 address usage is mandatory, and
this includes IPv4 addresses that are assigned by the concentrator
at its Internet-facing interfaces (<xref target="addnp"></xref>). A
pool of global IPv4 addresses is provisioned to the concentrator
along with possible instructions about the address sharing ratio to
apply (see Appendix B of <xref target="RFC6269"></xref>). Adequate
forwarding policies are enforced so that traffic destined to an
address of such pool is intercepted by the appropriate
concentrator.<figure anchor="addnp"
title="Example of Outgoing SYN without Source Address Preservation">
<artwork><![CDATA[+--+ +-----+ +------------+ +--+
|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
RM: Remote Machine
]]></artwork>
</figure></t>
<t hangText="IPv4 address 1:1 translation:">For networks that do not
face global IPv4 address depletion yet, the concentrator can be
configured so that source IPv4 addresses of the CPE are replaced
with other (public) IPv4 address. A pool of global IPv4 addresses is
then provisioned to the concentrator for this purpose. Rewriting
source IPv4 addresses may be used as a means to redirect incoming
traffic towards the appropriate concentrator.</t>
<t hangText="Source IPv6 address preservation:">Some IPv6
deployments may require the preservation of the source IPv6 address
(<xref target="addp"></xref>). This model avoids the need for the
concentrator to support ALGs to accommodate applications with IPv6
address referrals. In order to intercept incoming traffic, specific
IPv6 routes are injected so that traffic is redirected towards the
concentrator.<figure anchor="addp"
title="Example of Outgoing SYN with Source Address Preservation">
<artwork><![CDATA[+--+ +-----+ +------------+ +--+
|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---->|
| | | |
]]></artwork>
</figure></t>
<t hangText="IPv6 prefix sharing (NPTv6):">Rewriting the source IPv6
prefix (<xref target="RFC6296"></xref>) may be needed to redirect
incoming traffic towards the appropriate concentrator. A pool of
IPv6 prefixes is then provisioned to the concentrator for this
purpose.</t>
</list></t>
<t>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.</t>
<texttable align="center" style="headers">
<ttcol align="center">LAN Leg</ttcol>
<ttcol align="center">CPE-Concentrator Legs</ttcol>
<ttcol align="center">Concentrator-RM Leg</ttcol>
<c>IPv4</c>
<c>IPv4</c>
<c>IPv4</c>
<c>IPv4</c>
<c>IPv6</c>
<c>IPv4</c>
<c>IPv4</c>
<c>IPv6 & IPv4</c>
<c>IPv4</c>
<c>IPv6</c>
<c>IPv6</c>
<c>IPv6</c>
<c>IPv6</c>
<c>IPv4</c>
<c>IPv6</c>
<c>IPv6</c>
<c>IPv6 & IPv4</c>
<c>IPv6</c>
</texttable>
<t>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.</t>
</section>
<section title="Additional Considerations">
<t></t>
<section title="Authorization">
<t>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: <list style="symbols">
<t>The network provider may enforce a policy based on the
International Mobile Subscriber Identity (IMSI) to verify that a
user is allowed to benefit from the aggregation service. If that
authorization fails, the PDP context /bearer won't be mounted.
This method does not require any involvement from the
concentrator.</t>
<t>The network provider may enforce a policy based on Access
Control Lists (ACLs), e.g., at the Broadband Network Gateway (BNG)
to control the CPEs that are authorized to communicate with a
concentrator. These ACLs may be installed as a result of RADIUS
exchanges, for instance. This method does not require any
involvement from the concentrator.</t>
<t>The concentrator may implement an Ident interface <xref
target="RFC1413"></xref> to retrieve an identifier that will be
used to assess whether that client is authorized to make use of
the aggregation service. Ident exchanges will take place only when
receiving the first subflow from a given source IP address.</t>
<t>The concentrator may embed a RADIUS client that will solicit an
AAA server to check whether connections received from a given
source IP address are authorized or not.</t>
</list></t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Logging">
<t>If the concentrator is used in global IPv4 address sharing
environments, the logging recommendations discussed in Section 4 of
<xref target="RFC6888"></xref> need to be considered. Security-related
issues encountered in address sharing environments are documented in
Section 13 of <xref target="RFC6269"></xref>.</t>
</section>
<section title="EPC Billing & Accounting">
<t>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.).</t>
<t>It is out of the scope of this document to make any recommendation
in that area.</t>
</section>
</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<vspace blankLines="1" />NOTE:
Implementations may use "Oxe" subtype encoding for early deployment
purposes in managed networks.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>MPTCP-related security threats are discussed in <xref
target="RFC6181"></xref> and <xref target="RFC6824"></xref>. Additional
considerations are discussed in the following sub-sections.</t>
<section title="Privacy">
<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>
</section>
<section title="Denial-of-Service (DoS) ">
<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 network boundaries <xref
target="RFC2827"></xref>.</t>
<t>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 (<xref
target="RFC4987"></xref>).</t>
<t>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.</t>
</section>
<section title="Illegitimate Concentrator">
<t>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.</t>
</section>
<section title="High Rate Reassembly">
<t>The CPE and the concentrator may perform packet reassembly. Some
security-related issues are discussed in <xref
target="RFC4963"></xref><xref target="RFC1858"></xref><xref
target="RFC3128"></xref>.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to Chi Dung Phung, Mingui Zhang, and Christoph Paasch for
the comments.</t>
<t>Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
Aires).</t>
<t>Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
Xavier Grall for their valuable comments.</t>
<t>Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
Flahaut, Adrien Desportes, and Gregory Detal for the discussion.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6824'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5382'?>
<?rfc include='reference.RFC.4787'?>
<?rfc include='reference.RFC.7857'?>
<?rfc include='reference.RFC.0793'?>
<reference anchor="proto_numbers">
<front>
<title>Protocol Numbers</title>
<author fullname="IANA">
<organization>http://www.iana.org/assignments/protocol-numbers</organization>
</author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.I-D.zhang-gre-tunnel-bonding'?>
<?rfc include='reference.RFC.7413'?>
<?rfc include='reference.RFC.1928'?>
<?rfc include='reference.RFC.2473'?>
<?rfc include='reference.RFC.1701'?>
<?rfc include='reference.RFC.2827'?>
<?rfc include='reference.RFC.6967'?>
<?rfc include='reference.I-D.boucadair-mptcp-dhc'?>
<?rfc include='reference.RFC.4987'?>
<?rfc include='reference.RFC.4963'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.1858'?>
<?rfc include='reference.RFC.3128'?>
<?rfc include='reference.RFC.6181'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.1413'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:19 |