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

[Matthew Black]

I thought that SCOTUS ruled years ago that telco users possess a First 
Amendment right to spoof Caller ID.

Matthew


From: NANOG < > On Behalf Of Shane Ronan
Sent: Tuesday, October 04, 2022 11:22 AM
To: Michael Thomas 
Cc: nanog@nanog.org
Subject: Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

CAUTION: This email was sent from an external source.

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 
mailto:m...@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" 
To: "Michael Thomas" 
Cc: nanog@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 
mailto:m...@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" mailto:m...@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" 
> mailto:verobroadband@nanog.org>
>  on behalf of m...@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 
> 

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

[sronan]

Very different, collecting it would mean contacting EVERY customer to collect 
the data and then validating it all to ensure the customer was telling the 
truth, down to the individual phone number level. Imagine if to validate 
routes, you weren’t able to look at /24’s and higher but down to the individual 
address and didn’t have SWIP data to use as a starting point

> On Oct 4, 2022, at 10:34 PM, Christopher Morrow  
> wrote:
> 
> On Tue, Oct 4, 2022 at 8:36 PM  wrote:
>> 
>> The FCC hasn’t enforced it because the burden on large carriers to collect 
>> that data would be insane. And it would be reduce the flexibility of large 
>> carriers to take on new traffic in disaster situations, which is one of the 
>> strongest points of the PSTN. It’s not like the carriers have the data and 
>> aren’t using it, they simply don’t have the data.
> 
> /me looks at weblogs for a very large internet site
>  ".. burden on large carriers to collect that data would be insane..."
> 
> ORLY? do tell.

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

[Christopher Morrow]

On Tue, Oct 4, 2022 at 8:36 PM  wrote:
>
> The FCC hasn’t enforced it because the burden on large carriers to collect 
> that data would be insane. And it would be reduce the flexibility of large 
> carriers to take on new traffic in disaster situations, which is one of the 
> strongest points of the PSTN. It’s not like the carriers have the data and 
> aren’t using it, they simply don’t have the data.

/me looks at weblogs for a very large internet site
  ".. burden on large carriers to collect that data would be insane..."

ORLY? do tell.

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

[sronan]

The FCC hasn’t enforced it because the burden on large carriers to collect that 
data would be insane. And it would be reduce the flexibility of large carriers 
to take on new traffic in disaster situations, which is one of the strongest 
points of the PSTN. It’s not like the carriers have the data and aren’t using 
it, they simply don’t have the data.

> On Oct 4, 2022, at 8:30 PM, Michael Thomas  wrote:
> 
> 
>> On 10/4/22 5:23 PM, Peter Beckman wrote:
>>> On Tue, 4 Oct 2022, Michael Thomas wrote:
>>> 
>>> 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.
>> 
>>  How does one carrier that gets DIDs from multiple other carriers
>>  communicate to the termination carrier selected during LCR that the DID
>>  set as CallerID is indeed serviced by that carrier and authorized to use
>>  said DID as CallerID?
>> 
>>  If a call is asynchronous, e.g. the DID carrier is not the terminating
>>  carrier, how can the termination carrier trust/know definitively that
>>  someone is allowed to use that CallerID?
>> 
>>  Don't forget the resellers!!!
>> 
> My point is not that the termination carrier believe that it's legitimate 
> (although that would be nice), but to get the originating carrier to police 
> things before it ever gets forwarded. The FCC could have forced that ages ago 
> in most cases. Requiring the receiving end to police things is fraught with 
> false positives where the originating carrier has a lot more knowledge of who 
> their customer is.
> 
> Mike
> 

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

[Michael Thomas]

On 10/4/22 5:23 PM, Peter Beckman wrote:

On Tue, 4 Oct 2022, Michael Thomas wrote:

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.


 How does one carrier that gets DIDs from multiple other carriers
 communicate to the termination carrier selected during LCR that the DID
 set as CallerID is indeed serviced by that carrier and authorized to use
 said DID as CallerID?

 If a call is asynchronous, e.g. the DID carrier is not the terminating
 carrier, how can the termination carrier trust/know definitively that
 someone is allowed to use that CallerID?

 Don't forget the resellers!!!

