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