[Sipping] Re: draft-campen-sipping-stack-loop-detect-00, top route headers and spiraling

[Byron Campen <[e-mail]>]

	In regard to your first question, I had envisioned checking the  
topmost route header after the route header referring to the proxy  
was removed. If my wording suggests otherwise, I have erred.

	In regard to your second question, this problem had occurred to me  
also, although I did not address the particular variation of the  
problem where IP address does not have a one-to-one correspondence  
with proxy. In the case you mention, it would probably be safe to  
just pick one of the IP addresses being listened on, although if  
routing behavior differed depending on what address/port a request  
came in on, an approach like you mention is a likely candidate for  
solving the problem.

	As for your last question, yes the stack algorithm will usually  
detect a loop later than 3261 loop detection, but it is guaranteed to  
detect before completion of the second iteration of the loop. This is  
the tradeoff we make with this algorithm.

	Unfortunately, loop-detection actually doesn't solve the forking- 
loop exploit detailed in maxforwards-problems. Instead of a  
maxforwards^m level of amplification(m is the number of proxies  
involved), we still get well over an m! level of amplification.  
Robert Sparks worked it out to O(m^m), and I am not surprised (this  
of course only applies for cases where m < max-forwards). This is an  
improvement, but is still not acceptable. The only solution put  
forward so far  that seems to adequately reduce the damage caused by  
the forking loop exploit is the technique detailed in the max-breadth  
draft.

Best regards,
Byron Campen

> Both draft-campen-sipping-stack-loop-detect-00 and RFC3261 include  
> the topmost Route header in the calculation of a digest for loop  
> detection. This will fail in the following scenario involving a UE  
> and 3 proxies P1,P2,P3:
>
> UE sends:
> INVITE U1
> Route: P1
>
> P1 removes Route: P1 and forwards to P2:
> INVITE U1
> Route: P2
>
> P2 removes Route: P2 and forwards to P3 via P1:
> INVITE U1
> Route: P1, P3
>
> P1 receives this request and detects a loop (while it shouldn't).
>
> In other words, the route header that influences the processing is  
> the topmost Route header *after* removing route headers that point  
> to the element processing the request. In terms of RFC3261, the  
> processing step mentioned at the end of section 16.4 should be  
> performed before section 16.3 point 4.
>
> Second issue: the loop-detect-draft suggest the use of an IP  
> address to identify a node. This won't work in case multiple ports  
> and/or transports are used at a single IP address. Each should be  
> treated as a different logical instance of a proxy (hence:  
> suggestion to include the transport and port in the node identifier)
>
> Final question: do I understand correctly that the stack-based loop  
> detection algorithm may detect a multi-hop loop later than the  
> current RFC3261 algorithm? So if I have UE->P1->P2->P3->P1->P2 it  
> may detect it at P2, not P1?
>
> Regards,
>
> Jeroen
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP