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

["Dale Worley" <[e-mail]>]

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