FCC chairwoman: Fines alone aren't enough (Robocalls)
'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. [...]
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
Because it's illegal for common carriers to block traffic otherwise. On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users? Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
We're talking about blocking other carriers. On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise. Wait, what? It's illegal to police their own users? Mike > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 >
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 >
The issue isn't which 'prefixes' I accept from my customers, but which 'prefixes' I accept from the people I peer with, because it's entirely dynamic and without a doing a database dip on EVERY call, I have to assume that my peer or my peers customer or my peers peer is doing the right thing. I can't simply block traffic from a peer carrier, it's not allowed, so there has to be some mechanism to mark that a prefix should be allowed, which is what Shaken/Stir does. Shane On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this summer. > > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
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" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 < mike@mtcc.com > wrote: The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" < mike@mtcc.com > wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar= verobroadband.com@nanog.org on behalf of mike@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
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" <nanog@ics-il.net> To: "Shane Ronan" <shane@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 ----- Original Message ----- From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 < mike@mtcc.com > wrote: The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" < mike@mtcc.com > wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar= verobroadband.com@nanog.org on behalf of mike@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
On Tue, Oct 4, 2022 at 6:20 AM Mike Hammett <nanog@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" <nanog@ics-il.net> *To: *"Shane Ronan" <shane@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" <shane@ronan-online.com> *To: *"Michael Thomas" <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this summer. > > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
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" <cb.list6@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "Shane Ronan" <shane@ronan-online.com>, 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 < nanog@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. <blockquote> ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Mike Hammett" < nanog@ics-il.net > To: "Shane Ronan" < shane@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" < shane@ronan-online.com > To: "Michael Thomas" < mike@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 < mike@mtcc.com > wrote: <blockquote> The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" < mike@mtcc.com > wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar= verobroadband.com@nanog.org on behalf of mike@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
</blockquote> </blockquote>
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/
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" <nanog-bounces+rich.compton=charter.com@nanog.org on behalf of nanog@nanog.org> 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.
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago. Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> *To: *"Michael Thomas" <mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
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" <mike@mtcc.com> To: "Mike Hammett" <nanog@ics-il.net>, "Shane Ronan" <shane@ronan-online.com> 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 <blockquote> ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 < mike@mtcc.com > wrote: <blockquote> The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" < mike@mtcc.com > wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar= verobroadband.com@nanog.org on behalf of mike@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
</blockquote> </blockquote>
On 10/4/22 11:20 AM, Mike Hammett wrote:
Isn't part of STIR/SHAKEN to make it easier to determine the ingress provider, or the provider of last blame?
Not exactly. Unlike DKIM which is basically a "blame me" kind of authentication at the domain level, STIR/SHAKEN tries to solve the problem of who is allowed to use what E.164 address. You can probably educe which domain to blame from it... sort of -- I'm not familiar enough with the specifics to say how though. The object has always been to shut down open relays, and this is much much easier in the telephony space. Like for one, the FCC exists and regulates it. That is not true of email. Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Michael Thomas" <mike@mtcc.com> *To: *"Mike Hammett" <nanog@ics-il.net>, "Shane Ronan" <shane@ronan-online.com> *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" <shane@ronan-online.com> *To: *"Michael Thomas" <mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
Except the cost to do the data dips to determine the authorization isn't "free". On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this summer. > > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
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" <shane@ronan-online.com> To: "Michael Thomas" <mike@mtcc.com> Cc: "Mike Hammett" <nanog@ics-il.net>, 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 < mike@mtcc.com > wrote: On 10/4/22 6:07 AM, Mike Hammett wrote: <blockquote> 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 <blockquote> ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 < mike@mtcc.com > wrote: <blockquote> The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" < mike@mtcc.com > wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar= verobroadband.com@nanog.org on behalf of mike@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
</blockquote> </blockquote> </blockquote>
On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com. In fact, that would be a huge win since I could just use my email address book to make a call. You could tell that STIR/SHAKEN really went off the rails when it has heuristics on how to scrape E.164 addresses in the From: field. At this point we should be mostly ignoring legacy signaling, IMO. Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> *Cc: *"Mike Hammett" <nanog@ics-il.net>, 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 <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com.
You can do that all you want. You just don't get to interact with the PSTN. On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com. In fact, that would be a huge win since I could just use my email address book to make a call. You could tell that STIR/SHAKEN really went off the rails when it has heuristics on how to scrape E.164 addresses in the From: field. At this point we should be mostly ignoring legacy signaling, IMO.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@mtcc.com> *Cc: *"Mike Hammett" <nanog@ics-il.net> <nanog@ics-il.net>, 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 <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this
summer.
> > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
On 10/4/22 11:58 AM, Tom Beecher wrote:
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com.
You can do that all you want. You just don't get to interact with the PSTN.
What is the "PSTN" these days? It's a bunch of interconnected SIP proxies where there is nothing special about the identifiers used. With end to end SIP (or middle to middle, etc), the routing is not being done with e.164 addresses like in the legacy PSTN. It's just bellheaded thinking that e.164 addresses mean anything these days.The only time they make any difference is if they need to off ramp to legacy signaling which is becoming rarer and rarer. Mike
On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com. In fact, that would be a huge win since I could just use my email address book to make a call. You could tell that STIR/SHAKEN really went off the rails when it has heuristics on how to scrape E.164 addresses in the From: field. At this point we should be mostly ignoring legacy signaling, IMO.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@mtcc.com> *Cc: *"Mike Hammett" <nanog@ics-il.net> <mailto:nanog@ics-il.net>, 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 <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
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 <mike@mtcc.com> 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 mike@mtcc.com.
You can do that all you want. You just don't get to interact with the PSTN.
What is the "PSTN" these days? It's a bunch of interconnected SIP proxies where there is nothing special about the identifiers used. With end to end SIP (or middle to middle, etc), the routing is not being done with e.164 addresses like in the legacy PSTN. It's just bellheaded thinking that e.164 addresses mean anything these days.The only time they make any difference is if they need to off ramp to legacy signaling which is becoming rarer and rarer.
Mike
On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com. In fact, that would be a huge win since I could just use my email address book to make a call. You could tell that STIR/SHAKEN really went off the rails when it has heuristics on how to scrape E.164 addresses in the From: field. At this point we should be mostly ignoring legacy signaling, IMO.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@mtcc.com> *Cc: *"Mike Hammett" <nanog@ics-il.net> <nanog@ics-il.net>, 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 <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: 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 >
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 <mike@mtcc.com> 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 mike@mtcc.com.
You can do that all you want. You just don't get to interact with the PSTN. What is the "PSTN" these days? It's a bunch of interconnected SIP proxies where there is nothing special about the identifiers used. With end to end SIP (or middle to middle, etc), the routing is not being done with e.164 addresses like in the legacy PSTN. It's just bellheaded thinking that e.164 addresses mean anything these days.The only time they make any difference is if they need to off ramp to legacy signaling which is becoming rarer and rarer.
Mike
On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:31 AM, Mike Hammett wrote: What's regulated or implemented is rarely the best course of action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded insistence of still using E.164 addresses in the first place. With SIP they are complete legacy and there is no reason that my "telephone number" can't be mike@mtcc.com. In fact, that would be a huge win since I could just use my email address book to make a call. You could tell that STIR/SHAKEN really went off the rails when it has heuristics on how to scrape E.164 addresses in the From: field. At this point we should be mostly ignoring legacy signaling, IMO.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@mtcc.com> Cc: "Mike Hammett" <nanog@ics-il.net>, 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 <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote: I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization isn't "free".
Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern. Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
Except the pstn DB isn’t distributed like DNS is.
On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:21 AM, Shane Ronan wrote: Except the cost to do the data dips to determine the authorization isn't "free". Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern.
Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote: I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 >
On 10/4/22 1:40 PM, sronan@ronan-online.com wrote:
Except the pstn DB isn’t distributed like DNS is.
Yes, I had forgot about "dip" in that sense. But an originating provider doesn't need to do a dip to know that the calling number routes to itself. I've been talking about the calling provider not the called provider all along. Mike
On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization isn't "free".
Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern.
Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
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 <mike@mtcc.com> wrote:
On 10/4/22 1:40 PM, sronan@ronan-online.com wrote:
Except the pstn DB isn’t distributed like DNS is.
Yes, I had forgot about "dip" in that sense. But an originating provider doesn't need to do a dip to know that the calling number routes to itself. I've been talking about the calling provider not the called provider all along.
Mike
On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization isn't "free". Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern.
Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
From: "Shane Ronan" <shane@ronan-online.com> To: "Michael Thomas" <mike@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 <mike@mtcc.com> wrote: > The problem has always been solvable at the ingress provider. The > problem was that there was zero to negative incentive to do that. You > don't need an elaborate PKI to tell the ingress provider which prefixes > customers are allow to assert. It's pretty analogous to when submission > authentication was pretty nonexistent with email... there was no > incentive to not be an open relay sewer. Unlike email spam, SIP > signaling is pretty easy to determine whether it's spam. All it needed > was somebody to force regulation which unlike email there was always > jurisdiction with the FCC. > > Mike > > On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > > We're talking about blocking other carriers. > > > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > > Because it's illegal for common carriers to block traffic otherwise. > > > > Wait, what? It's illegal to police their own users? > > > > Mike > > > > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > > > > >
On 10/4/22 2:00 PM, sronan@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 <mike@mtcc.com> wrote:
On 10/4/22 1:40 PM, sronan@ronan-online.com wrote:
Except the pstn DB isn’t distributed like DNS is.
Yes, I had forgot about "dip" in that sense. But an originating provider doesn't need to do a dip to know that the calling number routes to itself. I've been talking about the calling provider not the called provider all along.
Mike
On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization isn't "free".
Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern.
Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------------------------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <mailto:shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mailto:mike@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 <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
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 <mike@mtcc.com> wrote:
On 10/4/22 2:00 PM, sronan@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 <mike@mtcc.com> <mike@mtcc.com> wrote:
On 10/4/22 1:40 PM, sronan@ronan-online.com wrote:
Except the pstn DB isn’t distributed like DNS is.
Yes, I had forgot about "dip" in that sense. But an originating provider doesn't need to do a dip to know that the calling number routes to itself. I've been talking about the calling provider not the called provider all along.
Mike
On Oct 4, 2022, at 2:40 PM, Michael Thomas <mike@mtcc.com> <mike@mtcc.com> wrote:
On 10/4/22 11:21 AM, Shane Ronan wrote:
Except the cost to do the data dips to determine the authorization isn't "free".
Since every http request in the universe requires a "database dip" and they are probably a billion times more common, that doesn't seem like a very compelling concern.
Mike
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <mike@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was that if everyone policed their customers, this wouldn't be a problem. Since some don't, something else needed to be tried.
Exactly. And that doesn't require an elaborate PKI. Who is allowed to use what telephone numbers is an administrative issue for the ingress provider to police. It's the equivalent to gmail not allowing me to spoof whatever email address I want. The FCC could have required that ages ago.
Mike
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
------------------------------ *From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this
summer.
> > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
I don’t think they are…
On Oct 4, 2022, at 6:54 PM, Michael Thomas <mike@mtcc.com> 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
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 <mike@mtcc.com> 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 <mike@mtcc.com<mailto:mike@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<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ics-il.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bo0uAAYDQOW8qVLoIa1ry3XqWW1fvzQl3ekm3Db77cg%3D&reserved=0> Midwest-IX http://www.midwest-ix.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.midwest-ix.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2BxqML5s%2FfiO2qJqgjTwIscrNnb%2FakGsBmNz3p07fFs%3D&reserved=0> ________________________________ From: "Shane Ronan" <shane@ronan-online.com><mailto:shane@ronan-online.com> To: "Michael Thomas" <mike@mtcc.com><mailto:mike@mtcc.com> Cc: nanog@nanog.org<mailto: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 <mike@mtcc.com<mailto:mike@mtcc.com>> wrote: The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com<mailto:mike@mtcc.com>> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org<mailto:verobroadband.com@nanog.org> on behalf of mike@mtcc.com<mailto:mike@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/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cyberscoop.com%2Ffcc-robocall-fine-database-removal%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YzrPveqbGpF%2FnpjU%2Bn9m6GTx5mhA2dG%2FzACG%2Fjmdumc%3D&reserved=0> > > > > [...] > > “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 >
I thought that SCOTUS ruled years ago that telco users possess a First Amendment right to spoof Caller ID.
If you are referring to Facebook v. Duguid , that's not what the ruling says at all. On Wed, Oct 5, 2022 at 1:23 AM Matthew Black <Matthew.Black@csulb.edu> wrote:
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 <mike@mtcc.com> *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 <mike@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 <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ics-il.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bo0uAAYDQOW8qVLoIa1ry3XqWW1fvzQl3ekm3Db77cg%3D&reserved=0>
Midwest-IX http://www.midwest-ix.com <https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.midwest-ix.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2BxqML5s%2FfiO2qJqgjTwIscrNnb%2FakGsBmNz3p07fFs%3D&reserved=0>
------------------------------
*From: *"Shane Ronan" <shane@ronan-online.com> <shane@ronan-online.com> *To: *"Michael Thomas" <mike@mtcc.com> <mike@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 <mike@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
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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/ <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cyberscoop.com%2Ffcc-robocall-fine-database-removal%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7C4f407d3657914e6e376808daa635d027%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005047301904372%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YzrPveqbGpF%2FnpjU%2Bn9m6GTx5mhA2dG%2FzACG%2Fjmdumc%3D&reserved=0> > > > > [...] > > “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
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: protocols
> > known as “STIR/SHAKEN” went fully into effect this summer. > > [...] > > Why did we need to wait for STIR/SHAKEN to do this? > > Mike >
This might have been what I read years ago: Teltech Systems Inc. v. Bryant, 5th Cir., No. 12-60027 https://news.bloomberglaw.com/us-law-week/states-cant-restrict-non-harmful-s... (requires login) https://law.justia.com/cases/federal/appellate-courts/ca5/12-60027/12-60027-... matthew From: Tom Beecher <beecher@beecher.cc> Sent: Wednesday, October 05, 2022 7:42 AM To: Matthew Black <Matthew.Black@csulb.edu> Cc: nanog@nanog.org Subject: Re: FCC chairwoman: Fines alone aren't enough (Robocalls) CAUTION: This email was sent from an external source. I thought that SCOTUS ruled years ago that telco users possess a First Amendment right to spoof Caller ID. If you are referring to Facebook v. Duguid , that's not what the ruling says at all. On Wed, Oct 5, 2022 at 1:23 AM Matthew Black <Matthew.Black@csulb.edu<mailto:Matthew.Black@csulb.edu>> wrote: 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 <mike@mtcc.com<mailto:mike@mtcc.com>> Cc: nanog@nanog.org<mailto: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 <mike@mtcc.com<mailto:mike@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<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ics-il.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7Cf4a98f61efc14329ef3508daa6dfd337%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005777501111367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ndbkfEIMzExkx0m0XlCMF9%2BG4u6J9GAHSj5vIg0Qblw%3D&reserved=0> Midwest-IX http://www.midwest-ix.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.midwest-ix.com%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7Cf4a98f61efc14329ef3508daa6dfd337%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005777501111367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=7xB9NY%2FM3cUB0iepIj4STpGARATRrzjfP7s4LOOow1M%3D&reserved=0> ________________________________ From: "Shane Ronan" <shane@ronan-online.com><mailto:shane@ronan-online.com> To: "Michael Thomas" <mike@mtcc.com><mailto:mike@mtcc.com> Cc: nanog@nanog.org<mailto: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 <mike@mtcc.com<mailto:mike@mtcc.com>> wrote: The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
We're talking about blocking other carriers.
On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com<mailto:mike@mtcc.com>> wrote:
On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > Because it's illegal for common carriers to block traffic otherwise.
Wait, what? It's illegal to police their own users?
Mike
> > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org<mailto:verobroadband.com@nanog.org> on behalf of mike@mtcc.com<mailto:mike@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/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cyberscoop.com%2Ffcc-robocall-fine-database-removal%2F&data=05%7C01%7CMatthew.Black%40csulb.edu%7Cf4a98f61efc14329ef3508daa6dfd337%7Cd175679bacd34644be82af041982977a%7C0%7C0%7C638005777501111367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=jfEzkwQBQcXnLbS2ViJF0%2FCIGi8CafnEu8DLiIh7ETM%3D&reserved=0> > > > > [...] > > “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 >
----- On Oct 5, 2022, at 5:25 PM, Matthew Black Matthew.Black@csulb.edu wrote: Hi Matthew,
This might have been what I read years ago:
Teltech Systems Inc. v. Bryant, 5th Cir., No. 12-60027
This case does not permit spoofing based on the First Amendment. In fact, the court's opinion explicitly refuses to discuss First Amendment issues:
Because we hold ASA is conflict-preempted by TCIA, we need not consider its validity under the dormant Commerce Clause or First Amendment.
In other words: the court ruled that the Federal TCIA preempts (overrules) the state's ASA. In this case, the state statute was more restrictive than the federal statute. The court merely set aside the state law in favor of the less restrictive federal law. The TCIA defines harmful spoofing as done with: "intent to defraud, cause harm, or wrongfully obtain anything of value" The ASA defines harmful spoofing as done with: "with the intent to deceive, defraud or mislead the recipient of a call" The court says here:
ASA is more restrictive than TCIA. On the one hand, spoofing done with "intent to defraud, cause harm, or wrongfully obtain anything of value" (harmful spoofing), in violation of TCIA, is also violative of ASA. On the other hand, spoofing done without such intent, but "with the intent to deceive . . . or mislead [**4] the recipient of the call" (non-harmful spoofing), violates only ASA.
Thus, such spoofing may still be a violation of federal law. A competent lawyer can tell you more :-) Thanks, Sabri
It appears that Matthew Black <Matthew.Black@csulb.edu> said:
-=-=-=-=-=- This might have been what I read years ago:
Teltech Systems Inc. v. Bryant, 5th Cir., No. 12-60027
No, that just said that federal law preempts a Mississippi state law that purported to regulate Caller ID. The federal law in 47 USC 227(e) says: (1)In general It shall be unlawful for any person within the United States, or any person outside the United States if the recipient is within the United States, in connection with any voice service or text messaging service, to cause any caller identification service to knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value, unless such transmission is exempted pursuant to paragraph (3)(B). In (3)(B) is a narrow carve-out for law enforcement and court orders. The important point is that spoofing is illegal with fraudulent intent, OK with benign intent. R's, John
The federal law in 47 USC 227(e) says:
(1)In general
It shall be unlawful for any person within the United States, or any person outside the United States if the recipient is within the United States, in connection with any voice service or text messaging service, to cause any caller identification service to knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value, unless such transmission is exempted pursuant to paragraph (3)(B).
In (3)(B) is a narrow carve-out for law enforcement and court orders.
The important point is that spoofing is illegal with fraudulent intent, OK with benign intent.
This is a very interesting conversation as there is a ongoing discussion on how to ban spoofed calls here in Italy.. Here operators must identify each customer and ensure that they are screening incoming numbers. Most do, but some do not and become sources of spoofed traffic. The biggest problem however comes from out of country originators that allow foreign call centers to use Italian numbers. Thus the calls come in from an international carrier. We are moving twords blocking incoming calls from international trunks containing Italian from numbers, something we see already in place for carriers in other EU countries such as France. Most operators here have been against stir/shaken as a means to resolve the problems. Brian
On 10/7/22 12:45 AM, Brian Turnbow via NANOG wrote:
The federal law in 47 USC 227(e) says:
(1)In general
It shall be unlawful for any person within the United States, or any person outside the United States if the recipient is within the United States, in connection with any voice service or text messaging service, to cause any caller identification service to knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value, unless such transmission is exempted pursuant to paragraph (3)(B).
In (3)(B) is a narrow carve-out for law enforcement and court orders.
The important point is that spoofing is illegal with fraudulent intent, OK with benign intent. This is a very interesting conversation as there is a ongoing discussion on how to ban spoofed calls here in Italy.. Here operators must identify each customer and ensure that they are screening incoming numbers. I assume by "incoming" you mean incoming from the customer? That is, you're making sure your customers are not spoofing? Most do, but some do not and become sources of spoofed traffic. The biggest problem however comes from out of country originators that allow foreign call centers to use Italian numbers. Are these spoofed or are they actually allocated to them? If they are actually allocated, their upstream provider should be enforcing too, right? Thus the calls come in from an international carrier. We are moving twords blocking incoming calls from international trunks containing Italian from numbers, something we see already in place for carriers in other EU countries such as France. On the other hand, this makes your "incoming" above sound like incoming from the phone network. So I'm probably confused. Most operators here have been against stir/shaken as a means to resolve the problems.
What reasons? Mike
Hi,
Most operators here have been against stir/shaken as a means to resolve the problems.
What reasons?
That it is complex and would take too much time and money, that it is only effective if done on international level and should only be done if decided on a European level. Without international support it would have little or no effect on robocall/spoofed calls. It is funny because when the topic first came up years ago some proposed creating a dedicated blockchain service... now that would not be complex nor costly... Brian
Dear Brian, et al.: 0) Thanks for sharing the Robocall situation in Italy. This confirms that the RoboCall phenomenon is now universal, not just in US. Although, from my experience, I am not surprised at all. 1) Based on my best understanding, I believe that the entire issue has been handled backwards, upside down or outside in. I have been waiting for what FCC's latest STIR/SHAKEN directive might be able to do. Its technicality sounded very impressive. It did seem to have some effect on Robocalls. As a consumer, however, this current approach has defeated the basic purpose of the original Caller-ID service. Apparently, true telephony (common) carriers have begun to ask to be compensated for accessing their subscriber database in the process of validating a caller by other (such as VoIP) operators. (In the old days of monopoly, this was not an issue because it would be reciprocal within the same carrier, or among a limited few similar ones.) As a consequence, Caller-ID displays of most incoming telephone calls nowadays often lack the caller names which was the key ingredient of the feature. They are replaced by a duplicated "caller number", or at best prefixed such with a "[V]" symbol which took me awhile to realize what it meant. This is very annoying since most people can't correlate such to more than a couple phone numbers of close relatives or associates, on the fly. However, this resultant system behavior serves RoboCallers' purpose just fine, because the repeated and persisted ringing sound from unknown callers disturb the called party sufficiently to the point of answering, once again. 2) The whole subject can be looked at from a very simple perspective such as a daily routine of accessing a premises for delivering something. We all know that the location of a property is publicly known by its street address. Any and every one can get to it. To control the access, a key to the lock on the door has to be given to only a welcomed few. For an establishment, a receptionist or a security guard serves the same purpose during business hours. 3) For postal services, a mail box at the entrance to a property or a mail room at an establshiment has been used for the above "buffering" purpose to deal with the junk mail. So far, these traditional setups have worked reasonably well for centuries. 4) When telephony was initially introduced, it was regarded as a novelty. Getting a call was a big event. No one had the notion about blocking any calls. Later on, the "caller pays only if a call is answered" convention led to the alerting device (the ringer) purposely made loud enough to be sure that the called party would be pressured to answer the call. During the manual switchboard days, operators screened the callers very effectively, because practically every caller was known to the operator. 5) To avoid disturbing workers by random calls, a receptionist / telephone operator was tasked with this "buffering" duty at any sizable establishment. As telephone switching equipment got mechanized, the combined DID (Direct Inward Dialing), VM (Voice Mail) and AA (Auto-Attendant) technologies took over this function. So, majority workers at institutions and businesses (except those served by CENTREX - CENTRal EXchange, because each is on a direct public phone number) have hardly ever been bothered by unwanted calls, even to the modern days. 6) As per-call charge dropped significantly, largely encouraged by bulk rates, then furthered by VoIP technology, the unwanted calls ranging from harassment, telemarketing to scam, etc. skyrocketed. Not knowing the extension numbers behind PABX (Private Automatic Branch eXchange) machines, Robocalls target private residences most of the time. 7) By miniaturizing DID, VM and AA subsystems, even residential single line telephone service could be shielded from RoboCalls just as well, as disclosed by US Pat. No.5,596,631. It was commercialized as a product called TriVOX VN100 (See URL below) that enabled a home owner to set a changeable combination lock at his telephone demarcation point for blocking all calls, except those welcomed callers who have been given the code (extension number). This effectively blocked all unwanted calls regardless the type, even though some might be legally exempted, such as political, religious or charitable, etc. However, FTC and FCC decided to take other routes. https://www.avinta.com/products-1/uwc/home/uwchme.htm 8) The Internet SPAM eMail issue can be parsed down to very similar components. In the earlier days, digital communication was established end-to-end directly via dial-up modems. Following the PSTN protocol and log-in procedure, the involved steps discouraged most of the abuse. Once the electronic messaging traffic got consolidated to limited few providers with store-and-forward facility, the screening function became part of their services. Behind the scene, they often ratchet up the screening process against one another with various new "rules", making the users frustrated about why certain routine eMails all of a sudden got bounced. In the meantime, there has been an add-on function offered by certain eMail services that buffers messages from unknown origin until the intended recipient grants the permission to let it through. However, it never seems to have caught on. 9) These days, RoboCalls and SPAMs are out-of-control activities wasting so much resources, not mentioning the aggravation imposed on ordinary citizens. However, looping these back to the "limited key distribution for the front door lock" analogy, STIR/SHAKEN and eMail servers policing one another may not be the optimal approaches. That is, if everyone has the freedom of having the key to any property, while the targeted party is at the mercy of remote unknown third party locksmiths who promise to do their best to disable those "illegal" keys somehow, how good the result could be? Since the basic nature of a communications provider, no matter whether it is a common carrier or a VoIP provider, is always to get the message delivered, the current screening schemes are against their very business model. This is kind like relying coyotes to guard a chicken coop. Does any of them have any incentive to perform well? Perhaps, FCC realizing fines aren't enough is finally validating this contradiction. 10) This line of analysis may be similarly applied to a couple other Internet related issues. However, I shall withhold them for another day. Regards, Abe (2022-10-09 12:09 EDT) P.S.: The VN100 mentioned in Pt. 7) above was a feasibility demonstration product. At that time, the size and cost of sub-systems involved were still bulky and expensive. All needed capabilities are now built into the basic SmartPhones. So, the required functionalities may be performed by a straightforward add-on APP. As well, the currently available IC devices make it feasible to build a compact stand-alone "VN100 + VM" module for supporting POTS (either landline or VoIP derived) configurations. So, an updated distributed defense system against RoboCall may now be deployed cost effectively. Since the enforceable life of US Pat. No. 5,596,631 has expired, any party recognizing the potential of applying this technology to benefit citizens of your region, please contact me offline. We will be glad to share our knowledge about this alternative. On 2022-10-07 03:45, Brian Turnbow via NANOG wrote:
The federal law in 47 USC 227(e) says:
(1)In general
It shall be unlawful for any person within the United States, or any person outside the United States if the recipient is within the United States, in connection with any voice service or text messaging service, to cause any caller identification service to knowingly transmit misleading or inaccurate caller identification information with the intent to defraud, cause harm, or wrongfully obtain anything of value, unless such transmission is exempted pursuant to paragraph (3)(B).
In (3)(B) is a narrow carve-out for law enforcement and court orders.
The important point is that spoofing is illegal with fraudulent intent, OK with benign intent. This is a very interesting conversation as there is a ongoing discussion on how to ban spoofed calls here in Italy.. Here operators must identify each customer and ensure that they are screening incoming numbers. Most do, but some do not and become sources of spoofed traffic. The biggest problem however comes from out of country originators that allow foreign call centers to use Italian numbers. Thus the calls come in from an international carrier. We are moving twords blocking incoming calls from international trunks containing Italian from numbers, something we see already in place for carriers in other EU countries such as France. Most operators here have been against stir/shaken as a means to resolve the problems.
Brian
-- This email has been checked for viruses by Avast antivirus software. www.avast.com
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 beckman@angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------
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
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 <mike@mtcc.com> 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
On Tue, Oct 4, 2022 at 8:36 PM <sronan@ronan-online.com> 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.
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 <morrowc.lists@gmail.com> wrote:
On Tue, Oct 4, 2022 at 8:36 PM <sronan@ronan-online.com> 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.
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" <mike@mtcc.com> wrote: The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC. Mike On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
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.
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" <mike@mtcc.com> wrote:
The problem has always been solvable at the ingress provider. The problem was that there was zero to negative incentive to do that. You don't need an elaborate PKI to tell the ingress provider which prefixes customers are allow to assert. It's pretty analogous to when submission authentication was pretty nonexistent with email... there was no incentive to not be an open relay sewer. Unlike email spam, SIP signaling is pretty easy to determine whether it's spam. All it needed was somebody to force regulation which unlike email there was always jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote: > We're talking about blocking other carriers. > > On 10/3/22, 3:05 PM, "Michael Thomas" <mike@mtcc.com> wrote: > > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: > > Because it's illegal for common carriers to block traffic otherwise. > > Wait, what? It's illegal to police their own users? > > Mike > > > > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" <nanog-bounces+jbazyar=verobroadband.com@nanog.org on behalf of mike@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 > > > >
On October 3, 2022 at 16:05 mike@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 | bzs@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*
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, bzs@theworld.com wrote:
On October 3, 2022 at 16:05 mike@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.
participants (20)
-
Abraham Y. Chen -
Brian Turnbow -
bzs＠theworld.com -
Ca By -
Christopher Morrow -
Clayton Zekelman -
Compton, Rich A -
Jawaid Bazyar -
John Levine -
Matthew Black -
Michael Thomas -
Mike Hammett -
Nathan Angelacos -
Peter Beckman -
Robert Blayzor -
Sabri Berisha -
Sean Donelan -
Shane Ronan -
sronan＠ronan-online.com -
Tom Beecher