--- 1/draft-ietf-tcpm-converters-15.txt 2020-02-13 10:13:16.615884251 -0800 +++ 2/draft-ietf-tcpm-converters-16.txt 2020-02-13 10:13:16.763888112 -0800 @@ -1,25 +1,25 @@ TCPM Working Group O. Bonaventure, Ed. Internet-Draft Tessares Intended status: Experimental M. Boucadair, Ed. -Expires: August 14, 2020 Orange +Expires: August 16, 2020 Orange S. Gundavelli Cisco S. Seo Korea Telecom B. Hesmans Tessares - February 11, 2020 + February 13, 2020 0-RTT TCP Convert Protocol - draft-ietf-tcpm-converters-15 + draft-ietf-tcpm-converters-16 Abstract This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -103,30 +103,30 @@ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9.1. Privacy & Ingress Filtering . . . . . . . . . . . . . . . 36 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 37 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 38 9.4. Traffic Theft . . . . . . . . . . . . . . . . . . . . . . 38 9.5. Authentication Considerations . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10.1. Convert Service Name . . . . . . . . . . . . . . . . . . 39 10.2. The Convert Protocol (Convert) Parameters . . . . . . . 39 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 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.2. Informative References . . . . . . . . . . . . . . . . . 44 Appendix A. Example Socket API Changes to Support the 0-RTT Convert Protocol . . . . . . . . . . . . . . . . . . 47 A.1. Active Open (Client Side) . . . . . . . . . . . . . . . . 47 - A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 48 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 + A.2. Passive Open (Converter Side) . . . . . . . . . . . . . . 47 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction 1.1. The Problem Transport protocols like TCP evolve regularly [RFC7414]. TCP has been improved in different ways. Some improvements such as changing @@ -1128,21 +1128,21 @@ the destination port number and IP address of the Server, for outgoing connections. For incoming connections destined to a Client serviced via a Transport Converter, these fields convey the source port number and IP address of the SYN packet received by the Transport Converter from the server. The Remote Peer IP Address MUST be encoded as an IPv6 address. IPv4 addresses MUST be encoded using the IPv4-Mapped IPv6 Address format defined in [RFC4291]. Further, Remote Peer IP address field MUST NOT 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 associated TCP connection. 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 address and a remote port (Figure 18), (2) the Extended Connect TLV spans more than 20 bytes and also includes the optional 'TCP Options' field (Figure 19). This field is used to request the advertisement of specific TCP options to the server. @@ -1787,46 +1787,24 @@ the Transport Converters of a domain. 10.2. The Convert Protocol (Convert) Parameters IANA is requested to create a new "The TCP Convert Protocol (Convert) Parameters" registry. The following subsections detail new registries within "The Convert 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 suitable documentation as described in Section 4.6 of [RFC8126] and to verify that the document is permanently and publicly available. + The Designated Expert is also expected to check the clarity of purpose and use of the requested code points. Also, criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a private use, and whether the registration description is clear. IANA must only accept registry updates to the 128-191 range (for both "Convert TLVs" and "Convert Error Messages" sub-registries) from the Designated Experts @@ -2008,22 +1987,22 @@ [Fukuda2011] Fukuda, K., "An Analysis of Longitudinal TCP Passive Measurements (Short Paper)", Traffic Monitoring and Analysis. TMA 2011. Lecture Notes in Computer Science, vol 6613. , 2011. [HotMiddlebox13b] Detal, G., Paasch, C., and O. Bonaventure, "Multipath in the Middle(Box)", HotMiddlebox'13 , December 2013, - . + . [I-D.arkko-arch-low-latency] Arkko, J. and J. Tantsura, "Low Latency Applications and the Internet Architecture", draft-arkko-arch-low- latency-02 (work in progress), October 2017. [I-D.boucadair-mptcp-plain-mode] Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., @@ -2383,22 +2363,22 @@ o 10-13: * Changes to address the comments from Phil: Add a new section to group data plane considerations in one place + add a new appendix with more details on address modes + rearrange the MPTCP text. o 14: fixed nits (the shepherd write-up) - o 15: Various clarifications in the text to address the detailed - comments provided by Mirja Kuehlewind + o 15: Rewrote parts of the text to address the detailed comments + provided by M. Kuehlewind Authors' Addresses Olivier Bonaventure (editor) Tessares Email: Olivier.Bonaventure@tessares.net Mohamed Boucadair (editor) Orange