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

Hi Hadriel,

what could be the solution for the case that there is a concatenation of full B2BUAs? E.g. there are several App Servers, and the application is targetting the last App Server in the signalling path or respectively needs to match a certain dialog at this AS. I think even a secure-call-id won't be successfull here?

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan
> Gesendet: Montag, 20. Juli 2009 02:54
> An: Dale Worley; sipcore@ietf.org
> Betreff: Re: [sipcore] draft-kaplan-sip-session-id-02
> 
> 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: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] 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
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 