[VoiceOps] STIR/SHAKEN warning!

Mary Lou Carey marylou at backuptelecom.com
Mon Jul 3 14:53:32 EDT 2023 

My understanding is that they can still sign for you, but they should be 
signing with YOUR certificate/token and not their own. That only adds 
the cost of the certificate/token to your budget.

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-1111

On 2023-07-03 01:45 PM, Carlos Alvarez via VoiceOps wrote:
> 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
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

More information about the VoiceOps mailing list