<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
On 2020/03/09 20:04, George Joseph wrote:<br>
<blockquote type="cite"
cite="mid:CAP=uFEvO44u+ZJ37JcyO++AsyeHEdW9rd5dcfphXvF3FZy-WjQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</blockquote>
<--snip--><br>
<blockquote type="cite"
cite="mid:CAP=uFEvO44u+ZJ37JcyO++AsyeHEdW9rd5dcfphXvF3FZy-WjQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
BTW:<br>
While you're at it: it would be a great oportunity to get it
sorted out<br>
completely by globaly adding session stability (one trunk
always uses<br>
same IP destination for all actions. If the destionation
can't be<br>
reached any more (or misbehaves), you have to reregister to
another IP<br>
of the list and remember the new IP for all following
actions).<br>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>Doesn't really help to solve the issue, but I hope it provides
some background as to WHY service providers do this.</p>
<p>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.<br>
</p>
<p>Kind Regards,<br>
Jaco</p>
</body>
</html>