I agree with Peter that we may want to integrate TLS - both client and server certificates. I haven't tried the module so I can't comment on how this should be done, but using TLS by default in a way controlled by the module would make me feel a little bit better about it.

What are the use cases you see for this functionality? Curious.

/O

On 29 Oct 2013, at 12:18, Charles Chance charles.chance@sipcentric.com wrote:

Do I need to do anything special within my module in order to do this? I assumed (perhaps wrongly) that it would work out of the box, providing tls was enabled correctly in config. Admittedly, I haven't tried it yet. Best,

Charles

On 29 Oct 2013 10:25, "Peter Dunkley" peter.dunkley@crocodilertc.net wrote: Hello,

Are there any options for pushing the traffic through the TLS module?

Regards,

Peter

On 29 October 2013 10:17, Charles Chance charles.chance@sipcentric.com wrote: Devs,

I'm looking for some advice/opinions.

Regarding security of the dmq messages between kamailios - currently it can be achieved by using a separate port (and/or ip) for dmq use and locking this down at firewall level. Of course, tls can be used to protect the content of the messages over the wire.

So is this enough? Or should I look to implement some kind of authentication mechanism as well? Perhaps something as simple as a pre-shared key would suffice, assuming the messages are encrypted of course. Full digest authentication is way too heavy in my opinion.

Any ideas? Or just leave it up to the user to secure it in network layer?

Cheers,

Charles

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ. _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- Peter Dunkley Technical Director Crocodile RCS Ltd

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ._______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

On 29 October 2013 11:24, Alex Balashov abalashov@evaristesys.com wrote:

It's not my decision, but personally, I'd leave this to the user to secure, just like everything else that is kind of IPC in nature (database connections, HTTP queries, etc originating from script).

I'm inclined to agree. The DMQ module is indeed IPC in nature, so by default I would expect to be responsible for securing that communication at network layer. But still I question myself, is this the correct approach.

Charles

I don't know what would be involved in pushing DMQ messages through TLS as I am not familiar with the routing DMQ messages take through the Kamailio stack.

I don't think that TLS should be mandatory for DMQ, just as it is not mandatory for SIP. My thinking was just that if there is a way to configure DMQ to use TLS (perhaps by just putting "tls:" on the front of the server address) it would be a good thing.

Regards,

Peter

On 29 October 2013 11:36, Charles Chance charles.chance@sipcentric.comwrote:

On 29 October 2013 11:24, Alex Balashov abalashov@evaristesys.com wrote:

It's not my decision, but personally, I'd leave this to the user to

...

secure, just like everything else that is kind of IPC in nature (database connections, HTTP queries, etc originating from script).

I'm inclined to agree. The DMQ module is indeed IPC in nature, so by default I would expect to be responsible for securing that communication at network layer. But still I question myself, is this the correct approach.

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.

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

On 29 Oct 2013, at 13:38, Charles Chance charles.chance@sipcentric.com 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? :-)

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 :-)

Thanks for the comments,

You're welcome!

/O

Charles

On 29 October 2013 11:45, Peter Dunkley peter.dunkley@crocodilertc.net wrote: I don't know what would be involved in pushing DMQ messages through TLS as I am not familiar with the routing DMQ messages take through the Kamailio stack.

I don't think that TLS should be mandatory for DMQ, just as it is not mandatory for SIP. My thinking was just that if there is a way to configure DMQ to use TLS (perhaps by just putting "tls:" on the front of the server address) it would be a good thing.

Regards,

Peter

On 29 October 2013 11:36, Charles Chance charles.chance@sipcentric.com wrote:

On 29 October 2013 11:24, Alex Balashov abalashov@evaristesys.com wrote:

It's not my decision, but personally, I'd leave this to the user to secure, just like everything else that is kind of IPC in nature (database connections, HTTP queries, etc originating from script).

