One document matched: draft-boucadair-mptcp-connectivity-checks-00.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-connectivity-checks-00"
ipr="trust200902">
<front>
<title abbrev="MPTCP Compatibility Assessement">MPTCP Connectivity
Checks</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>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date />
<abstract>
<t>This document specifies an extension to minimize the delay induced by
the presence of MPTCP-unfriendly nodes in some of the paths selected by
a MPTCP endpoint, and which may support the establishment of MPTCP
subflows. Concretely, this procedure allows a MPTCP endpoint to assess
whether the networks the endpoint connects to are compliant with MPTCP
signals or not. The procedure is not enabled for every new MPTCP
connection; it is activated upon bootstrap or when a network attachment
change occurs (e.g., attach to a new network, discover a new external IP
address, etc.).</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 anchor="introduction" title="Introduction">
<t>This document specifies an extension that minimizes the delay induced
by the presence of MPTCP-unfriendly nodes in the some of the paths
selected by a MPTCP endpoint, and which may support the establishment of
MPTCP subflows.</t>
<t>The problem space is further described in <xref
target="problem"></xref>, while a proposed solution is discussed in
<xref target="solution"></xref>.</t>
</section>
<section anchor="problem" title="Problem Space">
<t>Advanced flow-aware service functions (e.g., Performance Enhancement
Proxies (<xref target="RFC3135"></xref>), NATs <xref
target="RFC3022"></xref>, CGNs <xref target="RFC6888"></xref>, DS-Lite
AFTR <xref target="RFC6333"></xref>, NAT64 <xref
target="RFC6146"></xref>, NPTv6 <xref target="RFC6296"></xref>,
firewalls, etc.) are required to achieve various objectives such as IP
address sharing, firewalling, avoid covert channels, detect and protect
against ever increasing DDoS attacks, etc.</t>
<t>Removing those functions is not an option because they are used to
address constraints that are often typical of the current yet protean
Internet situation (global IPv4 address depletion comes to mind, but
also the plethora of services with different QoS/security/robustness
requirements, etc.), and this is even exacerbated by
environment-specific designs (e.g., the nature and the number of service
functions that need to be invoked at the Gi interface of a mobile
infrastructure). Moreover, these sophisticated service functions are
located in the network but also in service platforms, or intermediate
entities (e.g., CDNs). A flow-aware device can be embedded in a CPE
(Customer Premises Equipment) and/or hosted in the network provider's
side.</t>
<t>In the meantime, the presence of these flow-aware functions
complicates the introduction of new protocols or the introduction of
additional features for existing ones. Also, because some of these
flow-aware functions do not expose a deterministic behavior, additional
complications are encountered even if the protocol design includes
built-in features to detect (and possibly accommodate) the presence of
such functions. This document focuses on MPTCP <xref
target="RFC6824"></xref>.</t>
<t>MPTCP supports a mechanism to fallback to TCP when a flow-aware
function interferes with MPTCP signals. <xref target="ex1"></xref> and
<xref target="ex2"></xref> show two typical examples of the fallback
behavior. It is out of scope of this document to list all the possible
fallback scenarios. Refer to <xref target="RFC6824"></xref> for more
details about the exact fallback behavior.</t>
<t><figure align="center" anchor="ex1" title="Fallback Case 1">
<artwork><![CDATA[ Host T1 Host T2
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (initial MPTCP setup) | |
T0 |----------------------------------->| |
|<-----------------------------------| |
| | | |
| Fall Back to TCP | |
T0+t |----------------------------------->| |
|<-----------------------------------| |
| | | |
]]></artwork>
</figure></t>
<t><figure align="center" anchor="ex2" title="Fallback Case 2">
<artwork><![CDATA[ Host T1 Host T2
------------------------ ------------------------
Address A1 Address A2 Address B1 Address B2
---------- ---------- ---------- ----------
| | | |
| (initial MPTCP setup) | |
T0 |----------------------------------->| |
|<-----------------------------------| |
| | | |
| | | |
|<------- Wrong DSS------ | |
| | | |
| Fall Back to TCP | |
T0+t |----------------------------------->| |
|<-----------------------------------| |
| | | |
]]></artwork>
</figure></t>
<t>This behavior, if adopted for every new connection, will have
negative impacts on the quality of experience as perceived by a user.
This is not desirable.</t>
</section>
<section anchor="solution" title="Proposed Solution">
<t>The problem in <xref target="problem"></xref> can be originated by
MPTCP-unfriendly service function(s) located at the initiator side, the
receiver side, or the network in between. In order to avoid increasing
the delay to establish a TCP-based connection involving an MPTCP-enabled
endpoint, this document suggests the use of connectivity checks to
assess whether available paths as perceived by an MPTCP-enabled endpoint
can safely convey MPTCP signals. Doing so, the results of such
connectivty checks allow an MPTCP-enabled endpoint to decide whether
MPTCP needs to be disabled for all or part of its available network
attachments. This also allows the endpoint to identify which paths
cannot be used to establish the first subflow. Network attachments that
aren't MPTCP-friendly are tagged as such.</t>
<t>A dedicated functional element (referred to as MPTCP Connectivity
Check Server (MCCS)) is proposed to assess the MPTCP friendliness of its
network attachments. MCCS is attached to a network that does not involve
any MPTCP-unfriendly service function. If any MPTCP problem is
encountered when establishing a connection with an MCCS, it is an
indication that the issue is located at the remote MPTCP-enabled
endpoint.</t>
<t>This procedure is activated upon bootstrap or when a network
attachment change occurs (e.g., attach to a new network, discover a new
external IP address, etc.); it is not executed for every new MPTCP
connection:<list style="symbols">
<t>An MPTCP-enabled endpoint is configured with one or a list of
MCCS servers. <vspace blankLines="1" />A well-known name can be used
for this purpose. The name is then passed to the name resolution
library (e.g., Section 6.1.1 of <xref target="RFC1123"></xref>) to
retrieve the corresponding IP address(es) (IPv4, IPv6 or both).</t>
<t>The MPTCP-enabled terminal then establishes MPTCP connections
based upon all the IP addresses that have been retrieved (or a
subset thereof). Executing the procedure with more than one MCCS (if
available) is RECOMMENDED. <vspace blankLines="1" />These MPTCP
connections are meant to assess for each available network
attachment, interface, discovered external IP address, etc., that
the path that will be solicited when issuing packets does not break
MPTCP connections. <vspace blankLines="1" />The tests are executed
both from the MPTCP-enabled endpoint and also the MCCS. The
extension defined <xref
target="I-D.boucadair-mptcp-symmetric"></xref> is RECOMMENDED so
that the MCCS can initiate MPTCP connections, add new subflows to an
active MPTCP connection, etc. <vspace blankLines="1" />The tests are
performed to cover all failure cases (e.g., strip MPTCP signals,
alter some options, corrupted DSS, etc.). An example is depicted in
<xref target="ex3"></xref> for illustration purposes.<figure
align="center" anchor="ex3"
title="An example of connectivity checks">
<artwork><![CDATA[ Host T1 MCCS
------------------------ ----------
Address A1 Address An Address 1
---------- --------- ----------
| | |
| (initial MPTCP setup 1) |
|---------------------------------->-|
|<-----------------------------------|
| .... |
| |(initial MPTCP setup n)|
| |---------------------->|
| |<----------------------|
| | |
| .... |
| | MPTCP setup m |
| |<----------------------|
| |---------------------->|
| | |
]]></artwork>
</figure></t>
<t>As an outcome of the previous step, the MPTCP-enabled endpoint
can conclude whether all or some of its available network
attachments can "safely" be used when establishing MPTCP
connections.<vspace blankLines="1" />Interfaces/address/networks
that are MPTCP-unfriendly are tagged accordingly; those are not used
when establishing a new MPTCP connection with a remote peer or to
add a new subflow to an existing MPTCP connection.<vspace
blankLines="1" />In particular, an MPTCP-enabled endpoint will not
use MPTCP when all its network attachments are MPTCP-unfriendly.
This covers in particular the situation where the endpoint initialed
the connection or when the MPTCP device receives an MPTCP connection
(e.g., user-generated content context).</t>
<t>This procedure is executed whenever network conditions change, as
perceived by an MPTCP-enabled endpoint.</t>
</list></t>
<t>In the context of <xref target="I-D.deng-mptcp-proxy"></xref>, this
procedure can be implemented at the CPE side on behalf of the
MPTCP-enabled terminals the CPE is connected to in the user premises. An
MPTCP-enabled terminal localed behind a CPE assumes by default that its
default gateway is its MCCS. Doing so, this design allows to avoid
re-using the same connectivity checks for all the terminals located
behind a CPE.</t>
<t>A deployment option would consist in integrating connectivity check
capabilities in STUN servers <xref target="RFC5389"></xref>; an
extension would be needed for that purpose, though.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>MPTCP-related security considerations are documented in <xref
target="RFC6824"></xref> and <xref
target="I-D.ietf-mptcp-attacks"></xref>.</t>
<t>Security-consideration specific to MCCS will be discussed.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBC</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.ietf-mptcp-attacks"?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.1123'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.3135'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.5389'?>
<?rfc include='reference.I-D.deng-mptcp-proxy'?>
<reference anchor="I-D.boucadair-mptcp-symmetric"
target="https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-01">
<front>
<title>An Extension to MPTCP for Symmetrical Sub-Flow
Management</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>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<date day="04" month="March" year="2015" />
</front>
</reference>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:36:31 |