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/