<div dir="ltr">Hello Carsten,<div><br></div><div>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: </div><div><br></div><div><a href="https://github.com/tdimitrov/kamailio/tree/ipsec-wip">https://github.com/tdimitrov/kamailio/tree/ipsec-wip</a></div><div><br></div><div>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:</div><div><br></div><div><div>[11782894.569952] UDP: bad checksum. From <a href="http://192.168.178.61:6177">192.168.178.61:6177</a> to <a href="http://192.168.178.167:5061">192.168.178.167:5061</a> ulen 1332</div></div><div><br></div><div>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 :)</div><div><br></div><div>Besides this there is some more work on the module, but nothing serious:</div><div>- IPSec tunnels are not destroyed on deregister.</div><div>- IPSec tunnels are not cleaned up in case of ungraceful kamailio shutdown.</div><div>- Logic to allocate unique local IPSec ports to each UE is required.</div><div>- Some hardcoded params should be replaced with module config options.</div><div><br></div><div>I'll update this thread when I have got any significant progress.</div><div><br></div><div>Best regards,</div><div>Tsvetomir</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 11, 2017 at 5:15 PM, Tsvetomir Dimitrov <span dir="ltr"><<a href="mailto:tsv.dimitrov@gmail.com" target="_blank">tsv.dimitrov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Carsten,<div><br></div><div>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:</div><div>- 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.</div><div>- 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.</div><div><br></div><div>What needs to be done:</div><div>- Cleanup of ipsec SAs and policy on subscriber detach, PCSCF graceful shut down and PCSCF not so graceful shutdown.</div><div>- Module parameters for everything - for now all params are hardcoded.</div><div><br></div><div>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.</div><div><br></div><div>Best regards,</div><div>Tsvetomir</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 11, 2017 at 3:25 PM, Carsten Bock <span dir="ltr"><<a href="mailto:carsten@ng-voice.com" target="_blank">carsten@ng-voice.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Tsvetomir,<br>
<br>
any updates regarding this? I believe otherwise, I would assign<br>
ressources from our side for this in February/March next year.<br>
However, I would want to avoid double work.<br>
<br>
You can share it privately with me, if you don't want to publish it yet.<br>
<br>
Thanks,<br>
Carsten<br>
<div class="m_306894233221812261HOEnZb"><div class="m_306894233221812261h5"><br>
2017-10-19 9:49 GMT+02:00 Tsvetomir Dimitrov <<a href="mailto:tsv.dimitrov@gmail.com" target="_blank">tsv.dimitrov@gmail.com</a>>:<br>
> Hi Carsten,<br>
><br>
> Thanks for your responce and please excuse my late reply too. I'm still<br>
> working on the changes and will make a pull request as soon as I am ready.<br>
> It will be a separate module which handles the IPSec tunnel creation/tear<br>
> down, so that ims_register_pcscf won't be polluted with platform specific<br>
> functionality. You are right, that new module can be ifdef-ed and replaced<br>
> with something *BSD specific or whatever OS someone wants to use.<br>
><br>
> Best regards,<br>
> Tsvetomir<br>
><br>
> On Fri, Oct 13, 2017 at 6:21 AM, Carsten Bock <<a href="mailto:carsten@ng-voice.com" target="_blank">carsten@ng-voice.com</a>> wrote:<br>
>><br>
>> Hi Tsvetomir,<br>
>><br>
>> sorry for the late reply. I assume this mail got lost a bit in the<br>
>> days of Astricon. I even asked Daniel about this mail during Astricon,<br>
>> but he hadn't seen it yet. Right now, I'm officially on holiday....<br>
>><br>
>> Can you please provide a Pull-Request for the changes?<br>
>><br>
>> From my perspective, it is likely fine to have a Linux-Only module, it<br>
>> might not be the first one. If you can encapsulate your extensions<br>
>> with some IFDEF's, so the functionality can be disabled on non-Linux,<br>
>> then that would be fine with me.<br>
>><br>
>> It would be great, if Daniel or anyone else from the Management-Group<br>
>> could answer or comment this one as well??<br>
>><br>
>> Thanks,<br>
>> Carsten<br>
>><br>
>> 2017-10-04 10:14 GMT-04:00 Tsvetomir Dimitrov <<a href="mailto:tsv.dimitrov@gmail.com" target="_blank">tsv.dimitrov@gmail.com</a>>:<br>
>> > Hello,<br>
>> ><br>
>> > I am working on a functionality which handles ipsec tunel creation for<br>
>> > VoLTE<br>
>> > registration and I'd like to contribute it to the project. However the<br>
>> > code<br>
>> > is heavily Linux specific - uses xfrm framework, so it won't compile on<br>
>> > distribution with older kernels and definitely won't compile on *BSD.<br>
>> ><br>
>> > How problematic is this? How to handle this implementation so that it<br>
>> > gets<br>
>> > merged?<br>
>> ><br>
>> > Right now I can see two options:<br>
>> > 1. Implement the functionality in ims_register_pcscf.<br>
>> > 2. Implement separate ipsec module and handle the tunel creation/tear<br>
>> > down<br>
>> > from the configuration.<br>
>> ><br>
>> > The first solution is definitely the easiest one for implementation, but<br>
>> > after my patch the module won't be as portable as it is now and I'm<br>
>> > afraid<br>
>> > my patch will be rejected.<br>
>> ><br>
>> > The second one separates the platform specific code in separate module<br>
>> > and<br>
>> > won't affect ims_register_pcscf. However I need data from<br>
>> > ims_usrloc_pcscf,<br>
>> > which is not accessible from the configuration. Also, writing separate<br>
>> > module for a limited IPSEC handling seems like a overkill for me.<br>
>> ><br>
>> > What's your opinion?<br>
>> ><br>
>> > Best regards,<br>
>> > Tsvetomir<br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > Kamailio (SER) - Development Mailing List<br>
>> > <a href="mailto:sr-dev@lists.kamailio.org" target="_blank">sr-dev@lists.kamailio.org</a><br>
>> > <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Carsten Bock<br>
>> CEO (Geschäftsführer)<br>
>><br>
>> ng-voice GmbH<br>
>> Millerntorplatz 1<br>
>> 20359 Hamburg / Germany<br>
>><br>
>> <a href="http://www.ng-voice.com" rel="noreferrer" target="_blank">http://www.ng-voice.com</a><br>
>> mailto:<a href="mailto:carsten@ng-voice.com" target="_blank">carsten@ng-voice.com</a><br>
>><br>
>> Office <a href="tel:%2B49%2040%205247593-40" value="+4940524759340" target="_blank">+49 40 5247593-40</a><br>
>> Fax <a href="tel:%2B49%2040%205247593-99" value="+4940524759399" target="_blank">+49 40 5247593-99</a><br>
>><br>
>> Sitz der Gesellschaft: Hamburg<br>
>> Registergericht: Amtsgericht Hamburg, HRB 120189<br>
>> Geschäftsführer: Carsten Bock<br>
>> Ust-ID: DE279344284<br>
>><br>
>> Hier finden Sie unsere handelsrechtlichen Pflichtangaben:<br>
>> <a href="http://www.ng-voice.com/imprint/" rel="noreferrer" target="_blank">http://www.ng-voice.com/imprin<wbr>t/</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Kamailio (SER) - Development Mailing List<br>
>> <a href="mailto:sr-dev@lists.kamailio.org" target="_blank">sr-dev@lists.kamailio.org</a><br>
>> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-dev</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Kamailio (SER) - Development Mailing List<br>
> <a href="mailto:sr-dev@lists.kamailio.org" target="_blank">sr-dev@lists.kamailio.org</a><br>
> <a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Carsten Bock<br>
CEO (Geschäftsführer)<br>
<br>
ng-voice GmbH<br>
Millerntorplatz 1<br>
20359 Hamburg / Germany<br>
<br>
<a href="http://www.ng-voice.com" rel="noreferrer" target="_blank">http://www.ng-voice.com</a><br>
mailto:<a href="mailto:carsten@ng-voice.com" target="_blank">carsten@ng-voice.com</a><br>
<br>
Office <a href="tel:%2B49%2040%205247593-40" value="+4940524759340" target="_blank">+49 40 5247593-40</a><br>
Fax <a href="tel:%2B49%2040%205247593-99" value="+4940524759399" target="_blank">+49 40 5247593-99</a><br>
<br>
Sitz der Gesellschaft: Hamburg<br>
Registergericht: Amtsgericht Hamburg, HRB 120189<br>
Geschäftsführer: Carsten Bock<br>
Ust-ID: DE279344284<br>
<br>
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:<br>
<a href="http://www.ng-voice.com/imprint/" rel="noreferrer" target="_blank">http://www.ng-voice.com/imprin<wbr>t/</a><br>
<br>
______________________________<wbr>_________________<br>
Kamailio (SER) - Development Mailing List<br>
<a href="mailto:sr-dev@lists.kamailio.org" target="_blank">sr-dev@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi<wbr>-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>