Network Working Group R. Sparks Internet-Draft Estacado Systems Expires: August 30, 2006 S. Lawrence Pingtel Corp. A. Hawrylyshen Ditech Communications Corp. B. Campen, Ed. Estacado Systems February 26, 2006 Limiting the Damage from Amplification Attacks in SIP Proxies draft-sparks-sipping-max-breadth-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document recommends a mechanism for limiting the number of concurrent branches pursued for any given request. This is intended to reduce the damage caused by amplification attacks. Sparks, et al. Expires August 30, 2006 [Page 1] Internet-Draft sipping-max-breadth February 2006 The purpose of this document is to stimulate discussion of the identified problem and proposed solution. Some of the proposed solution language appears normative, but implementors should not treat the current document as such. Comments are solicited, and should be directed to the SIPPING working group list at 'sipping@ietf.org'. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Limiting amplification: the Max-Forwards division approach . . 3 3.1. Restoring the Meaning of Max-Forwards . . . . . . . . . . 3 3.2. Max-Forward Split Weight Selection . . . . . . . . . . . . 5 3.3. Limitations and Issues with Splitting Max-Forwards . . . . 5 3.4. Parallel and Sequential Forking . . . . . . . . . . . . . 6 4. Criticism from the sipping WG . . . . . . . . . . . . . . . . 6 5. An alternative: Max-Breadth . . . . . . . . . . . . . . . . . 6 6. An analysis of Max-Breadth . . . . . . . . . . . . . . . . . . 7 6.1. Limiting breadth without limiting depth. . . . . . . . . . 7 6.2. Parallel and Sequential Forking . . . . . . . . . . . . . 9 6.3. Max-Breadth Split Weight Selection . . . . . . . . . . . . 9 6.4. Limitations and Issues with Max-Breadth . . . . . . . . . 10 7. The usefulness of Max-Breadth . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Sparks, et al. Expires August 30, 2006 [Page 2] Internet-Draft sipping-max-breadth February 2006 1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2. Introduction This document restates the Max-Forwards division approach proposed in [maxforwards-problems], and summarizes the criticism offered by the sipping WG. Using this criticism as a guide, we present a modification that does not have the undesired properties of the Max- Forwards division approach, while retaining the ability to limit the harm caused by exploitation of forking. 3. Limiting amplification: the Max-Forwards division approach In the face of the scenario described in [maxforwards-problems], there are cases where the Max-Forwards header does a very poor job of limiting the number of messages on the transport network that are the direct result of the original request. If we consider that a single request is processed by a sequence of proxies, each of which decrement the value in the Max-Forwards header while forwarding the request to exactly one element, we see that Max-Forwards accurately bounds the number of forwards (and hence the number of messages) that are generated as a result of the original request. In cases where there are proxies forking requests en-route to the target UAS, following the suggestions in [RFC3261] for processing the Max-Forwards header result not in an upper bound on total messages or hops, but on network breadth or span. This means that for a typical Max-Forwards value of 70, the number of messages in the network is not seventy, but 2^70, which, absent pathological failures and network load, results in an enormous number of messages being generated from a single original request. In this environment Max- Forwards is really bounding not the number of forwards, but the depth of a tree containing an arbitrarily large number of forwards. 3.1. Restoring the Meaning of Max-Forwards To ensure that Max-Forwards is directly related to the number of requests that can result from processing a request, the proxy can elect to distribute the value of Max-Forwards between the resulting forked branches. Sparks, et al. Expires August 30, 2006 [Page 3] Internet-Draft sipping-max-breadth February 2006 Example of Splitting Max-Forwards Between Two Branches UA 1 Proxy 1 Proxy 2 F1 | INVITE (Max-Forwards: 70 | | |--------------------------->| | F2 | | INVITE (Max-Forwards: 35) | | |-------------------------->| F3 | | INVITE (Max-Forwards: 35) | | |-------------------------->| F1: Message from UA 1 to Proxy 1 INVITE sip:alice@example.com ... Max-Forwards: 70 ... F2: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.0 ... Max-Forwards: 35 ... F3: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.1 ... Max-Forwards: 35 ... Figure 1: Splitting Max-Forwards In general, the proxy would forward a request with original Max- Forwards of M to the N targets, setting the Max-Forwards in the outbound requests to: M --- - 1 if M > N and N > 1 N When 2N >= M >= N, all outbound requests can be set to 1. Sparks, et al. Expires August 30, 2006 [Page 4] Internet-Draft sipping-max-breadth February 2006 When N is 1, outbound requests can have Max-Forwards set to M-1. In no case should the sum of all N outgoing Max-Forwards (M_n) exceed the value in the original request (M): j --- \ / M_i <= M --- i=1 Bounding the sum in this fashion ensures that the Max-Forwards number has a direct impact on the number of requests and not just the span of the network that eventually processes the request. In the case where M < N, M/N-1 will be zero. This condition arises when the number of branches the proxy intends to create exceeds Max- Forwards. In this case, the implementation may choose to forward to all branches, setting Max-Forwards to 1. 3.2. Max-Forward Split Weight Selection There are a variety of mechanisms that a proxy might employ to select the weighting of each fork branch, and thus the value to put in the Max-Forwards header field on that request. Similarly if a proxy/ registrar has full knowledge about the depth of the path to a particular URI (to its own voice-mail servers for example), it might choose to only apportion that much of the remaining hops to that branch. This is a choice that would benefit from discussion in the community. The naive M/N suggestion above may prove adequate, but it is merely a sample mechanism for illustrating a potential solution. 3.3. Limitations and Issues with Splitting Max-Forwards Splitting the value of Max-Forwards using the suggestions in Section 3.1 results in limiting the depth that a request can reach into a network. The resulting maximum depth is now approximately: log ( M ) (or log base q of M) for q>1 q M for q=1 Where q is the mean number of fork branches created at each proxy. This could have implications in networks that rely on a large number Sparks, et al. Expires August 30, 2006 [Page 5] Internet-Draft sipping-max-breadth February 2006 of proxies or forwarded requests. If the initial default for Max- Forwards is 70, and a typical branching factor is 2, this bounds the depth of any search to 6. A branching factor of 3 results in a maximum depth of 3. Fortunately, most existing architectures which several proxies in a typical flow only branch at one or two of those proxies. The rest forward to a single location. In this kind of network, the simplistic calculation for apportioning Max-Forwards values yields more useful depths: 17 for a branching factor of 2, 7 for a branching factor of three. 3.4. Parallel and Sequential Forking An modification to the proposed solution would allow a service that branches to one set of contacts in parallel, followed by a separate parallel branch if the first fails to garner a 2xx or 6xx class response to apportion the available hops to each of the two parallel branches independently instead of dividing it among them. This weakens the control over the maximum number of messages generated, but improves the depth that can be reached with each of the parallel searches. This resonates with the typical use case of the first search trying to reach someone for live communication, and the second to reach a messaging system. This weakening might be mitigated by reducing Max-Forwards by one as the proxy proceeds to each new parallel search for a particular request. 4. Criticism from the sipping WG Because the Max-Forwards division approach imposes severe restrictions on the "reach" of legitimate SIP requests, the consensus has been that this would not be a good way to limit the effects of an amplification attack. Many of the patterns used in IMS, for instance, rely on repeatedly forwarding SIP requests to application servers and back. It is likely that these mechanisms would cease to function properly if even moderate forking occurred upstream, probably outside of the control of the provider. 5. An alternative: Max-Breadth While division of Max-Forwards was deemed unacceptable, it is still desirable to limit the potential damage caused by uncontrolled forking. To this end, we propose the addition of a new header field, Max- Breadth, and a new 4xx-class response code (numeric value TBD). The value of Max-Breadth will be an integer indicating the highest number of parallel branches that a request should be allowed to concurrently Sparks, et al. Expires August 30, 2006 [Page 6] Internet-Draft sipping-max-breadth February 2006 spawn. This will have the effect of limiting the number of concurrent transactions a request will be able to spawn, without limiting the depth that a request may propagate. Max-Breadth will be distributed between parallel branches, much like the proposal in Section 3.1, and may be reused for subsequent branches. This header field will not be decremented for each hop or otherwise used to limit the "depth" of a request. SIP elements MUST NOT allow the total Max-Breadth among the active branches of a forked request to exceed the Max-Breadth of the original request. The SIP element MAY distribute Max-Breadth in an arbitrary fashion between the active branches. A SIP element MAY choose to use a smaller amount of Max-Breadth than was present in the original request. If a SIP element finds that the incoming request has an insufficient Max-Breadth to properly carry out a necessary parallel fork, that element SHOULD return a 4xx (to be defined) Max- Breadth Exceeded response. If a Max-Breadth header field is not present in a request, the SIP element forwarding that request MUST add one with a value that SHOULD be 70. 6. An analysis of Max-Breadth 6.1. Limiting breadth without limiting depth. To place a limit on the total traffic generated from a single request without placing a constraint on depth, the breadth of the routing tree must be limited. Sparks, et al. Expires August 30, 2006 [Page 7] Internet-Draft sipping-max-breadth February 2006 Example of Splitting Max-Breadth Between Two Branches UA 1 Proxy 1 Proxy 2 F1 | INVITE (Max-Forwards: 70) | | | (Max-Breadth: 70) | | |--------------------------->| | F2 | | INVITE (Max-Forwards: 69) | | | (Max-Breadth: 35) | | |-------------------------->| F3 | | INVITE (Max-Forwards: 69) | | | (Max-Breadth: 35) | | |-------------------------->| F1: Message from UA 1 to Proxy 1 INVITE sip:alice@example.com ... Max-Forwards: 70 Max-Breadth: 70 ... F2: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.0 ... Max-Forwards: 69 Max-Breadth: 35 ... F3: Message from Proxy 1 to Proxy 2 INVITE sip:alice@example.com SIP/2.0 Via: SIP/2.0/TCP 10.1.1.20:59449; branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04.1 ... Max-Forwards: 69 Max-Breadth: 35 ... Note that Max-Forwards behaves exactly as it always has. In general, the proxy would forward a request with original Max- Breadth of M to the N targets, distributing M among the N targets, leaving an average outgoing Max-Breadth of Sparks, et al. Expires August 30, 2006 [Page 8] Internet-Draft sipping-max-breadth February 2006 M --- if M >= N N When N is 1, outbound requests can have Max-Breadth set to M. If N > M, the proxy will not be compelled the stop forwarding the request. Instead, the proxy may opt to fork M of the N branches to begin with (each exiting with a Max-Breadth of 1), and as these branches complete, Max-Breadth may be re-used on new branches until either all N branches have been attempted, or a 2xx or 6xx response is received. At no time should the sum of the current outgoing Max-Breadth (M_i) exceed the value in the original request (M): j --- \ / M_i <= M --- i=1 Bounding the sum in this fashion ensures that the Max-Breadth number has a direct impact on the span of the network, without limiting the depth of the network (limiting depth is still the job of Max- Forwards). 6.2. Parallel and Sequential Forking Inherent in this proposal is the ability of a proxy to "reuse" Max- Breadth by forking sequentially. The limitation on outgoing Max- Breadth is applied to concurrent branches only. For example, if a proxy receives a request with a Max-Breadth of 4, and has 8 targets to forward it to, that proxy may parallel fork to 4 of these targets initially (each with a Max-Breadth of 1, totaling an outgoing Max-Breadth of 4). If one of these transactions completes with a failure response, the outgoing Max-Breadth will drop to 3, allowing the proxy to forward to one of the 4 remaining targets (again, with a Max-Breadth of 1). 6.3. Max-Breadth Split Weight Selection Like the approach described in Section 3.1, there are a variety of mechanisms for controlling the weighting of each fork branch. Fork Sparks, et al. Expires August 30, 2006 [Page 9] Internet-Draft sipping-max-breadth February 2006 branches that are given more Max-Breadth are more likely to complete quickly (because it is less likely that a proxy down the line will be forced to fork sequentially). By the same token, if it is known that a given branch will not fork later on, a Max-Breadth of 1 may be assigned with no ill effect. 6.4. Limitations and Issues with Max-Breadth Unlike the Max-Forwards division approach, splitting the value of Max-Breadth places no limit on the depth that a request can reach. The maximum depth is still equal to the initial value of Max- Forwards. However, the fact that any given proxy may be forced into forking a request sequentially poses a problem. In some cases, forking sequentially may cause unacceptable delays in processing, with no transparency into why the delays are occurring (to the UAC). A way to address the transparency issue is to allow proxies to return a Max Breadth Exceeded response in cases where forking sequentially is unacceptable. 7. The usefulness of Max-Breadth Max-Breadth limits the total number of active branches spawned by a given request at any one time, while placing no constraint on the distance (measured in hops) that the request will propagate (ie, receiving a request with a Max-Breadth of 1 would usually mean that any forking must be sequential, not that the request should be denied). This will limit the effectiveness of any amplification attack that leverages forking, because the amount of state/bandwidth needed to process the traffic at any given point in time is capped. Max-Breadth can also provide a useful metric for monitoring changes in network behavior. For instance, an operator may choose to monitor the average value of Max-Breadth for requests transiting a proxy in each 5 second interval. If operation experience showed that average normally living within a certain band of values, departure from that band could trigger an alarm. A system involved in the amplification attack of [maxforwards-problems] would probably see a precipitous drop in that average. Such monitoring helps offset the chance that an amplification attack attempt might not be noticed since the mechanism proposed here puts an upper-bound on the total amount of concurrent traffic, and that bound will likely be set in practice to a value that is well under load that would threaten continued operation of the network. Sparks, et al. Expires August 30, 2006 [Page 10] Internet-Draft sipping-max-breadth February 2006 8. IANA Considerations TBD - (if this draft progresses, it will register a new header field name, and a new response code) 9. Security Considerations Allowing SIP elements to place implementation depedent restrictions on their outgoing Max-Breadth values can provide protection against malicious UACs that set Max-Breadth to an outrageously high number. If a request arrives at a proxy with a Max-Breadth of more than 70, that proxy is free to treat this request as having a Max-Breadth of 70. Proxy designers should be aware that arbitrarily reducing Max- Breadth may break applications of that proxy (in ways similar to those of arbitrarily reducing Max-Forwards). 10. Acknowledgments This idea was derived from the Max-Forwards division approach in [maxforwards-problems], and is only a minor refinement of that approach. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 11.2. Informative References [maxforwards-problems] Sparks, R., Ed., Lawrence, S., and A. Hawrylyshen, "". Sparks, et al. Expires August 30, 2006 [Page 11] Internet-Draft sipping-max-breadth February 2006 Authors' Addresses Robert Sparks Estacado Systems 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: RjS@nostrum.com Scott Lawrence Pingtel Corp. 400 West Cummings Park Suite 2200 Woburn, MA 01801 USA Phone: +1 781 938 5306 Email: slawrence@pingtel.com Alan Hawrylyshen Ditech Communications Corp. 602 - 11 Ave SW Suite 310 Calgary, Alberta T2R 1J8 Canada Phone: +1 403 561 7313 Email: ahawrylyshen@ditechcom.com Byron Campen (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: bcampen@estacado.net Sparks, et al. Expires August 30, 2006 [Page 12] Internet-Draft sipping-max-breadth February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sparks, et al. Expires August 30, 2006 [Page 13]