Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental France Telecom
Expires: March 25, 2016 September 22, 2015
An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport
Mode
draft-boucadair-mptcp-plain-mode-01
Abstract
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.
This document specifies an MPTCP option that is used to get rid of an
encapsulation scheme between the CPE and the MPTCP Concentrator.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2016.
Boucadair & Jacquenet Expires March 25, 2016 [Page 1]
Internet-Draft Plain MPTCP Transport Mode September 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation Mode vs. Plain Mode . . . . . . . . . . . . . . 5
4. Plain Mode MPTCP Option . . . . . . . . . . . . . . . . . . . 7
5. UDP Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
One of the promising deployment scenarios for Multipath TCP (MPTCP,
[RFC6824]) is to enable a Customer Premises Equipment (CPE) that is
connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the
usage of such resources, see for example [I-D.deng-mptcp-proxy] or
[RFC4908]. This deployment scenario relies on MPTCP proxies located
on both the CPE and network sides (Figure 1). 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.
Boucadair & Jacquenet Expires March 25, 2016 [Page 2]
Internet-Draft Plain MPTCP Transport Mode September 2015
IP Network #1
+------------+ _--------_ +------------+
| | (e.g., LTE ) | |
| CPE +=======+ +===+ |
| (MPTCP | (_ _) |Concentrator|
| Proxy) | (_______) | (MPTCP |
| | | Proxy) |------> Internet
| | | |
| | IP Network #2 | |
| | _--------_ | |
| | ( e.g., DSL ) | |
| +=======+ +==+ |
| | (_ _) | |
+-----+------+ (_______) +------------+
|
----CPE network----
|
end-nodes
Figure 1: "Network-Assisted" MPTCP Design
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.,
[I-D.boucadair-mptcp-dhc]).
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
Section 2.
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-IPn, GRE, etc.),
can be enabled. Also, this document investigates an alternate track
where UDP flows can be distributed among available paths without
requiring any encapsulation scheme.
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. It also works properly when NATs are present in the
network between the CPE and the Concentrator, unlike solutions that
rely upon GRE tunneling.
Boucadair & Jacquenet Expires March 25, 2016 [Page 3]
Internet-Draft Plain MPTCP Transport Mode September 2015
The applicability of the proposed solution to applications such as
RTP is out of scope. These applications may rely on specific
solutions such as [I-D.ietf-avtcore-mprtp].
2. Assumptions
The following assumptions are made:
o One or multiple concentrators are deployed on the network side to
assist MPTCP-enabled hosts to establish MPTCP connections via
available network attachments.
o 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.
o Various network attachments are provided to an MPTCP-enabled host/
CPE; all these network attachments are managed by the same
administrative entity.
o 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.
o The logic for mounting network attachments by a host is
deployment- and implementation-specific and is out of scope of
this document.
o 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.
o 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.
o 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.
o 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.
o 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
Boucadair & Jacquenet Expires March 25, 2016 [Page 4]
Internet-Draft Plain MPTCP Transport Mode September 2015
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.
3. Encapsulation Mode vs. Plain Mode
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.
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:
o The CPE is provisioned with the reachability information of its
Concentrator (e.g., [I-D.boucadair-mptcp-dhc]).
o 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.
o MPTCP packets are sent using a plain transport mode (i.e., without
any encapsulation header).
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
([RFC2827]) is implemented at the boundaries of the networks to
provide anti-spoofing.
The destination IP address is replaced by the CPE with one of the
IP addresses of the Concentrator.
The destination port number may be maintained as initially set by
the host or altered by the CPE.
Boucadair & Jacquenet Expires March 25, 2016 [Page 5]
Internet-Draft Plain MPTCP Transport Mode September 2015
The original destination IP address is copied into a dedicated
MPTCP option called "Plain Mode MPTCP" Option (see Section 4).
A binding entry must be maintained by the CPE for that outgoing
packet.
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 [RFC6967]). Whether these
complications apply or not is deployment-specific.
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.
o 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.
The source IP address and port are those of the Concentrators. A
binding entry is instantiated by the Concentrator to record the
state.
o 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.
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.
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).
A typical flow exchange is shown in Figure 2.
Boucadair & Jacquenet Expires March 25, 2016 [Page 6]
Internet-Draft Plain MPTCP Transport Mode September 2015
+-------+
|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_@
Figure 2: Flow Example
4. Plain Mode MPTCP Option
The format of the Plain Mode MPTCP Option is shown in Section 4.
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) |
+-------------------------------+
Figure 3: Plain Mode MPTCP Option
The description of the fields is as follows:
o Kind and Length: are the same as in [RFC6824].
o Subtype: to be defined by IANA (Section 6).
Boucadair & Jacquenet Expires March 25, 2016 [Page 7]
Internet-Draft Plain MPTCP Transport Mode September 2015
o 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.
o U-bit (UDP-bit): The use of this flag is detailed in Section 5.
o 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.
o Address: Includes a source or destination IP address. The address
family is determined by the "Length" field.
o Port: May be used to carry a port number.
5. UDP Traffic
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.
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 Figure 4.
Boucadair & Jacquenet Expires March 25, 2016 [Page 8]
Internet-Draft Plain MPTCP Transport Mode September 2015
+--------+ +------------+
| 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_@
Figure 4: UDP over TCP: Flow Example
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).
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 Section 3 MUST be followed.
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 Section 3.
Boucadair & Jacquenet Expires March 25, 2016 [Page 9]
Internet-Draft Plain MPTCP Transport Mode September 2015
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).
6. IANA Considerations
This document requests an MPTCP subtype code for this option:
o Plain Mode MPTCP Option
7. Security Considerations
The concentrator may have access to privacy-related information
(e.g., IMSI, link identifier, subscriber credentials, etc.). The
concentrator must not leak such sensitive information outside a local
domain.
Means to protect the MPTCP concentrator against Denial-of-Service
(DoS) attacks must be enabled. Such means include the enforcement of
ingress filtering policies at the 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.
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.
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.
8. Acknowledgements
Many thanks to S. Secci for the comments.
9. References
Boucadair & Jacquenet Expires March 25, 2016 [Page 10]
Internet-Draft Plain MPTCP Transport Mode September 2015
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
9.2. Informative References
[I-D.boucadair-mptcp-dhc]
Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options
for Network-Assisted Multipath TCP (MPTCP)", draft-
boucadair-mptcp-dhc-01 (work in progress), July 2015.
[I-D.deng-mptcp-proxy]
Lingli, D., Liu, D., Sun, T., Boucadair, M., and G.
Cauchie, "Use-cases and Requirements for MPTCP Proxy in
ISP Networks", draft-deng-mptcp-proxy-01 (work in
progress), October 2014.
[I-D.ietf-avtcore-mprtp]
Varun, V., Karkkainen, T., Ott, J., Ahsan, S., and L.
Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore-
mprtp-01 (work in progress), July 2015.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,
R., and H. Ohnishi, "Multi-homing for small scale fixed
network Using Mobile IP and NEMO", RFC 4908,
DOI 10.17487/RFC4908, June 2007,
<http://www.rfc-editor.org/info/rfc4908>.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments",
RFC 6967, DOI 10.17487/RFC6967, June 2013,
<http://www.rfc-editor.org/info/rfc6967>.
Boucadair & Jacquenet Expires March 25, 2016 [Page 11]
Internet-Draft Plain MPTCP Transport Mode September 2015
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes
France
Email: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires March 25, 2016 [Page 12]