Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt

From: [email-masked]
Date: Thu, 13 Jul 2006 17:14:50 +0200

Robert Sparks wrote:
> I have another open issue on the current algorithm (as it is presented 
> in RFC 3261) which suggests that the "Via" header should be added, 
> without telling that, of course, the branch parameter should NOT be 
> used in Hash calculation (overwise it will always be different and 
> loop will never be detected...)
>  
> the fork-loop-fix draft (at version -02) _REPLACES_ all of that text 
> in 3261. I don't think the replacement text has the problem you
> point to does it?
This is the part which mentions the open issues:

> This second part MUST vary with any field used by the location
>
>    service logic in determining where to retarget or forward this
>    request.  This is necessary to distinguish looped requests from
>    spirals by allowing the proxy to recognize if none of the values
>    affecting the processing of the request have changed.  Hence, The
>    second part MUST depend at least on the received Request-URI and any
>    Route header field values in the received request.  Implementers need
>    to take care to include all fields used by the location service logic
>    in that particular implementation.
>
>    This second part MUST NOT include the request method.  CANCEL and
>    non-200 ACK requests MUST have the same branch parameter value as the
>    corresponding request they cancel or acknowledge.  This branch
>    parameter value is used in correlating those requests at the server
>    handling them (see Sections 17.2.3 and 9.2).
I am confused with this part:
there is no more sent-by part of the Via header? why is not mentionned 
in the open issue part then? (like for Call-Id ,toTag, and fromTag which
should actually be removed...)

> Another quick comment on the section 4 of 
> draft-ietf-sip-fork-loop-fix-02.txt
>>>  4.  Loop Detection Check
>>>
>>>    Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor:
>>>    replace XXXX with the RFC number of this document) MUST perform the
>>>    following loop-detection test before forwarding a request.  Each Via
>>>    header field value in the request whose sent-by value matches a 
>>> value
>>>    placed into previous requests by this proxy MUST be inspected for 
>>> the
>>>    "second part" defined in Section 4.2.1 of RFC-XXXX.  This second 
>>> part
>>>    will not be present if the message was not forked when that Via
>>>    header field value was added.  If the second field is present, the
>>>    proxy MUST perform the second part calculation described in
>>>    Section 4.2.1 of RFC-XXXX on this request and compare the result to
>>>    the value from the Via header field.  If these values are equal, the
>>>    request has looped and the proxy MUST reject the request with a 482
>>>    (Loop Detected) response.  If the values differ, the request is
>>>    spiraling and processing continues to the next step.
>> The question here is, how do I know that the "second part" is present?
>> the common practice is to setup a branch with a "minus" separator, eg:
>> branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH
>> however, it is also common pratice for many implementation to setup 
>> some additionnal information in their branch, also using the "minus" 
>> separator,
>> e.g:
>> branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH
>>
>> So, since the "presence" of minus (or any other) separator may not be 
>> enough, and in order to be able be sure the "loop detection part" is 
>> here,
>> wouldn't it be useful to setup another kind of "magic cookie" for that?
>
> So the only thing that will look into the branch for the second part 
> is the thing that put that second part there.
> You don't need to know how anyone else forms their branch parameter 
> with respect to this.
>
> Since you put the value in, you know how to recognize whether it's 
> there. I don't see importance in making everyone
> do this the same way.
because if somebody use -XX at the end of the branch parameter (and this 
is common practice), I will have to make unecessary computation on the 
incoming request...
One possible solution to avoid this is to have some kind of magic 
cookie, or a pre-defined separator... If I decide to use '--' as 
separator,  unfortunately, it may 
by used by somebody else in its branch format (and for something ELSE 
than loop detection)...

_______________________________________________
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, 13 Jul 2006 13:34:35 -0400

On Jul 13, 2006, at 11:14 AM, [email-masked] wrote:

