Hadriel Kaplan wrote:
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
[EMAIL PROTECTED] wrote:
In regard to adding a Session-Id to requests are not given one by the
UAC:
Specifically, *subsequent* requests in the same dialog won't carry the
same value, at least until the node that inserted the value is reached,
if it is reached. And even then the same value won't be inserted unless
the inserting node is dialog stateful. That argues for only having
dialog stateful elements insert the header.
Although the draft mentions a UUID as one option, it leaves the mechanism to be
decided. One thing we could do instead of UUID, for example, would be to make
it a hash of the received call-id and local system/node ID and MAC or some
such. In other words take some non-volatile system data munged with the
call-id, and hash it to get the 128 bits of output for the Session-ID header
value. That way a stateless proxy can re-generate the same value again for
upstream and downstream requests and responses, without it compromising or
being re-create-able just from the call-id value and giving a reason for folks
to remove it.
But I'll have to ask some security folks about that.
Well, if there is already enough unchanging info that survives middle
boxes, then we don't need the header - we can just tell everybody to use
that.
Or, if you mean it is a hash of info that will then get munged, the
header needs to be inserted by some box before the munging happens. And
it still has the property that it is then only usable by those who are
downstream.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
