<div dir="ltr">Nathan,<br><br>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<div>- For some carriers regardless of what we sent attestation always seemed to have come back as B.<br>- For others where we send a self signed cert the attestation always comes back as C.<br>- 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.<br>- 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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 27, 2022 at 7:47 PM Nathan Anderson <<a href="mailto:nathana@fsr.com">nathana@fsr.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Carlos,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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 *<b>shrug*</b>.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...)</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
At the moment, here is where I stand:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
-- Nathan</div>
<div id="gmail-m_399748475416406296signature_bookmark"></div>
<div id="gmail-m_399748475416406296appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_399748475416406296divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Carlos Perez <<a href="mailto:cperez@sansay.com" target="_blank">cperez@sansay.com</a>><br>
<b>Sent:</b> Monday, June 27, 2022 3:37 PM<br>
<b>To:</b> Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>><br>
<b>Cc:</b> Voiceops.org <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject:</b> Re: [VoiceOps] SHAKEN testing services</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi Nathan,</div>
<div><br>
</div>
<div>We've put together something like you've requested (also open to the public) recently.
<br>
</div>
<div>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.
<span>Feel free to dial +18586098097.</span></div>
<div><span><br>
</span></div>
<div><span>Regards,<br>
</span></div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>
<div>Carlos Perez</div>
<div>Sansay, Inc.</div>
<div>
<div>
<div>+1 858-754-2216 Direct</div>
<div>+1 858-754-2211 Support<br>
</div>
<div>+1-858-754-2200 Main</div>
<div><br>
</div>
<div><a href="https://calendly.com/cperez-sansay/30min" target="_blank">https://calendly.com/cperez-sansay/30min</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div>
<div dir="ltr">On Mon, Jun 27, 2022 at 3:34 PM Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.)<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
-- Nathan<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div>