draft-ietf-tcpm-converters-09.txt   draft-ietf-tcpm-converters-10.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: January 23, 2020 Orange Expires: February 2, 2020 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
July 22, 2019 August 01, 2019
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-09 draft-ietf-tcpm-converters-10
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.
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 January 23, 2020. This Internet-Draft will expire on February 2, 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 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . 8
3.3. Sample Examples of Outgoing Converter-Assisted Multipath 3.3. Sample Examples of Outgoing Converter-Assisted Multipath
TCP Connections . . . . . . . . . . . . . . . . . . . . . 12 TCP Connections . . . . . . . . . . . . . . . . . . . . . 12
3.4. Sample Example of Incoming Converter-Assisted Multipath 3.4. Sample Example of Incoming Converter-Assisted Multipath
TCP Connection . . . . . . . . . . . . . . . . . . . . . 13 TCP Connection . . . . . . . . . . . . . . . . . . . . . 13
4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 14 4. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 15
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 15
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 16
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 16
4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17 4.2.3. The Info TLV . . . . . . . . . . . . . . . . . . . . 17
4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 17 4.2.4. Supported TCP Extensions TLV . . . . . . . . . . . . 18
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 18 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 19
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 20 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 21
4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21 4.2.7. The Cookie TLV . . . . . . . . . . . . . . . . . . . 21
4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 21 4.2.8. Error TLV . . . . . . . . . . . . . . . . . . . . . . 22
5. Compatibility of Specific TCP Options with the Conversion 5. Compatibility of Specific TCP Options with the Conversion
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 25
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 26
5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 26
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 27
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 27
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 27
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 28
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 28
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 29
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 31
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 31
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 31 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 32
8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 32 8.2. The Convert Protocol (Convert) Parameters . . . . . . . . 33
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 32 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 33
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 33
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 33 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Example Socket API Changes to Support the 0-RTT Appendix B. Example Socket API Changes to Support the 0-RTT
Convert Protocol . . . . . . . . . . . . . . . . . . 41 Convert Protocol . . . . . . . . . . . . . . . . . . 42
B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 41 B.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 42
B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42 B.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 42
Appendix C. Differences with SOCKSv5 . . . . . . . . . . . . . . 43 Appendix C. Some Design Considerations . . . . . . . . . . . . . 43
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix D. Differences with SOCKSv5 . . . . . . . . . . . . . . 44
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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 Acknowledgements [RFC2018] or large
skipping to change at page 6, line 9 skipping to change at page 6, line 13
Configuration means are outside the scope of this document. Configuration means are outside the scope of this document.
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 provides a protocol described in this document. Appendix C records some
comparison with SOCKS proxies that are already used to deploy considerations that impacted the design of the protocol. Appendix D
Multipath TCP in some cellular networks (Section 2.2 of [RFC8041]). provides a comparison with SOCKS proxies that are already used to
deploy Multipath TCP in some cellular networks (Section 2.2 of
[RFC8041]).
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The information shown between brackets in the figures refers to The information shown between brackets in the figures refers to
Convert Protocol messages described in Section 4. Convert Protocol messages described in Section 4.
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;
skipping to change at page 6, line 45 skipping to change at page 7, line 5
A Transport Converter is a network function that relays all data A Transport Converter is a network function that relays 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" 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). Also, the "Client" can accept incoming +------------+
connections via a Transport Converter (referred to as incoming Client <- upstream ->| Transport |<- downstream ->Server
connections). Nevertheless, and unless this is explicitly stated, | Converter |
the description assumes outgoing connections as default. +------------+
|
| customer-facing interface : Internet-facing interface
: |
|
+------------+
client <- upstream ->| Transport |<- downstream ->server
| Converter |
+------------+
|
customer-facing interface : Internet-facing interface
|
Figure 1: A Transport Converter Relays Data between Pairs of TCP Figure 1: A Transport Converter Relays Data between Pairs of TCP
Connections 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 Transport Converters can be operated by network operators or third
parties. Nevertheless, this document focuses on the single parties. Nevertheless, this document focuses on the single
administrative deployment case where the entity offering the administrative deployment case where the entity offering the
connectivity service to a client is also the entity which owns and connectivity service to a client is also the entity which owns and
operates the Transport Converter. operates the Transport Converter.
A Transport Converter can be embedded in a standalone device or be A Transport Converter can be embedded in a standalone device or be
activated as a service on a router. How such function is enabled is activated as a service on a router. How such function is enabled is
deployment-specific. A sample deployment is depicted in Figure 2. deployment-specific. A sample deployment is depicted in Figure 2.
skipping to change at page 9, line 38 skipping to change at page 9, line 40
used), the Client initiates a connection towards the Transport used), the Client initiates a connection towards the Transport
Converter and indicates the IP address and port number of the Server Converter and indicates the IP address and port number of the Server
within the connection establishment packet. Doing so enables the within the connection establishment packet. Doing so enables the
Transport Converter to immediately initiate a connection towards that Transport Converter to immediately initiate a connection towards that
Server, without experiencing an extra delay. The Transport Converter Server, without experiencing an extra delay. The Transport Converter
waits until the receipt of the confirmation that the Server agrees to waits until the receipt of the confirmation that the Server agrees to
establish the connection before confirming it to the Client. establish the connection before confirming it to the Client.
The Client places the destination address and port number of the The Client places the destination address and port number of the
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. In accordance with minimize connection establishment delays. The Transport Converter
[RFC1919], the Transport Converter maintains two connections that are maintains two connections that are combined together:
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.
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 relayed 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 relayed 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
sharing modes as discussed in 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 Figure 5 illustrates the establishment of an outgoing TCP connection
by a Client through a Transport Converter. by a Client through a Transport Converter.
Transport Transport
Client Converter Server Client Converter Server
| | | | | |
|SYN [->Server:port]| SYN | |SYN [->Server:port]| SYN |
|------------------>|--------------------->| |------------------>|--------------------->|
|<------------------|<---------------------| |<------------------|<---------------------|
| SYN+ACK [ ] | SYN+ACK | | SYN+ACK [ ] | SYN+ACK |
| | | | ... | ... |
Figure 5: Establishment of an Outgoing TCP Connection Through a Figure 5: Establishment of an Outgoing TCP Connection Through a
Transport Converter (1) 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. This information is sent at the beginning of the bytestream, Server.
either directly in the SYN+ACK or in a subsequent packet. For
graphical reasons, the figures in this section show that the
Transport Converter returns this information in the SYN+ACK packet.
An implementation could also place this information in a packet that
it sent shortly after the SYN+ACK.
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 is successful,
the Converter inserts the source IP address and source port number in 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 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 (i.e., only when the Converter is
in accordance with any information stored locally. That SYN is then configured in an address sharing mode), the destination IP address
forwarded to the next hop. SYN-ACK and ACK will be then exchanged and port number in accordance with any information stored locally.
between the Client, the Converter, and remote host to confirm the That SYN is then forwarded to the next hop. SYN+ACK and ACK will be
establishment of the connection. then exchanged between the Client, the Converter, and remote host to
confirm the establishment of 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 |
| ... | ... | | ... | ... |
Figure 6: Establishment of an Incoming TCP Connection Through a Figure 6: Establishment of an Incoming TCP Connection Through a
Transport Converter Transport Converter
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 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.
Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
data inside its payload but forbids the receiver from delivering it data inside its payload but forbids the receiver from delivering it
to the application until completion of the three-way-handshake. To to the application until completion of the three-way-handshake. To
enable applications to exchange data in a TCP handshake, this enable applications to exchange data in a TCP handshake, this
specification follows an approach similar to TCP Fast Open [RFC7413] specification follows an approach similar to TCP Fast Open [RFC7413]
and thus removes the constraint by allowing data in SYN packets to be and thus removes the constraint by allowing data in SYN packets to be
delivered to the Transport Converter application. delivered to the Transport Converter application.
As discussed in [RFC7413], such change to TCP semantic raises two As discussed in [RFC7413], such change to TCP semantic raises two
issues. First, duplicate SYNs can cause problems for some issues. First, duplicate SYNs can cause problems for some
skipping to change at page 12, line 4 skipping to change at page 11, line 51
the payload of SYN packets without creating additional security risks the payload of SYN packets without creating additional security risks
such as a network where addresses cannot be spoofed and the Transport such as a network where addresses cannot be spoofed and the Transport
Converter only serves a set of hosts that are identified by these Converter only serves a set of hosts that are identified by these
addresses. addresses.
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.
If the downstream (or upstream) connection fails for some reason If the downstream (or upstream) connection fails for some reason
(excessive retransmissions, reception of a 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 teardown 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
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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
connection towards this Server. Since the Server does not support connection towards this Server. Since the Server does not support
Multipath TCP, it replies with a SYN+ACK that does not contain the Multipath TCP, it replies with a SYN+ACK that does not contain the
MP_CAPABLE option. The Transport Converter notes that the connection MP_CAPABLE option. The Transport Converter notes that the connection
with the Server does not support Multipath TCP and returns the with the Server does not support Multipath TCP and returns the
extended TCP header received from the Server to the Client. extended TCP header received from the Server to the Client.
Note that, if the TCP connection fails for some reason, the Converter Note that, if the TCP connection fails for some reason, the Converter
tears down the Multipath TCP connection by transmitting a tears down the Multipath TCP connection by transmitting a
MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with MP_FASTCLOSE. Likewise, if the Multipath TCP connection ends with
the transmission of DATA_FINs, the Converter terminates the TCP the transmission of DATA_FINs, the Converter terminates the TCP
connection by using FIN segments. connection by using FIN segments. As a side note, given that with
Multipath TCP, RST only has the scope of the subflow and will only
close the concerned subflow but not affect the remaining subflows,
the Converter does not terminate the TCP connection upon receipt of
an RST over a Multipath subflow.
Figure 8 considers a Server that supports Multipath TCP. In this Figure 8 considers a Server that supports Multipath TCP. In this
case, it replies to the SYN sent by the Transport Converter with the case, it replies to the SYN sent by the Transport Converter with the
MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport MP_CAPABLE option. Upon reception of this SYN+ACK, the Transport
Converter confirms the establishment of the connection to the Client Converter confirms the establishment of the connection to the Client
and indicates to the Client that the Server supports Multipath TCP. and indicates to the Client that the Server supports Multipath TCP.
With this information, the Client has discovered that the Server With this information, the Client has discovered that the Server
supports Multipath TCP natively. This will enable the Client to supports Multipath TCP natively. This will enable the Client to
bypass the Transport Converter for the subsequent Multipath TCP bypass the Transport Converter for the subsequent Multipath TCP
connections that it will initiate towards this Server. connections that it will initiate towards this Server.
skipping to change at page 13, line 34 skipping to change at page 13, line 38
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
from remote hosts, the Client may use PCP [RFC6887] to instruct the from remote hosts, the Client may use PCP [RFC6887] to instruct the
skipping to change at page 14, line 18 skipping to change at page 14, line 23
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 an entry
is found, the Converter inserts an MP_CAPABLE option and Connect TLV 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 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 describes the messages that are exchanged between a This section defines the Convert protocol (Convert, for short)
Client and a Transport Converter. messages that are exchanged between a Client and a Transport
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 protocol (Convert, for short) messages from Clients. for Convert messages from Clients.
Clients send packets that are eligible to the conversion service to Clients send packets bound to connections eligible to the conversion
the provisioned Transport Converter using TBA as destination port service to the provisioned Transport Converter using TBA as
number. Additional information is supplied by Clients to the 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 Transport Converter by means of Convert messages as detailed in the
following sub-sections. following 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. A Convert message starts with a 32 bits long fixed bytestream. All Convert messages start 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).
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.
skipping to change at page 16, line 19 skipping to change at page 16, line 31
The Convert protocol uses variable length messages that are encoded The Convert protocol uses variable length messages that are encoded
using the generic TLV format depicted in Figure 11. using the generic TLV format depicted in Figure 11.
The length of all TLVs used by the Convert protocol is always a The length of all TLVs used by the Convert protocol is always a
multiple of four bytes. All TLVs are aligned on 32 bits boundaries. multiple of four bytes. All TLVs are aligned on 32 bits boundaries.
All TLV fields are encoded using the network byte order. All TLV fields are encoded using the network byte order.
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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type | Length | (optional) Value ... | | Type | Length | Value ... |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| ... Value | // ... (optional) Value //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 11: Convert Generic TLV Format Figure 11: Convert Generic TLV Format
The Length field is expressed in units of 32 bits words. If The Length field covers Type, Length, and Value fields. It is
necessary, Value MUST be padded with zeroes so that the length of the expressed in units of 32 bits words. If necessary, Value MUST be
TLV is a multiple of 32 bits. padded with zeroes so that the length of the TLV is a multiple of 32
bits.
A given TLV MUST only appear once on a connection. If two or more A given TLV MUST only appear once on a connection. If two or more
instances of the same TLV are exchanged over a Convert connection, instances of the same TLV are exchanged over a Convert connection,
the associated TCP connections MUST be closed. the associated TCP connections MUST be closed.
4.2.2. Summary of Supported Convert TLVs 4.2.2. Summary of Supported Convert TLVs
This document specifies the following Convert TLVs: This document specifies the following Convert TLVs:
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
skipping to change at page 19, line 15 skipping to change at page 19, line 41
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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type=0xA | Length | Remote Peer Port | | Type=0xA | Length | Remote Peer Port |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| | | |
| Remote Peer IP Address (128 bits) | | Remote Peer IP Address (128 bits) |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| TCP Options (Variable) | / TCP Options (Variable) /
| ... | / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
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 subfield, i.e.,
skipping to change at page 20, line 37 skipping to change at page 21, line 18
Converter to send to the Client the extended TCP header that was Converter to send to the Client the extended TCP header that was
returned by the Server in the SYN+ACK packet. This TLV is only sent returned by the Server in the SYN+ACK packet. This TLV is only sent
if the Client sent a Connect TLV to request the establishment of a if the Client sent a Connect TLV to request the establishment of a
connection. connection.
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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type=0x14 | Length | Unassigned | | Type=0x14 | Length | Unassigned |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Returned Extended TCP header | / Returned Extended TCP header /
| ... | / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 17: The Extended TCP Header TLV Figure 17: The Extended TCP Header TLV
The Returned Extended TCP header field is a copy of the extended The Returned Extended TCP header field is a copy of the extended
header that was received in the SYN+ACK by the Transport Converter. header that was received in the SYN+ACK by the Transport Converter.
The Unassigned field MUST be set to zero by the transmitter and The Unassigned field MUST be set to zero by the sender and ignored by
ignored by the receiver. These bits are available for future use the receiver. These bits are available for future use [RFC8126].
[RFC8126].
4.2.7. The Cookie TLV 4.2.7. The Cookie TLV
The Cookie TLV (Figure 18 is an optional TLV which use is similar to The Cookie TLV (Figure 18 is an optional TLV which use is similar to
the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want the TCP Fast Open Cookie [RFC7413]. A Transport Converter may want
to verify that a Client can receive the packets that it sends to to verify that a Client can receive the packets that it sends to
prevent attacks from spoofed addresses. This verification can be prevent attacks from spoofed addresses. This verification can be
done by using a Cookie that is bound to, for example, the IP done by using a Cookie that is bound to, for example, the IP
address(es) of the Client. This Cookie can be configured on the address(es) of the Client. This Cookie can be configured on the
Client by means that are outside of this document or provided by the Client by means that are outside of this document or provided by the
skipping to change at page 21, line 41 skipping to change at page 22, line 17
to reestablish a new connection to the Transport Converter that to reestablish a new connection to the Transport Converter that
includes the Cookie TLV. includes the Cookie TLV.
The format of the Cookie TLV is shown in Figure 18. The format of the Cookie TLV is shown in Figure 18.
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
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Type=0x16 | Length | Zero | | Type=0x16 | Length | Zero |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| Opaque Cookie | / Opaque Cookie /
| ... | / ... /
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 18: The Cookie TLV Figure 18: The Cookie TLV
4.2.8. Error TLV 4.2.8. Error TLV
The Error TLV (Figure 19) is meant to provide information about some The Error TLV (Figure 19) is meant to provide information about some
errors that occurred during the processing of a Convert message. errors that occurred during the processing of a Convert message.
This TLV has a variable length. It appears after the Convert fixed- This TLV has a variable length. Upon reception of an Error TLV, a
header in the bytestream returned by the Transport Converter. Upon Client MUST close the associated connection.
reception of an Error TLV, a Client MUST close the associated
connection.
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
+---------------+---------------+----------------+--------------+ +---------------+---------------+----------------+--------------+
| Type=0x1E | Length | Error Code | Value | | Type=0x1E | Length | Error Code | Value |
+---------------+---------------+----------------+--------------+ +---------------+---------------+----------------+--------------+
// ... (optional) Value //
+---------------------------------------------------------------+
Figure 19: The Error TLV Figure 19: The Error TLV
Different types of errors can occur while processing Convert Different types of errors can occur while processing Convert
messages. Each error is identified by an Error Code represented as messages. Each error is identified by an Error Code represented as
an unsigned integer. Four classes of error codes are defined: an unsigned integer. Four classes of error codes are defined:
o Message validation and processing errors (0-31 range): returned o Message validation and processing errors (0-31 range): returned
upon reception of an invalid message (including valid messages but upon reception of an invalid message (including valid messages but
with invalid or unknown TLVs). with invalid or unknown TLVs).
skipping to change at page 29, line 15 skipping to change at page 29, line 24
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 acknowledgement 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 the The case of a middlebox that removes the payload of SYN+ACKs (but not
payload of SYN) can be detected by a Client. This is hinted by the the payload of SYN) can be detected by a Client. This is hinted by
absence of an Error or Extended TCP Header TLV in a response. If an the absence of an Error or Extended TCP Header TLV in a response. If
Error was returned by the Transport Converter, a message to close the an Error was returned by the Transport Converter, a message to close
connection would normally follow from the Converter. If no such the connection would normally follow from the Converter. If no such
message is received, the Client may continue to use this Converter. message is received, the Client may continue to use this Converter.
As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect As explained in [RFC7413], some CGNs (Carrier Grade NATs) can affect
the operation of TFO if they assign different IP addresses to the the operation of TFO if they assign different IP addresses to the
same end host. Such CGNs could affect the operation of the cookie same end host. Such CGNs could affect the operation of the cookie
validation used by the Convert Protocol. As a reminder CGNs, enabled validation used by the Convert Protocol. As a reminder CGNs, enabled
on the path between a Client and a Transport Converter, must adhere on the path between a Client and a Transport Converter, must adhere
to the address preservation defined in [RFC6888]. See also the to the address preservation defined in [RFC6888]. See also the
discussion in Section 7.1 of [RFC7413]. discussion in Section 7.1 of [RFC7413].
skipping to change at page 43, line 5 skipping to change at page 43, line 37
However, this configuration is system-wide. This is convenient for However, this configuration is system-wide. This is convenient for
typical Transport Converter deployments where no other applications typical Transport Converter deployments where no other applications
relying on TFO are collocated on the same device. relying on TFO are collocated on the same device.
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. Differences with SOCKSv5 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
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
simplifies client implementations.
Appendix D. Differences with SOCKSv5
At a first glance, the solution proposed in this document could seem At a first glance, the solution proposed in this document could seem
similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP similar to the SOCKS v5 protocol [RFC1928] which is used to proxy TCP
connections. The Client creates a connection to a SOCKS proxy, connections. The Client creates a connection to a SOCKS proxy,
exchanges authentication information and indicates the destination exchanges authentication information and indicates the destination
address and port of the final server. At this point, the SOCKS proxy address and port of the final server. At this point, the SOCKS proxy
creates a connection towards the final server and relays all data creates a connection towards the final server and relays all data
between the two proxied connections. The operation of an between the two proxied connections. The operation of an
implementation based on SOCKSv5 is illustrated in Figure 23. implementation based on SOCKSv5 is illustrated in Figure 23.
 End of changes. 46 change blocks. 
105 lines changed or deleted 132 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/