idnits 2.17.1 draft-ietf-sip-fork-loop-fix-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 516. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 5, 2006) is 6435 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-04 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Expires: March 9, 2007 Pingtel Corp. 6 A. Hawrylyshen 7 Ditech Networks Inc. 8 September 5, 2006 10 Addressing an Amplification Vulnerability in Session Initiation Protocol 11 (SIP) Forking Proxies 12 draft-ietf-sip-fork-loop-fix-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 9, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document normatively updates RFC 3261, the Session Initiation 46 Protocol (SIP), to address a security vulnerability identified in SIP 47 proxy behavior. This vulnerability enables an attack against SIP 48 networks where a small number of legitimate, even authorized, SIP 49 requests can stimulate massive amounts of proxy-to-proxy traffic. 51 This document strengthens loop-detection requirements on SIP proxies 52 when they fork requests (that is, forward a request to more than one 53 destination). It also corrects and clarifies the description of the 54 loop-detection algorithm such proxies are required to implement. 56 Table of Contents 58 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3 61 4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . 5 62 4.1. Strengthening the requirement to perform loop-detection . 5 63 4.2. Correcting and clarifying the RFC 3261 loop-detection 64 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 6 66 4.2.2. Update to section 16.3 . . . . . . . . . . . . . . . . 7 67 4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 7 68 5. Impact on overall network performance . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 Intellectual Property and Copyright Statements . . . . . . . . . . 13 81 1. Conventions and Definitions 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119 [RFC2119]. 87 2. Introduction 89 Interoperability testing uncovered a vulnerability in the behavior of 90 forking SIP proxies as defined in [RFC3261]. This vulnerability can 91 be leveraged to cause a small number of valid SIP requests to 92 generate an extremely large number of proxy-to-proxy messages. A 93 version of this attack demonstrates fewer than ten messages 94 stimulating potentially 2^70 messages. 96 This document specifies normative changes to the SIP protocol to 97 address this vulnerability. According to this update, when a SIP 98 proxy forks a request to more than one destination, it is required to 99 ensure it is not participating in a request loop. 101 3. Vulnerability: Leveraging Forking to Flood a Network 103 This section describes setting up an attack with a simplifying 104 assumption, that two accounts on each of two different RFC 3261 105 compliant proxy/registrar servers that do not perform loop-detection 106 are available to an attacker. This assumption is not necessary for 107 the attack, but makes representing the scenario simpler. The same 108 attack can be realized with a single account on a single server. 110 Consider two proxy/registrar services, P1 and P2, and four Addresses 111 of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER 112 requests, establish bindings to these AoRs as follows (non-essential 113 details elided): 115 REGISTER sip:P1 SIP/2.0 116 To: 117 Contact: , 119 REGISTER sip:P1 SIP/2.0 120 To: 121 Contact: , 123 REGISTER sip:P2 SIP/2.0 124 To: 125 Contact: , 127 REGISTER sip:P2 SIP/2.0 128 To: 129 Contact: , 131 With these bindings in place, introduce an INVITE to any of the four 132 AoRs, say a@P1. This request will fork to two requests handled by 133 P2, which will fork to four requests handled by P1, which will fork 134 to eight messages handled by P2, and so on. This message flow is 135 represented in Figure 2. 137 | 138 a@P1 139 / \ 140 / \ 141 / \ 142 / \ 143 a@P2 b@P2 144 / \ / \ 145 / \ / \ 146 / \ / \ 147 a@P1 b@P1 a@P1 b@P1 148 / \ / \ / \ / \ 149 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 150 /\ /\ /\ /\ /\ /\ /\ /\ 151 . 152 . 153 . 155 Figure 2: Attack request propagation 157 Requests will continue to propagate down this tree until Max-Forwards 158 reaches zero. If the endpoint and two proxies involved follow RFC 159 3261 recommendations, the tree will be 70 rows deep, representing 160 2^70 requests. The actual number of messages may be much larger if 161 the time to process the entire tree worth of requests is longer than 162 Timer C at either proxy. In this case, a storm of 408s, and/or a 163 storm of CANCELs will also be propagating through the tree along with 164 the INVITEs. Remember that there are only two proxies involved in 165 this scenario - each having to hold the state for all the 166 transactions it sees (at least 2^69 simultaneously active 167 transactions near the end of the scenario). 169 The attack can be simplified to one account at one server if the 170 service can be convinced that contacts with varying attributes 171 (parameters, schemes, embedded headers) are sufficiently distinct, 172 and these parameters are not used as part of AOR comparisons when 173 forwarding a new request. Since RFC 3261 mandates that all URI 174 parameters must be removed from a URI before looking it up in a 175 location service and that the URIs from the Contact header are 176 compared using URI equality, the following registration should be 177 sufficient to set this attack up using a single REGISTER request to a 178 single account: 180 REGISTER sip:P1 SIP/2.0 181 To: 182 Contact: , 184 This attack was realized in practice during one of the SIP 185 Interoperability Test (SIPit) sessions. The scenario was extended to 186 include more than two proxies, and the participating proxies all 187 limited Max-Forwards to be no larger than 20. After a handful of 188 messages to construct the attack, the participating proxies began 189 bombarding each other. Extrapolating from the several hours the 190 experiment was allowed to run, the scenario would have completed in 191 just under 10 days. Had the proxies used the RFC 3261 recommended 192 Max-Forwards value of 70, and assuming they performed linearly as the 193 state they held increases, it would have taken 3 trillion years to 194 complete the processing of the single INVITE that initiated the 195 attack. It is interesting to note that a few proxies rebooted during 196 the scenario, and rejoined in the attack when they restarted (as long 197 as they maintained registration state across reboots). This points 198 out that if this attack were launched on the Internet at large, it 199 might require coordination among all the affected elements to stop 200 it. 202 4. Normative changes to RFC 3261 204 4.1. Strengthening the requirement to perform loop-detection 206 The following requirements mitigate the risk of a proxy falling 207 victim to the attack described in this document. 209 When a SIP proxy forks a particular request to more than one 210 destination, it MUST ensure that request is not looping through this 211 proxy. It is RECOMMENDED that proxies meet this requirement by 212 performing the Loop-Detection steps defined in this document. 214 The requirement to use this document's refinement of the loop- 215 detection algorithm in RFC 3261 is set at should-strength to allow 216 for future standards track mechanisms that will allow a proxy to 217 determine it is not looping. For example, a proxy forking to 218 destinations established using the sip-outbound mechanism [I-D.ietf- 219 sip-outbound] would know those branches will not loop. 221 A SIP proxy forwarding a request to only one location MAY perform 222 loop detection but is not required to. When forwarding to only one 223 location, the amplification risk being exploited is not present, and 224 the Max-Forwards mechanism is sufficient to protect the network. A 225 proxy is not required to perform loop detection when forwarding a 226 request to a single location even if it happened to have previously 227 forked that request (and performed loop detection) in its progression 228 through the network. 230 4.2. Correcting and clarifying the RFC 3261 loop-detection algorithm 232 4.2.1. Update to section 16.6 234 This section replaces all of item 8 in section 16.6 of RFC 3261 (item 235 8 begins on page 105 and ends on page 106 of RFC 3261). 237 8. Add a Via header field value 239 The proxy MUST insert a Via header field value into the copy before 240 the existing Via header field values. The construction of this value 241 follows the same guidelines of Section 8.1.1.7. This implies that 242 the proxy will compute its own branch parameter, which will be 243 globally unique for that branch, and will contain the requisite magic 244 cookie. Note that following only the guidelines in Section 8.1.1.7 245 will result in a branch parameter that will be different for 246 different instances of a spiraled or looped request through a proxy. 248 Proxies required to perform loop-detection by RFC XXXX (RFC-Editor: 249 replace XXXX with the RFC number of this document) have an additional 250 constraint on the value they place in the Via header field. Such 251 proxies SHOULD create a branch value separable into two parts in any 252 implementation dependent way. The first part MUST satisfy the 253 constraints of Section 8.1.1.7. The second part is used to perform 254 loop detection and distinguish loops from spirals. 256 This second part MUST vary with any field used by the location 257 service logic in determining where to retarget or forward this 258 request. This is necessary to distinguish looped requests from 259 spirals by allowing the proxy to recognize if none of the values 260 affecting the processing of the request have changed. Hence, The 261 second part MUST depend at least on the received Request-URI and any 262 Route header field values used when processing the received request. 263 Implementers need to take care to include all fields used by the 264 location service logic in that particular implementation. 266 This second part MUST NOT include the request method. CANCEL and 267 non-200 ACK requests MUST have the same branch parameter value as the 268 corresponding request they cancel or acknowledge. This branch 269 parameter value is used in correlating those requests at the server 270 handling them (see Sections 17.2.3 and 9.2). 272 4.2.2. Update to section 16.3 274 This section replaces all of item 4 in section 16.3 of RFC 3261 (item 275 4 appears on page 95 RFC 3261). 277 4. Loop Detection Check 279 Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor: 280 replace XXXX with the RFC number of this document) MUST perform the 281 following loop-detection test before forwarding a request. Each Via 282 header field value in the request whose sent-by value matches a value 283 placed into previous requests by this proxy MUST be inspected for the 284 "second part" defined in Section 4.2.1 of RFC-XXXX. This second part 285 will not be present if the message was not forked when that Via 286 header field value was added. If the second field is present, the 287 proxy MUST perform the second part calculation described in 288 Section 4.2.1 of RFC-XXXX on this request and compare the result to 289 the value from the Via header field. If these values are equal, the 290 request has looped and the proxy MUST reject the request with a 482 291 (Loop Detected) response. If the values differ, the request is 292 spiraling and processing continues to the next step. 294 4.2.3. Note to Implementers 296 A common way to create the second part of the branch parameter value 297 when forking a request is to compute a hash over the concatenation of 298 the Request-URI, any Route header field values used during processing 299 the request and any other values used by the location service logic 300 while processing this request. An MD5 [RFC1321] hash expressed in 301 hexadecimal (base64 is not permissible for a token) is a reasonable 302 choice of a hash function. Any hash function chosen should have the 303 property of very low probability of collision. Hashes resulting in 304 fewer than 128 bits are not recommended. 306 A common point of failure to interoperate at SIPit events has been 307 due to parsers objecting to the contents of other's Via header field 308 values when inspecting the Via stack for loops. Implementers need to 309 take care to avoid making assumptions about the format of another 310 element's Via header field value beyond the basic constraints placed 311 on that format by RFC 3261. In particular, parsing a header field 312 value with unknown parameter names, parameters with no values, 313 parameters values with and without quoted strings must not cause an 314 implementation to fail. 316 5. Impact on overall network performance 318 These requirements and the recommendation to use the loop-detection 319 mechanisms in this document make the favorable trade of exponential 320 message growth for work that is at worst case order n^2 as a message 321 crosses n proxies. Specifically, this work is order m*n where m is 322 the number of proxies in the path that fork the request to more than 323 one location. In practice, m is expected to be small. 325 The loop detection algorithm expressed in this document requires a 326 proxy to inspect each Via element in a received request. In the 327 worst case where a message crosses N proxies, each of which loop 328 detect, proxy k does k inspections, and the overall number of 329 inspections spread across the proxies handling this request is the 330 sum of k from k=1 to k=N which is N(N+1)/2. 332 6. IANA Considerations 334 None. 336 7. Security Considerations 338 This document is entirely about documenting and addressing a 339 vulnerability in SIP proxies as defined by RFC 3261 that can lead to 340 an exponentially growing message exchange attack. 342 Alternative solutions that were discussed included 344 Doing nothing - rely on suing the offender : While systems that have 345 accounts have logs that can be mined to locate abusers, it isn't 346 clear that this provides a credible deterrent or defense against 347 the attack described in this document. Systems that don't 348 recognize the situation and take corrective/preventative action 349 are likely to experience failure of a magnitude that precludes 350 retrieval of the records documenting the setup of the attack. (In 351 one scenario, the registrations can occur in a radically different 352 time period than the invite. The invite itself may have come from 353 an innocent). It's even possible that the scenario may be set up 354 unintentionally. Furthermore, for some existing deployments, the 355 cost and audit ability of an account is simply an email address. 356 Finding someone to punish may be impossible. Finally, there are 357 individuals who will not respond to any threat of legal action, 358 and the effect of even a single successful instance of this kind 359 of attack would be devastating to a service-provider. 361 Putting a smaller cap on Max-Forwards: The effect of the attack is 362 exponential with respect to the initial Max-Forwards value. 363 Turning this value down limits the effect of the attack. This 364 comes at the expense of severely limiting the reach of requests in 365 the network, possibly to the point that existing architectures 366 will begin to fail. 368 Controlling the number of concurrent requests : Bounding the total 369 number branches to which the original request can be forwarded 370 simultaneously limits the impact of the attack at any given point 371 in time. Proposals for limiting mechanisms where considered, but 372 no consensus to adopt them currently exists. 374 Disallowing registration bindings to arbitrary contacts : The way 375 registration binding is currently defined is a key part of the 376 success of the kind of attack documented here. The alternative of 377 limiting registration bindings to allow only binding to the 378 network element performing the registration, perhaps to the 379 extreme of ignoring bits provided in the Contact in favor of 380 transport artifacts observed in the registration request has been 381 discussed (particularly in the context of the mechanisms being 382 defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be 383 considered again in the future, but are currently insufficiently 384 developed to address the present threat. 386 Deprecate forking : This attack does not exist in a system that 387 relies entirely on redirection and initiation of new requests by 388 the original endpoint. Removing such a large architectural 389 component from the system at this time was deemed a too extreme 390 solution. 392 8. Acknowledgments 394 Thanks go to the implementors that subjected their code to this 395 scenario and helped analyze the results at SIPit 17. 397 9. Change Log 399 RFC Editor - Remove this section before publication 401 9.1. -02 to -03 403 Closed Open Issue 1 "Why are we including all of the Route headers 404 values?". The text has been modified to include only those values 405 used in processing the request. 407 Closed Open Issues 2 and 3 "Why did 3261 include Call-ID To-tag, 408 and From-tag and CSeq?" and "Why did 3261 include Proxy-Require 409 and Proxy-Authorization?". The group has not been able to 410 identify why these fields would be included in the hash generally, 411 and successful interoperability tests have not included them. 412 Since they were not included in the text for -02, the text for 413 this version was not affected. 415 Removed the word "cryptographic" from the hash description in the 416 non-normative note to implementers (per list discussion) and added 417 characterization of the properties the hash chosen should have. 419 9.2. -01 to -02 421 Integrated several editorial fixes suggested by Jonathan Rosenberg 423 Noted that the reduction of the attack to a single registration 424 against a single URI as documented in previous versions, is, in 425 fact, going to be effective against implementations conforming to 426 the standards before this repair. 428 Re-incorporated motivation from the original maxforwards-problem 429 draft into the security considerations section based on feedback 430 from Cullen Jennings 432 Introduced replacement text for the loop detection algorithm 433 description in RFC 3261, fixing the bug 648 (the topmost Via value 434 must not be included in the second part) and clarifying the 435 algorithm. Removed several other fields suggested by 3261 and 436 placed open issues around their presence. 438 Added a Notes to Implementors section capturing the "common way" 439 text and pointing to the interoperability issues that have been 440 observed with loop detection at previous SIPits 442 10. References 443 10.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 449 A., Peterson, J., Sparks, R., Handley, M., and E. 450 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 451 June 2002. 453 10.2. Informative References 455 [I-D.ietf-sip-outbound] 456 Jennings, C. and R. Mahy, "Managing Client Initiated 457 Connections in the Session Initiation Protocol (SIP)", 458 draft-ietf-sip-outbound-04 (work in progress), June 2006. 460 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 461 April 1992. 463 Authors' Addresses 465 Robert Sparks (editor) 466 Estacado Systems 467 17210 Campbell Road 468 Suite 250 469 Dallas, Texas 75254-4203 470 USA 472 Email: RjS@nostrum.com 474 Scott Lawrence 475 Pingtel Corp. 476 400 West Cummings Park 477 Suite 2200 478 Woburn, MA 01801 479 USA 481 Phone: +1 781 938 5306 482 Email: slawrence@pingtel.com 484 Alan Hawrylyshen 485 Ditech Networks Inc. 486 1167 Kensington Rd NW 487 Suite 200 488 Calgary, Alberta T2N 1X7 489 Canada 491 Phone: +1 403 806 3366 492 Email: ahawrylyshen@ditechnetworks.com 494 Intellectual Property Statement 496 The IETF takes no position regarding the validity or scope of any 497 Intellectual Property Rights or other rights that might be claimed to 498 pertain to the implementation or use of the technology described in 499 this document or the extent to which any license under such rights 500 might or might not be available; nor does it represent that it has 501 made any independent effort to identify any such rights. Information 502 on the procedures with respect to rights in RFC documents can be 503 found in BCP 78 and BCP 79. 505 Copies of IPR disclosures made to the IETF Secretariat and any 506 assurances of licenses to be made available, or the result of an 507 attempt made to obtain a general license or permission for the use of 508 such proprietary rights by implementers or users of this 509 specification can be obtained from the IETF on-line IPR repository at 510 http://www.ietf.org/ipr. 512 The IETF invites any interested party to bring to its attention any 513 copyrights, patents or patent applications, or other proprietary 514 rights that may cover technology that may be required to implement 515 this standard. Please address the information to the IETF at 516 ietf-ipr@ietf.org. 518 Disclaimer of Validity 520 This document and the information contained herein are provided on an 521 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 522 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 523 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 524 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 525 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 526 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 528 Copyright Statement 530 Copyright (C) The Internet Society (2006). This document is subject 531 to the rights, licenses and restrictions contained in BCP 78, and 532 except as set forth therein, the authors retain all their rights. 534 Acknowledgment 536 Funding for the RFC Editor function is currently provided by the 537 Internet Society.