[sr-dev] Contributing platform specific code to Kamailio

Mon Jan 22 15:06:09 CET 2018

Hello Carsten,

I promised to share the code with you. I wanted to push it in a better
shape, but I've got some difficulties, which take me more time than
expected. You can check it here:

https://github.com/tdimitrov/kamailio/tree/ipsec-wip

The code is far from production ready, but my main priority for now is to
make it work with real phone. My issue in nutshell: when the UE sends IPSec
protected REGISTER I can see the message reaching P-CSCF (in wireshark),
but the REGISTER is not delivered to the kamailio process. The ipsec itself
is initialised correctly (at least I see no errors). I think the issue is
that the UDP checksum of the REGISTER is wrong due to a NAT. I see lots of
lines like this in dmesg:

[11782894.569952] UDP: bad checksum. From 192.168.178.61:6177 to
192.168.178.167:5061 ulen 1332

Currently I'm working on a fix for this. I think there is a socket option
to disable UDP checksum validation, but I want to avoid this. If you have
got experience with such issues, any help is highly appreciated :)

Besides this there is some more work on the module, but nothing serious:
- IPSec tunnels are not destroyed on deregister.
- IPSec tunnels are not cleaned up in case of ungraceful kamailio shutdown.
- Logic to allocate unique local IPSec ports to each UE is required.
- Some hardcoded params should be replaced with module config options.

I'll update this thread when I have got any significant progress.

Best regards,
Tsvetomir

On Mon, Dec 11, 2017 at 5:15 PM, Tsvetomir Dimitrov <tsv.dimitrov at gmail.com>
wrote:

