On Thursday 31 October 2013, Charles Chance wrote:
On 31 Oct 2013 08:53, "Alex Hermann" alex@speakup.nl wrote:
If not, then, imho, the admin already has plenty of possibilities
(IP-based,
digest, TLS cert) to do authentication before calling that function. Why force one method if we can just leave it up to the admin to choose whatever fits best in his situation.
But aren't we allowing the admin to potentially shoot themselves in the foot, as Olle puts it?
Of course, but there are plenty ways to shoot oneself. Kamailio is not an end- user application. I see it more like a compiler than a word-processor. Certain capabilities are required to make an application with it.
I prefer the freedom to choose whatever method fits best in my situation/application. I like the current way in which the admin decides how INVITE, PUBLISH, XMLRPC, DMQ, etc are authenticated and/or authorized. None of the (C-)code handling those methods need special authentication routines implemented, it can all be done from within the script.
Implementing additional authorization methods inside DMQ will limit choice and create a higher burden on maintenance of the module.
There are already to much functions in Kamailio which had only 1 specific use case in mind, where everyone needing a little bit different behavior implemented it separately. Look for example at the many ways to get and/or format date-time values. Let's not add even more.
On 31 Oct 2013, at 12:20, Alex Hermann alex@speakup.nl wrote:
On Thursday 31 October 2013, Charles Chance wrote:
On 31 Oct 2013 08:53, "Alex Hermann" alex@speakup.nl wrote:
If not, then, imho, the admin already has plenty of possibilities
(IP-based,
digest, TLS cert) to do authentication before calling that function. Why force one method if we can just leave it up to the admin to choose whatever fits best in his situation.
But aren't we allowing the admin to potentially shoot themselves in the foot, as Olle puts it?
Of course, but there are plenty ways to shoot oneself. Kamailio is not an end- user application. I see it more like a compiler than a word-processor. Certain capabilities are required to make an application with it.
Agree that it's not an end-user application. But as we see in Asterisk the admin is changing away from the Unix and TCP/IP network specialist. I have students in Kamailio classes that doesn't understand how to edit config files. That did not happen three years ago. They all knew more about LInux than me then.
This should affect how we package and deliver our product.
I prefer the freedom to choose whatever method fits best in my situation/application. I like the current way in which the admin decides how INVITE, PUBLISH, XMLRPC, DMQ, etc are authenticated and/or authorized. None of the (C-)code handling those methods need special authentication routines implemented, it can all be done from within the script.
I never wanted to stop freedom to choose. But I no longer wanted the default to be "oh, and if you want to secure it go ahead and do it yourself". We need to start thinking security by default.
Implementing additional authorization methods inside DMQ will limit choice and create a higher burden on maintenance of the module.
I don't think so as long as we don't disable all the rest.
/O
On 10/31/2013 08:53 AM, Olle E. Johansson wrote:
Of course, but there are plenty ways to shoot oneself. Kamailio is not an end- user application. I see it more like a compiler than a word-processor. Certain capabilities are required to make an application with it.
Agree that it's not an end-user application. But as we see in Asterisk the admin is changing away from the Unix and TCP/IP network specialist. I have students in Kamailio classes that doesn't understand how to edit config files. That did not happen three years ago. They all knew more about LInux than me then.
This should affect how we package and deliver our product.
I'm not sure I agree. The changing nature of the user base will not change Kamailio's essence or structure. It's still fundamentally more like an SDK than like a finished application for the end-user.
In my opinion being able to choose to use DMQ over TCP, TLS, or UDP through setting the ";transport=" URI parameter in the modparams, and being able to validate the TLS certificate in the configuration file (in the same way as you do for all other traffic) is a good solution. Flexibility is good and TLS isn't always necessary and doesn't have to be used. It should be easy to use TLS when you want and easy to not use it when you want, and no-one (however well intentioned) should ever be able to force me to build my network by their rules. Also, this will mean that any future TLS enhancements (for example, validation of certificate on outgoing messages and DANE) will automatically be picked up too.
DMQ is a very advanced module and I don't think there should be too much concern over students who can't edit config files. If they can't work that out they are never going to be able to use Kamailio properly anyway. The fact that Kamailio is "hard" is a necessary function of its flexibility - it is because Kamailio doesn't do anything clever by default that makes it so powerful (because you can have full control over all the behaviour).
And none of this stops a teacher providing their students with good example configuration files for things like DMQ that do all of these things properly. Or even providing configuration file libraries (using "import_file" and check_route_exists()/route_if_exists()) that do all of the right stuff for them.
On 31 October 2013 13:12, Peter Dunkley peter.dunkley@crocodilertc.netwrote:
In my opinion being able to choose to use DMQ over TCP, TLS, or UDP through setting the ";transport=" URI parameter in the modparams, and being able to validate the TLS certificate in the configuration file (in the same way as you do for all other traffic) is a good solution. Flexibility is good and TLS isn't always necessary and doesn't have to be used. It should be easy to use TLS when you want and easy to not use it when you want, and no-one (however well intentioned) should ever be able to force me to build my network by their rules. Also, this will mean that any future TLS enhancements (for example, validation of certificate on outgoing messages and DANE) will automatically be picked up too.
This has been added already (locally, not yet pushed).
DMQ is a very advanced module and I don't think there should be too much concern over students who can't edit config files. If they can't work that out they are never going to be able to use Kamailio properly anyway. The fact that Kamailio is "hard" is a necessary function of its flexibility - it is because Kamailio doesn't do anything clever by default that makes it so powerful (because you can have full control over all the behaviour).
And none of this stops a teacher providing their students with good example configuration files for things like DMQ that do all of these things properly. Or even providing configuration file libraries (using "import_file" and check_route_exists()/route_if_exists()) that do all of the right stuff for them.
I guess there will always be two very distinct camps, and long may the discussion continue, but ultimately it is beyond the scope of DMQ alone. So here lies the remaining question - regarding DMQ module specifically, for now - is it acceptable to leave it up to the user now that they have a choice of transport and therefore the ability to validate TLS certificates if required?
Regards,
Charles
On 31 Oct 2013, at 14:12, Peter Dunkley peter.dunkley@crocodilertc.net wrote:
And none of this stops a teacher providing their students with good example configuration files for things like DMQ that do all of these things properly. Or even providing configuration file libraries (using "import_file" and check_route_exists()/route_if_exists()) that do all of the right stuff for them.
Hitting me with my own argument and code, that's cheating Peter :-)
Well, DMQ is one very strange and advanced module, I admit that. Like I said earlier I think my discussion now is more generic to how we communicate and build the product. I'm trying to change the attitude in a large group of stubborn engineers, including most of me, myself and I...
Having said that, I haven't forgotten that I need to work on your to-do-list, Peter. TLS connection verification is one of the items high on that list.
/O :-)
On 31 October 2013 14:07, Olle E. Johansson oej@edvina.net wrote:
Hitting me with my own argument and code, that's cheating Peter :-)
It's fun to play dirty once in a while :-)
Well, DMQ is one very strange and advanced module, I admit that. Like I said earlier I think my discussion now is more generic to how we communicate and build the product. I'm trying to change the attitude in a large group of stubborn engineers, including most of me, myself and I...
I certainly favour having security (and easy to use security) as a goal. But one of the things I like about Kamailio is the flexibility. For example, secure signalling is harder to trace (that's kind of the point), so when building a network I will tend do so with security disabled (or at least not enforced) so that I can make sure I am happy with the routing, and then tighten things up before I let other people on it.
Having said that, I haven't forgotten that I need to work on your to-do-list, Peter. TLS connection verification is one of the items high on that list.
Indeed. Currently my personal hit-list for Kamailio 4.2 is:
- auth_ephemeral secrets in a database table - per-message/frame deflate for WebSockets - validation of outbound TLS connections - SIP DANE
And if there is time I'd like to do some more work on MSRP too :-)
/O :-)
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 31 Oct 2013, at 15:17, Peter Dunkley peter.dunkley@crocodilertc.net wrote:
On 31 October 2013 14:07, Olle E. Johansson oej@edvina.net wrote:
Hitting me with my own argument and code, that's cheating Peter :-)
It's fun to play dirty once in a while :-)
Well, DMQ is one very strange and advanced module, I admit that. Like I said earlier I think my discussion now is more generic to how we communicate and build the product. I'm trying to change the attitude in a large group of stubborn engineers, including most of me, myself and I...
I certainly favour having security (and easy to use security) as a goal. But one of the things I like about Kamailio is the flexibility. For example, secure signalling is harder to trace (that's kind of the point), so when building a network I will tend do so with security disabled (or at least not enforced) so that I can make sure I am happy with the routing, and then tighten things up before I let other people on it.
Again -
I have never ever said that we should disable the flexibility. Just that we need to start from another side, have a different perspective when we decide default configurations, when we write documentation, when we talk about the product. We want the product to grow and be used by more and more people. That will mean different types of people and even amongst the current crowd a little security would not hurt.
/O
-
Alex Balashov -
Alex Hermann -
Charles Chance -
Olle E. Johansson -
Peter Dunkley