NANOG Digest, Vol 138, Issue 11

Thu Jul 11 23:01:38 UTC 2019

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 at 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 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/20190712/7cdb96e9/attachment.html>