Max-BreadthLimiting Amplification Attack Damage

Controlling the Impact of a Request on the Network

draft-sparks-sipping-max-breadth-00

Robert SparksEstacado 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.