My point is not that the termination carrier believe that it's 
legitimate (although that would be nice), but to get the originating 
carrier to police things before it ever gets forwarded. The FCC could 
have forced that ages ago in most cases. Requiring the receiving end to 
police things is fraught with false positives where the originating 
carrier has a lot more knowledge of who their customer is.


Mike

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

[Peter Beckman]

On Tue, 4 Oct 2022, Michael Thomas wrote:

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.


 How does one carrier that gets DIDs from multiple other carriers
 communicate to the termination carrier selected during LCR that the DID
 set as CallerID is indeed serviced by that carrier and authorized to use
 said DID as CallerID?

 If a call is asynchronous, e.g. the DID carrier is not the terminating
 carrier, how can the termination carrier trust/know definitively that
 someone is allowed to use that CallerID?

 Don't forget the resellers!!!

Beckman
---
Peter Beckman  Internet Guy
beck...@angryox.comhttps://www.angryox.com/
---

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

[sronan]

I don’t think they are…

> On Oct 4, 2022, at 6:54 PM, Michael Thomas  wrote:
> 
> 
>> On 10/4/22 3:08 PM, Shane Ronan wrote:
>> I'm talking about PSTN hops, which like I previously said still accounts for 
>> a VERY significant amount of calls.
>> 
>> 
> But what percentage of the spam calls? I thought they were mainly coming from 
> voip/SIP?
> 
> Mike
> 

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

[Michael Thomas]

On 10/4/22 3:08 PM, Shane Ronan wrote:
I'm talking about PSTN hops, which like I previously said still 
accounts for a VERY significant amount of calls.



But what percentage of the spam calls? I thought they were mainly coming 
from voip/SIP?


Mike

[NANOG-announce] NANOG 86 Hackathon, 1 Day DNS Class + Connect w/ Community via Affinity Groups!

[Nanog News]

*NANOG 86 Hackathon Kicks Off Friday! *
*Register Now to Attend In-Person and/or Virtually*

*Friday, 07 Oct - *Intro/Tutorial/Team Formation
*Saturday + Sunday, 15-16 Oct -* Hacking

On *Friday, 07 Oct, *we will hold the Hackathon welcome, introduction,
infrastructure tutorial, idea-pitching, and team-forming session over Zoom.

*Theme: *Packing up your Tool Kit - I

***Registration is required. View + print flyer here.



*REGISTER NOW *

*DNS Fundamentals  *
*NANOG 86 DNS 1-Day Class*

*Date:* 16 Oct. - In-Person Class
*Time: *10:00am - 4:00pm PST

*Description:* Exploration of the history of the Domain Number System
(DNS), the original design, how it works, and its evolution.

***Registration is required. View + print flyer here.


*REGISTER NOW *

*Connect with our Incredible Community! *
*Check out our "Affinity Groups" via our Community Forum*

Looking for a way to connect more with our incredible community? Join the
conversation and make new friends via our Community Forum Affinity Groups!

Current affinity groups available:
• Automation
• Coffee
• Diversity in Tech
• DNS
• Events & Social Groups
• IRRd
• Kids
• LGBTQ+
• Martial Arts
• RPKI
• Running
• Security
• Walking
• Whiskey Connoisseurs
• Wine Connoisseurs
• Women in Tech
• Yoga

*JOIN NOW
*
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG 86 Hackathon, 1 Day DNS Class + Connect w/ Community via Affinity Groups!

[Nanog News]

*NANOG 86 Hackathon Kicks Off Friday! *
*Register Now to Attend In-Person and/or Virtually*

*Friday, 07 Oct - *Intro/Tutorial/Team Formation
*Saturday + Sunday, 15-16 Oct -* Hacking

On *Friday, 07 Oct, *we will hold the Hackathon welcome, introduction,
infrastructure tutorial, idea-pitching, and team-forming session over Zoom.

*Theme: *Packing up your Tool Kit - I

***Registration is required. View + print flyer here.



*REGISTER NOW *

