[VoiceOps] SHAKEN testing services

Tue Jun 28 18:05:36 EDT 2022

I've also been unsure how the ANI should be encoded in the Identity header.
Before S/S, most termination vendors wanted the CallerID to be in 10 digit
form without a leading +1. Only a couple vendors could support e164 format
with a leading + or +1.

On Tue, Jun 28, 2022 at 2:14 PM Nathan Anderson <nathana at fsr.com> wrote:

> Following up here to let you all know that after consulting with Carlos,
> the only obvious difference that could be seen between our PASSporTs that
> were not being validated by both the Sansay & IDT tools and the ones being
> generated by our upstreams that were being validated, was that we were
> formatting the origination and destination numbers in globalized E.164
> format within the PASSporT JWT, complete with the + prefix, while the
> others included the U.S. country code of 1 but no + prefix.
>
> I removed the +, and instantly both the Sansay and IDC tools could decode
> and verify our PASSporTs.
>
> Much thanks to Carlos and Sansay for the assist in hunting this down.
>
> -- Nathan
> ------------------------------
> *From:* VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nathan
> Anderson <nathana at fsr.com>
> *Sent:* Tuesday, June 28, 2022 1:24 PM
> *To:* Dovid Bender <dovid at telecurve.com>
> *Cc:* Voiceops.org <voiceops at voiceops.org>
> *Subject:* Re: [VoiceOps] SHAKEN testing services
>
> Dovid,
>
> Our carriers swear up and down they are passing the Identity header we are
> sending to them; I opened tickets with them to verify.  And that if we do
> not send an Identity header, both of them will attest the call themselves.
>
> At this point, I also have no reason to doubt them, because we are getting
> identical results across two different carriers, and upon further testing,
> what I've found is that if we *don't* send our own Identity header, our
> calls pass validation with the PASSporT that our carriers generate & send.
> It's when we send our own that we get the "No-TN-Validation" result back
> from the Sansay test number.  Which now makes me suspect that there must be
> something wrong with what we're doing (even though that Voxbeam number that
> I referenced in my prior response has no problem reading back our
> attestation level to us).  I just don't know *what* is wrong, because none
> of these testing services actually give back detailed info about the mode
> of failure in the case of a problem.
>
> I've reached out to Carlos/Sansay to see if they can pull logs on their
> side in order to tell me what they're seeing when we call their number.
>
> You also implied that when you call the Sansay test number, you actually
> get back an attestation level from it.  That also has not been our
> experience: the Sansay number tells us whether the TN validation passed,
> failed, or is simply unvalidated...it doesn't read back the attestation
> level if it passes.  So I'm not sure why your experience is different
> there, unless you mistakenly wrote "Sansays number" when you meant
> something else (like "Voxbeam number" maybe).
>
> -- Nathan
>
> ------------------------------
> *From:* Dovid Bender <dovid at telecurve.com>
> *Sent:* Tuesday, June 28, 2022 3:18 AM
> *To:* Nathan Anderson <nathana at fsr.com>
> *Cc:* Carlos Perez <cperez at sansay.com>; Voiceops.org <
> voiceops at voiceops.org>
> *Subject:* Re: [VoiceOps] SHAKEN testing services
>
> 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
>
> _______________________________________________
> 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/d235ffe6/attachment.htm>