Subject: Re: [SIP] transaction identification

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 02:21:15 -0400

Neil Deason wrote:
> 
> > You might want to consider the case below though:
> >
> > ***************************************************************************
> >
> >                      ---------> u1@p2  ---> ub1@cb1
> >                      |
> >   ua@ca  ------> u@p ---------> u2@p2  ---> ub2@cb2
> >
> >
> > ca sends an INVITE to u@p, which forks the request to
> > different users. As it turns out, both ub1@cb1 and ub2@cb2 sends
> > a 200 OK and "p" happens to be able to forward multiple 200 OK's.
> > ca is an implementation that could actually ACK both of the 200 OK's
> > and setup and represent parallell media sessions towards both cb1
> > and cb2 for the single SIP session.
> >
> > Imagine "p" implementing some service or controlling a
> > firewall or media proxy for example. "p" would then have to
> > keep the different "sub-sessions" apart, because, cb1 & cb2
> > could hang up at different occasions.
> >
> > Consider "p" and "p2" to be Record-Routing.
> >
> > When cb2 hangs up it would appear in "p" as:
> >
> > BYE ua@ca, Route ua@ca
> >
> > and when cb1 hangs up it would appear in the proxy as:
> >
> > BYE ua@ca, Route ua@ca
> >
> > How should "p" be able to determine which "sub-session" the BYE
> > is for?
> 
> >From p's point of view the topmost Via would be different
> thus identifying the two possible BYEs as non isomorphic
> requests. Also in this example a tag in the From
> differentiates the call legs if the proxy needs to be
> call stateful for some specialised service.

Correct; the tag differentiates. 

Jo previously wrote:

> > I am missing something here; why does this eliminate loop detection?
> 
> It doesn't eliminate Loop Detection, but it means that you don't
> need to waste time decrypting Vias to check for loops.
> 
> Previously, I was concerned that this was a bogus approach, since
> if you attempt to detect Loops by decrypting Vias, any ACKs or
> CANCELs relating to this request would be ambiguous (would they be
> for the "first" time you "saw" the request, or for the "second"?).
> This is because there was no guarantee that the branch parameter
> would be different in each case.
> 
> Requiring that the branch parameter is always unique alleviates
> this problem; however, since you suggest adding some other
> invariant, it now becomes possible for a proxy to identify its
> "own" branch parameters.  Thus decrypting Vias for the sole
> purpose of checking for Loops becomes rendundant.
> 

I think you are saying that if the branch ID contains a component that
can identify the server itself, the server can find Via headers it
inserted?

So, let me try to summarize:

1. a request is matched to a transaction ID through a hash of (request
URI, To, From, Call-ID, CSeq, topmost Via), where the hash is done over
"canonical" representations of these (ie, you don't want insertion of a
white space to screw it up). The ACK and CANCEL use the same thing in a
PROXY (note this doesn't work for ACK in a UAS since the ACK can take a
different path entirely. One of the nasty things I really don't like).
So, for a UAS, you have two keys - one with the topmost Via, one
without. If there is no match on the key with the via for the ACK, you
try the one without.

2. the branch ID, in addition to the two components mentioned in the bis
draft, also now contains a third piece, which is sufficient extra info
to make the branch ID unique across all transactions as defined in 1.
Note that this uniqueness piece must be separable -i.e., you can't
include it in the hash of the incoming R-URI, TO, From,CSeq, Call-ID
defined in bis. Otherwise, you can't detect spirals. This could be the
transaction ID + server instance.

Does that sound right?

-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

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

---

From: Hisham Khartabil <[email-masked]>
Date: Fri, 01 Sep 2000 09:51:35 +0300

> without. If there is no match on the key with the via for the ACK, you

The way we get around getting a spiraled request with whitespaces added it by
calculating the hash of the parsed form of the headers forming a sting without the
spaces (eg: user+host+port+tag+... of To plus cseqnum+method ... and so on, ie
eliminating the spaces).  how does that sound

> transaction ID + server instance.

Would this be just for the encrypted via headers only?

Regards,
Hisham

---

From: Loita Jahnsson <[email-masked]>
Date: Fri, 01 Sep 2000 09:06:32 +0200

Hi,

> [ ... ]

> requests. 

OK, that's fine, what is unclear to me is how the two
calls would be separated.

> Also in this example a tag in the From

I thought all SIP messages through "p" in my example would 
share the same call leg. 

Are you implying that proxy "p" would modify the 
From, add it's own tag and thus have different call
legs in different directions?

Could you please extend your answer?

Thanks,

Best Regards,

   Loita Jahnsson
   SIP SW Designer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 03:09:46 -0400

> eliminating the spaces).  how does that sound

