From: Hadriel Kaplan <[email protected]>
Although the draft mentions a UUID as one option, it leaves the
mechanism to be decided.
In that regard, the draft is somewhat self-contradictory. In one
place it mentions UUIDs and in another place, it specifies the
Session-Id as a crypto-random quantity. But some UUID formats contain
the MAC address of the creator thereof, which violates the stated
security considerations.
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.
You'll have to include in the hash a secret local key. Otherwise an
adversary can check a guessed correspondence between a Call-Id and a
Session-Id.
Dale
_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.