These are important points - adding max-breadth makes the effects of
responses from the endpoints and CANCELS (from the originator or from
proxies) meaningful.
(In the original attack, the cancel could never catch up with the
request).
For the last point - Throwing the 600 doesn't tear the whole tree
down immediately. The 600 will be held by each node until all
branches under it complete.
Once that happens it moves upstream. When it moves upstream, the next
node starts canceling other branches. Those CANCELs still won't catch
the request,
but the number of things it has to chase is bounded above by a constant.
RjS
On Jul 24, 2007, at 9:48 AM, Adam Roach wrote:
During today's meeting, a point was raised surrounding whether the
max-breadth approach should limit the total number of requests or
merely the number of requests in flight at once. The statement is
that limiting only the ones in flight simultaneously ultimately
results in the same number of messages as would result without the
extension.
While there has been a token mention of Timer C, I think we're
underestimating the mitigating effect of Timer C.
As an additional point, I think it's worth pointing out that the
victim, if they recognize they are being subjected to this style of
attack, can tear the entire tree down fairly rapidly by throwing a
600-class response.
/a
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
