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

[Byron Campen <[e-mail]>]

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

_______________________________________________
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