[SR-Users] Call-ID Uniqueness and safety?

[Mark Boyce]

Hi Alex

The thought process our side was more in these stages;

- What if they’re not unique?

- What would it affect?

- Could it be used as an exploit?

- If not do we care?

… and wondered what others thought about it.


I think you’re/Fred/Daniels points of a simple sanity check on them is probably the simplest/best answer. We can then reject a UA as too broken for us to want to deal with if it fails.

We’ve also added a  $dlg_var(dlg_uuid)=$uuid(g)  just to tie some other state stuff in to

Mark

> On 13 Feb 2020, at 16:35, Alex Balashov <abalashov at evaristesys.com> wrote:
> 
> Also, RTPEngine keys live calls by a combination of Call-ID + available
> tags + optional Via-branch parameter. The odds of forging all of these
> are just astronomically low. 
> 
> If your concern is that an endpoint can overwrite its own recordings or
> whatnot, one should note that an endpoint can store a history of its own
> previously used Call-IDs and other unique identifiers regardless of
> length or the merits of the randomisation algorithm.
> 
> -- Alex
> 
> On Thu, Feb 13, 2020 at 11:21:21AM -0500, Alex Balashov wrote:
> 
>> On Thu, Feb 13, 2020 at 10:59:47AM +0000, Mark Boyce wrote:
>> 
>>> That’s exactly where we ended up. We’ve just added code to assign a
>>> uuid to each new dialog as it’s created. Which when logged via acc
>>> gives us the extra unique reference.
>> 
>> The trouble with that is it requires you to do a lot of gymnastics to
>> keep extra state. Using Call-ID as a key allows you to operate on calls
>> in a way that makes use solely of information contained in the SIP
>> message itself.
>> 
>> In an essentially thermodynamic sense, more state means more complexity,
>> and more fragility due to the inevitable bugs and corner cases that any
>> moving part and synchronisation effort brings. 
>> 
>> Call-IDs are required to be adequate GUIDs by the standard, and are
>> sufficiently unique that the chance of a malicious collision is
>> infinitesimal. Even short, bad GUIDs tend to be quite mathematically
>> unique, unless they're just so comically short as to make a mockery of
>> the GUID requirement. 
>> 
>> I would carefully weigh the economic and technical trade-offs of
>> assigning calls UUIDs on your side and maintaining that mapping. A more
>> pragmatic policy might be to reject requests with a Call-ID that is
>> below a certain string length.
>> 
>> -- Alex
>> 
>> -- 
>> Alex Balashov | Principal | Evariste Systems LLC
>> 
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>> 
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users