29 Oct
2013
29 Oct
'13
10:01 p.m.
On 29 Oct 2013, at 20:58, Charles Chance <charles.chance(a)sipcentric.com> wrote:
On 29 Oct 2013 17:52, "Olle E. Johansson"
<oej(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev