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 <[email protected]> wrote: > > On 10/4/22 2:00 PM, [email protected] 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 <[email protected]> <[email protected]> > wrote: > > > > > On 10/4/22 1:40 PM, [email protected] 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 <[email protected]> <[email protected]> > 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 <[email protected]> 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" <[email protected]> <[email protected]> >> *To: *"Michael Thomas" <[email protected]> <[email protected]> >> *Cc: *[email protected] >> *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 <[email protected]> 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" <[email protected]> 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" >>> <[email protected] on behalf of >>> [email protected]> 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 >>> > > >>> > >>> > >>> >> >>
