draft-ietf-tcpm-converters-18.txt   draft-ietf-tcpm-converters-19.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 7, 2020 Orange Expires: September 22, 2020 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
March 06, 2020 March 21, 2020
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-18 draft-ietf-tcpm-converters-19
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. A Transport Converter may provide conversion service Multipath TCP. A Transport Converter may provide conversion service
for one or more TCP extensions. The conversion service is provided for one or more TCP extensions. The conversion service is provided
by means of the TCP Convert Protocol (Convert). by means of the TCP Convert Protocol (Convert).
This protocol provides 0-RTT (Zero Round-Trip Time) conversion This protocol provides 0-RTT (Zero Round-Trip Time) conversion
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2020. This Internet-Draft will expire on September 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 31 skipping to change at page 2, line 31
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Problem . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Network-Assisted Connections: The Rationale . . . . . . . 4 1.2. Network-Assisted Connections: The Rationale . . . . . . . 4
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6 1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
2. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 6 2. Differences with SOCKSv5 . . . . . . . . . . . . . . . . . . 6
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 8 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 8
4. Architecture & Behaviors . . . . . . . . . . . . . . . . . . 9 4. Architecture & Behaviors . . . . . . . . . . . . . . . . . . 9
4.1. Functional Elements . . . . . . . . . . . . . . . . . . . 9 4.1. Functional Elements . . . . . . . . . . . . . . . . . . . 9
4.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 10 4.2. Theory of Operation . . . . . . . . . . . . . . . . . . . 11
4.3. Data Processing at the Transport Converter . . . . . . . 14 4.3. Data Processing at the Transport Converter . . . . . . . 14
4.4. Address Preservation vs. Address Sharing . . . . . . . . 16 4.4. Address Preservation vs. Address Sharing . . . . . . . . 16
4.4.1. Address Preservation . . . . . . . . . . . . . . . . 16 4.4.1. Address Preservation . . . . . . . . . . . . . . . . 16
4.4.2. Address/Prefix Sharing . . . . . . . . . . . . . . . 17 4.4.2. Address/Prefix Sharing . . . . . . . . . . . . . . . 17
5. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 18 5. Sample Examples . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Outgoing Converter-Assisted Multipath TCP Connections . . 18 5.1. Outgoing Converter-Assisted Multipath TCP Connections . . 18
5.2. Incoming Converter-Assisted Multipath TCP Connection . . 20 5.2. Incoming Converter-Assisted Multipath TCP Connection . . 20
6. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 21 6. The Convert Protocol (Convert) . . . . . . . . . . . . . . . 21
6.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 22 6.1. The Convert Fixed Header . . . . . . . . . . . . . . . . 22
6.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 16 skipping to change at page 3, line 16
7.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 34 7.2. Window Scale (WS) . . . . . . . . . . . . . . . . . . . . 34
7.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 34 7.3. Selective Acknowledgments . . . . . . . . . . . . . . . . 34
7.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 35 7.4. Timestamp . . . . . . . . . . . . . . . . . . . . . . . . 35
7.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 35 7.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 35
7.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 35 7.6. TCP Fast Open . . . . . . . . . . . . . . . . . . . . . . 35
7.7. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 36 7.7. TCP-AO . . . . . . . . . . . . . . . . . . . . . . . . . 36
8. Interactions with Middleboxes . . . . . . . . . . . . . . . . 36 8. Interactions with Middleboxes . . . . . . . . . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 37 9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 37
9.2. Authentication and Authorization Considerations . . . . . 38 9.2. Authentication and Authorization Considerations . . . . . 38
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 39 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 40 9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 40
9.5. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 40 9.5. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 40 10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 40
10.2. The Convert Protocol (Convert) Parameters . . . . . . . 41 10.2. The Convert Protocol (Convert) Parameters . . . . . . . 41
10.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 41 10.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 41
10.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 42 10.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 42
10.2.3. Convert Error Messages . . . . . . . . . . . . . . . 42 10.2.3. Convert Error Messages . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 43 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 45 11.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Example Socket API Changes to Support the 0-RTT Appendix A. Example Socket API Changes to Support the 0-RTT
Convert Protocol . . . . . . . . . . . . . . . . . . 48 Convert Protocol . . . . . . . . . . . . . . . . . . 48
A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 48 A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 48
A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 49 A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
1.1. The Problem 1.1. The Problem
Transport protocols like TCP evolve regularly [RFC7414]. TCP has Transport protocols like TCP evolve regularly [RFC7414]. TCP has
been improved in different ways. Some improvements such as changing been improved in different ways. Some improvements such as changing
the initial window size [RFC6928] or modifying the congestion control the initial window size [RFC6928] or modifying the congestion control
scheme can be applied independently on clients and servers. Other scheme can be applied independently on clients and servers. Other
improvements such as Selective Acknowledgments [RFC2018] or large improvements such as Selective Acknowledgments [RFC2018] or large
windows [RFC7323] require a new TCP option or to change the semantics windows [RFC7323] require a new TCP option or to change the semantics
of some fields in the TCP header. These modifications must be of some fields in the TCP header. These modifications must be
deployed on both clients and servers to be actually used on the deployed on both clients and servers to be actually used on the
Internet. Experience with the latter TCP extensions reveals that Internet. Experience with the latter class of TCP extensions reveals
their deployment can require many years. Fukuda reports in that their deployment can require many years. Fukuda reports in
[Fukuda2011] results of a decade of measurements showing the [Fukuda2011] results of a decade of measurements showing the
deployment of Selective Acknowledgments, Window Scale and TCP deployment of Selective Acknowledgments, Window Scale, and TCP
Timestamps. [ANRW17] describes measurements showing that TCP Fast Timestamps. [ANRW17] describes measurements showing that TCP Fast
Open (TFO) [RFC7413] is still not widely deployed. Open (TFO) [RFC7413] is still not widely deployed.
There are some situations where the transport stack used on clients There are some situations where the transport stack used on clients
(or servers) can be upgraded at a faster pace than the transport (or servers) can be upgraded at a faster pace than the transport
stack running on servers (or clients). In those situations, clients stack running on servers (or clients). In those situations, clients
would typically want to benefit from the features of an improved would typically want to benefit from the features of an improved
transport protocol even if the servers have not yet been upgraded and transport protocol even if the servers have not yet been upgraded and
conversely. Some assistance from the network to make use of these conversely. Some assistance from the network to make use of these
features is valuable. For example, Performance Enhancing Proxies features is valuable. For example, Performance Enhancing Proxies
skipping to change at page 4, line 49 skipping to change at page 4, line 49
1.2. Network-Assisted Connections: The Rationale 1.2. Network-Assisted Connections: The Rationale
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 in particular. A provide the benefits of such extensions to clients in particular. A
Transport Converter may provide conversion service for one or more Transport Converter may provide conversion service for one or more
TCP extensions. Which TCP extensions are eligible to the conversion TCP extensions. Which TCP extensions are eligible to the conversion
service is deployment-specific. The conversion service is provided service is deployment-specific. The conversion service is provided
by means of the 0-RTT TCP Convert Protocol (Convert), that is an by means of the 0-RTT TCP Convert Protocol (Convert), that is an
application-layer protocol which uses a specific TCP port number. application-layer protocol which uses a specific TCP port number on
the Converter.
The Convert Protocol provides Zero Round-Trip Time (0-RTT) conversion The Convert Protocol provides Zero Round-Trip Time (0-RTT) conversion
service since no extra delay is induced by the protocol compared to service since no extra delay is induced by the protocol compared to
connections that are not proxied. Particularly, the Convert Protocol connections that are not proxied. Particularly, the Convert Protocol
does not require extra signaling setup delays before making use of does not require extra signaling setup delays before making use of
the conversion service. The Convert Protocol does not require any the conversion service. The Convert Protocol does not require any
encapsulation (no tunnels, whatsoever). encapsulation (no tunnels, whatsoever).
The Transport Converter adheres to the main steps drawn in Section 3 The Transport Converter adheres to the main steps drawn in Section 3
of [RFC1919]. In particular, a Transport Converter achieves the of [RFC1919]. In particular, a Transport Converter achieves the
skipping to change at page 6, line 37 skipping to change at page 6, line 37
described in this document. described in this document.
1.3. Applicability Scope 1.3. Applicability Scope
0-RTT TCP Convert Protocol specified in this document MUST be used in 0-RTT TCP Convert Protocol specified in this document MUST be used in
a single administrative domain deployment model. That is, the entity a single administrative domain deployment model. That is, the entity
offering the connectivity service to a client is also be entity which offering the connectivity service to a client is also be entity which
owns and operates the Transport Converter, with no transit over a owns and operates the Transport Converter, with no transit over a
third-party network. third-party network.
Deployment of Transport Converters by third parties MUST adhere to Future deployment of Transport Converters by third parties MUST
the mutual authentication requirements in Section 9.2 to prevent adhere to the mutual authentication requirements in Section 9.2 to
illegitimate traffic interception (Section 9.4), in particular. prevent illegitimate traffic interception (Section 9.4), in
particular.
2. Differences with SOCKSv5 2. Differences with SOCKSv5
Several IETF protocols provide proxy services; the closest to the Several IETF protocols provide proxy services; the closest to the
0-RTT Convert protocol being the SOCKSv5 protocol [RFC1928]. This 0-RTT Convert protocol being the SOCKSv5 protocol [RFC1928]. This
protocol is already used to deploy Multipath TCP in some cellular protocol is already used to deploy Multipath TCP in some cellular
networks (Section 2.2 of [RFC8041]). networks (Section 2.2 of [RFC8041]).
A SOCKS Client creates a connection to a SOCKS Proxy, exchanges A SOCKS Client creates a connection to a SOCKS Proxy, exchanges
authentication information, and indicates the IP address and port authentication information, and indicates the IP address and port
skipping to change at page 8, line 41 skipping to change at page 8, line 41
Client is rejected as well. This feature is important for Client is rejected as well. This feature is important for
applications that check the availability of a Server or use the time applications that check the availability of a Server or use the time
to connect as a hint on the selection of a Server [RFC8305]. to connect as a hint on the selection of a Server [RFC8305].
A fourth difference is that the 0-RTT Convert protocol only allows A fourth difference is that the 0-RTT Convert protocol only allows
the Client to specify the IP address/port number of the destination the Client to specify the IP address/port number of the destination
server and not a DNS name. We evaluated an alternate design that server and not a DNS name. We evaluated an alternate design that
included the DNS name of the remote peer instead of its IP address as included the DNS name of the remote peer instead of its IP address as
in SOCKS [RFC1928]. However, that design was not adopted because it in SOCKS [RFC1928]. However, that design was not adopted because it
induces both an extra load and increased delays on the Transport induces both an extra load and increased delays on the Transport
Converter to handle and manage DNS resolution requests. Converter to handle and manage DNS resolution requests. Note that
the name resolution at the Converter may fail (e.g., private names
discussed in Section 2.1 of [RFC6731]) or may not match the one that
would be returned by a Client's resolution library (e.g., Section 2.2
of [RFC6731]).
3. Conventions and Definitions 3. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Architecture & Behaviors 4. Architecture & Behaviors
skipping to change at page 13, line 33 skipping to change at page 13, line 36
Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
data inside its payload but forbids the receiver from delivering it data inside its payload but forbids the receiver from delivering it
to the application until completion of the three-way-handshake. To to the application until completion of the three-way-handshake. To
enable applications to exchange data in a TCP handshake, this enable applications to exchange data in a TCP handshake, this
specification follows an approach similar to TCP Fast Open [RFC7413] specification follows an approach similar to TCP Fast Open [RFC7413]
and thus removes the constraint by allowing data in SYN packets to be and thus removes the constraint by allowing data in SYN packets to be
delivered to the Transport Converter application. delivered to the Transport Converter application.
As discussed in [RFC7413], such change to TCP semantic raises two As discussed in [RFC7413], such change to TCP semantic raises two
issues. First, duplicate SYNs can cause problems for some issues. First, duplicate SYNs can cause problems for applications
applications that rely on TCP. Second, TCP suffers from SYN flooding that rely on TCP; whether or not a given application is affected
attacks [RFC4987]. TFO solves these two problems for applications dependes on the details of that application protocol. Second, TCP
that can tolerate replays by using the TCP Fast Open option that suffers from SYN flooding attacks [RFC4987]. TFO solves these two
includes a cookie. However, the utilization of this option consumes problems for applications that can tolerate replays by using the TCP
space in the limited TCP header. Furthermore, there are situations, Fast Open option that includes a cookie. However, the utilization of
as noted in Section 7.3 of [RFC7413] where it is possible to accept this option consumes space in the limited TCP header. Furthermore,
the payload of SYN packets without creating additional security risks there are situations, as noted in Section 7.3 of [RFC7413] where it
such as a network where addresses cannot be spoofed and the Transport is possible to accept the payload of SYN packets without creating
Converter only serves a set of hosts that are identified by these additional security risks such as a network where addresses cannot be
addresses. spoofed and the Transport Converter only serves a set of hosts that
are identified by these addresses.
For these reasons, this specification does not mandate the use of the For these reasons, this specification does not mandate the use of the
TCP Fast Open option when the Client sends a connection establishment TCP Fast Open option when the Client sends a connection establishment
packet towards a Transport Converter. The Convert Protocol includes packet towards a Transport Converter. The Convert Protocol includes
an optional Cookie TLV that provides similar protection as the TCP an optional Cookie TLV that provides similar protection as the TCP
Fast Open option without consuming space in the TCP header. Fast Open option without consuming space in the TCP header.
Furthermore, this design allows for the use of longer cookies than Furthermore, this design allows for the use of longer cookies than
[RFC7413]. [RFC7413].
If the downstream (or upstream) connection fails for some reason If the downstream (or upstream) connection fails for some reason
(excessive retransmissions, reception of an RST segment, etc.), then (excessive retransmissions, reception of an RST segment, etc.), then
the Converter reacts by forcing the tear-down of the upstream (or the Converter reacts by forcing the tear-down of the upstream (or
downstream) connection. In particular, if an ICMP error message that downstream) connection. In particular, if an ICMP error message that
indicates a hard error is received on the downstream connection, the indicates a hard error is received on the downstream connection, the
Converter echoes the Code field of that ICMP message in a Destination Converter echoes the Code field of that ICMP message in a Destination
Unreachable Error TLV (see Section 6.2.8) that it transmits to the Unreachable Error TLV (see Section 6.2.8) that it transmits to the
skipping to change at page 14, line 22 skipping to change at page 14, line 24
indicates a hard error is received on the downstream connection, the indicates a hard error is received on the downstream connection, the
Converter echoes the Code field of that ICMP message in a Destination Converter echoes the Code field of that ICMP message in a Destination
Unreachable Error TLV (see Section 6.2.8) that it transmits to the Unreachable Error TLV (see Section 6.2.8) that it transmits to the
Client. Note that if an ICMP error message that indicates a soft Client. Note that if an ICMP error message that indicates a soft
error is received on the downstream connection, the Converter will error is received on the downstream connection, the Converter will
retransmit the corresponding data until it is acknowledged or the retransmit the corresponding data until it is acknowledged or the
connection times out. A classification of ICMP soft and hard errors connection times out. A classification of ICMP soft and hard errors
is provided in Table 1 of [RFC5461]. is provided in Table 1 of [RFC5461].
The same reasoning applies when the upstream connection ends with an The same reasoning applies when the upstream connection ends with an
exchange of FIN packets. In this case, the Converter will also exchange of FIN segments. In this case, the Converter will also
terminate the downstream connection by using FIN packets. If the terminate the downstream connection by using FIN segments. If the
downstream connection terminates with the exchange of FIN packets, downstream connection terminates with the exchange of FIN segments,
the Converter should initiate a graceful termination of the upstream the Converter should initiate a graceful termination of the upstream
connection. connection.
4.3. Data Processing at the Transport Converter 4.3. Data Processing at the Transport Converter
As mentioned in Section 4.2, the Transport Converter acts as a TCP As mentioned in Section 4.2, the Transport Converter acts as a TCP
proxy between the upstream connection (i.e., between the Client and proxy between the upstream connection (i.e., between the Client and
the Transport Converter) and the downstream connection (i.e., between the Transport Converter) and the downstream connection (i.e., between
the Transport Converter and the Server). the Transport Converter and the Server).
skipping to change at page 18, line 27 skipping to change at page 18, line 27
|dst:C src:Tc|dst:Te src:S| |dst:C src:Tc|dst:Te src:S|
|<---------SYN/ACK------------|<-----SYN/ACK-----| |<---------SYN/ACK------------|<-----SYN/ACK-----|
| | | | | |
|src:C dst:Tc|src:Te dst:S| |src:C dst:Tc|src:Te dst:S|
|------------ACK------------->|-------ACK------->| |------------ACK------------->|-------ACK------->|
| | | | | |
| ... | ... | | ... | ... |
Legend: Legend:
Tc: IP address used by the Transport Converter on the internal Tc: IP address used by the Transport Converter on the internal
relam. realm.
Te: IP address used by the Transport Converter on the external Te: IP address used by the Transport Converter on the external
relam. realm.
Figure 9: Address Sharing Figure 9: Address Sharing
5. Sample Examples 5. Sample Examples
5.1. Outgoing Converter-Assisted Multipath TCP Connections 5.1. Outgoing Converter-Assisted Multipath TCP Connections
As an example, let us consider how the Convert Protocol can help the 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 deployment of Multipath TCP. We assume that both the Client and the
Transport Converter support Multipath TCP, but consider two different Transport Converter support Multipath TCP, but consider two different
skipping to change at page 27, line 50 skipping to change at page 27, line 50
| ... | | ... |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 20: The TCP Options Field Figure 20: The TCP Options Field
Upon reception of a Base Connect TLV, and absent any policy (e.g., Upon reception of a Base Connect TLV, and absent any policy (e.g.,
rate-limit) or resource exhaustion conditions, a Transport Converter rate-limit) or resource exhaustion conditions, a Transport Converter
attempts to establish a connection to the address and port that it attempts to establish a connection to the address and port that it
contains. The Transport Converter MUST use by default the TCP contains. The Transport Converter MUST use by default the TCP
options that correspond to its local policy to establish this options that correspond to its local policy to establish this
connection. These are the options that it advertises in the connection.
Supported TCP Extensions TLV.
Upon reception of an Extended Connect TLV, a Transport Converter Upon reception of an Extended Connect TLV, a Transport Converter
first checks whether it supports the TCP Options listed in the 'TCP first checks whether it supports the TCP Options listed in the 'TCP
Options' field. If not, it returns an error TLV set to "Unsupported Options' field. If not, it returns an error TLV set to "Unsupported
TCP Option" (Section 6.2.8). If the above check succeeded and absent TCP Option" (Section 6.2.8). If the above check succeeded and absent
any rate limit policy or resource exhaustion conditions, a Transport any rate limit policy or resource exhaustion conditions, a Transport
Converter MUST attempt to establish a connection to the address and Converter MUST attempt to establish a connection to the address and
port that it contains. It MUST include in the SYN that it sends to port that it contains. It MUST include in the SYN that it sends to
the Server the options listed in the 'TCP Options' sub-field and the the Server the options listed in the 'TCP Options' sub-field and the
TCP options that it would have used according to its local policies. TCP options that it would have used according to its local policies.
skipping to change at page 32, line 49 skipping to change at page 32, line 49
Converter is experiencing a network failure to proxy the request. Converter is experiencing a network failure to proxy the request.
The Transport Converter MUST send this error code when it The Transport Converter MUST send this error code when it
experiences forwarding issues to proxy a connection. The experiences forwarding issues to proxy a connection. The
Transport Converter may indicate in the Value field the suggested Transport Converter may indicate in the Value field the suggested
delay (in seconds) that the Client SHOULD wait before soliciting delay (in seconds) that the Client SHOULD wait before soliciting
the Transport Converter for a new proxied connection. A Value of the Transport Converter for a new proxied connection. A Value of
zero corresponds to a default delay of at least 30 seconds. zero corresponds to a default delay of at least 30 seconds.
o Connection Reset (96): This error indicates that the final o Connection Reset (96): This error indicates that the final
destination responded with an RST packet. The Value field MUST be destination responded with an RST segment. The Value field MUST
set to zero. be set to zero.
o Destination Unreachable (97): This error indicates that an ICMP o Destination Unreachable (97): This error indicates that an ICMP
message indicating a hard error (e.g., destination unreachable, message indicating a hard error (e.g., destination unreachable,
port unreachable, or network unreachable) was received by the port unreachable, or network unreachable) was received by the
Transport Converter. The Value field MUST echo the Code field of Transport Converter. The Value field MUST echo the Code field of
the received ICMP message. the received ICMP message.
As a reminder, TCP implementations are supposed to act on an ICMP As a reminder, TCP implementations are supposed to act on an ICMP
error message passed up from the IP layer, directing it to the error message passed up from the IP layer, directing it to the
connection that triggered the error using the demultiplexing connection that triggered the error using the demultiplexing
skipping to change at page 37, line 51 skipping to change at page 37, line 51
Additional security considerations are discussed in the following Additional security considerations are discussed in the following
sub-sections. sub-sections.
9.1. Privacy & Ingress Filtering 9.1. Privacy & Ingress Filtering
The Transport Converter may have access to privacy-related The Transport Converter may have access to privacy-related
information (e.g., subscriber credentials). The Transport Converter information (e.g., subscriber credentials). The Transport Converter
is designed to not leak such sensitive information outside a local is designed to not leak such sensitive information outside a local
domain. domain.
Given its function and location in the network, a Transport Convert Given its function and location in the network, a Transport Converter
is in a position to observe all packets that it processes, to include is in a position to observe all packets that it processes, to include
payloads and meta-data; and has the ability to profile and conduct payloads and meta-data; and has the ability to profile and conduct
some traffic analysis of user behavior. The Transport Converter MUST some traffic analysis of user behavior. The Transport Converter MUST
be as protected as a core IP router (e.g., Section 10 of [RFC1812]). be as protected as a core IP router (e.g., Section 10 of [RFC1812]).
Furthermore, ingress filtering policies MUST be enforced at the Furthermore, ingress filtering policies MUST be enforced at the
network boundaries [RFC2827]. network boundaries [RFC2827].
This document assumes that all network attachments are managed by the This document assumes that all network attachments are managed by the
same administrative entity. Therefore, enforcing anti-spoofing same administrative entity. Therefore, enforcing anti-spoofing
skipping to change at page 38, line 32 skipping to change at page 38, line 32
use the Convert Protocol. use the Convert Protocol.
One possibility for mutual authentication is to use TLS to perform One possibility for mutual authentication is to use TLS to perform
mutual authentication between the client and the Converter. That is, mutual authentication between the client and the Converter. That is,
use TLS when a Client retrieves a Cookie from the Converter and rely use TLS when a Client retrieves a Cookie from the Converter and rely
on certificate-based client authentication, pre-shared key based on certificate-based client authentication, pre-shared key based
[RFC4279] or raw public key based client authentication [RFC7250] to [RFC4279] or raw public key based client authentication [RFC7250] to
secure this connection. If the authentication succeeds, the secure this connection. If the authentication succeeds, the
Converter returns a cookie to the Client. Subsequent Connect Converter returns a cookie to the Client. Subsequent Connect
messages will be authorized as a function of the content of the messages will be authorized as a function of the content of the
Cookie TLV. Cookie TLV. An attacker from within the network between a Client and
a Transport Converter may intercept the Cookie and use it to be
granted access to the conversion service. Such attack is only
possible if the attacker spoofs the IP address of the Client and the
network does not filter packets with source spoofed IP addresses.
The operator that manages the various network attachments (including The operator that manages the various network attachments (including
the Transport Converters) has various options for enforcing the Transport Converters) has various options for enforcing
authentication and authorization policies. For example, a non- authentication and authorization policies. For example, a non-
exhaustive list of methods to achieve authorization is provided exhaustive list of methods to achieve authorization is provided
hereafter: hereafter:
o The network provider may enforce a policy based on the o The network provider may enforce a policy based on the
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 TCP converter service. If user is allowed to benefit from the TCP converter service. If
skipping to change at page 40, line 15 skipping to change at page 40, line 22
To mitigate such attacks, the Transport Converter SHOULD rate limit To mitigate such attacks, the Transport Converter SHOULD rate limit
the number of pending requests for a given Client. It SHOULD also the number of pending requests for a given Client. It SHOULD also
avoid sending to remote Servers SYNs that are significantly longer avoid sending to remote Servers SYNs that are significantly longer
than the SYN received from the Client. Finally, the Transport than the SYN received from the Client. Finally, the Transport
Converter SHOULD only retransmit a SYN to a Server after having Converter SHOULD only retransmit a SYN to a Server after having
received a retransmitted SYN from the corresponding Client. Means to received a retransmitted SYN from the corresponding Client. Means to
protect against SYN flooding attacks should also be enabled (e.g., protect against SYN flooding attacks should also be enabled (e.g.,
Section 3 of [RFC4987]). Section 3 of [RFC4987]).
Attacks from within the network between a Client and a Transport Attacks from within the network between a Client and a Transport
Converter are yet another actual threat. Means to ensure that Converter (including attacks that change the protocol version) are
illegitimate nodes cannot connect to a network should be implemented. yet another threat. Means to ensure that illegitimate nodes cannot
connect to a network should be implemented.
9.4. Traffic Theft 9.4. Traffic Theft
Traffic theft is a risk if an illegitimate Converter is inserted in Traffic theft is a risk if an illegitimate Converter is inserted in
the path. Indeed, inserting an illegitimate Converter in the the path. Indeed, inserting an illegitimate Converter in the
forwarding path allows traffic interception and can therefore provide forwarding path allows traffic interception and can therefore provide
access to sensitive data issued by or destined to a host. Converter access to sensitive data issued by or destined to a host. Converter
discovery and configuration are out of scope of this document. discovery and configuration are out of scope of this document.
9.5. Logging 9.5. Logging
skipping to change at page 47, line 18 skipping to change at page 47, line 29
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
<https://www.rfc-editor.org/info/rfc6296>. <https://www.rfc-editor.org/info/rfc6296>.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
<https://www.rfc-editor.org/info/rfc6731>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013, DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>. <https://www.rfc-editor.org/info/rfc6887>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
 End of changes. 23 change blocks. 
41 lines changed or deleted 56 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/