[sr-dev] DMQ security
Alex Hermann
alex at speakup.nl
Thu Oct 31 14:30:05 CET 2013
On Thursday 31 October 2013, Charles Chance wrote:
> The thing is, DMQ is like a communication channel, over which messages can
> be sent by other modules or from within config. The channel itself is
> established on startup from within DMQ, at code level, not by the 3rd-party
> module or admin. When messages are sent/broadcast over that channel I would
> expect that all nodes currently sat in that channel have previously been
> verified and when I receive a message I don't have to perform my own checks
> each time (in which case I would need to know in advance the list of known
> IPs or perform my own authentication). Now as an admin, I can still choose
> which transport security I use to secure messages over the wire - this is
> outside of DMQ scope anyway - and I can still filter/act upon messages in
> my own "topic" in whichever way I choose. But I don't need to also worry
> about which nodes on that channel are friendly and which ones have been
> allowed to join without being authenticated first.
Thanks for the explanation.
> So there are two layers to DMQ - the underlying channel or network of
> "nodes" maintained dynamically by the DMQ module itself, and the "peers"
> (other modules, config script) which communicate over that network within
> their own discreet topics. My opinion is that the nodes MUST have some way
> internally of confirming their identity when joining/forming the underlying
> network.
Is this very different from "normal" SIP traffic? With SIP over TCP it is also
necessary to make a connection first.
In this scenario the decision could be made in the script. Maybe via a new
event-route on establishing an inbound (TCP-)connection.
> The peers (the function of DMQ which is exposed to the
> end-user/admin) are still then free to communicate in whichever way they
> choose and perform whatever authentication they like - although it actually
> wouldn't be necessary. I don't think this is limiting choice or creating a
> higher maintenance burden.
I was about to type a bit more on how i think about this issue, but meanwhile
Peter Dunkley has sent an email a few minutes ago where the first paragraph is
representing exactly what i was about to type here. (I agree with the rest of
his email too).
--
Greetings,
Alex Hermann
More information about the sr-dev
mailing list