Allowing the unrestricted laundering of all calls placed through their network under their own “B” attestation, uncritically and without differentiation, and without regard to any already-present attestation, is becoming a common intermediate service provider decision.
> On Jul 5, 2022, at 3:02 PM, Calvin Ellison <calvin.elli...@voxox.com> wrote: > > What are your opinions regarding intermediate carriers signing unattested > calls? Not to say they are the source of the call, but to facilitate > tracebacks and take accountability for transiting the call from whatever > upstream didn't sign or preserve the signature. > > > Calvin Ellison > Systems Architect > calvin.elli...@voxox.com > +1 (213) 285-0555 > > > > > The information contained herein is confidential and privileged information > or work product intended only for the individual or entity to whom it is > addressed. Any unauthorized use, distribution, or copying of this > communication is strictly prohibited. If you have received this communication > in error, please notify me immediately. > > > On Tue, Jul 5, 2022 at 11:47 AM Zilk, David <david.z...@cdk.com> wrote: > Mark, > > > > Agreed. I guess it comes down to how to decide who the originating carrier is > that should be doing the attestation. > > > > As an intermediate carrier, Bandwidth should just pass through whatever > Identity header they get; but if there is no Identity header (stripped > header, TDM link in the path, originating carrier not attesting, etc.) then > the only assumption they can make is that the partner originated the call > (even if they didn’t) and ‘B‘ is the only proper attestation they can apply. > > > > Bandwidth making the assumption that they are an intermediate carrier (and > the unattested calls came from some other (non-partner) service provider) > isn’t a reasonable assumption. > > > > David > > > > From: Mark Lindsey <lind...@e-c-group.com> > Sent: Tuesday, July 5, 2022 10:16 AM > To: Zilk, David <david.z...@cdk.com>; voiceops@voiceops.org > Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool > > > > The primary problem to fix, in this scenario, is that Term Provider 2 is > stripping the Identity header, and therefore violating 47 CFR § 64.6302(a). > So many engineers have configured SBCs to strip every header except the > handful they want to carry, but Identity needs to be added to those lists. > > > > The secondary problem to fix is that 47 CFR § 64.6302(b) allows intermediate > providers to legally opt out of STIR/SHAKEN in any practical fashion. > > > > I am speculating in the example call flow shown below, but I wouldn't see > Bandwidth's behavior as a key problem. The ATIS destination of the C-level > attestation is for a situation that, like flying pigs, doesn't appear to > occur anywhere in reality. Nobody just accepts SIP traffic from random, > anonymous sources for termination. I'm glad Bandwidth is adding the > attestation that it can add. > > > > Mark R Lindsey | SMTS | +1-229-316-0013 | m...@ecg.co > > Schedule a meeting > > > > > On Jul 5, 2022, at 13:01, Zilk, David <david.z...@cdk.com> wrote: > > > > If that is the case, a scammer that should be either attested C, or not > attested at all can game the system and upgrade their calls to any customer > of Bandwidth to B. Granted, B attestation isn’t much better than nothing, but > still it violates both the intent and the letter of the law. > > > > David Zilk > > CDK Global/IP Networked Services > > > > From: Mark Lindsey <lind...@e-c-group.com> > Sent: Tuesday, July 5, 2022 9:58 AM > To: Zilk, David <david.z...@cdk.com> > Cc: voiceops@voiceops.org > Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool > > > > I expect Bandwidth is attesting that they know the identity of the SIP > trunking provider that sent your call to Bandwidth. > > > > CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] > -> [term provider 3] -> [Bandwidth.com] > > > > ...And term provider 3 is a customer of Bandwidth.com. > > > > > > > > Mark R Lindsey | SMTS | +1-229-316-0013 | m...@ecg.co > > Schedule a meeting > > > > > > On Jul 5, 2022, at 12:19, Zilk, David <david.z...@cdk.com> wrote: > > > > I am getting results from a test to the Bandwidth number that are confusing. > It appears that our Identity header is not making it through to them, however > the call does have an Identity header, certified by Bandwith, with B > attestation. This is odd as we don't have any direct business relationship > with Bandwidth. How can they claim B attestation? > > David Zilk > CDK Global/IP Networked Services > > -----Original Message----- > From: VoiceOps <voiceops-boun...@voiceops.org> On Behalf Of David Frankel > Sent: Sunday, July 3, 2022 8:05 AM > To: voiceops@voiceops.org > Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool > > CAUTION: This email originated from outside of the CDK organization. Exercise > caution when clicking links or opening attachments, especially from unknown > senders. > > Last week I was forwarded a note from this list regarding tools to test and > debug SHAKEN Identity headers. That prompted us to stitch together some > modules we already had in an attempt to help. > > What we have is at http://identity.legalcallsonly.org. You can call one of > the test numbers listed on that page, and if we receive your header, we'll > read you a six-digit code. Disconnect and then plug the code into the box on > the web form, and we'll show you details of that Identity header. > > Perhaps most importantly, you'll be able to see if the header we received is > the one you sent. In addition, we parse the header and try to tell you if it > is correctly formatted and valid. > > Currently we have a couple of geographic DIDs and three toll-free numbers > (each using different underlying providers). So far we aren't having a lot of > success getting the Identity headers on the TFNs; we're working to improve > that. > > Suggestions welcome. We hope the tool provokes more discussion about best > practices regarding making the Authentication Framework as functional and > useful as possible. > > Happy 4th of July! > > David Frankel > ZipDX LLC > St. George, UT USA > > > _______________________________________________ > VoiceOps mailing list > VoiceOps@voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > VoiceOps@voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > > > > _______________________________________________ > VoiceOps mailing list > VoiceOps@voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > VoiceOps@voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
