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

Michael Thomas mike at mtcc.com
Tue Oct 4 18:37:55 UTC 2022


On 10/4/22 11:20 AM, Mike Hammett wrote:
> Isn't part of STIR/SHAKEN to make it easier to determine the ingress 
> provider, or the provider of last blame?

Not exactly. Unlike DKIM which is basically a "blame me" kind of 
authentication at the domain level, STIR/SHAKEN tries to solve the 
problem of who is allowed to use what E.164 address. You can probably 
educe which domain to blame from it... sort of -- I'm not familiar 
enough with the specifics to say how though.


The object has always been to shut down open relays, and this is much 
much easier in the telephony space. Like for one, the FCC exists and 
regulates it. That is not true of email.


Mike

>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------------------------------------------------
> *From: *"Michael Thomas" <mike at mtcc.com>
> *To: *"Mike Hammett" <nanog at ics-il.net>, "Shane Ronan" 
> <shane at ronan-online.com>
> *Cc: *nanog at nanog.org
> *Sent: *Tuesday, October 4, 2022 1:18:24 PM
> *Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)
>
>
> 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>
>     *To: *"Michael Thomas" <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/cf99850a/attachment.html>


More information about the NANOG mailing list