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
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@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:
- Implement the functionality in ims_register_pcscf.
- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
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@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@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:
- Implement the functionality in ims_register_pcscf.
- 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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Am Donnerstag, 19. Oktober 2017, 10:49:22 CET schrieb Tsvetomir Dimitrov:
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. [..]
Hello Tsvetomir,
good that you choose the path with the separate module. This is the way which was for example also choosen for the different RTP Forwarding modules, there is afaik one that needs a special linux kernel extension.
Best regards,
Henning Westerholt
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@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@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@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:
- Implement the functionality in ims_register_pcscf.
- 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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
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@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@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@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@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:
- Implement the functionality in ims_register_pcscf.
- 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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
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@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@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@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@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@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:
- Implement the functionality in ims_register_pcscf.
- 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@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
-
Carsten Bock -
Henning Westerholt -
Tsvetomir Dimitrov