Fine. Same as canonicalization. 

> Would this be just for the encrypted via headers only?

Well, nearly as I can tell it would only be needed if there is Via
hiding being done. 

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 03:12:36 -0400

> I thought all SIP messages through "p" in my example would

No; call legs have nothing to do with proxies.

ub1@cb1 will insert a tag into the To field into the 200 OK. So will
ub2@cb2, but these tags are both different. When ub1 hangs up, it places
its tag in its From field, and ub2@cb2 places its tag in the BYE. Thus,
the two BYEs differ in the From field, and thus will appear to u to be
different transactions.

-Jonathan R.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 1 Sep 2000 10:21:49 +0100

> can identify the server itself, the server can find Via headers it

Yes -- very much so.

> without. If there is no match on the key with the via for the ACK, you

Yup.  I might to be inclined to s/hash/combination/g, however, to
not restrict the implementation?

> transaction ID + server instance.

Sounds good to me.

Cheers,

 - Jo.

---

From: Loita Jahnsson <[email-masked]>
Date: Fri, 01 Sep 2000 11:58:41 +0200

Hi,

> the two BYEs differ in the From field, and thus will appear to u to be

Thanks for your quick response,

I still feel a bit lost however.

I appreciate the possibility to separate the BYE transactions
in "p".

The things I don't quite understand is:

(i)
When ub1@cb1 & ub2@cb2 hangs up, I thought they didn't
necessarily have to insert tags the From field. When I
read in the spec I only find this about the From tag:
"It MUST be present when it is possible that two instances
of a user sharing a SIP address can make call invitations
with the same call-ID". How does that apply to ub1@cb1
and ub2@cb2 in the above scenario?

(ii)
Imagine proxy "p" implementing a service or doing something
like controlling a firewall for example. To be able to
do this it needs to be call stateful in some respect.

Right now I could only visualize two ways of achieving
call statefullness in "p"; (a) either you add the "call
state information" as parameters as you proxy the messages
and pray that the client in the other end doesn't remove
that data when sending responses, generating new requests
or whatever. Or (b) actually keeping "call state" for
each call within the proxy.

If you prefer (b), you need some way of identifying
the different calls (not only transactions). As I would
have imagined this would be call leg + possibly some
other information.

Now I am trying to apply the "call leg has nothing to do
with proxies" statement for a "(b)" proxy implementation.
And that's where I get lost.

Could you please explain some more?

Thanks,

Best Regards,

   Loita Jahnsson
   SIP SW Designer

---

From: Neil Deason <[email-masked]>
Date: Fri, 01 Sep 2000 10:59:48 +0100

> Hisham Khartabil wrote:
[...]
> Well, nearly as I can tell it would only be needed if there is Via

Correct. The branch param is not one of the encrypted 
components when Via hiding is performed. This means
that if we make the branch param globally unique there
is no longer a requirement on Proxies to try and decrypt
all Via headers marked as hidden to perform loop detection. 
A proxy can just just recognise it's own globally unique 
branch param within any hidden Vias.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 1 Sep 2000 11:22:36 +0100

> and ub2@cb2 in the above scenario?

This text applies to the initial INVITE [0].  To see how
the tag plays a role in BYEs (and re-INVITEs, and whatever),
have a look at section 11.4:
   For the desired call leg, the To header field is
   set to the remote address, and the From header
   field is set to the local address (both including
   any tags).

> each call within the proxy.

(a) is not going to work without some sort of extension
(okay, ignoring putting bizarre parameters into Record-Route
Request-URIs).

> And that's where I get lost.

I think the point is that call leg is defined by the endpoints
involved, and thus irrelevant to the proxy -- it just does its
normal transaction processing.  However, the proxy is free to
maintain state on call legs as it chooses -- in general, this
is probably going to be invisible to any of the endpoints
involved in the call.

