Folks:
For those of you implementing rfc3261 proxies that do loop detection,
you may want to leave *out* the topmost Via when making a branch
ID as specified in section 16.6, step 8. If you include the
topmost Via, a loop will not be detected.
I am including an edited version of a private email exchange between
myself and Robert Sparks outlining this behavior and its resolution.
Regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566 Voice: +1 630 224 0216
-----------------------------------------------------------------------
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed Aug 21 10:45:23 CDT 2002
Robert:
This is in regards to a proxy adding a Via header with a
branch parameter which is calculated as per step 8, section
16.6 of rfc3261.
Why do we add the topmost Via header to the cryptographic hash of
the To tag, the From tag, Call-ID, CSeq number, and R-URI (before
translation) in detecting a loop? It would appear that doing so
will never result in a loop being detected. The topmost Via
will always be different in a looped request.
Consider the following:
F1 F2
UAC ----> P1 ----> P2
/\ +
| F3 |
+-------+
where F3 is the looped request and the loop is detected at P1. Now,
when P1 first proxies the request, it follows the instructions in
16.6, step 8. Since it is still constructing *it's* own Via header,
the topmost Via header referred to in 16.6 step 8 will be that of
the UAC. So, UAC's Via header is used to create the cryptographic
hash (as well as To tag, From tag, R-URI, ...)
At some later point, P1 gets F3 and scans the Via list to see if a
sent-by matched one it inserted (it will). So, it now uses
instructions in step 8 of section 16.6 to construct the branch
parameter. The instructions instruct it to use the "topmost Via
header", which in this case is that of P2's. So, the hash thus
constructed will not match what it inserted earlier, and it will
recognize this as a spiral.
Thanks,
- vijay
--------------------------------------------------------------------------------
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
On Wed, 2002-08-21 at 10:45, Vijay K. Gurbani wrote:
> Robert:
>
> This is in regards to a proxy adding a Via header with
> a branch parameter which is calculated as per step 8,
> section 16.6 of rfc3261.
>
> Why do we add the topmost Via header to the cryptographic hash
> of the To tag, the From tag, Call-ID, CSeq number, and R-URI
> (before translation) in detecting a loop? It would appear that
> doing so will never result in a loop being detected. The
> topmost Via will always be different in a looped request.
This is actually a very important characteristic if you _aren't_
doing loop detection (and remember that loop detection is optional
and even arguably undesirable).
If you produce the same branchid both times through the loop, the
downstream element will see the second message as a _retransmission_
of the first, not a request that has come around in a loop. It will
not forward that request, and the whole scenario dies a cascading
timeout death (necessarily having to wait for the timeout).
If you going through the trouble to detect loops, you should construct
branch parameters that allow you to detect them. I will add a bug to
explicitly call this out. The recipe that is currently described
(and note that it is not _prescribed_) is appropriate for proxies
that don't loop detect.
RjS
--------------------------------------------------------------------------------
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
inline.
Robert Sparks wrote:
> On Wed, 2002-08-21 at 10:45, Vijay K. Gurbani wrote:
>
> This is actually a very important characteristic if you _aren't_
> doing loop detection
> However, the text in rfc3261 (section 16.6, step 8) appears in the
> context that reads something as follows: "if you want to do loop
> detection, you should do the following..."
>
> (and remember that loop detection is optional and even arguably
> undesirable).
Yes, I remember us making it optional; although I can see it being
desirable in some cases.
> If you produce the same branchid both times through the loop, the
> downstream element will see the second message as a _retransmission_
> of the first, not a request that has come around in a loop. It will
> not forward that request, and the whole scenario dies a cascading
> timeout death (necessarily having to wait for the timeout).
True; but this is not optimal since resources are consumed in multiple
places until the timeout occurrs.
> If you going through the trouble to detect loops, you should
> construct branch parameters that allow you to detect them.
And that should not include the topmost Via header.
> I will add a bug to explicitly call this out. The recipe that is
> currently described (and note that it is not _prescribed_) is
> appropriate for proxies that don't loop detect.
Although, as I alluded to above, if you read step 8 of section 16.6,
it appears in the context of "if you want to detect loops, do the
following..." which is misleading for implementors.
Thanks,
- vijay
--------------------------------------------------------------------------------
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
> Yes, I remember us making it optional; although I can see it being
> desirable in some cases.
Ok - there are cases, but they're pretty much at the edge
(such as wireless, where its more expensive to send one extra
message than to load your system with an O(n2) operation).
> > If you produce the same branchid both times through the loop, the
> > downstream element will see the second message as a _retransmission_
> > of the first, not a request that has come around in a loop.
> > It will
> > not forward that request, and the whole scenario dies a cascading
> > timeout death (necessarily having to wait for the timeout).
>
> True; but this is not optimal since resources are consumed in multiple
> places until the timeout occurrs.
Which was my point - this is a _bad thing_ - we want to avoid it.
> > If you going through the trouble to detect loops, you should
> > construct branch parameters that allow you to detect them.
>
> And that should not include the topmost Via header.
Yes
> > I will add a bug to
> > explicitly call this out. The recipe that is currently described
> > (and note that it is not _prescribed_) is appropriate for proxies
> > that don't loop detect.
>
> Although, as I alluded to above, if you read step 8 of section 16.6,
> it appears in the context of "if you want to detect loops, do the
> following..." which is misleading for implementors.
I've added a bug to explicitly state the difference between the
branch calculation for proxies that do loop detection and those that
don't.
RjS
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
