idnits 2.17.1 draft-ietf-behave-turn-tcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 377. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 11, 2007) is 6010 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) -- Looks like a reference, but probably isn't: 'TODO' on line 183 == Unused Reference: '1' is defined on line 283, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 292, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 297, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 301, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 304, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 306, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 318, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-11 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-04 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave J. Rosenberg 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R. Mahy 5 Expires: May 14, 2008 Plantronics, Inc. 6 November 11, 2007 8 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations 9 draft-ietf-behave-turn-tcp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This specification defines an extension of Traversal Using Relays 43 around NAT (TURN), a relay protocol for NAT traversal, to allows a 44 TURN client to request TCP allocations, and defines new requests and 45 indications for the TURN server to open and accept and manage TCP 46 connection with the client's peers. TURN and this extension both 47 purposefully restricts the ways in which the relayed address can be 48 used. In particular, it prevents users from running general purpose 49 servers from ports obtained from the STUN server. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Initial Allocations . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Managing TCP Peers . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Connect Request . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Listen Permission Request . . . . . . . . . . . . . . . . . 4 58 3.3. Connection Status Indication . . . . . . . . . . . . . . . 4 59 4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. New value in REQUESTED-TRANSPORT . . . . . . . . . . . . . . . 5 61 6. New CONNECT-STAT Attribute . . . . . . . . . . . . . . . . . . 5 62 7. New Error Reponse Codes . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. New STUN Requests, Responses, and Indications . . . . . . . 6 66 9.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . . 6 67 9.3. New STUN response codes . . . . . . . . . . . . . . . . . . 6 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 14.1. Normative References . . . . . . . . . . . . . . . . . . . 7 74 14.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 Intellectual Property and Copyright Statements . . . . . . . . . . 9 78 1. Introduction 80 For TCP connections, the Connection Request allows the client to ask 81 the server to open a connection to the peer. This also adds a 82 permission to accept an incoming TCP connection from the remote 83 address of the peer. When the server and the peer try to open a TCP 84 connection at the same time, this is called TCP simultaneous open. 85 With a Listen Permission request a client can ask the server just to 86 add a permission to the peer and listen for a connection request. 88 When the TURN-to-peer leg is TCP, the TURN client needs to be aware 89 of the status of these TCP connections. Consequently, the TURN 90 server sends a Connection State Indication for a binding whenever the 91 relay connection status changes for one of the client's bindings, 92 except when the status changes due to a TURN client request (ex: an 93 explicit binding deallocation). 95 2. Initial Allocations 97 The procedures for an initial allocation are nearly identical to 98 those in the core TURN specification [2]. Define new value for 99 REQUESTED-TRANSPORT attribute. The client MUST NOT request the TCP 100 transport in an Allocate request sent to the TURN server over UDP. 102 3. Managing TCP Peers 104 3.1. Connect Request 106 The Connect Request is used by a client when it has obtained an 107 allocated transport address that is TCP. The client can use the 108 Connect Request to ask the server to open a TCP connection to a 109 specified destination address included in the request. 111 If the allocation is for a UDP port, the server MUST reject the 112 request with a 445 (Operation for TCP Only) response. If the request 113 does not contain a REMOTE-ADDRESS attribute, the server sends a 400 114 (Bad Request) Connect error response,. 116 If the request contains a REMOTE-ADDRESS attribute, the IP address 117 contained within it is added to the permissions for this allocation, 118 if it was not already present. This happens regardless of whether 119 the subsequent TCP connection attempt succeeds or not. 121 If a connection already exists for this address and port, the server 122 returns a 446 (Connection Already Exists) Connect error response. 123 Otherwise the server tries to establish the corresponding TCP 124 connection and returns a Connect Success Response. This just 125 indicates that the server added the permission and is attempting to 126 establish a TCP connection. The server does not wait for the 127 connection attempt to succeed or fail. The status of the connection 128 attempt is returned via the Connect Status Indication. 130 Note that the server needs to use the same source connection 131 address for all connections/permissions associated with an 132 allocation. For servers written using Berkeley sockets, the 133 SO_REUSEADDR flag is typically used to use the same local address 134 with multiple sockets. 136 3.2. Listen Permission Request 138 The Listen Permission Request is used by the client to ask the server 139 to create a permission for a TCP peer without attempting to make a 140 connection to that peer. If it has not already done so, the server 141 should start listening on the allocated port and should be prepared 142 to accept any incoming connection requests from a peer with an active 143 permission. 145 Note that the server needs to use the same source connection 146 address for all connections/permissions associated with an 147 allocation. For servers written using Berkeley sockets, the 148 SO_REUSEADDR flag is typically used to use the same local address 149 with multiple sockets. 151 3.3. Connection Status Indication 153 When the TURN to peer leg is TCP, the TURN client needs to be aware 154 of the status of TCP connections and other open permissions created 155 on its behalf. The TURN extension defines application states for a 156 TCP connection as follows: LISTEN, ESTABLISHED, CLOSED. 157 Consequently, the TURN server sends a Connection State Indication for 158 a TCP permission whenever the relay connection status changes for one 159 of the client's permissions except when the status changes due to a 160 TURN client request (ex: an explicit binding close or deallocation). 161 A Connection Status Indiciation MUST also contain a REMOTE-ADDRESS 162 attribute. 164 A TURN can only relay to a peer over TCP if the client 165 communicates with the server over TCP or TLS over TCP. Because of 166 this, the server can be assured that Connection Status Indications 167 are received reliably. 169 4. Forwarding 171 If a server receives a TCP connection request on an allocated TCP 172 transport address, it checks the permissions associated with that 173 allocation. If the source IP address of the TCP SYN packet matches 174 one of the permissions (the source port does not need to match), the 175 TCP connection is accepted. Otherwise, it is rejected. When a TCP 176 connection is accepted, the server sends the corresponding client a 177 Connect Status Indication with the CONNECT-STAT attribute set to 178 ESTABLISHED. No information is passed to the client if the server 179 rejects the connection because there is no corresponding permission. 181 If a server receives data on a TCP connection that terminates on the 182 allocated TCP transport address, the server sends the data received 183 on the TCP connection to the client as described in [TODO]. 185 Note that, because data is forwarded blindly across TCP bindings, 186 TLS will successfully operate over a TURN allocated TCP port if 187 the linkage to the client is also TCP. 189 5. New value in REQUESTED-TRANSPORT 191 This attribute is used by the client to request a specific transport 192 protocol for the allocated transport address. It is a 32 bit 193 unsigned integer. Its values are: 195 0x0000 0000: UDP 196 0x0000 0001: TCP 198 If an Allocate request is sent over TCP and requests a UDP 199 allocation, or an Allocate request is sent over TLS over TCP and 200 requests a UDP or TCP allocation, the server will relay data between 201 the two transports. 203 Extensions to TURN can define additional transport protocols in an 204 IETF-consensus RFC. 206 6. New CONNECT-STAT Attribute 208 The connection status attribute is used by the server to convey the 209 status of server-to-peer connections. It is a 32 bit unsigned 210 integer. Its values are: 212 0x0000 0000: LISTEN 213 0x0000 0001: ESTABLISHED 214 0x0000 0002: CLOSED 216 7. New Error Reponse Codes 218 445 (Operation for TCP Only): The client tried to send a request to 219 perform a TCP-only operation on an allocation, and allocation is UDP. 221 446 (Connection Already Exists): The client tried to open a 222 connection to a peer, but a connection to that peer already exists. 224 8. Security Considerations 226 9. IANA Considerations 228 This specification defines several new STUN messages, STUN 229 attributes, and STUN response codes. This section directs IANA to 230 add these new protocol elements to the IANA registry of STUN protocol 231 elements. 233 9.1. New STUN Requests, Responses, and Indications 235 Request/Response Transactions 236 0x007 : Connect 237 0x008 : Listen Permission 239 Indications 240 0x009 : Connect Status 242 9.2. New STUN Attributes 244 0x0023: CONNECT-STAT 246 9.3. New STUN response codes 248 445 Operation for TCP Only 249 446 Connection Already Exists 251 10. Security Considerations 253 TBD 255 11. IANA Considerations 257 TBD 259 12. IAB Considerations 261 The IAB has studied the problem of "Unilateral Self Address Fixing", 262 which is the general process by which a client attempts to determine 263 its address in another realm on the other side of a NAT through a 264 collaborative protocol reflection mechanism RFC 3424 [8]. The TURN 265 extension is an example of a protocol that performs this type of 266 function. The IAB has mandated that any protocols developed for this 267 purpose document a specific set of considerations. 269 TURN is an extension of the STUN protocol. As such, the specific 270 usages of STUN that use the TURN extensions need to specifically 271 address these considerations. Currently the only STUN usage that 272 uses TURN is ICE [9]. 274 13. Acknowledgements 276 The authors would like to thank Marc Petit-Huguenin for his comments 277 and suggestions. 279 14. References 281 14.1. Normative References 283 [1] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 284 Wing, "Session Traversal Utilities for (NAT) (STUN)", 285 draft-ietf-behave-rfc3489bis-11 (work in progress), 286 October 2007. 288 [2] Rosenberg, J., "Traversal Using Relays around NAT (TURN): Relay 289 Extensions to Session Traversal Utilities for NAT (STUN)", 290 draft-ietf-behave-turn-04 (work in progress), July 2007. 292 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 293 Levels", BCP 14, RFC 2119, March 1997. 295 14.2. Informative References 297 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 298 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 299 RFC 3550, July 2003. 301 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 302 Session Description Protocol (SDP)", RFC 3264, June 2002. 304 [6] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 306 [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 307 December 2005. 309 [8] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- 310 Address Fixing (UNSAF) Across Network Address Translation", 311 RFC 3424, November 2002. 313 [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 314 Protocol for Network Address Translator (NAT) Traversal for 315 Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in 316 progress), October 2007. 318 [10] Audet, F. and C. Jennings, "NAT Behavioral Requirements for 319 Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), 320 October 2006. 322 Authors' Addresses 324 Jonathan Rosenberg 325 Cisco Systems 326 600 Lanidex Plaza 327 Parsippany, NJ 07054 328 US 330 Phone: +1 973 952-5000 331 Email: jdrosen@cisco.com 332 URI: http://www.jdrosen.net 334 Rohan Mahy 335 Plantronics, Inc. 337 Email: rohan@ekabal.com 339 Full Copyright Statement 341 Copyright (C) The IETF Trust (2007). 343 This document is subject to the rights, licenses and restrictions 344 contained in BCP 78, and except as set forth therein, the authors 345 retain all their rights. 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 350 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 351 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Intellectual Property 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; nor does it represent that it has 362 made any independent effort to identify any such rights. Information 363 on the procedures with respect to rights in RFC documents can be 364 found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use of 369 such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository at 371 http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at 377 ietf-ipr@ietf.org. 379 Acknowledgment 381 Funding for the RFC Editor function is provided by the IETF 382 Administrative Support Activity (IASA).