Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (26)
A common implementation for the second branch-parameter part is a hash (e.g., CRC-32c or MD5 used non-cryptographically) over the Request-URI, Route header values, and other location-service inputs. Implementations SHOULD include at least one field that varies between different transactions to the same destination (e.g., Call-ID and CSeq) to avoid repeated failure on hash collision.
Deprecating forking entirely was considered and rejected as too extreme; the attack does not exist in a system relying entirely on redirection, but removing forking as an architectural component was deemed unacceptable.
Loop detection alone is insufficient when an attacker controls N distinct AORs each forking to all others; traffic grows faster than N! even with loop detection at all proxies. The Max-Breadth mechanism is designed to limit the effectiveness of this multi-AOR variant by capping concurrent branches.
Max-Breadth limits concurrent branches but allows breadth from completed branches to be reclaimed for subsequent sequential forks. An alternative that forbade reclamation was rejected because it would dramatically reduce the potential reach of requests and break existing deployments.
Reducing the Max-Forwards cap was considered and rejected: while it limits the exponential effect of the attack, it severely restricts request reach and could cause existing architectures to fail.
The loop-detection requirements make the favorable trade of exponential message growth for work that is at worst O(m*n) as a message crosses n proxies where m is the number of forking proxies. This is order N(N+1)/2 inspections in the worst case across all proxies.
A common SIPit interoperability failure has been parsers objecting to Via header field values from other elements. Implementations must avoid assumptions about the format of another element's Via beyond basic RFC 3261 constraints; unknown parameter names, valueless parameters, or quoted/unquoted parameter values must not cause failure.
A proxy MUST NOT decrement Max-Breadth for each hop or otherwise use it to restrict the depth of a request's propagation; Max-Breadth limits concurrent breadth only, not depth (that is Max-Forwards' role).
A SIP proxy forwarding a request to only one location MAY perform loop detection but is not required to; the amplification risk being exploited is not present in the non-forking case.
A User Agent Client (UAC) MAY place a Max-Breadth header field value in outgoing requests; if so, the value is RECOMMENDED to be 60.
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 or unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 (Max-Breadth Exceeded) response.
If a SIP proxy receives a request with no Max-Breadth header field value, it MUST add one; the value is RECOMMENDED to be 60. Proxies MUST have a maximum allowable Incoming Max-Breadth (RECOMMENDED 60), and MUST overwrite values exceeding this maximum with a value that SHOULD be no greater than the allowable maximum.
Proxies required to perform loop detection MUST inspect each Via header field value whose sent-by matches a value placed by this proxy. If the second part is present and equals the freshly-computed second part, the request has looped and the proxy MUST reject it with a 482 (Loop Detected) response.
Proxies required to perform loop detection SHOULD create a Via branch value separable into two parts: the first satisfying RFC 3261 Section 8.1.1.7, and the second used to perform loop detection and distinguish loops from spirals.
The second part of the Via branch parameter 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.
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 RFC 5393.
A UAS receiving a request with a Max-Breadth header field will ignore that field while processing the request. Max-Breadth does not affect UAS behavior.
The 440 (Max-Breadth Exceeded) response code signals that a request did not reach all possible destinations because the Max-Breadth budget was exhausted. Recovery options are similar to 483 (Too Many Hops): affect routing decisions or refine the request to reduce the search space.
The Max-Breadth header field carries a single positive integer representing the maximum number of concurrent branches a forked request may spawn from its current point. When a proxy forks, the Incoming Max-Breadth is divided among outgoing branches; Outgoing Max-Breadth is the sum of Max-Breadth values of branches without a final response.
Registers response code 440 with default reason phrase "Max-Breadth Exceeded" in the Response Codes sub-registry of the SIP Parameters registry.
Registers the Max-Breadth SIP header field (no compact form) in the Header Fields sub-registry of the SIP Parameters registry.
A small number of legitimate SIP requests can stimulate exponentially growing proxy-to-proxy traffic by leveraging forking. With RFC 3261 defaults, fewer than ten messages can stimulate potentially 2^71 messages through cross-registration of AORs across two proxies.
Protocol gateways (e.g., SIP-to-PSTN-to-SIP, B2BUAs) that strip loop-detection, Max-Forwards, or Max-Breadth data can create loops that none of these mechanisms protect against. If two such implementations are both involved in an attack, neither will detect it.
The Max-Breadth mechanism does not decrease aggregate traffic from a forking-loop attack; it only spreads traffic over a longer period by capping concurrent branches. An attacker can pump multiple requests to gradually build traffic. Deployments must monitor for gradual increases in concurrent outstanding transactions and be prepared to disable compromised resources.
The Max-Breadth header field takes a single positive integer value with no parameters, defined by the ABNF: Max-Breadth = "Max-Breadth" HCOLON 1*DIGIT.