*DNS Fundamentals  *
*NANOG 86 DNS 1-Day Class*

*Date:* 16 Oct. - In-Person Class
*Time: *10:00am - 4:00pm PST

*Description:* Exploration of the history of the Domain Number System
(DNS), the original design, how it works, and its evolution.

***Registration is required. View + print flyer here.


*REGISTER NOW *

*Connect with our Incredible Community! *
*Check out our "Affinity Groups" via our Community Forum*

Looking for a way to connect more with our incredible community? Join the
conversation and make new friends via our Community Forum Affinity Groups!

Current affinity groups available:
• Automation
• Coffee
• Diversity in Tech
• DNS
• Events & Social Groups
• IRRd
• Kids
• LGBTQ+
• Martial Arts
• RPKI
• Running
• Security
• Walking
• Whiskey Connoisseurs
• Wine Connoisseurs
• Women in Tech
• Yoga

*JOIN NOW
*

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

[Shane Ronan]

I'm talking about PSTN hops, which like I previously said still accounts
for a VERY significant amount of calls.

And like I said, even if they do care now, how do they build the database
of allowed prefixes by customers, without potentially impacting the ability
for a customer to make a call? Remember, with email if an email doesn't go
through because of tightened restrictions, no one dies. With a voice call,
it may very well be the difference between life and death, they are not the
same.

Shane

On Tue, Oct 4, 2022 at 5:34 PM Michael Thomas  wrote:

>
> On 10/4/22 2:00 PM, sro...@ronan-online.com wrote:
>
> I suppose but that also means they need to go back and figure out which
> prefixes to allow, since historically hasn’t been tracked.
>
>
> Which is the same thing as when email providers didn't care either.
> Getting them to care is key however you need to get that done.
>
>
> Also, how does the man in the middle since most calls don’t go from
> originating carrier to terminating carrier, know if the originator did
> their job?
>
> Why do the middle guys need to care? Only the originator and terminator
> have a stake in the spam problem. Of course I'm talking all SIP here, not
> with PSTN hops. Or is that what you're talking about?
>
>
> Mike
>
>
>
> On Oct 4, 2022, at 4:50 PM, Michael Thomas  
> wrote:
>
> 
>
>
> On 10/4/22 1:40 PM, sro...@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  
> 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  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"  
>> *To: *"Michael Thomas"  
>> *Cc: *nanog@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  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"  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"
>>> >> m...@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 

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

[Michael Thomas]

On 10/4/22 2:00 PM, sro...@ronan-online.com wrote:
I suppose but that also means they need to go back and figure out 
which prefixes to allow, since historically hasn’t been tracked.



Which is the same thing as when email providers didn't care either. 
Getting them to care is key however you need to get that done.




Also, how does the man in the middle since most calls don’t go from 
originating carrier to terminating carrier, know if the originator did 
their job?


Why do the middle guys need to care? Only the originator and terminator 
have a stake in the spam problem. Of course I'm talking all SIP here, 
not with PSTN hops. Or is that what you're talking about?



Mike





On Oct 4, 2022, at 4:50 PM, Michael Thomas  wrote:




On 10/4/22 1:40 PM, sro...@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  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  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" 

*To: *"Michael Thomas"  
*Cc: *nanog@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 
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" 
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"
 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 

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

[sronan]

I suppose but that also means they need to go back and figure out which 
prefixes to allow, since historically hasn’t been tracked.

Also, how does the man in the middle since most calls don’t go from originating 
carrier to terminating carrier, know if the originator did their job?

> On Oct 4, 2022, at 4:50 PM, Michael Thomas  wrote:
> 
> 
> 
> 
> On 10/4/22 1:40 PM, sro...@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  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  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" 
>> To: "Michael Thomas" 
>> Cc: nanog@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  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"  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" 
>>> > >> > m...@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
>>> >  > 

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

[Michael Thomas]

On 10/4/22 1:40 PM, sro...@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  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  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" 

*To: *"Michael Thomas"  
*Cc: *nanog@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 
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"  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"  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.
>      >      > [...]
>      >

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