> Hi Carsten,
>
> I'm working on this and I have got some progress, but unplanned two week
> sick leave delayed my work a lot. What I have done so far:
> - Fixed saving of security parameters in ims_usrloc_pcscf. My previous
> patch didn't handle SHM allocation correctly. This is can be merged so I'll
> open a pull request soon.
> - New module which handles ipsec tunnel creation. For now the module
> successfully registers SAs and policy via xfrm (no external bash scripts
> involved) on incoming REGISTER.
>
> What needs to be done:
> - Cleanup of ipsec SAs and policy on subscriber detach, PCSCF graceful
> shut down and PCSCF not so graceful shutdown.
> - Module parameters for everything - for now all params are hardcoded.
>
> The code is not very usable at the moment, mainly because there are a lot
> of hardcoded parameters. I can share it if you wish.
>
> Best regards,
> Tsvetomir
>
>
> On Mon, Dec 11, 2017 at 3:25 PM, Carsten Bock <carsten at ng-voice.com>
> wrote:
>
>> Hi Tsvetomir,
>>
>> any updates regarding this? I believe otherwise, I would assign
>> ressources from our side for this in February/March next year.
>> However, I would want to avoid double work.
>>
>> You can share it privately with me, if you don't want to publish it yet.
>>
>> Thanks,
>> Carsten
>>
>> 2017-10-19 9:49 GMT+02:00 Tsvetomir Dimitrov <tsv.dimitrov at gmail.com>:
>> > Hi Carsten,
>> >
>> > Thanks for your responce and please excuse my late reply too. I'm still
>> > working on the changes and will make a pull request as soon as I am
>> ready.
>> > It will be a separate module which handles the IPSec tunnel
>> creation/tear
>> > down, so that ims_register_pcscf won't be polluted with platform
>> specific
>> > functionality. You are right, that new module can be ifdef-ed and
>> replaced
>> > with something *BSD specific or whatever OS someone wants to use.
>> >
>> > Best regards,
>> > Tsvetomir
>> >
>> > On Fri, Oct 13, 2017 at 6:21 AM, Carsten Bock <carsten at ng-voice.com>
>> wrote:
>> >>
>> >> Hi Tsvetomir,
>> >>
>> >> sorry for the late reply. I assume this mail got lost a bit in the
>> >> days of Astricon. I even asked Daniel about this mail during Astricon,
>> >> but he hadn't seen it yet. Right now, I'm officially on holiday....
>> >>
>> >> Can you please provide a Pull-Request for the changes?
>> >>
>> >> From my perspective, it is likely fine to have a Linux-Only module, it
>> >> might not be the first one. If you can encapsulate your extensions
>> >> with some IFDEF's, so the functionality can be disabled on non-Linux,
>> >> then that would be fine with me.
>> >>
>> >> It would be great, if Daniel or anyone else from the Management-Group
>> >> could answer or comment this one as well??
>> >>
>> >> Thanks,
>> >> Carsten
>> >>
>> >> 2017-10-04 10:14 GMT-04:00 Tsvetomir Dimitrov <tsv.dimitrov at gmail.com
>> >:
>> >> > Hello,
>> >> >
>> >> > I am working on a functionality which handles ipsec tunel creation
>> for
>> >> > VoLTE
>> >> > registration and I'd like to contribute it to the project. However
>> the
>> >> > code
>> >> > is heavily Linux specific - uses xfrm framework, so it won't compile
>> on
>> >> > distribution with older kernels and definitely won't compile on *BSD.
>> >> >
>> >> > How problematic is this? How to handle this implementation so that it
>> >> > gets
>> >> > merged?
>> >> >
>> >> > Right now I can see two options:
>> >> > 1. Implement the functionality in ims_register_pcscf.
>> >> > 2. Implement separate ipsec module and handle the tunel creation/tear
>> >> > down
>> >> > from the configuration.
>> >> >
>> >> > The first solution is definitely the easiest one for implementation,
>> but
>> >> > after my patch the module won't be as portable as it is now and I'm
>> >> > afraid
>> >> > my patch will be rejected.
>> >> >
>> >> > The second one separates the platform specific code in separate
>> module
>> >> > and
>> >> > won't affect ims_register_pcscf. However I need data from
>> >> > ims_usrloc_pcscf,
>> >> > which is not accessible from the configuration. Also, writing
>> separate
>> >> > module for a limited IPSEC handling seems like a overkill for me.
>> >> >
>> >> > What's your opinion?
>> >> >
>> >> > Best regards,
>> >> > Tsvetomir
>> >> >
>> >> > _______________________________________________
>> >> > Kamailio (SER) - Development Mailing List
>> >> > sr-dev at lists.kamailio.org
>> >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Carsten Bock
>> >> CEO (Geschäftsführer)
>> >>
>> >> ng-voice GmbH
>> >> Millerntorplatz 1
>> >> 20359 Hamburg / Germany
>> >>
>> >> http://www.ng-voice.com
>> >> mailto:carsten at ng-voice.com
>> >>
>> >> Office +49 40 5247593-40
>> >> Fax +49 40 5247593-99
>> >>
>> >> Sitz der Gesellschaft: Hamburg
>> >> Registergericht: Amtsgericht Hamburg, HRB 120189
>> >> Geschäftsführer: Carsten Bock
>> >> Ust-ID: DE279344284
>> >>
>> >> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>> >> http://www.ng-voice.com/imprint/
>> >>
>> >> _______________________________________________
>> >> Kamailio (SER) - Development Mailing List
>> >> sr-dev at lists.kamailio.org
>> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > Kamailio (SER) - Development Mailing List
>> > sr-dev at lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>> >
>>
>>
>>
>> --
>> Carsten Bock
>> CEO (Geschäftsführer)
>>
>> ng-voice GmbH
>> Millerntorplatz 1
>> 20359 Hamburg / Germany
>>
>> http://www.ng-voice.com
>> mailto:carsten at ng-voice.com
>>
>> Office +49 40 5247593-40
>> Fax +49 40 5247593-99
>>
>> Sitz der Gesellschaft: Hamburg
>> Registergericht: Amtsgericht Hamburg, HRB 120189
>> Geschäftsführer: Carsten Bock
>> Ust-ID: DE279344284
>>
>> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
>> http://www.ng-voice.com/imprint/
>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> sr-dev at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180122/65ad20e5/attachment.html>