--- 1/draft-ietf-tcpm-converters-18.txt 2020-03-22 03:13:19.549137126 -0700 +++ 2/draft-ietf-tcpm-converters-19.txt 2020-03-22 03:13:19.689140708 -0700 @@ -1,25 +1,25 @@ TCPM Working Group O. Bonaventure, Ed. Internet-Draft Tessares Intended status: Experimental M. Boucadair, Ed. -Expires: September 7, 2020 Orange +Expires: September 22, 2020 Orange S. Gundavelli Cisco S. Seo Korea Telecom B. Hesmans Tessares - March 06, 2020 + March 21, 2020 0-RTT TCP Convert Protocol - draft-ietf-tcpm-converters-18 + draft-ietf-tcpm-converters-19 Abstract This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion @@ -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 September 7, 2020. + This Internet-Draft will expire on September 22, 2020. Copyright Notice Copyright (c) 2020 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 @@ -66,21 +66,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Network-Assisted Connections: The Rationale . . . . . . . 4 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 2. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 6 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 8 4. Architecture & Behaviors . . . . . . . . . . . . . . . . . . 9 4.1. Functional Elements . . . . . . . . . . . . . . . . . . . 9 - 4.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 10 + 4.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 11 4.3. Data Processing at the Transport Converter . . . . . . . 14 4.4. Address Preservation vs. Address Sharing . . . . . . . . 16 4.4.1. Address Preservation . . . . . . . . . . . . . . . . 16 4.4.2. Address/Prefix Sharing . . . . . . . . . . . . . . . 17 5. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Outgoing Converter-Assisted Multipath TCP Connections . . 18 5.2. Incoming Converter-Assisted Multipath TCP Connection . . 20 6. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 21 6.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 22 6.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 23 @@ -99,56 +99,56 @@ 7.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 34 7.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 34 7.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 35 7.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 35 7.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 35 7.7. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. Interactions with Middleboxes . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 37 9.2. Authentication and Authorization Considerations . . . . . 38 - 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 39 + 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 40 9.5. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 40 10.2. The Convert Protocol (Convert) Parameters . . . . . . . 41 10.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 41 10.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 42 10.2.3. Convert Error Messages . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Example Socket API Changes to Support the 0-RTT Convert Protocol . . . . . . . . . . . . . . . . . . 48 A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 48 A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 - Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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 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 + Internet. Experience with the latter class of 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 Acknowledgments, 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 @@ -180,21 +180,22 @@ 1.2. Network-Assisted Connections: The Rationale This document specifies an application proxy, called Transport Converter. A Transport Converter is a function that is installed by a network operator to aid the deployment of TCP extensions and to provide the benefits of such extensions to clients in particular. A Transport Converter may provide conversion service for one or more TCP extensions. Which TCP extensions are eligible to the conversion service is deployment-specific. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert), that is an - application-layer protocol which uses a specific TCP port number. + application-layer protocol which uses a specific TCP port number on + the Converter. The Convert Protocol provides Zero Round-Trip Time (0-RTT) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Particularly, the Convert Protocol does not require extra signaling setup delays before making use of the conversion service. The Convert Protocol does not require any encapsulation (no tunnels, whatsoever). The Transport Converter adheres to the main steps drawn in Section 3 of [RFC1919]. In particular, a Transport Converter achieves the @@ -262,23 +263,24 @@ described in this document. 1.3. Applicability Scope 0-RTT TCP Convert Protocol specified in this document MUST be used in a single administrative domain deployment model. That is, the entity offering the connectivity service to a client is also be entity which owns and operates the Transport Converter, with no transit over a third-party network. - Deployment of Transport Converters by third parties MUST adhere to - the mutual authentication requirements in Section 9.2 to prevent - illegitimate traffic interception (Section 9.4), in particular. + Future deployment of Transport Converters by third parties MUST + adhere to the mutual authentication requirements in Section 9.2 to + prevent illegitimate traffic interception (Section 9.4), in + particular. 2. Differences with SOCKSv5 Several IETF protocols provide proxy services; the closest to the 0-RTT Convert protocol being the SOCKSv5 protocol [RFC1928]. This protocol is already used to deploy Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]). A SOCKS Client creates a connection to a SOCKS Proxy, exchanges authentication information, and indicates the IP address and port @@ -362,21 +364,25 @@ Client is rejected as well. This feature is important for applications that check the availability of a Server or use the time to connect as a hint on the selection of a Server [RFC8305]. A fourth difference is that the 0-RTT Convert protocol only allows the Client to specify the IP address/port number of the destination server and not a DNS name. We evaluated an alternate design 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. + Converter to handle and manage DNS resolution requests. Note that + the name resolution at the Converter may fail (e.g., private names + discussed in Section 2.1 of [RFC6731]) or may not match the one that + would be returned by a Client's resolution library (e.g., Section 2.2 + of [RFC6731]). 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. 4. Architecture & Behaviors @@ -592,38 +597,38 @@ Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry data inside its payload but forbids the receiver from delivering it to the application until completion of the three-way-handshake. To enable applications to exchange data in a TCP handshake, this specification follows an approach similar to TCP Fast Open [RFC7413] and thus removes the constraint by allowing data in SYN packets to be delivered to the Transport Converter application. As discussed in [RFC7413], such change to TCP semantic raises two - issues. First, duplicate SYNs can cause problems for some - applications that rely on TCP. Second, TCP suffers from SYN flooding - attacks [RFC4987]. TFO solves these two problems for applications - that can tolerate replays by using the TCP Fast Open option that - includes a cookie. However, the utilization of this option consumes - space in the limited TCP header. Furthermore, there are situations, - as noted in Section 7.3 of [RFC7413] where it is possible to accept - the payload of SYN packets without creating additional security risks - such as a network where addresses cannot be spoofed and the Transport - Converter only serves a set of hosts that are identified by these - addresses. + issues. First, duplicate SYNs can cause problems for applications + that rely on TCP; whether or not a given application is affected + dependes on the details of that application protocol. Second, TCP + suffers from SYN flooding attacks [RFC4987]. TFO solves these two + problems for applications that can tolerate replays by using the TCP + Fast Open option that includes a cookie. However, the utilization of + this option consumes space in the limited TCP header. Furthermore, + there are situations, as noted in Section 7.3 of [RFC7413] where it + is possible to accept the payload of SYN packets without creating + additional security risks such as a network where addresses cannot be + spoofed and the Transport Converter only serves a set of hosts that + are identified by these addresses. 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 TCP header. - Furthermore, this design allows for the use of longer cookies than [RFC7413]. If the downstream (or upstream) connection fails for some reason (excessive retransmissions, reception of an RST segment, etc.), then the Converter reacts by forcing the tear-down of the upstream (or downstream) connection. In particular, if an ICMP error message that indicates a hard error is received on the downstream connection, the Converter echoes the Code field of that ICMP message in a Destination Unreachable Error TLV (see Section 6.2.8) that it transmits to the @@ -627,23 +632,23 @@ indicates a hard error is received on the downstream connection, the Converter echoes the Code field of that ICMP message in a Destination Unreachable Error TLV (see Section 6.2.8) that it transmits to the Client. Note that if an ICMP error message that indicates a soft error is received on the downstream connection, the Converter will retransmit the corresponding data until it is acknowledged or the connection times out. A classification of ICMP soft and hard errors is provided in Table 1 of [RFC5461]. The same reasoning applies when the upstream connection ends with an - exchange of FIN packets. In this case, the Converter will also - terminate the downstream connection by using FIN packets. If the - downstream connection terminates with the exchange of FIN packets, + exchange of FIN segments. In this case, the Converter will 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. 4.3. Data Processing at the Transport Converter As mentioned in Section 4.2, the Transport Converter acts as a TCP proxy between the upstream connection (i.e., between the Client and the Transport Converter) and the downstream connection (i.e., between the Transport Converter and the Server). @@ -804,23 +809,23 @@ |dst:C src:Tc|dst:Te src:S| |<---------SYN/ACK------------|<-----SYN/ACK-----| | | | |src:C dst:Tc|src:Te dst:S| |------------ACK------------->|-------ACK------->| | | | | ... | ... | Legend: Tc: IP address used by the Transport Converter on the internal - relam. + realm. Te: IP address used by the Transport Converter on the external - relam. + realm. Figure 9: Address Sharing 5. Sample Examples 5.1. Outgoing Converter-Assisted Multipath TCP Connections As an example, let us consider how the Convert Protocol can help the deployment of Multipath TCP. We assume that both the Client and the Transport Converter support Multipath TCP, but consider two different @@ -1245,22 +1250,21 @@ | ... | +---------------------------------------------------------------+ Figure 20: The TCP Options Field Upon reception of a Base Connect TLV, and absent any policy (e.g., rate-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. + connection. Upon reception of an Extended Connect TLV, a Transport Converter first checks whether it supports the TCP Options listed in the 'TCP Options' field. If not, it returns an error TLV set to "Unsupported TCP Option" (Section 6.2.8). If the above check succeeded 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 in the SYN that it sends to the Server the options listed in the 'TCP Options' sub-field and the TCP options that it would have used according to its local policies. @@ -1482,22 +1486,22 @@ Converter is experiencing a network failure to proxy the request. The Transport Converter MUST send this error code when it 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. + destination responded with an RST segment. The Value field MUST + be set to zero. o Destination Unreachable (97): This error indicates that an ICMP message indicating a hard error (e.g., destination unreachable, port unreachable, or network unreachable) was received by the Transport Converter. The Value field MUST echo the Code field of the received ICMP message. As a reminder, TCP implementations are supposed to act on an ICMP error message passed up from the IP layer, directing it to the connection that triggered the error using the demultiplexing @@ -1724,21 +1728,21 @@ Additional security considerations are discussed in the following sub-sections. 9.1. Privacy & Ingress Filtering The Transport Converter may have access to privacy-related information (e.g., subscriber credentials). The Transport Converter is designed to not leak such sensitive information outside a local domain. - Given its function and location in the network, a Transport Convert + Given its function and location in the network, a Transport Converter is in a position to observe all packets that it processes, to include payloads and meta-data; and has the ability to profile and conduct some traffic analysis of user behavior. The Transport Converter MUST be as protected as a core IP router (e.g., Section 10 of [RFC1812]). Furthermore, ingress filtering policies MUST be enforced at the network boundaries [RFC2827]. This document assumes that all network attachments are managed by the same administrative entity. Therefore, enforcing anti-spoofing @@ -1754,21 +1758,25 @@ use the Convert Protocol. One possibility for mutual authentication is to use TLS to perform mutual authentication between the client and the Converter. That is, use TLS when a Client retrieves a Cookie from the Converter and rely on certificate-based client authentication, pre-shared key based [RFC4279] or raw public key based client authentication [RFC7250] to secure this connection. If the authentication succeeds, the Converter returns a cookie to the Client. Subsequent Connect messages will be authorized as a function of the content of the - Cookie TLV. + Cookie TLV. An attacker from within the network between a Client and + a Transport Converter may intercept the Cookie and use it to be + granted access to the conversion service. Such attack is only + possible if the attacker spoofs the IP address of the Client and the + network does not filter packets with source spoofed IP addresses. The operator that manages the various network attachments (including the Transport Converters) has various options for enforcing authentication and authorization policies. For example, a non- exhaustive list of methods to achieve authorization is provided hereafter: o The network provider may enforce a policy based on the International Mobile Subscriber Identity (IMSI) to verify that a user is allowed to benefit from the TCP converter service. If @@ -1833,22 +1840,23 @@ To mitigate such attacks, the Transport Converter SHOULD rate limit the number of pending requests for a given Client. It SHOULD also avoid sending to remote Servers SYNs that are significantly longer than the SYN received from the Client. Finally, the Transport Converter SHOULD only retransmit a SYN to a Server after having received a retransmitted SYN from the corresponding Client. Means to protect against SYN flooding attacks should also be enabled (e.g., Section 3 of [RFC4987]). Attacks from within the network between a Client and a Transport - Converter are yet another actual threat. Means to ensure that - illegitimate nodes cannot connect to a network should be implemented. + Converter (including attacks that change the protocol version) are + yet another threat. Means to ensure that illegitimate nodes cannot + connect to a network should be implemented. 9.4. Traffic Theft Traffic theft is a risk if an illegitimate Converter is inserted in the path. Indeed, inserting an illegitimate Converter in the forwarding path allows traffic interception and can therefore provide access to sensitive data issued by or destined to a host. Converter discovery and configuration are out of scope of this document. 9.5. Logging @@ -2170,20 +2177,25 @@ [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, . [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, . + [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved + Recursive DNS Server Selection for Multi-Interfaced + Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, + . + [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, . [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, .