HTH,

 - Jo.

[0] I noticed that From tags were one of the "Open Issues".
    Has there been any resolution to this?

---

From: Loita Jahnsson <[email-masked]>
Date: Fri, 01 Sep 2000 14:12:03 +0200

Hi,

>    field is set to the local address (both including

Thanks, that was the part of information that I needed
to be pointed out.

Now I understand both Neils and Jonathans previous
answers:

> call stateful for some specialised service.

Given that, I think the following solution would work beautifully:

> transaction ID + server instance.

Thanks again,

Best Regards,

   Loita Jahnsson
   SIP SW Designer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 22:31:31 -0400

> branch param within any hidden Vias.

It might be worthwhile to take a step back and examine whether or not
this kind of fix (just needed for via hiding) can rather be addressed by
ditching via hiding and doing something else entirely. I don't think its
widely implemented, and there are definintely issues with the security
model (the next hop provides the feature for you).

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 02 Sep 2000 22:21:39 -0400

> model (the next hop provides the feature for you).

This is only one of the problems. With hindsight, my other concerns
about Via hiding:

- complexity, particularly hidden "gotchas" that surface at various
points (as in this instance);

- interference with loop detection and debugging;

- over-promise: unlike HTTP, where via-hiding makes some sense since all
data is in one place, Via-hiding in SIP by itself does nothing to hide
the caller. (I'm having a hard time thinking of applications where
hiding the caller doesn't matter, but where hiding a proxy does.)
There's all kind of other information leakage:

  - Contact
  - Route/Record-Route
  - SDP (various places, including o=, c=)
  - possibly accidental leakage in User-Agent header and Call-ID,
depending on how they're generated

Also, unless this is implemented everywhere, the feature is not likely
to be very useful, without the sender having any recourse such as "don't
route this request unless you can hide". I would guess that almost all
existing proxies simply ignore the Hide header.

Thus, there is a danger of asking for via-hiding and then deluding
oneself that this indeed provides anonymity.

I think we should welcome opportunities to simplify the spec by removing
marginally useful features.

For real anonymity, a back-to-back UA (that creates a "fresh" SDP entry
and otherwise scrubs the request of identifying information) seems about
the only viable approach.

Email has existed for many years without this feature, with "mixers" for
anonymity.

If this is truly needed, I would argue that this should be an extension
specified separately, with a Proxy-Require header.

Henning

---

From: Loita Jahnsson <[email-masked]>
Date: Mon, 04 Sep 2000 09:33:31 +0200

Hi,

> model (the next hop provides the feature for you).

Ditching via hiding sounds fair enough to me :)

If skipping the branch-id, you might want  to consider this 
(theoretical) case (or variations of it):

client-a  --->  proxy-1  --->  proxy-2

                proxy-1  <---  proxy-2

                proxy-1  --->  proxy-2

client-b  <---  proxy-1  <---  proxy-2

Consider proxy-1 and proxy-2 to be record-routing.

When client-b issues it's BYE it will imply a request-URI of
"user-a@client-a" throughout the proxy-chain.

If only looking at request-URI, cseq, to, from, call-id, and top-most
via I guess there would be no way for the proxies to separate
the transactions if they would like to.

If it should be possible for the proxies to separate the transactions
in cases like this (or variations of it) you might want to consider
some alternative solution, if skipping the branch-ID.

Best Regards,

   Loita Jahnsson
   SIP SW Designer

---

From: Neil Deason <[email-masked]>
Date: Mon, 04 Sep 2000 08:22:20 +0100

[...]
> model (the next hop provides the feature for you).

This possible fix was not introduced just for Via hiding.
The original discussion was about request retransmissions
on reverse spirals when record routing is in operation.

  A -INV-> P1 -INV-> P2 -INV-> P1 -INV-> B

A is originating UA, B is receiving UA, P1 & P2 are proxies 
that Record-Route. B now sends a BYE. When the P2-P1 "portion" 
of the BYE reaches P1, how will it distinguish that request 
from the initial B-P1 as the spec stands? So the idea was to 
change the definition of isomorphic requests to include a 
globally unique branch param. 

This also helped solve a problem with Via hiding. That said 
I am no fan of Via hiding and would welcome us dropping the 
whole thing. 

However, making the branch param unique is still a 
fix for the original problem. I note that it also helps 
improve general robustness. A proxy which detects a loop 
down the chain from where it actually happened, can 
use it to differentiate ACKs/CANCELs for the 1st/2nd 
time it saw the request. Of course this shouldn't happen 
unless a broken implementation up the chain failed to detect 
the loop itself.

Cheers,
Neil.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 04 Sep 2000 12:17:16 +0300

I thought this third part of the branch id is used for a proxy to id itself,
and I'm assuming it would be the same everytime. So, how does that make it
unique when it comes to identifying a transaction?

Here is my suggestion:

The calculated branch (the hash part) the came with the INVITE would be stored
as a generic-param in the Record-Route and then copied into route.  The proxy
would then use that to compare the BYE's (this is assuming that the legal loop
detection rules where followed)

