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

Tue Oct 4 18:58:17 UTC 2022

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

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> <shane at ronan-online.com>
> *To: *"Michael Thomas" <mike at mtcc.com> <mike at mtcc.com>
> *Cc: *"Mike Hammett" <nanog at ics-il.net> <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> <shane at ronan-online.com>
>> *To: *"Michael Thomas" <mike at mtcc.com> <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/a69449fa/attachment.html>