> Robert Sparks wrote:
>> I have another open issue on the current algorithm (as it is  
>> presented in RFC 3261) which suggests that the "Via" header should  
>> be added, without telling that, of course, the branch parameter  
>> should NOT be used in Hash calculation (overwise it will always be  
>> different and loop will never be detected...)
>>  the fork-loop-fix draft (at version -02) _REPLACES_ all of that  
>> text in 3261. I don't think the replacement text has the problem you
>> point to does it?
> there is no more sent-by part of the Via header? why is not  
> mentionned in the open issue part then? (like for Call-Id ,toTag,  
> and fromTag which

I didn't call that out as an open issue because we have clear  
consensus to not include the
topmost via in the calculation. I should have made a note of that in  
the changelog - sorry
for the confusion.

>
>> Another quick comment on the section 4 of draft-ietf-sip-fork-loop- 
>> fix-02.txt
>>>>  4.  Loop Detection Check
>>>>
>>>>    header field value in the request whose sent-by value matches  
>>>> a value
>>>>    placed into previous requests by this proxy MUST be inspected  
>>>> for the
>>>>    "second part" defined in Section 4.2.1 of RFC-XXXX.  This  
>>>> second part
>>> however, it is also common pratice for many implementation to  
>>> setup some additionnal information in their branch, also using  
>>> the "minus" separator,
>>> e.g:
>>> So, since the "presence" of minus (or any other) separator may  
>>> not be enough, and in order to be able be sure the "loop  
>>> detection part" is here,
>> So the only thing that will look into the branch for the second  
>> part is the thing that put that second part there.
>> You don't need to know how anyone else forms their branch  
>> parameter with respect to this.
>>
> because if somebody use -XX at the end of the branch parameter (and  
> this is common practice), I will have to make unecessary  
> computation on the incoming request...
> separator,  unfortunately, it may by used by somebody else in its  
> branch format (and for something ELSE than loop detection)...
>

What computation are you doing on other people's branch tag? You  
should only be looking inside ones you put there.

I think you're here at IETF - could we take this to an in-person  
conversation?

RjS

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 13 Jul 2006 16:03:15 -0500

Hi,

  There is draft available for avoiding loops also.

http://www.ietf.org/internet-drafts/draft-srivastava-sipping-loop-avoida
nce-00.txt

It got comments from the group. Refer following threads for the solution
to them

http://www1.ietf.org/mail-archive/web/sipping/current/msg11084.html

http://www1.ietf.org/mail-archive/web/sipping/current/msg11085.html

http://www1.ietf.org/mail-archive/web/sipping/current/msg11097.html

I will be updating the draft with these. Appreciate your comments also
on this.

It has nice side effect of checking of SIP reachability at the addition
of bindings when they are spanning across the domains i.e. * bindings
are not added in vacum * .

Thx
Samir

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 11:15 AM
> To: Robert Sparks
> Cc: [email-masked]
> Subject: [Sip] Re: question on draft-ietf-sip-fork-loop-fix-02.txt
> 
> Robert Sparks wrote:
> > in 3261. I don't think the replacement text has the problem 
> you point 
> > to does it?
> mentionned in the open issue part then? (like for Call-Id 
> ,toTag, and fromTag which should actually be removed...)
> 
> >> here, wouldn't it be useful to setup another kind of 
> "magic cookie" 
> >> for that?
> >
> > there. I don't see importance in making everyone do this 
> the same way.
> because if somebody use -XX at the end of the branch 
> parameter (and this is common practice), I will have to make 
> unecessary computation on the incoming request...
> One possible solution to avoid this is to have some kind of 
> magic cookie, or a pre-defined separator... If I decide to 
> use '--' as separator,  unfortunately, it may by used by 
> somebody else in its branch format (and for something ELSE 
> than loop detection)...
> 
> 
> 
>  
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked]
Date: Thu, 13 Jul 2006 15:47:51 +0200

After you presented in SIP meeting the 3 open issues of current SIP loop 
detection algorithm which are identified in sip-fork-loop-fix:
>   Open Issue 1 :  Why do all the Route header field values need to be
>       included?  Only the top two in the received request will normally
>       influence processing (in general, the topmost and any others this
>       proxy removes from the message, plus the topmost in the message
>       the proxy emits).  Can we simplify this to only include those
>       Route header field values that actually affect the processing of
>       the message?
>    Open Issue 2 :  RFC 3261 recommends Call-ID, To-tag, and From-tag and
>       CSeq be included in this second part.  Why?  This are guaranteed
>       to be invariant each time the request passes through this proxy.
>       Further the created value will only be compared with Vias received
>       from previous times the request went through this proxy, so there
>       is no possibility of comparing this value with a hash created from
>       some other request with a different Call-ID, To-tag, or From-tag
>       or CSeq.  I've removed these fields from the recommended set for
>       this version of the draft.
>   
Do we agree on these two?
>    Open Issue 3 :  RFC 3261 recommends including any Proxy-Require and
>       Proxy-Authorization header field values in the second part.  Why
>       it it valuable to call these out as special cases?  What is the
>       use case where they will be the only thing in a message returning
>       to a proxy that varies, making the return a spiral instead of a
>       loop?  I haven't been able to remember the motivation - we need to
>       re-identify that and capture it here or remove the text making
>       these anything other than a case covered by the abstract "fields
>       used by the location service logic".  This draft is taking the
>       second option.
I think Jonathan noticed during the meeting that he remembers a good 
reason to keep Proxy-Require and Proxy-Authorization, but I am not sure 
to know what is the final decision on this open issue.

I have another open issue on the current algorithm (as it is presented 
in RFC 3261) which suggests that the "Via" header should be added,
without telling that, of course, the branch parameter should NOT be used 
in Hash calculation (overwise it will always be different and loop will 
never be detected...)

>    header field value in the request whose sent-by value matches a value
>    placed into previous requests by this proxy MUST be inspected for the
>    "second part" defined in Section 4.2.1 of RFC-XXXX.  This second part
The question here is, how do I know that the "second part" is present?
the common practice is to setup a branch with a "minus" separator, eg:
branch=z9hg4bKRANDOMID-LOOPDETECTIONHASH
however, it is also common pratice for many implementation to setup some 
additionnal information in their branch, also using the "minus" separator,
e.g:
branch=z9hG4bKRANDOMID-MYIMPLEMENTATIONSTUFF-LOOPDETECTIONHASH

So, since the "presence" of minus (or any other) separator may not be 
enough, and in order to be able be sure the "loop detection part" is here,
wouldn't it be useful to setup another kind of "magic cookie" for that?

Thomas

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Jul 2006 10:32:29 -0400

On Jul 13, 2006, at 9:47 AM, [email-masked] wrote:

> After you presented in SIP meeting the 3 open issues of current SIP  
> loop detection algorithm which are identified in sip-fork-loop-fix:
> I think Jonathan noticed during the meeting that he remembers a  
> good reason to keep Proxy-Require and Proxy-Authorization, but I am  
> not sure to know what is the final decision on this open issue.
>
> be added,

> some additionnal information in their branch, also using the  
> "minus" separator,
> e.g:
> So, since the "presence" of minus (or any other) separator may not  
> be enough, and in order to be able be sure the "loop detection  
> part" is here,

RjS