I'm inclined to agree. The DMQ module is indeed IPC in nature, so by default I would expect to be responsible for securing that communication at network layer. But still I question myself, is this the correct approach.

Charles

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- Peter Dunkley Technical Director Crocodile RCS Ltd

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ._______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

On 29 Oct 2013, at 16:58, Jan Janak jan@janakj.org wrote:

On Tue, Oct 29, 2013 at 11:29 AM, Olle E. Johansson oej@edvina.net wrote:

...

On 29 Oct 2013, at 13:38, Charles Chance charles.chance@sipcentric.com 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. ;-)

Good to hear from you Jan!

/O

On 29 Oct 2013, at 18:40, Jan Janak jan@janakj.org wrote:

On Tue, Oct 29, 2013 at 12:03 PM, Olle E. Johansson oej@edvina.net wrote:

...

On 29 Oct 2013, at 16:58, Jan Janak jan@janakj.org wrote:

...

On Tue, Oct 29, 2013 at 11:29 AM, Olle E. Johansson oej@edvina.net wrote:

...

On 29 Oct 2013, at 13:38, Charles Chance charles.chance@sipcentric.com 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.

The problem we've experienced painfully in Asterisk is that there's no first choice at all. People use the stuff without any security. yes, that's stupid, yes, it should not happen.

But not everyone are like you and Alex. We might want to start building something that helps the ones that doesn't understand about the need for security, instead of doing the opposite and let them fall.

People that understand will always find the solution that fits their requirements anyway.

Kamailio is getting used outside of our historical user base with tech-savy admins. I think we should start thinking about how to handle that.

Anyway, this discussion is now outside of the DMQ module and should propably continue in a general dev meeting. /O

On 29 Oct 2013, at 20:58, Charles Chance charles.chance@sipcentric.com wrote:

On 29 Oct 2013 17:52, "Olle E. Johansson" oej@edvina.net wrote:

... Anyway, this discussion is now outside of the DMQ module and should propably continue in a general dev meeting.

Yes, perhaps slightly out of the original scope now, but very interesting discussion nonetheless :) Back to DMQ though, enabling TLS support would be straightforward enough with a small change to the code. Then in config the user will just have to specify "sips:..." as the server address instead of "sip:...".

NO! Don't mix SIPS: into the mix. In the rest of Kamailio we use ";transport=tls" SIPS: is a long a complicated bad story... ;-)

However, it still doesn't provide a way to verify that a received DMQ message has come from another DMQ instance, and not some other source.

S/MIME would handle that... ;-) Maybe we need something more simple. TLS will provide client certs which can contain metadata.

To explain a little how the module works - it does not require the user to provide a static list of nodes at startup. Instead, it need only know about one other node, from which it can retrieve a full list of other nodes. The list is then maintained dynamically between nodes, making it possible to spin up new instances without restarting all the existing ones or having to issue some kind of reload command on each.

So back to TLS, unless sessions are restricted to other servers in the cluster only, any client who is able to establish a connection with Kamailio is able to forge a DMQ message and currently, it will be processed blindly by the module.

Ok, that's no good at all.

Therefore, there still needs to be something within the module itself, a pre-shared key/secret for example, which enables the node to decide whether to act on the message or reject it. Once a node is in the shared list, it's not a problem, but during startup the other nodes will not know about it, so there needs to be some form of authentication, independent of the transport layer, I feel.

A shared private CA signing certs could be one solution. Anyone with a certificate signed by the cluster CA can join. SIP Identity could be used if you don't want TLS.

Am I the one who is overcomplicating things now?

No.

I need to take a new look at DMQ.

/O

Regards,

Charles

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ._______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hello All,

I have been thinking about this a little more today.

I'd like to put transport security aside for the moment as in my opinion, it is not a DMQ-specific concern and is possibly clouding the issue.

My immediate priority is to ensure, at module level, that the authenticity of DMQ messages can be verified before they are processed or rejected/ignored if not. Overhead is also an important consideration.

