SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

Thu Jul 11 05:12:36 UTC 2019

Their lawyers probably explained to them that they can "block" the call "after" accepting it and thus can get the best of both world -- the revenue from terminating the call while still preventing it from bothering their customers ...

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

>-----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