Please DO NOT reply to digests. It makes it way harder to follow discussions on the list this way. -- Töma On Fri, Jul 12, 2019, 1:42 AM Brandon Svec <bsvec@teamonesolutions.com> wrote:
Having a somewhat bell shaped head, this sums it up pretty well, “.. Maybe they don't actually care about this problem until they are 'forced' to care about it by their regulating body?”
As I understand, currently carriers are required to pass spoofed caller ID because there are many legitimate reasons to do so. There was some recent legislation loosening that requirement and there is no requirement to define what legitimate is, but still the issue is some one needs to care about the problem. That will require legislation and incentives to get to.
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Christopher Morrow Sent: Wednesday, 10 July, 2019 22:10 To: Sean Donelan Cc: nanog list Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean@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
End of NANOG Digest, Vol 138, Issue 11 **************************************
-- Brandon Svec 15106862204 voice | fax | sms
teamonesolutions.com 14729 Catalina St. San Leandro, CA 94577
.ılı.ılı. Cisco Meraki CMNA