31 Oct
2013
31 Oct
'13
4:20 p.m.
On Thursday 31 October 2013, Charles Chance wrote:
On 31 Oct 2013 08:53, "Alex Hermann"
<alex(a)speakup.nl> 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.
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.
--
Greetings,
Alex Hermann
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? 
31 Oct
31 Oct
5:53 p.m.
New subject: DMQ security
On 31 Oct 2013, at 12:20, Alex Hermann <alex(a)speakup.nl> wrote:
On Thursday 31 October 2013, Charles Chance wrote:
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.
On 31 Oct 2013 08:53, "Alex Hermann"
<alex(a)speakup.nl> 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. 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?
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
6:11 p.m.
New subject: DMQ security
On 10/31/2013 08:53 AM, Olle E. Johansson wrote:
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.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
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. 
6:12 p.m.
New subject: DMQ security
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.
7:03 p.m.
New subject: DMQ security
On 31 October 2013 13:12, Peter Dunkley <peter.dunkley(a)crocodilertc.net>wrote;wrote:
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
--
www.sipcentric.com
Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham
B7 4EJ.
7:07 p.m.
New subject: Kamailio security in general
On 31 Oct 2013, at 14:12, Peter Dunkley <peter.dunkley(a)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 :-)
7:17 p.m.
New subject: Kamailio security in general
On 31 October 2013 14:07, Olle E. Johansson <oej(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
7:22 p.m.
New subject: Kamailio security in general
On 31 Oct 2013, at 15:17, Peter Dunkley <peter.dunkley(a)crocodilertc.net> wrote:
On 31 October 2013 14:07, Olle E. Johansson <oej(a)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
3840
days inactive
3840
days old
7 comments
5 participants
participants (5)
-
Alex Balashov -
Alex Hermann -
Charles Chance -
Olle E. Johansson -
Peter Dunkley