Internet DRAFT - draft-herbert-tcp-in-udp
draft-herbert-tcp-in-udp
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,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/info/rfc2663>.
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,
<https://www.rfc-editor.org/info/rfc3168>.
[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,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[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,
<https://www.rfc-editor.org/info/rfc6936>.
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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, <https://datatracker.ietf.org/doc/html/draft-
ietf-tsvwg-udp-options-22>.
Author's Address
Tom Herbert
SiPanda
Santa Clara, CA,
United States of America
Email: tom@herbertland.com
Herbert Expires 12 February 2024 [Page 10]
