Internet DRAFT - draft-boucadair-mptcp-probe-subflow
draft-boucadair-mptcp-probe-subflow
Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Updates: 6824 (if approved) France Telecom
Intended status: Experimental July 6, 2015
Expires: January 7, 2016
Probing MPTCP Subflows
draft-boucadair-mptcp-probe-subflow-00
Abstract
This document specifies an extension to Multipath TCP (MPTCP) that is
meant to assess whether a path used to establish a given subflow is
MPTCP-friendly, i.e., intermediate nodes involved in that path do not
alter nor strip MPTCP options, which would prevent the establishment
of MPTCP communications along that path. A new flag bit, called
Probe Flag (P-flag) is defined for this purpose.
This document updates RFC6824.
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 January 7, 2016.
Boucadair & Jacquenet Expires January 7, 2016 [Page 1]
Internet-Draft MPTCP Probing July 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. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Probe Flag (P-flag) . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This document specifies an extension to Multipath TCP (MPTCP,
[RFC6824]) that is meant to assess whether a path used to establish a
given subflow is MPTCP-friendly. That is, intermediate nodes
involved in that path do not alter nor strip MPTCP options, which
would prevent the establishment of MPTCP communications along that
path.
The problem is summarized briefly in Section 2 while the probe flag
is defined in Section 3.
The solution proposed in this document allows to anticipate failures
due to the presence of MPTCP-unfriendly devices in the communication
paths.
Boucadair & Jacquenet Expires January 7, 2016 [Page 2]
Internet-Draft MPTCP Probing July 2015
2. The Problem
MPTCP supports a backup mode that relies on a dedicated flag, called
backup flag carried in the MP_JOIN option: when set, this flag
informs the remote peer that this is a backup subflow. Several
problems may be arise such as. For example:
o A peer decides to use a backup subflow but MPTCP cannot be used
for that subflow because an intermediate function removes DSS
options, for example. This failure will have a negative impact on
the quality of experience.
o Several subflows can be candidate to be used as backup but the
participating nodes do not know in advance whether associated
forwarding paths are MPTCP-friendly, i.e., they can actually
support MPTCP subflows. The participating nodes need some "hints"
to decide which subflows are to be used as regular ones and those
as backup. This lack of information may also affect the perceived
quality of experience.
3. Probe Flag (P-flag)
As a solution to the problem described in Section 2, a meaning is
associated with one of the reserved bits in MP_JOIN. This new flag
bit is called: Probe Flag (P-flag). This flag bit is used to
explicitly inform the remote peer that a probing procedure is
associated with the corresponding subflow.
Figure 1 and Figure 2 show the required update to the MP_JOIN option
format in SYN and SYN/ACK.
Boucadair & Jacquenet Expires January 7, 2016 [Page 3]
Internet-Draft MPTCP Probing July 2015
OLD:
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 = 12 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
NEW:
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 = 12 |Subtype|r|r|P|B| Address ID |
+---------------+---------------+-------+-+-+-+-+---------------+
| Receiver's Token (32 bits) |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
where "rr" are reserved bits for future assignment as
additional flag bits. r bits MUST each be sent as zero and MUST be
ignored on receipt.
Figure 1: Join Connection (MP_JOIN) Option (for Initial SYN)
Boucadair & Jacquenet Expires January 7, 2016 [Page 4]
Internet-Draft MPTCP Probing July 2015
OLD:
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 = 16 |Subtype| |B| Address ID |
+---------------+---------------+-------+-----+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
NEW:
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 = 16 |Subtype|r|r|P|B| Address ID |
+---------------+---------------+-------+-+-+-+-+---------------+
| |
| Sender's Truncated HMAC (64 bits) |
| |
+---------------------------------------------------------------+
| Sender's Random Number (32 bits) |
+---------------------------------------------------------------+
where "rr" are reserved bits for future assignment as
additional flag bits. r bits MUST each be sent as zero and MUST be
ignored on receipt.
Figure 2: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
When set, the P-Flag bit indicates to the remote peer that a probing
is associated with this subflow. The probing logic is to be further
defined in future versions of this specification. Only probing data
MUST be sent over a subflow that is tagged to be under probing.
Probing MUST NOT interfere with data exchange over regular subflows,
if any.
An MPTCP endpoint that receives an MP_JOIN with a P-flag set, MUST
echo the P-flag in the SYN/ACK if it supports the probing mechanism.
If not, the P-flag MUST be ignored (i.e., the P-flag of the MP_JOIN
included in the SYN/ACK must be set to 0).
P-flag can be set independently of the backup flag.
Boucadair & Jacquenet Expires January 7, 2016 [Page 5]
Internet-Draft MPTCP Probing July 2015
The handling of the B flag when P-flag is also set, is not altered by
this specification.
4. Security Considerations
MPTCP-related security considerations are documented in [RFC6824] and
[I-D.ietf-mptcp-attacks].
5. IANA Considerations
This document does not require any action from IANA.
6. Acknowledgements
TBC
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
7.2. Informative References
[I-D.ietf-mptcp-attacks]
Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
Raiciu, "Analysis of MPTCP residual threats and possible
fixes", draft-ietf-mptcp-attacks-04 (work in progress),
March 2015.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Boucadair & Jacquenet Expires January 7, 2016 [Page 6]
Internet-Draft MPTCP Probing July 2015
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires January 7, 2016 [Page 7]