what does everyone think?

Regards,
Hisham

---

From: Neil Deason <[email-masked]>
Date: Mon, 04 Sep 2000 10:46:11 +0100

> unique when it comes to identifying a transaction?

No. The new proposed third piece would be used to make the 
the branch ID globally unique.

> what does everyone think?

Not backwards compatible. Only maddr parameters are copied
from the Record-Route into the Route.

Cheers,
Neil.

---

From: Bertil Engelholm <[email-masked]>
Date: Mon, 04 Sep 2000 11:01:53 +0200

> marginally useful features.

This was exactly what I suggested a few weeks ago. I'm glad that you
also agree that we should try and remove "unnecessary" things from 
the specification. The things I beleave is marginally useful features 
which could be removed is :

* The compact form.
* The comma separated lists.
* Line folding.

There are also a number of other things I would like to remove
from the protocol which does not add any functionality what so
ever to the protocol. I.E :

* The possibility to add extra spaces basically whereever you like.
* The possibility to use upper and lower case as you like.

These things are not that important to remove but since I beleave
they only add unnecessary complexity without any gain at all I
would prefer having them removed. 

/Bertil

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Sep 2000 13:44:16 -0400

Neil Deason wrote:

> globally unique branch param.

Added to the spec. The definition of the second branch parameter was
always pretty vague, including "a sequence number", which presumably
would do as long as the count is across all transactions.

> I am no fan of Via hiding and would welcome us dropping the

Unless there's loud protest, it will vanish soon, so speak up if you're
fond of Via hiding.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Sep 2000 23:40:55 -0400

> would do as long as the count is across all transactions.

Just to be clear here; the discussion to date of having a third
component that is globally unique is going to be folded into the second
component. That component was used for the actual "branch"
identification - if a proxy forks, and the response comes, for which
forked request is the response? So, a globally unique ID will be used
here instead of a simple sequence number that resets for each
transaction.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Sep 2000 23:44:20 -0400

> from the Record-Route into the Route.

maddr is a URI parameter. All URI parameters should be copied, not just
those. 

As for record-route parameters, rfc2543 says:

> The calling user agent client copies the Record-Route header into a
>    Route header field of subsequent requests within the same call leg,
>    reversing the order of requests, so that the first entry is closest
>    to the user agent client. 

to me, this would indicate that this includes record-route header
parameters as well.

That aside, this isn't backwards compatible because the UAs don't copy
Via parameters into the route headers.

-Jonathan R.

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 05 Sep 2000 08:23:27 +0300

I apologise if I didn't make myself clear.

The suggestion was for the proxy itself to put a copy of the calculated branch into
the record-route, not the UA.  The UA copies the record-route into route, the branch
is copied in the process.

---

From: Neil Deason <[email-masked]>
Date: Tue, 05 Sep 2000 09:54:57 +0100

> maddr is a URI parameter. All URI parameters should be copied, not just

What you copy from Record-Route into Route depends on whether 
the UA finds the Record-Route in a request or a response. 
If it is in a response then it copies the Record-Route into
Route header fields. If it finds it in a request it only copies 
the maddr param and any port [bis-01]. The remainder of the 
Route name-addr value being taken from the originating
name-addr value, i.e. the Contact or From header.

