Subject: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Oct 2006 12:41:18 -0400

I've about got -04 ready to go - going through all the -03 comments  
to make sure they were covered  - this (and Jeroen's quoted comment)  
need a reply.

Inline:

On Sep 14, 2006, at 1:08 PM, Pete Cordell wrote:

> I don't think CSeq should be included either.  We want information  
> that is invariant throughout a session.  By including CSeq there's  
> a chance that one request doesn't have a hash collision when doing  
> the loop detection, but a subsequent request does.
>
> Pete.

We already have other things going into the input that will cause the  
output to vary between transactions. At a minimum an initial request  
might not have a Route hf, where a subsequent request may:
(from the draft):
> 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 used when processing
> the received request. Implementers need to take care to include all  
> fields used by the
> location service logic in that particular implementation.

So, including the CSeq does no harm, and it could do good to avoid  
repeating the collision.

>
> ----- Original Message ----- From: "Jeroen Van Bemmel"  
> <[email-masked]>
>> To: "Robert Sparks" <[email-masked]>
>>
>> Yes, except that using "the via branch" here is tricky: which one  
>> do you take?
>>
>> Pre-RFC3261 clients would not insert a branch parameter, so taking  
>> the top via branch wont always work. Using the branch parameter  
>> added by the proxy itself is possible, provided that only the  
>> "first part" is used. Implementors then need to make sure to  
>> disect the branch prior to calculating the loop hash.
>>
>> Possible, but easy to get wrong
>>
>> Jeroen

That is the same concern I have had all along with the basic way this  
"look through the Via stack" loop detection mechanism is constructed  
in the first place.
It's very likely that the first time implementer will do something  
wrong. The most frequent wrong thing I saw at SIPits back when this  
was mandatory the first time around
was that implementations were very fragile about parsing other  
people's Vias, particularly the Vias of other proxies that were using  
the via as a convenient place to hold
information about the transaction for when the response came back  
through (made for unusually formed, but quite legal field values).

To your specific comment, my text below was ambiguous. Here's the  
tightened up version that I'm putting in -04. Note that this isn't  
asking an implementation to do _any_ dissection
of a via branch parameter it didn't create (which is the confusion I  
think I caused you).
(from the draft):
>    When forming the second part using a hash,
>    implementations SHOULD include at least one field in the input  
> to the hash that
>    varies between different transactions attempting to reach the  
> same destination to avoid
>    repeated failure should the hash collide. The Call-ID and CSeq  
> fields, or the first part
>    of the via branch parameter value the proxy is currently  
> constructing would be good inputs for this purpose.

RjS

>
> -----Oorspronkelijk bericht -----
> Van: "Robert Sparks" <[email-masked]>
> Aan: "Jeroen Van Bemmel" <[email-masked]>
> CC: "Pete Cordell" <[email-masked]>; "Cullen Jennings"  
> <[email-masked]>; "SIP" <[email-masked]>
> Verzonden: 14-9-06 15:00
> Onderwerp: Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
>
> Hrmm. Let me poke at that for a minute.
>
> You would never compare the hashes you created for two different
> calls. You only compare hashes for
> different instances of the _same request_ reaching the element
> multiple times. The only things in the
> Via stack when the request reaches you are values placed when _this
> request_ went through other element,
> and you're checking to see if one of them just happened to be this
> element.
>
> The Call-ID is invariant for those comparisons. If you had a perfect
> hash, including it would have no effect
> on the correctness of the algorithm at all - it would be wasted
> effort, which is why we were removing it.
>
> But for a hash that has collisions, including it, or any other set of
> bits that change between requests,
> shifts where you land in the hash's range, increasing the probability
> that you won't encounter the _same_
> collision more than once.
>
> That may be exactly why call-id and cseq were included in the hash in
> 3261. Assuming that's so, then
> all we need are bits that change between transactions. The first part
> of the via branch parameter would
> be enough.
>
> So, I propose I add text explaining why you SHOULD (do we make this
> MUST?) add some set of bits that
> change between requests, and note that either the first part of the
> via branch or the combination of call-id
> and cseq would be good choices.
>
> RjS
>
> On Sep 14, 2006, at 5:20 AM, Jeroen Van Bemmel wrote:
>
>>
>> I suppose one issue is that if you do happen to be the 20 billionth
>> person
>> trying to make such a call, then your call will fail every time,
>> which may
>> be a bad effect.
>>
>> (jvb) And THAT'S the reason to include the call-id in the hash: to
>> ensure that an unlucky caller does not suffer the same fate twice
>> (or rather: to make it very unlikely)
>>
>> Jeroen
>
>
>
> _______________________________________________
> 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
>
>

_______________________________________________
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: Sat, 21 Oct 2006 12:48:00 -0400

ARGH!

Moments after hitting send and double-checking the text, I realized  
the text on using the first-part of the via as quoted below is  
horribly broken. Sorry - it was just wrong.

Instead of trying to repair it to go back to the topmost via hfv  
(which was the original idea, and _CAN_ have the problem Jeroen was  
worried about, I'll simplify back to
just Call-ID and CSeq.

RjS

On Oct 21, 2006, at 12:41 PM, Robert Sparks wrote:

> to make sure they were covered  - this (and Jeroen's quoted  
> comment) need a reply.
>
> Inline:
>
> We already have other things going into the input that will cause  
> the output to vary between transactions. At a minimum an initial  
> request might not have a Route hf, where a subsequent request may:
> (from the draft):
>> the received request. Implementers need to take care to include  
>> all fields used by the
>>> Pre-RFC3261 clients would not insert a branch parameter, so  
>>> taking the top via branch wont always work. Using the branch  
>>> parameter added by the proxy itself is possible, provided that  
>>> only the "first part" is used. Implementors then need to make  
>>> sure to disect the branch prior to calculating the loop hash.
>>>
> That is the same concern I have had all along with the basic way  
> this "look through the Via stack" loop detection mechanism is  
> constructed in the first place.
> people's Vias, particularly the Vias of other proxies that were  
> using the via as a convenient place to hold
> of a via branch parameter it didn't create (which is the confusion  
> I think I caused you).
> (from the draft):