idnits 2.17.1 draft-ietf-sip-fork-loop-fix-01.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 (March 31, 2006) is 6593 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) == Unused Reference: 'I-D.ietf-sip-outbound' is defined on line 249, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-03 Summary: 3 errors (**), 0 flaws (~~), 4 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: October 2, 2006 Pingtel Corp. 6 A. Hawrylyshen 7 Ditech Communications Corp. 8 March 31, 2006 10 Addressing an Amplification Vulnerability in Forking Proxies 11 draft-ietf-sip-fork-loop-fix-01 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 October 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 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 account 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 scenario 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 on the Internet at large, it 182 might require coordination among all the affected elements to stop 183 it. 185 4. Normative changes to RFC 3261 187 The following requirements mitigate the risk of a proxy falling 188 victim to the attack described in this document. 190 When a SIP proxy forks a particular request to more than one 191 destination, it MUST ensure that request is not looping through this 192 proxy. It is RECOMMENDED that proxies meet this requirement by 193 performing the Loop-Detection steps defined as an optional step in 194 Section 16.3 of RFC 3261. 196 The requirement to use the loop-detection algorithm in RFC 3261 is 197 set at should-strength since it is expected that other mechanisms 198 that will allow a proxy to determine it is not looping will be 199 standardized in the near future. For example, a proxy forking to 200 destinations established using the sip-outbound mechanism [I-D.ietf- 201 sip-outbound] would know those branches will not loop. 203 A SIP proxy forwarding a request to only one location MAY perform 204 loop detection but is not required to. When forwarding to only one 205 location, the amplification risk being exploited is not present, and 206 the Max-Forwards mechanism is sufficient to protect the network. A 207 proxy is not required to perform loop detection when forwarding a 208 request to a single location even if it previously forked that 209 request in its progression through the network. 211 5. Impact on overall network performance 213 These requirements and the recommendation to use the loop-detection 214 mechanisms from RFC 3261 make the favorable trade of exponential 215 message growth for work that is at worst case order n^2 as a message 216 crosses n proxies. Specifically, this work is order m*n where m is 217 the number of proxies in the path that fork the request to more than 218 one location. In practice, m is expected to be small. 220 6. IANA Considerations 222 None. 224 7. Security Considerations 226 This document is entirely about addressing a vulnerability in SIP 227 proxies as defined by RFC 3261 that can lead to an exponentially 228 growing message exchange attack. 230 8. Acknowledgements 232 Thanks go to the implementors that subjected their code to this 233 scenario and helped analyze the results at SIPit 17. 235 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.ietf-sip-outbound] 250 Jennings, C. and R. Mahy, "Managing Client Initiated 251 Connections in the Session Initiation Protocol (SIP)", 252 draft-ietf-sip-outbound-03 (work in progress), March 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.