[asterisk-dev] Asterisk 16.9.0-rc1 Now Available - unusable with Deutsche Telekom

[Jaco Kroon]

Hi,

On 2020/03/09 20:04, George Joseph wrote:
<--snip-->
>
>     BTW:
>     While you're at it: it would be a great oportunity to get it
>     sorted out
>     completely by globaly adding session stability (one trunk always uses
>     same IP destination for all actions. If the destionation can't be
>     reached any more (or misbehaves), you have to reregister to another IP
>     of the list and remember the new IP for all following actions).
>
>
> Yeah, we're thinking that's the only real solution but it's not a
> quick fix and will need some serious thought.  For instance, if on
> registration the first server in the set was successful but when
> Asterisk attempted to send a call, the first server failed, would you
> expect Asterisk to automatically try to re-register and then use the
> new server?  That would be a lot of work just to support DT.  Now if
> they could point to an RFC that codifies their required behavior it
> would be a different matter.  We checked around and couldn't find
> anything however.

I agree with this statement, not aware of anything either.  However,
also being on the ITSP side, and having similar restrictions in place,
as well as knowing what other service providers in SA does similar
things (I won't name them, nor the products they use).  I would ask that
this be given some thought.

The least restrictive (and probably least out of line) with RFC
"requirements" is to simply require that the source IP address of an
invite matches the registered address of the client.  Usually this is
only checked on the host you're contacting but at least one provider
we've encountered has gone to the effort of doing this via a central
database, and asterisk would in the current behaviour work with that (as
long as the registration stays valid).  The majority of SPs that does
this would however fail in a similar way as Deutsche Telekom.

This restriction used to prevent a sensible amount of fraudulent
activity, and with some code modification actually allowed us to detect
brute-force attempts and give "wrong password" responses back on INVITE
if not from the REGISTERED IP.  The behaviours of hackers have however
changed.  I'd rather not go into the details, but would like to add that
the security framework in asterisk 13 onwards helps greatly when used
and monitored properly.

The one thing I am willing to state w.r.t. behaviour from the fraudsters
is that they've taken to after-hours work, and are particularly active
between 18:00 on a Friday evening until around 6:00 on a Monday morning,
and actually take time zones into consideration.  They do now REGISTER
before INVITE (not all, but as a general rule).

Given the above, these restrictions are less and less useful, and with
providers taking more and more efforts w.r.t. redundancy, in general is
starting to become counter-productive.

Doesn't really help to solve the issue, but I hope it provides some
background as to WHY service providers do this.

With regards to the temporary workaround - as it turns out, most of our
customers prefers registering to a specific IP address as a rule
anyway.  When we move things around and their stuff breaks they complain
profusely, and when pushed as to why they use IP instead of DNS it
generally comes to the fore that their routers and/or DNS caches are
really bad at something.  MT is also a large contributor to this where
certain DNS queries are simply not responded to properly (As far as we
can determine it relates to larger DNS responses) and others caches
failures upon their own link failures.  We've taken precautionary
measures, but this does mean slowing down certain operations by weeks
(and months in extreme cases) in comparison to days.

Kind Regards,
Jaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200310/1afc686d/attachment.html>