[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
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.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx
(or http://www.xml2cpp.com)
=============================================
----- Original Message -----
From: "Jeroen Van Bemmel" <jbemmel at zonnet.nl>
To: "Robert Sparks" <rjsparks at nostrum.com>
Cc: "Cullen Jennings" <fluffy at cisco.com>; "SIP" <sip at ietf.org>; "Pete
Cordell" <pete at tech-know-ware.com>
Sent: Thursday, September 14, 2006 4:06 PM
Subject: RE: [Sip] Good Hash: draft-ietf-sip-fork-loop-fix-03
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
-----Oorspronkelijk bericht -----
Van: "Robert Sparks" <rjsparks at nostrum.com>
Aan: "Jeroen Van Bemmel" <jbemmel at zonnet.nl>
CC: "Pete Cordell" <pete at tech-know-ware.com>; "Cullen Jennings"
<fluffy at cisco.com>; "SIP" <sip at ietf.org>
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip