[VoiceOps] SHAKEN testing services

[Dovid Bender]

Nathan,

Could it be your carriers that are dropping the headers? We have tested
with a self signed cert and expected to have issues across the board. I
don't want to name shame so overall using a few carriers to terminate calls
to call Sansays number this is what we found
- For some carriers regardless of what we sent attestation always seemed to
have come back as B.
- For others where we send a self signed cert the attestation always comes
back as C.
- For the carriers where if we send a self signed cert it comes in as C,
if we send nothing the call comes in as B.
- Looking at our apache logs we mainly see Verizon wireless getting our
certs (could be others are caching?).  Surprisingly #2 is Telnyx followed
by random requests from AWS, Google and MS IP's.

On Mon, Jun 27, 2022 at 7:47 PM Nathan Anderson <nathana at fsr.com> wrote:

> Carlos,
>
> Nifty; thanks.  Unfortunately, I tried calling via 2 different carriers
> who both pass through Identity headers if supplied, but got
> No-TN-Validation result both times, implying that the PASSporT is getting
> stripped out somewhere along the way.  Your number looks to be supplied by
> Level3, so a bit surprised at this result since I know for a fact both of
> the services I tried have direct relationships with L3 & so I would think
> that they'd look-up LRN & then try to send the call direct to them rather
> than punt it to their LCRs, but **shrug**​.
>
> I don't have direct access to L3/Lumen term...any chance I can send the
> INVITE directly to an SBC on your side to just bypass the problematic
> path(s)?  (I presume I'd have to supply you with an IP on our side for you
> to whitelist...)
>
> If I get a failed validation result from the service, is it possible for
> somebody at Sansay look up on your side what specific part of the
> validation failed for a given call?
>
> At the moment, here is where I stand:
>
> Found a Voxbeam number (302-257-7304) that will read back attestation
> level.  This will read back exactly the attestation level that I supply in
> the PASSporT that I attach to the call, but it "works" regardless of
> whether I'm using self-signed testing cert or an actual, valid SHAKEN
> cert.  So this service doesn't actually seem to be validating anything.  At
> least I know that Identity header is making it all the way there & that
> it's encoded properly...
>
> IDT's service, on the other hand, will show that validation passed and the
> correct attestation level if I do not transmit my own Identity header, and
> instead have upstream carrier attest it themselves.  However, if I send our
> own Identity header using *either* our self-signed cert *or* our Sansay
> SHAKEN cert, I get "N/A - problematic" as the result, with no other
> explanation.
>
> If the Sansay testing service ends up having no problem validating our
> PASSporTs, that will be reassuring from one perspective, but concerning
> from another (why can IDT not validate any of our calls that we sign
> ourselves using our production cert, but Sansay can?).  So I'm kinda
> rooting for the Sansay test service to fail when validating our calls...
>
> -- Nathan
>
> ------------------------------
> *From:* Carlos Perez <cperez at sansay.com>
> *Sent:* Monday, June 27, 2022 3:37 PM
> *To:* Nathan Anderson <nathana at fsr.com>
> *Cc:* Voiceops.org <voiceops at voiceops.org>
> *Subject:* Re: [VoiceOps] SHAKEN testing services
>
> Hi Nathan,
>
> We've put together something like you've requested (also open to the
> public) recently.
> In the future we will also provide the SPID in the report, right now you
> get the status of the validation (Passed, Failed, No Validation) and the
> attestation level. Feel free to dial +18586098097.
>
> Regards,
>
> Carlos Perez
> Sansay, Inc.
> +1 858-754-2216 Direct
> +1 858-754-2211 Support
> +1-858-754-2200 Main
>
> https://calendly.com/cperez-sansay/30min
>
>
> On Mon, Jun 27, 2022 at 3:34 PM Nathan Anderson <nathana at fsr.com> wrote:
>
> Is there a list somewhere of third-party SHAKEN testing services available
> to the public?  Although our own STI-VS can validate our own PASSporTs
> signed by our newly-minted private key, I want to verify what the world
> at-large is seeing before I flip the switch on for all outgoing calls (&
> potentially cause a bunch of problems if it turns out that something's
> wrong).  So I'm envisioning something along the lines of a phone # one can
> call, and then get a report back of whether the terminating provider was
> able to validate the contents of the Identity header or not, and if not
> what the exact problem is.  (Obviously the path between us and them would
> need to be IP end-to-end unless out-of-band SHAKEN is in place for the PSTN
> "glue" circuit.)
>
> I've found a couple, but the results for the ones I've tried (e.g., IDT
> BYOC) are woefully simplistic and don't really explain what went wrong if
> something does go wrong.
>
> Thanks,
>
> -- Nathan
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20220628/6d16cbdf/attachment-0001.htm>