idnits 2.17.1 draft-ietf-sip-fork-loop-fix-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. ** 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 (February 24, 2006) is 6635 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 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: August 28, 2006 Pingtel Corp. 6 A. Hawrylyshen 7 Ditech Communications Corp. 8 February 24, 2006 10 Addressing an Amplification Vulnerability in Forking Proxies 11 draft-ietf-sip-fork-loop-fix-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document normatively updates RFC 3261, the Session Initiation 45 Protocol (SIP), to address a security vulnerability identified in SIP 46 proxy behavior. This vulnerability enables an attack against SIP 47 networks where a small number of legitimate, even authorized, SIP 48 requests can stimulate massive amounts of proxy-to-proxy traffic. 50 This document strengthens loop-detection requirements on SIP proxies 51 when they fork requests (that is, forward a request to more than one 52 destination). 54 Table of Contents 56 1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3 59 4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . . 5 60 5. Impact on overall network performance . . . . . . . . . . . . . 6 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Conventions and Definitions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC-2119 [RFC2119]. 76 2. Introduction 78 Interoperability testing uncovered a vulnerability in the behavior of 79 forking SIP proxies as defined in [RFC3261]. This vulnerability can 80 be leveraged to cause a small number of valid SIP requests to 81 generate an extremely large number of proxy-to-proxy messages. A 82 version of this attack demonstrates fewer than ten messages 83 stimulating potentially 2^70 messages. 85 This document specifies normative changes to the SIP protocol to 86 address this vulnerability. According to this update, when a SIP 87 proxy forks a request to more than one destination, it is required to 88 ensure it is not participating in a request loop. 90 3. Vulnerability: Leveraging Forking to Flood a Network 92 This section describes setting up an attack with a simplifying 93 assumption, that two accounts on each of two different RFC 3261 94 compliant proxy/registrar servers that do not perform loop-detection 95 are available to an attacker. This assumption is not necessary for 96 the attack, but makes representing the scenario simpler. The same 97 attack can be realized with a single accont on a single server. 99 Consider two proxy/registrar services, P1 and P2, and four Addresses 100 of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER 101 requests, establish bindings to these AoRs as follows (non-essential 102 details elided): 104 REGISTER sip:P1 SIP/2.0 105 To: 106 Contact: , 108 REGISTER sip:P1 SIP/2.0 109 To: 110 Contact: , 112 REGISTER sip:P2 SIP/2.0 113 To: 114 Contact: , 116 REGISTER sip:P2 SIP/2.0 117 To: 118 Contact: , 120 With these bindings in place, introduce an INVITE to any of the four 121 AoRs, say a@P1. This request will fork to two requests handled by 122 P2, which will fork to four requests handled by P1, which will fork 123 to eight messages handled by P2, and so on: 125 | 126 a@P1 127 / \ 128 / \ 129 / \ 130 / \ 131 a@P2 b@P2 132 / \ / \ 133 / \ / \ 134 / \ / \ 135 a@P1 b@P1 a@P1 b@P1 136 / \ / \ / \ / \ 137 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 138 /\ /\ /\ /\ /\ /\ /\ /\ 139 . 140 . 141 . 143 Figure 2 145 Requests will continue to propagate down this tree until Max-Forwards 146 reaches zero. If the endpoint and two proxies involved follow RFC 147 3261 recommendations, the tree will be 70 rows deep, representing 148 2^70 requests. The actual number of messages may be much larger if 149 the time to process the entire tree worth of requests is longer than 150 Timer C at either proxy. In this case, a storm of 408s, and/or a 151 storm of CANCELs will also be propagating through the tree along with 152 the INVITEs. Remember that there are only two proxies involved in 153 this scenario - each having to hold the state for all the 154 transactions it sees (at least 2^69 simultaneously active 155 transactions near the end of the scenario). 157 The attack can be simplified to one account at one server if the 158 service can be convinced that contacts with varying attributes 159 (parameters, schemes, embedded headers) are sufficiently distinct, 160 and these parameters are not used as part of AOR comparisons when 161 forwarding a new request. Perhaps: 163 REGISTER sip:P1 SIP/2.0 164 To: 165 Contact: , 167 This attack was realized in practice during one of the SIP 168 Interoperability Test (SIPit) sessions. The scenario was extended to 169 include more than two proxies, and the participating proxies all 170 limited Max-Forwards to be no larger than 20. After a handful of 171 messages to construct the attack, the participating proxies began 172 bombarding each other. Extrapolating from the several hours the 173 experiment was allowed to run, the scenerio would have completed in 174 just under 10 days. Had the proxies used the RFC 3261 recommended 175 Max-Forwards value of 70, and assuming they performed linearly as the 176 state they held increases, it would have taken 3 trillion years to 177 complete the processing of the single INVITE that initiated the 178 attack. It is interesting to note that a few proxies rebooted during 179 the scenario, and rejoined in the attack when they restarted (as long 180 as they maintained registration state across reboots). This points 181 out that if this attack were launched in the wild, it might require 182 coordination among all the affected elements to stop it. 184 4. Normative changes to RFC 3261 186 The following requirements mitigate the risk of a proxy falling 187 victim to the attack described in this document. 189 When a SIP proxy forks a particular request to more than one 190 destination, it MUST ensure that request is not looping through this 191 proxy. It is RECOMMENDED that proxies meet this requirement by 192 performing the Loop-Detection steps defined as an optional step in 193 Section 16.3 of RFC 3261. Other loop-detection mechanisms, such as 194 an adaptation of Knuth's algorithm, or the technique described in 195 [I-D.campen-sipping-stack-loop-detect] MAY be used. 197 A SIP proxy forwarding a request to only one location MAY perform 198 loop detection but is not required to. When forwarding to only one 199 location, the amplification risk being exploited is not present, and 200 the Max-Forwards mechanism is sufficient to protect the network. A 201 proxy is not required to peform loop detection when forwarding a 202 request to a single location even if it previously forked that 203 request in its progression through the network. 205 5. Impact on overall network performance 207 These requirements and the recommendation to use the loop-detection 208 mechanisms from RFC 3261 make the favorable trade of exponential 209 message growth for work that is at worst case order n^2 as a message 210 crosses n proxies. Specifically, this work is order m*n where m is 211 the number of proxies in the path that fork the request to more than 212 one location. In practice, m is expected to be small. Optimizations 213 such as that described in [I-D.campen-sipping-stack-loop-detect] 214 could reduce this to work that is linear with m and independent of n. 216 6. IANA Considerations 218 None. 220 7. Security Considerations 222 This document is entirely about addressing a vulnerability in SIP 223 proxies as defined by RFC 3261 that can lead to an exponentially 224 growing message exchange attack. 226 8. Acknowledgements 228 Thanks go to the implementors that subjected thier code to this 229 scenario and helped analyze the results at SIPIT 17. 231 Dave Oran brought the idea of using a Knuth's-algorithm-like 232 alternative to the loop detection mechanisms in RFC 3261 to the SIP 233 working group's attention many times in the development of the SIP 234 protocol. 236 9. References 237 9.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 243 A., Peterson, J., Sparks, R., Handley, M., and E. 244 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 245 June 2002. 247 9.2. Informative References 249 [I-D.campen-sipping-stack-loop-detect] 250 Campen, B., "An Efficient Loop Detection Algorithm for SIP 251 Proxies", draft-campen-sipping-stack-loop-detect-00 (work 252 in progress), February 2006. 254 Authors' Addresses 256 Robert Sparks (editor) 257 Estacado Systems 258 17210 Campbell Road 259 Suite 250 260 Dallas, Texas 75254-4203 261 USA 263 Email: RjS@nostrum.com 265 Scott Lawrence 266 Pingtel Corp. 267 400 West Cummings Park 268 Suite 2200 269 Woburn, MA 01801 270 USA 272 Phone: +1 781 938 5306 273 Email: slawrence@pingtel.com 275 Alan Hawrylyshen 276 Ditech Communications Corp. 277 602 - 11 Ave SW 278 Suite 310 279 Calgary, Alberta T2R 1J8 280 Canada 282 Phone: +1 403 561 7313 283 Email: ahawrylyshen@ditechcom.com 285 Intellectual Property Statement 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at 307 ietf-ipr@ietf.org. 309 Disclaimer of Validity 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 314 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 315 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 316 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Copyright Statement 321 Copyright (C) The Internet Society (2006). This document is subject 322 to the rights, licenses and restrictions contained in BCP 78, and 323 except as set forth therein, the authors retain all their rights. 325 Acknowledgment 327 Funding for the RFC Editor function is currently provided by the 328 Internet Society.