SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

Christopher Morrow morrowc.lists at gmail.com
Thu Jul 11 04:09:57 UTC 2019


On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean at donelan.com> wrote:
>
> On Tue, 9 Jul 2019, Sean Donelan wrote:
> > The agenda looks like lots of happy, happy talk from industry
> > representatives.
>
> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press
> release announcing plans to automatically block robocalls for its
> customers.
>
> https://about.att.com/story/2019/att_call_protect.html
>
> Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers
> AT&T* will add automatic fraud blocking and suspected spam-call alerts to
> millions of AT&T consumer lines at no charge.

oh goodie!

So, not being a bell shaped headed person... a question:
  The calling path and data available inside the phone network smells
(to me) like:
     ingress trunk + ANI + CallerID + outgoing trunk of destination ds0/handset

There seem like a bunch of pretty simple 'correlations' one could
make, that actually look a heck of a lot like 'netflow/log analysis
for ddos detection':
    o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
    o is this trunk sourcing calls from a low distribution of ANI but
a different distribution of CallerID
    o is this trunk sourcing calls from unmatched (as a percent of
total) ANI/CallerID

I would think you could make similar correlations across the
destinations on your phone-network:
    o Is there one ANI or CallerID talking to 'all' (a bunch, more
than X of type Y customer end point) of my endpoints?
    o are there implausible callerid being used? (lots of 'NPA-NXX
matches destination, yet from a very different geography?)

I imagine that with the number of calls here, this is just a splunk
correlation away from successful identification and then disabling of
these nuisance calls...
I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a
whiff of a care" on the part of the carrier(s), right?
Maybe they don't actually care about this problem until they are
'forced' to care about it by their regulating body?
'shaken' and 'stir' may not do anything at all useful for the problem,
but they do make it appear that the carriers care about the problem...
I'm certain that they know there are problems. The 5 items above can't
be 'new and novel' concepts ... since this is basically 'logs
analysis' that any security engineer worth their salt does as a matter
of course daily, right?

-chris



More information about the NANOG mailing list