13 Feb
2020
13 Feb
'20
12:20 p.m.
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(a)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:
--
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users