MPTCP Working Group O. Bonaventure Internet-Draft B. Hesmans Updates: 6824 (if approved) UCLouvain Intended status: Experimental M. Boucadair Expires: December 18, 2015 Orange June 16, 2015 Experimental Multipath TCP option draft-bonaventure-mptcp-exp-option-00 Abstract This document proposes a generic format for an experimental Multipath TCP option. This experimental option is expected to replace the option type that was reserved for private use in [RFC6824]. 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 December 18, 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. Bonaventure, et al. Expires December 18, 2015 [Page 1] Internet-Draft Exp. MPTCP Option June 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. The Experimental Multipath TCP option . . . . . . . . . . . . 3 3. Security considerations . . . . . . . . . . . . . . . . . . . 6 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Multipath TCP is an extension to TCP [RFC0793] that was specified in [RFC6824]. Like other TCP extensions, Multipath TCP relies on TCP options to exchange information. To mitigate some forms of middlebox interference, Multipath TCP uses only one TCP option identified by Kind=30 [RFC6824]. TCP Option Kind=30 has a variable length and includes a subtype field that can support up to 16 different Multipath TCP options. As of this writing, 8 different Multipath TCP options are defined [RFC6824] : o subtype=0x0 : MP_CAPABLE o subtype=0x1 : MP_JOIN o subtype=0x2 : DSS o subtype=0x3 : ADD_ADDR o subtype=0x4 : REMOVE_ADDR o subtype=0x5 : MP_PRIO o subtype=0x6 : MP_FAIL o subtype=0x7 : MP_FASTCLOSE In addition, subtype=0x8 is already reserved for a new version of the ADD_ADDR option [I-D.ietf-mptcp-rfc6824bis] and subtype=0xf is reserved for use in private testbeds [RFC6824]. There are thus less than six different Multipath TCP options that are available to extend the protocol. The Multipath TCP options defined above cover the basic functionalities for Multipath TCP but previous experience with TCP Bonaventure, et al. Expires December 18, 2015 [Page 2] Internet-Draft Exp. MPTCP Option June 2015 indicates that it can be expected that Multipath TCP implementors will propose new extensions that require a new option subtype. Some authors have already proposed such extensions [I-D.boucadair-mptcp-symmetric] [I-D.paasch-mptcp-syncookies] [I-D.xu-mptcp-prmp]. Given the small number of available Multipath TCP options, it will be difficult to officially reserve them for all proposed utilisations even if experiments with these new Multipath TCP options would probably be useful. This document proposes a shared use of the Multipath TCP option subtype=0xf following a similar approach as described in [RFC6994] for TCP. This approach is efficient as it encourages conducting new experiments while not consuming the limited option codepoint space. 2. The Experimental Multipath TCP option The extensibility of TCP depends largely on the definition of new TCP options. As of this writing, 30 different TCP options have been assigned by the IANA among the 256 possible values. Two of these option types (253 and 254) have been reserved as experimental options in [RFC4727]. However, this document did not specify how these experimental options should be used. [RFC6994] clarified the situation by proposing two encodings for these experimental options to support a shared use of the same option kind by different experimental options. Basically, [RFC6994] proposes to use a 16 bits experiment identifier in the first two bytes of the option as shown in the figure below. 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ExID | +--------+--------+--------+--------+ | option contents... +--------+--------+---... [RFC6994] extends this format to support 32 bits identifiers where the second 16 bits word is used to encode a magic number. 0 1 2 3 01234567 89012345 67890123 45678901 +--------+--------+--------+--------+ | Kind | Length | ExID | +--------+--------+--------+--------+ | ExID (con't) | option contents... +--------+--------+--------+--- Bonaventure, et al. Expires December 18, 2015 [Page 3] Internet-Draft Exp. MPTCP Option June 2015 The experimental TCP options defined in [RFC6994] could in theory be used over any TCP connection, including the subflows used by Multipath TCP. However, using them as such to support experimental features on a Multipath TCP connection would cause two practical problems. The first problem is that the utilisation of such an option should be negotiated during the three-way handshake by adding the experimental option in the SYN and SYN+ACK segments. Given the limited space for the options in these segments when Multipath TCP is used and other options are already used, this is not a valid approach. Second, middleboxes could accept the Multipath TCP option and drop or modify an experimental TCP option that is used to support an experimental Multipath TCP feature. This would increase the complexity of the middlebox handling algorithms inside a Multipath TCP implementation. For the above two reasons, we propose the utilisation of an Experimental Multipath TCP option that is encoded as shown in the figure below. 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| Flags | Experiment | +---------------+---------------+-------+-------+---------------+ | Id. (16 bits) | Subtype-specific data (variable length) ... +----------------------------------------------------------- ... Flags is a set of 4 flags: +-+-+-+-+ |S|U|r|r| +-+-+-+-+ where "rr" are for future assignment as additional flag bits. r bits MUST each be sent as zero and MUST be ignored on receipt. The Experimental Multipath TCP option has a variable length. It is always of kind=30 and Subtype=0xf. The Experiment identifier is a 16 bits integer that shall be assigned by using the same procedure as defined in [RFC6994]. [RFC6994] also supports the utilisation of 32 bits Experiment Identifiers. These 32 bits identifiers are composed of a 16 bits identifier assigned on a FCFS basis and a 16 bits magic number. At this stage, we propose that the Experimental Multipath TCP option uses only the 16 bits Experiment Identifier. The two high order flags that are included in the Experimental Multipath TCP option have the following semantics : Bonaventure, et al. Expires December 18, 2015 [Page 4] Internet-Draft Exp. MPTCP Option June 2015 o "S" flag (highest order bit) : This is the synchronising bit. When set to 1, it indicates that the host sending this option expects a reply from the remote host with an option having the same experiment identifier, but possibly containing other data. o "U" flag (second highest order bit) : When set to 1, this flag indicates that the experimental option was received by the sending host but it was unable to parse it. The two low order flags are currently reserved for further use. They MUST be set to zero when sending and ignored upon reception. To use the Experimental Multipath TCP option with a given experiment identifier over a Multipath TCP connection, the sending host must first verify the ability of the remote host to support this particular Experimental option. For this, it first sends in any valid TCP segment, including a duplicate acknowledgement, an Experimental Multipath TCP option with the "S" flag set. Upon reception of this option, the receiving host will verify whether it supports it. If yes, it shall return a TCP segment that contains the experimental option with the same identifier and the "S" and the "U" flags reset. This option may contain additional data depending on its semantics. If the receiving host does not recognise the experimental option that it has received, it shall return a TCP segment that contains the received experimental option with the "S" flag set to 0 and the "U" flag set to 1. Upon reception of this option, the sending host knows that the experimental option cannot be used over this Multipath TCP connection. Once the utilisation of a specific Experimental Multipath TCP option has been negotiated over a Multipath TCP connection, both hosts can use this experimental Multipath TCP option. If a host receives an Experimental Multipath TCP option with the "U" flag set to 0 that it does not support or contains information that it cannot parse, it shall return the exact option that it received with the "U" flag set to indicate the error to the remote host. If an invalid option is received with the "U" flag set to 0, it must be silently discarded. Future documents specifying new experimental MPTCP options should specify the extract semantic of the Subtype-specific data and whether additional validation operations are to be followed at both sides. Note, data can be included in an experimental data concurrently with the capability check (S/U). As a side effect of the use of a shared codepoint, an overhead of the 2 octets will be consumed in the option space for each experimental MPTCP option. This overhead should be taken into account when drawing conclusions related to the co-existence of multiple MPTCP Bonaventure, et al. Expires December 18, 2015 [Page 5] Internet-Draft Exp. MPTCP Option June 2015 experimental options or, even worse, between experimental MPTCP options and experimental TCP options. 3. Security considerations This document does not modify the security considerations for Multipath TCP. 4. IANA considerations This document proposes to modify the Multipath TCP option subtype 0xf that was reserved for utilisation in private testbed to support the Experimental Multipath TCP option. The same considerations as for [RFC6994] apply. IANA should create a "Multipath TCP Experimental Option Identifiers (MPTCP ExIDs)" registry. This registry contains the 16 bits ExIDs and a reference (description, document pointer, or assignee name and e-mail contact) for each entry. MPTCP ExIDs are assigned on a First Come, First Served (FCFS) [RFC5226]. IANA will advise applicants of duplicate entries to select an alternate value, as per typical FCFS processing. IANA will record known duplicate uses to assist the community in both debugging assigned uses as well as correcting unauthorized duplicate uses. IANA should impose no requirement on making a registration other than indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired but should not be required. 5. Conclusion This document has proposed a new experimental Multipath TCP option that is intended to replace the already defined, but apparently currently unused, Multipath TCP option reserved for private testbed. This new Experimental Multipath TCP option will enable implementors to perform experiments with Multipath TCP options without using the limited Multipath TCP option subtypes. 6. Acknowledgements This work was partially supported by the FP7-Trilogy2 project. This document was heavily inspired by [RFC6994]. Bonaventure, et al. Expires December 18, 2015 [Page 6] Internet-Draft Exp. MPTCP Option June 2015 7. References 7.1. Normative References [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.boucadair-mptcp-symmetric] Boucadair, M. and C. Jacquenet, "An Extension to MPTCP for Symmetrical Sub-Flow Management", draft-boucadair-mptcp- symmetric-02 (work in progress), March 2015. [I-D.ietf-mptcp-rfc6824bis] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", draft-ietf-mptcp-rfc6824bis-04 (work in progress), March 2015. [I-D.paasch-mptcp-syncookies] Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP robust for stateless webservers", draft-paasch-mptcp- syncookies-00 (work in progress), April 2015. [I-D.xu-mptcp-prmp] Xu, C., Huang, H., Zhang, H., Xiong, C., and L. Zhu, "Multipath Transmission Control Protocol (MPTCP) Partial Reliability Extension", draft-xu-mptcp-prmp-00 (work in progress), April 2015. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, August 2013. Bonaventure, et al. Expires December 18, 2015 [Page 7] Internet-Draft Exp. MPTCP Option June 2015 Authors' Addresses Olivier Bonaventure UCLouvain Email: Olivier.Bonaventure@uclouvain.be Benjamin Hesmans UCLouvain Email: Benjamin.Hesmans@uclouvain.be Mohamed Boucadair Orange Email: mohamed.boucadair@orange.com Bonaventure, et al. Expires December 18, 2015 [Page 8]