Internet-Draft T. Herbert Intended status: Standard track Quantonium Expires March 31, 2019 September 27, 2018 Generic TCP Encapsulation draft-herbert-tsvwg-gte-00 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 31, 2019. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Herbert Expires March, 2019 [Page 1] Internet Draft Generic TCP Encapsulation September 27, 2018 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Herbert Expires March, 2019 [Page 2] Internet Draft Generic TCP Encapsulation September 27, 2018 Abstract This specification describes Generic TCP Encapsulation (GTE) which is a method to encapsulate packets of different IP protocols within TCP data streams. Encapsulating packets in TCP facilitates communications across networks that block or sub-optimally handle non-TCP traffic. GTE is an adaptation of Generic UDP Encapsulation (GUE) to work in the context of TCP. GTE employs the GUE encapsulation format and optional extensions. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 5 2 Encapsulation format . . . . . . . . . . . . . . . . . . . . . 6 2.1 GTE messages in a TCP stream . . . . . . . . . . . . . . . . 6 2.2 TCP connections . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Encapsulation with GUE variant 0 . . . . . . . . . . . . . . 7 2.4 Encapsulation with GUE variant 1 . . . . . . . . . . . . . . 8 2.4.1 IPv4 direct encapsulation . . . . . . . . . . . . . . . 8 2.4.2 IPv6 direct encapsulation . . . . . . . . . . . . . . . 9 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Encapsulation flavors . . . . . . . . . . . . . . . . . . . 9 3.1.1 Network layer encapsulation . . . . . . . . . . . . . . 9 3.1.2 Transport layer encapsulation . . . . . . . . . . . . . 10 3.2 Encapsulator operation . . . . . . . . . . . . . . . . . . . 11 3.3 Decapsulator operation . . . . . . . . . . . . . . . . . . . 11 3.3.1 Receiving network layer encapsulation . . . . . . . . . 11 3.3.2 Receiving transport layer encapsulation . . . . . . . . 12 3.3.3 Error handling . . . . . . . . . . . . . . . . . . . . . 13 3.4 Processing a received control message . . . . . . . . . . . 13 3.5 NAT interaction . . . . . . . . . . . . . . . . . . . . . . 13 3.6 Checksum offload of encapsulated transport checksum . . . . 13 3.6.1 Transmit checksum offload . . . . . . . . . . . . . . . 14 3.6.2 Receive checksum offload . . . . . . . . . . . . . . . . 14 3.7 GUE extensions . . . . . . . . . . . . . . . . . . . . . . . 14 3.8 Surplus area . . . . . . . . . . . . . . . . . . . . . . . . 14 4 GTE control messages . . . . . . . . . . . . . . . . . . . . . 15 4.1 Message length size . . . . . . . . . . . . . . . . . . . . 15 4.2 GUE header template . . . . . . . . . . . . . . . . . . . . 16 4.2.1 Header template validation . . . . . . . . . . . . . . . 17 4.2.2 Optional extensions in header templates . . . . . . . . 17 4.2.3 Processing received messages . . . . . . . . . . . . . . 18 4.3 Example of UDP over GTE . . . . . . . . . . . . . . . . . . 18 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 6.1 TCP port number . . . . . . . . . . . . . . . . . . . . . . 20 6.2 GUE control types . . . . . . . . . . . . . . . . . . . . . 20 Herbert Expires March, 2019 [Page 3] Internet Draft Generic TCP Encapsulation September 27, 2018 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Herbert Expires March, 2019 [Page 4] Internet Draft Generic TCP Encapsulation September 27, 2018 1 Introduction This specification describes Generic TCP Encapsulation (GTE) which is a general method for encapsulating packets of arbitrary IP protocols within Transport Control Protocol (TCP) [RFC0793] streams. The motivation and basic requirements for encapsulating packets with TCP are described in [TCPENCAP]. The primary motivation is to tunnel packets over networks that either block or treat non-TCP traffic sub- optimally. For instance, a real-time gaming application that uses UDP may chose to encapsulate packets in TCP in order to traverse a stateful firewall that only allows TCP. GTE is an adaptation of Generic UDP Encapsulation [GUE] to encapsulate packets in a TCP stream. Packets are encapsulated in GTE messages. Each GTE message is composed of a message length, a GUE header variant, and a GUE payload. The message length is needed to demarcate messages in the TCP stream. The TCP data stream is then composed of a sequence of GTE messages. The GUE header and protocol in GTE messages are the same as that defined in GUE. Sender and receiver processing is modified accordingly to take into account the differences between TCP and UDP encapsulation. GTE defines an optimization to compress out the GUE header in certain circumstances. 1.1 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Herbert Expires March, 2019 [Page 5] Internet Draft Generic TCP Encapsulation September 27, 2018 2 Encapsulation format This section describes the encapsulation formats of Generic TCP Encapsulation. 2.1 GTE messages in a TCP stream A GTE message is encapsulated in a TCP stream. A message is comprised of a message length field, a GUE header of one of the GUE variants, and a payload which is either an encapsulated packet of some IP protocol or a control message such as an OAM (Operations, Administration, and Management) message. Encapsulation of GTE message in TCP has the general format: +-------------------------------+ | | | TCP/IP header | | | |-------------------------------| .... |-------------------------------| | Message length | |-------------------------------| | | | GUE Header | | | |-------------------------------| | | | Encapsulated packet | | or control message | | | +-------------------------------+ .... A TCP stream is composed of a sequence of GUE messages. Each message is prefixed by the length of the message for demarcation. Note that there is no on-to-one correspondence between a GTE message and a TCP segment. Multiple GTE messages may be in a single TCP segment, and a single GTE message may span multiple TCP segments. Additionally, there is no assumed alignment of GTE messages within a stream The GUE header and encapsulation are defined in [GUE]. A GTE message may carry variant 0 or variant 1 GUE packets. The formats are detailed below. Herbert Expires March, 2019 [Page 6] Internet Draft Generic TCP Encapsulation September 27, 2018 2.2 TCP connections A GTE stream is composed of GTE message. The message are sequential and per the semantics of TCP they are processed in order. +----------------+----------------+----------------|-------- | GTE message #1 | GTE message #2 | GTE message #3 | .... . +----------------+----------------+----------------|-------- A default TCP port number (suggesting 6080) will be assigned to GTE. A server may listen on this port number for incoming connections. When a connection is established, the data stream is interpreted as a sequence of GTE messages, so the first four bytes in the stream are the length of the first GTE message. GTE could also use an HTTP connection for the transport. This would be done using the HTTP Upgrade header to specify use of GTE. Specification of this is outside the scope of this document. Transport Layer Security (TLS) can be used on the TCP stream. In this case, the GTE messages are the plain text before TLS is applied. GTE messages are processed on receive after TLS processing. 2.3 Encapsulation with GUE variant 0 Variant 0 of GUE defines a generic extensible format to encapsulate packets by Internet protocol number. The format of a GTE message with GUE variant 0 is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 0 |C| Hlen | Proto/ctype | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G | | U ~ Extensions Fields (optional) ~ E | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h | | d ~ Private data (optional) ~ r | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | | ~ GUE payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Herbert Expires March, 2019 [Page 7] Internet Draft Generic TCP Encapsulation September 27, 2018 Fields: o Message Length: Length of the GTE message not including the four bytes of this field. The length is the sum of the GUE header length and the length of the encapsulated GUE payload. The size of the message length field may be changed using the Message Length Size control message (section 4.1). The GUE header fields are specified in [GUE] and GUE extensions are describe in [GUEEXTEN]. 2.4 Encapsulation with GUE variant 1 Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 packets in GUE. 2.4.1 IPv4 direct encapsulation A GTE message with direct encapsulation of an IPv4 packet has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |0|1|0|0| IHL |Type of Service| Total Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | Identification |Flags| Fragment Offset | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | Time to Live | Protocol | Header Checksum | 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Source IPv4 Address | h +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | Destination IPv4 Address | r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | | ~ IPv4 payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Herbert Expires March, 2019 [Page 8] Internet Draft Generic TCP Encapsulation September 27, 2018 2.4.2 IPv6 direct encapsulation A GTE message with direct encapsulation of an IPv6 packet has the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |0|1|1|0| Traffic Class | Flow Label | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Payload Length | NextHdr | Hop Limit | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | I + + P | | v + Source IPv6 Address + 6 | | + + h | | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | | | + + | | | | + Destination IPv6 Address + | | | | + + | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 3 Operation This section describes the operation of GTE. 3.1 Encapsulation flavors GTE can do either network layer of transport layer encapsulation. 3.1.1 Network layer encapsulation Network tunneling can be achieved by encapsulating layer 2 or layer 3 packets. In this case the encapsulator and decapsulator nodes are the tunnel endpoints as well as the endpoints of the GTE TCP connection. These could be routers providing tunnels on behalf of communicating hosts. Herbert Expires March, 2019 [Page 9] Internet Draft Generic TCP Encapsulation September 27, 2018 The figure below illustrates the use of GTE network layer encapsulation between two hosts. +---------------+ +---------------+ | | | | | Host 1 | | Host 2 | | | | | +---------------+ +---------------+ | ^ V | +---------------+ +---------------+ +---------------+ | | | TCP | | | | Encapsulator |-->| connection |-->| Decapsulator | | | | | | | +---------------+ +---------------+ +---------------+ Host 1 is sending packets to Host 2. An encapsulator performs encapsulation of packets from Host 1. These encapsulated packets traverse the network in a TCP stream. At the decapsulator, packets are decapsulated and sent on to Host 2. GTE encapsulation is not required the reverse direction. 3.1.2 Transport layer encapsulation GTE can encapsulate transport layer packets such as UDP or TCP. The encapsulated packets do not include their own IP header, instead the IP header is inferred from the TCP connection. The figure below illustrates the use of GTE transport layer encapsulation between two hosts. +---------------+ +---------------+ +---------------+ | | | TCP | | | | Host 1 |-->| connection |-->| Host 2 | | | | | | | +---------------+ +---------------+ +---------------+ When encapsulating transport layer packets, the encapsulator and decapsulator should be co-resident with the hosts. The encapsulated transport layer packets are in a TCP stream. The corresponding IP addresses of the endpoints of the TCP connection are taken to be the endpoints of the encapsulated transport packet. Note that the encapsulated transport layer packet is independent of the encapsulating TCP headers, in particular, port numbers of the outer TCP headers and encapsulated transport headers are independent. Herbert Expires March, 2019 [Page 10] Internet Draft Generic TCP Encapsulation September 27, 2018 3.2 Encapsulator operation Encapsulators create GTE data messages, set flags and optional extension fields in the GUE header, and forward packets to a decapsulator by writing messages on a TCP data stream. An encapsulator can be an end host originating the packets of a flow, or can be a network device performing encapsulation on behalf of hosts (routers implementing tunnels for instance). In either case, the intended target (decapsulator) is the peer of the TCP connection. If an encapsulator is tunneling packets -- that is encapsulating packets of layer 2 or layer 3 protocols (e.g. EtherIP, IPIP, or ESP tunnel mode) -- the propagation of network layer information, such as ECN [RFC6040] and diff-serv [RFC2983] should be considered. Since there is no one-to-one mapping between encapsulated packets and the outer packet, the best way to map information may not be obvious. For instance, two IP packets encapsulated in the same TCP segment may have different diff-serv bits. An implementation MAY apply its own configurable heuristics for tunneling of one protocol over another. 3.3 Decapsulator operation If a complete GTE data message is received on a TCP stream, the payload of the GTE message is logically extracted. An IP packet is created with an IP header that is fabricated from the TCP connection parameters. The next protocol in the IP header is set to the protocol from the proto field in the GUE header. The resulting packet is then resubmitted into the protocol stack to process as though it was received with the protocol in the GUE header. 3.3.1 Receiving network layer encapsulation Consider that a data message is received where GTE encapsulated an IP packet. In this case, the proto field in the GUE header is set to 4. +-------------------------------------+ | IP header (next proto = 6 TCP) | |-------------------------------------| | TCP header | |-------------------------------------| .... |-------------------------------------| | GUE (proto = 4,IPv4 encapsulation) | |-------------------------------------| | IP header and packet | +-------------------------------------+ .... Herbert Expires March, 2019 [Page 11] Internet Draft Generic TCP Encapsulation September 27, 2018 The receiver extracts the IP header and payload, and encapsulates that in an IP packet using IPIP encapsulation. The IP header is derived from the TCP connection or IP header that was present in a received TCP segment. The next protocol field is set to 4. The resultant packet would have the format: +-------------------------------------+ | IP header (next proto = 4,IPv4) | |-------------------------------------| | IP header and packet | +-------------------------------------+ This packet is then resubmitted into the protocol stack to be processed as an IPIP packet. 3.3.2 Receiving transport layer encapsulation Consider that a data message is received where GTE encapsulates a UDP packet. In this case, the proto field in the GUE header is set to 17 for UDP: +-------------------------------------+ | IP header (next proto = 6 TCP) | |-------------------------------------| | TCP header | |-------------------------------------| .... |-------------------------------------| | GUE (proto = 17, UDP) | |-------------------------------------| | UDP header and payload | +-------------------------------------+ .... The receiver extracts the UDP header and payload, and formats those in a corresponding UDP/IP packet. The IP header is derived from the TCP connection or IP header that was present in a received TCP segment. The next protocol field is set to 17. The resultant packet would have the format: +-------------------------------------+ | IP header (next proto = 17, UDP) | |-------------------------------------| | UDP header and payload | +-------------------------------------+ This packet is then resubmitted into the protocol stack to be processed as a UDP packet. Herbert Expires March, 2019 [Page 12] Internet Draft Generic TCP Encapsulation September 27, 2018 3.3.3 Error handling If a receiver encounters an error in processing the GUE header it SHOULD close the GTE connection and MAY log an error. The possible errors in processing a GUE header are described in [GUE]. 3.4 Processing a received control message If a valid GUE control message is received, the packet MUST be processed as a control message. The specific processing to be performed depends on the ctype in the GUE header. See [GUE]. 3.5 NAT interaction Transport layer encapsulation (section 3.1.2) allows TCP and UDP packets (without IP headers) to be directly encapsulated in GTE. The IP headers for these are derived from those used in the TCP connection. In particular, the pseudo header for an encapsulated transport checksum might cover the IP addresses used in outer TCP packets. When a packet traverses a NAT and the addresses of the TCP packet changes, the checksum for an encapsulated TCP or UDP packet becomes incorrect. To resolve this problem, the NAT Address Checksum option can be used [GUEEXEN]. A sender computes the one's complement checksum over the IP addresses for the outer TCP connection and sets the value in the Checksum field of the GUE NAT Address Checksum option. When a receiver processes the GTE message, it can compute the required checksum adjustment by taking the difference between checksum over the IP addresses for the connection that it sees and the value it received in the option. If the adjustment is non-zero then that can be added to the computed packet checksum in verification. The exact algorithm is described in [GUEEXTEN]. 3.6 Checksum offload of encapsulated transport checksum Checksum offload is a common technique in Network Interface Cards (NICS) to improve performance [UDPENCAP]. Checksum offload is done on a per packet basis and typically can offload only one checksum in a packet. Several techniques have been implemented to make general use of the capability to effectively offload checksum computation for any number of encapsulated transport checksums in a packet. These techniques include "checksum-unnecessary conversion", Local Checksum Offload (LCO), and Remote Checksum Offload (RCO). In the case of GTE, packets are encapsulated in a stream so the aforementioned techniques for checksum offload don't directly apply and must be adapted. Herbert Expires March, 2019 [Page 13] Internet Draft Generic TCP Encapsulation September 27, 2018 3.6.1 Transmit checksum offload To offload an encapsulated transport layer checksum for transmission, the Remote Checksum Offload (RCO) Option is used [GUEXTEN]. The Checksum Start and Checksum Offset fields in the option are set to point to the starting byte for checksum calculation and the offset where the checksum is to be written. When a receiver processes this field, it will write the derived checksum value at the indicated offset (i.e. the checksum field of an encapsulated transport protocol). 3.6.2 Receive checksum offload To offload a transport checksum calculation in a received GTE packet, the fact that TCP packets must always include a checksum can be leveraged. Given the TCP payload (or payloads) containing a GTE message, the checksum over the GTE message can be derived by subtracting out the checksum for portions of the payload that aren't part of the GTE message. Once the checksum over the GTE message is determined, that can be used to verify any encapsulated transport layer checksums in the message. Note that this is most efficient when a TCP segment contains only one (or part of one) GTE message. 3.7 GUE extensions There is no prohibition to using any of the GUE extensions [GUEEXTENS] in GTE. Their usefulness in the context of a TCP stream may vary. The use of NAT Address Checksum and Remote Checksum Offload options are described above. The Fragmentation option is not very useful since TCP provides segmentation and reassembly. Similarly, the GUE checksum option is not useful since the whole message is already covered by the TCP checksum. The Security, Payload Transform, and Alternate Checksum options may be useful to provide security or strong data integrity checks. The Group Identifier might be useful in some cases. 3.8 Surplus area A an encapsulated packet in GTE may have its own length field such that the encapsulated packet does not take up all the space of the GTE message as indicate by GTE message length. Any bytes beyond the encapsulated packet to the end of message are called "surplus area". Surplus area, for those protocols that have a separate length field, is considered to be reserved. [UDPOPTIONS] is a specification for placing UDP options in surplus area. Herbert Expires March, 2019 [Page 14] Internet Draft Generic TCP Encapsulation September 27, 2018 4 GTE control messages Two GUE control messages are defined to set parameters on a GTE connection. One control message sets the size of the message length field, and the other sets a GUE header template for compressing out the GUE header in GTE messages. 4.1 Message length size The default message length field in GTE is four bytes. The GUE "Message length size" control message allows the size to be changed for a GTE connection. The format of the message length size control message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 0 |1| Hlen | 0x10 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G | | U ~ Extensions Fields (optional) ~ E | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h | | d ~ Private data (optional) ~ r | |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MsgLenSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pertinent fields are: o GUE C bit: Set to 1 to indicate control message o GUE Proto/ctype field: Set to 0x10 to indicate a message length size control message o Reserved: Set to zero on transmit, ignored on receive o MsgLenSize: Number of byte for message length size. Valid values are 1,2,3, or 4 Note that the Reserved and MsgLenSize fields are in the payload of the GUE message. These fields are not included in the GUE header length. Herbert Expires March, 2019 [Page 15] Internet Draft Generic TCP Encapsulation September 27, 2018 If a received message is too short to include the MsgLenSize field or the MsgLenSize is zero or a value greater then 4, then the connection MUST be closed and an error MAY be logged. After a message length size control message is received, the size of the message length field in subsequent messages is taken to be the provided value. The message length size control message MAY be sent multiple times to use different sizes for lifetime of the connection. 4.2 GUE header template An application may use GTE to always tunnel one specific protocol over GTE where the GUE header is identical in all GTE messages. The "GUE header template" control message is defined to compress out the GUE header in such a case. The payload of this control message indicates the GUE header to be applied to all subsequent messages. The format of the GUE header template control message is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 0 |1| Hlen | 0x11 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G | | U ~ Extensions Fields (optional) ~ E | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h | | d ~ Private data (optional) ~ r | |/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 0 |0| Hlen | Proto/ctype | Flags | G +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U | | E ~ Extensions Fields (optional) ~ | | t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e | | m ~ Private data (optional) ~ p | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ Herbert Expires March, 2019 [Page 16] Internet Draft Generic TCP Encapsulation September 27, 2018 Pertinent fields in the (outer) GUE header are: o Variant: Set to 0 o C bit: Set to 1 to indicate control message o Proto/ctype field: Set to 0x11 to indicate a header template control message Pertinent fields in the GUE header template GUE are: o Variant: Must be set to 0 o C bit: Should be zero to indicate a data message o Proto/ctype: Set to the common IP protocol number for all the messages in the GTE stream The GUE header template may have flags set, extension fields present, as well as private data. 4.2.1 Header template validation The format of received GUE template header should be validated like a normal GUE header as described in [GUE]. If the header template is determined to be malformed, then the connection SHOULD be dropped and an error MAY be logged. The GUE header template must be variant 0. If a GUE header template is received with a variant that is another value the connection MUST be closed and an error MAY be logged. 4.2.2 Optional extensions in header templates Any GUE extension that may be set in a header template will need to be applicable to all messages. The Checksum and Alternate Checksum options are not useful in a GUE header template since their input includes payload data. If a proposed header template contains such options the connection SHOULD be dropped and an error MAY be logged. The Fragmentation option is nonsensical to be in a GUE header template. If a proposed header template contains the Fragmentation option then the connection SHOULD be dropped and an error MAY be logged. The Security option may be useful in a GUE header template if it does Herbert Expires March, 2019 [Page 17] Internet Draft Generic TCP Encapsulation September 27, 2018 not include any payload data as input. If the Security option in a header template requires payload data as input, then the connection SHOULD be dropped and an error MAY be logged. If the Security option in a header template doesn't require payload data as input, then it SHOULD be verified (in this case all the input should be contained within the GUE header template). If the Security option fails verification, then the connection SHOULD be dropped and an error MAY be logged. The Group Identifier, Remote Checksum Offload, NAT Address Checksum and Payload Transform options are valid optional extensions to use in a GUE header template. 4.2.3 Processing received messages After a GUE header template control message is received, the header template is applied to all subsequent GTE messages. GTE messages will contain a message length followed by the GUE payload. For each received message, the GUE header from the saved template for the connection is logically inserted into the message, and the message is processed as though the GUE header was received. The GUE header template control message can only be sent once on a connection. All messages following the control message are considered to have the same GUE header and there is no way to send any more GUE control messages on the stream. If both the message length size and the GUE header template are to be set for a GTE connection, then the message length size control message MUST be sent first. 4.3 Example of UDP over GTE This section provides an example use of the GTE control message to encapsulate a stream of UDP packets over a GTE connection. In this example, the sender uses both the message length size and GUE header template control messages. The message length size is set to two bytes to accommodate the largest UDP packet (65535 bytes). The GUE header template sets the protocol for all messages to be UDP, enables Remote Checksum Offload, and enables the NAT Address Checksum option. In this example, the checksum start and checksum offset field in the Remote Checksum Offload option take values of 0 and 6. The addresses of the connection in this example are 2001:DB8::c099:1:2:0 and 2001:DB8::a92a:7:8:1-- the one's complement sum over those addresses is 0x49c5. Herbert Expires March, 2019 [Page 18] Internet Draft Generic TCP Encapsulation September 27, 2018 The message length size and the GUE header template control messages would be as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |1| 0x1 | 0x10 | 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | 0x2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |1| 0x0 | 0x11 | 0x0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |0| 0x2 | 0x11 | 0x280 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | 0x6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0 | 0x49c5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the messages following these control messages are encapsulated UDP packets in the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | Source port | Destination port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | Length | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | | ~ UDP payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that for each message, a full UDP/IP packet can be created by deriving an IP header from the TCP connection (the address endpoints of the TCP connection are the same the addresses of the UDP packet). The NAT Address Checksum option can be used to insure that the UDP checksum remains correct if the TCP connection goes through a NAT. Herbert Expires March, 2019 [Page 19] Internet Draft Generic TCP Encapsulation September 27, 2018 5 Security Considerations GUE security mechanisms are applicable in GTE. Security considerations for TCP encapsulation are discussed in [TCPENCAP]. 6 IANA Considerations 6.1 TCP port number IANA is requested to assign one TCP port number for Generic TCP Encapsulation. The suggested number is 6080 which is the same as the UDP port number assigned for Generic UDP Encapsulation. 6.2 GUE control types IANA is requested to assign two values in the registry for the GUE control types: +----------------+------------------+---------------+ | Control type | Description | Reference | +----------------+------------------+---------------+ | 0x10 | GTE message | This document | | | length size | | | | | | | 0x11 | GUE header | This document | | | template | | +----------------+------------------+---------------+ 6 Acknowledgements 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [GUE] T. Herbert, L. Yong, and O. Zia, "Generic UDP Encapsulation", draft-ietf-intarea-gue-06 Herbert Expires March, 2019 [Page 20] Internet Draft Generic TCP Encapsulation September 27, 2018 7.2. Informative References [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . [TCPENCAP] T. Pauly and E. Kinnear, "TCP Encapsulation Considerations", draft-pauly-tcp-encapsulation-00 [GUEEXTEN] Herbert, T., Yong, L., and Templin, F., "Extensions for Generic UDP Encapsulation" draft-ietf-intarea-gue- extensions-05 [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", http://people.netfilter.org/pablo/netdev0.1/papers/UDP- Encapsulation-in-Linux.pdf [LCO] Cree, E., https://www.kernel.org/doc/Documentation/ networking/checksum-offloads.txt Author's Address Tom Herbert Quantonium 4701 Patrick Henry Santa Clara, CA 95054 US Email: tom@herbertland.com Herbert Expires March, 2019 [Page 21]