[VoiceOps] STIR/SHAKEN warning!

Mon Jul 3 14:45:05 EDT 2023

 I would love an update here.  We are an ultra tiny MSP, and have been told
all along by the major ULCs we use that we’re fine.  They are signing, all
good.  This is a monstrous change relative to our size and capital.

On Jul 3, 2023 at 11:09:33 AM, Mary Lou Carey via VoiceOps <
voiceops at voiceops.org> wrote:

> Thanks for the input, Mark! I'm going to call my contacts at the FCC as
> well and ask specifically what their stance o this is because from what
> I've heard they plan to start enforcing STIR/SHAKEN in August. That
> could be devastating to many since so many of the underlying carriers
> have been telling their clients they don't need their own
> certificate/token.
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-1111
>
> On 2023-06-30 05:28 PM, Mark R Lindsey wrote:
>
> 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! [1]
>
>
> 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 [2]
>
> | Newsletter [3]
>
>
> > 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
>
>
>
>
> Links:
>
> ------
>
> [1]
>
>
> https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==
>
> [2] https://ecg.co/lindsey/schedule
>
> [3]
>
>
> https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/
>
> _______________________________________________
> 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/20230703/f9a6ff91/attachment-0001.htm>