idnits 2.17.1 draft-martinsen-tram-ssoda-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2014) is 3482 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 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Uberti 5 Expires: March 19, 2015 Google 6 O. Moskalenko 7 Unaffiliated 8 September 15, 2014 10 Single SOcket Dual Allocation with TURN 11 draft-martinsen-tram-ssoda-01 13 Abstract 15 This draft describes a simple method for allocating one IPv4 and one 16 IPv6 relay address from a single ALLOCATE request to the TURN server. 17 This saves local ports on the client, reduces the number of 18 candidates gathered by the client, and reduces the number of messages 19 sent between the client and the TURN server. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 19, 2015. 44 Copyright Notice 46 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Creating an Allocation . . . . . . . . . . . . . . . . . . . 3 63 2.1. Sending an Allocate Request . . . . . . . . . . . . . . . 3 64 2.2. Receiving an Allocate Request . . . . . . . . . . . . . . 3 65 2.3. Receiving an Allocate Success Response . . . . . . . . . 5 66 2.4. Receiving an Allocate Error Response . . . . . . . . . . 5 67 3. Refreshing an Allocation . . . . . . . . . . . . . . . . . . 5 68 3.1. Sending a Refresh Request . . . . . . . . . . . . . . . . 6 69 3.2. Receiving a Refresh Request . . . . . . . . . . . . . . . 6 70 3.3. CreatePermission . . . . . . . . . . . . . . . . . . . . 6 71 3.3.1. Sending a CreatePermission Request . . . . . . . . . 6 72 3.3.2. Receiving a CreatePermission Request . . . . . . . . 7 73 4. Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 75 5.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.2. NATTools . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The main motivation for this draft is to reduce the number of local 85 ports on the client, reduce the number of candidates gathered during 86 the discovery process, and reduce the number of messages that need to 87 be exchanged to allocate the relay addresses needed for ICE. 89 Reducing the number of local ports is important as it saves resources 90 at three places in the network. First, the number of open ports on 91 the client is reduced, leading to fewer host candidates. Secondly, 92 with fewer local host ports there will be fewer NAT bindings for the 93 NAT to keep track of, and fewer server reflexive candidates. Lastly, 94 with a single 5-tuple in use, it reduces the number of open ports the 95 TURN server needs to open on the interface towards the client 96 (Private side). As ports are a scarce resource (16-bit number) 97 preserving them on the NAT and a the TURN server can make large scale 98 deployments easier. 100 2. Creating an Allocation 102 The behavior specified here affects the processing defined in 103 Section 6 of [RFC5766] and Section 4 of [RFC6156]. 105 2.1. Sending an Allocate Request 107 A client that wishes to obtain one IPv6 and one IPv4 by sending one 108 Allocate request MUST include two REQUESTED-ADDRESS-FAMILY 109 attributes, one for each address family, in the Allocate request that 110 it sends to the TURN server. The order of the REQUESTED-ADDRESS- 111 FAMILY is arbitrary, because the server either understands SSODA 112 (then the order does not matter) or the server does not understand 113 SSODA (then the server behavior is undefined - it may return a 400 114 error, or it may take the first attribute, or it may take the last 115 attribute). Multiple candidates of the same family are not 116 supported; the client MUST NOT include more than one REQUESTED- 117 ADDRESS-FAMILY attribute for a given address family. The mechanism 118 to formulate an Allocate request is described in Section 6.1 of 119 [RFC5766]. 121 The SSODA mechanism is not available when using the odd/ even port 122 allocation scheme. Clients MUST NOT include a REQUESTED-ADDRESS- 123 FAMILY attribute in an Allocate request that contains a RESERVATION- 124 TOKEN attribute. Clients MUST NOT include a second REQUESTED- 125 ADDRESS-FAMILY attribute in an Allocate request that contains an 126 EVEN-PORT attribute. 128 2.2. Receiving an Allocate Request 130 Once a server has verified that the request is authenticated and has 131 not been tampered with, the TURN server processes the Allocate 132 request following the rules in [RFC5766] and [RFC6156].. Only one 133 REQUESTED-ADDRESS-FAMILY attribute with the same family value is 134 allowed in the request. If two attributes with the same family value 135 exist the server MUST return 400 Bad Request error. 137 If no REQUESTED-ADDRESS-FAMILY attributes are present, the server 138 MUST treat this as if the request contained a single REQUESTED- 139 ADDRESS-FAMILY specifying the IPv4 address family. 141 If the server can successfully process the request, it allocates a 142 relay address for each of the REQUESTED-ADDRESS-FAMILY attributes 143 present in the Allocate request. The allocated relay addresses are 144 returned in separate XOR-RELAYED-ADDRESS attributes in the Allocate 145 response message. The ordering of the XOR-RELAYED-ADDRESS attributes 146 in the response is arbitrary. 148 If the server cannot satisfy the request at all, because none of the 149 specified address families are supported, the server MUST return a 150 440 error code, as indicated in [RFC6156]. 152 If the server cannot satisfy the request at all, because the server 153 could not allocate any of the specified addresses, the server MUST 154 return a 508 (Insufficient Capacity) error code as indicated in 155 [RFC5766]. 157 If some of the requested address could be allocated, but some could 158 not, either because the requested address family is not supported, or 159 the server currently lacks capacity, the server MUST indicate this 160 partial success by returning an Allocate Success Response that 161 contains XOR-RELAYED-ADDRESS attributes for the addresses that were 162 successfully allocated, as well as XOR-RELAYED-ADDRESS with ANY 163 addresses (that is, IPv4 address 0.0.0.0:0 or IPv6 address [::0]:0) 164 corresponding to the address families that could not be allocated. 165 This will notify the client that the desired REQUESTED-ADDRESS-FAMILY 166 was understood, but could not be allocated. A success response with 167 ANY addresses MUST NOT be returned if all allocation requests cannot 168 be satisfied; instead, an error response should be returned, as 169 indicated above. 171 This somewhat unusual pattern of partial success is used to avoid the 172 need for an additional round-trip when the client just wants whatever 173 address families the TURN server supports. 175 Note that while allocating multiple address families at the same time 176 is supported, doing this sequentially is not. The server MUST reject 177 any attempt to "add" an address family to an existing allocation with 178 a 437 (Allocation Mismatch) error code. 180 [OPEN ISSUE 1: do we need to include REQUESTED-ADDRESS-FAMILY 181 attribute(s) with failed address family (or families) to help the 182 client to recognize whether this is an "old" non-SSODA server or a 183 "new" SSODA-supporting server ?] 185 [OPEN ISSUE 2: do we have to consider a particular ordering of 186 REQUESTED-ADDRESS-FAMILY and REQUESTED-ADDRESS-FAMILY attributes in 187 the ALLOCATE request and response ? Can attribute ordering provide 188 some benefits in this case ?] 190 2.3. Receiving an Allocate Success Response 192 This section describes how the client must react on receiving a 193 response to the dual allocation request. If the client is not using 194 dual allocation, then the behavior is the same as the rules in 195 [RFC5766] and in [RFC6156]. 197 If the client receives an Allocate Success Response containing a non- 198 ANY (ANY as defined above) XOR-RELAYED-ADDRESS attribute for each of 199 the REQUESTED-ADDRESS-FAMILY attributes in the Allocate request sent 200 by the client, the client knows that the TURN server supports 201 multiple address family allocation over a single socket. All relay 202 addresses can now be used by the client. 204 If the Allocate response contains both usable XOR-RELAYED-ADDRESS 205 attributes as well as ANY XOR-RELAYED-ADDRESS attributes, then the 206 client knows that the TURN server "understands" dual allocation SSODA 207 request, but the server either does not support one of the requested 208 address families or cannot currently allocate an address of that 209 family. The allocated non-ANY address can be used, but the client 210 SHOULD NOT try to allocate any of the unsupported families on a 211 different 5-tuple. 213 If the Allocate Response contains only one XOR-RELAYED-ADDRESS 214 attribute, then the client knows that the TURN server does not 215 support SSODA. The client can retry the missing address family 216 allocations on new 5-tuples, if desired. Subsequent Allocate 217 requests towards the same TURN server SHOULD NOT include multiple 218 REQUESTED-ADDRESS-FAMILY attributes. 220 2.4. Receiving an Allocate Error Response 222 When doing dual allocation, if the client receives an Allocate error 223 response with the 440 (Unsupported Address Family) error code, then 224 the client knows that the TURN server does not support any of the 225 desired address families, or might be a non-SSODA server that 226 misinterpreted the included REQUESTED-ADDRESS-FAMILY attributes in 227 the Allocate request. The client SHOULD retry its IPv4 request on 228 the same 5-tuple, with no REQUESTED-ADDRESS-FAMILY attribute, and MAY 229 retry other address families on different local ports, by sending an 230 Allocate request with only one REQUESTED-ADDRESS-FAMILY attribute. 232 3. Refreshing an Allocation 234 The behavior specified here affects the processing defined in 235 Section 7 of [RFC5766] and Section 5 of [RFC6156]. This section MUST 236 only be used if the client has verified that the TURN server supports 237 SSODA during the allocation creation described in Section 2.1. 238 Otherwise, revert back to RFC 5766 or RFC 6156 behavior. 240 3.1. Sending a Refresh Request 242 To perform an allocation refresh, the client generates a Refresh 243 Request as described in Section 7.1 of [RFC5766]. When refreshing a 244 dual allocation, the client SHOULD include one or more REQUESTED- 245 ADDRESS-FAMILY attributes describing the the family types that should 246 be refreshed; the client MUST only include family types that it 247 previously allocated and has not yet deleted. When refreshing a 248 (single) allocation on a server that does not not support SSODA, 249 REQUESTED-ADDRESS-FAMILY should be omitted, for backwards 250 compatibility. 252 This process can also be used to delete an allocation of a specific 253 address type, by setting the lifetime of that refresh request to 0. 254 It is possible to delete one or more allocations depending on how 255 many REQUESTED-ADDRESS-FAMILY attributes are included. Deleting a 256 single allocation destroys any permissions or channels associated 257 with that particular allocation; it MUST NOT affect any permissions 258 or channels associated with allocations for other address families. 260 3.2. Receiving a Refresh Request 262 The server refreshes the allocated address families that match the 263 supplied REQUESTED-ADDRESS-FAMILY values. If any of the values in 264 the request do not match a currently allocated address, the server 265 MUST respond with a 437 (Allocation Mismatch) error. [OPEN ISSUE: 266 discuss whether this is the right error code for the situation] If no 267 REQUESTED-ADDRESS-FAMILY is present, the request should be treated as 268 applying to all current allocations, for backward compatibility. 270 The server MUST then refresh or delete the specified allocations, and 271 return a Refresh Success Response. 273 3.3. CreatePermission 275 The behavior specified here affects the processing defined in 276 Section 9 of [RFC5766] and Section 6 of [RFC6156] 278 3.3.1. Sending a CreatePermission Request 280 The client MUST only include XOR-PEER-ADDRESS attributes with 281 addresses that match an address family of one of the currently 282 allocated addresses. 284 3.3.2. Receiving a CreatePermission Request 286 If an XOR-PEER-ADDRESS attribute contains an address of an address 287 family different than that any of the relayed transport addresses 288 allocated, the server MUST generate an error response with the 443 289 (Peer Address Family Mismatch) response code, which is defined in 290 Section 6.2.1 of [RFC6156]. 292 4. Channels 294 The session channels setup process follows the same rules as in 295 [RFC5766] and in [RFC6156]; the client is allowed to set up multiple 296 channels within the same 5-tuple session. However, when using SSODA 297 and dual allocation, the peer addresses of those channels may be of 298 different families. Thus, a single 5-tuple session may create 299 several IPv4 channels and several IPv6 channels. 301 5. Implementation Status 303 [Note to RFC Editor: Please remove this section and reference to 304 [RFC6982] prior to publication.] 306 This section records the status of known implementations of the 307 protocol defined by this specification at the time of posting of this 308 Internet-Draft, and is based on a proposal described in [RFC6982]. 309 The description of implementations in this section is intended to 310 assist the IETF in its decision processes in progressing drafts to 311 RFCs. Please note that the listing of any individual implementation 312 here does not imply endorsement by the IETF. Furthermore, no effort 313 has been spent to verify the information presented here that was 314 supplied by IETF contributors. This is not intended as, and must not 315 be construed to be, a catalog of available implementations or their 316 features. Readers are advised to note that other implementations may 317 exist. 319 According to [RFC6982], "this will allow reviewers and working groups 320 to assign due consideration to documents that have the benefit of 321 running code, which may serve as evidence of valuable experimentation 322 and feedback that have made the implemented protocols more mature. 323 It is up to the individual working groups to use this information as 324 they see fit". 326 5.1. open-sys 328 Organization: This is a public project, the full list of authors 329 and contributors here: http://turnserver.open-sys.org/downloads/ 330 AUTHORS 332 Description: A mature open-source TURN server specs implementation 333 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 334 applications, especially geared for WebRTC. 336 Implementation: http://code.google.com/p/coturn/ 338 Level of maturity: The TURN SSODA extension implementation can be 339 qualified as "production" - it is well tested and fully 340 implemented, but not widely used, yet.. 342 Coverage: Fully implements SSODA this draft. 344 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 346 Implementation experience: Few changes to existing code 348 Contact: Oleg Moskalenko . 350 5.2. NATTools 352 Organization: Cisco 354 Description: NATTools is a set of client side focused ICE/TURN/STUN 355 libraries. 357 Implementation: https://github.com/cisco/NATTools 359 Level of maturity: Running test code works well. Not tested in any 360 released products. 362 Coverage: Implement this draft. 364 Licensing: BSD 366 Implementation experience: Simple, few changes to the client. 368 Contact: Paal-Erik Martinsen . 370 6. Security Considerations 372 As the client can ask for two allocations for each allocation request 373 sent, the TURN server can be DOS attacked with fewer messages. 374 However this problem is minimal as the messages needs to be 375 authenticated first as described in RFC 5766 [RFC5766]. 377 7. Acknowledgements 379 Authors would like to thank Simon Perreault for providing ideas 380 direction and insight. Jonathan Lennox provided excellent feedback 381 on the mailing list. 383 8. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 389 Relays around NAT (TURN): Relay Extensions to Session 390 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 392 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 393 Using Relays around NAT (TURN) Extension for IPv6", RFC 394 6156, April 2011. 396 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 397 Code: The Implementation Status Section", RFC 6982, July 398 2013. 400 Authors' Addresses 402 Paal-Erik Martinsen 403 Cisco Systems, Inc. 404 Philip Pedersens vei 20 405 Lysaker, Akershus 1366 406 Norway 408 Email: palmarti@cisco.com 410 Justin Uberti 411 Google 412 Kirkland, WA 413 USA 415 Email: justin@uberti.name 416 Oleg Moskalenko 417 Unaffiliated 418 Walnut Creek, CA 419 USA 421 Email: mom040267@gmail.com 422 URI: https://code.google.com/p/coturn/