0-RTT TCP Convert ProtocolTessaresOlivier.Bonaventure@tessares.netOrangemohamed.boucadair@orange.comProximusbart.peirens@proximus.comKorea Telecomsh.seo@kt.comMemphis Universitynndugudi@memphis.edu
Transport
TCPM Working GroupInternet-DraftThis document specifies an application proxy, called Transport Converter, to
assist the deployment of TCP extensions such as Multipath TCP.
This proxy is designed to avoid inducing extra delay when involved in
a network-assisted connection (that is, 0-RTT).
This specification assumes an explicit model, where the proxy is explicitly configured on hosts.— Editorial Note (To be removed by RFC Editor)Please update these statements with the RFC number to be assigned to this document:
[This-RFC]Please update TBA statements with the port number to be assigned to
the Converter Protocol.Transport protocols like TCP evolve regularly . TCP has been improved in different
ways. Some improvements such as changing the initial window size or modifying the
congestion control scheme can be applied independently on clients and servers.
Other improvements such as Selective Acknowledgements or large windows require
a new TCP option or to change the semantics of some fields in the TCP header. These modifications must
be deployed on both clients and servers to be actually used on the Internet.
Experience with the latter TCP extensions reveals that their deployment can
require many years. reports results of a decade of measurements showing
the deployment of Selective Acknowledgements, Window Scale and TCP Timestamps. describes
measurements showing that TCP Fast Open (TFO) is still not widely deployed.There are some situations where the transport stack used on clients (resp. servers)
can be upgraded at a faster pace than the transport stack running on servers (resp.
clients). In those situations, clients would typically want to benefit from the
features of an improved transport protocol even if the servers have not yet been
upgraded and conversely. In the past, Performance Enhancing Proxies have been
proposed and deployed as solutions to improve TCP performance over
links with specific characteristics.Recent examples of TCP extensions include Multipath TCP
or TCPINC . Those extensions
provide features that are interesting for clients such as wireless devices.
With Multipath TCP, those devices could seamlessly use WLAN and cellular networks,
for bonding purposes, faster handovers, or better resiliency.
Unfortunately, deploying those extensions on both a wide range of clients and
servers remains difficult.More recently, experimentation of 5G bonding, which has very scarce coverage, has been conducted
into global range of the incumbent 4G (LTE) connectivity in newly devised clients using Multipath TCP proxy.
Even if the 5G and the 4G bonding by using Multipath TCP increases the bandwidth to data transfer, it is
as well crucial to minimize latency for all the way between endhosts regardless of whether intermediate nodes
are inside or ouside of the mobile core.
In order to handle uRLLC (Ultra-Reliable Low-Latency Communication) for the next generation
mobile network, Multipath TCP and its proxy mechanism must be optimized to reduce latency.This document specifies an application proxy, called Transport Converter. A
Transport Converter is a function that is installed by a network
operator to aid the deployment of TCP extensions and to provide the benefits of such extensions to clients.
A Transport Converter may support conversion service for one or more TCP extensions.
This service is provided by means of the Converter Protocol (Convert), that is an application layer protocol
which uses TBA TCP port number ().The Transport Converter adheres to the main principles as drawn in . In particular, the Converter achieves the following:Listen for client sessions;Receive from a client the address of the final target server;Setup a session to the final server;Relay control messages and data between the client and the server;Perform access controls according to local policies.The main advantage of network-assisted Converters is that they enable new TCP extensions to be used on
a subset of the end-to-end path, which encourages the deployment of these extensions. The
Transport Converter allows the client and the server to directly negotiate TCP options.The Convert Protocol is a generic mechanism to provide 0-RTT conversion service.
As a sample applicability use case, this document specifies how the Convert Protocol
applies for Multiptah TCP. It is out of scope of this document to provide a comprehensive
list of potential all conversion services; separate documents may be edited in
the future for other conversion services upon need.This document does not assume that all the traffic is eligible to the network-assisted conversion service. Only a subset of the traffic will be forwarded to a Converter according to a set of policies. Furthermore, it is possible to bypass the Converter to connect to the servers that already support the required TCP extension.This document assumes that a client is configured with one or a list of Converters. Configuration means are outside the scope of this document.This document is organized as follows. We first provide a brief explanation of the
operation of Transport Converters in . We describe the Converter
Protocol in . We discuss in how Transport
Converters can be used to support different TCP options.
We then discuss the interactions with middleboxes
() and the security considerations ().Appendix A provides a comparison with SOCKS proxies that are already
used to deploy Multipath TCP in some cellular networks.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
when, and only when, they appear in all capitals,
as shown here.The architecture considers three types of endhosts:Client endhosts;Transport Converters;Server endhosts.A Transport Converter is a network function that relays all data exchanged over one
upstream connection to one downstream connection and vice versa ().
The Converter, thus, maintains state that associates one upstream connection to
a corresponding downstream connection.A connection can be initiated from both sides of the Transport Converter (Internet-facing interface, client-facing interface).Transport Converters can be operated by network operators or
third parties. Nevertheless, this document focuses on the single administrative deployment case where the entity offering the connectivity service to a client is also the entity which owns and operates the Transport Converter.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 deployment-specific ().The architecture assumes that
new software will be installed on the Client hosts and on Transport Converters.
Further, the architecture allows for making use of TCP new extensions if those are supported by a given server.The Client is configured, through means that are outside the
scope of this document,
with the names and/or the addresses of one or more Transport Converters.The architecture does not mandate anything on the server side.One of the benefits of this design
is that different transport protocol extensions can be used on the upstream
and the downstream connections. This encourages the deployment of new TCP extensions
until they are widely supported by servers.At a high level, the objective of the Transport Converter is to allow the
Client to use a specific extension, e.g. Multipath TCP, on a subset of
the end-to-end path even if the Server does not support this extension.
This is illustrated in where the Client initiates a
Multipath TCP connection with the Converter (Multipath packets are shown
with "===") while the Converter uses a regular TCP connection with the Server.The
packets belonging to the pair of connections between the Client and Server
passing through a Transport Converter
may follow a different path than the packets directly exchanged between the
Client and the Server. Deployments should minimize the possible additional delay
by carefully selecting the location of the Transport Converter used to reach a
given destination.When establishing a connection, the Client can, depending on local policies,
either contact the Server directly (e.g., by sending a TCP SYN towards the Server)
or create the connection via a Transport Converter. In the latter case, which is the case we consider in this document, the Client
initiates a connection towards the Transport Converter and indicates the IP address and port number of
the ultimate Server inside the connection establishment packet. Doing so enables the Transport Converter to immediately initiate
a connection towards that Server, without experiencing an extra delay. The Transport Converter waits until the
confirmation that the Server agrees to establish the connection before confirming
it to the Client.The client places the
destination address and port number of the target Server in the payload of the SYN sent to the Converter by
leveraging TCP Fast Open . In accordance with , the Transport Converter
maintains two connections that are combined together:the upstream connection is the one between the Client and the Transport Converter.the downstream connection is between the Transport Converter and the remote Server.Any user data received by the Transport Converter over the upstream (resp., downstream)
connection is relayed over the downstream (resp., upstream) connection. illustrates the
establishment of a TCP connection by the Client through a Transport Converter. The
information shown between brackets is part of the Converter Protocol
described later in this document.The Client sends a SYN destined to the Transport Converter. This SYN contains a
TFO cookie and inside its payload the addresses and ports of the destination
Server. The Transport Converter does not reply immediately to this SYN. It
first tries to create a TCP connection towards the destination Server. If this
second connection succeeds, the Transport Converter confirms the establishment ofthe connection to the Client by returning a SYN+ACK and the first bytes of
the bytestream contain information about the TCP options that were negotiated
with the final Server. This information
is sent at the beginning of the bytestream, either directly in the SYN+ACK or in
a subsequent packet. For graphical reasons, the figures in this section show
that the 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 Client via a Transport Converter.
This is typically the case when the Client embeds a server (video server, for example).The procedure described in assumes that the Client has obtained a TFO cookie
from the Transport Converter. This is part of the Bootstrap procedure which is illustrated
in . The Client sends a SYN with a TFO request option to obtain a
valid cookie from the Converter. The Converter replies with a TFO cookie in the SYN+ACK.
Once this connection has been established, the Client sends a Bootstrap message to request
the list of TCP options for which the Transport Converter provides a conversion service.Note that the Converter may rely on local policies to decide whether it can service a given
requesting Client. That is, the Converter will not return a cookie for that Client. How such policies are supplied to the Converter are out of scope.Also, the Converter may behave in a cookie-less mode when appropriate means are enforced
at the Converter and the network in-between to protect against attacks such as spoofing
and SYN flood. Under such deployments, the use of TFO is not required.As an example (), let us consider how the Convert protocol can help the deployment of
Multipath TCP . We assume that both the Client and the Transport
Converter support Multipath TCP, but consider two different cases depending
whether the Server supports Multipath TCP or not. A Multipath TCP connection is created
by placing the MP_CAPABLE (MPC) option in the SYN sent by the Client. describes the operation of the Transport Converter
if the Server does not support Multipath TCP.The Client tries to initiate a Multipath TCP connection by sending a SYN with the
MP_CAPABLE option (MPC in ). The SYN includes the address and port number
of the final Server and the Transport Converter attempts to initiate a Multipath TCP
connection towards this Server. Since the Server does not support Multipath TCP, it
replies with a SYN+ACK that does not contain the MP_CAPABLE option. The Transport
Converter notes that the connection with the Server does not support Multipath TCP
and returns the TCP options received from the Server to the Client. considers a Server that supports Multipath TCP. In this case, it
replies to the SYN sent by the Transport Converter with the MP_CAPABLE option.
Upon reception of this SYN+ACK, the Transport Converter confirms the establishment
of the connection to the Client and indicates to
the Client that the Server supports Multipath TCP. With this information,
the Client has discovered that the Server supports Multipath TCP
natively. This will enable it to bypass the Transport Converter for the next
Multipath TCP connection that it will initiate towards this Server.An example of an incoming Converter-assisted Multipath TCP connection is depicted
in . In order to support incoming connections from remote hosts,
the Client may use PCP to instruct the Converter to create dynamic
mappings. Those mappings will be used by the Converter to intercept an incoming
TCP connection destined to the Client and convert it into a Multipath TCP connection.This section describes in details the messages that are exchanged between a Client and
a Transport Converter. The Converter Protocol (Convert, for short) leverages the TCP Fast Open
extension .The Converter Protocol uses a 32 bits long fixed header that is sent
by both the Client and the Transport Converter. This header indicates both
the version of the protocol used and the length of the Convert message.The Fixed Header is used to exchange information about the version and length of
the messages between the Client and the Transport Converter.The Client and the
Transport Converter MUST send the fixed-sized header shown in as
the first four bytes of the bytestream.The Version is encoded as an 8 bits unsigned integer value. This document specifies
version 1. Version 0 is reserved by this document and MUST NOT be used.The Total Length is the number of 32 bits word, including the
header, of the bytestream that are consumed by the Converter protocol messages.
Since Total Length is also an 8 bits unsigned integer, those messages cannot
consume more than 1020 bytes of data. This limits the number of bytes
that a Transport Converter needs to process. A
Total Length of zero is invalid and the connection MUST be reset upon
reception of such a header.The Unassigned field MUST be set to zero in this
version of the protocol. These bits are available for
future use .The Convert protocol uses variable length messages that are encoded using
the generic TLV format depicted in .
All TLV fields are encoded using the network byte order.A given TLV MUST only appear once on a connection. If two or more
instances of the same TLV are exchanged over a Converter connection, the associated
TCP connections MUST be closed.This document specifies the following Convert TLVs:To establish a connection via a Transport Converter, a Client MUST first obtain a valid
TFO cookie from that Converter. This is the bootstrap procedure during which the Client
opens a connection to the Transport Converter with an empty TFO option.
According to , the Transport Converter returns its cookie in the SYN+ACK.
Then the Client sends a Bootstrap TLV () to which
the Transport Converter replies with
the Supported TCP Extension Services TLV described in .With the TFO cookie of the Transport Converter, the Client can request
the establishment of connections to remote servers with the Connect TLV
(see ). If the connection can be established with the final server,
the Transport Converter replies with the Extended TCP Header TLV
and returns an Error TLV inside a RST packet
(see ).When the Transport Converter receives an incoming connection
establishment from a Client, it MUST process the TCP options found in
the SYN and the Connect TLV. In general, the Transport Converter
MUST add to the proxied SYN the TCP options that were included in the
Connect TLV. It SHOULD add to the proxied SYN the TCP options that
were included in the incoming SYN provided that it supports the
corresponding TCP extension.There are some exceptions to these rules given the semantics of some
TCP options. First, TCP options with Kinds 0 (EOL), 1 (NOP), 2
(MSS), and 3 (WS) MUST be used according to the configuration of the
TCP stack of the Transport Converter. The Timestamps option
(Kind=10) SHOULD be used in the proxied SYN if it was present in the
incoming SYN, but the contents of the option in the proxied SYN
SHOULD be set by the Converter's stack. The MP_CAPABLE option SHOULD
be added to the proxied SYN if it was present in the incoming SYN,
but the content of the option in the proxied SYN SHOULD be set by the
Converter's stack. The TCP Fast Open cookie option SHOULD be handled
as described in Section 6.As a general rule, when an error is encountered an Error TLV with the
appropriate error code MUST be returned.The Bootstrap TLV ( is sent by a Client to request the TCP extensions that are
supported by a Transport Converter and for which it provides a conversion
service. It is typically sent on the first connection
that a Client establishes with a Transport Converter to learn its
capabilities. Assuming a Client is entitled to invoke the Converter, this latter replies with the Supported TCP
Extensions Services TLV described in .The Supported TCP Extension Services TLV () is used by a Converter to announce the
TCP options for which it provides a conversion service.
Each supported TCP option is encoded
with its TCP option Kind listed in the "TCP Parameters" registry
maintained by IANA.TCP option Kinds 0, 1, and 2 defined in
are supported by all TCP implementations and thus MUST NOT
appear in this list.The list of Supported TCP Extension Services is padded with
0 to end on a 32 bits boundary.Typically, if the Converter only supports Multipath TCP conversion service, solely Kind=30 will be present in the Supported TCP Extension Services TLV returned by the Converter to a requesting Client.The Connect TLV () is used to request the establishment of a connection via a Transport Converter.The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain the destination port and IP address of the target server for an outgoing connection towards a server located on the Internet. For incoming connections destined to a client serviced via a Converter, these fields convey the source port and IP address.The Remote Peer IP Address MUST be encoded
as an IPv6 address. IPv4 addresses MUST be encoded using the
IPv4-Mapped IPv6 Address format defined in .The optional 'TCP Options' field is used to specify how specific TCP Options
should be advertised by the Transport Converter
to the final destination of a connection. If this field is not supplied, the Transport
Converter MUST use the default TCP options that correspond to its local
policy.The 'TCP Options' field is a variable length field that carries
a list of TCP option fields (). Each TCP option field is encoded as a
block of 2+n bytes where the first byte is the TCP
option Type and the second byte is the length of the TCP option
as specified in . The minimum value for the TCP option Length is 2.
The TCP options that do not include a length subfield, i.e., option types
0 (EOL) and 1 (NOP) defined in cannot be placed inside the
TCP options field of the Connect TLV. The optional Value field
contains the variable-length part of the TCP option. A length of two
indicates the absence of the Value field. The TCP options field
always ends on a 32 bits boundary after being padded with zeros.If a Transport Converter receives a Connect TLV with a non-empty TCP options
field, and the Converter accets to process the request, it SHALL present those options to the destination
peer in addition to the TCP options that it would have used according to its local
policies. For the
TCP options that are listed without an optional value, the Converter MUST generate its
own value. For the TCP options that are included in the 'TCP Options' field with
an optional value, it SHALL copy the entire option for use in the connection with the destination peer. This feature is required to support TCP Fast Open.The Converter may discard a Connect TLV request for many reasons (e.g., bad TFO cookie, authorization failed, out of resources). An error message indicating the encountered error is returned to the requesting Client . In order to prevent denial-of-service attacks, error messages sent to a Client SHOULD be rate-limited.The Extended TCP Header TLV () is used by the Transport 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 if the Client sent
a Connect TLV to request the establishment of a connection.The Returned Extended TCP header field is a copy of the extended header
that was received in the SYN+ACK by the Transport Converter.The Unassigned field MUST be set to zero by the transmitter and ignored by the
receiver. These bits are available for future use .The optional Error TLV () can be used by the Transport Converter to provide
information about some errors that occurred during the processing
of a request to convert a connection. This TLV appears after
the Convert header in a RST segment returned by the
Transport Converter if the error is fatal and prevented the
establishment of the connection. If the error is not fatal and
the connection could be established with the final destination, then
the error TLV will be carried in the payload.Different types of errors can occur while processing Convert
messages. Each error is identified by a code represented as an unsigned integer.
Four classes of errors are defined:Message validation and processing errors (0-31 range): returned upon reception of an an invalid message (including valid messages but with invalid or unknown TLVs).Client-side errors (32-63 range): the Client sent a request that could not be accepted by the Converter (e.g., unsupported operation).Converter-side errors (64-95 range) : problems encountered on the Converter (e.g., lack of resources) which prevent it from fulfilling the Client's request.Errors caused by destination server (96-127 range) : the final destination could not be reached or it replied with a reset message.The following error codes are defined in this document:Unsupported Version (0): The version number indicated in the fixed header of a message received from a peer is not supported.
This error code MUST be generated by a Converter when it receives a request having a version number that it does not support.
The value field MUST be set to the version supported by the Converter. When multiple versions are supported by the Converter, it includes the list of supported version in the value field; each version is encoded in 8 bits.
Upon receipt of this error code, the client checks whether it supports one of the versions returned by the Converter. The highest common supported version MUST be used by the client in subsequent exchanges with the Converter.Malformed Message (1): This error code is sent to indicate that a message can not be successfully parsed.
To ease troubleshooting, the value field MUST echo the received message. The Converter and the Client MUST send a RST containing this error upon reception of a malformed message.Unsupported Message (2): This error code is sent to indicate that a message type is not supported by the Converter.
To ease troubleshooting, the value field MUST echo the received message. The Converter and the Client MUST send a RST containing this error upon reception of an unsupported message.Not Authorized (32): This error code indicates that the Converter refused to create a connection because of a lack of authorization (e.g., administratively prohibited, authorization failure, etc.). The Value field MUST be set to zero.
This error code MUST be sent by the Converter when a request cannot be successfully processed because the authorization failed.Unsupported TCP Option (33): A TCP option that the Client requested to
advertise to the final Server cannot be safely used jointly with the conversion
service.
The Value field is set to the type of the unsupported
TCP option. If several unsupported TCP options were specified in the
Connect TLV, only one of them is returned in the Value.Resource Exceeded (64): This error indicates that the Transport Converter does
not have enough resources to perform the request.
This error MUST be sent by the Converter when it does not have sufficient resources to handle a new connection.Network Failure (65): This error indicates that the Converter is experiencing a network failure to relay the request.
The Converter MUST send this error code when it experiences forwarding issues to relay a connection.Connection Reset (96): This error indicates that the final
destination responded with a RST packet. The Value field MUST be set to zero.Destination Unreachable (97): This error indicates that an ICMP destination
unreachable, port unreachable, or network unreachable was received
by the Converter. The Value field MUST echo the Code
field of the received ICMP message.
This error message MUST be sent by the Converter when it receives an error message that is bound to a message it relayed previously. summarizes the different error codes.In this section, we discuss how several standard track TCP options can be
supported through the Converter. The non-standard track options and
the experimental options will be discussed in other documents.Three TCP options were initially defined in : End-of-Option List (Kind=0),
No-Operation (Kind=1) and Maximum Segment Size (Kind=2). The first two options are
mainly used to pad the TCP extended header. There is no reason for a client
to request a Converter to specifically send these options towards the
final destination.The Maximum Segment Size option (Kind=2) is used by a host to indicate the largest
segment that it can receive over each connection. This value is function of the
stack that terminates the TCP connection. There is no reason for a Client to request
a Converter to advertise a specific MSS value to a remote server.A Converter MUST ignore options with Kind=0, 1 or 2 if they appear
in a Connect TLV. It MUST NOT announce them in a Bootstrap TLV.The Window Scale option (Kind=3) is defined in . As for the MSS option, the
window scale factor that is used for a connection strongly depends on the TCP stack
that handles the connection. When a Converter opens a TCP connection towards a
remote server on behalf of a Client, it SHOULD use a WS option with a scaling factor
that corresponds to the configuration of its stack. A local configuration MAY allow for WS option in the proxied message to be function of the scaling
factor of the incoming connection.There is no benefit from a deployment viewpoint in enabling a Client of a Converter to
specifically request the utilisation of the WS option (Kind=3) with a specific
scaling factor towards a remote Server. For this reason, a Converter MUST ignore
option Kind=3 if it appears in a Connect TLV. It MUST NOT announce it in a Bootstrap TLV.Two distinct TCP options were defined to support selective acknowledgements in .
This first one, SACK Permitted (Kind=4), is used to negotiate the utilisation of selective
acknowledgements during the three-way handshake. The second one, SACK (Kind=5), carries
the selective acknowledgements inside regular segments.The SACK Permitted option (Kind=4) MAY be advertised by a Transport Converter in
the Bootstrap TLV. In this case, Clients connected to this Transport Converter MAY include
the SACK Permitted option in the Connect TLV.The SACK option (Kind=5) cannot be used during the three-way handshake. For this
reason, a Transport Converter MUST ignore
option Kind=5 with if it appears in a Connect TLV. It MUST NOT announce it in a Bootstrap TLV.The Timestamp option was initially defined in which has been replaced
by . It can be used during the three-way handshake to negotiate the utilisation
of the timestamps during the TCP connection. It is notably used to improve round-trip-time estimations
and to provide protection against wrapped sequence numbers (PAWS). As for the WS option,
the timestamps are a property of a connection and there is limited benefit in
enabling a client to request a Converter to use the timestamp option when establishing a
connection to a remote server. Furthermore, the timestamps that are used by TCP stacks
are specific to each stack and there is no benefit in enabling a client to specify the
timestamp value that a Converter could use to establish a connection to a remote server.A Transport Converter MAY advertise the Timestamp option (Kind=8) in the Bootstrap TLV. The clients
connected to this Converter MAY include the Timestamp option in the Connect TLV but without
any timestamp.The Multipath TCP options are defined in .
defines one variable length TCP option (Kind=30) that includes a
subtype field to support several Multipath TCP options. There are
several operational use cases where clients would like to use
Multipath TCP through a Converter . However, none of
these use cases require the Client to specify the content of
the Multipath TCP option that the Converter should send to a
remote server.A Transport Converter which supports Multipath TCP conversion service MUST advertise the Multipath TCP option (Kind=30) in the Bootstrap TLV. Clients
serviced by this Converter may include the Multipath TCP option in the Connect TLV but without
any content.The TCP Fast Open cookie option (Kind=34) is defined in . There are two different
usages of this option that need to be supported by Transport Converters.
The first utilisation of the Fast Open cookie is to request a cookie from the server.
In this case, the option is sent with an empty cookie by the client and the server returns
the cookie. The second utilisation of the Fast Open cookie is to send a cookie to the
server. In this case, the option contains a cookie.A Transport Converter MAY advertise the TCP Fast Open cookie option (Kind=34) in the Bootstrap TLV.
If a Transport Converter has advertised the support for TCP Fast Open in its Bootstrap TLV, it needs
to be able to process two types of Connect TLV. If such a Transport Converter receives a Connect TLV
with the TCP Fast Open cookie option that does not contain a cookie, it MUST add an empty
TCP Fast Open cookie option in the SYN sent to the remote server. If such a Transport Converter
receives a Connect TLV with the TCP Fast Open cookie option that contains a cookie, it MUST copy the
TCP Fast Open cookie option in the SYN sent to the remote server.The TCP User Timeout option is defined in . The associated
TCP option (Kind=28) does not appear to be widely deployed.Editor's Note: Feedback requested for the utilisation of this option by
deployed TCP stacks.TCP-AO provides a technique to authenticate all the
packets exchanged over a TCP connection. Given the nature of this
extension, it is unlikely that the applications that require their
packets to be authenticated end-to-end would want their connections
to pass through a converter. For this reason, we do not recommend
the support of the TCP-AO option by Transport Converters. The only
use cases where is makes sense to combine TCP-AO and the solution
in this document are those where the
TCP-AO-NAT extension is in use.A Converter MUST NOT advertise the TCP-AO option (Kind=29) in the Bootstrap TLV.
If a Converter receives a Connect TLV that contains the TCP-AO option,
it MUST reject the establishment of the connection with error code set to "Unsupported
TCP Option", except if the TCP-AO-NAT option is used.The TCP Experimental options are defined in . Given the variety of
semantics for these options and their experimental nature, it is impossible
to discuss them in details in this document.The Converter Protocol was designed to be used in networks that do not
contain middleboxes that interfere with TCP. We describe in this
section how a Client can detect middlebox interference and stop using
the Transport Converter affected by this interference.Internet measurements
have shown that middleboxes can affect the deployment of TCP extensions.
In this section, we only discuss the middleboxes
that modify SYN and SYN+ACK packets since the Converter Protocol places
its messages in such packets.Let us first consider a middlebox that removes the TFO Option from the SYN packet.
This interference will be detected by the Client during the bootstrap procedure
discussed in . A Client should not use a Transport Converter
that does not reply with the TFO option during the Bootstrap.Consider a middlebox that removes the SYN payload after the bootstrap
procedure. The Client can detect this problem by looking at the
acknowledgement number field of
the SYN+ACK returned by the Transport Converter.
The Client should stop to use this
Transport Converter given the middlebox interference.As explained in , some carrier-grade NATs can affect the operation of
TFO if they assign different IP addresses to the same end host. Such carrier-grade
NATs could affect the operation of the TFO Option used by the Converter Protocol.
See also the discussion in Section 7.1 of .The Converter may have access to privacy-related information (e.g., subscriber credentials).
The Converter MUST NOT leak such sensitive information outside a local domain.Given its function and its location in the network, a Transport Converter has
access to the payload of all the packets that it processes. As such, it MUST be protected as a core IP router (e.g., ).Furthermore, ingress filtering policies MUST be enforced at the network boundaries .This document assumes that all network attachments are managed by the same administrative entity. Therefore, enforcing anti-spoofing filters at these network ensures that hosts are not sending traffic with spoofed source IP addresses.The Converter Protocol is intended to be used in managed networks where end hosts
can be identified by their IP address. Thanks to the Bootstrap procedure,
the Transport Converter can verify that
the Client correctly receives packets sent by the Converter. Stronger authentication
schemes MUST be defined to use the Converter Protocol in more open network environments; such schemes are out of scope of this document.See below for authorization considerations that are specific for Multipath TCP.Another possible risk is the amplification attacks since a Transport Converter sends
a SYN towards a remote Server upon reception of a SYN from a Client. This could
lead to amplification attacks if the SYN sent by the Transport Converter were larger
than the SYN received from the Client or if the Transport Converter retransmits the
SYN. To mitigate such attacks, the Transport Converter SHOULD rate limit the number of
pending requests for a given Client. It SHOULD also avoid sending to remote Servers SYNs
that are significantly longer than the SYN received from the Client. In practice,
Transport Converters SHOULD NOT advertise to a Server TCP options that were not specified
by the Client in the received SYN. Finally, the Transport Converter SHOULD only retransmit
a SYN to a Server after having received a retransmitted SYN from the corresponding Client.Upon reception of a SYN that contains a valid TFO cookie and a Connect TLV, the
Transport Converter attempts to establish a TCP connection to a remote Server. There is a
risk of denial of service attack if a Client requests too many connections
in a short period of time. Implementations SHOULD limit the number of pending
connections from a given Client. Means to protect against SYN flooding
attacks MUST also be enabled .Traffic theft is a risk if an illegitimate Converter is inserted in the
path. Indeed, inserting an illegitimate Converter in the forwarding path
allows traffic interception and can therefore provide access to
sensitive data issued by or destined to a host. Converter discovery and configuration are out of scope of this document.Multipath TCP-related security threats are discussed in and
.The operator that manages the various network attachments
(including the Converters) can enforce authentication and authorization
policies using appropriate mechanisms. For example, a non-exhaustive
list of methods to achieve authorization is provided hereafter:The network provider may enforce a policy based on the
International Mobile Subscriber Identity (IMSI) to verify that a
user is allowed to benefit from the aggregation service. If that
authorization fails, the Packet Data Protocol (PDP) context/bearer
will not be mounted. This method does not require any
interaction with the Converter.The network provider may enforce a policy based upon Access
Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
to control the hosts that are authorized to communicate with
a Converter. These ACLs may be installed as a result of RADIUS exchanges,
e.g. . This method does not
require any interaction with the Converter.A device that embeds the Converter may also host a RADIUS client that
will solicit an AAA server to check whether connections received
from a given source IP address are authorized or not
.A first safeguard against the misuse of Converter resources by illegitimate
users (e.g., users with access networks that are not managed by the
same provider that operates the Converter) is the Converter to reject
Multipath TCP connections received on its Internet-facing interfaces. Only
Multipath PTCP connections received on the customer-facing interfaces of a Converter will
be accepted.IANA is requested to assign a TCP port number (TBA) for the Converter Protocol
from the "Service Name and Transport Protocol Port Number Registry" available at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.IANA is requested to create a new "The Converter Protocol (Convert)
Parameters" registry.The following subsections detail new registries within "The Converter
Protocol (Convert) Parameters" registry.IANA is requested to create the "Convert versions" sub-registry. New
values are assigned via Standards Action.The initial values to be assigned at the creation of the registry are
as follows:IANA is requested to create the "Convert TLVs" sub-registry. The
procedure for assigning values from this registry is as follows:The values in the range 1-127 can be assigned via Standards Action.The values in the range 128-191 can be assigned via Specification Required.The values in the range 192-255 can be assigned for Private Use.The initial values to be assigned at the creation of the registry are
as follows:IANA is requested to create the "Convert Errors" sub-registry. Codes
in this registry are assigned as a function of the error type. Four
types are defined; the following ranges are reserved for each of
these types:Message validation and processing errors: 0-31Client-side errors: 32-63Converter-side errors: 64-95Errors caused by destination server: 96-127The procedure for assigning values from this sub-registry is as
follows:0-191: Values in this range are assigned via Standards Action.192-255: Values in this range are assigned via Specification Required.The initial values to be assigned at the creation of the registry are
as follows:Although they could disagree with the contents of the document,
we would like to thank Joe Touch and Juliusz Chroboczek whose
comments on the MPTCP mailing list have forced
us to reconsider the design of the solution several times.We would like to thank Raphael Bauduin, Stefano Secci, and
Benjamin Hesmans for their help
in preparing this document. Sri Gundavelli and Nandini Ganesh provided
valuable feedback about the handling of TFO and the error codes.
Thanks to them.This document builds upon earlier documents that proposed various forms
of Multipath TCP proxies ,
and .From :Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
Nishida, and Christoph Paasch for their valuable comments.Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and
Sri Gundavelli for the fruitful discussions in IETF#95 (Buenos
Aires).Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
Xavier Grall for their inputs.Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
Srinivasan, and Raghavendra Mallya for the discussion.As noted above, this document builds on two previous documents.The authors of were:
- Mohamed Boucadair
- Christian Jacquenet
- Olivier Bonaventure
- Denis Behaghel
- Stefano Secci
- Wim Henderickx
- Robert Skog
- Suresh Vinapamula
- SungHoon Seo
- Wouter Cloetens
- Ullrich Meyer
- Luis M. Contreras
- Bart PeirensThe authors of were:
- Bart Peirens
- Gregory Detal
- Sebastien Barre
- Olivier BonaventureThis section to be removed before publication.00 : initial version, designed to support Multipath TCP and TFO only00 to -01 : added section describing the support of different
standard tracks TCP options by Transport Converters, clarification of the IANA section, moved the SOCKS comparison to the appendix and various minor modificationsTransmission Control ProtocolIP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]TCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.TCP Fast OpenThis document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.TCP SYN Flooding Attacks and Common MitigationsThis document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. This memo provides information for the Internet community.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP HeadersWhen experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. [STANDARDS-TRACK]TCP User Timeout OptionThe TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [STANDARDS-TRACK]The TCP Authentication OptionThis document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.TCP Extensions for High PerformanceThis memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. [STANDARDS-TRACK]Requirements for IP Version 4 RoutersThis memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]Classical versus Transparent IP ProxiesThis document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.SOCKS Protocol Version 5This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]TCP Selective Acknowledgment OptionsThis memo proposes an implementation of SACK and discusses its performance and related issues. [STANDARDS-TRACK]Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address SpoofingThis paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Performance Enhancing Proxies Intended to Mitigate Link-Related DegradationsThis document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. This memo provides information for the Internet community.Happy Eyeballs: Success with Dual-Stack HostsWhen a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK]Threat Analysis for TCP Extensions for Multipath Operation with Multiple AddressesMultipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. This document is not an Internet Standards Track specification; it is published for informational purposes.A Roadmap for Transmission Control Protocol (TCP) Specification DocumentsThis document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.This document obsoletes RFC 4614.Port Control Protocol (PCP)The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.Increasing TCP's Initial WindowThis document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.A TCP Authentication Option Extension for NAT TraversalThis document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through Network Address Translators and/or Network Address and Port Translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.TCP Extensions for High PerformanceThis document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against Wrapped Sequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.This document obsoletes RFC 1323 and describes changes from it.Cryptographic protection of TCP Streams (tcpcrypt)This document specifies tcpcrypt, a TCP encryption protocol designed for use in conjunction with the TCP Encryption Negotiation Option (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable. Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data may be transmitted. However, this cost can be avoided between two hosts that have recently established a previous tcpcrypt connection.SOCKS Protocol Version 6The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication.Extensions for Network-Assisted MPTCP Deployment ModelsBecause of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called MPTCP Conversion Point (MCP). Network-Assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. MCPs located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies extensions for Network-Assisted MPTCP deployment models.Link bonding with transparent Multipath TCPThis document describes the utilisation of the transparent Multipath TCP mode to enable network operators to provide link bonding services in hybrid access networks.Low Latency Applications and the Internet ArchitectureSome recent Internet technology developments relate to improvements in communications latency. For instance, improvements in radio communications or the recent work in IETF transport, security, and web protocols. There are also potential applications where latency would play a more significant role than it has traditionally been in the Internet communications. Modern networking systems offer many tools for building low-latency networks, from highly optimised individual protocol components to software controlled, virtualised and tailored network functions. This memo views the developments from a system viewpoint, and considers the potential future stresses that the strive for low-latency support for applications may bring.TCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824 [RFC6824] through clarifications and modifications primarily driven by deployment experience.RADIUS Extensions for Network-Assisted Multipath TCP (MPTCP)Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called MPTCP Conversion Point (MCP). Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. MCPs located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple MCPs.An Analysis of Longitudinal TCP Passive Measurements (Short Paper)Tracking transport-layer evolution with PATHspiderIs it still possible to extend TCP ?Multipath TCP DeploymentMultipath in the Middle(Box)The description above is a simplified description of the Converter protocol.
At a first glance, the proposed solution could seem similar to the SOCKS v5 protocol
. This protocol is used to proxy TCP connections. The Client creates
a connection to a SOCKS proxy, exchanges authentication information and indicates
the destination address and port of the final server. At this point, the SOCKS
proxy creates a connection towards the final server and relays all data between
the two proxied connections. The operation of an implementation based on SOCKSv5 is illustrated in .The Converter protocol also relays data
between an upstream and a downstream connection, but there are important
differences with SOCKSv5.A first difference is that the Converter protocol leverages the TFO option
to exchange all control information during the three-way handshake. This reduces
the connection establishment delay compared to SOCKS that requires two
or more round-trip-times before the establishment of the downstream connection towards
the final destination. In today's Internet, latency is a important metric and
various protocols have been tuned to reduce their latency . A recently proposed extension to SOCKS also leverages the TFO
option .A second difference is that the Converter protocol explicitly takes the TCP extensions
into account. By using the Converter protocol, the Client can learn whether
a given TCP extension is supported by the destination Server. This enables the Client to
bypass the Transport Converter when the destination supports the required
TCP extension. Neither SOCKS v5 nor the proposed SOCKS v6
provide such a feature.A third difference is that a Transport Converter will only accept the connection
initiated by the Client provided that the downstream connection is accepted by
the Server. If the Server refuses the connection establishment attempt from
the Transport Converter, then the upstream connection from the Client
is rejected as well. This feature is important for applications that check the
availability of a Server or use the time to connect as a hint on the
selection of a Server .