diff options
Diffstat (limited to 'doc/rfc/rfc5393.txt')
| -rw-r--r-- | doc/rfc/rfc5393.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc5393.txt b/doc/rfc/rfc5393.txt new file mode 100644 index 0000000..e0b46c5 --- /dev/null +++ b/doc/rfc/rfc5393.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group R. Sparks, Ed. +Request for Comments: 5393 Tekelec +Updates: 3261 S. Lawrence +Category: Standards Track Nortel Networks, Inc. + A. Hawrylyshen + Ditech Networks Inc. + B. Campen + Tekelec + December 2008 + + + Addressing an Amplification Vulnerability + in Session Initiation Protocol (SIP) Forking Proxies + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2008 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document normatively updates RFC 3261, the Session Initiation + Protocol (SIP), to address a security vulnerability identified in SIP + proxy behavior. This vulnerability enables an attack against SIP + networks where a small number of legitimate, even authorized, SIP + requests can stimulate massive amounts of proxy-to-proxy traffic. + + This document strengthens loop-detection requirements on SIP proxies + when they fork requests (that is, forward a request to more than one + destination). It also corrects and clarifies the description of the + loop-detection algorithm such proxies are required to implement. + Additionally, this document defines a Max-Breadth mechanism for + limiting the number of concurrent branches pursued for any given + request. + + + +Sparks, et al. Standards Track [Page 1] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions and Definitions .....................................3 + 3. Vulnerability: Leveraging Forking to Flood a Network ............3 + 4. Updates to RFC 3261 .............................................7 + 4.1. Strengthening the Requirement to Perform Loop Detection ....7 + 4.2. Correcting and Clarifying the RFC 3261 + Loop-Detection Algorithm ...................................7 + 4.2.1. Update to Section 16.6 ..............................7 + 4.2.2. Update to Section 16.3 ..............................8 + 4.2.3. Impact of Loop Detection on Overall Network + Performance .........................................9 + 4.2.4. Note to Implementers ................................9 + 5. Max-Breadth ....................................................10 + 5.1. Overview ..................................................10 + 5.2. Examples ..................................................11 + 5.3. Formal Mechanism ..........................................12 + 5.3.1. Max-Breadth Header Field ...........................12 + 5.3.2. Terminology ........................................13 + 5.3.3. Proxy Behavior .....................................13 + 5.3.3.1. Reusing Max-Breadth .......................14 + 5.3.4. UAC Behavior .......................................14 + 5.3.5. UAS Behavior .......................................14 + 5.4. Implementer Notes .........................................14 + 5.4.1. Treatment of CANCEL ................................14 + 5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14 + 5.4.3. Max-Breadth and Automaton UAs ......................14 + 5.5. Parallel and Sequential Forking ...........................15 + 5.6. Max-Breadth Split Weight Selection ........................15 + 5.7. Max-Breadth's Effect on Forking-Based + Amplification Attacks .....................................15 + 5.8. Max-Breadth Header Field ABNF Definition ..................16 + 6. IANA Considerations ............................................16 + 6.1. Max-Breadth Header Field ..................................16 + 6.2. 440 Max-Breadth Exceeded Response .........................16 + 7. Security Considerations ........................................16 + 7.1. Alternate Solutions That Were Considered and Rejected .....17 + 8. Acknowledgments ................................................19 + 9. References .....................................................19 + 9.1. Normative References ......................................19 + 9.2. Informative References ....................................19 + + + + + + + + + +Sparks, et al. Standards Track [Page 2] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +1. Introduction + + Interoperability testing uncovered a vulnerability in the behavior of + forking SIP proxies as defined in [RFC3261]. This vulnerability can + be leveraged to cause a small number of valid SIP requests to + generate an extremely large number of proxy-to-proxy messages. A + version of this attack demonstrates fewer than ten messages + stimulating potentially 2^71 messages. + + This document specifies normative changes to the SIP protocol to + address this vulnerability. According to this update, when a SIP + proxy forks a request to more than one destination, it is required to + ensure it is not participating in a request loop. + + This normative update alone is insufficient to protect against + crafted variations of the attack described here involving multiple + Addresses of Record (AORs). To further address the vulnerability, + 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. + + The mechanisms in this update will protect against variations of the + attack described here that use a small number of resources, including + most unintentional self-inflicted variations that occur through + accidental misconfiguration. However, an attacker with access to a + sufficient number of distinct resources will still be able to + stimulate a very large number of messages. The number of concurrent + messages will be limited by the Max-Breadth mechanism, so the entire + set will be spread out over a long period of time, giving operators + better opportunity to detect the attack and take corrective measures + outside the protocol. Future protocol work is needed to prevent this + form of the attack. + +2. 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]. + +3. Vulnerability: Leveraging Forking to Flood a Network + + This section describes setting up an attack with a simplifying + assumption: that two accounts on each of two different RFC 3261 + compliant proxy/registrar servers that do not perform loop detection + are available to an attacker. This assumption is not necessary for + the attack but makes representing the scenario simpler. The same + attack can be realized with a single account on a single server. + + + +Sparks, et al. Standards Track [Page 3] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + Consider two proxy/registrar services, P1 and P2, and four Addresses + of Record, a@P1, b@P1, a@P2, and b@P2. Using normal REGISTER + requests, establish bindings to these AORs as follows (non-essential + details elided): + + REGISTER sip:P1 SIP/2.0 + To: <sip:a@P1> + Contact: <sip:a@P2>, <sip:b@P2> + + REGISTER sip:P1 SIP/2.0 + To: <sip:b@P1> + Contact: <sip:a@P2>, <sip:b@P2> + + REGISTER sip:P2 SIP/2.0 + To: <sip:a@P2> + Contact: <sip:a@P1>, <sip:b@P1> + + REGISTER sip:P2 SIP/2.0 + To: <sip:b@P2> + Contact: <sip:a@P1>, <sip:b@P1> + + With these bindings in place, introduce an INVITE request to any of + the four AORs, say a@P1. This request will fork to two requests + handled by P2, which will fork to four requests handled by P1, which + will fork to eight messages handled by P2, and so on. This message + flow is represented in Figure 1. + + | + a@P1 + / \ + / \ + / \ + / \ + a@P2 b@P2 + / \ / \ + / \ / \ + / \ / \ + a@P1 b@P1 a@P1 b@P1 + / \ / \ / \ / \ + a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 + /\ /\ /\ /\ /\ /\ /\ /\ + . + . + . + + Figure 1: Attack Request Propagation + + + + + +Sparks, et al. Standards Track [Page 4] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + Requests will continue to propagate down this tree until Max-Forwards + reaches zero. If the endpoint and two proxies involved follow RFC + 3261 recommendations, the tree will be 70 rows deep, representing + 2^71-1 requests. The actual number of messages may be much larger if + the time to process the entire tree's worth of requests is longer + than Timer C at either proxy. In this case, a storm of 408 responses + and/or a storm of CANCEL requests will also be propagating through + the tree along with the INVITE requests. Remember that there are + only two proxies involved in this scenario - each having to hold the + state for all the transactions it sees (at least 2^70 simultaneously + active transactions near the end of the scenario). + + The attack can be simplified to one account at one server if the + service can be convinced that contacts with varying attributes + (parameters, schemes, embedded headers) are sufficiently distinct, + and these parameters are not used as part of AOR comparisons when + forwarding a new request. Since RFC 3261 mandates that all URI + parameters must be removed from a URI before looking it up in a + location service and that the URIs from the Contact header field are + compared using URI equality, the following registration should be + sufficient to set up this attack using a single REGISTER request to a + single account: + + REGISTER sip:P1 SIP/2.0 + To: <sip:a@P1> + Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud> + + This attack was realized in practice during one of the SIP + Interoperability Test (SIPit) sessions. The scenario was extended to + include more than two proxies, and the participating proxies all + limited Max-Forwards to be no larger than 20. After a handful of + messages to construct the attack, the participating proxies began + bombarding each other. Extrapolating from the several hours the + experiment was allowed to run, the scenario would have completed in + just under 10 days. Had the proxies used the RFC 3261 recommended + Max-Forwards value of 70, and assuming they performed linearly as the + state they held increased, it would have taken 3 trillion years to + complete the processing of the single INVITE request that initiated + the attack. It is interesting to note that a few proxies rebooted + during the scenario and rejoined in the attack when they restarted + (as long as they maintained registration state across reboots). This + points out that if this attack were launched on the Internet at + large, it might require coordination among all the affected elements + to stop it. + + Loop detection, as specified in this document, at any of the proxies + in the scenarios described so far would have stopped the attack + immediately. (If all the proxies involved implemented this loop + + + +Sparks, et al. Standards Track [Page 5] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + detection, the total number of stimulated messages in the first + scenario described would be reduced to 14; in the variation involving + one server, the number of stimulated messages would be reduced to + 10.) However, there is a variant of the attack that uses multiple + AORs where loop detection alone is insufficient protection. In this + variation, each participating AOR forks to all the other + participating AORs. For small numbers of participating AORs (10, for + example), paths through the resulting tree will not loop until very + large numbers of messages have been generated. Acquiring a + sufficient number of AORs to launch such an attack on networks + currently available is quite feasible. + + In this scenario, 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). + + ___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. The Max-Breadth mechanism defined + in this document is designed to limit the effectiveness of this + variation of the attack. + + + +Sparks, et al. Standards Track [Page 6] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + In all of the scenarios, it is important to notice that at each + forking proxy, an additional branch could be added pointing to a + single victim (that might not even be a SIP-aware element), resulting + in a massive amount of traffic being directed towards the victim from + potentially as many sources as there are AORs participating in the + attack. + +4. Updates to RFC 3261 + +4.1. Strengthening the Requirement to Perform Loop Detection + + The following requirements mitigate the risk of a proxy falling + victim to the attack described in this document. + + When a SIP proxy forks a particular request to more than one + location, it MUST ensure that request is not looping through this + proxy. It is RECOMMENDED that proxies meet this requirement by + performing the loop-detection steps defined in this document. + + The requirement to use this document's refinement of the loop- + detection algorithm from RFC 3261 is set at should-strength to allow + for future Standards-Track mechanisms that will allow a proxy to + determine it is not looping. For example, a proxy forking to + destinations established using the sip-outbound mechanism [OUTBOUND] + would know those branches will not loop. + + A SIP proxy forwarding a request to only one location MAY perform + loop detection but is not required to. When forwarding to only one + location, the amplification risk being exploited is not present, and + the Max-Forwards mechanism will protect the network to the extent it + was designed (always keep in mind the constant multiplier due to + exhausting Max-Forwards while not forking). A proxy is not required + to perform loop detection when forwarding a request to a single + location even if it happened to have previously forked that request + (and performed loop detection) in its progression through the + network. + +4.2. Correcting and Clarifying the RFC 3261 Loop-Detection Algorithm + +4.2.1. Update to Section 16.6 + + This section replaces all of item 8 in Section 16.6 of RFC 3261 (item + 8 begins on page 105 and ends on page 106 of RFC 3261). + + + + + + + + +Sparks, et al. Standards Track [Page 7] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + 8. Add a Via Header Field Value + + The proxy MUST insert a Via header field value into the copy before + the existing Via header field values. The construction of this value + follows the same guidelines of Section 8.1.1.7. This implies that + the proxy will compute its own branch parameter, which will be + globally unique for that branch, and will contain the requisite magic + cookie. Note that following only the guidelines in Section 8.1.1.7 + will result in a branch parameter that will be different for + different instances of a spiraled or looped request through a proxy. + + Proxies required to perform loop detection by RFC 5393 have an + additional constraint on the value they place in the Via header + field. Such proxies SHOULD create a branch value separable into two + parts in any implementation-dependent way. + + The remainder of this section's description assumes the existence of + these two parts. If a proxy chooses to employ some other mechanism, + it is the implementer's responsibility to verify that the detection + properties defined by the requirements placed on these two parts are + achieved. + + The first part of the branch value MUST satisfy the constraints of + Section 8.1.1.7. The second part is used to perform loop detection + and distinguish loops from spirals. + + This second part MUST vary with any field used by the location + service logic in determining where to retarget or forward this + request. This is necessary to distinguish looped requests from + spirals by allowing the proxy to recognize if none of the values + affecting the processing of the request have changed. Hence, the + second part MUST depend at least on the received Request-URI and any + Route header field values used when processing the received request. + Implementers need to take care to include all fields used by the + location service logic in that particular implementation. + + This second part MUST NOT vary with the request method. CANCEL and + non-200 ACK requests MUST have the same branch parameter value as the + corresponding request they cancel or acknowledge. This branch + parameter value is used in correlating those requests at the server + handling them (see Sections 17.2.3 and 9.2). + +4.2.2. Update to Section 16.3 + + This section replaces all of item 4 in Section 16.3 of RFC 3261 (item + 4 appears on page 95 of RFC 3261). + + + + + +Sparks, et al. Standards Track [Page 8] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + 4. Loop-Detection Check + + Proxies required to perform loop detection by RFC 5393 MUST perform + the following loop-detection test before forwarding a request. Each + Via header field value in the request whose sent-by value matches a + value placed into previous requests by this proxy MUST be inspected + for the "second part" defined in Section 4.2.1 of RFC 5393. This + second part will not be present if the message was not forked when + that Via header field value was added. If the second field is + present, the proxy MUST perform the second-part calculation described + in Section 4.2.1 of RFC 5393 on this request and compare the result + to the value from the Via header field. If these values are equal, + the request has looped and the proxy MUST reject the request with a + 482 (Loop Detected) response. If the values differ, the request is + spiraling and processing continues to the next step. + +4.2.3. Impact of Loop Detection on Overall Network Performance + + These requirements and the recommendation to use the loop-detection + mechanisms in this document make the favorable trade of exponential + message growth for work that is, at worst, order n^2 as a message + crosses n proxies. Specifically, this work is order m*n where m is + the number of proxies in the path that fork the request to more than + one location. In practice, m is expected to be small. + + The loop-detection algorithm expressed in this document requires a + proxy to inspect each Via element in a received request. In the + worst case, where a message crosses N proxies, each of which loop + detect, proxy k does k inspections, and the overall number of + inspections spread across the proxies handling this request is the + sum of k from k=1 to k=N which is N(N+1)/2. + +4.2.4. Note to Implementers + + A common way to create the second part of the branch parameter value + when forking a request is to compute a hash over the concatenation of + the Request-URI, any Route header field values used during processing + the request, and any other values used by the location service logic + while processing this request. The hash should be chosen so that + there is a low probability that two distinct sets of these parameters + will collide. Because the maximum number of inputs that need to be + compared is 70, the chance of a collision is low even with a + relatively small hash value, such as 32 bits. CRC-32c as specified + in [RFC4960] is a specific acceptable function, as is MD5 [RFC1321]. + Note that MD5 is being chosen purely for non-cryptographic + properties. An attacker who can control the inputs in order to + produce a hash collision can attack the connection in a variety of + other ways. When forming the second part using a hash, + + + +Sparks, et al. Standards Track [Page 9] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + implementations SHOULD include at least one field in the input to the + hash that varies between different transactions attempting to reach + the same destination to avoid repeated failure should the hash + collide. The Call-ID and CSeq fields would be good inputs for this + purpose. + + A common point of failure to interoperate at SIPit events has been + due to parsers objecting to the contents of another element's Via + header field values when inspecting the Via stack for loops. + Implementers need to take care to avoid making assumptions about the + format of another element's Via header field value beyond the basic + constraints placed on that format by RFC 3261. In particular, + parsing a header field value with unknown parameter names, parameters + with no values, or parameter values with or without quoted strings + must not cause an implementation to fail. + + Removing, obfuscating, or in any other way modifying the branch + parameter values in Via header fields in a received request before + forwarding it removes the ability for the node that placed that + branch parameter into the message to perform loop detection. If two + elements in a loop modify branch parameters this way, a loop can + never be detected. + +5. Max-Breadth + +5.1. Overview + + The Max-Breadth mechanism defined here limits the total number of + concurrent branches caused by a forked SIP request. 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 it may spawn. As branches complete, their + portion of the 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 the 440 (Max-Breadth + Exceeded) response defined in this document. + + 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 is forked + to. As Section 3 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 + + + + +Sparks, et al. Standards Track [Page 10] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + 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. + + A client receiving a 440 (Max-Breadth Exceeded) response can infer + that its request did not reach all possible destinations. Recovery + options are similar to those when receiving a 483 (Too Many Hops) + response, and include affecting the routing decisions through + whatever mechanisms are appropriate to result in a less broad search, + or refining the request itself before submission to make the search + space smaller. + +5.2. 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 + + + +Sparks, et al. Standards Track [Page 11] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + 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 + + + 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 + +5.3. Formal Mechanism + +5.3.1. Max-Breadth Header Field + + The Max-Breadth header field takes a single positive integer as its + value. The Max-Breadth header field value takes no parameters. + + + + + + + + +Sparks, et al. Standards Track [Page 12] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +5.3.2. Terminology + + For each "response context" (see Section 16 of [RFC3261]) in a proxy, + this mechanism defines two positive integral values: Incoming Max- + Breadth and Outgoing Max-Breadth. Incoming Max-Breadth is the value + in the Max-Breadth header field in the request that formed the + response context. Outgoing Max-Breadth is the sum of the Max-Breadth + header field values in all forwarded requests in the response context + that have not received a final response. + +5.3.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, + which is RECOMMENDED to be 60. If this maximum is exceeded in a + received request, the proxy MUST overwrite it with a value that + SHOULD be no greater than its allowable maximum. + + 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 440 (Max-Breadth + Exceeded) response. + + Notice that these requirements mean a proxy receiving a request with + a Max-Breadth of 1 can only fork serially, but it is not required to + fork at all -- it can return a 440 instead. Thus, this mechanism is + not a tool a user agent can use to force all proxies in the path of a + request to fork serially. + + 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. + + + + + + + + +Sparks, et al. Standards Track [Page 13] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +5.3.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. + +5.3.4. UAC Behavior + + A User Agent Client (UAC) MAY place a Max-Breadth header field value + in outgoing requests. If so, this value is RECOMMENDED to be 60. + +5.3.5. UAS Behavior + + This mechanism does not affect User Agent Server (UAS) behavior. A + UAS receiving a request with a Max-Breadth header field will ignore + that field while processing the request. + +5.4. Implementer Notes + +5.4.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 + affects the Outgoing Max-Breadth in the associated INVITE response + context. Receiving a CANCEL in no way affects the Incoming Max- + Breadth of the associated INVITE response context. + +5.4.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. A proxy may receive multiple 2xx responses for + a single forwarded INVITE request. Also, [RFC2543] 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 a 2xx response to an INVITE request must be careful to avoid + bugs caused by subtracting multiple times for a single branch. + +5.4.3. Max-Breadth and Automaton UAs + + Designers of automaton user agents (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 into requests that are sent as a result. + + + +Sparks, et al. Standards Track [Page 14] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + 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. + +5.5. Parallel and Sequential Forking + + Inherent in the definition of this mechanism 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). + +5.6. 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 + 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 [OUTBOUND]. + +5.7. 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. (i.e., + 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. + + + + + + + + + + +Sparks, et al. Standards Track [Page 15] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +5.8. Max-Breadth Header Field ABNF Definition + + This specification extends the grammar for the Session Initiation + Protocol by adding an extension-header. The ABNF [RFC5234] + definition is as follows. + + Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT + +6. IANA Considerations + + This specification registers a new SIP header field and a new SIP + response according to the processes defined in [RFC3261]. + +6.1. Max-Breadth Header Field + + This information appears in the Header Fields sub-registry of the SIP + Parameters registry. + + RFC 5393 (this specification) + + Header Field Name: Max-Breadth + + Compact Form: none + +6.2. 440 Max-Breadth Exceeded Response + + This information appears in the Response Codes sub-registry of the + SIP Parameters registry. + + Response code: 440 + + Default Reason Phrase: Max-Breadth Exceeded + +7. Security Considerations + + This document is entirely about documenting and addressing a + vulnerability in SIP proxies as defined by RFC 3261 that can lead to + an exponentially growing message exchange attack. + + The Max-Breadth mechanism defined here does not decrease the + aggregate traffic caused by the forking-loop attack. It 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. An attacker could pump multiple requests into a + network that uses the Max-Breadth mechanism and gradually build + traffic to unreasonable levels. Deployments should monitor carefully + and react to gradual increases in the number of concurrent + outstanding transactions related to a given resource to protect + + + +Sparks, et al. Standards Track [Page 16] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + against this possibility. Operators should anticipate being able to + temporarily disable any resources identified as being used in such an + attack. A rapid increase in outstanding concurrent transactions + system-wide may be an indication of the presence of this kind of + attack across many resources. Deployments in which it is feasible + for an attacker to obtain a very large number of resources are + particularly at risk. If detecting and intervening in each instance + of the attack is insufficient to reduce the load, overload may occur. + + Implementers and operators are encouraged to follow the + recommendations being developed for handling overload conditions (see + [REQS] and [DESIGN]). + + Designers of protocol gateways should consider the implications of + this kind of attack carefully. As an example, if a message transits + from a SIP network into the Public Switched Telephone Network (PSTN) + and subsequently back into a SIP network, and information about the + history of the request on either side of the protocol translation is + lost, it becomes possible to construct loops that neither Max- + Forwards nor loop detection can protect against. This, combined with + forking amplification on the SIP side of the loop, will result in an + attack as described in this document that the mechanisms here will + not abate, not even to the point of limiting the number of concurrent + messages in the attack. These considerations are particularly + important for designers of gateways from SIP to SIP (as found in + B2BUAs, for example). Many existing B2BUA implementations are under + some pressure to hide as much information about the two sides + communicating with them as possible. Implementers of such + implementations may be tempted to remove the data that might be used + by the loop-detection, Max-Forwards, or Max-Breadth mechanisms at + other points in the network, taking on the responsibility for + detecting loops (or forms of this attack). However, if two such + implementations are involved in the attack, neither will be able to + detect it. + +7.1. Alternate Solutions That Were Considered and Rejected + + Alternative solutions that were discussed include: + + Doing nothing - rely on suing the offender: While systems that have + accounts have logs that can be mined to locate abusers, it isn't + clear that this provides a credible deterrent or defense against + the attack described in this document. Systems that don't + recognize the situation and take corrective/preventative action + are likely to experience failure of a magnitude that precludes + retrieval of the records documenting the setup of the attack. (In + one scenario, the registrations can occur in a radically different + time period than the INVITE transaction. The INVITE request + + + +Sparks, et al. Standards Track [Page 17] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + + itself may have come from an innocent). It's even possible that + the scenario may be set up unintentionally. Furthermore, for some + existing deployments, the cost and audit ability of an account is + simply an email address. Finding someone to punish may be + impossible. Finally, there are individuals who will not respond + to any threat of legal action, and the effect of even a single + successful instance of this kind of attack would be devastating to + a service provider. + + Putting a smaller cap on Max-Forwards: The effect of the attack is + exponential with respect to the initial Max-Forwards value. + Turning this value down limits the effect of the attack. This + comes at the expense of severely limiting the reach of requests in + the network, possibly to the point that existing architectures + will begin to fail. + + Disallowing registration bindings to arbitrary contacts: The way + registration binding is currently defined is a key part of the + success of the kind of attack documented here. The alternative of + limiting registration bindings to allow only binding to the + network element performing the registration, perhaps to the + extreme of ignoring bits provided in the Contact in favor of + transport artifacts observed in the registration request, has been + discussed (particularly in the context of the mechanisms being + defined in [OUTBOUND]). Mechanisms like this may be considered + again in the future, but are currently insufficiently developed to + address the present threat. + + Deprecate forking: This attack does not exist in a system that + relies entirely on redirection and initiation of new requests by + the original endpoint. Removing such a large architectural + component from the system at this time was deemed too extreme a + solution. + + Don't reclaim breadth: An alternative design of the Max-Breadth + mechanism that was considered and rejected was to not allow the + breadth from completed branches to be reused (see + Section 5.3.3.1). Under this alternative, an introduced request + would cause, at most, the initial value of Max-Breadth + transactions to be generated in the network. While that approach + limits any variant of the amplification vulnerability described + here to a constant multiplier, it would dramatically change the + potential reach of requests, and there is belief that it would + break existing deployments. + + + + + + + +Sparks, et al. Standards Track [Page 18] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +8. Acknowledgments + + Thanks go to the implementers that subjected their code to this + scenario and helped analyze the results at SIPit 17. Eric Rescorla + provided guidance and text for the hash recommendation note. + +9. References + +9.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. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +9.2. Informative References + + [DESIGN] Hilt, V., "Design Considerations for Session Initiation + Protocol (SIP) Overload Control", Work in Progress, + July 2008. + + [OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated + Connections in the Session Initiation Protocol (SIP)", + Work in Progress, October 2008. + + [REQS] Rosenberg, J., "Requirements for Management of Overload + in the Session Initiation Protocol", Work in Progress, + July 2008. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. + Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, + March 1999. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + + + + + + +Sparks, et al. Standards Track [Page 19] + +RFC 5393 Amplification Vulnerability in SIP December 2008 + + +Authors' Addresses + + Robert Sparks (editor) + Tekelec + 17210 Campbell Road + Suite 250 + Dallas, Texas 75254-4203 + USA + + EMail: RjS@nostrum.com + + + Scott Lawrence + Nortel Networks, Inc. + 600 Technology Park + Billerica, MA 01821 + USA + + Phone: +1 978 288 5508 + EMail: scott.lawrence@nortel.com + + + Alan Hawrylyshen + Ditech Networks Inc. + 823 E. Middlefield Rd + Mountain View, CA 94043 + USA + + Phone: +1 650 623 1300 + EMail: alan.ietf@polyphase.ca + + + Byron Campen + Tekelec + 17210 Campbell Road + Suite 250 + Dallas, Texas 75254-4203 + USA + + EMail: bcampen@estacado.net + + + + + + + + + + + +Sparks, et al. Standards Track [Page 20] + |