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

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 20 May 2006 14:23:35 +0200

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Byron Campen <[email-masked]>
Date: Sat, 20 May 2006 11:10:53 -0500

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
>
> 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
>
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 20 May 2006 18:22:09 +0200

Byron,

Thanks for your responses. I think it would be worthwhile to include this information in your draft, it helps to make things explicit.
  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. 

I made a suggestion on the list the other day: keep a forking proxy from forwarding to an element which is already on the Via list, i.e. loop prevention rather than detection. You would still need both of course, since one cannot rely on other proxies having implemented this. I believe it could be a simple and effective solution, what do you think?

Regards,

Jeroen

---

From: Byron Campen <[email-masked]>
Date: Sat, 20 May 2006 12:17:57 -0500

Yes, I plan to revise my draft, although the information you have  
highlighted below would be more appropriate to put in a revision of  
the fork-loop-fix draft, and possibly also the max-breadth draft.
	The fork-prevention idea will not work, I am afraid, since it will  
trigger on legitimate spirals that pop up all the time in the real  
world. (Say, bob@foo -> appserver -> bob@foo -> bob's UAs (fork) )

Best regards,
Byron Campen

> Byron,
> Thanks for your responses. I think it would be worthwhile to  
> include this information in your draft, it helps to make things  
> explicit.
> 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.
>
> I made a suggestion on the list the other day: keep a forking proxy  
> from forwarding to an element which is already on the Via list,  
> i.e. loop prevention rather than detection. You would still need  
> both of course, since one cannot rely on other proxies having  
> implemented this. I believe it could be a simple and effective  
> solution, what do you think?
>
> Regards,
>
> Jeroen
>