idnits 2.17.1 draft-thomson-tram-turn-bandwidth-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 == 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 date (July 4, 2014) is 3576 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) == Unused Reference: 'RFC5245' is defined on line 309, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-02) exists of draft-martinsen-tram-discuss-00 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Standards Track B. Aboba 5 Expires: January 5, 2015 Microsoft 6 A. Johnston 7 Avaya 8 O. Moskalenko 9 public project 10 rfc5766-turn-server 11 July 4, 2014 13 A Bandwidth Attribute for TURN 14 draft-thomson-tram-turn-bandwidth-01 16 Abstract 18 An attribute is defined for Session Traversal Utilities for NAT 19 (STUN) that allows for declarations of bandwidth limits on the 20 negotiated flow. The application of this attribute is the 21 negotiation of bandwidth between a Traversal Using Relays around NAT 22 (TURN) client and a TURN server. 24 Status of this Memo 26 This Internet-Draft is submitted 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 5, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. The BANDWIDTH Attribute . . . . . . . . . . . . . . . . . . . . 4 61 4. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. ICE Usage . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Bandwidth Measurement Considerations . . . . . . . . . . . . . 5 66 5.1. Rate Enforcement . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Implementation Status . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 This document defines a BANDWIDTH attribute that can be used to 78 request and allocate bandwidth at a Traversal Using Relays around NAT 79 (TURN) relay [RFC5766]. 81 The operator of a TURN server will likely wish to provide fairness 82 between relayed sessions. A TURN server might also wish to limit the 83 use of service to audio-only sessions, or low bandwidth video and 84 audio sessions. In addition, the server may apply rate-limiting 85 policy depending on the credential used for authentication, or the 86 origin of the client. Without the BANDWIDTH attribute, there is no 87 way for a client to indicate the expected bandwidth utilization, or 88 for the server to indicate the maximum bandwidth utilization allowed 89 before rate limiting could be applied. 91 This attribute is used for indicating a bandwidth limit that is set 92 in policy. The sender is not advised or required to utilize 93 bandwidth up to this limit; limits are usually set well in excess of 94 application needs. Senders also limit their use of bandwidth in 95 reaction to path congestion and "circuit breakers". 97 Note that the BANDWIDTH attribute was originally in the TURN draft up 98 to version draft-ietf-behave-turn-07 where it was removed as "the 99 requirements for this feature were not clear and it was felt the 100 feature could be easily added later." This draft proposes adding 101 this attribute back into TURN. A related error code 507 102 "Insufficient Bandwidth Capacity" was also defined in the TURN 103 Internet-Draft, but is not proposed in this draft. This attribute 104 has also been proposed to be used by ICE to provide communication 105 consent [I-D.thomson-mmusic-rtcweb-bw-consent]. No use cases have 106 been identified where bandwidth information is useful for a STUN 107 server which is responding to STUN binding requests. 109 There have been discussions about what other media-related 110 information could be usefully exchanged between a TURN client and a 111 TURN server. One proposal was for the actual media type (voice, 112 video, data) to be exchanged. Other proposals include more 113 granularity over the bandwidth, including max, min, average, etc. 114 While these could be added, the authors do not feel the use cases for 115 these data have been sufficiently developed yet. Also, this 116 information is known in signaling through the SDP attributes and 117 parameters. In a particular implementation, it could be possible for 118 a signaling-aware entity to share this information with a TURN server 119 in order to apply policy for the media relay. 121 2. Terminology 123 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 124 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 125 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 126 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 127 levels for compliant implementations. 129 The terms client, server, and peer are those used for TURN, as 130 defined in [RFC5766]. 132 3. The BANDWIDTH Attribute 134 The BANDWIDTH attribute (identifier TBD) identifies the rate of 135 packet transmission in kilobits per second that is permitted for a 136 given transport flow. The BANDWIDTH attribute is a comprehension- 137 optional attribute (see Section 15 from [RFC5389]). Figure 1 shows 138 the format of this attribute. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Attribute Type (TBD) | Length (4) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Bandwidth | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: Bandwidth Attribute Format 150 The value of this attribute is an unsigned integer that represents 151 the maximum bandwidth for the flow in kilobits per second (1 kilobit 152 = 1024 bits). This is the original format of the Bandwidth 153 attribute. This format could include a maximum and average 154 bandwidth, as the BANDWIDTH-USAGE attribute proposed in 155 [I-D.martinsen-tram-discuss]. 157 4. Applications 159 This section discusses the application of the BANDWIDTH attribute for 160 STUN, TURN, and ICE. 162 4.1. STUN Usage 164 Since the bandwidth of a communications session has no bearing on a 165 STUN server that simply responds to binding requests, this attribute 166 MUST NOT be used for client-server STUN requests or responses. 168 4.2. TURN Usage 170 This attribute can be useful for communication between a TURN client 171 and a TURN server. 173 The BANDWIDTH attribute indicates a limit to available bandwidth for 174 TURN [RFC5766] allocation. The bandwidth limit is symmetric; the 175 value covers the bandwidth of data sent from a peer toward the TURN 176 server and the bandwidth of data sent from client to the TURN server. 178 A BANDWIDTH attribute MAY be present in an Allocate request. This 179 attribute indicates that the given bandwidth is requested. A 180 BANDWIDTH attribute MAY be present in an Allocate response. This 181 attribute in a response indicates the limit that will be applied by 182 the TURN server. The value a TURN server provides could be 183 influenced by the value that a TURN client requests at the discretion 184 of server policy. A client could use this bandwidth limitation of 185 the TURN server in choosing media types or in choosing codecs for a 186 media session. 188 4.3. ICE Usage 190 While [I-D.thomson-mmusic-rtcweb-bw-consent] proposed the use of the 191 BANDWIDTH attribute to provide bandwidth consent for ICE, this draft 192 does not do so. This attribute MUST NOT be used with ICE. 194 5. Bandwidth Measurement Considerations 196 Allocation messages (Binding and Allocate) sent to and from the TURN 197 server are exempt from any bandwidth measurement accounting. 199 In calculating bandwidth, the entire IP packet - including the header 200 - is measured. This is identical to the measurement performed by the 201 Real-time Transport Protocol (RTP) [RFC3550]. At a TURN server, 202 bandwidth measurement is performed on the packets arriving at or 203 leaving from the TURN server, prior to the encapsulation that occurs 204 between TURN server and TURN client. 206 Determining the rate requires that the bits be allocated to specific 207 intervals of time. How bits are allocated MAY vary between 208 implementations. 210 Measurement of bandwidth is imperfect and inconsistent. Packet 211 jitter can result in fluctuations in received packet rate so that a 212 receiver might see an instantaneous bandwidth that is different to 213 what the sender might have transmitted. Jitter can cause the 214 observed bandwidth of incoming packets to temporarily increase above 215 the permitted rate. At a minimum, implementations SHOULD allow for 216 short periods of excessive bandwidth to allow for these temporary 217 increases. 219 5.1. Rate Enforcement 221 Enforcement of limits by the TURN server SHOULD provide an allowance 222 for application usages that temporarily exceed the limit. For 223 example, assessing observed bandwidth usage as an average over 10 224 seconds ensures that real-time video does not clip unnecessarily; 225 shorter durations could result in the enforcement affecting valuable 226 intra-frames. 228 6. Security Considerations 230 For STUN requests or responses that are not sent using TLS or DTLS 231 transport, the bandwidth information contained in the BANDWIDTH 232 attribute will be available to an eavesdropper who could use it to 233 learn about the nature of a session to be established. For example, 234 they might be able to deduce from the bandwidth requested that the 235 session is likely to be audio only, or audio and video. However, an 236 on-path attacker can likely learn this same information from either 237 the signaling channel or by inspecting the RTP packet headers, which 238 are in the clear for SRTP, or simply by measuring the media bandwidth 239 used. 241 If a STUN request or response is transported using TCP or UDP, the 242 BANDWIDTH attribute will have integrity protection from the MESSAGE- 243 INTEGRITY attribute if the request is authenticated using the STUN 244 short-term or long-term authentication method. Unauthenticated TCP 245 or UDP requests will not have integrity protection and could be 246 modified by a MitM attacker. The use of DTLS transport 247 [I-D.ietf-tram-stun-dtls] provides integrity protection for the 248 BANDWIDTH attribute regardless of the STUN authentication method 249 used. 251 7. IANA Considerations 253 The STUN BANDWIDTH attribute uses the TBD value in the comprehension- 254 optional range. This attribute is registered in the "STUN Attribute" 255 Registry following the procedures of Section 18.2 of [RFC5389]. 257 8. Implementation Status 259 Note to RFC Editor: Please remove this entire section prior to 260 publication, including the reference to RFC 6982. 262 This section records the status of known implementations of the 263 protocol defined by this specification at the time of posting of this 264 Internet-Draft, and is based on a proposal described in [RFC6982]. 265 The description of implementations in this section is intended to 266 assist the IETF in its decision processes in progressing drafts to 267 RFCs. Please note that the listing of any individual implementation 268 here does not imply endorsement by the IETF. Furthermore, no effort 269 has been spent to verify the information presented here that was 270 supplied by IETF contributors. This is not intended as, and must not 271 be construed to be, a catalog of available implementations or their 272 features. Readers are advised to note that other implementations may 273 exist. 275 According to [RFC6982], "this will allow reviewers and working groups 276 to assign due consideration to documents that have the benefit of 277 running code, which may serve as evidence of valuable experimentation 278 and feedback that have made the implemented protocols more mature. 279 It is up to the individual working groups to use this information as 280 they see fit". 282 A multiple realms capable advanced open source TURN server (named 283 'Coturn') has been created by Oleg Moskalenko and is freely licensed 284 under the New BSD license. This reference implementation and proof- 285 of-concept provides a clone (a spin-off) of the rfc5766-turn-server 286 project adding STUN BANDWIDTH attribute support, among other TRAM 287 Working Group STUN and TURN extensions. 289 'Coturn' is backward-compatible with rfc5766-turn-server project but 290 the code is more complex and it uses a different (also more complex) 291 database structure. It is the intent to add all IETF TRAM TURN 292 server related capabilities to this project as they mature. 'Coturn' 293 is publicly available and can be found at: 294 https://code.google.com/p/coturn/ 296 9. References 298 9.1. Normative References 300 [I-D.ietf-tram-stun-dtls] 301 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 302 Layer Security (DTLS) as Transport for Session Traversal 303 Utilities for NAT (STUN)", draft-ietf-tram-stun-dtls-05 304 (work in progress), June 2014. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 310 (ICE): A Protocol for Network Address Translator (NAT) 311 Traversal for Offer/Answer Protocols", RFC 5245, 312 April 2010. 314 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 315 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 316 October 2008. 318 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 319 Relays around NAT (TURN): Relay Extensions to Session 320 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 322 9.2. Informative References 324 [I-D.martinsen-tram-discuss] 325 Martinsen, P. and H. Wildfeuer, "Differentiated prIorities 326 and Status Code-points Using Stun Signalling (DISCUSS)", 327 draft-martinsen-tram-discuss-00 (work in progress), 328 February 2014. 330 [I-D.thomson-mmusic-rtcweb-bw-consent] 331 Thomson, M. and B. Aboba, "Bandwidth Constraints for 332 Session Traversal Utilities for NAT (STUN)", 333 draft-thomson-mmusic-rtcweb-bw-consent-00 (work in 334 progress), October 2012. 336 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 337 Jacobson, "RTP: A Transport Protocol for Real-Time 338 Applications", STD 64, RFC 3550, July 2003. 340 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 341 Code: The Implementation Status Section", RFC 6982, 342 July 2013. 344 Authors' Addresses 346 Martin Thomson 347 Mozilla 348 331 E Evelyn Street 349 Mountain View, CA 94041 350 USA 352 Phone: +1 650-353-1925 353 Email: martin.thomson@gmail.com 355 Bernard Aboba 356 Microsoft 357 One Microsoft Way 358 Redmond, WA 98052 359 USA 361 Email: bernard_aboba@outlook.com 363 Alan Johnston 364 Avaya 365 St. Louis, MO 366 USA 368 Email: alan.b.johnston@gmail.com 370 Oleg Moskalenko 371 public project rfc5766-turn-server 372 Walnut Creek, CA 373 USA 375 Email: mom040267@gmail.com 376 URI: https://code.google.com/p/rfc5766-turn-server/