[Asterisk-Dev] Channel registry question
Steven Sokol
ssokol at sokol-associates.com
Thu Mar 4 14:51:08 MST 2004
> Rejecting new registrations in my opinion is bad. Take the case of a
> machine being moved around on a DHCP lease, you would want it to come
> back up as quickly as possible. Take the case of a hot spare configured
> to take over if it notices the primary goes offline. We want these to
> take over quickly and not wait for some timeout function to say the old
> registration is no longer active.
Ok. Both sound like valid arguments to preclude rejecting the registration
out-of-hand. Agreed.
> The best bet would be some form of deregister with ack, but what if it
> is used as an attack. You could forge a dereg packet and send it down to
> a machine in an effort to make them no longer get calls. When would the
> dereg'ed machine know to reconnect and try again.
I don't know how worried I am about attacks. I guess its possible, but if
we required the "reg. override" message to be accompanied by the password
for the channel in question, wouldn't that prevent all but the most
determined hackers?
CLIENT B ASTERISK CLIENT A
1) REGREQ--------------------->|
2) REGREJ[R]<------------------|
3) REGOVRD[SECRET]------------>|
4) |----------------->REJTERM
5) |<-----------------ACK
6) REGACK<---------------------|
> This all basically points out that you should be a decent admin when
> working on configs.
Ok? I can see that I need to keep an eye on the possible introduction of
security holes, but I would think that this issue could be resolved in
several ways, all of which are more secure as the status quo. I would think
that the current method of unchecked re-registration is somewhat less secure
because the user can never be sure that they are the only channel "xxxx"
registering with the system.
> > Should this be written up as a bug, or a request for a feature?
>
> I'm not sure it is either.
I'd say its one or the other. I would think probably feature rather than
bug.
Thanks,
Steve
More information about the asterisk-dev
mailing list