Network Working Group T. Herbert Internet-Draft SiPanda Intended status: Experimental 11 August 2023 Expires: 12 February 2024 TCP-in-UDP Encapsulation draft-herbert-tcp-in-udp-00 Abstract This document specifies a method of encapsulating TCP protocol packets within UDP headers. TCP-in-UDP is useful in situations where network capabilities specific to UDP can be leveraged for TCP packets. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 February 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Herbert Expires 12 February 2024 [Page 1] Internet-Draft TCPinUDP August 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. UDP Header . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Source Port . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Destination Port . . . . . . . . . . . . . . . . . . 5 2.1.3. Checksum . . . . . . . . . . . . . . . . . . . . . . 5 2.1.4. Length . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. TCP-in-UDP header . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Rsvd . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Addresses checksum . . . . . . . . . . . . . . . . . 5 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. TCP-in-UDP processing . . . . . . . . . . . . . . . . . . 6 3.1.1. Processing for NAT traversal . . . . . . . . . . . . 6 3.1.2. Sending TCP-in-UDP packets . . . . . . . . . . . . . 7 3.1.3. Receiving TCP-in-UDP packets . . . . . . . . . . . . 7 3.2. TCP processing . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Basic processing . . . . . . . . . . . . . . . . . . 8 3.2.2. Explicit Congestion Notification . . . . . . . . . . 8 3.2.3. MTU, MSS, and Packetization Layer Path MTU . . . . . 8 3.3. ICMP Processing . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document specifies a method of encapsulating TCP protocol packets within UDP headers. TCP-in-UDP is useful in situations where network capabilities specific to UDP can be leveraged. Effectively, this is a means to support the TCP protocols in the "UDP as a network layer" model. For example, this enables the use of UDP Options [I-D.ietf-tsvwg-udp-options] with TCP. 1.1. Requirements TCP-in-UDP MUST be capable of traversing NAT device that change the IP addresses. To facilitate this, a small shim header, called the TCP-in-UDP header, is employed and lies between the UDP header and TCP header of a packet. The TCP-in-UDP header contains the ones' complement sum of the original source and destination addresses; this is sufficient for a receiver to properly adjust the TCP checksum when Herbert Expires 12 February 2024 [Page 2] Internet-Draft TCPinUDP August 2023 the packet traversed a NAT. The use of TCP-in-UDP encapsulation need not be symmetric between the two directions of the flow. That is, TCP packets may be encapsulated in UDP from a source to a peer, but packets sent in the reverse path may be sent in plain TCP/IP packets. Similarly, a source that is sending TCP-in-UDP packets is not required to encapsulate all packets sent on a connection; it is however RECOMMENDED that all packets are encapsulated if there are stateful devices in the network path. The UDP port numbers do not correlate with the TCP port numbers. The source port number is set to an entropy value for the TCP connection, and the destination port number is set to a well known port number for TCP-in-UDP. The UDP port numbers are are not swapped between the direction of a flow and devices SHOULD NOT attempt to infer flow state from the UDP port numbers. Based on the destination port number, intermediate nodes MAY attempt to parse the UDP payload of a TCP-in-UDP packet which consists of the TCP-in-UDP header, TCP header, and TCP payload. However, it is NOT RECOMMENED that intermediate nodes parse UDP payloads based on port numbers as that may lead to misinterpretation as described in [RFC7605]. 1.2. Terminology 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]. 2. Packet format TCP-in-UDP is a straight forward encapsulation of a TCP header and its payload within the payload of a UDP datagram. The headers for TCP-in-UDP encapsulation consist of: * IPv4 or IPv6 header * UDP header * TCP-in-UDP header * TCP header * TCP payload Herbert Expires 12 February 2024 [Page 3] Internet-Draft TCPinUDP August 2023 The IPv4 or IPv6 headers have the standard format where the next protocol is set to UDP. Note that the IP source and destination addresses are the addresses for both the UDP packet and the encapsulated TCP packet, and so the pseudo headers for computing the UDP checksum and TCP checksum include the same source and destination addresses of the IPv4 or IPv6 header. The destination port number of the UDP header is set to a well known port number for TCP-in-UDP. The UDP source port number is set to an entropy value for the TCP 5-tuple. The TCP-in-UDP header is a four byte header with a sixteen bit field that is set to the ones' complement sum of the source and destination addresses. The field is needed to adjust the TCP checksum appropriately to be correct if TCP-in-UDP packet traverse a NAT device and the IP addresses (see section 3.1.1). The format of a UDP header and TCP-in-UDP headers are: 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 UDP Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port = entropy value | Dest. Port = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TCP-in-UDP header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd | Addresses checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. UDP Header 2.1.1. Source Port TCP-in-UDP permits the UDP source port value to be used to encode an entropy value. The UDP source port contains a 16-bit entropy value that is generated by the source to identify a flow for the encapsulated packet. The port value SHOULD be within the ephemeral port range, i.e., 49152 to 65535, where the high-order two bits of the port number are set to one. The port value SHOULD be derived from the TCP 5-tuple; this can either be a hash over the 5-tuple, or simply a random number that is assigned by the source for the TCP connection maintained in its PCB (Protocol Control Block). The source port value SHOULD be consistent for all packets sent on a TCP connection. Note that the UDP source port does not need to be the Herbert Expires 12 February 2024 [Page 4] Internet-Draft TCPinUDP August 2023 same value as the TCP source port (to produce sufficient entropy the values should be unrelated). 2.1.2. Destination Port The destination port of the UDP header is set to TCP-in-UDP (TBD); see Section 5. 2.1.3. Checksum The UDP checksum is set and processed per [RFC0768] and [RFC1122] for IPv4 and per [RFC8200] for IPv6. The checksum MUST be non-zero for IPv6 packets. 2.1.4. Length The usage of this field is in accordance with the current UDP specification in [RFC0768]. This length will include the UDP header (eight bytes), TCP-in-UDP header (four bytes), the TCP header, and the TCP payload. 2.2. TCP-in-UDP header 2.2.1. Rsvd This field MUST be set zero when sending, and SHOULD be ignored at reception. 2.2.2. Addresses checksum This field is set to the sixteen bit ones' complement sum of the source and destination addresses of a packet. For IPv4, the sum is computed over the IPv4 source and destination addresses: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For IPv6, the sum is computed over the IPv6 source and destination addresses: Herbert Expires 12 February 2024 [Page 5] Internet-Draft TCPinUDP August 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Operation 3.1. TCP-in-UDP processing 3.1.1. Processing for NAT traversal A UDP packet that encapsulates TCP may traverse a NAT such that the source or destination IP addresses change. Since the TCP checksum of the encapsulated TCP header includes the addresses in the checksum pseudo header, after the NAT traversal the encapsulated TCP checksum will no longer be correct. To allow NAT traversal with TCP-in-UDP, the TCP-in-UDP header contains the ones' complement sum of the source and destination IP addresses. This value is used to compensate in the TCP checksum field for the effects of the IP addresses changing. When a packet is received and the checksum value in the TCP-in-UDP header doesn't equal the ones' complement sum of the received IP addresses then it is assumed that the packet traversed a NAT and the IP addresses were changed. To adjust the TCP checksum in the case a TCP-in-UDP packet traversed a NAT, the checksum delta of the IP addresses is first computed. This is the ones' complement sum of the received IP address minus the checksum value in the TCP-in-UDP header. The result is then subtracted from the value in the TCP checksum field. Herbert Expires 12 February 2024 [Page 6] Internet-Draft TCPinUDP August 2023 For this algorithm to work, the IP addresses MUST be covered by a checksum other than the TCP checksum. In IPv4, the addresses are covered by the IPv4 header checksum and the UDP checksum if it is non-zero. In IPv6, the addresses are only covered by the UDP checksum, hence in IPv6 the UDP checksum MUST be used on set to a non-zero value with TCP-in-UDP. In particular, TCP-in-UDP is not a tunneling protocol and the use of a zero IPv6 UDP checksum [RFC6936] is not applicable. NAT devices MUST perform Network Address Translation as per requirements of [RFC2663]. NAT devices MUST NOT attempt to translate the encapsulated TCP checksum in TCP-in-UDP packets. 3.1.2. Sending TCP-in-UDP packets The procedures for creating and sending a TCP-in-UDP packet are: 1. Create a TCP-in-UDP packet with an IP header, UDP header, TCP-in- UDP header, TCP header, and TCP payload. The IP header next protocol is UDP. The payload length is set to the sum of twelve, the length of the TCP header, and the length of the TCP payload. The TCP header and other fields in the IP header are set to the canonical values for TCP/IP packet. 2. Set the UDP source port to an entropy value corresponding to the TCP connection. Set the UDP destination port to the TCP-in-UDP port number. Set the UDP length to the the sum of twelve, the length of the TCP header, and the length of the TCP payload. Set the UDP checksum appropriately; the UDP checksum MAY be zero for IPv4, it MUST be non-zero for IPv6 packets. 3. Set the Addresses Checksum field in the TCP-in-UDP header (in the UDP payload) to the ones' complement sum of the source and destination IP addresses. 4. Send packet 3.1.3. Receiving TCP-in-UDP packets The procedures for processing a received TCP-in-UDP packet are: 1. Receive a TCP-in-UDP packet. Process the IP header and UDP header as normal Process the TCP-in-UDP header and adjust the TCP checksum for NAT traversal. Procedures for adjusting the TCP checksum are: Herbert Expires 12 February 2024 [Page 7] Internet-Draft TCPinUDP August 2023 1. Compute the ones' complement checksum of the source and destination IP addresses in the received packet 2. Invert the result of step 1; that is perform an "exclusive or" of the value from the field 3. Perform a ones' complement addition on the result from Step 2 and the value of the Addresses Checksum field. The result is the checksum delta 4. Add the result from Step 3 to the value of the TCP checksum field of the TCP header. This is the updated TCP checksum value 5. Store the result of step 4 in the TCP checksum field of the TCP header. 3.2. TCP processing 3.2.1. Basic processing TCP processing for TCP-in-UDP is mostly agnostic to the encapsulation in UDP. When sending, the UDP headers and TCP-in-UDP headers are logically inserted into a TCP/IP packets; and when a TCP-in-UDP packet is received the UDP and TCP-in-UDP headers are logically removed before processing the TCP packet. 3.2.2. Explicit Congestion Notification Explicit Congestion Notification (ECN) [RFC3168] is transparent to TCP-in-UDP. The Traffic Class field of the IPv6 header [RFC8200] and Type of Service field [RFC0791] are set the values per the TCP protocol-- these fields would be set the same rather TCP-in-UDP encapsulation is used or not. 3.2.3. MTU, MSS, and Packetization Layer Path MTU When TCP-in-UDP is in used, the twelve bytes of additional overhead MUST be taken into account-- most likely this is just the what the MSS would be without encapsulation minus twelve bytes. Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] would also take this overhead into account Herbert Expires 12 February 2024 [Page 8] Internet-Draft TCPinUDP August 2023 3.3. ICMP Processing Upon receiving and ICMP error for a TCP-in-UDP, the receiving host can match the packet to the originating TCP flow by inspecting the headers and bytes of IP payload that are in the ICMP message ([RFC0792], [RFC4443]). 4. Security Considerations TCP-in-UDP doesn not introduce any new security risks, It is compatible with network layer and transport layer security mechanisms including IPsec, TLS, and the TCP Authentication options. 5. IANA Considerations IANA has allocated to assign UDP destination port number for TCP-in- UDP. 6. References 6.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . Herbert Expires 12 February 2024 [Page 9] Internet-Draft TCPinUDP August 2023 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 6.2. Informative References [I-D.ietf-tsvwg-udp-options] Touch, J. D., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-22, 9 June 2023, . Author's Address Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 12 February 2024 [Page 10]