idnits 2.17.1 draft-cheshire-tcp-over-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2013) is 3952 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft J. Graessley 4 Intended status: Standards Track R. McGuire 5 Expires: January 1, 2014 Apple 6 June 30, 2013 8 Encapsulation of TCP and other Transport Protocols over UDP 9 draft-cheshire-tcp-over-udp-00 11 Abstract 13 Encapsulation of TCP and other transport protocols over UDP enables 14 use of UDP-based NAT traversal techniques with other transport 15 protocols. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 1, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Conventions and Terminology Used in this Document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 53 "OPTIONAL" in this document are to be interpreted as described in 54 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 56 2. Introduction 58 To establish direct communication between two devices that are both 59 behind NAT gateways, Interactive Connectivity Establishment (ICE) 60 [RFC5245] is used to create the necessary mappings in both NAT 61 gateways. While, in principle, ICE should work for both TCP and UDP, 62 recent work has shown that in practice success rates are higher using 63 UDP (about 80% for UDP, compared to 60% for TCP) [RFC5128]. 65 However, many applications want flow control, congestion control, 66 reliability, and other properties provided by TCP. Hence it would be 67 desirable to encapsulate TCP over UDP, to provide the transport 68 protocol capabilities provided by TCP, combined with the NAT- 69 traversal capability available with UDP. 71 Using ICE [RFC5245] entails sending and receiving STUN [RFC5389] 72 packets. Therefore it is necessary for the encapsulation format to 73 support STUN packets and encapsulated TCP packets sharing the same 74 UDP port. 76 This document defines a suitable encapsulation of TCP (and other 77 transport protocols) over UDP. 79 We anticipate in-kernel implementations of TCP-over-UDP, making use 80 of the kernel's existing mature TCP code, but user-level 81 implementations of TCP-over-UDP are also possible, using a high- 82 quality user-space TCP implementation that provides the necessary 83 congestion control and other desirable aspects of TCP. This allows 84 applications to use TCP-over-UDP on operating systems that don't 85 provide TCP-over-UDP. 87 The performance and congestion control properties of TCP-over-UDP are 88 exactly the same as traditional TCP. TCP-over-UDP is traditional TCP 89 using UDP/IP as the datagram transport, instead of just raw IP as the 90 datagram transport. Existing TCP facilities such as window scaling, 91 timestamps, selective ack, and TCP header options are supported, as 92 they are with native TCP. In fact, TCP options are expected to work 93 more reliably with TCP-over-UDP, because middleboxes will be less 94 able to easily interfere with such options, modifying them, stripping 95 them, or dropping packets containing TCP options, as they often do 96 today with native TCP packets. In particular, Multipath TCP-over-UDP 97 is expected to work more reliably than native Multipath TCP 98 [RFC6824], because middleboxes that interfere with use of those TCP 99 options will be less able to do that when the packets are 100 encapsulated inside UDP. 102 Any protocol than can be run over native TCP, including TLS, can be 103 run over TCP-over-UDP. 105 NAT gateways typically use shorter timeouts for UDP port mappings 106 than they do for TCP port mappings. This means that long-lived TCP- 107 over-UDP connections will need to send more frequent keepalive 108 packets than native TCP connections. For this reason, native TCP 109 connections are still preferable for long-lived mostly-idle 110 connections. For these connections, TCP-over-UDP should be used only 111 when native TCP fails. 113 3. Conceptual API 115 While the protocol specified in this document could be implemented in 116 a variety of ways, it is helpful to describe one possible API model 117 to illustrate the intended functionality. In this illustrative API, 118 the client application first creates an "attachable" UDP socket, and 119 then creates an "attached" TCP socket which shares its UDP port. All 120 TCP packets sent and received by the "attached" TCP socket are 121 encapsulated inside UDP packets. 123 Note that the TCP socket conceptually has no associated source port 124 of its own. The UDP port numbers provide all the necessary traffic 125 demultiplexing, and fully identify the software endpoint to which a 126 given UDP packet is directed. No further demultiplexing at the TCP 127 level is required. Equivalently, the TCP source port could be 128 thought of as being "UDP port X". Note that TCP using "UDP port X" 129 as its source port is not that same as a native TCP connection using 130 "TCP port X" as its source port. For example, a host with a TCP- 131 over-UDP socket listening for TCP-over-UDP connections to UDP port 80 132 will often also have a native TCP socket listening for native TCP 133 connections to TCP port 80. 135 4. Packet Format 137 The most-significant four bits of the first octet of the UDP payload 138 determine whether the payload is: 140 o 0x0-0x3: A raw UDP payload (typically a STUN packet) 141 o 0x5-0xF: An encapsulated TCP packet 142 o 0x4: Some other transport protocol (e.g., SCTP, DCCP, or even UDP) 144 These three packet varieties are described in more detail below. 146 4.1. Raw UDP 148 When the client makes an API call to transmit a UDP payload on an 149 "attachable" UDP socket, where the most-significant four bits of the 150 first octet of the payload are in the range 0x0-0x3 (as is the case 151 for a STUN [RFC5389] packet, where the most-significant two bits are 152 always zero) the entire UDP payload is sent-as is, with no 153 modification. 155 Upon reception of a UDP packet where the most-significant four bits 156 of the first octet are in the range 0x0-0x3, the entire payload is 157 delivered to the application's UDP socket without modification. 159 This allows a client application to exchange STUN packets with an 160 unmodified STUN server that knows nothing about this new 161 encapsulation. 163 4.2. Encapsulated TCP 165 When the client makes an API call to transmit TCP data on an 166 "attached" TCP socket, encapsulated TCP packets are generated and 167 sent. 169 For clarity of explanation, this section describes the process of 170 generating these packets in terms of (i) first generating a standard 171 TCP packet in the conventional way, and then (ii) performing a 172 rewriting step to transform it into a TCP-over-UDP packet just prior 173 to transmission. Upon reception, the inverse rewrite is performed to 174 transform it back into a conventional TCP packet, which is then 175 handed to the TCP stack for the usual TCP processing. In this model 176 the only required change to an existing in-kernal TCP implementation 177 is that its per-connection data structures need to include an 178 additional one-bit flag signifying whether this is a native TCP 179 connection or a TCP-over-UDP connection. This is necessary to allow 180 TCP port X and TCP-over-UDP port X to coexist simultaneously. 182 It is likely that, for better efficiency, implementers may choose to 183 modify their TCP code to generate TCP-over-UDP packets directly, 184 rather than first generating a standard TCP header and then rewriting 185 it. Nonetheless, for clarity, the description which follows assumes 186 that a standard TCP packet has been generated, and describes how such 187 a packet would be transformed into a TCP-over-UDP packet. 189 In the IP header, the IP protocol field is changed from 0x06 (TCP) to 190 0x11 (UDP). 192 The TCP header [RFC0793] is then rewritten as described below to 193 transform it into a legal UDP header [RFC0768]. A 20-octet (or more) 194 TCP header is formatted as shown below: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Source Port | Destination Port | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Sequence Number | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Acknowledgment Number | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Data | |U|A|P|R|S|F| | 206 | Offset| Reserved |R|C|S|S|Y|I| Window | 207 | | |G|K|H|T|N|N| | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Checksum | Urgent Pointer | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | (Optional) Options | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 1: TCP Header Format 216 This header is rewritten into the encapsulated TCP-over-UDP format 217 shown below: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Source Port | Destination Port | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Length | Checksum | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Data | | |A|P|R|S|F| | 227 | Offset| Reserved |0|C|S|S|Y|I| Window | 228 | | | |K|H|T|N|N| | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Sequence Number | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Acknowledgment Number | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | (Optional) Options | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: Encapsulated TCP-over-UDP Header Format 239 The specified TCP source port is replaced by the UDP socket's source 240 port. If the implementation generates the TCP header using the UDP 241 port number, then this is a no-op. 243 The specified destination port is preserved. Note that for the 244 packet to be interpreted correctly upon reception, the receiving peer 245 must (obviously) implement TCP-over-UDP and have it enabled for the 246 receiving UDP socket. 248 The length is the customary UDP length field, indicating the number 249 of octets from the start of this header to the end of the payload. 250 It can be computed from the Total Length and Internet Header Length 251 fields in the IP header. 253 The Checksum is the customary UDP Checksum. Note that the checksum 254 does not have to be recomputed by brute-force; it can be derived 255 using a simple calculation involving the original TCP Checksum and 256 the fields modified in the course of this header rewrite. 258 The header up to this point is now a standard UDP header. 260 The remainder of the TCP header is re-ordered so that the "Data 261 Offset" line comes next. Since the minimum legal value for Data 262 Offset is 5, this yields a UDP payload where the most-significant 263 four bits of the first octet are necessarily in the range 0x5-0xF. 265 The Sequence Number and Acknowledgment Number appear next. 267 The TCP Checksum is omitted, since it is redundant. The UDP header 268 has its own checksum. 270 The TCP Urgent Pointer field is omitted. TCP-over-UDP does not 271 support urgent data. The TCP URG flag MUST NOT be set. 273 This in-place rewrite converts the 20-octet (or more) TCP header into 274 a 20-octet (or more) TCP-over-UDP header. Since the header size is 275 the same, the TCP MSS is unchanged. 277 Upon reception of a UDP packet where the most-significant four bits 278 of the first octet are in the range 0x5-0xF, on a UDP port with TCP- 279 over-UDP enabled, the code performs the inverse of the transformation 280 described above, and then hands the resulting TCP packet to the 281 existing TCP implementation for further processing. 283 4.3. Encapsulated UDP and Other Transport Protocols 285 When the client makes an API call to transmit a UDP payload where the 286 most-significant four bits of the first octet are not in the range 287 0x0-0x3, an explicit UDP-in-UDP encapsulation is used. A four-octet 288 header is inserted before the UDP payload: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | 0x40 | proto = 0x11 | 0x00 | 0x00 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 3: Encapsulated UDP-over-UDP Header Format 298 Upon reception of a UDP packet where the most-significant four bits 299 of the first octet have the value 0x4, on a UDP port with TCP-over- 300 UDP enabled, this signifies an encapsulated transport protocol (other 301 than TCP). The value in the second octet indicates the encapsulated 302 protocol. 304 The details of how a given transport protocol is encapsulated over 305 UDP are defined on a per-protocol basis. In particular, the complete 306 transport protocol SHOULD NOT be included in its entirety, since some 307 of the fields are redundant or unnecessary (as illustrated above for 308 TCP). For protocols that use 16-bit port numbers, these port number 309 fields SHOULD be omitted from the encapsulated header, since the 310 necessary demultiplexing function is performed by the UDP header's 311 port number fields. 313 In the case of UDP, none of the UDP header fields are replicated in 314 the encapsulated content, since the outer UDP header contains all the 315 necessary information to infer the effective inner UDP header 316 contents (i.e. the source and destination ports are the same, the 317 length field of the effective inner UDP header is four octets less 318 than the outer UDP header's length field, and the checksum is 319 recomputed). Upon reception of such a packet, the four-octet 320 encapsulation header is stripped off, and the remaining payload 321 delivered to the application. For UDP packets where the most- 322 significant four bits of the first octet are not in the range 0x0- 323 0x3, this results in an effective MTU reduction of four octets. This 324 is not expected to cause any significant problems. The primary use 325 of TCP-over-UDP is expected to be for STUN and TCP sharing a UDP 326 port. 328 5. IANA Considerations 330 No IANA actions are required by this document. 332 6. Security Considerations 334 No new security risks occur as a result of using this protocol. 336 7. References 338 7.1. Normative References 340 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 341 August 1980. 343 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 344 RFC 793, September 1981. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 7.2. Informative References 351 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 352 Peer (P2P) Communication across Network Address 353 Translators (NATs)", RFC 5128, March 2008. 355 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 356 (ICE): A Protocol for Network Address Translator (NAT) 357 Traversal for Offer/Answer Protocols", RFC 5245, 358 April 2010. 360 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 361 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 362 October 2008. 364 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 365 "TCP Extensions for Multipath Operation with Multiple 366 Addresses", RFC 6824, January 2013. 368 Authors' Addresses 370 Stuart Cheshire 371 Apple Inc. 372 1 Infinite Loop 373 Cupertino, California 95014 374 USA 376 Phone: +1 408 974 3207 377 Email: cheshire@apple.com 379 Josh Graessley 380 Apple Inc. 381 1 Infinite Loop 382 Cupertino, California 95014 383 USA 385 Phone: +1 408 974 5710 386 Email: jgraessley@apple.com 388 Rory McGuire 389 Apple Inc. 390 1 Infinite Loop 391 Cupertino, California 95014 392 USA 394 Phone: +1 408 862 3633 395 Email: rlpm@apple.com