Network Working Group R. Sparks Internet-Draft Estacado Systems Expires: December 3, 2007 S. Lawrence Pingtel Corp. A. Hawrylyshen Ditech Networks Inc. B. Campen, Ed. Estacado Systems June 2007 Limiting the number of concurrent branches for a Session Initiation Protocol request draft-sparks-sipping-max-breadth-01 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 December 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. This Sparks, et al. Expires December 3, 2007 [Page 1] Internet-Draft sipping-max-breadth June 2007 tool helps protect against certain amplification attacks that leverage the Session Initiation Protocol's request forking mechanism. Table of Contents 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Formal Mechanism . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. "Max-Breadth" Header . . . . . . . . . . . . . . . . . . . 5 4.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 5 4.3.1. Reusing Max-Breadth . . . . . . . . . . . . . . . . . 6 4.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. UAS behavior . . . . . . . . . . . . . . . . . . . . . . . 6 5. Implementor Notes . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Treatment of CANCEL . . . . . . . . . . . . . . . . . . . 6 5.2. Reclamation of Max-Breadth on 2xx Responses . . . . . . . 7 5.3. Max-Breadth and Automaton UAs . . . . . . . . . . . . . . 7 6. Parallel and Sequential Forking . . . . . . . . . . . . . . . 7 7. Max-Breadth Split Weight Selection . . . . . . . . . . . . . . 7 8. Max-Breadth's Effect on Forking-based Amplification Attacks . 8 9. Header Field Definition . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10.1. Max-Forwards Header Field . . . . . . . . . . . . . . . . 8 10.2. 4xx Max-Breadth Exceeded response . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11.1. Loop-Detection and the Wide-Fork Loop Attack . . . . . . . 9 11.2. Inefficacy of Securing AORs . . . . . . . . . . . . . . . 10 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Sparks, et al. Expires December 3, 2007 [Page 2] Internet-Draft sipping-max-breadth June 2007 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 defines the Max-Breadth mechanism to limit the total number of concurrent branches caused by a forked SIP request. The mechanism only limits concurrency. It does not limit the total number of branches a request can traverse over its lifetime. With this mechanism, all proxyable requests are assigned a positive integral Max-Breadth value, which denotes the maximum number of concurrent branches this request may spawn through parallel forking as it is forwarded from its current point. When a proxy forwards a request, its Max-Breadth value is divided among the outgoing requests. In turn, each of the forwarded requests has a limit on how many concurrent branches they may spawn. As branches complete, thier portion Max-Breadth value becomes available for subsequent branches, if needed. If there is insufficient Max-Breadth to carry out a desired parallel fork, a proxy can return a new 4xx Max-Breadth Exceeded response (the actual 4xx value will be selected later in the consensus process). This mechanism operates independently from Max-Forwards. Max- Forwards limits the depth of the tree a request may traverse as it is forwarded from its origination point to each destination it may be forked to. As [I-D.ietf-sip-fork-loop-fix] shows, the number of branches in a tree of even limited depth can be made large (exponential with depth) by leveraging forking. Each such branch has a pair of SIP transaction state machines associated with it. The Max-Breadth mechanism limits the number of branches that are active (those that have running transaction state machines) at any given point in time. Max-Breadth does not prevent forking. It only limits the number of concurrent parallel forked branches. In particular, a Max-Breadth of 1 restricts a request to pure serial forking rather than restricting it from being forked at all. Sparks, et al. Expires December 3, 2007 [Page 3] Internet-Draft sipping-max-breadth June 2007 3. Examples UAC Proxy A Proxy B Proxy C | INVITE | | | | Max-Breadth: 60 | INVITE | | | Max-Forwards: 70 | Max-Breadth: 30 | | |-------------------->| Max-Forwards: 69 | | | |------------------->| | | | INVITE | | | | Max-Breadth: 30 | | | | Max-Forwards: 69 | | | |--------------------------------------->| | | | | Parallel forking UAC Proxy A Proxy B Proxy C | INVITE | | | | Max-Breadth: 60 | INVITE | | | Max-Forwards: 70 | Max-Breadth: 60 | | |-------------------->| Max-Forwards: 69 | | | |------------------->| | | | some error response| | | |<-------------------| | | | INVITE | | | | Max-Breadth: 60 | | | | Max-Forwards: 69 | | | |--------------------------------------->| | | | | Sequential forking UAC Proxy A Proxy B Proxy C | INVITE | | | | Max-Breadth: 60 | INVITE | | | Max-Forwards: 70 | Max-Breadth: 60 | INVITE | |-------------------->| Max-Forwards: 69 | Max-Breadth: 60 | | |------------------->| Max-Forwards: 68 | | | |------------------>| | | | | | | | | | | | | No forking Sparks, et al. Expires December 3, 2007 [Page 4] Internet-Draft sipping-max-breadth June 2007 MB == Max-Breadth MF == Max-Forwards | MB: 4 | MF: 5 MB: 2 P MB: 2 MF: 4 / \ MF: 4 +---------------+ +------------------+ MB: 1 P MB: 1 MB: 1 P MB: 1 MF: 3 / \ MF: 3 MF: 3 / \ MF: 3 +---+ +-------+ +----+ +-------+ P P P P MB: 1 | MB: 1 | MB: 1 | MB: 1 | MF: 2 | MF: 2 | MF: 2 | MF: 2 | P P P P MB: 1 | MB: 1 | MB: 1 | MB: 1 | MF: 1 | MF: 1 | MF: 1 | MF: 1 | P P P P . . . Max-Breadth and Max-Forwards working together 4. Formal Mechanism 4.1. "Max-Breadth" Header The Max-Breadth header takes a single positive integer as its value. The Max-Breadth header takes no parameters. 4.2. Terminology For each "response context" (see [RFC3261] Sec 16) in a proxy, this mechanism defines two positive integral values; Incoming Max-Breadth and Outgoing Max-Breadth. Incoming Max-Breadth is the value of the Max-Breadth header field value in the request that formed the response context. Outgoing Max-Breadth is the sum of the Max-Breadth of all forwarded requests in the response context, that have not received a final response. 4.3. Proxy Behavior If a SIP proxy receives a request with no Max-Breadth header field value, it MUST add one, with a value that is RECOMMENDED to be 60. Proxies MUST have a maximum allowable Incoming Max-Breadth value, Sparks, et al. Expires December 3, 2007 [Page 5] Internet-Draft sipping-max-breadth June 2007 which is RECOMMENDED to be 60. If this maximum is exceeded in a received request, the proxy MUST overwrite with a value that SHOULD be no greater than its allowable maximum (ISSUE 2). All proxied requests MUST contain a single Max-Breadth header field value. SIP proxies MUST NOT allow the Outgoing Max-Breadth to exceed the Incoming Max-Breadth in a given response context. If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 4xx Max-Breadth Exceeded response. A SIP proxy MAY distribute Max-Breadth in an arbitrary fashion between active branches. A proxy SHOULD NOT use a smaller amount of Max-Breadth than was present in the original request, unless the Incoming Max-Breadth exceeded the proxy's maximum acceptable value. A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use it to restrict the "depth" of a request's propagation. 4.3.1. Reusing Max-Breadth Because forwarded requests that have received a final response do not count towards the Outgoing Max-Breadth, whenever a final response arrives, the Max-Breadth that was used on that branch becomes available for reuse. Proxies SHOULD be prepared to reuse this Max- Breadth in cases where there may be elements left in the target-set. 4.4. UAC Behavior A UAC MAY place a Max-Breadth header field value in outgoing requests. If so, this value is RECOMMENDED to be 60 (ISSUE 2). 4.5. UAS behavior This mechanism does not affect UAS behavior. 5. Implementor Notes 5.1. Treatment of CANCEL Since CANCEL requests are never proxied, a Max-Breadth header-field- value is meaningless in a CANCEL request. Sending a CANCEL in no way effects the Outgoing Max-Breadth in the associated INVITE response Sparks, et al. Expires December 3, 2007 [Page 6] Internet-Draft sipping-max-breadth June 2007 context. Receiving a CANCEL in no way effects the Incoming Max- Breadth of the associated INVITE response context. 5.2. Reclamation of Max-Breadth on 2xx Responses Whether 2xx responses free up Max-Breadth is mostly a moot issue, since proxies are forbidden to start new branches in this case. But, there is one caveat. For INVITE, we may receive multiple 2xx for a single branch. Also, 2543 implementations may send back a 6xx followed by a 2xx on the same branch. Implementations that subtract from the Outgoing Max-Breadth when they receive an INVITE/2xx must be careful to avoid bugs caused by subtracting multiple times for a single branch. 5.3. Max-Breadth and Automaton UAs Designers of automaton UAs (including B2BUAs, gateways, exploders, and any other element that programmatically sends requests as a result of incoming SIP traffic) should consider whether Max-Breadth limitations should be placed on outgoing requests. For example, it is reasonable to design B2BUAs to carry the Max-Breadth value from incoming requests over into requests that are sent as a result. Also, it is reasonable to place Max-Breadth constraints on sets of requests sent by exploders, when they may be leveraged in an amplification attack. 6. Parallel and Sequential Forking Inherent in this proposal is the ability of a proxy to reclaim apportioned Max-Breadth while 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 drops to 3, allowing the proxy to forward to one of the 4 remaining targets (again, with a Max-Breadth of 1). 7. Max-Breadth Split Weight Selection There are a variety of mechanisms for controlling the weight of each fork branch. Fork 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 Sparks, et al. Expires December 3, 2007 [Page 7] Internet-Draft sipping-max-breadth June 2007 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. This would be appropriate, for example, if a proxy knows the branch is using the SIP outbound extension [I-D.ietf-sip-outbound]. 8. Max-Breadth's Effect on Forking-based Amplification Attacks 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 can propagate. (ie, receiving a request with a Max-Breadth of 1 means that any forking must be sequential, not that forking is forbidden) This limits 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. 9. Header Field Definition This specification extends the grammar for the Session Initation Protocol by adding the following extension-header: Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT 10. IANA Considerations This specification registers a new SIP header field and a new SIP response according to the processes defined in [RFC3261]. 10.1. Max-Forwards Header Field This information should appear in the header sub-registry under http://www.iana.org/assignments/sip-parameters. RFC XXXX (this specification) Header Field Name: Max-Breadth Compact Form: none 10.2. 4xx Max-Breadth Exceeded response This information should appear in the response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Sparks, et al. Expires December 3, 2007 [Page 8] Internet-Draft sipping-max-breadth June 2007 Response code: 4xx (The actual response code will be chosen later in the process) Default Reason Phrase: Max-Breadth Exceeded 11. Security Considerations 11.1. Loop-Detection and the Wide-Fork Loop Attack In [I-D.ietf-sip-fork-loop-fix], the forking-loop attack presented involves only 2 participating AORs. In this case, loop-detection is sufficient to stop the attack before significant amplification is achieved. However, in cases where the number of participating AORs is large, loop-detection gives insufficient protection against the attack. (It is worth noting here that acquiring several AORs to participate in an attack is quite easy, and networks are vulnerable to this attack regardless of the degree of control they maintain over their AORs; see Section 11.2.) Loop-detection is insufficient protection against the wide-fork loop attack because requests will often take many hops to complete a loop, and there are a very large number of different loops that will occur during the attack. In fact, if N is the number of participating AORs, and provided N is less than or equal to Max-Forwards, the amount of traffic generated by the attack is greater than N!, even if all proxies involved are performing loop-detection. Suppose we have a set of N AORs, all of which are set up to fork to the entire set. For clarity, assume AOR 1 is where the attack begins. Every permutation of the remaining N-1 AORs will play out, defining (N-1)! distinct paths, without repeating any AOR. Then, each of these paths will fork N ways one last time, and a loop will be detected on each of these branches. These final branches alone total N! requests ((N-1)! paths, with N forks at the end of each path). Sparks, et al. Expires December 3, 2007 [Page 9] Internet-Draft sipping-max-breadth June 2007 Forwarded Requests vs. Number of Participating AORs ___N____Requests_ | 1 | 1 | | 2 | 4 | | 3 | 15 | | 4 | 64 | | 5 | 325 | | 6 | 1956 | | 7 | 13699 | | 8 | 109600 | | 9 | 986409 | | 10 | 9864100 | Forwarded Requests vs. Number of Participating AORs In a network where all proxies are performing loop-detection, an attacker is still afforded rapidly increasing returns on the number of AORs they are able to leverage. 11.2. Inefficacy of Securing AORs Additionally, networks that maintain "perfect" control of their AORs are vulnerable, because an attacker may easily compromise a less secure network, and direct traffic from the attack anywhere they choose. This is accomplished by adding additional bindings to the participating AORs. Note that this method may be used to attack SIP networks that do not use AORs, or even non-SIP networks. 12. Open Issues ISSUE 1 As it is presently written, this mechanism does not decrease the aggregate traffic caused by the forking-loop attack. This mechanism only serves to spread the traffic caused by the attack over a longer period, by limiting the number of concurrent branches that are being processed at the same time. This may not be good enough, considering that an attacker may continue to pump requests into the amplifier they have constructed, causing the traffic to gradually build to unreasonable levels. An alternative would be to forbid reuse of Max-Breadth from completed branches, but this could break existing deployments. Should the mechanism allow breadth from completed branches to be reused or not? Sparks, et al. Expires December 3, 2007 [Page 10] Internet-Draft sipping-max-breadth June 2007 ISSUE 2 The document currently recommends a default starting value of 60 for Max-Forwards. Is this the right value? (60=2*2*3*5 - it was chosen to make small divisions of the value easy to do). Is it neccessary to recommend a starting value at all? ISSUE 3 The document will need to pick a 400-class code and replace the occurances of 4xx here with it. 13. References 13.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. 13.2. Informative References [I-D.ietf-sip-fork-loop-fix] Sparks, R., "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", draft-ietf-sip-fork-loop-fix-05 (work in progress), March 2007. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-08 (work in progress), March 2007. Authors' Addresses Robert Sparks Estacado Systems 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: RjS@nostrum.com Sparks, et al. Expires December 3, 2007 [Page 11] Internet-Draft sipping-max-breadth June 2007 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 Networks Inc. 1167 Kensington Cr NW Suite 200 Calgary, Alberta T2N 1X7 Canada Phone: +1 403 561 7313 Email: alan.ietf@polyphase.ca Byron Campen (editor) Estacado Systems 17210 Campbell Road Suite 250 Dallas, Texas 75254-4203 USA Email: bcampen@estacado.net Sparks, et al. Expires December 3, 2007 [Page 12] Internet-Draft sipping-max-breadth June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Sparks, et al. Expires December 3, 2007 [Page 13]