NANOG Digest, Vol 138, Issue 11

Thu Jul 11 17:07:34 UTC 2019

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 at 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 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
>
>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190711/81b8d40d/attachment.html>