Subject: RE: [Sip] comments on draft-ietf-sip-fork-loop-fix-01

From: <[email-masked]>
Date: Mon, 22 May 2006 08:45:41 +0530

Hi,

I was thinking how to reduce the impact of overhead for calculating the
digest.

If it is suggested as follows, I think it will reduce the overhead on
normal scenarios:

Proxy checks to see if its address is there in the via already. 
If it is not there, it proceeds normally without calculating the digest
and inserting Via to the outgoing request without the digest.
If it is there, then it is possible that the request is looping. So,
this time around, it calculates a digests and inserts and sends it
along.
If it is looping, the request will definitely come in again, which can
be rejected.
This way the impact of calculating the digest is required (reduced to a
smaller percent of the sessions) only when the proxy is suspicious the
request might be looping.
Of course this results in the scenarios mentioned in the id to be
successful in completing the first loop, but the second loop will be
detected and arrested. I think this can be applicable to general loop
detection, and not just fork loop fixes.

I am not sure if this already has been discussed. If not, this probably
can be considered to be suggested in the id.

Regards,
Ravi.

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 12:25 AM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] comments on draft-ietf-sip-fork-loop-fix-01
> 
> inline
> 
> > inline.
> >
> > Jeroen van Bemmel wrote:
> >
> >>>>  These requirements and the recommendation to use the 
> loop-detection
> >>>>    mechanisms from RFC 3261 make the favorable trade of 
> exponential
> >>>>    message growth for work that is at worst case order 
> n^2 as a message
> >>>>    crosses n proxies.  Specifically, this work is order 
> m*n where m is
> >>>>    the number of proxies in the path that fork the 
> request to more than
> >>>>    one location.  In practice, m is expected to be small.
> >>>
> >>>
> >>> You should explain what this work is - checking each of the N via 
> >>> headers. You also don't explicitly say that this n^2 work 
> is spread 
> >>> across n proxies. Its only N at any particular proxy.  This is 
> >>> important because, as I argued at the mike, I think the 
> constant in 
> >>> front of this is sufficiently small to be unimportant.
> >>>
> >>
> >> I would expect that the bulk of the work is not inspecting the Via 
> >> headers, but rather calculating the digest for 
> distinguishing loops 
> >> from spirals.
> >
> > Sure. But you only need to do that when there is a loop of 
> any sort. 
> > In other words, you first check to see if your address is 
> on the Via list.
> > Only if its there do you bother to check if it was a loop 
> vs. a spiral.
> >
> 
> There are 2 points at which a proxy calculates a digest: upon 
> reception 
> (RFC3261 16.3 point 4) and when forwarding (RFC3261 16.6 
> point 8). You can 
> avoid the first when there is no matching via header, and you 
> can avoid the 
> second when you already calculated the first, but it will have to be 
> performed once for each passage of a request (before translation), 
> regardless whether there is a loop or not.
> 
> >
> >
> >> And you're trading *potential* (typically very rare) 
> exponential message 
> >> growth for *guaranteed* (always, for every forked request) 
> order n^2 
> >> work.
> >
> > Well, the huge potential damage from this attack really 
> does require this 
> > tradeoff. I still don't think the work is that significant. 
> Its O(N) on 
> > each proxy and I really do think this constant is very 
> small. Just the 
> > time it takes to find your own address in the Via list.
> >
> 
> It's not that I disagree with the necessity, just that it 
> should be made 
> explicit what is being traded-off here
> 
> Regards,
> 
> jeroen
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip