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