Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

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