draft-ietf-tcpm-converters-01.txt   draft-ietf-tcpm-converters-02.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: September 6, 2018 Orange Expires: January 2, 2019 Orange
B. Peirens S. Gundavelli
Proximus Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
A. Nandugudi July 01, 2018
Memphis University
March 05, 2018
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-01 draft-ietf-tcpm-converters-02
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 1, line 48
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 September 6, 2018.
This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 40 skipping to change at page 2, line 39
3.4. Sample Example of Incoming Converter-Assisted Multipath 3.4. Sample Example of Incoming Converter-Assisted Multipath
TCP Connection . . . . . . . . . . . . . . . . . . . . . 11 TCP Connection . . . . . . . . . . . . . . . . . . . . . 11
4. The Converter Protocol (Convert) . . . . . . . . . . . . . . 12 4. The Converter Protocol (Convert) . . . . . . . . . . . . . . 12
4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 12 4.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 12
4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 13 4.2.1. Generic Convert TLV Format . . . . . . . . . . . . . 13
4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 14 4.2.2. Summary of Supported Convert TLVs . . . . . . . . . . 14
4.2.3. The Bootstrap TLV . . . . . . . . . . . . . . . . . . 15 4.2.3. The Bootstrap TLV . . . . . . . . . . . . . . . . . . 15
4.2.4. Supported TCP Extension Services TLV . . . . . . . . 15 4.2.4. Supported TCP Extension Services TLV . . . . . . . . 15
4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. Connect TLV . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 17 4.2.6. Extended TCP Header TLV . . . . . . . . . . . . . . . 18
4.2.7. Error TLV . . . . . . . . . . . . . . . . . . . . . . 18 4.2.7. Error TLV . . . . . . . . . . . . . . . . . . . . . . 18
5. Compatibility of Specific TCP Options with the Conversion 5. Compatibility of Specific TCP Options with the Conversion
Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 21 5.1. Base TCP Options . . . . . . . . . . . . . . . . . . . . 21
5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 21 5.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 22
5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 22 5.3. Selective Acknowledgements . . . . . . . . . . . . . . . 22
5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 23 5.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 23
5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 23 5.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 23
5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 23 5.7. TCP User Timeout . . . . . . . . . . . . . . . . . . . . 24
5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.8. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 24 5.9. TCP Experimental Options . . . . . . . . . . . . . . . . 24
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 24 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 25 7.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 25
7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 25 7.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 26
7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 26 7.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Multipath TCP-specific Considerations . . . . . . . . . . 26 7.5. Multipath TCP-specific Considerations . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. Convert Service Port Number . . . . . . . . . . . . . . . 27 8.1. Convert Service Port Number . . . . . . . . . . . . . . . 27
8.2. The Converter Protocol (Convert) Parameters . . . . . . . 27 8.2. The Converter Protocol (Convert) Parameters . . . . . . . 27
8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 27 8.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 27
8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 28 8.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 28
8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 28 8.2.3. Convert Error Messages . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 30
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 34 Appendix A. Differences with SOCKSv5 . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
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
windows [RFC7323] require a new TCP option or to change the semantics windows [RFC7323] require a new TCP option or to change the semantics
of some fields in the TCP header. These modifications must be of some fields in the TCP header. These modifications must be
skipping to change at page 4, line 20 skipping to change at page 4, line 20
for bonding purposes, faster handovers, or better resiliency. for bonding purposes, faster handovers, or better resiliency.
Unfortunately, deploying those extensions on both a wide range of Unfortunately, deploying those extensions on both a wide range of
clients and servers remains difficult. clients and servers remains difficult.
More recently, experimentation of 5G bonding, which has very scarce More recently, experimentation of 5G bonding, which has very scarce
coverage, has been conducted into global range of the incumbent 4G coverage, has been conducted into global range of the incumbent 4G
(LTE) connectivity in newly devised clients using Multipath TCP (LTE) connectivity in newly devised clients using Multipath TCP
proxy. Even if the 5G and the 4G bonding by 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 increases the bandwidth to data transfer, it is as well crucial to
minimize latency for all the way between endhosts regardless of minimize latency for all the way between endhosts regardless of
whether intermediate nodes are inside or ouside of the mobile core. whether intermediate nodes are inside or outside of the mobile core.
In order to handle uRLLC (Ultra-Reliable Low-Latency Communication) In order to handle uRLLC (Ultra-Reliable Low-Latency Communication)
for the next generation mobile network, Multipath TCP and its proxy for the next generation mobile network, Multipath TCP and its proxy
mechanism must be optimized to reduce latency. mechanism must be optimised to reduce latency.
This document specifies an application proxy, called Transport This document specifies an application proxy, called Transport
Converter. A Transport Converter is a function that is installed by Converter. A Transport Converter is a function that is installed by
a network operator to aid the deployment of TCP extensions and to a network operator to aid the deployment of TCP extensions and to
provide the benefits of such extensions to clients. A Transport provide the benefits of such extensions to clients. A Transport
Converter may support conversion service for one or more TCP Converter may support conversion service for one or more TCP
extensions. This service is provided by means of the Converter extensions. This service is provided by means of the Converter
Protocol (Convert), that is an application layer protocol which uses Protocol (Convert), that is an application layer protocol which uses
TBA TCP port number (Section 8). TBA TCP port number (Section 8).
skipping to change at page 5, line 7 skipping to change at page 5, line 7
o Perform access controls according to local policies. o Perform access controls according to local policies.
The main advantage of network-assisted Converters is that they enable 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, new TCP extensions to be used on a subset of the end-to-end path,
which encourages the deployment of these extensions. The Transport which encourages the deployment of these extensions. The Transport
Converter allows the client and the server to directly negotiate TCP Converter allows the client and the server to directly negotiate TCP
options. options.
The Convert Protocol is a generic mechanism to provide 0-RTT The Convert Protocol is a generic mechanism to provide 0-RTT
conversion service. As a sample applicability use case, this conversion service. As a sample applicability use case, this
document specifies how the Convert Protocol applies for Multiptah document specifies how the Convert Protocol applies for Multipath
TCP. It is out of scope of this document to provide a comprehensive TCP. It is out of scope of this document to provide a comprehensive
list of potential all conversion services; separate documents may be list of potential all conversion services; separate documents may be
edited in the future for other conversion services upon need. edited in the future for other conversion services upon need.
This document does not assume that all the traffic is eligible to the This document does not assume that all the traffic is eligible to the
network-assisted conversion service. Only a subset of the traffic network-assisted conversion service. Only a subset of the traffic
will be forwarded to a Converter according to a set of policies. will be forwarded to a Converter according to a set of policies.
Furthermore, it is possible to bypass the Converter to connect to the Furthermore, it is possible to bypass the Converter to connect to the
servers that already support the required TCP extension. servers that already support the required TCP extension.
This document assumes that a client is configured with one or a list This document assumes that a client is configured with one or a list
of Converters. Configuration means are outside the scope of this of Converters (e.g., [I-D.boucadair-tcpm-dhc-converter]).
document. Configuration means are outside the scope of this document.
This document is organized as follows. We first provide a brief This document is organized as follows. We first provide a brief
explanation of the operation of Transport Converters in Section 3. explanation of the operation of Transport Converters in Section 3.
We describe the Converter Protocol in Section 4. We discuss in We describe the Converter Protocol in Section 4. We discuss in
Section 5 how Transport Converters can be used to support different Section 5 how Transport Converters can be used to support different
TCP options. We then discuss the interactions with middleboxes TCP options. We then discuss the interactions with middleboxes
(Section 6) and the security considerations (Section 7). (Section 6) and the security considerations (Section 7).
Appendix A provides a comparison with SOCKS proxies that are already Appendix A provides a comparison with SOCKS proxies that are already
used to deploy Multipath TCP in some cellular networks. used to deploy Multipath TCP in some cellular networks.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
Client hosts and on Transport Converters. Further, the architecture Client hosts and on Transport Converters. Further, the architecture
allows for making use of TCP new extensions if those are supported by allows for making use of TCP new extensions if those are supported by
a given server. a given server.
The Client is configured, through means that are outside the scope of 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 this document, with the names and/or the addresses of one or more
Transport Converters. Transport Converters.
The architecture does not mandate anything on the server side. The architecture does not mandate anything on the server side.
Similar to address sharing mechanisms, the architecture does not
interfere with end-to-end TLS connections between the client and the
server.
One of the benefits of this design is that different transport One of the benefits of this design is that different transport
protocol extensions can be used on the upstream and the downstream protocol extensions can be used on the upstream and the downstream
connections. This encourages the deployment of new TCP extensions connections. This encourages the deployment of new TCP extensions
until they are widely supported by servers. until they are widely supported by servers.
3.2. Theory of Operation 3.2. Theory of Operation
At a high level, the objective of the Transport Converter is to allow 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 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 subset of the end-to-end path even if the Server does not support
skipping to change at page 13, line 46 skipping to change at page 13, line 46
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 | (optional) Value ... |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| ... (optional) Value | | ... (optional) Value |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 10: Converter Generic TLV Format Figure 10: Converter Generic TLV Format
A given TLV MUST only appear once on a connection. If two or more A given TLV LUST only appear once on a connection. If two or more
instances of the same TLV are exchanged over a Converter connection, copies of the same TLV are exchanged over a Converter connection, the
the associated TCP connections MUST be closed. associated TCP connections MUST be closed. All fields are encoded
using the network byte order. The length field is the number of 32
bits words.
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:
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
| Type | Hex | Length | Description | | Type | Hex | Length | Description |
+------+-----+----------+------------------------------------------+ +------+-----+----------+------------------------------------------+
| 1 | 0x1 | 1 | Bootstrap TLV | | 1 | 0x1 | 1 | Bootstrap TLV |
| 10 | 0xA | Variable| Connect TLV | | 10 | 0xA | Variable| Connect TLV |
skipping to change at page 16, line 22 skipping to change at page 16, line 22
service, solely Kind=30 will be present in the Supported TCP service, solely Kind=30 will be present in the Supported TCP
Extension Services TLV returned by the Converter to a requesting Extension Services TLV returned by the Converter to a requesting
Client. Client.
4.2.5. Connect TLV 4.2.5. Connect TLV
The Connect TLV (Figure 14) is used to request the establishment of a The Connect TLV (Figure 14) is used to request the establishment of a
connection via a Transport Converter. connection via a Transport Converter.
The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain The 'Remote Peer Port' and 'Remote Peer IP Address' fields contain
the destination port and IP address of the target server for an the destination port number and IP address of the target server for
outgoing connection towards a server located on the Internet. For an outgoing connection towards a server located on the Internet. For
incoming connections destined to a client serviced via a Converter, incoming connections destined to a client serviced via a Converter,
these fields convey the source port and IP address. these fields convey the source port and IP address.
The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4
addresses MUST be encoded using the IPv4-Mapped IPv6 Address format addresses MUST be encoded using the IPv4-Mapped IPv6 Address format
defined in [RFC4291]. defined in [RFC4291].
The optional 'TCP Options' field is used to specify how specific TCP The optional 'TCP Options' field is used to specify how specific TCP
Options should be advertised by the Transport Converter to the final Options should be advertised by the Transport Converter to the final
destination of a connection. If this field is not supplied, the destination of a connection. If this field is not supplied, the
Transport Converter MUST use the default TCP options that correspond Transport Converter MUST use the default TCP options that correspond
to its local policy. to its local policy.
The Connect TLV could be designed to be generic to include the DNS
name of the remote peer instead of its IP address as in SOCKS
[RFC1928]. However, that design was not adopted because it induces
both an extra load and increased delays on the Converter to handle
and manage DNS resolution requests.
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 | Remote Peer Port | | Type | Length | Remote Peer Port |
+---------------+---------------+-------------------------------+ +---------------+---------------+-------------------------------+
| | | |
| Remote Peer IP Address (128 bits) | | Remote Peer IP Address (128 bits) |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
skipping to change at page 17, line 31 skipping to change at page 17, line 47
| TCPOpt type | TCPOpt Length | Value (opt) | .... | | TCPOpt type | TCPOpt Length | Value (opt) | .... |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| .... | | .... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| ... | | ... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 15: The TCP Options field Figure 15: The TCP Options field
If a Transport Converter receives a Connect TLV with a non-empty TCP If a Transport Converter receives a Connect TLV with a non-empty TCP
options field, and the Converter accets to process the request, it options field, and the Converter acceptss to process the request, it
SHALL present those options to the destination peer in addition to SHALL present those options to the destination peer in addition to
the TCP options that it would have used according to its local the TCP options that it would have used according to its local
policies. For the TCP options that are listed without an optional policies. For the TCP options that are listed without an optional
value, the Converter MUST generate its own value. For the TCP value, the Converter MUST generate its own value. For the TCP
options that are included in the 'TCP Options' field with an optional 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 value, it SHALL copy the entire option for use in the connection with
the destination peer. This feature is required to support TCP Fast the destination peer. This feature is required to support TCP Fast
Open. Open.
The Converter may discard a Connect TLV request for many reasons The Converter may discard a Connect TLV request for many reasons
skipping to change at page 26, line 49 skipping to change at page 27, line 9
International Mobile Subscriber Identity (IMSI) to verify that a International Mobile Subscriber Identity (IMSI) to verify that a
user is allowed to benefit from the aggregation service. If that user is allowed to benefit from the aggregation service. If that
authorization fails, the Packet Data Protocol (PDP) context/bearer authorization fails, the Packet Data Protocol (PDP) context/bearer
will not be mounted. This method does not require any interaction will not be mounted. This method does not require any interaction
with the Converter. with the Converter.
o The network provider may enforce a policy based upon Access o The network provider may enforce a policy based upon Access
Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG)
to control the hosts that are authorized to communicate with a to control the hosts that are authorized to communicate with a
Converter. These ACLs may be installed as a result of RADIUS Converter. These ACLs may be installed as a result of RADIUS
exchanges, e.g. [I-D.boucadair-mptcp-radius]. This method does exchanges, e.g. [I-D.boucadair-radext-tcpm-converter]. This
not require any interaction with the Converter. method does not require any interaction with the Converter.
o A device that embeds the Converter may also host a RADIUS client o A device that embeds the Converter may also host a RADIUS client
that will solicit an AAA server to check whether connections that will solicit an AAA server to check whether connections
received from a given source IP address are authorized or not received from a given source IP address are authorized or not
[I-D.boucadair-mptcp-radius]. [I-D.boucadair-radext-tcpm-converter].
A first safeguard against the misuse of Converter resources by A first safeguard against the misuse of Converter resources by
illegitimate users (e.g., users with access networks that are not illegitimate users (e.g., users with access networks that are not
managed by the same provider that operates the Converter) is the managed by the same provider that operates the Converter) is the
Converter to reject Multipath TCP connections received on its Converter to reject Multipath TCP connections received on its
Internet-facing interfaces. Only Multipath PTCP connections received Internet-facing interfaces. Only Multipath PTCP connections received
on the customer-facing interfaces of a Converter will be accepted. on the customer-facing interfaces of a Converter will be accepted.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 29, line 34 skipping to change at page 29, line 38
Figure 19: The Convert Error Codes Figure 19: The Convert Error Codes
9. Acknowledgements 9. Acknowledgements
Although they could disagree with the contents of the document, we Although they could disagree with the contents of the document, we
would like to thank Joe Touch and Juliusz Chroboczek whose comments would like to thank Joe Touch and Juliusz Chroboczek whose comments
on the MPTCP mailing list have forced us to reconsider the design of on the MPTCP mailing list have forced us to reconsider the design of
the solution several times. the solution several times.
We would like to thank Raphael Bauduin, Stefano Secci, and Benjamin We would like to thank Raphael Bauduin, Stefano Secci, Benjamin
Hesmans for their help in preparing this document. Sri Gundavelli Hesmans and Anandatirtha Nandugudi for their help in preparing this
and Nandini Ganesh provided valuable feedback about the handling of document. Nandini Ganesh provided valuable feedback about the
TFO and the error codes. Thanks to them. handling of TFO and the error codes. Thanks to them.
This document builds upon earlier documents that proposed various This document builds upon earlier documents that proposed various
forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode], forms of Multipath TCP proxies [I-D.boucadair-mptcp-plain-mode],
[I-D.peirens-mptcp-transparent] and [HotMiddlebox13b]. [I-D.peirens-mptcp-transparent] and [HotMiddlebox13b].
From [I-D.boucadair-mptcp-plain-mode]: From [I-D.boucadair-mptcp-plain-mode]:
Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi
Nishida, and Christoph Paasch for their valuable comments. Nishida, and Christoph Paasch for their valuable comments.
skipping to change at page 30, line 15 skipping to change at page 30, line 19
Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and
Xavier Grall for their inputs. Xavier Grall for their inputs.
Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas
Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves
Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun
Srinivasan, and Raghavendra Mallya for the discussion. Srinivasan, and Raghavendra Mallya for the discussion.
9.1. Contributors 9.1. Contributors
Bart Peirens contributed to an early version of the document.
As noted above, this document builds on two previous documents. As noted above, this document builds on two previous documents.
The authors of [I-D.boucadair-mptcp-plain-mode] were: - Mohamed The authors of [I-D.boucadair-mptcp-plain-mode] were:
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 Peirens
The authors of [I-D.peirens-mptcp-transparent] were: - Bart Peirens - o Mohamed Boucadair
Gregory Detal - Sebastien Barre - Olivier Bonaventure
o Christian Jacquenet
o Olivier Bonaventure
o Denis Behaghel
o Stefano Secci
o Wim Henderickx
o Robert Skog
o Suresh Vinapamula
o SungHoon Seo
o Wouter Cloetens
o Ullrich Meyer
o Luis M. Contreras
o Bart Peirens
The authors of [I-D.peirens-mptcp-transparent] were:
o Bart Peirens
o Gregory Detal
o Sebastien Barre
o Olivier Bonaventure
10. Change Log 10. Change Log
This section to be removed before publication. This section to be removed before publication.
o 00 : initial version, designed to support Multipath TCP and TFO o 00 : initial version, designed to support Multipath TCP and TFO
only only
o 00 to -01 : added section Section 5 describing the support of o 00 to -01 : added section Section 5 describing the support of
different standard tracks TCP options by Transport Converters, different standard tracks TCP options by Transport Converters,
clarification of the IANA section, moved the SOCKS comparison to clarification of the IANA section, moved the SOCKS comparison to
the appendix and various minor modifications the appendix and various minor modifications
o 01 to -02 : Minor modifications
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 32, line 30 skipping to change at page 33, line 18
latency-02 (work in progress), October 2017. latency-02 (work in progress), October 2017.
[I-D.boucadair-mptcp-plain-mode] [I-D.boucadair-mptcp-plain-mode]
Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,
D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,
Contreras, L., and B. Peirens, "Extensions for Network- Contreras, L., and B. Peirens, "Extensions for Network-
Assisted MPTCP Deployment Models", draft-boucadair-mptcp- Assisted MPTCP Deployment Models", draft-boucadair-mptcp-
plain-mode-10 (work in progress), March 2017. plain-mode-10 (work in progress), March 2017.
[I-D.boucadair-mptcp-radius] [I-D.boucadair-radext-tcpm-converter]
Boucadair, M. and C. Jacquenet, "RADIUS Extensions for Boucadair, M. and C. Jacquenet, "RADIUS Extensions for
Network-Assisted Multipath TCP (MPTCP)", draft-boucadair- 0-RTT TCP Converters", draft-boucadair-radext-tcpm-
mptcp-radius-05 (work in progress), October 2017. converter-00 (work in progress), April 2018.
[I-D.boucadair-tcpm-dhc-converter]
Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options
for 0-RTT TCP Converters", draft-boucadair-tcpm-dhc-
converter-00 (work in progress), April 2018.
[I-D.ietf-mptcp-rfc6824bis] [I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", draft-ietf-mptcp-rfc6824bis-10 (work Multiple Addresses", draft-ietf-mptcp-rfc6824bis-11 (work
in progress), March 2018. in progress), May 2018.
[I-D.ietf-tcpinc-tcpcrypt] [I-D.ietf-tcpinc-tcpcrypt]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic protection of TCP Streams Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in
progress), November 2017. progress), June 2018.
[I-D.olteanu-intarea-socks-6] [I-D.olteanu-intarea-socks-6]
Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6", Olteanu, V. and D. Niculescu, "SOCKS Protocol Version 6",
draft-olteanu-intarea-socks-6-01 (work in progress), draft-olteanu-intarea-socks-6-02 (work in progress), March
October 2017. 2018.
[I-D.peirens-mptcp-transparent] [I-D.peirens-mptcp-transparent]
Peirens, B., Detal, G., Barre, S., and O. Bonaventure, Peirens, B., Detal, G., Barre, S., and O. Bonaventure,
"Link bonding with transparent Multipath TCP", draft- "Link bonding with transparent Multipath TCP", draft-
peirens-mptcp-transparent-00 (work in progress), July peirens-mptcp-transparent-00 (work in progress), July
2016. 2016.
[IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment", [IETFJ16] Bonaventure, O. and S. Seo, "Multipath TCP Deployment",
IETF Journal, Fall 2016 , n.d.. IETF Journal, Fall 2016 , n.d..
skipping to change at page 36, line 37 skipping to change at page 37, line 37
Olivier Bonaventure (editor) Olivier Bonaventure (editor)
Tessares Tessares
Email: Olivier.Bonaventure@tessares.net Email: Olivier.Bonaventure@tessares.net
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Bart Peirens Sri Gundavelli
Proximus Cisco
Email: bart.peirens@proximus.com Email: sgundave@cisco.com
SungHoon Seo SungHoon Seo
Korea Telecom Korea Telecom
Email: sh.seo@kt.com Email: sh.seo@kt.com
Anandatirtha Nandugudi
Memphis University
Email: nndugudi@memphis.edu
 End of changes. 33 change blocks. 
55 lines changed or deleted 104 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/