--- 1/draft-ietf-tcpm-converters-10.txt 2019-09-27 02:13:04.724059552 -0700 +++ 2/draft-ietf-tcpm-converters-11.txt 2019-09-27 02:13:04.828062184 -0700 @@ -1,37 +1,37 @@ TCPM Working Group O. Bonaventure, Ed. Internet-Draft Tessares Intended status: Experimental M. Boucadair, Ed. -Expires: February 2, 2020 Orange +Expires: March 30, 2020 Orange S. Gundavelli Cisco S. Seo Korea Telecom B. Hesmans Tessares - August 01, 2019 + September 27, 2019 0-RTT TCP Convert Protocol - draft-ietf-tcpm-converters-10 + draft-ietf-tcpm-converters-11 Abstract This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. This proxy is designed to avoid inducing extra delay when involved in a network-assisted connection (that is, 0-RTT). This specification assumes an explicit model, where the proxy is explicitly configured on hosts. -Editorial Note (To be removed by RFC Editor) + -- Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: [This-RFC] Please update TBA statements with the port number to be assigned to the 0-RTT TCP Convert Protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -39,21 +39,21 @@ 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 https://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 February 2, 2020. + This Internet-Draft will expire on March 30, 2020. Copyright Notice Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,90 +64,90 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Network-Assisted Connections: The Rationale . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Functional Elements . . . . . . . . . . . . . . . . . . . 6 - 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 8 + 3.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 9 3.3. Sample Examples of Outgoing Converter-Assisted Multipath - TCP Connections . . . . . . . . . . . . . . . . . . . . . 12 + TCP Connections . . . . . . . . . . . . . . . . . . . . . 13 3.4. Sample Example of Incoming Converter-Assisted Multipath - TCP Connection . . . . . . . . . . . . . . . . . . . . . 13 + TCP Connection . . . . . . . . . . . . . . . . . . . . . 14 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 15 - 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15 - 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16 - 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16 - 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16 - 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17 - 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 18 - 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 19 - 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 21 - 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21 - 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 22 + 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 16 + 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 17 + 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 17 + 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 18 + 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 19 + 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 20 + 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 22 + 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 22 + 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 23 5. Compatibility of Specific TCP Options with the Conversion - Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25 - 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26 - 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26 - 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 27 - 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27 - 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27 - 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28 - 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28 - 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29 - 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30 - 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 - 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31 - 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 32 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32 - 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 33 - 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 33 - 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33 - 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 34 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 9.2. Informative References . . . . . . . . . . . . . . . . . 37 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40 + Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 26 + 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 27 + 5.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 27 + 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 28 + 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 28 + 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 28 + 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 29 + 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 29 + 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 29 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 30 + 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 31 + 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 + 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 32 + 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 33 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 33 + 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 34 + 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 34 + 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 34 + 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 35 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 9.2. Informative References . . . . . . . . . . . . . . . . . 38 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Example Socket API Changes to Support the 0-RTT - Convert Protocol . . . . . . . . . . . . . . . . . . 42 - B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 42 - B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42 - Appendix C. Some Design Considerations . . . . . . . . . . . . . 43 - Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 44 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 + Convert Protocol . . . . . . . . . . . . . . . . . . 43 + B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 43 + B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 43 + Appendix C. Some Design Considerations . . . . . . . . . . . . . 44 + Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 45 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 1. Introduction 1.1. The Problem Transport protocols like TCP evolve regularly [RFC7414]. TCP has been improved in different ways. Some improvements such as changing the initial window size [RFC6928] or modifying the congestion control scheme can be applied independently on clients and servers. Other - improvements such as Selective Acknowledgements [RFC2018] or large + improvements such as Selective Acknowledgments [RFC2018] or large windows [RFC7323] require a new TCP option or to change the semantics of some fields in the TCP header. These modifications must be deployed on both clients and servers to be actually used on the Internet. Experience with the latter TCP extensions reveals that their deployment can require many years. Fukuda reports in [Fukuda2011] results of a decade of measurements showing the - deployment of Selective Acknowledgements, Window Scale and TCP + deployment of Selective Acknowledgments, Window Scale and TCP Timestamps. [ANRW17] describes measurements showing that TCP Fast Open (TFO) [RFC7413] is still not widely deployed. There are some situations where the transport stack used on clients (or servers) can be upgraded at a faster pace than the transport stack running on servers (or clients). In those situations, clients would typically want to benefit from the features of an improved transport protocol even if the servers have not yet been upgraded and conversely. Some assistance from the network to make use of these features is valuable. For example, Performance Enhancing Proxies @@ -230,20 +230,33 @@ policies. These policies, and how they are communicated to endpoints, are out of scope. Furthermore, it is possible to bypass the Transport Converter to connect directly to the servers that already support the required TCP extension(s). This document assumes an explicit model in which a client is configured with one or a list of Transport Converters (statically or through protocols such as [I-D.boucadair-tcpm-dhc-converter]). Configuration means are outside the scope of this document. + The use of a Transport Converter means that there is no end-to-end + transport connection between the client and server. This could + potentially create problems in some scenarios such as those discussed + in Section 4 of [RFC3135]. Some of these problems may not be + applicable, for example, a Transport Converter can inform a client by + means of Network Failure (65) or Destination Unreachable (97) error + messages (Section 4.2.8) that it encounters a failure problem; the + client can react accordingly. An endpoint, or its network + administrator, can assess the benefit provided by the Transport + Converter service versus the risk. This is one reason why the + Transport Converter functionality has to be explicitly requested by + an endpoint. + This document is organized as follows. First, Section 3 provides a brief explanation of the operation of Transport Converters. Then, Section 4 describes the Convert Protocol. Section 5 discusses how Transport Converters can be used to support different TCP extensions. Section 6 then discusses the interactions with middleboxes, while Section 7 focuses on the security considerations. Appendix B describes how a TCP stack would need to support the protocol described in this document. Appendix C records some considerations that impacted the design of the protocol. Appendix D @@ -264,46 +277,45 @@ Only the exchange of control messages is depicted in the figures. 3. Architecture 3.1. Functional Elements The Convert Protocol considers three functional elements: o Clients; - o Transport Converters; o Servers. - A Transport Converter is a network function that relays all data + A Transport Converter is a network function that proxies all data exchanged over one upstream connection to one downstream connection and vice versa (Figure 1). The Transport Converter, thus, maintains state that associates one upstream connection to a corresponding downstream connection. A connection can be initiated from both sides of the Transport Converter (Internet-facing interface, customer-facing interface). | : | +------------+ Client <- upstream ->| Transport |<- downstream ->Server - | Converter | + connection | Converter | connection +------------+ | customer-facing interface : Internet-facing interface | - Figure 1: A Transport Converter Relays Data between Pairs of TCP + Figure 1: A Transport Converter Proxies Data between Pairs of TCP Connections "Client" refers to a software instance embedded on a host that can reach a Transport Converter via its customer-facing interface. The "Client" can initiate connections via a Transport Converter (referred to as outgoing connections (Section 3.3)). Also, the "Client" can accept incoming connections via a Transport Converter (referred to as incoming connections (Section 3.4)). Transport Converters can be operated by network operators or third @@ -419,32 +431,38 @@ Server in the payload of the SYN sent to the Transport Converter to minimize connection establishment delays. The Transport Converter maintains two connections that are combined together: o the upstream connection is the one between the Client and the Transport Converter. o the downstream connection is between the Transport Converter and the Server. + The control messages, discussed in Section 4, establish state in the + Transport Converter that will enable it to proxy between the two TCP + connections. These control messages are destined to the Transport + Convert and are, thus, removed by the Converter when proxying between + the two connections. + Any user data received by the Transport Converter over the upstream - (or downstream) connection is relayed over the downstream (or + (or downstream) connection is proxied over the downstream (or upstream) connection. In particular, if the initial SYN message contains data in its payload (e.g., [RFC7413]), that data MUST be - placed right after the Convert TLVs when generating the relayed SYN. + placed right after the Convert TLVs when generating the SYN. The Converter associates a lifetime with state entries used to bind an upstream connection with its downstream connection. - A Transport Converter MAY operate in address preservation or address - sharing modes as discussed in Section 5.4 of - [I-D.nam-mptcp-deployment-considerations]. Which behavior to use by + A Transport Converter may operate in address preservation or address + sharing modes (e.g., Section 5.4 of + [I-D.nam-mptcp-deployment-considerations]). Which behavior to use by a Transport Converter is deployment-specific. If address sharing mode is enabled, the Transport Converter MUST adhere to REQ-2 of [RFC6888] which implies a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]) must be supported. This behavior is meant to avoid breaking applications that depend on the source address remaining constant. Figure 5 illustrates the establishment of an outgoing TCP connection by a Client through a Transport Converter. @@ -461,37 +479,45 @@ Transport Converter The Client sends a SYN destined to the Transport Converter. The payload of this SYN contains the address and port number of the Server. The Transport Converter does not reply immediately to this SYN. It first tries to create a TCP connection towards the target Server. If this upstream connection succeeds, the Transport Converter confirms the establishment of the connection to the Client by returning a SYN+ACK and the first bytes of the bytestream contain information about the TCP options that were negotiated with the - Server. + Server. Also, a state entry is instantiated for this connection. + This state entry is used by the Converter to handle subsequent + messages belonging to the connection. Note that the Converter + silently ignores Non-SYN messages that do not match an active state + entry. The connection can also be established from the Internet towards a Client via a Transport Converter (Figure 6). This is typically the case when an application on the Client listens to a specific port (the Client hosts an application server, typically). When the Converter receives an incoming SYN from a remote host, it checks if it can provide the conversion service for the destination IP address - and destination port number of that SYN. If the check is successful, - the Converter inserts the source IP address and source port number in - the SYN packet, rewrites the source IP address to one of its IP - addresses and, eventually (i.e., only when the Converter is + and destination port number of that SYN. If the check fails, the + packet is silently ignored by the Converter. If the check is + successful, the Converter inserts the source IP address and source + port number in the SYN packet, rewrites the source IP address to one + of its IP addresses and, eventually (i.e., only when the Converter is configured in an address sharing mode), the destination IP address and port number in accordance with any information stored locally. - That SYN is then forwarded to the next hop. SYN+ACK and ACK will be - then exchanged between the Client, the Converter, and remote host to - confirm the establishment of the connection. + That SYN is then forwarded to the next hop. A transport session + entry is created by the Converter for this connection. SYN+ACK and + ACK will be then exchanged between the Client, the Converter, and + remote host to confirm the establishment of the connection. The + Converter uses the transport session entry to proxy packets belonging + to the connection. Transport Remote Client Converter Host (RH) | | | |SYN [<-RH IP@:port]| SYN | |<------------------|<---------------------| |------------------>|--------------------->| | SYN+ACK [ ] | SYN+ACK | | ... | ... | @@ -521,21 +547,21 @@ For these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet towards a Transport Converter. The Convert protocol includes an optional Cookie TLV that provides similar protection as the TCP Fast Open option without consuming space in the extended TCP header. In particular, this design allows for the use of longer cookies. If the downstream (or upstream) connection fails for some reason (excessive retransmissions, reception of an RST segment, etc.), then - the Converter should force the teardown of the upstream (or + the Converter should force the tear-down of the upstream (or downstream) connection. The same reasoning applies when the upstream connection ends. In this case, the Converter should also terminate the downstream connection by using FIN segments. If the downstream connection terminates with the exchange of FIN segments, the Converter should initiate a graceful termination of the upstream connection. 3.3. Sample Examples of Outgoing Converter-Assisted Multipath TCP Connections @@ -553,21 +579,20 @@ Transport Client Converter Server |SYN, | | |MPC [->Server:port]| SYN, MPC | |------------------>|--------------------->| |<------------------|<---------------------| | SYN+ACK,MPC [.] | SYN+ACK | |------------------>|--------------------->| | ACK, MPC | ACK | - | | | | ... | ... | Figure 7: Establishment of a Multipath TCP Connection Through a Transport Converter towards a Server that Does Not Support Multipath TCP The Client tries to initiate a Multipath TCP connection by sending a SYN with the MP_CAPABLE option (MPC in Figure 7). The SYN includes the address and port number of the target Server, that are extracted and used by the Transport Converter to initiate a Multipath TCP @@ -600,21 +625,20 @@ Transport Client Converter Server |SYN, | | |MPC [->Server:port]| SYN, MPC | |------------------>|--------------------->| |<------------------|<---------------------| |SYN+ACK, | SYN+ACK, MPC | |MPC [MPC supported]| | |------------------>|--------------------->| | ACK, MPC | ACK, MPC | - | | | | ... | ... | Figure 8: Establishment of a Multipath TCP Connection Through a Converter Towards an MPTCP-capable Server 3.4. Sample Example of Incoming Converter-Assisted Multipath TCP Connection An example of an incoming Converter-assisted Multipath TCP connection is depicted in Figure 9. In order to support incoming connections @@ -629,72 +653,76 @@ port number). The Converter accepts the request by creating a TCP mapping (internal IP address, internal port number, external IP address, external port number). The external IP address and external port number will be then advertised using an out-of-band mechanism so that remote hosts can initiate TCP connections to the Client via the Converter. Note that the external and internal information may be the same. Then, when the Converter receives an incoming SYN, it checks its mapping table to verify if there is an active mapping matching the - destination IP address and destination port of that SYN. If an entry - is found, the Converter inserts an MP_CAPABLE option and Connect TLV - in the SYN packet, rewrites the source IP address to one of its IP + destination IP address and destination port of that SYN. If no entry + is found, the Converter silently ignores the message. If an entry is + found, the Converter inserts an MP_CAPABLE option and Connect TLV in + the SYN packet, rewrites the source IP address to one of its IP addresses and, eventually, the destination IP address and port number in accordance with the information stored in the mapping. SYN+ACK and ACK will be then exchanged between the Client and the Converter to confirm the establishment of the initial subflow. The Client can add new subflows following normal Multipath TCP procedures. Transport Remote Client Converter Host | | | |<--------------------|<-------------------| |SYN, | SYN | |MPC[Remote Host:port]| | |-------------------->|------------------->| | SYN+ACK, MPC | SYN+ACK | |<--------------------|<-------------------| | ACK, MPC | ACK | - | | | | ... | ... | Figure 9: Establishment of an Incoming Multipath TCP Connection through a Transport Converter It is out of scope of this document to define specific Convert TLVs to manage incoming connections. These TLVs can be defined in a separate document. 4. The Convert Protocol (Convert) This section defines the Convert protocol (Convert, for short) messages that are exchanged between a Client and a Transport Converter. By default, the Transport Converter listens on TCP port number TBA for Convert messages from Clients. Clients send packets bound to connections eligible to the conversion service to the provisioned Transport Converter using TBA as - destination port number. This applies for both control and data - messages. Additional information is supplied by Clients to the - Transport Converter by means of Convert messages as detailed in the - following sub-sections. + destination port number. This applies for both control messages and + data. Additional information is supplied by Clients to the Transport + Converter by means of Convert messages as detailed in the following + sub-sections. Convert messages may appear only in a SYN, SYN+ACK, or ACK. Convert messages MUST be included as the first bytes of the - bytestream. All Convert messages start with a 32 bits long fixed + bytestream. All Convert messages starts with a 32 bits long fixed header (Section 4.1) followed by one or more Convert TLVs (Type, Length, Value) (Section 4.2). + User data can be included in SYN or non-SYN messages. User data is + unambiguously distinguished from Convert TLVs owing to the Total + Length field in the Convert messages. + 4.1. The Convert Fixed Header The Convert Protocol uses a 32 bits long fixed header that is sent by both the Client and the Transport Converter over each established connection. This header indicates both the version of the protocol used and the length of the Convert message. The Client and the Transport Converter MUST send the fixed-sized header, shown in Figure 10, as the first four bytes of the bytestream. @@ -885,21 +913,21 @@ / ... / +---------------------------------------------------------------+ Figure 15: The Connect TLV The 'TCP Options' field is a variable length field that carries a list of TCP option fields (Figure 16). Each TCP option field is encoded as a block of 2+n bytes where the first byte is the TCP option Kind and the second byte is the length of the TCP option as specified in [RFC0793]. The minimum value for the TCP option Length - is 2. The TCP options that do not include a length subfield, i.e., + is 2. The TCP options that do not include a length sub-field, i.e., option types 0 (EOL) and 1 (NOP) defined in [RFC0793] MUST NOT be placed inside the TCP options field of the Connect TLV. The optional Value field contains the variable-length part of the TCP option. A length of two indicates the absence of the Value field. The TCP options field always ends on a 32 bits boundary after being padded with zeros. 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 +---------------+---------------+---------------+---------------+ @@ -916,21 +944,21 @@ limit) or resource exhaustion conditions, a Transport Converter attempts to establish a connection to the address and port that it contains. The Transport Converter MUST use by default the TCP options that correspond to its local policy to establish this connection. These are the options that it advertises in the Supported TCP Extensions TLV. Upon reception of an extended Connect TLV, and absent any rate limit policy or resource exhaustion conditions, a Transport Converter MUST attempt to establish a connection to the address and port that it - contains. It MUST include the options of the 'TCP Options' subfield + contains. It MUST include the options of the 'TCP Options' sub-field in the SYN sent to the Server in addition to the TCP options that it would have used according to its local policies. For the TCP options that are listed without an optional value, the Transport Converter MUST generate its own value. For the TCP options that are included in the 'TCP Options' field with an optional value, it MUST copy the entire option for use in the connection with the destination peer. This feature is required to support TCP Fast Open. The Transport Converter may discard a Connect TLV request for various reasons (e.g., authorization failed, out of resources, invalid @@ -1119,24 +1147,24 @@ Converter does not have enough resources to perform the request. This error MUST be sent by the Transport Converter when it does not have sufficient resources to handle a new connection. The Transport Converter may indicate in the Value field the suggested delay (in seconds) that the Client SHOULD wait before soliciting the Transport Converter for a new proxied connection. A Value of zero corresponds to a default delay of at least 30 seconds. o Network Failure (65): This error indicates that the Transport - Converter is experiencing a network failure to relay the request. + Converter is experiencing a network failure to proxy the request. The Transport Converter MUST send this error code when it - experiences forwarding issues to relay a connection. The + experiences forwarding issues to proxy a connection. The Transport Converter may indicate in the Value field the suggested delay (in seconds) that the Client SHOULD wait before soliciting the Transport Converter for a new proxied connection. A Value of zero corresponds to a default delay of at least 30 seconds. o Connection Reset (96): This error indicates that the final destination responded with an RST packet. The Value field MUST be set to zero. o Destination Unreachable (97): This error indicates that an ICMP @@ -1202,27 +1230,27 @@ proxied message to be function of the scaling factor of the incoming connection. There is no benefit from a deployment viewpoint in enabling a Client of a Transport Converter to specifically request the utilization of the WS option (Kind=3) with a specific scaling factor towards a remote Server. For this reason, a Transport Converter MUST ignore option Kind=3 if it appears in a Connect TLV. It MUST NOT announce it in a Supported TCP Extensions TLV. -5.3. Selective Acknowledgements +5.3. Selective Acknowledgments Two distinct TCP options were defined to support selective - acknowledgements in [RFC2018]. This first one, SACK Permitted + acknowledgments in [RFC2018]. This first one, SACK Permitted (Kind=4), is used to negotiate the utilization of selective - acknowledgements during the three-way handshake. The second one, - SACK (Kind=5), carries the selective acknowledgements inside regular + acknowledgments during the three-way handshake. The second one, SACK + (Kind=5), carries the selective acknowledgments inside regular segments. The SACK Permitted option (Kind=4) MAY be advertised by a Transport Converter in the Supported TCP Extensions TLV. Clients connected to this Transport Converter MAY include the SACK Permitted option in the Connect TLV. The SACK option (Kind=5) cannot be used during the three-way handshake. For this reason, a Transport Converter MUST ignore option Kind=5 if it appears in a Connect TLV. It MUST NOT announce it in a @@ -1244,22 +1272,22 @@ could use to establish a connection to a remote server. A Transport Converter MAY advertise the Timestamp option (Kind=8) in the TCP Supported Extensions TLV. The clients connected to this Transport Converter MAY include the Timestamp option in the Connect TLV but without any timestamp. 5.5. Multipath TCP The Multipath TCP options are defined in [RFC6824]. [RFC6824] - defines one variable length TCP option (Kind=30) that includes a - subtype field to support several Multipath TCP options. There are + defines one variable length TCP option (Kind=30) that includes a sub- + type field to support several Multipath TCP options. There are several operational use cases where clients would like to use Multipath TCP through a Transport Converter [IETFJ16]. However, none of these use cases require the Client to specify the content of the Multipath TCP option that the Transport Converter should send to a remote server. A Transport Converter which supports Multipath TCP conversion service MUST advertise the Multipath TCP option (Kind=30) in the Supported TCP Extensions TLV. Clients serviced by this Transport Converter may include the Multipath TCP option in the Connect TLV but without any @@ -1327,21 +1355,21 @@ Nevertheless, and in order to allow for a robust service, this section describes how a Client can detect middlebox interference and stop using the Transport Converter affected by this interference. Internet measurements [IMC11] have shown that middleboxes can affect the deployment of TCP extensions. In this section, we only discuss the middleboxes that modify SYN and SYN+ACK packets since the Convert Protocol places its messages in such packets. Consider a middlebox that removes the SYN payload. The Client can - detect this problem by looking at the acknowledgement number field of + detect this problem by looking at the acknowledgment number field of the SYN+ACK returned by the Transport Converter. The Client MUST stop to use this Transport Converter given the middlebox interference. Consider now a middlebox that drops SYN/ACKs with a payload. The Client won't be able to establish a connection via the Transport Converter. The case of a middlebox that removes the payload of SYN+ACKs (but not the payload of SYN) can be detected by a Client. This is hinted by @@ -1687,22 +1715,22 @@ [Fukuda2011] Fukuda, K., "An Analysis of Longitudinal TCP Passive Measurements (Short Paper)", Traffic Monitoring and Analysis. TMA 2011. Lecture Notes in Computer Science, vol 6613. , 2011. [HotMiddlebox13b] Detal, G., Paasch, C., and O. Bonaventure, "Multipath in the Middle(Box)", HotMiddlebox'13 , December 2013, - . + . [I-D.arkko-arch-low-latency] Arkko, J. and J. Tantsura, "Low Latency Applications and the Internet Architecture", draft-arkko-arch-low- latency-02 (work in progress), October 2017. [I-D.boucadair-mptcp-plain-mode] Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., @@ -1862,21 +1890,21 @@ servers like web servers. The Convert protocol is different and as discussed in RFC7413, there are different ways to protect from such attacks. Instead of using a TFO cookie inside the TCP options, which consumes precious space in the extended TCP header, this version supports the utilization of a Cookie that is placed in the SYN payload. This provides the same level of protection as a TFO Cookie in environments were such protection is required. * the Bootstrap procedure has been simplified based on feedback - from implementers + from implementors * Error messages are not included in RST segments anymore but sent in the bytestream. Implementors have indicated that processing such segments on clients was difficult on some platforms. This change simplifies client implementations. * Many minor editorial changes to clarify the text based on implementors feedback. o 05 to -06: Many clarifications to integrate the comments from the @@ -1903,21 +1931,21 @@ * Nits * Added Appendix A on example Socket API changes o 08: * Added short discussion on the termination of connections o 09: - * Various to comments received during last call + * Address various comments received during last call Appendix B. Example Socket API Changes to Support the 0-RTT Convert Protocol B.1. Active Open (Client Side) On the client side, the support of the 0-RTT Converter protocol does not require any other changes than those identified in Appendix A of [RFC7413]. Those modifications are already supported by multiple TCP stacks. @@ -1988,21 +2016,21 @@ Recently, the TCP_FASTOPEN_NO_COOKIE socket option has been added to provide the same behavior on a per socket basis. This enables a single host to support both servers that require the TFO cookie and servers that do not use it. Appendix C. Some Design Considerations Several implementors expressed concerns about the use of TFO. As a reminder, the TFO Cookie protects from some attack scenarios that affect open servers like web servers. The Convert protocol is - different and as discussed in RFC7413, there are different ways to + different and, as discussed in RFC7413, there are different ways to protect from such attacks. Instead of using a TFO cookie inside the TCP options, which consumes precious space in the extended TCP header, the Convert protocol supports the utilization of a Cookie that is placed in the SYN payload. This provides the same level of protection as a TFO Cookie in environments were such protection is required. Error messages are not included in RST segments but sent in the bytestream. Implementors have indicated that processing such segments on clients was difficult on some platforms. This change @@ -2089,21 +2117,21 @@ Server [RFC8305]. A fourth difference is that the Convert protocol only allows the client to specify the address/port of the destination server and not a DNS name. We evaluated an alternate design for the Connect TLV that included the DNS name of the remote peer instead of its IP address as in SOCKS [RFC1928]. However, that design was not adopted because it induces both an extra load and increased delays on the Transport Converter to handle and manage DNS resolution requests. -Acknowledgements +Acknowledgments Although they could disagree with the contents of the document, we would like to thank Joe Touch and Juliusz Chroboczek whose comments on the MPTCP mailing list have forced us to reconsider the design of the solution several times. We would like to thank Raphael Bauduin, Stefano Secci, Anandatirtha Nandugudi and Gregory Vander Schueren for their help in preparing this document. Nandini Ganesh provided valuable feedback about the handling of TFO and the error codes. Yuchung Cheng and Praveen @@ -2177,20 +2205,21 @@ Authors' Addresses Olivier Bonaventure (editor) Tessares Email: Olivier.Bonaventure@tessares.net Mohamed Boucadair (editor) Orange + Clos Courtel Rennes 35000 France Email: mohamed.boucadair@orange.com Sri Gundavelli Cisco Email: sgundave@cisco.com