[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