Subject: RE: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 20 Apr 2006 09:50:28 +0200

>Do you mean "EVEN if other standardized mechanisms exist?"

Yes.

>If so, no - that's not what we're trying to say.

Then, what is the problem with the text I proposed earlier:

"RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized
mechansims for loop detecting MAY be used instead, or in addition, 
To the one defined in RFC 3261.".

Regards,

Christer

On 20-Apr-06, at 4:05 PM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi Robert,
>
> What you say is pretty much what I said in my proposed text (see 
> below), that a proxy "MUST ensure, using a standards lopp detection 
> mechanism, that a request is not looping through this proxy.".
>
> After that I said that one mechanism is defined in RFC3261, but other 
> mechanisms can also be used. The reason for that was that the text 
> would be "valid" also after other mechanisms have been defined.
>
> Do we want to say that a proxy SHOULD use the 3261 mechanism, EVEN if 
> other mechanims exist?
>
> Regards,
>
> Christer
>
>
>
>
>
>
> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: 20. huhtikuuta 2006 9:57
> To: Christer Holmberg (JO/LMF)
> Cc: Jonathan Rosenberg; [email-masked]; Robert Sparks; Keith Drage; Dean

> Willis
> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt
>
> How do you get that from this conversation?
>
> What we want to say is you MUST perform loop detection if you are 
> forking to locations that might loop. You SHOULD use the 3261 
> algorithm to do this detection.
>
> That's stronger and more specific than simply saying you SHOULD use
> 3261 loop detection in
> a vacuum.
>
> RjS
>
> On 20-Apr-06, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote:
>
>>
>> Hi,
>>
>> So, all we want to say with this draft is: "You SHOULD implement this

>> optional RFC3261 feature"?
>>
>> Regards,
>>
>> Christer
>>
>>
>> -----Original Message-----
>> From: Jonathan Rosenberg [mailto:[email-masked]]
>> Sent: 12. huhtikuuta 2006 18:11
>> To: Christer Holmberg (JO/LMF)
>> Cc: Robert Sparks; [email-masked]; Robert Sparks; Keith Drage; Dean 
>> Willis
>> Subject: Re: [Sip] WGLC for draft-ietf-sip-fork-loop-fix-01.txt
>>
>>
>>
>> Christer Holmberg (JO/LMF) wrote:
>>
>>
>>> So, maybe you could say: "MUST ensure, using a standards lopp 
>>> detection mechanism, that a request is not looping through this 
>>> proxy.
>>
>>> RFC 3261 defines a mechanism in chapter x.x.x.. Other standardized 
>>> mechansims for loop detecting MAY be used instead, or in addition, 
>>> to
>
>>> the one defined in RFC 3261.".
>>>
>>> Or something like that...
>>
>> I don't like that wording. I think its important to give clear 
>> guidance on what an implementor should do. The clear guidance is to 
>> implement the loop detection mechanism in RFC3261.
>>
>> -Jonathan R.
>>
>>
>> -- 
>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> Cisco Fellow                                   Parsippany, NJ
>> 07054-2711
>> Cisco Systems
>> [email-masked]                              FAX:   (973) 952-5050
>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>> http://www.cisco.com
>

_______________________________________________
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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Apr 2006 17:15:47 +0900

I don't have a problem with that. If I were to have any problem at  
all, it would
be in the redundancy with what the spec language means anyhow.

I'll throw a small monkey wrench into this. We're finding at SIPit  
(again)
that the text for loop detection in 3261 is nigh-unimplementable. People
who are trying to follow it for the first time are creating code that  
just does
not work. It is far from a concise description of an algorithm, and  
some of
its recommendations are wrong. (For instance, inclusion of the topmost
Via in the hash always produces a miss even if there is a loop).

Several of the participants here will be summarizing the problems they
have with this text over the next few weeks. I will be offline for a  
couple
of weeks starting this weekend - when I return I'll compile their input
and see if we can provide a clear description of how to do this loop  
detection.

I'll also note that these participants  find the algorithm in  stack- 
loop-detect
clear and plan to implement it and send comparative performance numbers
over what they have that reflects what 3261 says modified to actually  
work.

RjS

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Apr 2006 10:20:59 -0500

Robert Sparks wrote:
> (again) that the text for loop detection in 3261 is
> nigh-unimplementable. People who are trying to follow it for the
> first time are creating code that just does not work. It is far from
> a concise description of an algorithm, and some of its
> recommendations are wrong. (For instance, inclusion of the topmost 

Robert: That is a known bug (see
http://bugs.sipit.net/show_bug.cgi?id=648).  We had opened this
bug way back in 2002.  Basically, proxies that do loop detection
should not include the topmost Via in the hash.  Instead,
including a cryptographic hash of the To tag, the From tag, the
Call-ID, R-URI (before translation), CSeq number, and Route
headers should do the trick.  The spec also mentions Proxy-Require
and Proxy-Authorization fields, but I have had some success with
just the first set of fields.

Also, I am confused -- in previous bakeoffs, we have successfully
tested loop detection; so why can't we do this now?

> loop-detect clear and plan to implement it and send comparative
> performance numbers over what they have that reflects what 3261 says
> modified to actually work.

That should be interesting.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Apr 2006 01:11:20 +0900

inline -

> tested loop detection; so why can't we do this now?

Well - if you remember, we went through a lot of pain at each event when
we were testing new implementations of loop detection. By the end of  
each
event, most of the people that were trying to get it right got it  
working, but at
the start, it was a mess.

That basically went away when we went to max-forwards because most
people just took that logic out. Now that we're asking for it again,  
we're right
back to things not working.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Apr 2006 11:29:32 -0500

Robert Sparks wrote:
> Well - if you remember, we went through a lot of pain at each event
> when we were testing new implementations of loop detection. By the
> end of  each event, most of the people that were trying to get it
> right got it working, but at the start, it was a mess.

Yes, I remember those pains very well.  But most implementations
that did the "advanced scenarios" did eventually -- after much
configuration problems -- get it working with the set of headers
(except the Via header) suggested in rfc3261.

> we're right back to things not working.

That's the thing that puzzles me -- rfc3261 never deprecated loop
detection in favor of M-F.  All through until rfc3261 was released
(June 2002) and even thereafter, we used to do the loop detection
tests in the bakeoffs.  But I have not attended the bakeoff in the
last couple of years, so is it the case that somewhere down the
line we stopped doing loop detection tests in the bakeoffs
despite it still being a MAY in rfc3261?

Oh well...

- vijay

---

From: Robert Sparks <[email-masked]>
Date: Fri, 21 Apr 2006 08:07:11 +0900

inline

> despite it still being a MAY in rfc3261?

We still run the loop/spirals test. But for the last several years of  
SIPits,
almost no-one used the loop-detection concept. The vast majority of
implementations relied on max-forwards to end loops.

RjS