Subject: [Sip] Note: minor change in transaction ID

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2002 14:51:55 -0500

Folks,

Bis-08 will reflect a minor change in the way transaction matching is
done. The current text in -07 basically uses the combination of the
branch ID and source address/port as a transaction ID. We decided to use
the two, rather than branch ID alone, to help avoid collisions between
branch IDs from different proxies, whether intentionally or maliciously.

Usage of the actual source address has some problems, however:

1. For SCTP, the sender can switch between multiple interfaces when
sending,
2. It is possible that a routing change could alter the choice of the
source interface for sending a request, at a proxy that is running ontop
of a routing process (like gated) which is commonly done.

The use of network addresses from packets as identifiers is, generally
speaking, plagued with such problems, are we are best advised to avoid
them.

SO, instead, the transaction ID will be based on the branch ID and the
value of the sent-by parameter of the top Via. This has similar spacial
uniqueness properties as the source address, but SIP mandates its
consistency throughout a transaction, thus avoiding many of the pitfalls
above.

I also made the branch ID unique in space and time, rather than just
time, as was mandated by -07. The reasons it that the sent-by field
might contain a cluster address, and thus the requests from each proxy
in the cluster would contain the same sent-by value, potentially. I
think this property is very useful and very important.

COmments, questions, as always...

THanks,
Jonathan R.

-- 
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  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: "Jo Hornsby" <[email-masked]>
Date: Mon, 18 Feb 2002 21:04:33 -0000

Jonathan Rosenberg wrote:
> Bis-08 will reflect a minor change in the way transaction matching
> is done. The current text in -07 basically uses the combination of
> the branch ID and source address/port as a transaction ID. We
> decided to use the two, rather than branch ID alone, to help avoid
> collisions between branch IDs from different proxies, whether
> intentionally or maliciously.
>
> sending, 2. It is possible that a routing change could alter the
> choice of the source interface for sending a request, at a proxy
> that is running ontop of a routing process (like gated) which is
> commonly done.
>
> speaking, plagued with such problems, are we are best advised to
> avoid them.
>
> value of the sent-by parameter of the top Via. This has similar
> spacial uniqueness properties as the source address, but SIP
> mandates its consistency throughout a transaction, thus avoiding
> many of the pitfalls above.

Hmmm....

I wonder if it might be worth mentioning that a proxy
may use other [meta]data, too.  For instance, if it
were to key based on branch ID and sent-by and local
port (that the request was received over), for
instance, then it would be impossible for a rogue
proxy to screw-up another proxy's transaction when
using e.g., TCP and TLS, right?

In fact, in such a case, I guess that the sent-by
doesn't even matter.

I'm not sure how of a problem being able to "hide"
requests is; that is, how useful it would be for an
attacker in practice.  However, it doesn't seem too
harmful to allow an extra degree of freedom.

The only problem I can see with such an approach is
with ol' CANCEL and ACK, such that I guess it's
not technically illegal that these could be received
over a different "connection".  But I can't see that
would be difficult to work around.  In any case,
it's perhaps slightly suspicious that an upstream
element would be doing such a thing.

> might contain a cluster address, and thus the requests from each
> proxy in the cluster would contain the same sent-by value,
> potentially. I think this property is very useful and very
> important.

Indeed.  And realistically, it's generally not-a-lot
of effort to move from uniqueintime to
uniqueinspaceandtime.  A prefix of "potato" normally
works, IMHO. &:)

 - Jo.