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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/