Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
Extracted elements (13)
B2BUAs cause unbounded SIP request loops because, as UACs, they may legally reset the Max-Forwards value on their outgoing side. Via-based loop detection defined in RFC 3261 cannot detect loops across such B2BUAs any earlier than when Max-Forwards reaches zero.
Existing ad hoc B2BUA loop-detection approaches—tracking outstanding dialog-forming requests per URI pair, detecting repeated media addressing information, or encoding instance identifiers—are brittle because it is hard to define when a value has been seen 'too many times', and forking and spiraling cause false positives.
The Max-Forwards copy-and-decrement requirement applies to dialog-forming and out-of-dialog SIP requests; applying it to in-dialog requests is optional (MAY) but may cause issues with devices that set Max-Forwards based on the number of received Via or Record-Route headers.
All B2BUA types MUST copy the received Max-Breadth header field from the UAS-side request to any UAC-side request(s) they generate, as if they were a proxy following RFC 5393.
B2BUAs, acting as a UAS, MUST check the received Max-Forwards header field and reject or respond to the request if the value is zero, as defined in RFC 3261.
B2BUAs of all types MUST follow the requirements imposed on proxies in RFC 5393 Section 5.3.3 for Max-Breadth, including generating the header field if none is received and limiting its maximum value.
B2BUAs that generate parallel requests on their UAC side for a single incoming UAS-side request MUST follow RFC 5393 Max-Breadth handling rules as if they were a parallel forking proxy, to mitigate amplification.
If the received request did not contain a Max-Forwards header field, a B2BUA MUST create one in any UAC-side request it generates; the value of the new Max-Forwards header SHOULD be 70, per RFC 3261 Section 16.6 Step 3.
It is RECOMMENDED that B2BUAs implement the Via header field loop-detection mechanism defined for proxies in RFC 5393.
The Max-Breadth SIP header field, introduced by RFC 5393, mitigates parallel forking amplification floods. B2BUAs must propagate it across the UAS-to-UAC boundary and apply the same generation and limiting rules as proxies.
The Max-Forwards SIP header field limits the number of hops a request may traverse. B2BUAs must treat it as proxies do: copy, decrement, and reject at zero, ensuring loops terminate rather than running indefinitely.
Some B2BUAs intentionally reset Max-Forwards and Max-Breadth to obfuscate the number of hops a request has traversed for privacy or security reasons. This goal conflicts with loop-detection requirements; administrators must choose between obfuscation and loop detection. Manufacturers MUST comply with the normative rules by default but MAY provide user-configurable overrides.
This document introduces no security issues beyond those already documented for parallel forking amplification in RFC 5393 Section 7.