On Tue, Oct 4, 2022 at 6:20 AM Mike Hammett <na...@ics-il.net> wrote:
> Sorta like in the IP world, if everyone did BCP38/84, amplification > attacks wouldn't exist. Not everyone does, so... > Tragedy of the commons Furthermore, those customers are paying to not be policed. > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Mike Hammett" <na...@ics-il.net> > *To: *"Shane Ronan" <sh...@ronan-online.com> > *Cc: *nanog@nanog.org > *Sent: *Tuesday, October 4, 2022 8:07:55 AM > > *Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls) > > I think the point the other Mike was trying to make was that if everyone > policed their customers, this wouldn't be a problem. Since some don't, > something else needed to be tried. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ------------------------------ > *From: *"Shane Ronan" <sh...@ronan-online.com> > *To: *"Michael Thomas" <m...@mtcc.com> > *Cc: *nanog@nanog.org > *Sent: *Monday, October 3, 2022 9:54:07 PM > *Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls) > > The issue isn't which 'prefixes' I accept from my customers, but which > 'prefixes' I accept from the people I peer with, because it's entirely > dynamic and without a doing a database dip on EVERY call, I have to assume > that my peer or my peers customer or my peers peer is doing the right thing. > > I can't simply block traffic from a peer carrier, it's not allowed, so > there has to be some mechanism to mark that a prefix should be allowed, > which is what Shaken/Stir does. > > Shane > > > > On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas <m...@mtcc.com> wrote: > >> The problem has always been solvable at the ingress provider. The >> problem was that there was zero to negative incentive to do that. You >> don't need an elaborate PKI to tell the ingress provider which prefixes >> customers are allow to assert. It's pretty analogous to when submission >> authentication was pretty nonexistent with email... there was no >> incentive to not be an open relay sewer. Unlike email spam, SIP >> signaling is pretty easy to determine whether it's spam. All it needed >> was somebody to force regulation which unlike email there was always >> jurisdiction with the FCC. >> >> Mike >> >> On 10/3/22 3:13 PM, Jawaid Bazyar wrote: >> > We're talking about blocking other carriers. >> > >> > On 10/3/22, 3:05 PM, "Michael Thomas" <m...@mtcc.com> wrote: >> > >> > On 10/3/22 1:54 PM, Jawaid Bazyar wrote: >> > > Because it's illegal for common carriers to block traffic >> otherwise. >> > >> > Wait, what? It's illegal to police their own users? >> > >> > Mike >> > >> > > >> > > On 10/3/22, 2:53 PM, "NANOG on behalf of Michael Thomas" >> <nanog-bounces+jbazyar=verobroadband....@nanog.org on behalf of >> m...@mtcc.com> wrote: >> > > >> > > >> > > On 10/3/22 1:34 PM, Sean Donelan wrote: >> > > > 'Fines alone aren't enough:' FCC threatens to blacklist >> voice >> > > > providers for flouting robocall rules >> > > > >> > > > >> https://www.cyberscoop.com/fcc-robocall-fine-database-removal/ >> > > > >> > > > [...] >> > > > “This is a new era. If a provider doesn’t meet its >> obligations under >> > > > the law, it now faces expulsion from America’s phone >> networks. Fines >> > > > alone aren’t enough,” FCC chairwoman Jessica Rosenworcel >> said in a >> > > > statement accompanying the announcement. “Providers that >> don’t 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 >> > > >> > >> > >> > > >
