Re: [sipcore] draft-kaplan-sip-session-id-02

[Hadriel Kaplan <[e-mail]>]

Hi Dale,
The thing is they're really trying to solve different things, though I know I didn't do a good job explaining it at the last WG meeting. :(

The secure-call-id is trying to provide a real Call-ID value which middleboxes won't change - for middleboxes that change it for the specific purpose of privacy or topology-hiding.  And by that I mean a real Call-ID: useful for dialog matching, the dialog-events package, and any of the things a Call-ID value is used in (there are many, as you know).

People put Call-ID values in all sorts of things, and expect it to work end-to-end, and are "surprised" when something in the middle changed them.  So secure-call-id is trying to provide a Call-ID that won't be changed by those middleboxes.  It *will* still be changed by other B2BUA's, for example many IP-PBX's and App Servers change the Call-ID, and will continue doing so.  It's ok that they do - most of the applications which use Call-ID's are targeted to those IP-PBXs/App-Servers, and they have some other reasons for changing them.

Session-ID is for something different: a session identifier which crosses any form of middlebox including real/full B2BUA's, but is not used for the dialog-matching type things a Call-ID is used for.  When I tried to use it for some of those other things, I got feedback with concern that it was subverting the Call-ID mechanism - if a B2BUA changed the Call-ID then it was unwise of me to try to second-guess it and bypass its replacement.  I agreed with that concern, so Session-ID is for troubleshooting purposes only at this time.

So the two mechanisms are not at odds, nor are they alternatives for the same thing.

A middlebox which replaces Call-ID's *does* know if it's a secure-call-id.  If it has no '@', and no IP Addr/hostname format in it, it's sufficiently benign to not change.

-hadriel

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dale Worley
> 
> The Session-Id has a tremendous advantage over the "secure Call-Id":  In
> a system that is not tightly managed by a central authority, middleboxes
> have no way of knowing whether a UA is generating "secure Call-Ids" or
> not.  So they must replace all Call-Ids, subverting the UAs that are
> generating secure Call-Ids.  But (absent malice on the part of UAs),
> Session-Ids are known to be secure, and middleboxes know not to replace
> them.  So I think we should deprecate draft-kaplan-sip-secure-call-id in
> favor of draft-kaplan-sip-session-id.
> 
> Dale