There are no unknown entities involved here - the nodes will always be servers within the same infrastructure. So surely this is as simple as the sending node including a signature/MAC with each request - an HMAC_SHA1 hash of the message for instance, keyed with a pre-shared secret? This way, both message integrity and authenticity can be confirmed by the receiving node, completely independent of the chosen transport security method (or lack thereof). Does anyone see a problem with this approach? It certainly introduces less overhead than private keys/certificates and allows more flexibility than a static ACL which must be reloaded if new nodes are introduced into the cluster.

As always, any feedback greatly appreciated!

Charles

On 29 October 2013 21:01, Olle E. Johansson oej@edvina.net wrote:

On 29 Oct 2013, at 20:58, Charles Chance charles.chance@sipcentric.com wrote:

On 29 Oct 2013 17:52, "Olle E. Johansson" oej@edvina.net wrote:

...

... Anyway, this discussion is now outside of the DMQ module and should propably continue in a general dev meeting.

Yes, perhaps slightly out of the original scope now, but very interesting discussion nonetheless :)

Back to DMQ though, enabling TLS support would be straightforward enough with a small change to the code. Then in config the user will just have to specify "sips:..." as the server address instead of "sip:...".

NO! Don't mix SIPS: into the mix. In the rest of Kamailio we use ";transport=tls" SIPS: is a long a complicated bad story... ;-)

However, it still doesn't provide a way to verify that a received DMQ message has come from another DMQ instance, and not some other source.

S/MIME would handle that... ;-) Maybe we need something more simple. TLS will provide client certs which can contain metadata.

To explain a little how the module works - it does not require the user to provide a static list of nodes at startup. Instead, it need only know about one other node, from which it can retrieve a full list of other nodes. The list is then maintained dynamically between nodes, making it possible to spin up new instances without restarting all the existing ones or having to issue some kind of reload command on each.

So back to TLS, unless sessions are restricted to other servers in the cluster only, any client who is able to establish a connection with Kamailio is able to forge a DMQ message and currently, it will be processed blindly by the module.

Ok, that's no good at all.

Therefore, there still needs to be something within the module itself, a pre-shared key/secret for example, which enables the node to decide whether to act on the message or reject it. Once a node is in the shared list, it's not a problem, but during startup the other nodes will not know about it, so there needs to be some form of authentication, independent of the transport layer, I feel.

A shared private CA signing certs could be one solution. Anyone with a certificate signed by the cluster CA can join. SIP Identity could be used if you don't want TLS.

...

Am I the one who is overcomplicating things now?

No.

I need to take a new look at DMQ.

/O

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._______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

On 29 Oct 2013, at 16:47, Alex Balashov abalashov@evaristesys.com wrote:

On 10/29/2013 08:38 AM, Charles Chance 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.

My personal opinion, mine only, is that transport security is most efficiently provided by transport/network-layer technologies, especially inside static networks.

HTTPS/TLS on the web makes sense because web browsing inherently entails ad hoc connections to unfamiliar servers. That's the very nature of the web and of the browser. The argument could be made that this is also the nature of SIP when it comes to peer-to-peer IP/IP calling, but de facto, the few places where SIP-TLS is used, it seems to be mostly used to encrypt signaling between fixed peers (aka "a SIP trunk"). Or at least, that's my impression--I haven't done a study.

Either way, does DMQ traffic look more like WWW traffic, or more like infrastructure traffic between a fixed number of endpoints within a static topology? I would contend that it is the latter, and for this reason, it should be up to the network administrator to build a secure network, use encrypted tunnels if necessary, etc.

However, I've always been against overcomplicating things, which isn't how IETF/standards/evangelism/advocacy/consulting careers are made...

That's the right strategy. But on the other hand we see that since we don't deliver security by default, no one implements it and then they happily blame the software for being insecure...

I don't think adding security by default is "overcomplicating", but that may be a discussion we can continue over a beer sometime, Alex.

/O