MPTCP Working Group O. Bonaventure Internet-Draft UCLouvain Intended status: Informational July 06, 2015 Expires: January 7, 2016 Supporting long TCP options in Multipath TCP draft-bonaventure-mptcp-long-options-00 Abstract The extensibility of TCP is severely limited by the Data Offset field of the TCP header that limits the number of bytes that can be used in each segment to transport options. This document considers Multipath TCP as the starting point and analyses different alternatives to improve the ability of Multipath TCP to transport TCP extensions. 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. 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 Expires January 7, 2016 [Page 1] Internet-Draft MPTCP Long Options July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Lessons learned with Multipath TCP . . . . . . . . . . . . . 3 3. Extending the DSS option . . . . . . . . . . . . . . . . . . 4 3.1. First approach : TCP EOL as marker . . . . . . . . . . . 6 3.2. Second approach : Option length in DSS . . . . . . . . . 9 3.3. Third approach : using the control stream for options . . 10 3.4. Middlebox interference . . . . . . . . . . . . . . . . . 12 4. Negotiating the extended DSS option . . . . . . . . . . . . . 16 5. Compatibility with the existing TCP options . . . . . . . . . 16 5.1. End-of-Option List . . . . . . . . . . . . . . . . . . . 16 5.2. Maximum Segment Size . . . . . . . . . . . . . . . . . . 16 5.3. No-Operation . . . . . . . . . . . . . . . . . . . . . . 16 5.4. SACK-Permitted . . . . . . . . . . . . . . . . . . . . . 16 5.5. SACK option . . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Timestamps . . . . . . . . . . . . . . . . . . . . . . . 17 5.7. TCP-TFO . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.8. TCP-AO option . . . . . . . . . . . . . . . . . . . . . . 17 5.9. TCP-User Timeout . . . . . . . . . . . . . . . . . . . . 17 5.10. Multipath TCP options . . . . . . . . . . . . . . . . . . 17 6. Security consideration . . . . . . . . . . . . . . . . . . . 18 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Multipath TCP is an extension to TCP [RFC0793] that was standardized in [RFC6824]. Multipath TCP uses several types of TCP options to exchange data. Like other TCP extensions, Multipath TCP suffers from the 4 bits Data Offset field of the TCP header that limits the size of the entire header, including options to 60 bytes. This limits the total length of the TCP options to 40 bytes, which becomes a problem for segments that include SACK [RFC2018], Timestamp [RFC1323], Multipath TCP [RFC6824] and TCP-AO [RFC5925]. For example, it becomes difficult to combine these four option types in a single segment. Various techniques to extend the TCP option space are being discussed [I-D.ietf-tcpm-tcp-edo] within the TCPM working group. As of this writing, there is not enough experience with such extensions and their possible interference with middleboxes that are known to limit the extensibility of TCP [IMC11]. Instead of starting from regular TCP as the other proposals, we assume that Multipath TCP has been successfully negotiated for the Bonaventure Expires January 7, 2016 [Page 2] Internet-Draft MPTCP Long Options July 2015 TCP connection and evaluate how the unique features of Multipath TCP can be tweaked to carry large TCP options including long SACK blocks. Instead of changing the semantics of the Data Offset field, adding a new TCP option or encoding the payload, we start from the DSS options used by Multipath TCP. This gives us more flexibility and leverages the middlebox resilience provided by Multipath TCP. In this document, we focus on the transport of longer TCP options once the Multipath TCP connection has been established. We leave for further work the problem of extending the TCP option space in the SYN segment during the three-way handshake. This document is organized as follows. We first discuss the lessons that were learned from the specification, implementation and deployment of Multipath TCP in section Section 2. We then discuss in Section 3 several solutions that modify the DSS option to support the transmission of additional TCP options. We propose in Section 4 to negotiate the utilisation of this option as a new Multipath TCP version. Section 5 discusses how the existing TCP options can be supported with the solution proposed in this document. 2. Lessons learned with Multipath TCP During the design, implementation and deployment of Multipath TCP during the last years we have learned some lessons on how various types of middleboxes can interfere with a TCP extension. These lessons have been documented in several scientific publications [IMC11] [HotMiddlebox13], but it is worth summarising them again. The first lesson concerns the initial three way handshake. Most TCP extensions assume that the utilisation of a new option can be safely negotiated by sending an option inside the initial SYN segment and verifying that the same option is present in the returned SYN+ACK. This is the approach used for SACK [RFC2018] and to some extent the WSCALE and TS extensions defined in [RFC7323]. Unfortunately, measurements with Multipath TCP showed that there are middleboxes that simply echo in the SYN+ACK segment any unknown option received in the SYN segment. To cope with such middleboxes, the TCP option used to negotiate the utilisation of a TCP extension cannot be the same in the SYN and SYN+ACK segments. The active opener must verify that the option sent in the SYN segment has not been modified before being returned in the SYN+ACK segment. The second lesson is also about the initial three way handshake. A middlebox can modify the SYN+ACK segment on the return path without having observed the option contained in the SYN segment. This kind of middlebox interference can be a problem for the negotiation of the utilisation of a TCP extension since the states of the active and the Bonaventure Expires January 7, 2016 [Page 3] Internet-Draft MPTCP Long Options July 2015 passive opener might disagree. Multipath TCP solves this problem by sending information in the third ACK. The third lesson is that despite a successful negotiation during the three way handshake by using option type x, middleboxes might still remove option type x in some segments on the connection. Any TCP extension must be able to cope with segments that do not contain an expected option. The fourth lesson is that middleboxes can split segments. Such middleboxes can be located inside the network or be simply the TSO implementation on the network interface card of the sending hosts [IMC11]. These network interface cards are very popular and it is difficult for a TCP stack to correctly detect their exact behaviour concerning the handling of TCP options. These cards expose a large MSS to the TCP stack and then split the large segment in smaller segments that are (usually) checksummed by the card. According to [IMC11] all the tested cards copy all the options included in the large segment into the smaller ones. The fifth lesson is that middleboxes can coalesce segments. Such middleboxes can be located inside the network or more likely on the receiving host. Most network interface cards implement GRO by performing the opposite operation of TSO. If the segments that are received in sequence always contain the same option, then these segments are coalesced in a larger segment which is delivered to the TCP stack. Note that the size of the segments that are delivered to the TCP stack will vary in function of the packet losses and also of the utilisation of options by the sending host. The sixth lesson is that middleboxes can modify, inject or remove data from the payload of TCP segments. A typical example are the Application Level Gateways used on Network Address Translators to "seamlessly" support application-level protocols that exchange IP addresses in the bytestream. To support these applications, ALGs need to modify the IP addresses (and possibly port numbers) exchanged in the bytestream. 3. Extending the DSS option The DSS option is defined in [RFC6824]. This option has a variable length depending on the utilisation of the 'm', 'M', 'a' and 'A' flags. The format of this option in shown in Figure 1. An important point to note is that it contains several flags that are currently reserved for future use. Bonaventure Expires January 7, 2016 [Page 4] Internet-Draft MPTCP Long Options July 2015 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| ( reser.) |F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data sequence number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-Level Length (2 octets) | Checksum (2 octets) | +-------------------------------+------------------------------+ Figure 1: DSS option We assume in this document that the utilisation of the modified DSS option is negotiated as a new Multipath TCP version in the three way handshake. The general approach evaluated in this document is to place the additional TCP options inside the payload and modify the DSS to indicate which part of the payload contains TCP options (if any) and which part contains payload data (if any). The generic solution is shown graphically in Figure 2. <- ext. -> options +--------+---------+--------+----------+--------...-----+ | ip hdr | TCP hdr | DSS | Options | User Data | +--------+---------+--------+----------+--------...-----+ <- DO -> <- Payload of TCP segment--> covered covered by DSS mapping Figure 2: Usage of the modified DSS option The key question for all the approaches discussed in this section is how to modify the DSS option to indicate the boundary between the additional TCP options and the payload. For simplicity, we assume in this section that only the Multipath TCP DSS option is placed in the extended TCP header. The other TCP are placed inside the payload which is covered by the DSS option. Bonaventure Expires January 7, 2016 [Page 5] Internet-Draft MPTCP Long Options July 2015 3.1. First approach : TCP EOL as marker A first approach to extend the TCP option space is to simply assume that each DSS option is always followed by one or more TCP options and that the EOL option, defined in [RFC0793] is used to mark the end of the additional TCP options. For simplicity, we assume that the DSS option is the only option that consumes space in the TCP header extension (i.e. the Data Offset field of the TCP header has a value equal to the length of the DSS option, possibly with a few NOP options to align it on 32 bits boundaries). The length included in the DSS option remains the length of the payload which is part of the bytestream without taking into account the bytes consummed by the included TCP options. This is illustrated in Figure 3. If the DSS checksum has been negotiated, it is computed only on the user data and the pseudo-header defined in [RFC6824]. +--------+---------+--------+--------+-----+------...-----+ | IP hdr | TCP hdr | DSS | Opt x | EOL | User data | +--------+---------+--------+--------+-----+------...-----+ <- Payload of TCP segment--> covered by DSS mapping Figure 3: Using the TCP EOL option to mark the boundary between TCP options and user data In this figure, Option x and the payload are optional. With this design there is always one byte used by the EOL option inside each segment that contains a DSS option. Let us now analyse how this solution react to middleboxes that coalesce or split segments. Figure 4 illustrates a middlebox that splits a large segment and copies the DSS option in both. The DSS option shows the mapping between the DSN (2) and the subflow sequence number (1) and the length covered by the DSS option. Bonaventure Expires January 7, 2016 [Page 6] Internet-Draft MPTCP Long Options July 2015 +---------+--------+-----+------...---+ | TCP hdr | DSS | EOL | Payload | | seq=1 | 2->1 | | 4 bytes | | len=5 | len=4 | | | +---------+--------+-----+------...---+ || \/ +---------+--------+-----+------...---+ | TCP hdr | DSS | EOL | Payload | | seq=1 | 2->1 | | 2 bytes | | len=3 | len=4 | | | +---------+--------+-----+------...---+ +---------+--------+-------...---+ | TCP hdr | DSS | Payload | | seq=3 | 2->1 | 2 bytes | | len=2 | len=4 | | +---------+--------+-------...---+ Figure 4: Effect of Segment splitting If the segment is split as shown in the above example, a Multipath TCP receiver will parse the DSS option in the first segment and wait until it has received all the mapped data before extracting the EOL option and the payload. Segment splitting does not affect this solution. If a middlebox coalesces segments, the situation is different. Let us consider the scenario shown in Figure 5. Bonaventure Expires January 7, 2016 [Page 7] Internet-Draft MPTCP Long Options July 2015 +---------+--------+-----+------...---+ | TCP hdr | DSS | EOL | Payload | | seq=1 | 2->1 | | 2 bytes | | len=3 | len=2 | | | +---------+--------+-----+------...---+ +---------+--------+-----+-------...--+ | TCP hdr | DSS | EOL | Payload | | seq=3 | 4->3 | | 2 bytes | | len=3 | len=2 | | | +---------+--------+-----+------...---+ || \/ +---------+--------+-----+------...---+-----+------...---+ | TCP hdr | DSS | EOL | Payload | EOL | Payload | | seq=1 | 2->1 | | 2 bytes | | 2 bytes | | len=5 | len=2 | | | | | +---------+--------+-----+------...---+-----+------------+ or +---------+--------+-----+------...---+-----+------...---+ | TCP hdr | DSS | EOL | Payload | EOL | Payload | | seq=1 | 3->3 | | 2 bytes | | 2 bytes | | len=5 | len=2 | | | | | +---------+--------+-----+------...---+-----+------------+ Figure 5: Effect of Segment Coalescing Since the two small segments do not contain the same option, a middlebox should not in theory coalesce them. Anyway, let us analyse what happens in this case. If the middlebox only copies the TCP option in the first segment, then the receiver will process the first EOL option and the first block of 2 bytes of payload. The remaining bytes are not covered by a mapping. The receiver will ack at the data level the first block of two bytes in the payload but not the second. After some time, the sender will retransmit the unacknowledged data with a new DSS option that will cover the data of the second segment. The same applies if the middlebox copies the second DSS option in the coalesced segment. A first drawback of this solution is that the TCP stack must parse the payload to extract all the options that are included inside a DSS map. A possible alternative to simplify this parsing would be to redefine an unused bit of the DSS option to indicate that the mapped Bonaventure Expires January 7, 2016 [Page 8] Internet-Draft MPTCP Long Options July 2015 payload starts with TCP options. If this bit is reset, then there are no options in the payload and the receiver can process the payload as usual. Parsing the payload might have a performance impact on packet filters used on some routers or firewalls that process TCP options. A second drawback of this approach is that the TCP options consumme TCP sequence space and are transmitted reliably. This implies that a measurement application that uses the difference between the sequence number of the SYN and FIN segments to compute the number of bytes exchanged over a connection will overestimate the number of bytes exchanged by the communicating applications. 3.2. Second approach : Option length in DSS The second approach is to include an 'Options length' field inside the DSS option to indicate the part of the payload that follows the DSS option that is used by TCP options. This is illustrated with the modified DSS option 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| ( reser.) |F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Data ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Data sequence number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ | Data-Level Length (2 octets) | Checksum (2 octets) | +-------------------------------+------------------------------+ | TCP Options Length | +-------------------------------+ Figure 6: Extending the DSS option to include a TCP options length This 'TCP Options length' field could be encoded in several ways : o as a 16 bits field that encodes the number of bytes used for options. This solution has the advantage of being aligned on 16 bits boundaries and supports options of up to 64 KBytes. o as an 8 bits field that encodes the number of bytes used for options. This solution supports options of up to 255 bytes. The Bonaventure Expires January 7, 2016 [Page 9] Internet-Draft MPTCP Long Options July 2015 DSS option is not aligned on 32 bits boundaries and TCP option padding might be required in the TCP extended header. o as an 8 bits field that encodes the number of 32 bits words used for options. This solution supports options of up to 1020 bytes. The DSS option is aligned on 16 bits boundaries and TCP option padding is required inside the DSS option. The last solution is probably the best compromise between overhead and extensibility. It however adds some complexity in the padding mechanism that needs to be used to encode the TCP options that appear before the DSS option and the TCP options that are encoded within the DSS option since both need to be aligned on 32 bits boundaries. With the three solutions above, it is possible to send data mapped by a DSS option without any TCP option by using a Length field (i.e. 20, 24 or 28 bytes) for the DSS option that does not include space for the 'Options Length'. 3.3. Third approach : using the control stream for options The control stream is an extension to Multipath TCP that was proposed in [I-D.paasch-mptcp-control-stream]. This extension redefines one flag (called 'S' in Figure 7) of the DSS option. 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|(reserved)|S|F|m|M|a|A| +---------------+---------------+-------+----------------------+ | Control ACK (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ |Control sequence number (4 or 8 octets, depending on flags) | +--------------------------------------------------------------+ | Subflow Sequence Number (4 octets) | +-------------------------------+------------------------------+ |Control-Level Length (2 octets)| Checksum (2 octets) | +-------------------------------+------------------------------+ Figure 7: Modification of the DSS option to indicate whether it maps user data (S=0) or TCP options (S=1) The control stream defines two separate bytestreams. The default bytestream is used to carry application level data. These datas are mapped by using the above DSS option with the 'S' flag set to 0. When the 'S' flag of the DSS option is set to 1, this indicates that the mapped data belongs to the second bytestream. In Bonaventure Expires January 7, 2016 [Page 10] Internet-Draft MPTCP Long Options July 2015 [I-D.paasch-mptcp-control-stream], this second bytestream was used to exchange options using a special TLV format. One of the use cases mentioned in [I-D.paasch-mptcp-control-stream] was the exchange of security keys. However, this solution was neither implemented nor deployed. We reuse it to map TCP options on the second bytestream. Figure 8 shows some examples of segments containing only TCP options, only user data or both user data and TCP options. In the first example, the S bit is set to 1 and thus the mapped payload only contains TCP options. In this segment, the DO field of the TCP header covers only the DSS option. In the second example, the S bit is set to zero and the payload contains user data. Again, the DO field of the TCP header only covers the DSS option. The third example combines both options and user data in a single segment. The first part of the payload, containing 'Opt x', is covered by the DSS with the S bit set to 1. This DSS maps TCP options. The second part of the payload contains user data. In this last example, the DO field of the TCP header covers the two DSS options. TCP segment containing extended options +--------+---------+--------------+--------+-------+ | IP hdr | TCP hdr | DSS (S=1) | Opt x | Opt y | +--------+---------+--------------+--------+-------+ <-- Payload ----> Covered by DSS TCP segment containing data +--------+---------+--------------+------...---+ | IP hdr | TCP hdr | DSS (S=0) | Payload | +--------+---------+--------------+------...---+ <- Payload -> Covered by DSS TCP segment containing both extended options and data covered by DSS (S=0) <-- + ---> +--------+---------+-----------+-----------+-------+---...---+ | IP hdr | TCP hdr | DSS (S=1) | DSS (S=0) |Opt x | Payload | +--------+---------+-----------+-----------+-------+---...---+ <- + -> covered by DSS (S=1) Figure 8: Examples of extended segments Bonaventure Expires January 7, 2016 [Page 11] Internet-Draft MPTCP Long Options July 2015 Note that to support both data and extended TCP options, two DSS options must be placed inside the segment. This implies that each of them must have a length of 20 bytes. In practice, we do not expect that hosts will often need to send extended options and data simultaneously. A better approach is to send data and extended options in different segments. Each TCP option that is included in the payload mapped by a DSS option MUST be encoded by using the standard Type-Length-Value format for TCP options [RFC0793]. The TCP options that are included in the payload mapped by a DSS option MAY end with TCP option zero (End of Option List). With this modified DSS option, the length of the extended TCP options is only limited by the length than can be mapped by a DSS option. Given that a DSS option can map up to 64 KBytes of data, it is possible to send up to 64 KBytes worth of options. 3.4. Middlebox interference We now qualitatively evaluate the last solution and analyze how middleboxes could interfere with the transmission of extended TCP options. A first point to note is that although the example below assume for simplicity that only the DSS option is part of the TCP header covered by the Data Offset, this is not a requirement. A TCP segment can include other TCP options inside the header covered by the Data Offset field. Our first use case is a middlebox that inserts a new TCP option and modifies the TCP Data Offset. Figure 9 considers the impact of such a middlebox on both a segment containing userdata and a segment containing extended TCP options. Such a middlebox was proposed in [I-D.ananth-middisc-tcpopt]. Bonaventure Expires January 7, 2016 [Page 12] Internet-Draft MPTCP Long Options July 2015 Initial segment containing options <--- DO covered ---> <-- DSS mapped--> +---------+--------------+--------+-------+ | TCP hdr | DSS (S=1) | Opt x | Opt y | +---------+--------------+--------+-------+ Modified segment containing options <--- DO covered ---> <-- DSS mapped--> +---------+----------+--------------+--------+-------+ | TCP hdr |Added Opt | DSS (S=1) | Opt x | Opt y | +---------+----------+--------------+--------+-------+ Initial segment containing userdata <--- DO covered ---> <-- DSS mapped--> +---------+--------------+--------+-------+ | TCP hdr | DSS (S=0) | User data | +---------+--------------+--------+-------+ Modified segment containing options <--- DO covered ---> <-- DSS mapped--> +---------+----------+--------------+--------+-------+ | TCP hdr |Added Opt | DSS (S=0) | User data | +---------+----------+--------------+--------+-------+ Figure 9: Impact of the insertion of a TCP option The proposed solution correctly copes with such a middlebox. It does not work on a path where a middlebox removes the DSS option because this option is required for the operation of Multipath TCP. In this case, Multipath TCP performs a fallback to regular TCP. Our second use case is a middlebox that splits a segment that contains TCP options or user data and copies the DSS option in both resulting segments. This is illustrated in Figure 10 Bonaventure Expires January 7, 2016 [Page 13] Internet-Draft MPTCP Long Options July 2015 +---------+--------+--------+ | TCP hdr | DSS(S1)| Opt x | | seq=1 | 2->1 | 4 bytes| | len=5 | len=4 | | +---------+--------+--------+ || \/ +---------+--------+--------+ | TCP hdr | DSS(S1)| Opt | | seq=1 | 2->1 | 2 bytes| | len=3 | len=4 | | +---------+--------+--------+ +---------+--------+--------+ | TCP hdr | DSS(S1)| Opt | | seq=3 | 2->1 | 2 bytes| | len=5 | len=4 | | +---------+--------+--------+ Figure 10: Effect of segment splitting With such a middlebox that splits a segment and copies the DSS option, the receiver can recover the extended option once it has received the two segments. The same applies for user data and is already supported by Multipath TCP implementations [IMC13a]. The third use case is a middlebox that coalesces two segments. We consider the case where a segment containing extended options is coalesced with a segment containing user data. A similar reasoning applies for other types of segment. This is illustrated in Figure 11. Bonaventure Expires January 7, 2016 [Page 14] Internet-Draft MPTCP Long Options July 2015 +---------+--------+-------------+ | TCP hdr | DSS(S1)| Options | | seq=1 | 2->1 | 4 bytes | | len=4 | len=4 | | +---------+--------+-------------+ +---------+--------+-------- --+ | TCP hdr | DSS(S0)| User data | | seq=5 | 4->5 | 2 bytes | | len=2 | len=2 | | +---------+--------+-----------+ || \/ Coalescing middlebox +---------+--------+----------+------------+ | TCP hdr | DSS(S1)| Options | User data | | seq=1 | 2->1 | 4 bytes | 2 bytes | | len=6 | len=4 | | | +---------+--------+----------+------------+ or +---------+--------+----------+------------+ | TCP hdr | DSS(S0)| Options | User data | | seq=1 | 4->5 | 4 bytes | 2 bytes | | len=6 | len=2 | | | +---------+--------+----------+------------+ Figure 11: Effect of Segment Coalescing Multipath TCP implementations already support middleboxes that coalesce consecutive segments containing data as demonstrated in [IMC13a]. There are two different possibilities depending on whether the first or the second DSS option is copied in the coalesced segment If the first DSS option is copied, then the receiver has a valid mapping for the extended TCP options and can decode them but no mapping for the user data. The sender will timeout and retransmit a segment containing the user data with a valid mapping. If the second DSS option is copied, then the receiver can process the user data but has to wait for a retransmission of the mapping that covers the extended TCP options. Bonaventure Expires January 7, 2016 [Page 15] Internet-Draft MPTCP Long Options July 2015 4. Negotiating the extended DSS option The proposed extended DSS option should only be used between hosts that support the extension. This should be negotiated during the three way handshake for the initial subflow. There are two possible solutions for this negotiation : o Redefine one of the unused bits (e.g. 'B') of the MP_CAPABLE option [RFC6824] to negotiate the utilisation of the extended DSS option o Define a new version of the Multipath protocol [RFC6824] Given the impact of the change, it is probable safer to increment the protocol version number. 5. Compatibility with the existing TCP options In this section, we discuss how the existing TCP options can be transported by using the control stream. 5.1. End-of-Option List If used, this option, defined in [RFC0793] MUST appear as the last TCP option in each DSS-mapped payload that contains TCP options. 5.2. Maximum Segment Size The MSS option, defined in [RFC0793] can only appear in SYN segments. It MUST never be sent inside a DSS-mapped payload. If a host receives a DSS-mapped payload that contains this option, it MUST ignore the entire DSS-mapped payload. 5.3. No-Operation This option, defined in [RFC0793] is often used to align TCP options to word boundaries. Some middleboxes replace existing TCP options with this option [IMC11]. A host that sends TCP options inside a DSS-mapped payload MAY send one or more No-Operation options inside the DSS-mapped payload. 5.4. SACK-Permitted This option, defined in [RFC2018], is used to negotiate the utilisation of the selective acknowledgements during the three way handshake. It MUST thus not appear in any DSS-mapped payload. If a host receives a DSS-mapped payload that contains this option, it MUST ignore the entire DSS-mapped payload. Bonaventure Expires January 7, 2016 [Page 16] Internet-Draft MPTCP Long Options July 2015 5.5. SACK option This option, defined in [RFC2018], MAY either be sent as a regular TCP option or inside a DSS-mapped payload. Placing the option in a DSS-mapped payload has two advantages. First, the length of the SACK option is not anymore limited by the maximum length of the TCP header. Second, this option will be delivered reliably to the destination. 5.6. Timestamps This option, defined in [RFC1323] and revised in [RFC7323] SHOULD not appear in any DSS-mapped payload. It does not benefit from the reliability provided by the DSS-mapped payload. 5.7. TCP-TFO Two options are defined in [I-D.ietf-tcpm-fastopen] : Fast Open Cookie and Fast Open Cookie Request. These two options can only be used inside SYN segments. For this reason, they MUST never be sent inside a DSS-mapped payload. If a host receives a DSS-mapped payload that contains one of these options, it MUST ignore the entire DSS- mapped payload. 5.8. TCP-AO option This option, defined in [RFC5925], allows to authenticate the TCP segments exchanged between hosts. Given the processing rules defined in [RFC5925], it seems difficult to place it as defined in [RFC5925] inside a DSS-mapped payload. For this reason, a host MUST never send the TCP-AO option inside a DSS-mapped payload. It should be noted that a DSS option of length 20 bytes can be used inside a segment that is covered by a TCP-AO option of 20 bytes or less. 5.9. TCP-User Timeout This option is defined in [RFC5482]. It MAY either be sent as a regular TCP option or inside a DSS-mapped payload. Placing the option in a DSS-mapped payload provides a reliable delivery of the option for the applications requiring it. 5.10. Multipath TCP options Several Multipath TCP options are defined in [RFC6824]. Some of them can benefit from the reliability and the unrestricted length of the DSS-mapped payload. Bonaventure Expires January 7, 2016 [Page 17] Internet-Draft MPTCP Long Options July 2015 The MP_CAPABLE and MP_JOIN options can only appear in SYN segments. They MUST never be sent inside a DSS-mapped payload. If a host receives a DSS-mapped payload that contains one of these options, it MUST reject the entire DSS-mapped payload. Similarly, a DSS option cannot appear inside a DSS-mapped payload. If a host receives a DSS-mapped payload that contains another DSS option, it MUST reject the entire DSS-mapped payload. The ADD_ADDR and REMOVE_ADDR can benefit from the reliability of being transported inside a DSS-mapped payload. As discussed in [Cellnet12], the loss of such options can impact the performance of Multipath TCP in failover scenarios. Another benefit of the DSS- mapped payload is that a multihomed host that has several IPv6 addresses could advertise all its addresses by sending a single DSS- mapped segment. The MP_PRIO option can also benefit from the added reliability of placing it inside a DSS-mapped payload. The MP_FAIL option is used when there are problems with middleboxes. In this case, placing it inside a DSS-mapped payload is unlikely to help. For this reason, it MUST never appear inside a DSS-mapped payload. The MP_FASTCLOSE option is used to abruptly terminate an MPTCP connection.It can be transmitted as a DSS-mapped option. 6. Security consideration The solution proposed in this document does not modify the security properties of Multipath TCP. The security considerations listed in [RFC6824] [RFC6181] apply. 7. Conclusion In this document, we have proposed a simple modification to the format of the DSS option in Multipath TCP to support the transport of long TCP options inside the TCP payload while leveraging the existing Multipath TCP mechanisms. 8. Acknowledgements This work was partially supported by the FP7-Trilogy2 project. We would like to thank Joe Touch and Bob Briscoe whose work on extending the TCP option space [I-D.briscoe-tcpm-inner-space] [I-D.ietf-tcpm-tcp-edo] has motivated this work. This document also benefitted from comments and suggestions from Fabien Duchene, Christoph Paasch and Benjamin Hesmans. Bonaventure Expires January 7, 2016 [Page 18] Internet-Draft MPTCP Long Options July 2015 9. Informative References [Cellnet12] Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O. Bonaventure, "Exploring Mobile/WiFi Handover with Multipath TCP", ACM SIGCOMM workshop on Cellular Networks (Cellnet12) , 2012, . [HotMiddlebox13] Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O. Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT workshop HotMiddlebox , December 2013, . [I-D.ananth-middisc-tcpopt] Knutsen, A., Ramaiah, A., and A. Ramasamy, "TCP option for transparent Middlebox negotiation", draft-ananth-middisc- tcpopt-02 (work in progress), February 2013. [I-D.briscoe-tcpm-inner-space] Briscoe, B., "Inner Space for TCP Options", draft-briscoe- tcpm-inner-space-01 (work in progress), October 2014. [I-D.ietf-tcpm-fastopen] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", draft-ietf-tcpm-fastopen-10 (work in progress), September 2014. [I-D.ietf-tcpm-tcp-edo] Touch, J. and W. Eddy, "TCP Extended Data Offset Option", draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015. [I-D.paasch-mptcp-control-stream] Paasch, C. and O. Bonaventure, "A generic control stream for Multipath TCP", draft-paasch-mptcp-control-stream-00 (work in progress), February 2014. [IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it still possible to extend TCP?", Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11) , 2011, . Bonaventure Expires January 7, 2016 [Page 19] Internet-Draft MPTCP Long Options July 2015 [IMC13a] Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and B. Donnet, "Revealing Middlebox Interference with Tracebox", Proceedings of the 2013 ACM SIGCOMM conference on Internet measurement conference , 2013, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, March 2009. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, March 2011. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, "TCP Extensions for High Performance", RFC 7323, September 2014. Author's Address Olivier Bonaventure UCLouvain Email: Olivier.Bonaventure@uclouvain.be Bonaventure Expires January 7, 2016 [Page 20]