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