Re: NANOG Digest, Vol 138, Issue 11

[Töma Gavrichenkov <ximaera () gmail com>]

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