idnits 2.17.1 draft-herbert-transports-over-udp-01.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 == Line 597 has weird spacing: '...n. This allow...' == Line 625 has weird spacing: '...fied by secur...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2016) is 2844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 206, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- No information found for draft-chesire-tcp-over-udp - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-nvo3-gue-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Facebook 4 Expires: January 7, 2017 6 July 6, 2016 8 Transport layer protocols over UDP 9 draft-herbert-transports-over-udp-01 11 Abstract 13 This specification defines a mechanism to encapsulate layer 4 14 transport protocols over UDP. Such encapsulation facilitates 15 deployment of alternate transport protocols or transport protocol 16 features on the Internet. DTLS can be employed to encrypt the 17 encapsulated transport header in a packet thus minimizing the 18 exposure of transport layer information to the network and so 19 promoting the end-to-end networking principle. Transport connection 20 identification can be disassociated from network location (IP 21 addresses) to provide connection persistence for mobility and across 22 state eviction in NAT. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2 Basic encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1 Encapsulation format . . . . . . . . . . . . . . . . . . . . 5 67 2.2 Direct transport protocol encapsulation . . . . . . . . . . 6 68 3 Disassociated location encapsulation . . . . . . . . . . . . . 8 69 3.1 Packet format . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.2 Session identifiers . . . . . . . . . . . . . . . . . . . . 9 71 3.3 TOU Identity . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.4 Connection tuple . . . . . . . . . . . . . . . . . . . . . . 10 73 3.5 Session lookup tables . . . . . . . . . . . . . . . . . . . 11 74 3.6 Session identifier negotiation . . . . . . . . . . . . . . . 11 75 3.7 Transport connection lookup . . . . . . . . . . . . . . . . 13 76 3.8 Established state . . . . . . . . . . . . . . . . . . . . . 14 77 3.9 Learning addresses and ports . . . . . . . . . . . . . . . . 14 78 3.10 Closing a sessions . . . . . . . . . . . . . . . . . . . . 14 79 3.11 Session creation deferral . . . . . . . . . . . . . . . . . 14 80 4 TCP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.1 Mapping TCP state to TOU session state . . . . . . . . . . . 15 82 4.2 Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 4.3 SYN cookies . . . . . . . . . . . . . . . . . . . . . . . . 15 84 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 16 85 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 86 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 7.1 Normative References . . . . . . . . . . . . . . . . . . . 17 88 7.2 Informative References . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 91 1 Introduction 93 This specification defines Transport Layer Protocols over UDP (TOU) 94 as generic mechanism to encapsulate IP transport protocols over UDP 95 [RFC0768]. The purpose of TOU is to facilitate the use of alternate 96 protocols and protocol mechanisms over the Internet. 98 The realities of protocol ossification in the Internet, particularly 99 the infeasibility of deploying IP protocol extensions and alternative 100 transport protocols (protocols other than UDP and TCP), have been 101 well documented. A direction to resolve protocol ossification is 102 suggested in RFC7663 [RFC7663]: 104 "... putting a transport protocol atop a cryptographic protocol 105 atop UDP resets the transport versus middlebox tussle by making 106 inspection and modification above the encryption and demux layer 107 impossible." 109 Accordingly, this specification provides a method to encapsulate 110 transport layer protocols in UDP and allows encrypting most of the 111 UDP payload including the encapsulated transport headers and 112 payloads. This solution espouses a model that only the minimal 113 necessary information about the packet is made visible to the 114 network. This exposed information is sufficient to route the packet 115 through the network and to demultiplex and decrypt the packet at the 116 receiving end host. In particular, the encapsulated protocol and 117 related connection state may be rendered invisible to the network. 119 TOU allows "disassociated location" for connection identification at 120 the end points. That is the identification of a connection for a 121 received packet can be independent of the network layer addresses of 122 the packet. Disassociated location enables connection persistence for 123 different use cases in mobility and NAT state eviction. 125 1.1 Requirements 127 The requirements of TOU are: 129 - Allow encapsulation of any IP transport layer protocol (e.g. 130 TCP, SCTP, UDP, DCCP, etc.) over UDP. 132 - Work seamlessly with NAT including conditions where the ports 133 or addresses being used for an encapsulated connection change. 134 To provide for this we disassociate the layer 4 endpoint 135 identification from the IP addresses. 137 - Allow encryption/authentication of the encapsulated transport 138 packet including transport headers. The encryption algorithm 139 should be flexible to allow different methods. Any layer 4 140 information that is exposed in cleartext (such as session 141 identifier defined below) should be authenticated. 143 - Information needed for TOU is sent with along with encapsulated 144 transport packets, there are no standalone TOU messages. Any 145 negotiation to set up state for TOU should not require 146 additional round trips apart from those needed by the 147 encapsulated transport protocol. 149 - The solution must not be biased towards any particular 150 implementation method. Specifically, TOU should allow for 151 transport protocol implementations in userspace, kernel, 152 hardware, etc. 154 - Minimize changes to transport protocols and implementation. TOU 155 should not require any changes to the transport protocol 156 proper, however TOU will extend the concept of transport 157 endpoints beyond the canonical 5-tuple. 159 - Minimize changes to applications. TOU should be enabled with 160 existing applications, APIs, and transport protocols without 161 needing major rework. The desire to use transport layer 162 protocols over UDP should not require applications to adopt 163 completely new transport protocols. 165 1.2 Related work 167 Several transport and encapsulation protocols have been defined to be 168 encapsulated within UDP [RFC0768]. In this model, the payload of a 169 UDP packet contains a protocol header and payload for an encapsulated 170 protocol. 172 TCP-over-UDP [I-D.chesire-tcp-over-udp] specifies a method to 173 encapsulate TCP in UDP. That solution essentially casts the UDP 174 header into a modified TCP header so that the port numbers 175 simultaneously refer to both the UDP and TCP flows. In TOU, the TCP 176 header (generally transport header) is encapsulated in UDP without 177 changing the header format. 179 SCTP-over-UDP [RFC6951] describes a straightforward encapsulation of 180 SCTP in UDP. This work should be leverage-able for use with SCTP in 181 TOU. One potential benefit of TOU is that disassociated location 182 encapsulation (described below) could be used to maintain SCTP 183 connections when UDP NAT flow mappings change. 185 QUIC [QUIC] implements a new transport protocol that is intended to 186 run over UDP. QUIC defines a connection identifier that is used to 187 identify connections at the endpoints independent of IP addresses or 188 UDP ports. A similar concept is adopted for TOU in the session 189 abstraction. 191 SPUD [I-D.hildebrand-spud-prototype] defines an architecture for 192 group grouping UDP packets together in a "tube", also allowing 193 network devices on the path between endpoints to participate 194 explicitly in the tube outside the end-to-end context. TOU implements 195 a subset of the the SPUD architecture but expressly does not require 196 or include provisions to leak end-to-end information for consumption 197 in the network. The encapsulation protocol used in TOU (GUE) is 198 extensible to optionally allow information exposure if this proves to 199 be warranted. 201 1.3 Terminology 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 2 Basic encapsulation 209 Generic UDP Encapsulation (GUE) [I-D.ietf-nvo3-gue] is the 210 encapsulation protocol for encapsulating transport layer protocols 211 over UDP. TOU can encapsulate both stateless transport protocols 212 (e.g. UDP, DCCP, UDP-lite) and stateful protocols (e.g TCP, SCTP). 214 2.1 Encapsulation format 216 The general format of TOU encapsulation using GUE (UDP) is: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 221 | Source port | Destination port | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 223 | Length | Checksum | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 225 |0x0|C| Hlen | Proto/ctype | Flags | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 ~ GUE Fields (optional) ~ 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 ~ Transport layer packet ~ 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Proto/ctype contains the IP protocol number of the GUE payload, in 236 the case of TOU this contains the protocol number of a transport 237 protocol (e.g. for TCP over UDP the value is 6). The C bit (control) 238 is zero for TOU indicating that GUE is carrying a data packet. 239 Certain general GUE flags and fields, such as remote checksum offload 240 or fragmentation, may be useful for TOU but not required for its 241 operation. The example packet formats in the remainder of the this 242 document do not indicate use of any flags or fields other than those 243 required for TOU operation. 245 The Hlen contains the GUE header length in 32-bit words, including 246 optional fields but not the first four bytes of the header. Computed 247 as (header_len - 4) / 4. All GUE headers are a multiple of four bytes 248 in length. Maximum header length is 128 bytes. 250 2.2 Direct transport protocol encapsulation 252 Transport protocol packets can be encapsulated directly in GUE. The 253 simplest format of this is: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 258 | Source port | Destination port | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 260 | Length | Checksum | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 262 |0x0|0| 0 | Protocol | 0 | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 ~ Transport layer packet ~ 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 For example, TCP over UDP could be encapsulated as: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 273 | Source port | Destination port | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 275 | Length | Checksum | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 277 |0x0|0| 0 | 6 | 0 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 279 | Source Port | Destination Port | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 281 | Sequence Number | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 283 | Acknowledgment Number | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 285 | Data | |U|A|P|R|S|F| | TCP 286 | Offset| Reserved |R|C|S|S|Y|I| Window | | 287 | | |G|K|H|T|N|N| | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 289 | Checksum | Urgent Pointer | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 | Options | Padding | | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 293 | data | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 For TOU the flow identification of the encapsulated transport packet 297 includes the encapsulating UDP source and destination port. For a 298 transport protocol that uses the canonical ports for flow 299 identification, flows are identified by the 7-tuple: 301 303 Where protocol refers to the encapsulated protocol (taken from the 304 Proto/ctype field in the GUE header), SrcIP and DstIP refer to the 305 source and destination IP addresses, SrcPort and DstPort refer to the 306 respective ports in the encapsulated transport header, SrcUport and 307 DstUport refer to the source and destination ports in the 308 encapsulating (outer) UDP header. 310 To reply to a transport layer packet encapsulated in TOU, a 311 corresponding TOU packet is sent where the source and destination 312 addresses, source and destination UDP ports, and source and 313 destination transport ports are swapped. The outer addresses and 314 ports may have undergone NAT so that the return path must also go 315 through NAT. To ensure reachabilty, a host must reply to a TOU 316 encapsulated with a corresponding TOU packet. 318 Stateful protocol connections are identified by the 7-tuple as 319 defined above. Since the UDP ports are included in the connection 320 tuples, the typical transport layer 5-tuple () of a TOU connection does not need to be unique with 322 those of non-TOU connections. 324 The inner and outer ports have no correlation. The lengths and 325 checksums must also be set correctly in each header layer. In the 326 case of UDP-over-UDP for IPv6 both the inner and outer checksum must 327 be set. 329 For encapsulated transport packets that define a checksum that 330 includes a pseudo header (e.g. TCP), the checksum pseudo header is 331 changed to only cover the transport layer ports and not the IP 332 addresses. Note that the addresses in a packet traversing NAT may be 333 changed so that the pseudo header checksum for TOU would no longer be 334 correct-- not including the addresses in the pseudo header checksum 335 avoids these bad checksums. In this case the IP addresses are already 336 covered in IPv4 header checksum or the outer UDP checksum for IPv6. 338 3 Disassociated location encapsulation 340 TOU allows transport protocol encapsulation where the location is 341 disassociated from flow identification. That is a connection can 342 remain functional even if the addresses or encapsulation ports 343 change. A common use case will be when NAT state mappings for UDP 344 flows changing. TOU includes a facility to negotiate a shared session 345 identifier for a transport connection which is sent as part of the 346 encapsulation of packets for the connection. The session identifier 347 is used in connection lookup instead of the IP addresses and 348 encapsulation ports. 350 This section describes the protocol formats and operational aspects 351 of TOU for disassociated location transport protocol encapsulation. 353 3.1 Packet format 355 Transport layer packets are encapsulated using Generic UDP 356 Encapsulation (GUE). Two GUE flags and two field are defined for TOU. 357 The format of this encapsulation is illustrated below: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 362 | Source port | Destination port | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 364 | Length | Checksum | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 366 |0x0|0| Hlen | Protocol | 0 |S|D| 0 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 + Source session identifier + 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 + Destination session identifier + 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 ~ Transport layer packet ~ 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 S: Source session identifier bit: This indicates the presence of 382 the source session identifier field. 384 D: Destination session identifier bit. This indicates the presence 385 of the destination session identifier field. 387 Source session identifier: 64-bit field that holds the source 388 (sender's) session identifier. 390 Destination session identifier: 64-bit field that holds the 391 destination (receiver's) session identifier. 393 3.2 Session identifiers 395 A session represents a flow of packets that correspond to the same 396 transport layer connection. Sessions are identified by a pair of 397 session identifiers where both sides of a connection create session 398 identifier for the session. Session identifier negotiation 399 establishes the session pair between two hosts so that each host will 400 know both the locally created session identifier as well as the one 401 created by the remote peer. When a packet is sent on a session the 402 peer's session identifier is included in the packet, on reception the 403 received session identifier is matched to a session. 405 A session has identifier has two uses: 407 1) A location independent representation of the identities in the 408 communication. 410 2) Security context for encryption or authentication of the 411 encapsulated packet. 413 Each node defines a namespace over its communications. Local session 414 identifiers must be unique in the name space of each node in the 415 communication. Each side of a transport communication creates a local 416 session identifier for a session. 418 3.3 TOU Identity 420 TOU disassociates the IP address of a peer from the abstraction of 421 transport protocol endpoint. A peer's identity is implicit in session 422 identifiers that are established between the two nodes of a 423 communications session. All packets sent in the session contain a 424 session identifier. Each local session identifier is unique among all 425 other communications for a node, so the node can use it to 426 distinguish between different communicating peers. A session 427 identifier is meaningful only to the nodes that share it in a 428 communication, externally to those nodes it has no defined meaning. 429 Since session identifiers are disassociated with IP addresses, no 430 relevant information can consistently be inferred in the network. Two 431 packets containing the same session identifier but use different 432 addresses may in fact refer to the same session. Two packets with the 433 same session identifier and same addresses (and UDP ports) that are 434 temporally observed probably, but not definitely, refer to the same 435 session. Note that sessions identifiers are not symmetric for both 436 directions of a flow. 438 Transport layer communications occurs between two nodes in a network. 439 Nodes in this context are not restricted to hosts, any application or 440 process can be considered a node. A node is unambiguously reachable 441 and distinguishable from other nodes, that is if a packet is received 442 it must be deterministic as to which node on the host the packet 443 belongs. For a server application that listens on one or more UDP 444 ports for TOU packets, each listener port instance can be considered 445 a node. For a client application, each peer destination (IP address, 446 TOU port) might be considered to belong to a different node, however 447 for simplicity the whole client application could considered as one 448 node. 450 3.4 Connection tuple 452 The local session identifier, instead of IP addresses, provides the 453 endpoint identity of a transport layer connection. As mentioned this 454 allows the IP addresses associated with the endpoint addresses to 455 change without breaking the connection. The transport layer tuple 456 that identifies a specific connection thus changes accordingly to use 457 the session identifier instead of addresses. 459 For a transport protocol that uses canonical ports for flow 460 identification, a flow in TOU is identified at receive by the 4- 461 tuple: 463 465 Where the source and destination ports refer to the encapsulated 466 transport layer ports in a TOU packet. 468 A session is created for each transport layer connection. A single 469 session could be used to multiplex several connections over the same 470 session however that is not recommended. If such semantics are needed 471 the transport layer protocol can provide that (SCTP sub-streams for 472 instance). A transport layer connection may be sent using different 473 session identifiers during its lifetime. This may be useful for 474 instance to limit tracking of long lived transport connections. 476 3.5 Session lookup tables 478 TOU logically uses two different tables to perform session lookup.: 480 - Local session table 482 The tuple used to match in this table is: 484 486 - Established sessions table 488 Lookups in the established sessions table are performed on the 489 session identifier of a received packet. The lookup tuple in 490 established sessions table is trivially: 492 494 The session negotiation table is consulted when a TOU packet is 495 received where the S bit is set and the D bit is not set-- most 496 commonly this occurs when session negotiation is being performed. The 497 established sessions table is consulted when the D bit is set in a 498 TOU packet. 500 3.6 Session identifier negotiation 502 The process of session identifier negotiation is: 504 1) The initiating host creates its session state and local session 505 identifier. The process is: 507 a) Create a 64-bit random number 509 b) Check the local sessions table if a state with a local 510 session identifier of the same value exists 512 - If no session has that same local identifier it is 513 considered unique. Process to next step. 515 - Else, the proposed value is not unique. Repeat the process 516 (got back to step a.) 518 2) Send a TOU packet with the S bit set and the source session 519 identifier set to the value created in step 1. 521 3) Peer host receives the TOU packet. Since the S bit is set and 522 the D bit is not set this indicates session identifier 523 negotiation. 525 4) The target creates a proposed session identifier. This is based 526 on a secure hash over the 6-tuple: 528 530 srcIP, dstIP, udp_sport, udp_dport, and source_SID are the 531 respective values in the packet. gen is a generation number for 532 the algorithm. For the first invocation this value is zero. The 533 hash calculation should include a randomly seeded key. 535 5) The target performs a lookup on the proposed local session 536 identifier. There are three possibilities: 538 - If no session is found with the same identifier proceed with 539 the next step. This is a new negotiation. 541 - If a matching session is found and it is less than N seconds 542 old and the saved local IP address, remote IP adress, local 543 UDP port, remote UDP port, and peer SID match the dstIP, 544 srcIP, udp_dport, udp_sport, and source_SID in the packet-- 545 then the session negotiation is considered a retransmission. 546 Goto step 7. 548 - Else, the proposed local session identifier is not unique. 549 Repeat the process with an incremented generation number 550 (goto step 4). 552 6) Create a new session state. Save the IP address, UDP port 553 numbers, the source_SID as the remoteSID, and the created SID 554 value as the local SID. 556 7) Send a response packet (e.g. a TCP SYN-ACK) with both the S bit 557 and the D bit set. The source session identifier is the local 558 session identifier, the destination is the remote session 559 identifier that was learned from the initiator. 561 8) When the intitiator receives the packet it will match the local 562 session based on the destination session identifier. The source 563 session identifier is recorded in the session state. 565 The initiator responds (e.g. final ACK in TCP 3WHS) with both 566 the source and destination identifiers set (to allow use with 567 SYN cookies). The destination session identifier contains the 568 value learned from the target. 570 9) When the target receives a TOU packet with the D bit set and 571 matches a session, this indicates that session negotiation is 572 complete. Any subsequent packets sent by either the target or 573 initiator will only have the destination session identifer set. 575 3.7 Transport connection lookup 577 A connected transport protocol typically maintains one or more tables 578 of connections (i.e. multiple tables may be used for different 579 connection states). In lieu of using IP addresses, connection lookup 580 is performed in TOU using the session (specifically a reference to 581 the session). 583 For a transport protocol using the canonical definition of ports, the 584 tuple for matching connections in TOU becomes: 586 588 This implies that connection lookup for a received packet involves 589 two lookups: 591 1) A lookup is performed to find the session. 593 2) A connection lookup is performed using the session found in #1 594 in the lookup tuple. 596 Note that TOU requires that a separate session is created for each 597 encapsulated transport layer connection. This allows consolidating 598 session and connection lookup by including a reference to the 599 transport connection in the session state. 601 3.8 Established state 603 After session establishment, which normally corresponds to transport 604 protocol connection being established, running operations commences. 605 Each packet sent on the underlying connection will be encapsulated 606 using TOU. The 64-bit destination session identifier is set in 607 packets by both sides of the connection to the peer's session 608 identifier. When either side receives a packet a lookup is performed 609 on the destination session identifier in the established sessions 610 table. 612 3.9 Learning addresses and ports 614 After session negotiation is complete connection identification is 615 disassociated from the network layer, however a host still needs to 616 know the IP address and destination UDP port to send a TOU packets to 617 a destination. These are learned from received packets and are 618 recorded in the session state. 620 The destination address and port for a session can change over time 621 (for example a NAT may remap the UDP flow to use different addresses 622 and ports). The peer address and port are inferred from the source 623 address and port in packets received over the session. When a packet 624 on a session is received and has been fully validated (session state 625 matched and authenticity is verified by security mechanisms such as 626 DTLS), if the source address or source port does not match those 627 recorded in the session state then the new values are saved in the 628 session state; packets subsequently sent will use the new address and 629 port for the destination. 631 3.10 Closing a sessions 633 A session is closed when the underlying transport connection closes 634 (e.g. a TCP connection moves to closed state). 636 3.11 Session creation deferral 638 When a target receives an initial packet (e.g. a TCP SYN with with 639 only source session identifier set in the GUE header) creating a 640 session state may be deferred until the transport layer creates its 641 state. If the transport layer does not create a state (e.g. the SYN 642 generated a reset) no session state is created. The reply packet is 643 returned with TOU using the same session identifier received in the 644 request (in this case the source session identifier is no set). 646 4 TCP over UDP 648 TCP over UDP implicitly allows nodes using TCP to be multihomed and 649 mobile. 651 4.1 Mapping TCP state to TOU session state 653 Session state can be created in conjunction with creating TCP state 654 (TCP PCB for instance). If a TCP packet is received for which no 655 state exists, a reply to the packet is sent without creating session 656 state. For instance this would happen is a TCP stack sends a TCP-RST 657 in response to a SYN. 659 For SYN packets the destination session identifier must be zero (D 660 bit is not set). The source session identifier is set to a value that 661 is unique among all connections in the client name space as described 662 in section 3.6. 664 Replies to SYN, ie. SYN-ACK packets, must have both the source and 665 destination identifiers set (D bit and S bit are set). The source 666 identifier on the responding host is created as described in section 667 3.6. 669 The final ACK to complete TWS and all packets sent in established 670 state and beyond only include the destination session (only the D bit 671 is set). 673 Note that simultaneous opens cannot happen. A simultaneous connection 674 attempt between two nodes with same TCP ports will result in two 675 different sessions with two different identifiers. 677 The session state is destroyed when the underlying TCP connection 678 moves to closed state. In the initiator this entails freeing session 679 identifier to be used with new connections. At the target, the full 680 session identifier is free to be reused. 682 4.2 Resets 684 TCP resets may be sent with either the destination session identifier 685 set or the source session identifier set. If the reset is being sent 686 based on an existing connection state with negotiated session 687 identifiers, then the peer session identifier is used as the 688 destination session identifier in the reset packet. If the reset is 689 generated without any associated session state, then the destination 690 session identifier in the packet that generated the reset is used as 691 the source session identifer in the reset packet. 693 4.3 SYN cookies 695 For SYN cookies, a target may send a SYN-ACK without creating a 696 session state. A session identifier should be created so that it is 697 unique with other established sessions or any values used in other 698 SYN responses within last N minutes. When a client responds to the 699 SYN cookie ACK and the server verifies the SYN cookie is valid 700 (including the session identifier) the TCP connection state and 701 session state can then be created using the session identifier 702 provided in the received packet. As described in section 3.6 the 703 session identifier created in response to a SYN packet is based on a 704 secure hash and so is useful for validation of SYN cookies. 706 5 Security Considerations 708 Using strong end to end security is recommended with TOU. In 709 disassociated location encapsulation security is extremely important 710 to prevent spoofing and connection hijacking (assuming that an 711 attacker can deduce the session identifiers). In order to thwart this 712 end to end security should be established that authenticates the 713 nodes in a communication. 715 Security is provided using DTLS [RFC6347] and the GUE Payload 716 Transform Field [I-D.hy-gue-4-secure-transport]. The encapsulation 717 format of TOU with DTLS is: 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 722 | Source port | Destination port | | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP 724 | Length | Checksum | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 726 |0x0|0| Hlen | 59 | 0 |T|S|D| 0 | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Payload Transform Field | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | | 731 + Source session identifier + 732 | | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 + Destination session identifier + 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | | 739 ~ Encrypted transport layer packet ~ 740 | | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 The T flag bit in the GUE header indicates the presence of the 744 Payload Transform Field. 746 The Payload Transform field is defined as: 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Type | Payload Type | Reserved | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Type: Payload transform codepoint. 0x1 indicates DTLS. 754 Payload type: IP protocol of the encrypted payload. 756 The Proto/type field in the GUE header is set to 59 "no next header" 757 to indicate that the GUE payload cannot be parsed as an IP protocol. 759 6 IANA Considerations 761 Two bits and one field in the GUE header are reserved for TOU use. 763 Port 6080 has been reserved for GUE, however we will request another 764 port specfically for TOU. GUE would be used on this TOU port, however 765 only TOU that encapsulates a transport protocol with TCP-friendly 766 congestion control is used. Thus traffic destined to the TOU port (as 767 well as traffic in the reverse direction of a flow) can be assumed to 768 be properly congestion controlled and not subject to reflection or 769 other attacks common to some uses of UDP. 771 7 References 773 7.1 Normative References 775 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 776 August 1980, . 778 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 779 Security Version 1.2", RFC 6347, January 2012, 780 . 782 7.2 Informative References 784 [RFC7663] B. Trammell, Ed., M. Kuehlewind, Ed. "Report from the IAB 785 Workshop on Stack Evolution in a Middlebox Internet 786 (SEMI)}, October 2015. 788 [I-D.chesire-tcp-over-udp] Chesire, S., Graessley, J., and McGuire, 789 R., "Encapsulation of TCP and other Transport Protocols 790 over UDP", June 2013 792 [QUIC] Roskind, J., "QUIC: Multiplexed Stream Transport Over UDP", 793 http://www.ietf.org/proceedings/88/slides/slides-88- 794 tsvarea-10.pdf 796 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 797 Control Transmission Protocol (SCTP) Packets for End-Host 798 to End-Host Communication", RFC 6951, May 2013, 799 . 801 [I-D.hildebrand-spud-prototype] Hildebrand, J. and Trammell, B. 802 "Substrate Protocol for User Datagrams (SPUD) Prototype", 803 draft-hildebrand-spud-prototype-03 (work in preogress), 804 March 2015. 806 [I-D.ietf-nvo3-gue] Herbert, T., Yong, L., and Zia, O., "Generic UDP 807 Encapsulation", draft-ietf-nvo3-gue-01 (work in progress), 808 March 2016. 810 [I-D.hy-gue-4-secure-transport] Yong, L. and Herbert, T. Generic UDP 811 Encapsulation (GUE) for Secure Transport draft-hy-gue-4- 812 secure-transport-03 (work in progress), March 2016 814 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 815 Security Version 1.2", RFC 6347, January 2012, 816 . 818 Authors' Addresses 820 Tom Herbert 821 Facebook 822 1 Hacker Way 823 Menlo Park, CA 824 US 826 EMail: tom@herbertland.com