Rebekah Johnson: Hi everyone and welcome to another episode of Tuesday Talks where we shed light on the evolving complexities within the communications ecosystem. Joining Anis and I again for part two of our Mythbusting: “What is the Current State of STIR/SHAKEN Implementation,” topic, is Chris Wendt. Chris is the co-chair of the ATIS\SIP forum IP-NNI Joint Task Force. He is also the co-chair of the STI-GA Technical Committee, and as always, a welcomed guest of Numeracle.
So Chris, thank you so much for joining us again on another Tuesday Talks.
Chris Wendt: Thanks for having me back.
Rebekah Johnson: In part one, we dove into the challenge that service providers have with their local policy when attesting to what they know of the caller or, we might refer to them as an Enterprise, and that caller's authorization to deliver calls using a specific TN.
So let’s continue the Enterprise Challenge discussion, but this time let’s shift towards the technologies to support bridging that gap. When I referred to that gap, what we're talking about is the situation where the service provider's direct customer is perhaps a BPO, which is a Business Process Outsourcing call center. So, this provider sits between the voice service provider and the Enterprise, thus creating the gap that creates the challenge for the voice service provider to sign the calls with an A-Level Attestation.
So, Chris, can you tell us what's currently being done from a technical perspective for this gap that the voice service providers are facing when they're deploying their STIR/SHAKEN or Robocall Mitigation Solution.
Chris Wendt: There's a couple of techniques people are looking at. I think we're at the early stages and there's work being done on a number of techniques. The first one that both of us have been involved in primarily, is the use of a certificate delegation. The point of that is the originating service provider that isn't directly initiating that call, who needs some proof that the legitimate caller that is using a telephone number, is the actual vetted user that can use that number.
What certificate delegation allows is an Enterprise or any VoIP entity that isn't necessarily authoritative over a telephone number, to sign based on delegated authority. Basically, it will sign the call just like with SHAKEN except it's not the official SHAKEN certificate, it's one that represents this authority. Once it gets to the originating provider that is converted. The originating provider looks at that, they validate it, they know absolutely where the call came from and that can be used as proof that it can provide A-Attestation.
There are some other techniques that are also being discussed. One is a database that can be shared between different providers, a letter of authorization technique... these are more commercial arrangements that are made between providers to create a level of trust. But the telephone system is pretty diverse and there are lots of ways a call could go, especially in terms of least-cost routing, and other techniques people are generally using in the VoIP world. For me, the delegate certificates have the most legs in terms of solving those really challenging Enterprise scenarios.
Anis Jaffer: I would agree, Chris. I also think the centralized database or any database model would create a situation very similar to what we have with the CNAM databases. Today we have service providers using CNAM DB’s, there are more than one, but still, essentially the challenge is you need to update a single database or any database that a service provider dips into.
Chris Wendt: The telephone system has been around for a while and I think the techniques that are in place today are really thinking more from a service provider perspective. I think what we do in the telephone network is facilitate more end-to-end use cases where especially from an Enterprise point of view, you want to control your calling name, and with Rich Call Data other things, potentially enhance how a call appears at the far end of the call to the called party.
That's sort of what we're trying to strategically move towards, to more of an end-to-end that is a little bit separate from the actual routing of the call from provider to provider.
Anis Jaffer: So with delegated certs, enterprises have better control because they are attaching the certs real-time in their call. And what you also mentioned about RCD, which is a claim that can be used to add data such as a logo and call reason, how did that come about? What are your thoughts on how that data can be used up to termination?
Chris Wendt: Well, they really stem from thinking about now that we have identity headers and signed credentials that are part of the telephone ecosystem, how do we extend beyond just proving that the telephone number is correct? How can we add more value to this? How can we encourage people to be adopting this? How can we potentially add new opportunities for value in the telephone network as part of this effort?
I sometimes use turning ‘lemons into lemonade’; you take something that's mandated and something that not everybody is looking at and say, “Oh I have to do this because the FCC is telling me to do this.” Rather than looking at it that way, what are the opportunities to take this and use this opportunity to upgrade the telephone network to more possibilities?
So RCD was all about that. I would say it's the ‘no-brainer edition,’ because we're signing a telephone number, it's easy to sign a calling name, it's easy to sign some extensible piece of JSON that allows you to pass multiple pieces of information that you want the customer to potentially react to or see when they're answering the call.
Anis Jaffer: Is this RCD claim created just for the SHAKEN Standard or was it something that exists even outside? How do you ensure that it is a standard format that everybody can accept?
Chris Wendt: So, maybe this gets more into the deep levels of the way standards work, but the way that we've been doing things, and I think this actually works generally well and it’s very typical with most telecom standards, is you build a more generic framework within IETF. IETF is all about protocols, the base-level protocols, SIP is defined in IETF, X.509, the PKI standards that we use as part of STIR/SHAKEN are in IETF. We use them at a core or generic level, and then generally, industry forums and interest groups might take that, 3GPP is a big example of how the mobile guys took IETF standards, and build a more practical implementable framework specific for those scenarios. We take those, and in our case, that's exactly what STIR and SHAKEN represent, it’s the U.S.-specific standards that take the STIR framework and expand those into more of the best practices implementation details for real service provider networks.
We did the same thing with RCD, we created a base-spec with IETF and took that to the IP-NNI to find the SHAKEN version of that. We’ll probably continue to follow that path so you could implement, and we hope that people implement, STIR and RCD across even private networks and other things like that, which may not have to follow SHAKEN because maybe that’s a different scenario, but that these technologies are available across all those spaces.
Rebekah Johnson: I want to go back to the two options of the Central Database and Delegated Certificate. I followed comments, specifically reply comments, back in May of last year, we’re coming up on the anniversary of it, and I dove into what those two approaches achieve and what they don't achieve. I wanted to get your thoughts around it.
First I’ll talk about what they do achieve because that’s the same for both sides. They do achieve some kind of vetting process of the entity before their identity is established, whether it's in delegated certificates or on the central depository. They also have their own approach to TN authorization. In the comments, something that I really honed in on was security. That's where these two models really break apart. So, I wanted to get your perspective on the security that's afforded through the delegated certificate versus what we get in the centralized database.
Chris Wendt: The basis of STIR, and any real security protocol, is making sure you can track things end-to-end. With a digital signature, you have somebody that signs something that needs to be validated at the other end.
The problem with Central Database is that you have a disruption there; somebody put something in the database even if you authenticate who's putting that in the database you have to correlate that back to this call that's coming a month later to two years later. You have no cryptographic connection to that database. My worry, and I think probably your worry as well, is if I put my telephone number in the database, what's to say that somebody else comes along and manipulates the originating service provider to think that they own that number? And because they're in that database they get an A-Attestation, or even worse there's RCD, so there’s information associated with it and you really confuse the user because you're providing all this great information of who it is, but it's actually the wrong person. That's my major concern on the end-to-end security of how you do those things.
Now I think there are maybe some valid scenarios like in an isolated trust network where you could accomplish those things. But it really doesn't have the global reach that I think the fundamentals of what we have in STIR, which is end-to-end security, provides.
Rebekah Johnson: I think you might be talking about blockchain and we are not going into that topic in this session. That’s a totally different topic that’s got legs now too.
I think what’s good, at least from those perspectives, is that security is just essential. And it’s interesting, Chris, I hadn't thought about it until you just said this with regards to the RCD and the verification of it, is the liability in that scenario with the central repository. What if I'm a service provider and I'm depending upon this information and that it's being vetted, and that it's accurate and truthful, and I sign a call with A-level Attestation and find out it's actually not really the entity it's some other actor who's fooled me into it. I don't know what the answer to this is or open up a can of worms but I can’t help but wonder who would be liable for that? Are these situations we’re going to see in the future? I think there's so much more yet to learn with these deployment models.
Chris Wendt: When building a system with security at the forefront, you want to make sure there are no holes and I would hate to create holes with some of these techniques. That's why I put a lot of work into the certificate delegations because I knew we would need something that’s bulletproof in terms of end-to-end.
Rebekah Johnson: On that point, when do you think the delegated certificate model will be rolled out across the industry? Can you give us an update on what is the process and where we are at?
Chris Wendt: Sure. A bunch of companies have asked the STI-GA about support for delegate certificates. All of the specs are done for that and approved in the IP-NNI, which is the one that's associated with SHAKEN. There are a couple of processes that have to happen in terms of updating the policies but I anticipate that hopefully, that will come out fairly soon where results of the process for getting that policy are accepted and put into place and then we can start doing that officially.
Rebekah Johnson: With the onset of the delegated certificates into the industry as a use for A-Level, we're already seeing a lot of service providers talking about going ahead and getting your calls signed with an A-level Attestation and it'll achieve all these things for you like your contact rates are going to go up. Is there anything to the claim that service providers can deliver calls to more terminating devices because of agreements with providers to guarantee calls are delivered with A-Attestation?
Chris Wendt: I just think that’s the entire goal of what we’re trying to get to. I think we talked a little bit about it last time, but BNC really only exists because we weren't ready. We needed a crawl-walk-run approach because we’re running at an accelerated pace to get the specs in place and to get a solution in place. To me, the enterprise techniques that allow you in a secure way to give out an A-Attestation to all calls that are legit with a legit telephone number association, that's where we need to be.
The FFC’s done a great job at pushing the industry. Obviously, we've been working quite rapidly as an industry to get there, and hopefully after June 30th and after some of the smaller providers also come on board, we will be at high-level percentages of calls that are signed. It will be something that can be relied upon and hopefully, the enterprise techniques will follow soon afterward. It really gets us to the point where we can rely on verification of calls and relying more on that, rather than trying to look at the stopgap things that are happening today.
Anis Jaffer: It seems with RCD claims as part of the delegated certs, enterprises would be able to send Rich Call Data (logos, called reasons, etc.), but not all recipients use the same device. You have Android users, you have Apple users, for example, the vast majority of cell phone networks, don't behave the same way. So are there challenges with terminating devices in how they receive and process this data?
Chris Wendt: Definitely. Just because the Standards exist, doesn't mean everybody has to implement it, however, I hope the industry moves towards us. There seems to be a lot of excitement around it, there seems to be a lot of folks that certainly appreciate the capabilities of what Rich Call Data does. There are some more proprietary solutions out there that folks are pushing, so I think, hopefully at the end of the day, proprietary solutions maybe get you so far but generally, standards really open up the ecosystem and provide a wider audience for something and at the end of the day, provide the most value.
I think that's been proven many times over, that following a standard, while some people think they have to own the market, really is generally the biggest economic opportunity to use standard techniques.
Rebekah Johnson: It’s funny you should say that because I've seen some marketing claims that people are saying they are the only service provider who can sign. But no, it’s called a Standard, which means everybody can participate and everyone is signing the same way. You’re signing is not any more magical than somebody else’s signing.
And that’s part of why we have our Tuesday Talks, we want people to be educated and aware so that they can make the right decisions for their businesses.
Chris Wendt: That’s the interesting thing too, just like I was saying, we have these standards but that doesn't mean that you can't do your own twist on them that’s standards compatible that does provide more value or provides your own secret sauce. There are always opportunities to claim you're the best server, but as long as you conform to the standard you're good.
Rebekah Johnson: Speaking of opportunities, exciting on Tuesday Talks day, the FCC's Wireline Competition Bureau announced the immediate opening of the Robocall Mitigation Database. This database is supposed to provide details on filing instructions and establishes the June 30th, 2021 deadline for voice service providers to submit required information in the database.
I'm not sure what the required information is, I still have to research a little bit more. I did do a look-up on the database and we already have hundreds of entries, so that's exciting. I don't know what percentage that represents in the United States, but I’m just curious to know what your thoughts are or if you have anything to contribute on that with the Robocall Mitigation Certification Database?
Chris Wendt: This is a big positive for the industry because while we do want this whole STIR/SHAKEN effort to be industry-led, there always has to be something that guides who participates and provides the policy. The FCC doing this really provides the central guideposts of conforming the policies to who's participating. A lot of it has to do with, similar to filings, that the folks that are in the database correspond to providing public filings on their Robocall Mitigation plan. That's probably the requirement going forward you have to commit to Implementing STIR/SHAKEN and other regulations around call blocking.
That's what I think it's all about and hopefully, that's useful for the industry going forward and really controls who can participate and makes that hopefully more open and then trusted as well.
Rebekah Johnson: What’s interesting too is that everyone who's in that database doesn't mean that they've implemented the exact same Robocall Mitigation strategy. With just a quick look at where we have to go find out what each provider’s plan is, you have to actually go into the ECFS Filing System, look at the proper docket number, find their report, and then it might be redacted. It doesn't necessarily look like it's a report for the public, even though this is supposed to be useful to the public, but more just a list of who's at least doing their homework assignment and who's finish their homework assignment. At least you have class participation if you have submitted something into the database.
One of the key points before this goes awry after today is, the database is live but it has a time period before the actions made on the entries go into effect, which is in September. I'll get the proper day, but I think it’s September 28th. So on June 30th, 2021 we are not going to see a massive drop in service providers connecting with that provider if their names are not on the list. It will be interesting to see what service providers are trying to do with regards to the downstream carriers where maybe their calls are passing through. What insight do they have on that? Do they need to pick different routes? I don't know. There's a whole other discussion that we're going to have around that particular topic and bring in some lawyers for that one. With how it gets used, I think we have a lot of discussions that we need to have on that.
Chris Wendt: June 30th is all about the initial commitments that larger providers have made. By June 30th I think there will be a fairly significant amount of calls that are signed. It’s bringing in the lower hanging fruit providers into the mix and those that had made exceptions. Hopefully, by the end of the year, we’ll really be starting to see a large percentage of calls being signed.
Rebekah Johnson: If anything, I really hope it’s educational, at least to the regulators and the enforcement side of just how prepared and ready the ecosystem is. I'm hoping this is an indicator of that as well so that we understand at least with future rule-making that may still be coming down the pipeline, of the effects that might have. Because you're actually getting insight into everybody’s strategy. Perhaps, and hopefully, we can use this as a tool to make really smart rule-making by understanding where the ecosystem is at, at the time.
Chris, thank you again for participating in another Tuesday Talks. Since we have just a few minutes left lets see if our audience has any live questions today. So, Molly, do we have any questions?
Molly Weis: We do have one question/comment wondering about the new Robocall Mitigation Database: Do we think that the FCC might be seeding this database from an existing Transit Network DB? Could that be part of the existing entries that are already there?
Chris Wendt: I think the initial participants in the database, I'm pretty sure this is true, are based on who filed commitments with the FCC currently. Then they're probably opening it up to the broader ecosystem to essentially do the same thing, except, it'll be a database entry.
Rebekah Johnson: I think there's a little bit of research you have to do. I'm going to find a way to make this very simple for how we correlate the entry in the excel spreadsheet that you can download, versus the filing itself. If the FCC doesn’t have it, Numeracle is going to build it, it's a very easy thing to do. This is a simple correlation that we can bring together, otherwise, everybody is going to have to hunt and it's time-consuming.
I think there is a better way for us to be able to pull the information together so you can see exactly what the service provider has done, versus having to look at the list. Because the list actually doesn't tell you anything other than they filed something. They could have filed, but are nowhere near close or aren’t able to do this within time or need extra time. You have to go and read every single file.
Chris Wendt: I think the FCC is pretty serious about commitments to solving the problem.
Rebekah Johnson: Well, you can come up with your own Robocall Mitigation Strategy, it doesn't have to be STIR/SHAKEN because there are going to be some that have networks where they can't make the physical upgrade, but have a plan in the meantime while we work on a strategy.
Chris Wendt: Yes, there are some rules, mostly having to do with either STIR/SHAKEN or some folks are looking at the 9-IP if you have a 7-Interconnection providing a potential solution there, which the industry is also working on in parallel. There is some flexibility there, but it's not ultimate flexibility, you can't just come out of the woodwork and write something new. It has to be fairly real.
Anis Jaffer: I did a very quick look at the database and there is a column for STIR/SHAKEN Implementation status. A lot of them right now are showing ‘Not Applicable,’ but I did see a few providers that have mentioned that they've completed STIR/SHAKEN.
Rebekah Johnson: There’s a lot of N/A so I’m not sure, other than it’s got a name and an address. I think we’ll have to dig for some more information.
Chris Wendt: And that’s why we need to do more of these things with the FCC, we meaning the general industry needs to make people aware of what the requirements are and what the path forward is. It’s the complex topics, and not everybody has been paying full attention to them, although they should be pretty aware of it if you’re in this industry.
Rebekah Johnson: I think we have time for one last question very quickly. Allen Percy submitted it and he’s asking if there's any early adoption indications for delegated certificates for enterprises?
Chris Wendt: There have been a few industry POC's that have been announced and discussed, even the mode in public forums. I know there's a bunch of STIR/SHAKEN providers working on it so that's where we're at now. We’re waiting on the policy part from the STI-GA to make it official, but hopefully, after that, you can see some solutions coming out of the woodwork, I suspect.
Rebekah Johnson: Yes, I agree. We're seeing innovation around it including ourselves.
Thanks for joining us today on another episode of Tuesday Talks. We’ll see you again on Tuesday, May 4th, where we will be discussing, “Leveraging Trust in the Network with Rich Call Data and the Authentication of Branded Assets.” We hope to see you then.
