FCC chairwoman: Fines alone aren't enough (Robocalls)

Tue Oct 4 20:50:18 UTC 2022

On 10/4/22 1:40 PM, sronan at ronan-online.com wrote:
> Except the pstn DB isn’t distributed like DNS is.

Yes, I had forgot about "dip" in that sense. But an originating provider 
doesn't need to do a dip to know that the calling number routes to 
itself. I've been talking about the calling provider not the called 
provider all along.

Mike

>
>> On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike at mtcc.com> wrote:
>>
>> 
>>
>>
>> On 10/4/22 11:21 AM, Shane Ronan wrote:
>>> Except the cost to do the data dips to determine the authorization 
>>> isn't "free".
>>
>> Since every http request in the universe requires a "database dip" 
>> and they are probably a billion times more common, that doesn't seem 
>> like a very compelling concern.
>>
>> Mike
>>
>>
>>>
>>> On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike at mtcc.com> wrote:
>>>
>>>
>>>     On 10/4/22 6:07 AM, Mike Hammett wrote:
>>>>     I think the point the other Mike was trying to make was that if
>>>>     everyone policed their customers, this wouldn't be a problem.
>>>>     Since some don't, something else needed to be tried.
>>>>
>>>>
>>>     Exactly. And that doesn't require an elaborate PKI. Who is
>>>     allowed to use what telephone numbers is an administrative issue
>>>     for the ingress provider to police. It's the equivalent to gmail
>>>     not allowing me to spoof whatever email address I want. The FCC
>>>     could have required that ages ago.
>>>
>>>
>>>     Mike
>>>
>>>>
>>>>     -----
>>>>     Mike Hammett
>>>>     Intelligent Computing Solutions
>>>>     http://www.ics-il.com
>>>>
>>>>     Midwest-IX
>>>>     http://www.midwest-ix.com
>>>>
>>>>     ------------------------------------------------------------------------
>>>>     *From: *"Shane Ronan" <shane at ronan-online.com>
>>>>     <mailto:shane at ronan-online.com>
>>>>     *To: *"Michael Thomas" <mike at mtcc.com> <mailto:mike at mtcc.com>
>>>>     *Cc: *nanog at nanog.org
>>>>     *Sent: *Monday, October 3, 2022 9:54:07 PM
>>>>     *Subject: *Re: FCC chairwoman: Fines alone aren't enough
>>>>     (Robocalls)
>>>>
>>>>     The issue isn't which 'prefixes' I accept from my customers,
>>>>     but which 'prefixes' I accept from the people I peer with,
>>>>     because it's entirely dynamic and without a doing a database
>>>>     dip on EVERY call, I have to assume that my peer or my peers
>>>>     customer or my peers peer is doing the right thing.
>>>>
>>>>     I can't simply block traffic from a peer carrier, it's not
>>>>     allowed, so there has to be some mechanism to mark that a
>>>>     prefix should be allowed, which is what Shaken/Stir does.
>>>>
>>>>     Shane
>>>>
>>>>
>>>>
>>>>     On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas <mike at mtcc.com>
>>>>     wrote:
>>>>
>>>>         The problem has always been solvable at the ingress
>>>>         provider. The
>>>>         problem was that there was zero to negative incentive to do
>>>>         that. You
>>>>         don't need an elaborate PKI to tell the ingress provider
>>>>         which prefixes
>>>>         customers are allow to assert. It's pretty analogous to
>>>>         when submission
>>>>         authentication was pretty nonexistent with email... there
>>>>         was no
>>>>         incentive to not be an open relay sewer. Unlike email spam,
>>>>         SIP
>>>>         signaling is pretty easy to determine whether it's spam.
>>>>         All it needed
>>>>         was somebody to force regulation which unlike email there
>>>>         was always
>>>>         jurisdiction with the FCC.
>>>>
>>>>         Mike
>>>>
>>>>         On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
>>>>         > We're talking about blocking other carriers.
>>>>         >
>>>>         > On 10/3/22, 3:05 PM, "Michael Thomas" <mike at mtcc.com> wrote:
>>>>         >
>>>>         >      On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>>>>         >      > Because it's illegal for common carriers to block
>>>>         traffic otherwise.
>>>>         >
>>>>         >      Wait, what? It's illegal to police their own users?
>>>>         >
>>>>         >      Mike
>>>>         >
>>>>         >      >
>>>>         >      > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael
>>>>         Thomas" <nanog-bounces+jbazyar=verobroadband.com at nanog.org
>>>>         on behalf of mike at mtcc.com> wrote:
>>>>         >      >
>>>>         >      >
>>>>         >      >      On 10/3/22 1:34 PM, Sean Donelan wrote:
>>>>         >      >      > 'Fines alone aren't enough:' FCC threatens
>>>>         to blacklist voice
>>>>         >      >      > providers for flouting robocall rules
>>>>         >      >      >
>>>>         >      >      >
>>>>         https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
>>>>         >      >      >
>>>>         >      >      > [...]
>>>>         >      >      > “This is a new era. If a provider doesn’t
>>>>         meet its obligations under
>>>>         >      >      > the law, it now faces expulsion from
>>>>         America’s phone networks. Fines
>>>>         >      >      > alone aren’t enough,” FCC chairwoman
>>>>         Jessica Rosenworcel said in a
>>>>         >      >      > statement accompanying the announcement.
>>>>         “Providers that don’t follow
>>>>         >      >      > our rules and make it easy to scam
>>>>         consumers will now face swift
>>>>         >      >      > consequences.”
>>>>         >      >      >
>>>>         >      >      > It’s the first such enforcement action by
>>>>         the agency to reduce the
>>>>         >      >      > growing problem of robocalls since call ID
>>>>         verification protocols
>>>>         >      >      > known as “STIR/SHAKEN” went fully into
>>>>         effect this summer.
>>>>         >      >      > [...]
>>>>         >      >
>>>>         >      >      Why did we need to wait for STIR/SHAKEN to do
>>>>         this?
>>>>         >      >
>>>>         >      >      Mike
>>>>         >      >
>>>>         >
>>>>         >
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221004/5d617d3a/attachment.html>