[sronan]

Inter-telco trunks aren’t all SIP, you might be surprised how much 
“traditional” trunking there still is.

> On Oct 4, 2022, at 3:18 PM, Michael Thomas  wrote:
> 
> 
> 
> 
>> 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 m...@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  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 m...@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" 
 To: "Michael Thomas" 
 Cc: "Mike Hammett" , nanog@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  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" 
> To: "Michael Thomas" 
> Cc: nanog@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  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"  wrote:
>> >
>> >  On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
>> >  > Because it's illegal 

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

[sronan]

Except the pstn DB isn’t distributed like DNS is.

> On Oct 4, 2022, at 2:40 PM, Michael Thomas  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  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" 
 To: "Michael Thomas" 
 Cc: nanog@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  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"  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" 
> >  > m...@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
> >  >
> >
> >
 

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

[Tom Beecher]

>
> The only time they make any difference is if they need to off ramp to
> legacy signaling which is becoming rarer and rarer.
>

There are still significant parts of global phone systems that are reliant
on legacy circuit switching tech. It needs to be accounted for today, and
the foreseeable future.

On Tue, Oct 4, 2022 at 3:18 PM Michael Thomas  wrote:

>
> 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 m...@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  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 m...@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"  
>> *To: *"Michael Thomas"  
>> *Cc: *"Mike Hammett"  ,
>> nanog@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  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"  
>>> *To: *"Michael Thomas"  
>>> *Cc: *nanog@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  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"  wrote:
 >
 >  On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
 >  

Re: [EXTERNAL] Re: FCC chairwoman: Fines alone aren't enough (Robocalls)

[Compton, Rich A]

DDoS traffic coming from legit/botted sources that is not spoofed is not DDoS 
amplification.  DDoS amplification requires spoofing.  If everyone did 
BCP38/84, there would be no DDoS amplification attacks.  

-Rich

On 10/4/22, 1:14 PM, "NANOG on behalf of Robert Blayzor via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

On 10/4/22 09:19, Mike Hammett wrote:
> Sorta like in the IP world, if everyone did BCP38/84, amplification 
> attacks wouldn't exist. Not everyone does, so...


Wouldn't exist? Maybe only in part, BCP38/84 does nothing for a majority 
of DDoS amp attacks. Most traffic is coming from legit/botted sources.

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

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

[Michael Thomas]

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 m...@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  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 m...@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" 

*To: *"Michael Thomas"  
*Cc: *"Mike Hammett" 
, nanog@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  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" 

*To: *"Michael Thomas"  
*Cc: *nanog@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
 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

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

[Robert Blayzor via NANOG]

On 10/4/22 09:19, Mike Hammett wrote:
Sorta like in the IP world, if everyone did BCP38/84, amplification 
attacks wouldn't exist. Not everyone does, so...



Wouldn't exist? Maybe only in part, BCP38/84 does nothing for a majority 
of DDoS amp attacks. Most traffic is coming from legit/botted sources.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

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

[Michael Thomas]

Back when P-Asserted-Identity was coming into being I screamed at the 
top of my lungs that it was going to get abused. The reply was that the 
telephone network was a closed system so it wasn't a problem. It turns 
out that we were both sort of right. At that time, email submission 
authentication was still pretty uncommon so most ISP's were open relay 
sewers so there was nobody to name and shame, so we figured that it 
would be a good idea to provide that means. That's pretty much the case 
of telephony now since their providers don't care what the identity is 
in the signaling. But it was always the case that they could care and 
not allow spoofing, just like I can't spoof email addresses from my 
gmail account. And very unlike email, telephony has lots of regulatory 
machinery to require that to happen.


Mike

On 10/4/22 11:22 AM, b...@theworld.com wrote:

On October 3, 2022 at 16:05 m...@mtcc.com (Michael Thomas) 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.

Analogies to email are always fraught.

How often do LEGITIMATE telco customers make hundreds if not thousands
of calls per hour w/o some explicit arrangement with their telco?

As they say, a telephone company is a vast, detailed billing system
with an added voice feature.

