draft-ietf-tcpm-converters-15.txt   draft-ietf-tcpm-converters-16.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: August 14, 2020 Orange Expires: August 16, 2020 Orange
S. Gundavelli S. Gundavelli
Cisco Cisco
S. Seo S. Seo
Korea Telecom Korea Telecom
B. Hesmans B. Hesmans
Tessares Tessares
February 11, 2020 February 13, 2020
0-RTT TCP Convert Protocol 0-RTT TCP Convert Protocol
draft-ietf-tcpm-converters-15 draft-ietf-tcpm-converters-16
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 1, line 49 skipping to change at page 1, line 49
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 August 14, 2020. This Internet-Draft will expire on August 16, 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 3, line 19 skipping to change at page 3, line 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 36 9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 36
9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 37 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 37
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 38 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 38
9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 38 9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 38
9.5. Authentication Considerations . . . . . . . . . . . . . . 38 9.5. Authentication Considerations . . . . . . . . . . . . . . 38
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 39 10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 39
10.2. The Convert Protocol (Convert) Parameters . . . . . . . 39 10.2. The Convert Protocol (Convert) Parameters . . . . . . . 39
10.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 40 10.2.1. Convert Versions . . . . . . . . . . . . . . . . . . 40
10.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 41 10.2.2. Convert TLVs . . . . . . . . . . . . . . . . . . . . 40
10.2.3. Convert Error Messages . . . . . . . . . . . . . . . 41 10.2.3. Convert Error Messages . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 44 11.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A. Example Socket API Changes to Support the 0-RTT Appendix A. Example Socket API Changes to Support the 0-RTT
Convert Protocol . . . . . . . . . . . . . . . . . . 47 Convert Protocol . . . . . . . . . . . . . . . . . . 47
A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 47 A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 47
A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 48 A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 47
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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
skipping to change at page 25, line 48 skipping to change at page 25, line 48
the destination port number and IP address of the Server, for the destination port number and IP address of the Server, for
outgoing connections. For incoming connections destined to a Client outgoing connections. For incoming connections destined to a Client
serviced via a Transport Converter, these fields convey the source serviced via a Transport Converter, these fields convey the source
port number and IP address of the SYN packet received by the port number and IP address of the SYN packet received by the
Transport Converter from the server. Transport Converter from the server.
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]. Further, Remote Peer IP address field MUST NOT defined in [RFC4291]. Further, Remote Peer IP address field MUST NOT
include multicast, broadcast, and host loopback addresses [RFC6890]. include multicast, broadcast, and host loopback addresses [RFC6890].
If a Converter receives a Connect TLVs witch such invalid addresses, If a Converter receives a Connect TLVs with such invalid addresses,
it MUST reply with a Malformed Message Error TLV and close the it MUST reply with a Malformed Message Error TLV and close the
associated TCP connection. associated TCP connection.
We distinguish two types of Connect TLV based on their length: (1) We distinguish two types of Connect TLV based on their length: (1)
the Base Connect TLV has a length of 20 bytes and contains a remote the Base Connect TLV has a length of 20 bytes and contains a remote
address and a remote port (Figure 18), (2) the Extended Connect TLV address and a remote port (Figure 18), (2) the Extended Connect TLV
spans more than 20 bytes and also includes the optional 'TCP Options' spans more than 20 bytes and also includes the optional 'TCP Options'
field (Figure 19). This field is used to request the advertisement field (Figure 19). This field is used to request the advertisement
of specific TCP options to the server. of specific TCP options to the server.
skipping to change at page 39, line 50 skipping to change at page 39, line 50
the Transport Converters of a domain. the Transport Converters of a domain.
10.2. The Convert Protocol (Convert) Parameters 10.2. The Convert Protocol (Convert) Parameters
IANA is requested to create a new "The TCP Convert Protocol (Convert) IANA is requested to create a new "The TCP Convert Protocol (Convert)
Parameters" registry. Parameters" registry.
The following subsections detail new registries within "The Convert The following subsections detail new registries within "The Convert
Protocol (Convert) Parameters" registry. Protocol (Convert) Parameters" registry.
Registration requests for the 128-191 range (for both "Convert TLVs"
and "Convert Error Messages" sub-registries) are evaluated after a
three-week review period on the tcp-convert-review@ietf.org mailing
list, on the advice of one or more Designated Experts. However, to
allow for the allocation of values prior to publication, the
Designated Experts may approve registration once they are satisfied
that such a specification will be published. New registration
requests should be sent in the form of an email to the review mailing
list; the request should use an appropriate subject (e.g., "Request
to register 0-RTT Convert TLV: example" or "Request to register 0-RTT
Convert Error Message: example"). IANA will only accept new
registrations from the Designated Experts, and will check that review
was requested on the mailing list in accordance with these
procedures.
Within the review period, the Designated Experts will either approve
or deny the registration request, communicating this decision to the
review list and IANA. Denials should include an explanation and, if
applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the
iesg@ietf.org mailing list) for resolution.
The Designated Expert is expected to ascertain the existence of The Designated Expert is expected to ascertain the existence of
suitable documentation as described in Section 4.6 of [RFC8126] and suitable documentation as described in Section 4.6 of [RFC8126] and
to verify that the document is permanently and publicly available. to verify that the document is permanently and publicly available.
The Designated Expert is also expected to check the clarity of The Designated Expert is also expected to check the clarity of
purpose and use of the requested code points. purpose and use of the requested code points.
Also, criteria that should be applied by the Designated Experts Also, criteria that should be applied by the Designated Experts
includes determining whether the proposed registration duplicates includes determining whether the proposed registration duplicates
existing functionality, whether it is likely to be of general existing functionality, whether it is likely to be of general
applicability or whether it is useful only for a private use, and applicability or whether it is useful only for a private use, and
whether the registration description is clear. IANA must only accept whether the registration description is clear. IANA must only accept
registry updates to the 128-191 range (for both "Convert TLVs" and registry updates to the 128-191 range (for both "Convert TLVs" and
"Convert Error Messages" sub-registries) from the Designated Experts "Convert Error Messages" sub-registries) from the Designated Experts
skipping to change at page 44, line 34 skipping to change at page 44, line 21
[Fukuda2011] [Fukuda2011]
Fukuda, K., "An Analysis of Longitudinal TCP Passive Fukuda, K., "An Analysis of Longitudinal TCP Passive
Measurements (Short Paper)", Traffic Monitoring and Measurements (Short Paper)", Traffic Monitoring and
Analysis. TMA 2011. Lecture Notes in Computer Science, vol Analysis. TMA 2011. Lecture Notes in Computer Science, vol
6613. , 2011. 6613. , 2011.
[HotMiddlebox13b] [HotMiddlebox13b]
Detal, G., Paasch, C., and O. Bonaventure, "Multipath in Detal, G., Paasch, C., and O. Bonaventure, "Multipath in
the Middle(Box)", HotMiddlebox'13 , December 2013, the Middle(Box)", HotMiddlebox'13 , December 2013,
<http://inl.info.ucl.ac.be/publications/ <http://inl.info.ucl.ac.be/publications/multipath-
multipath-middlebox>. middlebox>.
[I-D.arkko-arch-low-latency] [I-D.arkko-arch-low-latency]
Arkko, J. and J. Tantsura, "Low Latency Applications and Arkko, J. and J. Tantsura, "Low Latency Applications and
the Internet Architecture", draft-arkko-arch-low- the Internet Architecture", draft-arkko-arch-low-
latency-02 (work in progress), October 2017. latency-02 (work in progress), October 2017.
[I-D.boucadair-mptcp-plain-mode] [I-D.boucadair-mptcp-plain-mode]
Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel,
D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R.,
Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U.,
skipping to change at page 52, line 30 skipping to change at page 52, line 18
o 10-13: o 10-13:
* Changes to address the comments from Phil: Add a new section to * Changes to address the comments from Phil: Add a new section to
group data plane considerations in one place + add a new group data plane considerations in one place + add a new
appendix with more details on address modes + rearrange the appendix with more details on address modes + rearrange the
MPTCP text. MPTCP text.
o 14: fixed nits (the shepherd write-up) o 14: fixed nits (the shepherd write-up)
o 15: Various clarifications in the text to address the detailed o 15: Rewrote parts of the text to address the detailed comments
comments provided by Mirja Kuehlewind provided by M. Kuehlewind
Authors' Addresses Authors' Addresses
Olivier Bonaventure (editor) Olivier Bonaventure (editor)
Tessares Tessares
Email: Olivier.Bonaventure@tessares.net Email: Olivier.Bonaventure@tessares.net
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
 End of changes. 11 change blocks. 
35 lines changed or deleted 13 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/