< draft-herbert-transports-over-udp-00.txt		draft-herbert-transports-over-udp-01.txt >
	INTERNET-DRAFT T. Herbert		INTERNET-DRAFT T. Herbert
	Intended Status: Informational Facebook		Intended Status: Informational Facebook
	Expires: November 20, 2016		Expires: January 7, 2017
	May 19, 2016		July 6, 2016
	Transport layer protocols over UDP		Transport layer protocols over UDP
	draft-herbert-transports-over-udp-00		draft-herbert-transports-over-udp-01
	Abstract		Abstract
	This specification defines a mechanism to encapsulate layer four		This specification defines a mechanism to encapsulate layer 4
	transport protocols over UDP. Such encapsulation facilitates		transport protocols over UDP. Such encapsulation facilitates
	deployment of alternate transport protocols or transport protocol		deployment of alternate transport protocols or transport protocol
	features on the Internet. DTLS can be employed to encrypt the		features on the Internet. DTLS can be employed to encrypt the
	encapsulated transport header in a packet thus minimizing the		encapsulated transport header in a packet thus minimizing the
	exposure of transport layer information to the network and so		exposure of transport layer information to the network and so
	promoting the end-to-end networking principle.		promoting the end-to-end networking principle. Transport connection
			identification can be disassociated from network location (IP
			addresses) to provide connection persistence for mobility and across
			state eviction in NAT.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 44 ¶		skipping to change at page 2, line 4 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright and License Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
	2 Basic encapsulation . . . . . . . . . . . . . . . . . . . . . . 5		2 Basic encapsulation . . . . . . . . . . . . . . . . . . . . . . 5
	2.1 Encapsulation format . . . . . . . . . . . . . . . . . . . . 5		2.1 Encapsulation format . . . . . . . . . . . . . . . . . . . . 5
	2.2 Direct transport protocol encapsulation . . . . . . . . . . 6		2.2 Direct transport protocol encapsulation . . . . . . . . . . 6
	2.3 Encapsulated Extension headers . . . . . . . . . . . . . . . 8		3 Disassociated location encapsulation . . . . . . . . . . . . . 8
	2.4 Obfuscating transport layer protocol number . . . . . . . . 8		3.1 Packet format . . . . . . . . . . . . . . . . . . . . . . . 8
	3 Disassociated location encapsulation . . . . . . . . . . . . . . 9		3.2 Session identifiers . . . . . . . . . . . . . . . . . . . . 9
	3.1 Packet format . . . . . . . . . . . . . . . . . . . . . . . 9		3.3 TOU Identity . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2 TOU Identity . . . . . . . . . . . . . . . . . . . . . . . . 10		3.4 Connection tuple . . . . . . . . . . . . . . . . . . . . . . 10
	3.3 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.5 Session lookup tables . . . . . . . . . . . . . . . . . . . 11
	3.4 Communication roles . . . . . . . . . . . . . . . . . . . . 11		3.6 Session identifier negotiation . . . . . . . . . . . . . . . 11
	3.5 Session identifier format . . . . . . . . . . . . . . . . . 11		3.7 Transport connection lookup . . . . . . . . . . . . . . . . 13
	3.6 Connection tuple . . . . . . . . . . . . . . . . . . . . . . 12		3.8 Established state . . . . . . . . . . . . . . . . . . . . . 14
	3.7 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.9 Learning addresses and ports . . . . . . . . . . . . . . . . 14
	3.7.1 Session lookup tables . . . . . . . . . . . . . . . . . 12		3.10 Closing a sessions . . . . . . . . . . . . . . . . . . . . 14
	3.7.2 Transport connection lookup . . . . . . . . . . . . . . 13		3.11 Session creation deferral . . . . . . . . . . . . . . . . . 14
	3.7.3 Session identifier negotiation . . . . . . . . . . . . . 14		4 TCP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.7.3 Established state . . . . . . . . . . . . . . . . . . . 16		4.1 Mapping TCP state to TOU session state . . . . . . . . . . . 15
	3.7.4 Closing a sessions . . . . . . . . . . . . . . . . . . . 16		4.2 Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.7.5 Session creation deferral . . . . . . . . . . . . . . . 16		4.3 SYN cookies . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.8 TCP over UDP example . . . . . . . . . . . . . . . . . . . . 16		5 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
	4 Security Considerations . . . . . . . . . . . . . . . . . . . . 17		6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17
	5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18		7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7.1 Normative References . . . . . . . . . . . . . . . . . . . 17
	6.1 Normative References . . . . . . . . . . . . . . . . . . . 19		7.2 Informative References . . . . . . . . . . . . . . . . . . 17
	6.2 Informative References . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1 Introduction		1 Introduction
	This specification defines Transport Layer Protocols over UDP (TOU)		This specification defines Transport Layer Protocols over UDP (TOU)
	as generic mechanism to encapsulate IP transport protocols over UDP		as generic mechanism to encapsulate IP transport protocols over UDP
	[RFC0768]. The purpose of TOU to facilitate the use of alternate		[RFC0768]. The purpose of TOU is to facilitate the use of alternate
	protocols and protocol mechanisms over the Internet.		protocols and protocol mechanisms over the Internet.
	The realities of protocol ossification in the Internet, particularly		The realities of protocol ossification in the Internet, particularly
	the infeasibility of deploying IP protocol extensions and alternative		the infeasibility of deploying IP protocol extensions and alternative
	transport protocols (protocols other than UDP and TCP), have been		transport protocols (protocols other than UDP and TCP), have been
	well documented. A direction to resolve protocol ossification is		well documented. A direction to resolve protocol ossification is
	suggested in RFC7663 [RFC7663]:		suggested in RFC7663 [RFC7663]:
	"... putting a transport protocol atop a cryptographic protocol		"... putting a transport protocol atop a cryptographic protocol
	atop UDP resets the transport versus middlebox tussle by making		atop UDP resets the transport versus middlebox tussle by making
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	Accordingly, this specification provides a method to encapsulate		Accordingly, this specification provides a method to encapsulate
	transport layer protocols in UDP and allows encrypting most of the		transport layer protocols in UDP and allows encrypting most of the
	UDP payload including the encapsulated transport headers and		UDP payload including the encapsulated transport headers and
	payloads. This solution espouses a model that only the minimal		payloads. This solution espouses a model that only the minimal
	necessary information about the packet is made visible to the		necessary information about the packet is made visible to the
	network. This exposed information is sufficient to route the packet		network. This exposed information is sufficient to route the packet
	through the network and to demultiplex and decrypt the packet at the		through the network and to demultiplex and decrypt the packet at the
	receiving end host. In particular, the encapsulated protocol and		receiving end host. In particular, the encapsulated protocol and
	related connection state may be rendered invisible to the network.		related connection state may be rendered invisible to the network.
	Additionally, this solution allows encapsulation of IPv6 extension
	headers, particularly destination options, which can then also be		TOU allows "disassociated location" for connection identification at
	hidden from inspection in the network.		the end points. That is the identification of a connection for a
			received packet can be independent of the network layer addresses of
			the packet. Disassociated location enables connection persistence for
			different use cases in mobility and NAT state eviction.
	1.1 Requirements		1.1 Requirements
	The requirements of TOU are:		The requirements of TOU are:
	- Allow encapsulation of any IP transport layer protocol (e.g.		- Allow encapsulation of any IP transport layer protocol (e.g.
	TCP, SCTP, UDP, DCCP, etc.) over UDP.		TCP, SCTP, UDP, DCCP, etc.) over UDP.
	- Work seamlessly with NAT including conditions where the ports		- Work seamlessly with NAT including conditions where the ports
	or addresses being used for an encapsulated connection change.		or addresses being used for an encapsulated connection change.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 10 ¶
	identification from the IP addresses.		identification from the IP addresses.
	- Allow encryption/authentication of the encapsulated transport		- Allow encryption/authentication of the encapsulated transport
	packet including transport headers. The encryption algorithm		packet including transport headers. The encryption algorithm
	should be flexible to allow different methods. Any layer 4		should be flexible to allow different methods. Any layer 4
	information that is exposed in cleartext (such as session		information that is exposed in cleartext (such as session
	identifier defined below) should be authenticated.		identifier defined below) should be authenticated.
	- Information needed for TOU is sent with along with encapsulated		- Information needed for TOU is sent with along with encapsulated
	transport packets, there are no standalone TOU messages. Any		transport packets, there are no standalone TOU messages. Any
	negotiation to set up state for TOU should not require any		negotiation to set up state for TOU should not require
	additional round trips apart from those needed by the		additional round trips apart from those needed by the
	encapsulated transport protocol.		encapsulated transport protocol.
	- The solution must not be biased towards any particular		- The solution must not be biased towards any particular
	implementation method. Specifically, TOU should allow for		implementation method. Specifically, TOU should allow for
	transport protocol implementations in userspace, kernel,		transport protocol implementations in userspace, kernel,
	hardware, etc.		hardware, etc.
	- Minimize changes to transport protocols and implementation. TOU		- Minimize changes to transport protocols and implementation. TOU
	should not require any changes to the transport protocol		should not require any changes to the transport protocol
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 38 ¶
	completely new transport protocols.		completely new transport protocols.
	1.2 Related work		1.2 Related work
	Several transport and encapsulation protocols have been defined to be		Several transport and encapsulation protocols have been defined to be
	encapsulated within UDP [RFC0768]. In this model, the payload of a		encapsulated within UDP [RFC0768]. In this model, the payload of a
	UDP packet contains a protocol header and payload for an encapsulated		UDP packet contains a protocol header and payload for an encapsulated
	protocol.		protocol.
	TCP-over-UDP [I-D.chesire-tcp-over-udp] specifies a method to		TCP-over-UDP [I-D.chesire-tcp-over-udp] specifies a method to
	encapsulate TCP in UDP. That solution essentially casts UDP header		encapsulate TCP in UDP. That solution essentially casts the UDP
	into a modified TCP header so that the port numbers simultaneously		header into a modified TCP header so that the port numbers
	refer to both the UDP and TCP flows. In TOU, the TCP header		simultaneously refer to both the UDP and TCP flows. In TOU, the TCP
	(generally transport header) is encapsulated in UDP without changing		header (generally transport header) is encapsulated in UDP without
	the header format.		changing the header format.
	SCTP-over-UDP [RFC6951] describes a straightforward encapsulation of		SCTP-over-UDP [RFC6951] describes a straightforward encapsulation of
	SCTP in UDP. This work should be leverage-able for use with SCTP in		SCTP in UDP. This work should be leverage-able for use with SCTP in
	TOU. One potential benefit of TOU is that disassociated location		TOU. One potential benefit of TOU is that disassociated location
	encapsulation (described below) could be used to maintain SCTP		encapsulation (described below) could be used to maintain SCTP
	connections when UDP NAT flow mappings change.		connections when UDP NAT flow mappings change.
	QUIC [QUIC] implements a new transport protocol that is intended to		QUIC [QUIC] implements a new transport protocol that is intended to
	run over UDP. QUIC defines a connection identifier that is used to		run over UDP. QUIC defines a connection identifier that is used to
	identify connections at the endpoints independent of IP addresses or		identify connections at the endpoints independent of IP addresses or
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 24 ¶
	in the network. The encapsulation protocol used in TOU (GUE) is		in the network. The encapsulation protocol used in TOU (GUE) is
	extensible to optionally allow information exposure if this proves to		extensible to optionally allow information exposure if this proves to
	be warranted.		be warranted.
	1.3 Terminology		1.3 Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2 Basic encapsulation		2 Basic encapsulation
	Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] is the		Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] is the
	encapsulation protocol for encapsulating transport layer protocols		encapsulation protocol for encapsulating transport layer protocols
	over UDP. TOU can encapsulate both stateless transport protocols		over UDP. TOU can encapsulate both stateless transport protocols
	(such as UDP, DCCP, UDP-lite) and stateful protocols (like TCP and		(e.g. UDP, DCCP, UDP-lite) and stateful protocols (e.g TCP, SCTP).
	SCTP). Additionally, TOU may encapsulate IPv6 Destination Options
	extension headers.
	2.1 Encapsulation format		2.1 Encapsulation format
	The general format of TOU encapsulation using GUE (UDP) is:		The general format of TOU encapsulation using GUE (UDP) is:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	|0x0|C| Hlen | Proto/ctype | Flags |		|0x0|C| Hlen | Proto/ctype | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ GUE Fields (optional) ~		~ GUE Fields (optional) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Transport layer packet ~		~ Transport layer packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Proto/ctype contains the IP protocol number of the GUE payload, in		Proto/ctype contains the IP protocol number of the GUE payload, in
	the case of TOU this contains the protocol number of a transport		the case of TOU this contains the protocol number of a transport
	protocol (e.g. for TCP over UDP the value is 6). The C bit (control)		protocol (e.g. for TCP over UDP the value is 6). The C bit (control)
	is not used with TOU indicating that GUE is carrying a data packet.		is zero for TOU indicating that GUE is carrying a data packet.
	The flags and fields may be set for TOU as described below. Certain		Certain general GUE flags and fields, such as remote checksum offload
	general GUE flags-fields, such as remote checksum offload or		or fragmentation, may be useful for TOU but not required for its
	fragmentation, may be useful for TOU but not required for its
	operation. The example packet formats in the remainder of the this		operation. The example packet formats in the remainder of the this
	document do not indicate use of any flags or fields other than those		document do not indicate use of any flags or fields other than those
	required for TOU operation.		required for TOU operation.
	The Hlen contains the GUE header length in 32-bit words, including		The Hlen contains the GUE header length in 32-bit words, including
	optional fields but not the first four bytes of the header. Computed		optional fields but not the first four bytes of the header. Computed
	as (header_len - 4) / 4. All GUE headers are a multiple of four bytes		as (header_len - 4) / 4. All GUE headers are a multiple of four bytes
	in length. Maximum header length is 128 bytes.		in length. Maximum header length is 128 bytes.
	2.2 Direct transport protocol encapsulation		2.2 Direct transport protocol encapsulation
	Transport protocol packets can be encapsulated directly in GUE. The		Transport protocol packets can be encapsulated directly in GUE. The
	simplest format of this is:		simplest format of this is:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	|0x0|0| 0 | Protocol | 0 |		|0x0|0| 0 | Protocol | 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Transport layer packet ~		~ Transport layer packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For example, TCP over UDP could be encapsulated as:		For example, TCP over UDP could be encapsulated as:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	|0x0|0| 0 | 6 | 0 |		|0x0|0| 0 | 6 | 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source Port | Destination Port |		| Source Port | Destination Port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Sequence Number |		| Sequence Number | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Acknowledgment Number |		| Acknowledgment Number | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Data | |U|A|P|R|S|F| |		| Data | |U|A|P|R|S|F| | TCP
	| Offset| Reserved |R|C|S|S|Y|I| Window |		| Offset| Reserved |R|C|S|S|Y|I| Window | |
	| | |G|K|H|T|N|N| |		| | |G|K|H|T|N|N| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Checksum | Urgent Pointer |		| Checksum | Urgent Pointer | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| Options | Padding |		| Options | Padding | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	| data |		| data |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For TOU the flow identification of the encapsulated transport packet		For TOU the flow identification of the encapsulated transport packet
	includes the encapsulating UDP source and destination port. For a		includes the encapsulating UDP source and destination port. For a
	transport protocol that uses the canonical ports for flow		transport protocol that uses the canonical ports for flow
	identification, flows are identified by the 7-tuple:		identification, flows are identified by the 7-tuple:
	<Protocol, SrcIP, DstIP, SrcPort, DstPort, SrcUport, DstUport>		<Protocol, SrcIP, DstIP, SrcPort, DstPort, SrcUport, DstUport>
	Where protocol refers to the encapsulated protocol (taken from the		Where protocol refers to the encapsulated protocol (taken from the
	Proto/ctype field in the GUE header), SrcIP and DstIP refer to the		Proto/ctype field in the GUE header), SrcIP and DstIP refer to the
	source and destination IP addresses, SrcPort and DstPort refer to the		source and destination IP addresses, SrcPort and DstPort refer to the
	respective ports in the encapsulated transport header, SrcUport and		respective ports in the encapsulated transport header, SrcUport and
	DstUport refer to the source and destination ports in the		DstUport refer to the source and destination ports in the
	encapsulating (outer) UDP header.		encapsulating (outer) UDP header.
	To reply to a transport layer packet encapsulated in TOU, a		To reply to a transport layer packet encapsulated in TOU, a
	corresponding TOU packet is sent where the source and destination		corresponding TOU packet is sent where the source and destination
	addresses, source and destination UDP ports, and source and		addresses, source and destination UDP ports, and source and
	destination transport ports are swapped. The outer addresses and		destination transport ports are swapped. The outer addresses and
	ports may have undergone NAT so that the return path must also go		ports may have undergone NAT so that the return path must also go
	through NAT. To ensure reachabilty, a host MUST reply to a TOU		through NAT. To ensure reachabilty, a host must reply to a TOU
	encapsulated with a corresponding TOU packet.		encapsulated with a corresponding TOU packet.
	Stateful protocol connections are identified by the 7-tuple as		Stateful protocol connections are identified by the 7-tuple as
	defined above. Since the UDP ports are included in the connection		defined above. Since the UDP ports are included in the connection
	tuples, the typical transport layer 5-tuple (<Protocol, SrcIP, DstIP,		tuples, the typical transport layer 5-tuple (<Protocol, SrcIP, DstIP,
	Sport, Dport>) of a TOU connection does not need to be unique with		Sport, Dport>) of a TOU connection does not need to be unique with
	those of non-TOU connections.		those of non-TOU connections.
	The inner and outer ports have no correlation. The lengths and		The inner and outer ports have no correlation. The lengths and
	checksums must also be set correctly in each header layer. In the		checksums must also be set correctly in each header layer. In the
	case of UDP over UDP for IPv6 that both the inner and outer checksum		case of UDP-over-UDP for IPv6 both the inner and outer checksum must
	must be set.		be set.
	For encapsulated transport packets that define a checksum that		For encapsulated transport packets that define a checksum that
	includes a pseudo header (e.g. TCP) the checksum pseudo header		includes a pseudo header (e.g. TCP), the checksum pseudo header is
	remains the same. The pseudo header includes the IP addresses and		changed to only cover the transport layer ports and not the IP
	transport layer ports. In particular the UDP ports are not included		addresses. Note that the addresses in a packet traversing NAT may be
	in that pseudo header and the UDP checksum covers the UDP ports.		changed so that the pseudo header checksum for TOU would no longer be
			correct-- not including the addresses in the pseudo header checksum
	2.3 Encapsulated Extension headers		avoids these bad checksums. In this case the IP addresses are already
			covered in IPv4 header checksum or the outer UDP checksum for IPv6.
	For IPv6, encapsulation of IPv6 Fragment and Destination Options
	extension headers is permitted. These options are processed at a
	destination after processing the UDP and GUE encapsulation headers.
	Logically, the encapsulation headers are treated as though they are
	themselves extension headers, so processing an encapsulated extension
	header is done in the context of being an extension header within the
	corresponding IP layer packet.
	Since encapsulated extension headers are contained within the UDP
	payload (and the payload may often be encrypted) there is no
	allowance that intermediate devices parse these headers. Extension
	headers that require visibility to intermediate nodes, such as hop by
	hop option or routing header, cannot be encapsulated in TOU.
	2.4 Obfuscating transport layer protocol number
	The GUE header indicates the IP protocol of the encapsulated packet.
	This is either contained in the Proto/ctype field of the primary GUE
	header, or is contained in the Payload Type field of a GUE Transform
	Field (used to encrypt the payload with DTLS). If the protocol must
	be obfuscated, that is the transport protocol in use must be hidden
	from the network, then a trivial destination options can be used.
	The PadN destination option can be used to encode the transport
	protocol as a next header of an extension header (and maintain
	alignment of encapsulated transport headers). The Proto/ctype field
	or Payload Type field of the GUE Transform field is set to 60 to
	indicate that the first encapsulated header is a Destination Options
	extension header.
	The format of the extension header is below:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | 2 | 1 | 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For IPv4, it is permitted in TOU to used this precise destination
	option to contain the obfuscated protocol number. In this case next
	header must refer to a valid IP protocol for IPv4. No other extension
	headers or destination options are permitted with IPv4.
	3 Disassociated location encapsulation		3 Disassociated location encapsulation
	TOU allows transport protocol encapsulation where the location is		TOU allows transport protocol encapsulation where the location is
	disassociated from flow identification. That is a connection can		disassociated from flow identification. That is a connection can
	remain functional even if the addresses or encapsulation ports		remain functional even if the addresses or encapsulation ports
	change. A common use case will be when NAT state mappings for UDP		change. A common use case will be when NAT state mappings for UDP
	flows change. TOU includes a facility to negotiate a shared session		flows changing. TOU includes a facility to negotiate a shared session
	identifier for a transport connection which is sent as part of the		identifier for a transport connection which is sent as part of the
	encapsulation of packets for the connection. The session identifier		encapsulation of packets for the connection. The session identifier
	is used in connection lookup instead of the IP addresses and		is used in connection lookup instead of the IP addresses and
	encapsulation ports.		encapsulation ports.
	This section describes the protocol formats and operational aspects		This section describes the protocol formats and operational aspects
	of TOU for disassociated location transport protocol encapsulation.		of TOU for disassociated location transport protocol encapsulation.
	3.1 Packet format		3.1 Packet format
	Transport layer packets are encapsulated using Generic UDP		Transport layer packets are encapsulated using Generic UDP
	Encapsulation (GUE). Two GUE flags and one field are defined for TOU.		Encapsulation (GUE). Two GUE flags and two field are defined for TOU.
	The format of this encapsulation is illustrated below:		The format of this encapsulation is illustrated below:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	|0x0|0| 2 | Protocol | 0 |S|I| 0 |		|0x0|0| Hlen | Protocol | 0 |S|D| 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Session identifier +		+ Source session identifier +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Transport layer packet ~		+ Destination session identifier +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Transport layer packet ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	S: Session identifier bit. This indicates the presence of the		S: Source session identifier bit: This indicates the presence of
	session identifier field.		the source session identifier field.
	I: Initiator bit. When set indicates that the packet is sent from		D: Destination session identifier bit. This indicates the presence
	the initiator side of the session, when not set indicates the		of the destination session identifier field.
	packet is sent from the target.
	Session identifier: 64-bit field that holds the session		Source session identifier: 64-bit field that holds the source
	identifier.		(sender's) session identifier.
	3.2 TOU Identity		Destination session identifier: 64-bit field that holds the
			destination (receiver's) session identifier.
			3.2 Session identifiers
			A session represents a flow of packets that correspond to the same
			transport layer connection. Sessions are identified by a pair of
			session identifiers where both sides of a connection create session
			identifier for the session. Session identifier negotiation
			establishes the session pair between two hosts so that each host will
			know both the locally created session identifier as well as the one
			created by the remote peer. When a packet is sent on a session the
			peer's session identifier is included in the packet, on reception the
			received session identifier is matched to a session.
			A session has identifier has two uses:
			1) A location independent representation of the identities in the
			communication.
			2) Security context for encryption or authentication of the
			encapsulated packet.
			Each node defines a namespace over its communications. Local session
			identifiers must be unique in the name space of each node in the
			communication. Each side of a transport communication creates a local
			session identifier for a session.
			3.3 TOU Identity
	TOU disassociates the IP address of a peer from the abstraction of		TOU disassociates the IP address of a peer from the abstraction of
	transport protocol endpoint. A peer's identity is implicit in a		transport protocol endpoint. A peer's identity is implicit in session
	session identifier that is established between the two nodes of a		identifiers that are established between the two nodes of a
	communications session (corresponding to one transport connection).		communications session. All packets sent in the session contain a
	All packets sent in the session contain a session identifier. The		session identifier. Each local session identifier is unique among all
	session identifier is unique among all other communications for a		other communications for a node, so the node can use it to
	node, so the node can use it to distinguish between different		distinguish between different communicating peers. A session
	communicating peers. A session identifier is meaningful only to the		identifier is meaningful only to the nodes that share it in a
	nodes that share it in a communication, externally to those nodes it		communication, externally to those nodes it has no defined meaning.
	has no defined meaning. Since session identifiers are disassociated		Since session identifiers are disassociated with IP addresses, no
	with IP addresses, no relevant information can consistently be		relevant information can consistently be inferred in the network. Two
	inferred in the network. Two packets containing the same session		packets containing the same session identifier but use different
	identifier but use different addresses may in fact refer to the same		addresses may in fact refer to the same session. Two packets with the
	session. Two packets with the same session identifier and same		same session identifier and same addresses (and UDP ports) that are
	addresses (and UDP ports) that are temporally observed probably, but		temporally observed probably, but not definitely, refer to the same
	not definitely, refer to the same session.		session. Note that sessions identifiers are not symmetric for both
			directions of a flow.
	Transport layer communications occurs between two nodes in a network.		Transport layer communications occurs between two nodes in a network.
			Nodes in this context are not restricted to hosts, any application or
	Nodes in this context is not restricted to hosts, any application or
	process can be considered a node. A node is unambiguously reachable		process can be considered a node. A node is unambiguously reachable
	and distinguishable from other nodes, that is if a packet is received		and distinguishable from other nodes, that is if a packet is received
	it must be deterministic as to which node on the host the packet		it must be deterministic as to which node on the host the packet
	belongs. For a server application that listens on one or more UDP		belongs. For a server application that listens on one or more UDP
	ports for TOU packets, each listener port instance can be considered		ports for TOU packets, each listener port instance can be considered
	a node. For a client application, each peer destination (IP address,		a node. For a client application, each peer destination (IP address,
	TOU port) might be considered to belong to a different node, however		TOU port) might be considered to belong to a different node, however
	for simplicity the whole client application could considered as one		for simplicity the whole client application could considered as one
	node.		node.
	3.3 Sessions		3.4 Connection tuple
	TOU uses sessions to enable communications between two nodes using an		The local session identifier, instead of IP addresses, provides the
	encapsulated transport layer protocol. A session is represented by a		endpoint identity of a transport layer connection. As mentioned this
	session identifier. The session identifier has two uses:		allows the IP addresses associated with the endpoint addresses to
			change without breaking the connection. The transport layer tuple
			that identifies a specific connection thus changes accordingly to use
			the session identifier instead of addresses.
	1) An location independent representation of the identities in the		For a transport protocol that uses canonical ports for flow
	communication.		identification, a flow in TOU is identified at receive by the 4-
			tuple:
	2) Security context for encryption or authentication of the		<protocol, destination SID, source port, destination port>
	encapsulated packet.
	Each node defines a namespace over its communications. Session		Where the source and destination ports refer to the encapsulated
	identifiers must be unique in the name space of each node in the		transport layer ports in a TOU packet.
	communication. Each side of a communication contributes to the
	session identifier so that the identifier is unique relative to each
	node.
	3.4 Communication roles		A session is created for each transport layer connection. A single
			session could be used to multiplex several connections over the same
			session however that is not recommended. If such semantics are needed
			the transport layer protocol can provide that (SCTP sub-streams for
			instance). A transport layer connection may be sent using different
			session identifiers during its lifetime. This may be useful for
			instance to limit tracking of long lived transport connections.
	At the start of a communications the session identifier must be		3.5 Session lookup tables
	negotiated between two nodes. The node that initiates a communication
	is the "initiator" and its peer is the "target". The roles are
	persistent for the lifetime of the session, each packet in the
	session is marked to indicate whether it was sent by the initiator or
	the target.
	3.5 Session identifier format		TOU logically uses two different tables to perform session lookup.:
	A session identifier is a 64-bit value that is sent in each packet of		- Local session table
	a session. To ensure relative uniqueness within both nodes of a
	communication, each side contributes part of the session identifier.
	A session identifier negotiation is defined to create the shared
	session identifier.
	The session identifier is split into a 32-bit initiator component and		The tuple used to match in this table is:
	a 32-bit target component as illustrated below:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		<srcIP, dstIP, udp_sport, udp_dport, source_SID>
	| Initiator component |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Target component |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Initiator and Target components of the Session Identifier are		- Established sessions table
	always non-zero except in the case that session identifier
	negotiation is in progress in which case an initiator sends a session
	identifier with a Target component that is zero.
	3.6 Connection tuple		Lookups in the established sessions table are performed on the
			session identifier of a received packet. The lookup tuple in
			established sessions table is trivially:
	The session identifier, instead of IP addresses, provides the		<destination_SID>
	endpoint identity of a transport layer connection. As mentioned this
	allows the IP addresses associated with the endpoint addresses to
	change without breaking the connection. The transport layer tuple
	that identifies a specific connection thus changes accordingly to use
	the session identifier instead of addresses.
	For a transport protocol that uses canonical ports for flow		The session negotiation table is consulted when a TOU packet is
	identification, a flow in TOU is identified by the 4-tuple:		received where the S bit is set and the D bit is not set-- most
			commonly this occurs when session negotiation is being performed. The
			established sessions table is consulted when the D bit is set in a
			TOU packet.
	<protocol, session, source port, destination port>		3.6 Session identifier negotiation
	Where the source and destination ports refer to the encapsulated		The process of session identifier negotiation is:
	transport layer ports in a TOU packet.
	A session is created for each transport layer connection, there is no		1) The initiating host creates its session state and local session
	concept of multiplexing different transport connections over a single		identifier. The process is:
	sessions. If such semantics are needed the transport layer protocol
	can provide that (SCTP sub-streams for instance).
	3.7 Operation		a) Create a 64-bit random number
	This section describes the operation of TOU using disassociated		b) Check the local sessions table if a state with a local
	location encapsulation. TOU state, such as session, is created and		session identifier of the same value exists
	destroyed in conjunction with corresponding state changes in the
	connection of an encapsulated transport protocol.
	3.7.1 Session lookup tables		- If no session has that same local identifier it is
			considered unique. Process to next step.
	TOU logically uses two different tables to perform session lookup.:		- Else, the proposed value is not unique. Repeat the process
			(got back to step a.)
	- Session negotiation table		2) Send a TOU packet with the S bit set and the source session
			identifier set to the value created in step 1.
	The tuple used to match in this table is:		3) Peer host receives the TOU packet. Since the S bit is set and
			the D bit is not set this indicates session identifier
			negotiation.
	<srcIP, dstIP, udp_sport, udp_dport, ISID>		4) The target creates a proposed session identifier. This is based
			on a secure hash over the 6-tuple:
	Where ISID refers to the initiator component of the session		<srcIP, dstIP, udp_sport, udp_dport, source_SID, gen>
	identifier, the target component is not considered for lookup
	in the session negotiation table.
	- Established sessions table		srcIP, dstIP, udp_sport, udp_dport, and source_SID are the
			respective values in the packet. gen is a generation number for
			the algorithm. For the first invocation this value is zero. The
			hash calculation should include a randomly seeded key.
	Lookups in the established sessions table are performed on the		5) The target performs a lookup on the proposed local session
	session identifier of a received packet. The lookup tuple in		identifier. There are three possibilities:
	established sessions table is trivially:
	<Session identifier>		- If no session is found with the same identifier proceed with
			the next step. This is a new negotiation.
	Before session negotiation completes connection lookup is always		- If a matching session is found and it is less than N seconds
	performed on the session negotiation table using fixed location mode		old and the saved local IP address, remote IP adress, local
	(that is the addresses, ports, and initiator component of the session		UDP port, remote UDP port, and peer SID match the dstIP,
	identifier are matched).		srcIP, udp_dport, udp_sport, and source_SID in the packet--
			then the session negotiation is considered a retransmission.
			Goto step 7.
	The target must consult the session negotiation table when the Target		- Else, the proposed local session identifier is not unique.
	session identifier component of a received packet is zero. It		Repeat the process with an incremented generation number
	consults the established sessions table when the Target component of		(goto step 4).
	session identifier is non-zero.
	The initiator first consults the established sessions table for every		6) Create a new session state. Save the IP address, UDP port
	packet. If an entry is not found for the session identifier then the		numbers, the source_SID as the remoteSID, and the created SID
	session negotiation table is consulted. Note that if the ISID is		value as the local SID.
	unique for all connections in the node then the two tables can be
	consolidated into a single one which is keyed solely by ISID. So in
	this method the session lookup process is:
	1) Initiator performs a lookup based on ISID. If no entry is found		7) Send a response packet (e.g. a TCP SYN-ACK) with both the S bit
	then the session does not exist in the node's namespace.		and the D bit set. The source session identifier is the local
			session identifier, the destination is the remote session
			identifier that was learned from the initiator.
	2) If the entry contains a non-zero TSID and the TSID matches that		8) When the intitiator receives the packet it will match the local
	received in the packet then this entry is a match. If the TSID		session based on the destination session identifier. The source
	doesn't match then the session is not matched.		session identifier is recorded in the session state.
	3) Otherwise the the entry contains a zero value for the transport		The initiator responds (e.g. final ACK in TCP 3WHS) with both
	component of the session ID so session negotiation is in		the source and destination identifiers set (to allow use with
	progress. Perform fixed location verification by matching the		SYN cookies). The destination session identifier contains the
	received address and port numbers to the recorded values. If		value learned from the target.
	they all match, then the session is matched. The recorded TSID
	is set to the non-zero value received in the packet which		9) When the target receives a TOU packet with the D bit set and
	implicitly moves the entry to the established sessions table.		matches a session, this indicates that session negotiation is
			complete. Any subsequent packets sent by either the target or
			initiator will only have the destination session identifer set.
			3.7 Transport connection lookup
	3.7.2 Transport connection lookup
	A connected transport protocol typically maintains one or more tables		A connected transport protocol typically maintains one or more tables
	of connections (i.e. multiple tables may be used for different		of connections (i.e. multiple tables may be used for different
	connection states). In lieu of using IP addresses, connection lookup		connection states). In lieu of using IP addresses, connection lookup
	is performed in TOU using the session (specifically a reference to		is performed in TOU using the session (specifically a reference to
	the session).		the session).
	For a transport protocol using the canonical definition of ports, the		For a transport protocol using the canonical definition of ports, the
	tuple for matching connections in TOU becomes:		tuple for matching connections in TOU becomes:
	<Protocol, Session, Source-port, Destination-port>		<Protocol, Session, Source-port, Destination-port>
	skipping to change at page 14, line 28 ¶		skipping to change at page 14, line 5 ¶
	1) A lookup is performed to find the session.		1) A lookup is performed to find the session.
	2) A connection lookup is performed using the session found in #1		2) A connection lookup is performed using the session found in #1
	in the lookup tuple.		in the lookup tuple.
	Note that TOU requires that a separate session is created for each		Note that TOU requires that a separate session is created for each
	encapsulated transport layer connection. This allows consolidating		encapsulated transport layer connection. This allows consolidating
	session and connection lookup by including a reference to the		session and connection lookup by including a reference to the
	transport connection in the session state.		transport connection in the session state.
	3.7.3 Session identifier negotiation		3.8 Established state
	A session must be negotiated between two nodes to create a unique
	session identifier within the namespace of each node. Session
	negotiation is initiated by one node which assumes the role of
	"initiator", and its peer node has the role of "target". Typically,
	initiators would be clients and targets are servers. Initiating a
	session identifier negotiation coincides with the start of connection
	establishment in the encapsulated transport protocol.
	During session identifier negotiation session lookup is be done in
	fixed location mode (IP address, UDP ports, ISID must be matched) for
	either the initiator or the target.
	The steps for session negotiation are:
	1) Initiator creates initial packet for sending to a target with
	an encapsulated transport packet. The transport packet must
	contain an initial packet for establishing a transport layer
	connection (e.g. a TCP-SYN). The initiator component of the
	session identifier is set to a random value that makes it
	unique with other existing sessions in the node; the target
	component is set to zero.
	2) Target receives packet. Since the target portion of the session
	identifier is zero this indicates a session identifier
	negotiation. Target performs a lookup in the session identifier
	negotiation table in fixed location mode. The session
	identifier negotiation table records session negotiations that
	are in progress.
	- If an entry is not found in the session negotiation table
	then this is a new negotiation. The target creates the target
	portion of the session identifier such that whole session
	identifier is unique in the target node's name space. Next
	the target creates a corresponding entry in the session
	negotiation table.
	- If an entry is found, then this is a retransmission of a
	session negotiation packet. The target value saved in the
	entry indicates the value to set in session identifier for
	reply packets.
	3) Target responds with a transport protocol packet. In the case
	of TCP connection establishment this will be a SYN-ACK. The
	fully qualified session identifier is used in the TOU
	encapsulation.
	4) Initiator receives response packet (SYN-ACK). It performs a
	session lookup using the session identifier.
	- First the established sessions table is consulted. If an
	entry for the session identifier is present in the table then
	the session is matched.
	- If no entry is found in the established sessions table, then
	the session negotiation table is consulted. The initiator
	component is used for lookup. If a matching entry is found,
	the addresses and ports in the packet must be verified to
	match the entry using fixed location mode.
	5) Initiator sends an ACK (completing three-way handshake in the
	transport protocol). The fully qualified session identifier is
	used in the TOU encapsulation.
	6) Target receives ACK. Target moves the session entry from the
	session negotiation table to the established sessions table.
	Note that after a session moves to the established sessions table in
	a target, it is possible that an out of order retransmission of an
	initial packet (e.g. SYN) may be received for the session. The TSID
	of the packet is zero and the target will not find the session in the
	session identifier negotiation table. The target will treat this as
	new connection and reply to the intiator with different session
	identfier (TSID differs) than that for the established session. When
	the initiator receives the reply packet it may match the ISID to the
	established session, but the TSID in the received packet differs from
	the recorded one so the packet is dropped. The spurious session in
	session negotiation table of the target will be removed when the
	underlying connection times out. Alternatively, the target may
	maintain an entry in the session negotiation table for some period of
	time to identify retransmitted session negotiation packets.
	Since the initiator component is assumed to be unique for all created
	sessions, the session negotiation table and established tables can be
	consolodated into a single table keyed by the initiator component of
	the session identifier.
	3.7.3 Established state
	After session establishment, which normally corresponds to transport		After session establishment, which normally corresponds to transport
	protocol connection being established, running operations commences.		protocol connection being established, running operations commences.
	Each packet sent on the underlying connection will be encapsulated		Each packet sent on the underlying connection will be encapsulated
	using TOU. The 64-bit session identifier is set by both sides of the		using TOU. The 64-bit destination session identifier is set in
	connection, and each side sets the Initiator bit (I bit in the GUE		packets by both sides of the connection to the peer's session
	header) accordingly-- the initiator sets I bit in all packets of the		identifier. When either side receives a packet a lookup is performed
	connection, the target clears the bit. When either side receives a		on the destination session identifier in the established sessions
	packet a lookup is performed on the session identifier in the		table.
	established sessions table.
	3.7.4 Closing a sessions		3.9 Learning addresses and ports
			After session negotiation is complete connection identification is
			disassociated from the network layer, however a host still needs to
			know the IP address and destination UDP port to send a TOU packets to
			a destination. These are learned from received packets and are
			recorded in the session state.
			The destination address and port for a session can change over time
			(for example a NAT may remap the UDP flow to use different addresses
			and ports). The peer address and port are inferred from the source
			address and port in packets received over the session. When a packet
			on a session is received and has been fully validated (session state
			matched and authenticity is verified by security mechanisms such as
			DTLS), if the source address or source port does not match those
			recorded in the session state then the new values are saved in the
			session state; packets subsequently sent will use the new address and
			port for the destination.
			3.10 Closing a sessions
	A session is closed when the underlying transport connection closes		A session is closed when the underlying transport connection closes
	(e.g. a TCP connection moves to closed state).		(e.g. a TCP connection moves to closed state).
	3.7.5 Session creation deferral		3.11 Session creation deferral
	When a target receives an initial packet (e.g. a TCP SYN with a		When a target receives an initial packet (e.g. a TCP SYN with with
	session identifier whose target component is zero) creating a session		only source session identifier set in the GUE header) creating a
	state may be deferred until until the transport layer creates its		session state may be deferred until the transport layer creates its
	state. If the transport layer does not create a state (e.g. the SYN		state. If the transport layer does not create a state (e.g. the SYN
	generated a reset) no TOU state is created. The reply packet is		generated a reset) no session state is created. The reply packet is
	returned with TOU using the same session identifier received in the		returned with TOU using the same session identifier received in the
	request (in this case target component of the session identifier is		request (in this case the source session identifier is no set).
	zero).
	3.8 TCP over UDP example		4 TCP over UDP
	TCP over UDP implicitly allows nodes using TCP to be multihomed and		TCP over UDP implicitly allows nodes using TCP to be multihomed and
	mobile.		mobile.
	For SYN packets the target session identifier must be set to zero.		4.1 Mapping TCP state to TOU session state
	The initiator's session identifier is set to a value that is unique
	among all connections in the client name space.
	The initiator must set the I bit for all packet sent for a
	connection. SYN packets (no ACK) MUST contain a zero value in the
	Target session identifier field. If a SYN packet with a nonzero
	Target Session Identifier is received from an initiator the packet
	must be dropped. All other packets sent by the initiator must have
	the Target Session Identifier set to nonzero, if a non-SYN packet is
	received from an initiator (I bit is set) with a nonzero Target
	session identifier then the packet must be dropped.
	The target must clear the I bit for all packet sent for a connection.
	All packet sent by a target (I bit not set) must have a nonzero
	Target session identifier except in the case that the target is
	rejecting a connection request (e.g. a TCP-RST is sent in reply to a
	TCP-SYN).
	Note that simultaneous opens cannot happen. A simultaneous connection
	attempt between two nodes with same TCP ports will result in two
	different sessions with two different identifiers.
	Session state can be created in conjunction with creating TCP state		Session state can be created in conjunction with creating TCP state
	(TCP PCB for instance). If a TCP packet is received for which no		(TCP PCB for instance). If a TCP packet is received for which no
	state exists, a rely to the packet is sent without creating session		state exists, a reply to the packet is sent without creating session
	state. For instance this would happen is a TCP stack sends a TCP-RST		state. For instance this would happen is a TCP stack sends a TCP-RST
	in response to a SYN.		in response to a SYN.
	In the cases of SYN cookies, a target may send a SYN-ACK without		For SYN packets the destination session identifier must be zero (D
	creating a session state. A session identifier should be created so		bit is not set). The source session identifier is set to a value that
	that it is unique with other established sessions or any values used		is unique among all connections in the client name space as described
	in other SYN responses within last N minutes. When a client responds		in section 3.6.
	to the SYN cookie ACK and the server verifies the SYN cookie is valid
	(including the session identifier) the TCP connection state and		Replies to SYN, ie. SYN-ACK packets, must have both the source and
	session state can then be created using the session identifier		destination identifiers set (D bit and S bit are set). The source
	provided in the received packet.		identifier on the responding host is created as described in section
			3.6.
			The final ACK to complete TWS and all packets sent in established
			state and beyond only include the destination session (only the D bit
			is set).
			Note that simultaneous opens cannot happen. A simultaneous connection
			attempt between two nodes with same TCP ports will result in two
			different sessions with two different identifiers.
	The session state is destroyed when the underlying TCP connection		The session state is destroyed when the underlying TCP connection
	moves to closed state. In the initiator this entails freeing session		moves to closed state. In the initiator this entails freeing session
	identifier to be used with new connections. At the target, the full		identifier to be used with new connections. At the target, the full
	session identifier is free to be reused.		session identifier is free to be reused.
	4 Security Considerations		4.2 Resets
			TCP resets may be sent with either the destination session identifier
			set or the source session identifier set. If the reset is being sent
			based on an existing connection state with negotiated session
			identifiers, then the peer session identifier is used as the
			destination session identifier in the reset packet. If the reset is
			generated without any associated session state, then the destination
			session identifier in the packet that generated the reset is used as
			the source session identifer in the reset packet.
			4.3 SYN cookies
			For SYN cookies, a target may send a SYN-ACK without creating a
			session state. A session identifier should be created so that it is
			unique with other established sessions or any values used in other
			SYN responses within last N minutes. When a client responds to the
			SYN cookie ACK and the server verifies the SYN cookie is valid
			(including the session identifier) the TCP connection state and
			session state can then be created using the session identifier
			provided in the received packet. As described in section 3.6 the
			session identifier created in response to a SYN packet is based on a
			secure hash and so is useful for validation of SYN cookies.
			5 Security Considerations
	Using strong end to end security is recommended with TOU. In		Using strong end to end security is recommended with TOU. In
	disassociated location encapsulation security is extremely important		disassociated location encapsulation security is extremely important
	to prevent spoofing and connection hijacking (assuming that an		to prevent spoofing and connection hijacking (assuming that an
	attacker can deduce the session identifiers). In order to thwart this		attacker can deduce the session identifiers). In order to thwart this
	end to end security should be established that authenticates the		end to end security should be established that authenticates the
	nodes in a communication.		nodes in a communication.
	Security is provided using DTLS [RFC6347] and the GUE Payload		Security is provided using DTLS [RFC6347] and the GUE Payload
	Transform Field [I-D.hy-gue-4-secure-transport]. The encapsulation		Transform Field [I-D.hy-gue-4-secure-transport]. The encapsulation
	format of TOU with DTLS is:		format of TOU with DTLS is:
	0 1 2 3		0 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	|0x0|0| 3 | Protocol | 0 |T|S|I| 0 |		|0x0|0| Hlen | 59 | 0 |T|S|D| 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Payload Transform Field |		| Payload Transform Field |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Session identifier (optional) +		+ Source session identifier +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Encrypted transport layer packet ~		+ Destination session identifier +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Encrypted transport layer packet ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The T flag bit in the GUE header indicates the presence of the		The T flag bit in the GUE header indicates the presence of the
	Payload Transform Field.		Payload Transform Field.
	The Payload Transform field is defined as:		The Payload Transform field is defined as:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Payload Type | Reserved |		| Type | Payload Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: Payload transform codepoint. 0x1 indicates DTLS.		Type: Payload transform codepoint. 0x1 indicates DTLS.
	Payload type: IP protocol of the encrypted payload.		Payload type: IP protocol of the encrypted payload.
	The Proto/type field in the GUE header is set to 59 "no next header"		The Proto/type field in the GUE header is set to 59 "no next header"
	to indicate that the GUE payload cannot be parsed as an IP protocol.		to indicate that the GUE payload cannot be parsed as an IP protocol.
	5 IANA Considerations		6 IANA Considerations
	Two bits and one field in the GUE header are reserved for TOU use.		Two bits and one field in the GUE header are reserved for TOU use.
	Port 6080 has been reserved for GUE, however we will request another		Port 6080 has been reserved for GUE, however we will request another
	port specficilly for TOU. GUE would be used on this TOU port, however		port specfically for TOU. GUE would be used on this TOU port, however
	only TOU that encapsulates a transport protocol with TCP-frienly		only TOU that encapsulates a transport protocol with TCP-friendly
	congestion control is used. Thus traffic destined to the TOU port (as		congestion control is used. Thus traffic destined to the TOU port (as
	well as traffic in the reverse direction of a flow) can be assumed to		well as traffic in the reverse direction of a flow) can be assumed to
	be properly congestion controlled and not suject to reflection or		be properly congestion controlled and not subject to reflection or
	other attacks common to some uses of UDP.		other attacks common to some uses of UDP.
	6 References		7 References
	6.1 Normative References		7.1 Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980, <http://www.rfc-editor.org/info/rfc768>.		August 1980, <http://www.rfc-editor.org/info/rfc768>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012,		Security Version 1.2", RFC 6347, January 2012,
	<http://www.rfc-editor.org/info/rfc6347>.		<http://www.rfc-editor.org/info/rfc6347>.
	6.2 Informative References		7.2 Informative References
	[RFC7663] B. Trammell, Ed., M. Kuehlewind, Ed. "Report from the IAB		[RFC7663] B. Trammell, Ed., M. Kuehlewind, Ed. "Report from the IAB
	Workshop on Stack Evolution in a Middlebox Internet		Workshop on Stack Evolution in a Middlebox Internet
	(SEMI)}, October 2015.		(SEMI)}, October 2015.
	[I-D.chesire-tcp-over-udp] Chesire, S., Graessley, J., and McGuire,		[I-D.chesire-tcp-over-udp] Chesire, S., Graessley, J., and McGuire,
	R., "Encapsulation of TCP and other Transport Protocols		R., "Encapsulation of TCP and other Transport Protocols
	over UDP", June 2013		over UDP", June 2013
	[QUIC] Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP",		[QUIC] Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP",
End of changes. 88 change blocks.
	462 lines changed or deleted		391 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/