nanog mailing list archives
Re: NANOG Digest, Vol 138, Issue 11
From: Töma Gavrichenkov <ximaera () gmail com>
Date: Fri, 12 Jul 2019 02:01:38 +0300
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 apressrelease 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&TCustomersAT&T* will add automatic fraud blocking and suspected spam-callalerts tomillions 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? -chrisEnd 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
Current thread:
- Re: NANOG Digest, Vol 138, Issue 11 Brandon Svec (Jul 11)
- Re: NANOG Digest, Vol 138, Issue 11 Töma Gavrichenkov (Jul 11)