Quite unlike email where it's mostly fire and forget plus or minus
hitting a spam filter precisely because there is no billing, no
incentive. And no voice "snowshoeing".

I doubt robocalls are ever made with anything like spam
roboarmies.

With email it's like every single computer on the net with an IP
address has, in effect, a (potentially) fully functional "originating
switch" (again, some exceptions like port 25 blocking.) People have
run spambots from others' printers etc.

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

[Tom Beecher]

>
>  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 m...@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  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 m...@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"  
> *To: *"Michael Thomas"  
> *Cc: *"Mike Hammett"  ,
> nanog@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  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"  
>> *To: *"Michael Thomas"  
>> *Cc: *nanog@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  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"  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"
>>> >> m...@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. 

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

[Michael Thomas]

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 m...@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" 
*To: *"Michael Thomas" 
*Cc: *"Mike Hammett" , nanog@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  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" 

*To: *"Michael Thomas"  
*Cc: *nanog@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 
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" 
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"  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 

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

[Michael Thomas]

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

*To: *"Michael Thomas"  
*Cc: *nanog@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  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"  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"  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
>      >
>
>

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

[Michael Thomas]

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" 
*To: *"Mike Hammett" , "Shane Ronan" 


*Cc: *nanog@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" 
*To: *"Michael Thomas" 
*Cc: *nanog@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  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"  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"  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

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

[Mike Hammett]

What's regulated or implemented is rarely the best course of action. Does this 
cause more good or harm? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Shane Ronan"  
To: "Michael Thomas"  
Cc: "Mike Hammett" , nanog@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 < m...@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"  
To: "Michael Thomas"  
Cc: nanog@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 < m...@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" < m...@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" 
> >  > m...@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 
> > 
> 
> 

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

[Michael Thomas]

On 10/4/22 7:05 AM, Jawaid Bazyar wrote:

Phone spam pretty much always involves the knowledge and involvement of the 
provider. There are no phone providers who don't know when one of their 
customers are making millions of robocalls.

International toll fraud also always involves the collusion of corrupt small 
country telephone monopolies.

So unlike email spam, where there are a million ways to send a million emails a 
minute without someone being aware, phone spam is definitively collisional. (Is 
that a word?)


All the more reason why waiting for STIR/SHAKEN was unnecessary. And yes 
the telephony network is a lot easier than email to police.


Mike





On 10/3/22, 5:05 PM, "Michael Thomas"  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"  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" 
 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
 >  >
 >
 >

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

[bzs]

On October 3, 2022 at 16:05 m...@mtcc.com (Michael Thomas) 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.

Analogies to email are always fraught.

How often do LEGITIMATE telco customers make hundreds if not thousands
of calls per hour w/o some explicit arrangement with their telco?

As they say, a telephone company is a vast, detailed billing system
with an added voice feature.

Quite unlike email where it's mostly fire and forget plus or minus
hitting a spam filter precisely because there is no billing, no
incentive. And no voice "snowshoeing".

I doubt robocalls are ever made with anything like spam
roboarmies.

With email it's like every single computer on the net with an IP
address has, in effect, a (potentially) fully functional "originating
switch" (again, some exceptions like port 25 blocking.) People have
run spambots from others' printers etc.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

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

[Shane Ronan]

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  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"  
> *To: *"Michael Thomas"  
> *Cc: *nanog@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  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"  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"
>> > m...@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
>> >  >
>> >
>> >
>>
>
>

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

[Mike Hammett]

Isn't part of STIR/SHAKEN to make it easier to determine the ingress provider, 
or the provider of last blame? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Michael Thomas"  
To: "Mike Hammett" , "Shane Ronan"  
Cc: nanog@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 

- Original Message -

From: "Shane Ronan"  
To: "Michael Thomas"  
Cc: nanog@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 < m...@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" < m...@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" 
> >  > m...@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 
> > 
> 
> 

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

[Michael Thomas]

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" 
*To: *"Michael Thomas" 
*Cc: *nanog@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  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"  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"
 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
>      >
>
>

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

[Nathan Angelacos]

