Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transaction ID

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Jan 2002 10:53:24 +0200

Hi,

I have nothing against the proposal, but a couple of small issues we
shouldn't forget.

1. Forking. 

The To-tag must still be used to separate responses from different
servers. Nothing strange there, but one should be aware of it.

2. Message merging

Until now, the branch id was used by an UAS to check if a received
INVITE message was a re-transmit of a previous INVITE message, or the
same INVITE but which has taken a DIFFERENT route, since the "old"
transaction identifiers (To, From, Call-ID and CSeq) were the same in
both cases. I guess the "old" identifiers, or at least parts (maybe the
Call-ID and CSeq are enough?) of them, still have to be used for this
purpose, don't they?

Also, since different To tags will be used for the 482 messages(s) the
receiver must check the To tag to be able to separate the responses,
since they will all have the same branch id.

Regards,

Christer Holmberg
Ericsson Finland

Jonathan Rosenberg wrote:
> 
> The rough consensus of IETF 52 was to accept this proposal, but a little
> more detail is needed.
> 
> Mike had pointed out some security vulnerabilities introduced by this;
> namely, a malicious proxy could clobber other peoples transactions by
> using their transaction keys in the via. Of course, it can always do
> that today by inserting their to/from/call-id/via/r-uri, so its not much
> different. However, there was agreement that the server would compute
> the transaction key as a hash of the via branch ID, the source IP/port
> and a private key.
> 
> We also need to clarify that the proxy should construct the branch ID to
> be unique, and document the specific cookie value.
> 
> Any further comments? I feel strongly that we should do this, since it
> will solve a LOT of interop problems that arise with looping and spirals
> and the whole nine yards, which continue to plague us at bakeoffs.
> 
> -Jonathan R.
> 
> Vijay Gurbani wrote:
> 
> > Jonathan Rosenberg wrote:
> >
> >>Issue:
> >>
> > [...]
> >
> >>Bis-05 has taken a big step forward with a rigorous definition of
> >>transaction, which makes it clear that its a single "branch" in the tree
> >>of requests formed when a UAC sends a request through a bunch of proxies.
> >>That is, the To/From/CSeq/Call-ID identify the root of this tree, and the
> >>Via branch + r-uri further identify each branch in the tree. Based on
> >>this, it is natural to take the final step, and define the transaction ID
> >>for a request/response MUCH more simply - it is the value of the branch ID
> >>in the topmost via, with the small caveat that CANCEL has the same branch
> >>ID, but its a different transaction.
> >>
> >
> > Also that ACKs for non-2xx response must have the same branch ID as the
> > INVITE did.
> >
> > [...]
> >
> >
> >>Proposal:
> >>
> >>Allow for branch ID to be the transaction ID, by taking the steps
> >>described above.
> >>
> >
> > Fine.
> >
> > - vijay
> >
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 14:59:36 -0500

> servers. Nothing strange there, but one should be aware of it.

This is orthogonal and unrelated. Usage of tags is for dialog matching
and I believe is well documented in bis-05.

> Call-ID and CSeq are enough?) of them, still have to be used for this

A merged request would appear as a different transaction, with a
different branch ID. If the proxy cares to determine that this is a
merge (generally not necessary), it could look at to/from/call-id/cseq
if it wants, but there is no reason as far as I can tell. Proxies do not
handle merging, only UAs. 

> since they will all have the same branch id.

Huh?? They will most certainly NOT have the same branch ID. When a proxy
forks, each branch has a separate branch ID. For each transaction, there
is a unique transaction ID, and that is the value of the branch ID,
period. It is very simple now. 

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Jan 2002 07:41:49 +0200

Hi,

>if it wants, but there is no reason as far as I can tell.

So, since the INVITE in this case is a DIFFERENT transaction (previously
it was part of the SAME transaction, even if the branch id was
different), should it be treated as a merge in the first place? If it's
treated as a different transaction, isn't there a protocol error, since
it uses the SAME CSeq value as another transaction? So, instead of
checking if the INVITE is a merge, the UAS could simply return 400?

>Proxies do not handle merging, only UAs.

I was talking about UAs.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Jan 2002 01:23:53 -0500

> checking if the INVITE is a merge, the UAS could simply return 400?

Christer, please read bis-05, Section 17.

There is now a clear and concise definition of transaction. It is scoped
between a client and a server transaction in two elements. Each hop
between a pair of stateful proxies is a separate transaction. CSeq is
used as an ordering mechanism of requests between UAs, within the scope
of a dialog. A dialog is identified by Call-iD, to/from. 

Thus, there is no protocol error when a proxy or a UA receives a request
with the same cseq but is a different tnrasaction.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Jan 2002 08:45:02 +0200

Hi,

>with the same cseq but is a different tnrasaction.

So, in THEORY a UAC could now send two or more mid-call INFOs (or
re-INVITEs etc), within a specific dialog, using the SAME CSeq, and the
UAS would not treat it as an error, right?

OR, does the UAS have to know if a received request is a merge (an
initial INVITE, for example), in which case it's not an error using the
same CSeq, or if a received request was sent by the UAC, in which case I
think it IS an error using the same CSeq. Again, in both cases the
requests are received within the same dialog.

I don't want to continue this thread forever, but I just need a
clarification.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 25 Jan 2002 02:26:03 -0500

> So, in THEORY a UAC could now send two or 
> more mid-call INFOs (or re-INVITEs etc), 
> within a specific dialog, using the SAME 
> CSeq, and the UAS would not treat it as 
> an error, right?

If a positive response was returned to the 
first request, a 482 should be returned 
to the other branched request.  If a 
negative response was returned, the UA 
should analyze the request like the other 
branched request was not received.

There are two main reasons to branch within
a dialogue.  
1) Allows a proxy to resubmit a request
   when a UAS or proxy didn't like 
   something the proxy added.
2) Allows a proxy to resubmit a request
   under failure conditions using the
   bis-05 section 24 functionality.