<div dir="ltr"><div>Hello All,</div><div><br></div><div>I have been thinking about this a little more today.<br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>As always, any feedback greatly appreciated!<br></div><div><br></div><div>Charles</div><div><br></div><div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 October 2013 21:01, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="im"><div>On 29 Oct 2013, at 20:58, Charles Chance <<a href="mailto:charles.chance@sipcentric.com" target="_blank">charles.chance@sipcentric.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><p dir="ltr">On 29 Oct 2013 17:52, "Olle E. Johansson" <<a href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>> wrote:</p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
...<br>Anyway, this discussion is now outside of the DMQ module and should propably<br>continue in a general dev meeting.</blockquote><p dir="ltr"><br></p><p dir="ltr">Yes, perhaps slightly out of the original scope now, but very interesting discussion nonetheless :)<br>
</p><p dir="ltr">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:...".</p>
<div><br></div></div></blockquote></div>NO! Don't mix SIPS: into the mix. In the rest of Kamailio we use ";transport=tls"</div><div>SIPS: is a long a complicated bad story... ;-)<div class="im"><br><blockquote type="cite">
<div dir="ltr"><p dir="ltr">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.</p><div><br></div></div></blockquote></div>S/MIME would handle that... ;-)</div>
<div>Maybe we need something more simple. TLS will provide client certs which can contain metadata.<div class="im"><br><blockquote type="cite"><div dir="ltr"><p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<div><br></div></div></blockquote></div>Ok, that's no good at all.<div class="im"><br><blockquote type="cite"><div dir="ltr"><p dir="ltr">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.</p>
<div><br></div></div></blockquote></div>A shared private CA signing certs could be one solution. Anyone with a certificate signed by the cluster CA can join. </div><div>SIP Identity could be used if you don't want TLS. </div>
<div><br></div><div><div class="im">> Am I the one who is overcomplicating things now?<br><blockquote type="cite"><div dir="ltr"><div><br></div></div></blockquote></div>No.</div><div><br></div><div>I need to take a new look at DMQ. </div>
<div><br></div><div>/O<br><blockquote type="cite"><div dir="ltr"><p dir="ltr">Regards,</p><p dir="ltr">Charles</p><p dir="ltr"><br></p>
</div><div class="im">
<br>
<font face="Helvetica, Arial, sans-serif"><font><span style="font-size:10pt"><a href="http://www.sipcentric.com/" title="blocked::http://www.sipcentric.com/" target="_blank">www.sipcentric.com</a><br>
<br>
Follow us on twitter <a href="http://twitter.com/sipcentric" title="blocked::http://twitter.com/sipcentric" target="_blank">@sipcentric</a><br>
<br>
<font color="gray">Sipcentric Ltd.
Company registered in England & Wales no. 7365592.</font> <font color="gray">Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.</font></span></font></font>_______________________________________________<br></div><div class="im">sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></blockquote></div><br></div><br>_______________________________________________<br>
sr-dev mailing list<br>
<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
<br></blockquote></div><br><br>
</div></div>
<br>
<font face="Helvetica, Arial, sans-serif"><font size="2"><span style="font-size:10pt"><a href="http://www.sipcentric.com/" title="blocked::http://www.sipcentric.com/" target="_blank">www.sipcentric.com</a><br>
<br>
Follow us on twitter <a href="http://twitter.com/sipcentric" title="blocked::http://twitter.com/sipcentric" target="_blank">@sipcentric</a><br>
<br>
<font color="gray">Sipcentric Ltd.
Company registered in England & Wales no. 7365592.</font> <font color="gray">Registered
office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.</font></span></font></font>