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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
