Hi Fred 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.
Thanks Mark > On 13 Feb 2020, at 10:51, Fred Posner <[email protected]> wrote: > > Mark, > > There’s a module in Kamailio for uuid which would be generated by kamailio > and may be useful in your needs. You may need the additional step of > correlating the uuid to the call-I’d, but should be better prevention of > injection type issues. > > -- Fred > direct/sms +1 (336) 439-3733 > > >> On Feb 13, 2020, at 4:57 AM, Daniel-Constantin Mierla <[email protected]> >> wrote: >> >> Hello, >> >> there are many things that can go wrong if a bad actor can forge sip >> messages. That's why the call has to be authenticated/authorized in the >> first place (either user/password or some other trusted relationship by >> IP, certificate, ...). >> >> Now if a trusted actor tries to do bad things, then it is harder to >> prevent, but once discovered, the identity is known and it can be >> eventually published in a way or another (by laws and the commercial >> agreement). >> >> Normally, the call-id should be randomly generated, with very low >> chances of overlapping during the same time frame of active call. If >> rtpengine is adding its own random part to file names, then the risk of >> overwriting later is also very low. >> >> The dialog is identified by call-id, from tag (set by caller) and to tag >> (set by callee), so in this case both caller and callee have to be bad >> actors. >> >> But in many cases call-id is used alone as a key. Adding the from tag is >> quite useless, because is set by the same UA, so if it wants to send >> same call-id, can do the same with from tag. Then the to-tag is set by >> the called side and during the call initiations, there can be many >> outgoing branches, so during the 1xx phase there can be a couple of >> to-tags flowing around. So if something needs to be stored in the early >> phase, the to-tag of the to-be-answered call is not yet know. >> >> Rejecting new calls having the same callid as another recent one could >> be safety check to plug if you are really concerned and you don't trust >> completely who is making the call. You can easily use a htable for that, >> to cache used call-ids and block new calls with same value. >> >> Cheers, >> Daniel >> >>> On 13.02.20 10:07, Mark Boyce wrote: >>> Hi all >>> >>> Over coffee we’ve been discussing the uniqueness and safety of call-id this >>> morning. Lots of things like RTPEngine recording use call-id to generate >>> filenames (yes it does escape them first :-). Not to mention dialog >>> tracking (also uses from/to tags) etc. >>> >>> Which got us thinking. As call-id is determined by the first SIP packet >>> that normally comes from a UA, should we care if this UA was broken or >>> worse malicious? >>> >>> What would happen if they were repeated? For example we may struggle to >>> determine a recordings owner in RTPEngine (file name format is >>> callid+random.wav). >>> >>> For security should we be rejecting requests where we’ve seen the call-id >>> before? >>> >>> >>> All theoretical over coffee, as it was that or start working! >>> >>> Just wondering what peoples thoughts were? >>> >>> Cheers >>> Mark >>> _______________________________________________ _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
