How does the UAC cancelling the request help. Surely all we end up with is the CANCEL request desperatly trying to catch up with all the propagated INVITE requests. I see nothing in the transaction model that helps it catch up, and I suspect (based on experience in non-SIP systems) that it never will in most people's implementations. It will always be pretty much the same number of steps behind.
Regards Keith > -----Original Message----- > From: Dale Worley [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 24, 2007 4:01 PM > To: [email protected] > Subject: Re: [Sip] Two minor Max-Breadth comments > > From: Adam Roach <[EMAIL PROTECTED]> > > 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. > > Also, the UAC, if it is not perverse, will ultimately cancel > the request. > > Dale > > > _______________________________________________ > 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
