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

Daniel-Constantin Mierla miconda at gmail.com
Fri Feb 14 12:10:24 CET 2020


Hello,

to add a few more from my past experiences ... I have a couple of
deployments where I check the call-id not to be duplicate in active
transactions because of some other constraints (customer requirements)
specific for the respective services -- for example, not allowing
parallel forking from upstream/caller side.

Sometimes it bites back, because some UAs re-use the call-id after a 302
redirect, although that should be a completely new call. Because of
usual small delays in deleting old records (like being able to catch
retransmissions or route the ACK for 302), this extra check might block
the follow up INVITE after 302 -- I hit this only once with an old PBX
system -- so then you start adding exceptions to the rule.

IMO, the best is to evaluate the risks for your service, what is
impacted, and try to keep everything as simple as possible. Putting a
very complex system in place might cost way more that having a very rare
case happening that you mitigate manually. Keeping backups of data and
files has an important role.

Cheers,
Daniel

On 13.02.20 18:20, Mark Boyce wrote:
> 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
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com




More information about the sr-users mailing list