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

Tue Oct 4 19:18:06 UTC 2022

On 10/4/22 11:58 AM, Tom Beecher wrote:
>
>      Honestly the root of a lot of the problems here is the bellheaded
>     insistence of still using E.164 addresses in the first place. With
>     SIP they are complete legacy and there is no reason that my
>     "telephone number" can't be mike at mtcc.com.
>
>
> You can do that all you want. You just don't get to interact with the 
> PSTN.

What is the "PSTN" these days? It's a bunch of interconnected SIP 
proxies where there is nothing special about the identifiers used. With 
end to end SIP (or middle to middle, etc), the routing is not being done 
with e.164 addresses like in the legacy PSTN. It's just bellheaded 
thinking that e.164 addresses mean anything these days.The only time 
they make any difference is if they need to off ramp to legacy signaling 
which is becoming rarer and rarer.

Mike

>
> On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <mike at mtcc.com> wrote:
>
>
>     On 10/4/22 11:31 AM, Mike Hammett wrote:
>>     What's regulated or implemented is rarely the best course of
>>     action. Does this cause more good or harm?
>
>
>     Honestly the root of a lot of the problems here is the bellheaded
>     insistence of still using E.164 addresses in the first place. With
>     SIP they are complete legacy and there is no reason that my
>     "telephone number" can't be mike at mtcc.com. In fact, that would be
>     a huge win since I could just use my email address book to make a
>     call. You could tell that STIR/SHAKEN really went off the rails
>     when it has heuristics on how to scrape E.164 addresses in the
>     From: field. At this point we should be mostly ignoring legacy
>     signaling, IMO.
>
>
>     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: *"Mike Hammett" <nanog at ics-il.net>
>>     <mailto:nanog at ics-il.net>, nanog at nanog.org
>>     *Sent: *Tuesday, October 4, 2022 1:21:41 PM
>>     *Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)
>>
>>     Except the cost to do the data dips to determine the
>>     authorization isn't "free".
>>
>>     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/5f1329c4/attachment.html>