idnits 2.17.1 draft-thomson-mmusic-rtcweb-bw-consent-00.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 (October 12, 2012) is 4213 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) == Outdated reference: A later version (-04) exists of draft-muthu-behave-consent-freshness-01 ** 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) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtcweb M. Thomson 3 Internet-Draft B. Aboba 4 Intended status: Standards Track Microsoft 5 Expires: April 15, 2013 October 12, 2012 7 Bandwidth Constraints for Session Traversal Utilities for NAT (STUN) 8 draft-thomson-mmusic-rtcweb-bw-consent-00 10 Abstract 12 An attribute is defined for Session Traversal Utilities for NAT 13 (STUN) that allows for declarations of bandwidth limits on the 14 negotiated flow. The application of this attribute to reducing 15 denial of service attacks from internet telephony systems. Other 16 applications include negotiation of bandwidth at packet relays. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 15, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. The BANDWIDTH Attribute . . . . . . . . . . . . . . . . . . . . 4 55 4. Application . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. ICE Bandwidth Consent . . . . . . . . . . . . . . . . . . . 5 57 4.1.1. STUN Usage . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1.2. Bandwidth Limiting . . . . . . . . . . . . . . . . . . 5 59 4.1.3. Bandwidth Consent Revocation . . . . . . . . . . . . . 6 60 4.2. Relay Bandwidth Allocation . . . . . . . . . . . . . . . . 6 61 5. Bandwidth Measurement Considerations . . . . . . . . . . . . . 6 62 5.1. Rate Enforcement . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 A key security property that Interactivity Connectivity Establishment 74 (ICE) [RFC5245] establishes is that the subject of a flow of packets 75 consents to receive packets. This provides a measure of protection 76 against the Voice Hammer attack (see Section 18.5.1 of [RFC5245]) 77 where an attacker with access to signaling induces valid clients to 78 send excessive amounts of data toward a victim. 80 ICE depends on the use of a Session Traversal Utilities for NAT 81 (STUN) Binding request and response to provide an indication of 82 consent. A host that provides a Binding response demonstrates that 83 they have seen the transaction ID and are therefore either on the 84 path between sender and receiver, or have an agent on the path. 86 As a result of the connectivity check, the sender determines that 87 either the receiving host consents to receiving packets, or some on- 88 path attacker has faked consent. In the latter case, the on-path 89 attacker is already in a position to generate packets toward the 90 receiving host, so this does not present an advantage to the attacker 91 and we discount the attack. 93 This basic consent mechanism only establishes that some data is 94 acceptable. It does not establish how much the receiver is prepared 95 to accept. In particular, where media multiplexing is negotiated, 96 consent cannot be provided for individual media; it must apply to all 97 potential streams received on a transport address. Given the wide 98 disparity in potential bandwidth usage by text, audio and video, this 99 enables a volume-based denial of service attack. In this attack a 100 service that is prepared to automatically accept real-time 101 communications can become the target of excessive bandwidth from 102 clients. This only requires that the client visits the attacker's 103 site, there is no user consent required. 105 This attack is only mitigated by measures such as continuing consent 106 [I-D.muthu-behave-consent-freshness]. Refusing to provide continuing 107 consent takes a non-trivial amount of time to effect changes in 108 senders. Thus, continuing consent can only limit the duration of an 109 attack, not prevent it, and only by refusing all media traffic. 111 This document defines a BANDWIDTH attribute for STUN that can be used 112 to prevent this attack. This attribute can also be used to request 113 and allocate bandwidth at a Traversal Using Relays around NAT (TURN) 114 relay. 116 This attribute is used for indicating a bandwidth limit that is set 117 in policy. The sender is not advised or required to utilize 118 bandwidth up to this limit; limits are usually set well in excess of 119 application needs. Senders also limit their use of bandwidth in 120 reaction to path congestion and "circuit breakers". 122 2. Terminology 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 126 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 127 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 128 levels for compliant implementations. 130 The term "sender" and "receiver" refer to peers that are respectively 131 sending or receiving packets on a given transport flow. In a typical 132 peer to peer transport flow, both peers act in both roles. ICE 133 terminology, specifically candidate, flow, and candidate are borrowed 134 from [RFC5245]. 136 3. The BANDWIDTH Attribute 138 The BANDWIDTH attribute (identifier TBD) identifies the rate of 139 packet transmission in kilobits per second that is permitted for a 140 given transport flow. The BANDWIDTH attribute is a comprehension- 141 optional attribute (see Section 15 from [RFC5389]). Figure 1 shows 142 the format of this attribute. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Attribute Type (TBD) | Length (4) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Bandwidth | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: Bandwidth Attribute Format 154 The value of this attribute is an unsigned integer that represents 155 the maximum bandwidth for the flow in kilobits per second (1 kilobit 156 = 1024 bits). 158 4. Application 160 Bandwidth limits are applied to both ICE connectivity checking and 161 TURN relay allocation. 163 4.1. ICE Bandwidth Consent 165 For a negotiated ICE flow, the BANDWIDTH attribute indicates the 166 bandwidth that a receiver consents to receive. 168 In the absence of a BANDWIDTH attribute, no bandwidth limits apply to 169 a flow. 171 4.1.1. STUN Usage 173 A sender that supports this attribute MUST include a BANDWIDTH 174 attribute in the STUN Binding requests it generates for connectivity 175 checks. The primary utility of this inclusion is to indicate support 176 for a parameter. 178 A receiver that supports this attribute includes the permitted 179 bandwidth in the STUN Binding response it generates. A receiver that 180 requires bandwidth consent MUST ignore Binding requests that do not 181 include the BANDWIDTH attribute. A receiver MAY use the value in the 182 Binding request as guidance on what bandwidth to permit. 184 4.1.2. Bandwidth Limiting 186 An ICE-capable sender MUST NOT exceed the allowed bandwidth that has 187 been indicated in connectivity checks for the specific flow. 188 Bandwidth limits for each flow are independent. That is, a bandwidth 189 limit learned from a connectivity check response only applies to 190 packets that are sent from the local candidate to the remote 191 candidate that were used in that connectivity check. An attacker 192 with access to signaling could otherwise insert a candidate that they 193 control. The attacker-controlled candidate could then indicate a 194 larger bandwidth limit that affects other flows. 196 Independent bandwidth limits for flows implies that where there are 197 multiple valid candidate pairs the overall bandwidth limit is 198 increased for each valid candidate pair. For an attacker, this 199 presents an opportunity to multiply the bandwidth that flows toward a 200 receiver by the number of valid candidate pairs. A receiver SHOULD 201 monitor the incoming bandwidth for a component and limit the 202 aggregate bandwidth to the expected maximum. This depends on 203 application-specific knowledge of how flows are expected to be used, 204 such as knowledge of how the ICE component relates to Session 205 Description Protocol (SDP) [RFC4566] "m=" lines. If an aggregate 206 limit is exceeded, the receiver SHOULD revoke consent (Section 4.1.3) 207 on one or more flows. 209 In ICE, a peer MAY choose to include a BANDWIDTH value of zero prior 210 to nominating a candidate pair. This implies that only STUN Binding 211 requests are permitted on the flow. The advantage of this is that 212 the bandwidth allowance is not increased by the number of valid 213 candidate pairs. This increases the latency of flow setup because 214 the controlled peer needs to perform a post-nomination connectivity 215 check to check if available bandwidth has increased to a usable 216 value. 218 4.1.3. Bandwidth Consent Revocation 220 During ongoing consent checks [I-D.muthu-behave-consent-freshness], 221 the BANDWIDTH attribute allows for a faster revocation of consent by 222 a receiver. Without the BANDWIDTH attribute, the receiver stops 223 responding to Binding requests. The sender only stops sending when 224 enough of these responses are lost. By responding with a BANDWIDTH 225 value of zero, a sender ceases packet transmission on the flow in a 226 much shorter time. 228 A sender MUST cease transmission of all packets toward a receiver 229 that indicates a bandwidth of zero. This is important even where 230 rates are averaged over time, where changes in the bandwidth limit 231 might otherwise take some time. 233 4.2. Relay Bandwidth Allocation 235 The BANDWIDTH attribute indicates a limit to available inbound 236 bandwidth for TURN [RFC5766] allocation. Inbound bandwidth is the 237 bandwidth of data sent from a peer toward the TURN server. 239 A BANDWIDTH attribute - when present in an Allocate request - 240 indicates that the given bandwidth is requested. A BANDWIDTH 241 attribute in an Allocate response indicates the limit that will be 242 applied by the TURN server. The value a TURN server provides could 243 be influenced by the value that a TURN client requests at the 244 discretion of server policy. 246 A TURN client can use the indicated bandwidth to limit the value that 247 it sends in ICE connectivity check responses. 249 Bandwidth that the TURN client sends toward the TURN server is not 250 governed by this attribute. A TURN server is able to terminate an 251 allocation if a TURN client generates excessive outbound bandwidth. 253 5. Bandwidth Measurement Considerations 255 Connectivity check and allocation messages (Binding and Allocate) are 256 exempt from any bandwidth measurement accounting. This allows 257 consent to be verified without being subject to delays due to 258 bandwidth throttling. Senders are expected to limit the rate of 259 outgoing connectivity checks using independent mechanisms. 261 In calculating bandwidth, the entire IP packet - including the header 262 - is measured. This is identical to the measurement performed by the 263 Real-Time Transport Protocol (RTP) [RFC3550]. At a TURN server, 264 bandwidth measurement is performed on the packets arriving at the 265 TURN server, prior to the encapsulation that occurs between TURN 266 server and TURN client. 268 Determining the rate requires that the bits be allocated to specific 269 intervals of time. How bits are allocated MAY vary between 270 implementations. 272 Measurement of bandwidth is imperfect and inconsistent. Packet 273 jitter can result in fluctuations in received packet rate so that a 274 receiver might see an instantaneous bandwidth that is different to 275 what the sender might have transmitted. Jitter can cause the 276 observed bandwidth of incoming packets to temporarily increase above 277 the permitted rate. At a minimum, implementations SHOULD allow for 278 short periods of excessive bandwidth to allow for these temporary 279 increases. 281 5.1. Rate Enforcement 283 [[Editor's Note: There are two approaches to this: Either make the 284 limit a hard limit (with a small jitter allowance), which would 285 necessitate fairly high bandwidth limits for normal usage lest there 286 be squeezing or dropping of video i-frames, which can significantly 287 affect a real-time experience. The other approach, taken here, 288 permits a more usage-aware limiting, taking the limit as more of a 289 "guideline", which allows latitude for temporary excess, enabling 290 more realistic limits (and probably some queueing somewhere), with 291 guarantees on compliance with the limit over longer periods.]] 293 Enforcement of bandwidth limits is a sender responsibility, though a 294 receiver or other middlebox MAY perform enforcement. Senders are 295 able to make temporary allowances for the data that is being 296 transmitted, by averaging bandwidth usage to account. This allows 297 for different bandwidth usage profiles. For example, real-time audio 298 typically uses a nearly constant rate, whereas bandwidth consumption 299 increases significantly for the transmission of intra-frames in real- 300 time video. In contrast, real-time application sharing has highly 301 unpredictable bandwidth consumption. 303 Enforcement of limits by nodes other than the sender SHOULD provide 304 an allowance for application usages that temporarily exceed the 305 limit. For example, assessing observed bandwidth usage as an average 306 over 10 seconds ensures that real-time video does not clip 307 unnecessarily; shorter durations could result in any enforcement 308 affecting valuable intra-frames. 310 6. Security Considerations 312 ICE negotiation potentially results in multiple candidate pairs for a 313 component becoming valid. If a non-zero bandwidth value is used 314 during the checking phase, the sender might be convinced that there 315 are multiple valid flows. Mitigation measures and considerations for 316 their use are described in Section 4.1. 318 7. IANA Considerations 320 IANA has allocated a code of (TBD) to the STUN BANDWIDTH attribute. 321 This attribute is registered in the "STUN Attribute" Registry 322 following the procedures of Section 18.2 of [RFC5389]. BANDWIDTH is 323 a comprehension-optional STUN attribute. 325 8. Acknowledgments 327 Humayun Khan, Tim Moore provided input and implementation experience. 329 9. References 331 9.1. Normative References 333 [I-D.muthu-behave-consent-freshness] 334 Perumal, M., Wing, D., and H. Kaplan, "STUN Usage for 335 Consent Freshness and Session Liveness", 336 draft-muthu-behave-consent-freshness-01 (work in 337 progress), July 2012. 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 343 (ICE): A Protocol for Network Address Translator (NAT) 344 Traversal for Offer/Answer Protocols", RFC 5245, 345 April 2010. 347 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 348 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 349 October 2008. 351 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 352 Relays around NAT (TURN): Relay Extensions to Session 353 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 355 9.2. Informative References 357 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 358 Jacobson, "RTP: A Transport Protocol for Real-Time 359 Applications", STD 64, RFC 3550, July 2003. 361 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 362 Description Protocol", RFC 4566, July 2006. 364 Authors' Addresses 366 Martin Thomson 367 Microsoft 368 3210 Porter Drive 369 Palo Alto, CA 94304 370 USA 372 Phone: +1 650-353-1925 373 Email: martin.thomson@outlook.com 375 Bernard Aboba 376 Microsoft 377 One Microsoft Way 378 Redmond, WA 98052 379 USA 381 Email: bernard_aboba@outlook.com