Max-Breadth Limiting Amplification Attack Damage Controlling the Impact of a Request on the Network draft-sparks-sipping-max-breadth-00 Robert Sparks Estacado Systems

Max-Breadth Discussed in depth at SIPit 17. Concept explored in maxforward- problems by apportioning remaining Max-Forwards values among branches –Feedback: would break existing deployments New proposal: A separate, complementary mechanism to Max- Forwards

Max-Breadth Mechanism New Max-Breadth header carries # of concurrent branches that can be added downstream from recipient. Value apportioned among branches –As branches finish, their value can be reclaimed and applied to new branches –Small values push forking towards serial (1==serial) where that makes sense –For applications where restricting the branching this way doesn’t make sense, an element would return a new 4xx Max-Breadth exceeded response

Impact of Mechanism Requests generally traverse the same graph, but only a bounded number of edges are active (each edge is a SIP transaction) at any given time. In existing and currently anticipated deployments, mechanism would not perturb processing at all unless something was going wrong.

Why is this important? The loop-detection fix to the known amplification attack helps, but isn’t perfect. –With loop-detection, attack reduces to O(2^M) where M is the number of AORs involved. Minor changes render O(2^MlogM) amplification Depletion of Max-Breadth can be monitored, providing early warning and better diagnostics for emerging problems.

Going Forward List discussion –Before SIPit is better Analyze the mechanism –Can we identify a concrete application where this approach causes harm? If not, this should be passed to SIP soon.