Re: [sipcore] draft-kaplan-sip-secure-call-id-00

[Hadriel Kaplan <[e-mail]>]

Hi Dale,
Sorry for not seeing this email last month - I had tuned out the sipcore list because I was getting brain-fried trying to follow the 4424bis discussion. :)

The idea for providing "upgradeability" to have middleboxes stop changing Call-ID's dynamically for security reasons, is to have them in fact inspect the Call-ID value for conformance to the draft: namely that a Call-ID value does not have a '@' token.

Clearly a UAC could still create a Call-ID without the '@' token but still with an IP-Address or hostname embedded in the value, and the current draft recommends that middleboxes which replace the Call-ID for security reasons should inspect it for such as well, regardless of that token.  

Adding a "+)puK>" identifier does not avoid that having to happen.  A security-paranoid middlebox would inspect the value regardless of whether the Call-ID starts with "+)puK>" or not.  So adding it doesn't obviate the need.

So in your example of Acme SBC's, the SBC's would need to be upgraded to support the draft, and detect legacy vs. draft-complaint Call-ID's by looking for the '@' token (and hostname/ip-address), on a per-out-of-dialog-request basis. 

Furthermore, there are UAC's which already generate Call-ID's compliant to the current draft, so I wanted to support them as is, without penalizing them to have to change.

-hadriel

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dale Worley
> Sent: Wednesday, June 24, 2009 5:19 PM
> To: SIPCORE
> Subject: [sipcore] draft-kaplan-sip-secure-call-id-00
> 
> The difficulty with draft-kaplan-sip-secure-call-id-00 is that it
> provides no mechanism for a B2BUA or other device to switch from
> Call-Id-obscuring to Call-Id-preserving behavior, even when the SIP
> elements involved are trying to cooperate.
> 
> For example, suppose I'm a SIP network provider with Acme Packet SBCs at
> the boundary of my network.  Currently, the SBCs obscure Call-Ids for
> reasons of commercial secrecy.  If I replace some or all of the UAs in
> the network with ones that generate Call-Ids according to the draft,
> nothing happens -- there's no way for the SBCs to detect that the
> Call-IDs conform to the draft, and change their behavior.  My only
> option is to update *all* the UAs, then reconfigure the SBCs to not
> obscure Call-Ids.  This is probably unworkable even in enterprise PBX
> systems, much less walled-garden service provider networks -- and yet we
> want the mechanism to work in open and nearly-open SIP networks.
> 
> What the draft needs is not the current "negative criterion" that
> enables B2BUAs to detect Call-Ids that definitely do not conform to the
> draft, but a "positive criterion" that enables B2BUAs to detect Call-Ids
> that *do* conform to the draft.
> 
> We did this sort of thing before, with the "magic cookie" z9hG4bK in the
> branch value to distinguish RFC 3261 from RFC 2453 messages.  So let us
> define the "new" Call-Id format to be:
> 
>     callid  =  "+)puK>" 22*( %x41-5A     ; "A"-"Z"
>                            / %x61-7A     ; "a"-"z"
>                            / %x30-39     ; "0"-"9"
>                            / "_"
>                            / "."
>                            / "!" )
> 
> That provides 132 bits of randomness in 28 characters, and most likely a
> string of that format has never existed in the history of the world.  So
> when a B2BUA sees a Call-Id of that format, it can trust that the value
> was generated properly and can avoid changing it.
> 
> Dale
> 
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore