[VoiceOps] STIR/SHAKEN warning!
Mark R Lindsey
lindsey at e-c-group.com
Fri Jun 30 18:28:06 EDT 2023
Like Mary Lou, I'd like to help all voice service providers get their STIR/SHAKEN implementations up and running. And it's crucial to do verification as well as attestation! <https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==>
There are a lot of good options -- I'm personally seeing a lot of activity around Neustar, Sansay, and Transnexus. I personally like to implement the HTTPS REST interface, but most implementations are doing it with SIP and 302. I think I've configured over 10 different variations so far. There are tons of technical methods.
BUT... the rules on this third-party SHAKEN are not completely clear cut; I tell my clients that "the jury is still out," because the FCC is still seeking comment on whether this is appropriate. I'm expecting rules to be issued clarifying it.
To read more about where the FCC is on this, see the section starting at Paragraph 99 in FCC-23-18A1 published March 17, 2023:
We seek comment on whether, and under what circumstances, a third party may authenticate calls on behalf of a provider with A- or B-level attestations consistent with the ATIS standards. Pursuant to ATIS-1000074, in order to apply a B-level attestation for a call, the signing party must originate the call onto the IP-based service network and have a direct authenticated relationship with the customer.An A-level attestation additionally requires the signing provider to establish a verified association with the telephone number used for the call.341 Can a third-party authenticating a call on behalf of an originating provider satisfy all or any these criteria, and if so, how? Does the answer to that question depend on the nature of the relationship between the originating provider and the third party? For instance, is it possible for a third party that is a wholesale provider for a reseller, or an intermediate provider, to apply A- or B-level attestations on behalf of an originating provider in a manner that complies with the ATIS attestation-level criteria, but not a different type of third party? Are there third parties authenticating calls on behalf of originating providers that can only apply C-level attestations under the ATIS criteria? If commenters contend that third parties can meet the ATIS criteria for signing calls with A- and B-level attestations because they effectively stand in the shoes of the originating provider with the direct relationship with the customer, we ask that they specify the legal bases for that conclusion, e.g., the specific grounds for an agency theory, if any, and/or how the terms of the ATIS standards may be construed to include the third-party arrangement.
To the extent commenters contend that third parties may satisfy the criteria to sign calls with A- or B-level attestations, what information must be shared between originating providers and third parties for those attestation levels to be applied, is that information sharing occurring, and does it implicate any legal or public interest concerns, including privacy concerns?
Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf
Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting <https://ecg.co/lindsey/schedule> | Newsletter <https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>
> On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps <voiceops at voiceops.org> wrote:
>
> I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them.
>
> THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token!
>
> It doesn't matter if you're a reseller or a facilities-based carrier. Whoever bills the customer is the carrier of record and is responsible for signing the customer's calls with THEIR OWN certificate/token. While an upstream carrier can sign calls for your company, they must sign with YOUR certificate/token - not their own because they don't have a direct connection with your customer.
>
> Please understand that you're putting your network at risk when you share a token with another company because there's no way to differentiate between traffic when it's all under the same certificate/token. If your upstream carrier signs all their customer's traffic with their token, it only takes one bad customer to shut their whole network down. The only way to protect your company from other companies' mistakes is to make sure your upstream carrier is signing your calls with your certificate/token.
>
> One may not think they can get away with using someone else's certificate/token because it would be difficult to monitor the call stream for offenders. Let me just tell you the ITG can easily compare the Robocall Mitigation Database with the Approved Carriers list to locate the companies that don't have their own certificate/token. They don't need to look at traffic to determine that.
>
> Please don't play Russian roulette with your company because it's not worth losing your whole business over the cost of a certificate/token. Getting your own certificate/token can take anywhere from 2 weeks to 2 months depending on where you are in the process. From what I've heard, the FCC will start blocking traffic in August so if you haven't started the process....do so now!
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-1111
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20230630/fc748658/attachment-0001.htm>
More information about the VoiceOps
mailing list