On Tue, 2022-10-04 at 08:05 -0600, Jawaid Bazyar wrote:
> Phone spam pretty much always involves the knowledge and involvement
> of the provider. There are no phone providers who don't know when one
> of their customers are making millions of robocalls.
> 
> International toll fraud also always involves the collusion of
> corrupt small country telephone monopolies.
> 
> So unlike email spam, where there are a million ways to send a
> million emails a minute without someone being aware, phone spam is
> definitively collisional. (Is that a word?)
> 

collusion:  

noun:
secret or illegal cooperation or conspiracy, especially in order to
cheat or deceive others.

Law:
illegal cooperation or conspiracy, especially between ostensible
opponents in a lawsuit.


Yup.  Having worked for a small VoIP provider, your comment is exactly
on point.

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

[Jawaid Bazyar]

Phone spam pretty much always involves the knowledge and involvement of the 
provider. There are no phone providers who don't know when one of their 
customers are making millions of robocalls.

International toll fraud also always involves the collusion of corrupt small 
country telephone monopolies.

So unlike email spam, where there are a million ways to send a million emails a 
minute without someone being aware, phone spam is definitively collisional. (Is 
that a word?)


On 10/3/22, 5:05 PM, "Michael Thomas"  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"  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" 
 
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
>  >
>
>

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

[Mike Hammett]

Is there any information on how much is from customers intent on fraud and how 
much is from compromised systems? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Ca By"  
To: "Mike Hammett"  
Cc: "Shane Ronan" , nanog@nanog.org 
Sent: Tuesday, October 4, 2022 8:24:07 AM 
Subject: Re: FCC chairwoman: Fines alone aren't enough (Robocalls) 







On Tue, Oct 4, 2022 at 6:20 AM Mike Hammett < na...@ics-il.net > wrote: 




Sorta like in the IP world, if everyone did BCP38/84, amplification attacks 
wouldn't exist. Not everyone does, so... 





Tragedy of the commons 


Furthermore, those customers are paying to not be policed. 









- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Mike Hammett" < na...@ics-il.net > 
To: "Shane Ronan" < sh...@ronan-online.com > 
Cc: nanog@nanog.org 
Sent: Tuesday, October 4, 2022 8:07:55 AM 



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


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. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 



From: "Shane Ronan" < sh...@ronan-online.com > 
To: "Michael Thomas" < m...@mtcc.com > 
Cc: nanog@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 < m...@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" < m...@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" 
> >  > m...@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 
> > 
> 
> 

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

[Ca By]

On Tue, Oct 4, 2022 at 6:20 AM Mike Hammett  wrote:

> Sorta like in the IP world, if everyone did BCP38/84, amplification
> attacks wouldn't exist. Not everyone does, so...
>

Tragedy of the commons

Furthermore, those customers are paying to not be policed.


>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Mike Hammett" 
> *To: *"Shane Ronan" 
> *Cc: *nanog@nanog.org
> *Sent: *Tuesday, October 4, 2022 8:07:55 AM
>
> *Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)
>
> 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.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Shane Ronan" 
> *To: *"Michael Thomas" 
> *Cc: *nanog@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  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"  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"
>> > m...@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
>> >  >
>> >
>> >
>>
>
>
>

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

[Mike Hammett]

Sorta like in the IP world, if everyone did BCP38/84, amplification attacks 
wouldn't exist. Not everyone does, so... 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Mike Hammett"  
To: "Shane Ronan"  
Cc: nanog@nanog.org 
Sent: Tuesday, October 4, 2022 8:07:55 AM 
Subject: Re: FCC chairwoman: Fines alone aren't enough (Robocalls) 


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. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Shane Ronan"  
To: "Michael Thomas"  
Cc: nanog@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 < m...@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" < m...@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" 
> >  > m...@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 
> > 
> 
> 

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

[Mike Hammett]

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. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Shane Ronan"  
To: "Michael Thomas"  
Cc: nanog@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 < m...@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" < m...@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" 
> >  > m...@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 
> > 
> 
> 

Re: Request for help: academic study (questionnaire)

