idnits 2.17.1 draft-ietf-sip-fork-loop-fix-07.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 994. 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 (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 (July 3, 2008) is 5769 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 (-20) exists of draft-ietf-sip-outbound-15 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks, Ed. 3 Internet-Draft Tekelec 4 Updates: 3261 (if approved) S. Lawrence 5 Intended status: Standards Track Bluesocket Inc. 6 Expires: January 4, 2009 A. Hawrylyshen 7 Ditech Networks Inc. 8 B. Campen 9 Tekelec 10 July 3, 2008 12 Addressing an Amplification Vulnerability in Session Initiation Protocol 13 (SIP) Forking Proxies 14 draft-ietf-sip-fork-loop-fix-07 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 4, 2009. 41 Abstract 43 This document normatively updates RFC 3261, the Session Initiation 44 Protocol (SIP), to address a security vulnerability identified in SIP 45 proxy behavior. This vulnerability enables an attack against SIP 46 networks where a small number of legitimate, even authorized, SIP 47 requests can stimulate massive amounts of proxy-to-proxy traffic. 49 This document strengthens loop-detection requirements on SIP proxies 50 when they fork requests (that is, forward a request to more than one 51 destination). It also corrects and clarifies the description of the 52 loop-detection algorithm such proxies are required to implement. 53 Additionally, this document defines a Max-Breadth mechanism for 54 limiting the number of concurrent branches pursued for any given 55 request. 57 Table of Contents 59 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 5 62 4. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . . . 9 63 4.1. Strengthening the Requirement to Perform Loop-detection . 9 64 4.2. Correcting and Clarifying the RFC 3261 Loop-detection 65 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 9 67 4.2.2. Update to Section 16.3 . . . . . . . . . . . . . . . . 10 68 4.2.3. Impact of Loop-detection on Overall Network 69 Performance . . . . . . . . . . . . . . . . . . . . . 11 70 4.2.4. Note to Implementors . . . . . . . . . . . . . . . . . 11 71 5. Max-Breadth . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 5.3. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . 14 75 5.3.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . 14 76 5.3.2. Terminology . . . . . . . . . . . . . . . . . . . . . 14 77 5.3.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 78 5.3.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 15 79 5.3.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . 16 80 5.4. Implementor Notes . . . . . . . . . . . . . . . . . . . . 16 81 5.4.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . 16 82 5.4.2. Reclamation of Max-Breadth on 2xx Responses . . . . . 16 83 5.4.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . 16 84 5.5. Parallel and Sequential Forking . . . . . . . . . . . . . 16 85 5.6. Max-Breadth Split Weight Selection . . . . . . . . . . . . 17 86 5.7. Max-Breadth's Effect on Forking-based Amplification 87 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 5.8. Max-Breadh Header Field ABNF Definition . . . . . . . . . 17 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 90 6.1. Max-Forwards Header Field . . . . . . . . . . . . . . . . 17 91 6.2. 440 Max-Breadth Exceeded response . . . . . . . . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 94 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 20 96 9.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 20 97 9.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 20 98 9.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 20 99 9.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 21 100 9.6. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 21 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 105 Intellectual Property and Copyright Statements . . . . . . . . . . 24 107 1. Conventions and Definitions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 113 2. Introduction 115 Interoperability testing uncovered a vulnerability in the behavior of 116 forking SIP proxies as defined in [RFC3261]. This vulnerability can 117 be leveraged to cause a small number of valid SIP requests to 118 generate an extremely large number of proxy-to-proxy messages. A 119 version of this attack demonstrates fewer than ten messages 120 stimulating potentially 2^71 messages. 122 This document specifies normative changes to the SIP protocol to 123 address this vulnerability. According to this update, when a SIP 124 proxy forks a request to more than one destination, it is required to 125 ensure it is not participating in a request loop. 127 This normative update alone is insufficient to protect against 128 crafted variations of the attack described here involving multiple 129 AORs. To further address the vulnerability, this document defines 130 the Max-Breadth mechanism to limit the total number of concurrent 131 branches caused by a forked SIP request. The mechanism only limits 132 concurrency. It does not limit the total number of branches a 133 request can traverse over its lifetime. 135 3. Vulnerability: Leveraging Forking to Flood a Network 137 This section describes setting up an attack with a simplifying 138 assumption, that two accounts on each of two different RFC 3261 139 compliant proxy/registrar servers that do not perform loop-detection 140 are available to an attacker. This assumption is not necessary for 141 the attack, but makes representing the scenario simpler. The same 142 attack can be realized with a single account on a single server. 144 Consider two proxy/registrar services, P1 and P2, and four Addresses 145 of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER 146 requests, establish bindings to these AoRs as follows (non-essential 147 details elided): 149 REGISTER sip:P1 SIP/2.0 150 To: 151 Contact: , 153 REGISTER sip:P1 SIP/2.0 154 To: 155 Contact: , 157 REGISTER sip:P2 SIP/2.0 158 To: 159 Contact: , 161 REGISTER sip:P2 SIP/2.0 162 To: 163 Contact: , 165 With these bindings in place, introduce an INVITE to any of the four 166 AoRs, say a@P1. This request will fork to two requests handled by 167 P2, which will fork to four requests handled by P1, which will fork 168 to eight messages handled by P2, and so on. This message flow is 169 represented in Figure 1. 171 | 172 a@P1 173 / \ 174 / \ 175 / \ 176 / \ 177 a@P2 b@P2 178 / \ / \ 179 / \ / \ 180 / \ / \ 181 a@P1 b@P1 a@P1 b@P1 182 / \ / \ / \ / \ 183 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 184 /\ /\ /\ /\ /\ /\ /\ /\ 185 . 186 . 187 . 189 Figure 1: Attack request propagation 191 Requests will continue to propagate down this tree until Max-Forwards 192 reaches zero. If the endpoint and two proxies involved follow RFC 193 3261 recommendations, the tree will be 70 rows deep, representing 194 2^71-1 requests. The actual number of messages may be much larger if 195 the time to process the entire tree worth of requests is longer than 196 Timer C at either proxy. In this case, a storm of 408s, and/or a 197 storm of CANCELs will also be propagating through the tree along with 198 the INVITEs. Remember that there are only two proxies involved in 199 this scenario - each having to hold the state for all the 200 transactions it sees (at least 2^70 simultaneously active 201 transactions near the end of the scenario). 203 The attack can be simplified to one account at one server if the 204 service can be convinced that contacts with varying attributes 205 (parameters, schemes, embedded headers) are sufficiently distinct, 206 and these parameters are not used as part of AOR comparisons when 207 forwarding a new request. Since RFC 3261 mandates that all URI 208 parameters must be removed from a URI before looking it up in a 209 location service and that the URIs from the Contact header are 210 compared using URI equality, the following registration should be 211 sufficient to set this attack up using a single REGISTER request to a 212 single account: 214 REGISTER sip:P1 SIP/2.0 215 To: 216 Contact: , 218 This attack was realized in practice during one of the SIP 219 Interoperability Test (SIPit) sessions. The scenario was extended to 220 include more than two proxies, and the participating proxies all 221 limited Max-Forwards to be no larger than 20. After a handful of 222 messages to construct the attack, the participating proxies began 223 bombarding each other. Extrapolating from the several hours the 224 experiment was allowed to run, the scenario would have completed in 225 just under 10 days. Had the proxies used the RFC 3261 recommended 226 Max-Forwards value of 70, and assuming they performed linearly as the 227 state they held increases, it would have taken 3 trillion years to 228 complete the processing of the single INVITE that initiated the 229 attack. It is interesting to note that a few proxies rebooted during 230 the scenario, and rejoined in the attack when they restarted (as long 231 as they maintained registration state across reboots). This points 232 out that if this attack were launched on the Internet at large, it 233 might require coordination among all the affected elements to stop 234 it. 236 Loop-detection, as specified in this document, at any of the proxies 237 in the scenarios described so far would have stopped the attack 238 immediately. (If all the proxies involved implemented this loop- 239 detection, the total number of stimulated messages in the first 240 scenario described is reduced to 14, and in the variation involving 241 one server, the number of stimulated messages is reduced to 10.) 242 However, there is a variant of the attack that uses multiple AORs 243 where loop-detection alone is insufficient protection. In this 244 variation, each participating AOR forks to all the other 245 participating AORs. For small numbers of participating AORs (10 246 example), paths through the resulting tree will not loop until very 247 large numbers of messages have been generated. Acquiring a 248 sufficient number of AORs to launch such an attack on networks 249 currently available is quite feasible. 251 In this scenario, requests will often take many hops to complete a 252 loop, and there are a very large number of different loops that will 253 occur during the attack. In fact, if N is the number of 254 participating AORs, and provided N is less than or equal to Max- 255 Forwards, the amount of traffic generated by the attack is greater 256 than N!, even if all proxies involved are performing loop-detection. 258 Suppose we have a set of N AORs, all of which are set up to fork 259 to the entire set. For clarity, assume AOR 1 is where the attack 260 begins. Every permutation of the remaining N-1 AORs will play 261 out, defining (N-1)! distinct paths, without repeating any AOR. 262 Then, each of these paths will fork N ways one last time, and a 263 loop will be detected on each of these branches. These final 264 branches alone total N! requests ((N-1)! paths, with N forks at 265 the end of each path). 267 Forwarded Requests vs. Number of Participating AORs 269 ___N____Requests_ 270 | 1 | 1 | 271 | 2 | 4 | 272 | 3 | 15 | 273 | 4 | 64 | 274 | 5 | 325 | 275 | 6 | 1956 | 276 | 7 | 13699 | 277 | 8 | 109600 | 278 | 9 | 986409 | 279 | 10 | 9864100 | 281 Forwarded Requests vs. Number of Participating AORs 283 In a network where all proxies are performing loop-detection, an 284 attacker is still afforded rapidly increasing returns on the number 285 of AORs they are able to leverage. The Max-Breadth mechanism defined 286 in this document is designed to limit the effectiveness of this 287 variation of the attack. 289 In all of the scenarios, it is important to notice that at each 290 forking proxy, an additional branch could be added pointing to a 291 single victim (that might not even be a SIP-aware element), resulting 292 in a massive amount of traffic being directed towards the victim from 293 potentially as many sources as there are AORs participating in the 294 attack. 296 4. Updates to RFC 3261 298 4.1. Strengthening the Requirement to Perform Loop-detection 300 The following requirements mitigate the risk of a proxy falling 301 victim to the attack described in this document. 303 When a SIP proxy forks a particular request to more than one 304 location, it MUST ensure that request is not looping through this 305 proxy. It is RECOMMENDED that proxies meet this requirement by 306 performing the Loop-Detection steps defined in this document. 308 The requirement to use this document's refinement of the loop- 309 detection algorithm in RFC 3261 is set at should-strength to allow 310 for future standards track mechanisms that will allow a proxy to 311 determine it is not looping. For example, a proxy forking to 312 destinations established using the sip-outbound mechanism 313 [I-D.ietf-sip-outbound] would know those branches will not loop. 315 A SIP proxy forwarding a request to only one location MAY perform 316 loop detection but is not required to. When forwarding to only one 317 location, the amplification risk being exploited is not present, and 318 the Max-Forwards mechanism will protect the network to the extent it 319 was designed to do (always keep the constant multiplier due to 320 exhausting Max-Forwards while not forking in mind.) A proxy is not 321 required to perform loop detection when forwarding a request to a 322 single location even if it happened to have previously forked that 323 request (and performed loop detection) in its progression through the 324 network. 326 4.2. Correcting and Clarifying the RFC 3261 Loop-detection Algorithm 328 4.2.1. Update to section 16.6 330 This section replaces all of item 8 in section 16.6 of RFC 3261 (item 331 8 begins on page 105 and ends on page 106 of RFC 3261). 333 8. Add a Via header field value 335 The proxy MUST insert a Via header field value into the copy before 336 the existing Via header field values. The construction of this value 337 follows the same guidelines of Section 8.1.1.7. This implies that 338 the proxy will compute its own branch parameter, which will be 339 globally unique for that branch, and will contain the requisite magic 340 cookie. Note that following only the guidelines in Section 8.1.1.7 341 will result in a branch parameter that will be different for 342 different instances of a spiraled or looped request through a proxy. 344 Proxies required to perform loop-detection by RFC XXXX (RFC-Editor: 345 replace XXXX with the RFC number of this document) have an additional 346 constraint on the value they place in the Via header field. Such 347 proxies SHOULD create a branch value separable into two parts in any 348 implementation dependent way. The first part MUST satisfy the 349 constraints of Section 8.1.1.7. The second part is used to perform 350 loop detection and distinguish loops from spirals. 352 This second part MUST vary with any field used by the location 353 service logic in determining where to retarget or forward this 354 request. This is necessary to distinguish looped requests from 355 spirals by allowing the proxy to recognize if none of the values 356 affecting the processing of the request have changed. Hence, The 357 second part MUST depend at least on the received Request-URI and any 358 Route header field values used when processing the received request. 359 Implementers need to take care to include all fields used by the 360 location service logic in that particular implementation. 362 This second part MUST NOT vary with the request method. CANCEL and 363 non-200 ACK requests MUST have the same branch parameter value as the 364 corresponding request they cancel or acknowledge. This branch 365 parameter value is used in correlating those requests at the server 366 handling them (see Sections 17.2.3 and 9.2). 368 4.2.2. Update to Section 16.3 370 This section replaces all of item 4 in section 16.3 of RFC 3261 (item 371 4 appears on page 95 RFC 3261). 373 4. Loop Detection Check 375 Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: 376 replace XXXX with the RFC number of this document) MUST perform the 377 following loop-detection test before forwarding a request. Each Via 378 header field value in the request whose sent-by value matches a value 379 placed into previous requests by this proxy MUST be inspected for the 380 "second part" defined in Section 4.2.1 of RFC-XXXX. This second part 381 will not be present if the message was not forked when that Via 382 header field value was added. If the second field is present, the 383 proxy MUST perform the second part calculation described in 384 Section 4.2.1 of RFC-XXXX on this request and compare the result to 385 the value from the Via header field. If these values are equal, the 386 request has looped and the proxy MUST reject the request with a 482 387 (Loop Detected) response. If the values differ, the request is 388 spiraling and processing continues to the next step. 390 4.2.3. Impact of Loop-detection on Overall Network Performance 392 These requirements and the recommendation to use the loop-detection 393 mechanisms in this document make the favorable trade of exponential 394 message growth for work that is at worst case order n^2 as a message 395 crosses n proxies. Specifically, this work is order m*n where m is 396 the number of proxies in the path that fork the request to more than 397 one location. In practice, m is expected to be small. 399 The loop detection algorithm expressed in this document requires a 400 proxy to inspect each Via element in a received request. In the 401 worst case where a message crosses N proxies, each of which loop 402 detect, proxy k does k inspections, and the overall number of 403 inspections spread across the proxies handling this request is the 404 sum of k from k=1 to k=N which is N(N+1)/2. 406 4.2.4. Note to Implementors 408 A common way to create the second part of the branch parameter value 409 when forking a request is to compute a hash over the concatenation of 410 the Request-URI, any Route header field values used during processing 411 the request and any other values used by the location service logic 412 while processing this request. The hash should be chosen so that 413 there is a low probability that two distinct sets of these parameters 414 will collide. Because the maximum number of inputs which need to be 415 compared is 70 the chance of a collision is low even with a 416 relatively small hash value, such as 32 bits. CRC-32c as specified 417 in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321]. 418 Note that MD5 is being chosen purely for non-cryptographic 419 properties. An attacker who can control the inputs in order to 420 produce a hash collision can attack the connection in a variety of 421 other ways. When forming the second part using a hash, 422 implementations SHOULD include at least one field in the input to the 423 hash that varies between different transactions attempting to reach 424 the same destination to avoid repeated failure should the hash 425 collide. The Call-ID and CSeq fields would be good inputs for this 426 purpose. 428 A common point of failure to interoperate at SIPit events has been 429 due to parsers objecting to the contents of other's Via header field 430 values when inspecting the Via stack for loops. Implementers need to 431 take care to avoid making assumptions about the format of another 432 element's Via header field value beyond the basic constraints placed 433 on that format by RFC 3261. In particular, parsing a header field 434 value with unknown parameter names, parameters with no values, 435 parameters values with and without quoted strings must not cause an 436 implementation to fail. 438 Removing, obfuscating, or in any other way modifying the branch 439 parameter values in Via header fields in a received request before 440 forwarding it removes the ability for the node that placed that 441 branch parameter into the message to perform loop-detection. If two 442 elements in a loop modify branch parameters this way, a loop can 443 never be detected. 445 5. Max-Breadth 447 5.1. Overview 449 The Max-Breadth mechanism defined here limits the total number of 450 concurrent branches caused by a forked SIP request. With this 451 mechanism, all proxyable requests are assigned a positive integral 452 Max-Breadth value, which denotes the maximum number of concurrent 453 branches this request may spawn through parallel forking as it is 454 forwarded from its current point. When a proxy forwards a request, 455 its Max-Breadth value is divided among the outgoing requests. In 456 turn, each of the forwarded requests has a limit on how many 457 concurrent branches they may spawn. As branches complete, their 458 portion of the Max-Breadth value becomes available for subsequent 459 branches, if needed. If there is insufficient Max-Breadth to carry 460 out a desired parallel fork, a proxy can return the 440 (Max-Breadth 461 Exceeded) response defined in this document. 463 This mechanism operates independently from Max-Forwards. Max- 464 Forwards limits the depth of the tree a request may traverse as it is 465 forwarded from its origination point to each destination it may be 466 forked to. As Section 3 shows, the number of branches in a tree of 467 even limited depth can be made large (exponential with depth) by 468 leveraging forking. Each such branch has a pair of SIP transaction 469 state machines associated with it. The Max-Breadth mechanism limits 470 the number of branches that are active (those that have running 471 transaction state machines) at any given point in time. 473 Max-Breadth does not prevent forking. It only limits the number of 474 concurrent parallel forked branches. In particular, a Max-Breadth of 475 1 restricts a request to pure serial forking rather than restricting 476 it from being forked at all. 478 A client receiving a 440 (Max-Breadth Exceeded) response can infer 479 that it its request did not reach all possible destinations. 480 Recovery options are similar to those when receiving a 483 (Too Many 481 Hops) response, and include affecting the routing decisions through 482 whatever mechanisms are appropriate to result in a less broad search, 483 or refining the request itself before submission to make the search 484 space smaller. 486 5.2. Examples 488 UAC Proxy A Proxy B Proxy C 489 | INVITE | | | 490 | Max-Breadth: 60 | INVITE | | 491 | Max-Forwards: 70 | Max-Breadth: 30 | | 492 |-------------------->| Max-Forwards: 69 | | 493 | |------------------->| | 494 | | INVITE | | 495 | | Max-Breadth: 30 | | 496 | | Max-Forwards: 69 | | 497 | |--------------------------------------->| 498 | | | | 500 Parallel forking 502 UAC Proxy A Proxy B Proxy C 503 | INVITE | | | 504 | Max-Breadth: 60 | INVITE | | 505 | Max-Forwards: 70 | Max-Breadth: 60 | | 506 |-------------------->| Max-Forwards: 69 | | 507 | |------------------->| | 508 | | some error response| | 509 | |<-------------------| | 510 | | INVITE | | 511 | | Max-Breadth: 60 | | 512 | | Max-Forwards: 69 | | 513 | |--------------------------------------->| 514 | | | | 516 Sequential forking 518 UAC Proxy A Proxy B Proxy C 519 | INVITE | | | 520 | Max-Breadth: 60 | INVITE | | 521 | Max-Forwards: 70 | Max-Breadth: 60 | INVITE | 522 |-------------------->| Max-Forwards: 69 | Max-Breadth: 60 | 523 | |------------------->| Max-Forwards: 68 | 524 | | |------------------>| 525 | | | | 526 | | | | 527 | | | | 529 No forking 531 MB == Max-Breadth MF == Max-Forwards 533 | MB: 4 534 | MF: 5 535 MB: 2 P MB: 2 536 MF: 4 / \ MF: 4 537 +---------------+ +------------------+ 538 MB: 1 P MB: 1 MB: 1 P MB: 1 539 MF: 3 / \ MF: 3 MF: 3 / \ MF: 3 540 +---+ +-------+ +----+ +-------+ 541 P P P P 542 MB: 1 | MB: 1 | MB: 1 | MB: 1 | 543 MF: 2 | MF: 2 | MF: 2 | MF: 2 | 544 P P P P 545 MB: 1 | MB: 1 | MB: 1 | MB: 1 | 546 MF: 1 | MF: 1 | MF: 1 | MF: 1 | 547 P P P P 548 . 549 . 550 . 552 Max-Breadth and Max-Forwards working together 554 5.3. Formal Mechanism 556 5.3.1. "Max-Breadth" Header 558 The Max-Breadth header takes a single positive integer as its value. 559 The Max-Breadth header takes no parameters. 561 5.3.2. Terminology 563 For each "response context" (see [RFC3261] Sec 16) in a proxy, this 564 mechanism defines two positive integral values; Incoming Max-Breadth 565 and Outgoing Max-Breadth. Incoming Max-Breadth is the value of the 566 Max-Breadth header field value in the request that formed the 567 response context. Outgoing Max-Breadth is the sum of the Max-Breadth 568 of all forwarded requests in the response context, that have not 569 received a final response. 571 5.3.3. Proxy Behavior 573 If a SIP proxy receives a request with no Max-Breadth header field 574 value, it MUST add one, with a value that is RECOMMENDED to be 60. 575 Proxies MUST have a maximum allowable Incoming Max-Breadth value, 576 which is RECOMMENDED to be 60. If this maximum is exceeded in a 577 received request, the proxy MUST overwrite it with a value that 578 SHOULD be no greater than its allowable maximum. 580 All proxied requests MUST contain a single Max-Breadth header field 581 value. 583 SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the 584 Incoming Max-Breadth in a given response context. 586 If a SIP proxy determines a response context has insufficient 587 Incoming Max-Breadth to carry out a desired parallel fork, and the 588 proxy is unwilling/unable to compensate by forking serially or 589 sending a redirect, that proxy MUST return a 440 (Max-Breadth 590 Exceeded) response. 592 Notice that these requirements means a proxy receiving a request with 593 a Max-Breadth of 1 can only fork serially, but it is not required to 594 fork at all - it can return a 440 instead. Thus, this mechanism is 595 not a tool a user-agent can use to force all proxies in the path of a 596 request to fork serially. 598 A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion 599 between active branches. A proxy SHOULD NOT use a smaller amount of 600 Max-Breadth than was present in the original request, unless the 601 Incoming Max-Breadth exceeded the proxy's maximum acceptable value. 602 A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use 603 it to restrict the "depth" of a request's propagation. 605 5.3.3.1. Reusing Max-Breadth 607 Because forwarded requests that have received a final response do not 608 count towards the Outgoing Max-Breadth, whenever a final response 609 arrives, the Max-Breadth that was used on that branch becomes 610 available for reuse. Proxies SHOULD be prepared to reuse this Max- 611 Breadth in cases where there may be elements left in the target-set. 613 5.3.4. UAC Behavior 615 A UAC MAY place a Max-Breadth header field value in outgoing 616 requests. If so, this value is RECOMMENDED to be 60. 618 5.3.5. UAS behavior 620 This mechanism does not affect UAS behavior. A UAS receiving a 621 request with a Max-Breadth header field will ignore that field while 622 processing the request. 624 5.4. Implementor Notes 626 5.4.1. Treatment of CANCEL 628 Since CANCEL requests are never proxied, a Max-Breadth header-field- 629 value is meaningless in a CANCEL request. Sending a CANCEL in no way 630 effects the Outgoing Max-Breadth in the associated INVITE response 631 context. Receiving a CANCEL in no way effects the Incoming Max- 632 Breadth of the associated INVITE response context. 634 5.4.2. Reclamation of Max-Breadth on 2xx Responses 636 Whether 2xx responses free up Max-Breadth is mostly a moot issue, 637 since proxies are forbidden to start new branches in this case. But, 638 there is one caveat. For INVITE, we may receive multiple 2xx for a 639 single branch. Also, 2543 implementations may send back a 6xx 640 followed by a 2xx on the same branch. Implementations that subtract 641 from the Outgoing Max-Breadth when they receive an INVITE/2xx must be 642 careful to avoid bugs caused by subtracting multiple times for a 643 single branch. 645 5.4.3. Max-Breadth and Automaton UAs 647 Designers of automaton UAs (including B2BUAs, gateways, exploders, 648 and any other element that programmatically sends requests as a 649 result of incoming SIP traffic) should consider whether Max-Breadth 650 limitations should be placed on outgoing requests. For example, it 651 is reasonable to design B2BUAs to carry the Max-Breadth value from 652 incoming requests over into requests that are sent as a result. 653 Also, it is reasonable to place Max-Breadth constraints on sets of 654 requests sent by exploders, when they may be leveraged in an 655 amplification attack. 657 5.5. Parallel and Sequential Forking 659 Inherent in the definition of this mechanism is the ability of a 660 proxy to reclaim apportioned Max-Breadth while forking sequentially. 661 The limitation on outgoing Max-Breadth is applied to concurrent 662 branches only. 664 For example, if a proxy receives a request with a Max-Breadth of 4, 665 and has 8 targets to forward it to, that proxy may parallel fork to 4 666 of these targets initially (each with a Max-Breadth of 1, totaling an 667 Outgoing Max-Breadth of 4). If one of these transactions completes 668 with a failure response, the outgoing Max-Breadth drops to 3, 669 allowing the proxy to forward to one of the 4 remaining targets 670 (again, with a Max-Breadth of 1). 672 5.6. Max-Breadth Split Weight Selection 674 There are a variety of mechanisms for controlling the weight of each 675 fork branch. Fork branches that are given more Max-Breadth are more 676 likely to complete quickly (because it is less likely that a proxy 677 down the line will be forced to fork sequentially). By the same 678 token, if it is known that a given branch will not fork later on, a 679 Max-Breadth of 1 may be assigned with no ill effect. This would be 680 appropriate, for example, if a proxy knows the branch is using the 681 SIP outbound extension [I-D.ietf-sip-outbound]. 683 5.7. Max-Breadth's Effect on Forking-based Amplification Attacks 685 Max-Breadth limits the total number of active branches spawned by a 686 given request at any one time, while placing no constraint on the 687 distance (measured in hops) that the request can propagate. (ie, 688 receiving a request with a Max-Breadth of 1 means that any forking 689 must be sequential, not that forking is forbidden) 691 This limits the effectiveness of any amplification attack that 692 leverages forking, because the amount of state/bandwidth needed to 693 process the traffic at any given point in time is capped. 695 5.8. Max-Breadh Header Field ABNF Definition 697 This specification extends the grammar for the Session Initation 698 Protocol by adding the following extension-header: 700 Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT 702 6. IANA Considerations 704 This specification registers a new SIP header field and a new SIP 705 response according to the processes defined in [RFC3261]. 707 6.1. Max-Forwards Header Field 709 This information should appear in the header sub-registry under 710 http://www.iana.org/assignments/sip-parameters. 712 RFC XXXX (this specification) 713 Header Field Name: Max-Breadth 715 Compact Form: none 717 6.2. 440 Max-Breadth Exceeded response 719 This information should appear in the response-code sub-registry 720 under http://www.iana.org/assignments/sip-parameters. 722 Response code: 440 724 Default Reason Phrase: Max-Breadth Exceeded 726 7. Security Considerations 728 This document is entirely about documenting and addressing a 729 vulnerability in SIP proxies as defined by RFC 3261 that can lead to 730 an exponentially growing message exchange attack. 732 Alternative solutions that were discussed included 734 Doing nothing - rely on suing the offender: While systems that have 735 accounts have logs that can be mined to locate abusers, it isn't 736 clear that this provides a credible deterrent or defense against 737 the attack described in this document. Systems that don't 738 recognize the situation and take corrective/preventative action 739 are likely to experience failure of a magnitude that precludes 740 retrieval of the records documenting the setup of the attack. (In 741 one scenario, the registrations can occur in a radically different 742 time period than the invite. The invite itself may have come from 743 an innocent). It's even possible that the scenario may be set up 744 unintentionally. Furthermore, for some existing deployments, the 745 cost and audit ability of an account is simply an email address. 746 Finding someone to punish may be impossible. Finally, there are 747 individuals who will not respond to any threat of legal action, 748 and the effect of even a single successful instance of this kind 749 of attack would be devastating to a service-provider. 751 Putting a smaller cap on Max-Forwards: The effect of the attack is 752 exponential with respect to the initial Max-Forwards value. 753 Turning this value down limits the effect of the attack. This 754 comes at the expense of severely limiting the reach of requests in 755 the network, possibly to the point that existing architectures 756 will begin to fail. 758 Disallowing registration bindings to arbitrary contacts: The way 759 registration binding is currently defined is a key part of the 760 success of the kind of attack documented here. The alternative of 761 limiting registration bindings to allow only binding to the 762 network element performing the registration, perhaps to the 763 extreme of ignoring bits provided in the Contact in favor of 764 transport artifacts observed in the registration request has been 765 discussed (particularly in the context of the mechanisms being 766 defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be 767 considered again in the future, but are currently insufficiently 768 developed to address the present threat. 770 Deprecate forking: This attack does not exist in a system that 771 relies entirely on redirection and initiation of new requests by 772 the original endpoint. Removing such a large architectural 773 component from the system at this time was deemed a too extreme 774 solution. 776 The Max-Breadth mechanism defined here does not decrease the 777 aggregate traffic caused by the forking-loop attack. It only serves 778 to spread the traffic caused by the attack over a longer period, by 779 limiting the number of concurrent branches that are being processed 780 at the same time. An attacker could pump multple requests into a 781 network that uses the Max-Breadth mechanism and gradually build 782 traffic to unreasonable levels. Deployments should monitor carefully 783 and react to gradual increases in the number of concurrent 784 outstanding transactions related to a given resource to protect 785 against this possibility. An alternative design of the Max-Breadth 786 mechanism that was considered and rejected was to not allow the 787 breadth from completed branches to be reused Section 5.3.3.1. Under 788 this alternative, an introduced request would cause at most the 789 initial value of Max-Breadth transactions to be generated in the 790 network. While that approach limits any variant of the amplification 791 vulnerability described here to a constant multipler, it would 792 dramatically change the potential reach of requests and there is 793 beleif that it would break existing deployments. 795 8. Acknowledgments 797 Thanks go to the implementors that subjected their code to this 798 scenario and helped analyze the results at SIPit 17. Eric Rescorla 799 provided guidance and text for the hash recommendation note. 801 9. Change Log 803 RFC Editor - Remove this section before publication 805 9.1. -06 to -07 807 Cleaning up some things based on WGLC and review for publication 808 request (like refreshing references) 810 Added a sentence to the overview discussing what a client might do 811 if it got a 440 813 Reinforced that a UAC will ignore a Max-Breadth header 815 Updated the reference to CRC32C - from 3309 to 4960 817 Integrated fixes from Jan Kolomaznik's review 819 9.2. -05 to -06 821 Integrated Max-Breadth based on working group discussion of the 822 secdir review 824 Added a paragraph pointing out that removing or modifying other 825 node's branch parameters defeats their ability to loop detect 827 Moved the total number of messages from O(2^70) to O(2^71) based 828 on an observation by Jan Kolomaznik. To see this, note that the 829 total number of requests is the sum from i=0 to Max-Forwards of 830 2^i which is 2^(Max-Forwards+1) - 1. The point of the text 831 doesn't change - (the point being that the number is _big_). 833 Made the new 4xx concrete (choosing 440) 835 Added a sentence reinforcing that if you forward to only one 836 branch, you still potentially have a constant multiplier of 837 messages in the network as Max-Forwards runs out (based on 838 feedback from Thomas Cross.) 840 9.3. -04 to -05 842 Boilerplate update, editorial nits fixed 844 9.4. -03 to -04 846 Addressed WGLC comments 848 Changed the hash recommendation per list consensus 850 Reintroduced Call-ID and CSeq (list discussion rediscovered one 851 use for them in avoiding repeated hash collisions) 853 9.5. -02 to -03 855 Closed Open Issue 1 "Why are we including all of the Route headers 856 values?". The text has been modified to include only those values 857 used in processing the request. 859 Closed Open Issues 2 and 3 "Why did 3261 include Call-ID To-tag, 860 and From-tag and CSeq?" and "Why did 3261 include Proxy-Require 861 and Proxy-Authorization?". The group has not been able to 862 identify why these fields would be included in the hash generally, 863 and successful interoperability tests have not included them. 864 Since they were not included in the text for -02, the text for 865 this version was not affected. 867 Removed the word "cryptographic" from the hash description in the 868 non-normative note to implementers (per list discussion) and added 869 characterization of the properties the hash chosen should have. 871 9.6. -01 to -02 873 Integrated several editorial fixes suggested by Jonathan Rosenberg 875 Noted that the reduction of the attack to a single registration 876 against a single URI as documented in previous versions, is, in 877 fact, going to be effective against implementations conforming to 878 the standards before this repair. 880 Re-incorporated motivation from the original maxforwards-problem 881 draft into the security considerations section based on feedback 882 from Cullen Jennings 884 Introduced replacement text for the loop detection algorithm 885 description in RFC 3261, fixing the bug 648 (the topmost Via value 886 must not be included in the second part) and clarifying the 887 algorithm. Removed several other fields suggested by 3261 and 888 placed open issues around their presence. 890 Added a Notes to Implementors section capturing the "common way" 891 text and pointing to the interoperability issues that have been 892 observed with loop detection at previous SIPits 894 10. References 896 10.1. Normative References 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, March 1997. 901 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 902 A., Peterson, J., Sparks, R., Handley, M., and E. 903 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 904 June 2002. 906 10.2. Informative References 908 [I-D.ietf-sip-outbound] 909 Jennings, C. and R. Mahy, "Managing Client Initiated 910 Connections in the Session Initiation Protocol (SIP)", 911 draft-ietf-sip-outbound-15 (work in progress), June 2008. 913 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 914 April 1992. 916 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 917 RFC 4960, September 2007. 919 Authors' Addresses 921 Robert Sparks (editor) 922 Tekelec 923 17210 Campbell Road 924 Suite 250 925 Dallas, Texas 75254-4203 926 USA 928 Email: RjS@nostrum.com 930 Scott Lawrence 931 Bluesocket Inc. 932 10 North Ave. 933 Burlington, MA 01803 934 USA 936 Phone: +1 781 229 0533 937 Email: slawrence@bluesocket.com 938 Alan Hawrylyshen 939 Ditech Networks Inc. 940 823 E. Middlefield Rd 941 Mountain View, CA 94043 942 Canada 944 Phone: +1 650 623 1300 945 Email: alan.ietf@polyphase.ca 947 Byron Campen 948 Tekelec 949 17210 Campbell Road 950 Suite 250 951 Dallas, Texas 75254-4203 952 USA 954 Email: bcampen@estacado.net 956 Full Copyright Statement 958 Copyright (C) The IETF Trust (2008). 960 This document is subject to the rights, licenses and restrictions 961 contained in BCP 78, and except as set forth therein, the authors 962 retain all their rights. 964 This document and the information contained herein are provided on an 965 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 966 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 967 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 968 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 969 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 970 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 972 Intellectual Property 974 The IETF takes no position regarding the validity or scope of any 975 Intellectual Property Rights or other rights that might be claimed to 976 pertain to the implementation or use of the technology described in 977 this document or the extent to which any license under such rights 978 might or might not be available; nor does it represent that it has 979 made any independent effort to identify any such rights. Information 980 on the procedures with respect to rights in RFC documents can be 981 found in BCP 78 and BCP 79. 983 Copies of IPR disclosures made to the IETF Secretariat and any 984 assurances of licenses to be made available, or the result of an 985 attempt made to obtain a general license or permission for the use of 986 such proprietary rights by implementers or users of this 987 specification can be obtained from the IETF on-line IPR repository at 988 http://www.ietf.org/ipr. 990 The IETF invites any interested party to bring to its attention any 991 copyrights, patents or patent applications, or other proprietary 992 rights that may cover technology that may be required to implement 993 this standard. Please address the information to the IETF at 994 ietf-ipr@ietf.org.