idnits 2.17.1 draft-ietf-behave-turn-tcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5163 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 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave S. Perreault, Ed. 3 Internet-Draft Viagenie 4 Intended status: Standards Track J. Rosenberg 5 Expires: September 9, 2010 Cisco Systems 6 March 8, 2010 8 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations 9 draft-ietf-behave-turn-tcp-06.txt 11 Abstract 13 This specification defines an extension of Traversal Using Relays 14 around NAT (TURN), a relay protocol for NAT traversal, to allow a 15 TURN client to request TCP allocations, and defines new requests and 16 indications for the TURN server to open and accept TCP connections 17 with the client's peers. TURN and this extension both purposefully 18 restrict the ways in which the relayed address can be used. In 19 particular, it prevents users from running general purpose servers 20 from ports obtained from the TURN server. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 65 4. Client Processing . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Creating an Allocation . . . . . . . . . . . . . . . . . . 6 67 4.2. Refreshing an Allocation . . . . . . . . . . . . . . . . . 6 68 4.3. Initiating a Connection . . . . . . . . . . . . . . . . . 7 69 4.4. Receiving a Connection . . . . . . . . . . . . . . . . . . 7 70 4.5. Sending and Receiving Data . . . . . . . . . . . . . . . . 8 71 4.6. Data Connection Maintenance . . . . . . . . . . . . . . . 8 72 5. TURN Server Behavior . . . . . . . . . . . . . . . . . . . . . 8 73 5.1. Receiving a TCP Allocate Request . . . . . . . . . . . . . 8 74 5.2. Receiving a Connect Request . . . . . . . . . . . . . . . 9 75 5.3. Receiving a TCP Connection on an Allocated Port . . . . . 10 76 5.4. Receiving a ConnectionBind Request . . . . . . . . . . . . 10 77 5.5. Data Connection Maintenance . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 6.1. New STUN Methods . . . . . . . . . . . . . . . . . . . . . 11 80 6.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 11 81 6.2.1. CONNECTION-ID . . . . . . . . . . . . . . . . . . . . 11 82 6.3. New STUN response codes . . . . . . . . . . . . . . . . . 12 83 6.4. Security Considerations . . . . . . . . . . . . . . . . . 12 84 6.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn] is an 93 extension to the Session Traversal Utilities for NAT [RFC5389] 94 protocol. TURN allows for clients to communicate with a TURN server, 95 and ask it to allocate ports on one of its host interfaces, and then 96 relay traffic between that port and the client itself. TURN, when 97 used in concert with STUN and Interactive Connectivity Establishment 98 (ICE) [I-D.ietf-mmusic-ice] form a solution for NAT traversal for 99 UDP-based media sessions. 101 However, TURN itself does not provide a way for a client to allocate 102 a TCP-based port on a TURN server. Such an allocation is needed for 103 cases where a TCP-based session is desired with a peer, and NATs 104 prevent a direct TCP connection. Examples include application 105 sharing between desktop softphones, or transmission of pictures 106 during a voice communications session. 108 This document defines an extension to TURN which allows a client to 109 obtain a TCP allocation. It also allows the client to initiate 110 outgoing TCP connections from that allocation to peers, and accept 111 incoming TCP connection requests from peers made towards that 112 allocation. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Overview of Operation 122 +--------+ 123 | | 124 | Peer1 | 125 / | | 126 / | | 127 / +--------+ 128 / 129 / 130 / Peer Data 1 131 / 132 +--------+ Control +--------+ / 133 | | -------------- | | / 134 | Client | Client Data 1 | TURN | 135 | | -------------- | Server | \ 136 | | -------------- | | \ 137 +--------+ Client Data 2 +--------+ \ 138 \ 139 \ 140 \ +--------+ 141 \ | | 142 Peer Data 2 \ | Peer2 | 143 \ | | 144 | | 145 +--------+ 147 Figure 1: TURN TCP Model 149 The overall model for TURN-TCP is shown in Figure 1. The client will 150 have two different types of connections to its TURN server. For each 151 allocated port, it will have a single control connection. Control 152 connections are used to obtain allocations and open up new 153 connections. Furthermore, for each connection to a peer, the client 154 will have a single connection to its TURN server. These connections 155 are called data connections. Consequently, there is a data 156 connection from the client to its TURN server (the client data 157 connection) and one from the TURN server to a peer (the peer data 158 connection). Actual application data is sent on these connections. 159 Indeed, after an initial TURN message which binds the client data 160 connection to a peer data connection, only application data can be 161 sent - no TURN messaging. This is in contrast to the control 162 connection, which only allows TURN messages and not application data. 164 To obtain a TCP-based allocation, a client must have a TCP or TLS 165 connection to its TURN server. Using that connection, it sends an 166 Allocate request. That request contains a REQUESTED-TRANSPORT 167 attribute, which indicates a TCP-based allocation is desired. A 168 server which supports this extension will allocate a TCP port and 169 begin listening for connection requests on that port. It then 170 returns the allocated port to the client in the response to the 171 Allocate request. The connection on which the Allocate request was 172 sent is the control connection. 174 If a client wishes to establish a TCP connection to a peer from that 175 allocated address, it issues a Connect request to the TURN server 176 over the control connection. That request contains a XOR-PEER- 177 ADDRESS attribute identifying the peer IP address and port to which a 178 connection is to be made. The TURN server attempts to open the TCP 179 connection, and assuming it succeeds, then responds to the Connect 180 request with a success response. The server also creates a 181 connection identifier associated with this connection, and passes 182 that connection identifier back to the client in the success 183 response. Note that a maximum of one connection to a given peer 184 (address and port combination) can be established per allocation. 186 In order to actually send data on the new connection or otherwise 187 utilize it in any way, the client establishes a new TCP connection to 188 its TURN server. Once established, it issues a ConnectionBind 189 request to the server. That request echoes back the connection 190 identifier to the TURN server. The TURN server uses it to correlate 191 the two connections. As a consequence, the TCP connection to the 192 peer is associated with a TCP connection to the client 1-to-1. The 193 two connections are now data connections. At this point, if the 194 server receives data from the peer, it forwards that data towards the 195 client, without any kind of encapsulation. Any data received by the 196 TURN server from the client over the client data connection are 197 forwarded to the peer, again without encapsulation or framing of any 198 kind. Once a connection has been bound using the ConnectionBind 199 request, TURN messaging is no longer permitted on the connection. 201 In a similar way, when a peer opens a TCP connection towards the 202 allocated port, the server checks if there is a permission in place 203 for that peer. If there is none, the connection is closed. 204 Permissions are created with the CreatePermission request sent over 205 the control connection, just as for UDP TURN. If there is a 206 permission in place, the TURN server sends, to the client, a 207 ConnectionAttempt Indication over the control connection. That 208 indication contains a connection identifier. Once again, the client 209 initiates a separate TCP connection to its TURN server, and over that 210 connection, issues a ConnectionBind request. Once received, the TURN 211 server will begin relaying data back and forth. The server closes 212 the peer data connection if no ConnectionBind request is received 213 after a timeout. 215 If the client closes a client data connection, the corresponding peer 216 data connection is closed. If the peer closes a peer data 217 connection, the corresponding client data connection is closed. In 218 this way, the status of the connection is directly known to the 219 client. 221 The TURN server will relay the data between the client and peer data 222 connections, utilizing an internal buffer. However, back pressure is 223 used in order to achieve end-to-end flow control. If the buffer from 224 client to peer fills up, the TURN server ceases to read off the 225 client data connection, which causes TCP backpressure through the OS 226 towards the client. 228 4. Client Processing 230 4.1. Creating an Allocation 232 To create a TCP allocation, a client MUST initiate a new TCP or TLS 233 connection to its TURN server, identical to the TCP or TLS procedures 234 defined in [I-D.ietf-behave-turn]. TCP allocations cannot be 235 obtained using a UDP association between client and server. 237 Once set up, a client MUST send a TURN Allocate request. That 238 request MUST contain a REQUESTED-TRANSPORT attribute whose value is 239 6, corresponding to TCP. 241 The request MUST NOT include a DONT-FRAGMENT, RESERVATION-TOKEN or 242 EVEN-PORT attribute. The corresponding features are specific to UDP 243 based capabilities and are not utilized by TURN-TCP. However, a 244 LIFETIME attribute MAY be included, with semantics identical to the 245 UDP case. 247 The procedures for authentication of the Allocate request and 248 processing of success and failure responses are identical to those 249 for UDP. 251 Once a success response is received, the TCP connection to the TURN 252 server is called the control connection for that allocation. 254 4.2. Refreshing an Allocation 256 The procedures for refreshing an allocation are identical to those 257 for UDP. Note that the Refresh MUST be sent on the control 258 connection. 260 4.3. Initiating a Connection 262 To initiate a TCP connection to a peer, a client MUST send a Connect 263 request over the control channel for the desired allocation. The 264 Connect request MUST include a XOR-PEER-ADDRESS attribute containing 265 the IP address and port of the peer to which a connection is desired. 267 If the connection is successfully established, the client will 268 receive a success response. That response will contain a 269 CONNECTION-ID attribute. The client MUST initiate a new TCP 270 connection to the server, utilizing the same destination IP address 271 and port to which the control connection was established. This 272 connection MUST be made using a different local IP address and/or 273 port. Authentication of the client by the server MUST use the same 274 method and credentials as for the control connection. Once 275 established, the client MUST send a ConnectionBind request. That 276 request MUST include the CONNECTION-ID attribute, echoed from the 277 Connect Success response. When a response to the ConnectionBind 278 request is received, if it is a success, the TCP connection on which 279 it was sent is called the client data connection corresponding to the 280 peer. 282 If the result of the Connect request was a Error Response, and the 283 response code was 447, it means that the TURN server was unable to 284 connect to the peer. The client MAY retry with the same XOR-PEER- 285 ADDRESS attribute, but MUST wait at least 10 seconds. 287 As with any other request, multiple Connect requests MAY be sent 288 simultaneously. However, Connect requests with the same XOR-PEER- 289 ADDRESS parameter MUST NOT be sent simultaneously. 291 4.4. Receiving a Connection 293 After an Allocate request is successfully processed by the server, 294 the client will start receiving a ConnectionAttempt indication each 295 time a peer for which a permission has been installed attempts a new 296 connection to the allocated address. This indication will contain a 297 CONNECTION-ID and a XOR-PEER-ADDRESS attributes. If the client 298 wishes to accept this connection, it MUST initiate a new TCP 299 connection to the server, utilizing the same destination IP address 300 and port to which the control connection was established. This 301 connection MUST be made using a different local IP address and/or 302 port. Authentication of the client by the server MUST use the same 303 method and credentials as for the control connection. Once 304 established, the client MUST send a ConnectionBind request. That 305 request MUST include the CONNECTION-ID attribute, echoed from the 306 ConnectionAttempt indication. When a response to the ConnectionBind 307 request is received, if it is a success, the TCP connection on which 308 it was sent is called the client data connection corresponding to the 309 peer. 311 4.5. Sending and Receiving Data 313 Once a client data connection is established, data sent on it by the 314 client will be relayed as-is to the peer by the server. Similarly, 315 data sent by the peer to the server will be relayed as-is to the 316 client over the data connection. 318 4.6. Data Connection Maintenance 320 The client MUST refresh the allocation corresponding to a data 321 connection, using the Refresh request as defined in 322 [I-D.ietf-behave-turn], for as long as it wants to keep the data 323 connection alive. 325 When the client wishes to terminate its relayed connection to the 326 peer, it closes the data connection to the server. 328 Note: No mechanism for keeping alive the NAT bindings (potentially 329 on the client data connection as well as on the peer data 330 connection) is included. This service is not provided by TURN- 331 TCP. If such a feature is deemed necessary, it can be implemented 332 higher up the stack, in the application protocol being tunneled 333 inside TURN-TCP. Also, TCP keep-alives MAY be used to keep the 334 NAT bindings on the client data connection alive. 336 5. TURN Server Behavior 338 5.1. Receiving a TCP Allocate Request 340 The process is similar to that defined in [I-D.ietf-behave-turn], 341 Section 6.2, with the following exceptions: 343 1. If the REQUESTED-TRANSPORT attribute is included and specifies a 344 protocol other than UDP or TCP, the server MUST reject the 345 request with a 442 (Unsupported Transport Protocol) error. (If 346 the value is UDP, the server MUST continue with the procedures of 347 [I-D.ietf-behave-turn] instead of this document.) 349 2. If the client connection transport is not TCP or TLS, the server 350 MUST reject the request with a 400 (Bad Request) error. 352 3. If the request contains the DONT-FRAGMENT, EVEN-PORT, or 353 RESERVATION-TOKEN attribute, the server MUST reject the request 354 with a 400 (Bad Request) error. 356 4. A TCP relayed transport address MUST be allocated instead of a 357 UDP one. 359 5. The RESERVATION-TOKEN attribute MUST NOT be present in the 360 success response. 362 If all checks pass, the server MUST start accepting incoming TCP 363 connections on the relayed transport address. Refer to Section 5.3 364 for details. 366 5.2. Receiving a Connect Request 368 When the server receives a Connect request, it processes as follows. 370 If the request is received on a TCP connection for which no 371 allocation exists, the server MUST return a 437 (Allocation Mismatch) 372 error. 374 If the server is currently processing a Connect request for this 375 allocation with the same XOR-PEER-ADDRESS, it MUST return a 446 376 (Connection Already Exists) error. 378 If the server has already successfully processed a Connect request 379 for this allocation with the same XOR-PEER-ADDRESS, and the resulting 380 client and peer data connections are either pending or active, it 381 MUST return a 446 (Connection Already Exists) error. 383 If the request does not contain a XOR-PEER-ADDRESS attribute, or if 384 such attribute is invalid, the server MUST return a 400 (Bad Request) 385 error. 387 Otherwise, and if the new connection is permitted by local policy, 388 the server MUST initiate an outgoing TCP connection. The local 389 endpoint is the relayed transport address associated with the 390 allocation. The remote endpoint is the one indicated by the XOR- 391 PEER-ADDRESS attribute. If the connection attempt fails or times 392 out, the server MUST return a 447 (Connection Timeout or Failure) 393 error. The timeout value MUST be at least 30 seconds. 395 If the connection is successful, it is now called a peer data 396 connection. The server MUST buffer any data received from the 397 client. Data MUST NOT be lost unless the buffer exceeds a limit 398 defined by local policy, in which case the data connection MUST be 399 closed. The server adjusts its advertised TCP receive window to 400 reflect the amount of empty buffer space. 402 The server MUST include the CONNECTION-ID attribute in the Connect 403 success response. The attribute's value MUST uniquely identify the 404 peer data connection. 406 If no ConnectionBind request associated with this peer data 407 connection is received after 30 seconds, the peer data connection 408 MUST be closed. 410 5.3. Receiving a TCP Connection on an Allocated Port 412 When a server receives an incoming TCP connection on a relayed 413 transport, it processes as follows. 415 The server MUST accept the connection. If it is not successful, 416 nothing is sent to the client over the control connection. 418 If the connection is successfully accepted, it is now called a peer 419 data connection. The server MUST buffer any data received from the 420 peer. Data MUST NOT be lost unless the buffer is about to exceed a 421 limit defined by local policy, in which case the data connection MUST 422 be closed. The server adjusts its advertised TCP receive window to 423 reflect the amount of empty buffer space. 425 If no permission for this peer has been installed for this 426 allocation, the server MUST close the connection with the peer 427 immediately after it has been accepted. 429 Otherwise, the server sends a ConnectionAttempt indication to the 430 client over the control connection. The indication MUST include a 431 XOR-PEER-ADDRESS attribute containing the peer's address, as well as 432 a CONNECTION-ID attribute uniquely identifying the peer data 433 connection. 435 If no ConnectionBind request associated with this peer data 436 connection is received after 30 seconds, the peer data connection 437 MUST be closed. 439 5.4. Receiving a ConnectionBind Request 441 When a server receives a ConnectionBind request, it processes as 442 follows. 444 If the client connection transport is not TCP or TLS, the server MUST 445 return a 400 (Bad Request) error. 447 If the request does not contain the CONNECTION-ID attribute, or if 448 this attribute does not refer to an existing pending connection, the 449 server MUST return a 400 (Bad Request) error. 451 Otherwise, the client connection is now called a client data 452 connection. Data received on it MUST be sent as-is to the associated 453 peer data connection. 455 Data received on the associated peer data connection MUST be sent 456 as-is on this client data connection. This includes data that was 457 received after the associated Connect or request was successfully 458 processed and before this ConnectionBind request was received. 460 5.5. Data Connection Maintenance 462 If the allocation associated with a data connection expires, the data 463 connection MUST be closed. 465 When a client data connection is closed or times out, the server MUST 466 close the corresponding peer data connection. 468 When a peer data connection is closed or times out, the server MUST 469 close the corresponding client data connection. 471 6. IANA Considerations 473 This specification defines several new STUN methods, STUN attributes, 474 and STUN error codes. This section directs IANA to add these new 475 protocol elements to the IANA registry of STUN protocol elements. 477 6.1. New STUN Methods 479 This section lists the codepoints for the new STUN methods defined in 480 this specification. See Section 4 and Section 5 for the semantics of 481 these new methods. 483 0x000A : Connect 484 0x000B : ConnectionBind 485 0x000C : ConnectionAttempt 487 6.2. New STUN Attributes 489 This STUN extension defines the following new attributes: 491 0x002A : CONNECTION-ID 493 6.2.1. CONNECTION-ID 495 The CONNECTION-ID attributes uniquely identifies a peer data 496 connection. It is a 32-bit unsigned integral value. 498 6.3. New STUN response codes 500 446 Connection Already Exists 501 447 Connection Timeout or Failure 503 6.4. Security Considerations 505 After a TCP connection is established between the server and a peer, 506 and before a ConnectionBind request is received from the client, the 507 server buffers all data received from the peer. This protocol 508 specification lets the server drop the connection if the buffer size 509 is about to exceed a limit defined by local policy. This policy 510 should ensure that memory resources are not exceeded. See also 511 [RFC4732], Section 2.1.3. 513 All the security considerations applicable to STUN [RFC5389] and TURN 514 [I-D.ietf-behave-turn] are applicable to this document as well. 516 6.5. Acknowledgements 518 Thanks to Rohan Mahy and Philip Matthews for their initial work on 519 getting this document started. 521 The authors would also like to thank Alfred E. Heggestad, Ari 522 Keranen, Marc Petit-Huguenin, Dave Thaler, and Dan Wing for their 523 comments and suggestions. 525 7. References 527 7.1. Normative References 529 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 530 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 531 October 2008. 533 [I-D.ietf-behave-turn] 534 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 535 Relays around NAT (TURN): Relay Extensions to Session 536 Traversal Utilities for NAT (STUN)", 537 draft-ietf-behave-turn-16 (work in progress), July 2009. 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, March 1997. 542 7.2. Informative References 544 [I-D.ietf-mmusic-ice] 545 Rosenberg, J., "Interactive Connectivity Establishment 546 (ICE): A Protocol for Network Address Translator (NAT) 547 Traversal for Offer/Answer Protocols", 548 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 550 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 551 Service Considerations", RFC 4732, December 2006. 553 Authors' Addresses 555 Simon Perreault (editor) 556 Viagenie 557 2600 boul. Laurier, suite 625 558 Quebec, QC G1V 4W1 559 Canada 561 Phone: +1 418 656 9254 562 Email: simon.perreault@viagenie.ca 563 URI: http://www.viagenie.ca 565 Jonathan Rosenberg 566 Cisco Systems 567 600 Lanidex Plaza 568 Parsippany, NJ 07054 569 US 571 Phone: +1 973 952-5000 572 Email: jdrosen@cisco.com 573 URI: http://www.jdrosen.net