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 <[email protected]>
Sent: Tuesday, July 5, 2022 10:16 AM
To: Zilk, David <[email protected]>; [email protected]
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) [1]. 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) [1] 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 | [email protected]
Schedule a meeting [2]
On Jul 5, 2022, at 13:01, Zilk, David <[email protected]> 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 <[email protected]>
Sent: Tuesday, July 5, 2022 9:58 AM
To: Zilk, David <[email protected]>
Cc: [email protected]
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 [3]]
...And term provider 3 is a customer of Bandwidth.com. [4]
Mark R Lindsey | SMTS | +1-229-316-0013 | [email protected]
Schedule a meeting [5]
On Jul 5, 2022, at 12:19, Zilk, David <[email protected]> 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 <[email protected]> On Behalf Of David
Frankel
Sent: Sunday, July 3, 2022 8:05 AM
To: [email protected]
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 [6]. 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
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops [7]
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops [7]
