On Thursday 31 October 2013, Charles Chance wrote:
> On 31 Oct 2013 08:53, "Alex Hermann" <alex(a)speakup.nl> wrote:
> > If not, then, imho, the admin already has plenty of possibilities
>
> (IP-based,
>
> > digest, TLS cert) to do authentication before calling that function.
> > Why force one method if we can just leave it up to the admin to choose
> > whatever fits best in his situation.
>
> But aren't we allowing the admin to potentially shoot themselves in the
> foot, as Olle puts it?
Of course, but there are plenty ways to shoot oneself. Kamailio is not an end-
user application. I see it more like a compiler than a word-processor. Certain
capabilities are required to make an application with it.
I prefer the freedom to choose whatever method fits best in my
situation/application. I like the current way in which the admin decides how
INVITE, PUBLISH, XMLRPC, DMQ, etc are authenticated and/or authorized. None of
the (C-)code handling those methods need special authentication routines
implemented, it can all be done from within the script.
Implementing additional authorization methods inside DMQ will limit choice and
create a higher burden on maintenance of the module.
There are already to much functions in Kamailio which had only 1 specific use
case in mind, where everyone needing a little bit different behavior
implemented it separately. Look for example at the many ways to get and/or
format date-time values. Let's not add even more.
--
Greetings,
Alex Hermann
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
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 <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.
i have in mtrees table rows with two different tname values. when i
start my sip proxy, mtree module complains about not being able to
convert string to integer:
Oct 30 16:12:07 rautu /usr/sbin/sip-proxy[4092]: ERROR: mtree [mtree.c:163]: mt_add_to_tree(): bad integer string <test>
i added some debug and found out that mtree module does not change the
tree where it adds nodes even when tname value in mtrees records changes
from one record to the next. the above error was generated from the
second record that belongs to tree2 when first record belonged to tree1:
modparam("mtree", "mtree", "name=tree1;type=2;dbtable=mtrees;")
modparam("mtree", "mtree", "name=tree2;type=0;dbtable=mtrees;")
debug output showed that mtree module tried to load also the second
record to tree1.
-- juha
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab.
FS#351 - registrar: memory and db get not synced
User who did this: Víctor Seva (linuxmaniac)
Summary: registrar: process expired contacts first -> registrar: memory and db get not synced
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=351
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.