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]