I knew Gavin Belson was behind this. — Sent from mobile, with due apologies for brevity and errors.
> On Dec 17, 2019, at 4:07 PM, Paul Timmins <[email protected]> wrote: > > > I see it as stopping fraud the same way SPF and DKIM stopped spam. > > On 12/17/19 3:38 PM, Dovid Bender wrote: >> Mike beat me to it. It's going to stop fraud. The bigger issue you are going >> to have is the larger packets. So many devices out there can't seem to >> fragment packets correctly. >> >> >> On Tue, Dec 17, 2019 at 3:28 PM <[email protected]> wrote: >>> Hi Peter, >>> >>> Good question. First, if you're using Hooli, you'll have to migrate to >>> Pipernet sooner or later. Their middle-out compression provides much better >>> call quality so it's worth the effort to migrate. >>> >>> But to the issue you raised, the purpose of STIR/SHAKEN is not to block >>> robocalls per se, it is to provide an authentication chain so that you can >>> determine and contact the originating carrier regardless of the route the >>> call took to reach the terminating side. This has been a big issue; many >>> VoIP companies hand off calls to large indifferent CLEC or IXCs who send >>> them everywhere but won't respond to the terminating carrier's fraud and >>> nuisance requests. >>> >>> So, now we can see that the call was attested by Hooli, and if Hooli does >>> not cooperate with our fraud/nuisance investigations we are now authorized >>> to block traffic signed by Hooli. That does fix the problem to a large >>> degree. >>> >>> However, it's also worthy of note that this is not the main problem that >>> needs to be solved. The main problem that needs to be solved is the case >>> where you are sending the call to Hooli originating from a number that is >>> assigned to our CLEC, which you don't have permission to use. This does >>> solve that problem, because Hooli is only going to issue partial attestation >>> for that call since it's not their number. So we can still contact Hooli >>> about it because they attested it and from that I can find them, but we or >>> our subscriber can also block calls with partial attestations if we/they >>> choose to. >>> >>> Regards, >>> >>> Mike >>> >>> Mike Ray, MBA, CNE, CTE >>> Astro Companies, LLC >>> 11523 Palm Brush Trail #401 >>> Lakewood Ranch, FL 34202 >>> DIRECT: call or text 941 600-0207 >>> http://www.astrocompanies.com >>> >>> -----Original Message----- >>> From: VoiceOps <[email protected]> On Behalf Of Peter Beckman >>> Sent: Tuesday, December 17, 2019 2:58 PM >>> To: VoiceOps <[email protected]> >>> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help? >>> >>> A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. >>> They didn't get deep into the technical details but there were a bunch of >>> big carrier representatives there. >>> >>> If you haven't followed STIR/SHAKEN, it's really just an additional SIP >>> header that contains cryptographically-signed information about the origin >>> point of the call. >>> >>> You can verify the signature with publically published public keys so you >>> know whomever signed it is really them. >>> >>> Here's a few resources if you want to learn more: >>> >>> https://www.bandwidth.com/glossary/stir-shaken/ >>> https://www.fcc.gov/call-authentication >>> https://en.wikipedia.org/wiki/STIR/SHAKEN >>> https://www.home.neustar/stir-shaken-resource-hub >>> >>> There are three levels to tell you how much you should trust the origin of >>> the call: >>> >>> 1. Full -- The call came from the originating carrier's customer and is >>> authorized to use the number >>> >>> 2. Partial -- The call came from the originating carrier's customer but >>> may or may not be authorized to use the number >>> >>> 3. Gateway -- The carrier has authenticated from where it received the >>> call, but cannot authenticate the call source (e.g., International >>> Gateway call). >>> >>> As an example, as will be many legit cases, a Verizon Wireless mobile >>> customer will place a call, which will route to Verizon, who will sign the >>> call using STIR/SHAKEN with Full Attestation and we can all "trust" the >>> call. >>> >>> But now we throw in VoIP. >>> >>> I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my >>> calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call >>> from me (their customer) with a valid CallerID I'm authorized to use and so >>> Hooli signs the call with STIR/SHAKEN with Full Attestation. >>> >>> Turns out the call was a robocall. >>> >>> What changes? The only thing that changes is that the receiving party, say >>> Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's >>> customer, so how does Soylent complain to Hooli about the content of the >>> call? >>> >>> And as carriers, we are not legally responsible for the content of our >>> customer's calls. >>> >>> How will Soylent accept 90% of Hooli's Fully Attested valid traffic but >>> avoid the 10% that is spam/robocalls that are ALSO Fully Attested? >>> >>> How exactly does STIR/SHAKEN help fix the robocall and spam call problem? >>> >>> Yes, I could block all of Hooli's calls where the attestation is Partial or >>> Gateway, but you run the risk of false positives, especially in the >>> International category, or just when Hooli isn't sure, like when I rent a >>> DID from Acme but do termination through Hooli -- Hooli doesn't know that I >>> am authorized to use that DID from Acme, even though I am, so Hooli has to >>> mark my call as Partial or Gateway. >>> >>> I'm all for reducing annoying spam and robocalls, but I'm still not yet >>> convinced that STIR/SHAKEN is going to materially reduce them. >>> >>> Let's discuss! >>> >>> Beckman >>> --------------------------------------------------------------------------- >>> Peter Beckman Internet Guy >>> [email protected] http://www.angryox.com/ >>> --------------------------------------------------------------------------- >>> _______________________________________________ >>> VoiceOps mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/voiceops >>> >>> _______________________________________________ >>> VoiceOps mailing list >>> [email protected] >>> https://puck.nether.net/mailman/listinfo/voiceops >> >> >> _______________________________________________ >> VoiceOps mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/voiceops > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
