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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 16:51:32 -0500

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Dec 2001 12:10:11 -0500

There were no further comments on the proposal itself. I am considering 
the issue closed, with the proposed resolution below accepted.

-Jonathan R.

Jonathan Rosenberg wrote:

>>> 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.
>>
>>