> to me, this would indicate that this includes record-route header

bis-01 says:
   If a UAC finds a Record-Route header in a response, it copies
it into
   Route header fields of all subsequent requests within the same
call
   leg, reversing the order of fields, so that the first entry is
the
   server closest to the UAC.
   ...
   If a UA finds a Record-Route header in a request received as a
UAS,
   it copies the Record-Route maddr parameters and any port
value,
   maintaining their ordering, to the Route header field of
future
   requests issued as a UAC.
	
> Via parameters into the route headers.

The suggestion was that a Via branch hash also be stored
as a generic param in the Record-Route. Unfortunately generic
params do not make it from the Record-Route into the Route.
(Remember the discussion about state pushing through Route)

Cheers,
Neil

---

From: Neil Deason <[email-masked]>
Date: Tue, 05 Sep 2000 10:10:02 +0100

> is copied in the process.

Generic params added to a Record-Route by the Proxy are 
not subsequently returned in the Route. We have been there 
before see the slide 'State pushing through Route'
in Jonathan's open issues presentation from the 48th
IETF meeting.

However, in this case unless there is a problem with making 
the branch ID globally unique to solve the original 
problem this probably isn't worth getting too excited about.

Cheers,
Neil

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2000 08:25:42 -0400

> here instead of a simple sequence number that resets for each

Yes, the second parameter is now defined to be a globally unique
identifier. Strictly speaking, it only has to be unique within a server,
but it seems that we've learned along the way that if in doubt, globally
unique is safest. This is strictly a local matter, so any changes are
just affecting local operation, not interoperation.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Sep 2000 10:15:21 -0400

> name-addr value, i.e. the Contact or From header.

Well, the name-addr is part of the URI. The question is: what about
Record-Route parameters? Seems like these should be copied. The spec
should be clarified in that regard.

> (Remember the discussion about state pushing through Route)

I agree that this idea of mingling Via and Record-Route is not a good
path to follow. Seems like we have arrived already at the ideal solution
- usage of the sequence number component of the branch ID. That aside,
as a separate note, its worth noting the following:

> in Jonathan's open issues presentation from the 48th

This is true; a proxy won't get back any Record-Route parameters it
inserts. But, URI parameters will get returned through the request URI.
Implementations of a UAC should be sure to copy the entire URI from the
Record-Routes in the response, into Route in subsequent requests.
Similarly, All URI params in the Contact header in the request
(excepting maddr and port of course), should be copied into Routes used
by the UAS.

-Jonathan R.

---

From: Neil Deason <[email-masked]>
Date: Tue, 05 Sep 2000 16:52:31 +0100

> should be clarified in that regard.

I am not sure I follow you. Are you proposing that generic 
Record-Route params are copied into Route? This wouldn't 
help as any salient parameters would be lost when the preceding
Server pops the Route into the Request URI. The spec is already 
clear about what is copied from where in constructing Route
when it comes to URI params. But this has it's own problems
if you are banking on getting any params back from there.
Which URI would you expect to get it back from as it differs
depending whether the caller or callee sends the request.

[...]

> (excepting maddr and port of course), should be copied into Routes used

But from where exactly will a Proxy will get a URI params back? 
Are you saying it should insert any param it wants back into 
the URI in the Contact, as well as the Record-Route, in case 
it comes back from a UAS. I would argue that a Proxy should 
leave the URIs well alone.

For example in state pushing case the idea of a new header 
would be preferable providing sufficient justification for it's 
introduction is made.

Cheers,
Neil.

---

From: [email-masked]
Date: 5 Sep 2000 20:02:21 -0000

Quoting Henning Schulzrinne <[email-masked]>:

>
> Unless there\'s loud protest, it will vanish soon, so speak up if 
you\'re
> fond of Via hiding.

I should start by saying I am not fond of Via hiding. It will make me 
happy if is goes away.

However, I see an overall problem in SIP+SDP as being leaking
internal network topololgy information. Firewalls go out
of the way to hide this kind of information, which SIP is giving
away.

I think a narrow scope of attempting to hide only the topology should 
suffice. Hiding every hop is probably not necessary. Problem areas 
should include \'Contact:\' and SDP.

Shiv