On Tue, Oct 29, 2013 at 12:03 PM, Olle E. Johansson <[email protected]> wrote: > > On 29 Oct 2013, at 16:58, Jan Janak <[email protected]> wrote: > >> On Tue, Oct 29, 2013 at 11:29 AM, Olle E. Johansson <[email protected]> wrote: >>> >>> On 29 Oct 2013, at 13:38, Charles Chance <[email protected]> >>> wrote: >>> >>> I agree with Olle that the common "pass the buck" attitude is wrong, >>> although in this case I don't believe securing the messages should be >>> mandatory. Often the communication between servers will be over a >>> private/secure network and the user should be allowed to disable it if they >>> deem it an unnecessary overhead. >>> >>> Is that another myth - the secure/private/inside network? :-) >> >> Have you heard of IPsec? > It doesn't happen by default... But yes it's an alternative. The people that > use > IPsec is not the ones I'm worrying about. > >> >>> Either way, the ability to use TLS where required is a definite must, so >>> I'll go away and look into that now. >>> >>> At least write the documentation so that most people believe that they have >>> to have TLS and work hard to disable it :-) >> >> I am not convinced this is the right documentation style. I think >> documentation should be balanced, it's IMHO better to explain what >> options are available and not force a particular security mechanism >> down people's throat. > > Well, we've been at this for many years and still all of us have a very > limited number of installations using security mechanisms we have. > > Why is that? I don't think that it's because they use IPsec. ;-)
Are you concerned about client-to-server or server-cluster scenarios? I was mainly pointing out that TLS is not necessarily the first choice when it comes to securing communication in server clusters, which is AFAIK where the dmq module is meant to be used. And in this particular case I'm not sure if making it hard to disable is the right choice. Client-to-server scenarios are a different story, of course. -Jan _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
