Subject: [SIP] Loop Detection Again

From: "Jo Hornsby" <[email-masked]>
Date: Tue, 22 Aug 2000 14:58:17 +0100

Hi,

I'd like to revisit the thorny issue of Loop Detection and
Via-Hiding, if I may.

Imagine an INVITE issued by a User Agent, UA X, which is routed
through Proxy A to Proxy B, whereby Proxy B decides to send it
on to Proxy A.  At this point the INVITE has looped.  However,
Proxy A requested Via hiding, so does not detect the loop, and
forwards the request to Proxy B again.
  
    +------+         +---------+   1st   +---------+
    |      |         |         | ------> |         |   
    | UA X | ------> | Proxy A |         | Proxy B |
    |      |         |         | ------> |         |
    +------+         +---------+   2nd   +---------+
                          ^                   |     
                          |                   |     
                          |                   |     
                          +-------------------+      

I will call the request from UA X to Proxy A, X-A;
the "first" request from Proxy A to Proxy B, A-B;
the request from Proxy B to Proxy A, B-A;
and the "second", already-looped, request from Proxy A to Proxy B, A-B2.

As I understand it [1], it is supposed to be Proxy B that detects
the loop, by attempting to decrypt Vias.  I have big trouble with
this, because if Proxy A is stateful, then any ACK or CANCEL
generated by Proxy A will be ambiguous in that Proxy B will be
unable to determine if the ACK or CANCEL is for request A-B or
request A-B2.

Am I right about this?

Wouldn't it perhaps be better if proxies could detect loops even if
their Via had been hidden?  It seems to me that recommending that the
branch parameter is somehow uniquely identifiable to an instance of an
implementation would enable this; say by recommending that some
portion conforms to the requirements of the "tag" parameter.
Then detecting loops would just require a proxy to search for any
Vias that have branch parameters that look "familiar", and then
performing the usual computation (to avoid flagging spirals as loops).

Now comes my real dilemma. &:)

Say Proxy A isn't clever with branch parameters, and thus does add
another hop, A-B2, to an already-looped request.  Now Proxy B can
detect the loop.  However, if Proxy B is stateful, should it attempt
to detect the loop?  To Proxy B, this request A-B2 is going to look
like a retransmission of A-B based on the To, From, Call-ID, CSeq,
Request-URI, and topmost-Via...but there are other Vias present.

I guess what I'm asking is if a stateful proxy should be aggressive
in loop detection, by checking every single request it sees, or just
for "new" requests (i.e., when To, From, Call-ID, CSeq, Request-URI,
topmost-Via tuple match no others).

My gut feeling is that it should only check for "new" requests,
because dragons be elsewhere.  For instance, if Proxy B responds
with a 482, and Proxy A ACKs, then the ACK is not going to be
distinguishable; unless Proxy B puts some special tag in the To
header, I guess.

The real shame is that CANCELs are completely indistinguishable
(okay, save the case that Proxy A is stateless), which is just plain
unfair if Proxy B happened to fork to other places besides Proxy A.
(I would note that "aggressive" loop detection by Proxy B here would
help in that if it returns the 482 "quickly", it's less likely to
see a CANCEL for A-B2; i.e., if a CANCEL arrives, it's more likely
to be for A-B.)

One other point that springs to mind: if it were recommended that
branch parameters were unique, period, would that help to alleviate
this problem?  (I currently read 6.46.6 as requiring them just to
be unique within the space of one request.)

Thoughts?

Cheers,

 - Jo.

[1] Paragraph 4 of Section 6.25 in bis-01:
  A server that is capable of hiding Via headers MUST attempt to
  decrypt all Via headers marked as "hidden" to perform loop detection.
  Servers that are not capable of hiding can ignore hidden Via fields
  in their loop detection algorithm.
-- 
  Jo Hornsby; IT Professional         --       mailto:[email-masked]
 Ubiquity Software Corporation        --         http://www.ubiquity.net/

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Shail Bhatnagar <[email-masked]>
Date: Tue, 22 Aug 2000 18:19:33 -0400

Jo, I have a fundamental disagreement here so have not read your 
entire email. See my embedded question. 

Thanks,
Shail

>     +------+         +---------+   1st   +---------+

I thought that if proxy B is stateful, request A-B2 will hash to 
the same transaction control block as the request A-B since the
4 tuple (Call-ID, From, To and CSeq) has not changed. Correct ??

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 24 Aug 2000 12:14:38 +0100

> entire email. See my embedded question.

You probably should have. &:)

> 4 tuple (Call-ID, From, To and CSeq) has not changed. Correct ??

Yes, these requests are identical based on the isomorphism rules
(should really also be considering Request-URI and topmost-Via).
I was alluding to this with my observation that ACKs/CANCELs are
problematic; and in any case, I explicitly addressed the point
later on (where I talked about "aggressive" loop detection).

This isn't a helpful observation since, as I understand it, this
is how loops are supposed to be detected when Via hiding is
employed.  That is why I'm arguing against. &:)

Cheers,

 - Jo.