[Etienne-Victor Depasquale via NANOG]

Here's an update on the analytics

.

I'm concurrently running a parallel survey with support from a market
research team.
The results will be part of a submission to a journal, with the scope of
energy-aware telecommunications.
(I admit that the work is taking longer than I expected back in June)

Any feedback/discussion which you, the prime exponents of our industry's
cutting operational edge (I am just an academic), would care to share with
me, would be a most valuable asset.

With sincere thanks and regards to all,

Etienne

On Mon, Sep 12, 2022 at 12:24 PM Etienne-Victor Depasquale 
wrote:

> I'm truly grateful for the response received
> 
> (available until Wednesday 8pm CET)
>
> I'm short on North American - headquartered telcos / MSOs; any support
> would be deeply appreciated (link to questionnaire is here
> ).
>
> With thanks,
>
> Etienne
>
> On Mon, Jul 25, 2022 at 10:09 AM Etienne-Victor Depasquale 
> wrote:
>
>> ***Apologies for cross-posting***
>>
>> Interim results
>> 
>>  (available
>> until 26th July, 10 am CET)
>>
>> Link to fill in survey  (for those
>> who have been unable to do so and might be interested in doing so).
>>
>> Sincere and heartfelt thanks to those who have already filled in the
>> survey.
>>
>> Etienne
>>
>> On Thu, Jul 21, 2022 at 12:56 PM Etienne-Victor Depasquale <
>> ed...@ieee.org> wrote:
>>
>>> Dear NANOGers,
>>>
>>> Payback time (unprocessed, interim aggregate analytics, more to come
>>> later):
>>>  Next-generation metro area networks (google.com)
>>> 
>>> ,
>>> available until tomorrow Friday 22nd 8pm CET.
>>>
>>> I need more data (42/50 received/desired - at time of publication),
>>> especially from MSOs
>>> (but please, if you can, whatever your operator genre, do
>>> answer/distribute/nudge).
>>>
>>> Cheers,
>>>
>>> Etienne
>>>
>>> On Thu, Jul 14, 2022 at 12:34 PM Etienne-Victor Depasquale <
>>> ed...@ieee.org> wrote:
>>>
 I'm at 15/50 (received/desired) responses - thank you so much to those
 who've helped.

 Please, if you can answer/distribute/nudge, it would help to make this
 study meaningful
 (for convenience: https://forms.gle/Hh4oy5DdryvQYnqJA)

 Thank you for your patience with this reminder of mine.


 Cheers,

 Etienne

 On Thu, Jul 7, 2022 at 8:38 AM Etienne-Victor Depasquale <
 ed...@ieee.org> wrote:

> Hello NANOGers,
>
>
> I'm asking for your help through your response to a questionnaire
> that forms part of an academic study that I'm carrying out
> .
>
> The study is directed solely towards facilitating understanding of
> metro area networks, for analysts who approach from the perspective of
> energy consumption.
>
> The study is anonymous (no individual or company names are solicited),
> and individual responses will only be used in aggregate.
>
> I shall send a digest of the survey to the mailing list, and will
> correspond with respondents who would like a copy of the paper which I
> intend to produce with the results.
>
>
> Yours sincerely,
>
> Etienne
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


 --
 Ing. Etienne-Victor Depasquale
 Assistant Lecturer
 Department of Communications & Computer Engineering
 Faculty of Information & Communication Technology
 University of Malta
 Web. https://www.um.edu.mt/profile/etiennedepasquale

>>>
>>>
>>> --
>>> Ing. Etienne-Victor Depasquale
>>> Assistant Lecturer
>>> Department of Communications & Computer Engineering
>>> Faculty of Information & Communication Technology
>>> University of Malta
>>> Web. https://www.um.edu.mt/profile/etiennedepasquale
>>>
>>
>>
>> --
>> Ing. Etienne-Victor Depasquale
>> Assistant Lecturer
>> Department of Communications & Computer Engineering
>> Faculty of Information & Communication Technology
>> University of Malta
>> Web. https://www.um.edu.mt/profile/etiennedepasquale
>>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer