Subject: [SIP] hiding via field and loop detection

From: [email-masked]
Date: Wed, 19 Jul 2000 18:37:11 -0500

The current definition for via field encryption says that
a client can request a server to encrypt a via header.

However since it is the next server that is going to encrypt
the via header, in case of a loop, the current server cannot
check if it is in the via list.

A---------P1---------P2
                |                 |
                |                 |
                |                 |
               P3---------P4

Say P1 intoduces Hide: route header in the request sent to P2 and
the request loops back to P1. Since the via is encrypted by P2
P1 won't be able to decrypt it and we are unable to detect a loop.

P2 can detect the loop on P1's behalf by seeing P1 twice on the via
list. However the loop detection is meant for own and not for some
other proxy.
-Deepak

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jul 2000 01:19:47 -0400

THis is addressed in the spec. From Section 6.22:

> 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.
> 
> 
>         If hidden headers were not marked, a proxy would have to
>         decrypt all headers to detect loops, just in case one was
>         encrypted, as the Hide: Hop option may have been removed
>         along the way.
> 
>    A host MUST NOT add such a "Hide: hop" header field unless it can
>    guarantee it will only send a request for this destination to the
>    same next hop. The reason for this is that it is possible that the
>    request will loop back through this same hop from a downstream proxy.
>    The loop will be detected by the next hop if the choice of next hop
>    is fixed, but could loop an arbitrary number of times otherwise.

So, the loop is detected by the next hop after the loop. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 20 Jul 2000 11:11:21 +0100

> So, the loop is detected by the next hop after the loop. 
[...]
> >           P3---------P4
[P1 has requested Hide: hop, so cannot detect the loop.]

In this case, how should P2 respond?  In the case of an INVITE,
I think there's a problem, since ACK-based reliability is going
to screw things up.

P2 now has "two" requests: P1P2 and P1P2L (looped).  If P2
responds with a 482, P1 could potentially figure out which
request was being responded to by looking at the Vias; however,
if it now ACKs that response, since the response is generated
locally, there will only be one Via, so P2 cannot determine
whether this ACK is for the INVITE P1P2 or P1P2L.  (This is
similar to the problem with aggressively detecting request-
merging situations at arbitrary points downstream.)

Would the best thing be for P2 just not to respond?  P1 will
then eventually time-out, and return 408, or something.  This
should end up doing (roughly) the Right Thing; there's just
potential for information lossage.

Alternatively, P2 could note the loop, CANCEL the branch spawned
by the P1P2 (first) request and return 482 (for P1P2).  The
problem with this would be if either P3 or P4 had forked, since
the INVITE could still be successful along other routes.

Finally, P2 could respond with 482 in the normal fashion, and
add some special tag to the To header.  In this case, it would
be able to distinguish the ACKs.  The only time it wouldn't be
able to do this would be if the request already had a tag in
the To header, but I guess looping is far less likely on
re-INVITEs.

I note that if P1 ever issues a CANCEL for whatever reason,
P2 has no chance.  Should policy be to go with the most routed
request?  (If the request had forked at other points, this
could be considered desirable.)

This isn't such an issue for non-INVITEs, since there is no
ACK to worry about.  The proxies do still need to examine
Vias to figure out exactly which request they're responding-to/
receiving; and there is still the same problem with CANCEL.

One last point: perhaps it would be an idea that the spec
RECOMMENDED that either proxies add a unique (a la tag) parameter
to their Vias -- "proxy", or something -- or make the branch
parameter of their Vias uniquely recognisable somehow.  Since
the parameters are not encrypted, this would allow a proxy to
recognise a looped request without having to do any sort of
decryption.

Comments?

Cheers,

 - Jo.