Re: [stir] Setting Expectations regarding STIR Deployment Realities

[Richard Shockey <[e-mail]>]

 

Let me add a few points in line here and BTW David thanks for your thoughtful and informed insights.  Good to hear from you. 

 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN [phone]

 

 

From: stir <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Monday, August 15, 2016 at 10:21 AM
To: David Frankel <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

 

Your suggestion to “enumerate the out-of-scope dependencies” is a good request.

 

I hope the authors will make some attempt, as well as an example or two.  (Ironically the word “example” appears 54 times but not in relation to an actual example.)

 

RS>  Where have I heard that broken record before.  

 

My personal view agrees with yours that there seems to be an expectation that STIR will operate on endpoints in an end-to-end fashion when in fact, to have any hope of nearer term deployment of anything hopefully approaching critical mass (and even then there are very big challenges), the carriers will be required to do the key management, the signing, and the interpretation of signatures.

 

 

RS> Agreed. Certainly some people think the STIR mechanism will operate in an end to end fashion, and it may well in the distant future but that represented a level of complexity and cost that no one wants to impose on the industry at this time.  As you well know the industry has a legitimate allergy to large numbering databases. Not to mention we’ve seen a variety of issues with WEB PKI deployments that simply cannot be permitted under the circumstances.  Phone numbers are not domain names.  We are dealing with a first order level of deployments, that as you point out, in large measure will require carriers to do the key management signing etc.  That is the world as it is now, not as some wish it were.  The important thing now is for the authors to clarify what the construct looks like on the wire and avoid any discussion of Layer 8-10 issues that are outside the scope of the charter.  The current documents represent the appropriate level of tools necessary to design an appropriate implementable system. 

 

 

 

What is signed and how it is interpreted are critical pieces of information and need to be kept extremely simple or, IMHO, this will be as big mess as you’ve tried to warn.  And of course these critical pieces will not be provided here.

 

As far as “out-of-scope dependencies” I’ll suggest that how keys are managed, what is signed, and how the signatures should be interpreted are the big 3 that occur to me.

 

I am hopeful that the SHAKEN Framework being crafted in the ATIS/SIP Forum IP NNI Joint Task Force will be able to accomplish the “what” is signed and how key management (for North American carrier implementations) should operate.  I suspect carrier key management may be a subject of regulation but don’t know for sure.

 

 

RS> That is our joint desire and the NNI TF will be meeting this month to review ongoing requirements and deliverables, especially in light of the conclave on the 19 at Commission HQ. 

 

 

I am also hopeful that 3GPP will define “how” the SHAKEN signature is to be interpreted, especially for corner-case requirements such as E911 when roaming on a carrier with whom the subscriber’s carrier does not have a roaming relationship, and manual roaming.

 

RS> Agreed and preliminary outreach has gone out to the relevant 3GPP committees. 

 

 

Outside of carrier implementation, I have very little idea what endpoint developers will want to do, but am willing to let the market figure that out for itself.

 

Pierce

 

 

From: David Frankel [mailto:[e-mail]] 
Sent: August 14, 2016 8:43 PM
To: [e-mail]
Subject: [stir] Setting Expectations regarding STIR Deployment Realities

 

I am writing this note to share a perspective on several aspects of STIR and its related specifications. I was prompted to do this by the numerous notes from Dave Crocker and the discussions that have ensued.

 

My comments here are not specifically directed to Dave’s issues. Rather, I noted that Dave was asking the group to live up to a level of rigor that, I think, was higher than where we’ve been operating. And I wanted to highlight some other areas that haven’t been fully addressed and probably hold future pitfalls for this effort. Being rigorous and explicit about these issues might help us reach the end goals more quickly and pragmatically than ignoring them.

 

There seems to be a lot of confusion, at least outside the group, about how STIR will be deployed and what the effect will be. I discuss below three of the most significant areas where I observe this:

I) Specifications vs. Network Realities

II) The (massive) nuances of Caller-Name vs. Caller-ID

III) Expectations regarding Robocalls

 

I’m not an “expert” on all things telecom, but I do have several decades of experience with legacy and current telephony, mostly in the United States. I’m hopeful that my comments are useful, at least to some. If they are out of place for this list, I’m sure people will let me know, and I’ll ask you to forgive me and just ignore and/or delete this note if it isn’t helpful.

 

I’m sure at least some of you will read this and say, “Yeah, we knew all that already.” And maybe it’s all been sufficiently considered and doesn’t need additional attention. I’ll share anyway.

 

I) Specifications vs. Network Realities: When writing “specifications” for the handling of telephone calls, a couple of important realities come to mind. One is that there are numerous “authorities” for how telephone networks (as we know, it isn’t just one network; it’s a network of networks) “must” or “should” work. A second is that even if you could gather those various specs and directives and regulations, you would find that the actual implementation is full of deviations – some large and some small; some on purpose and some accidental; some rare and some commonplace.

 

In the beginning (depending on where you define the starting line), there were specs from the Bell System, published in modern times by Bellcore which became Telcordia. (Again, you’ll see that I am mostly USA-centric, so you can assume that’s what I’m talking about unless I mention otherwise.) When (the old) AT&T was the dominant carrier, most operators around the edges used these specs at least as their starting point for implementing and running their networks; equipment manufacturers conformed in order to place their gear with those operators.

 

But even back then, as the networks were digitized and computerized (SS7, ISDN, SONET, ATM, SCPs, STPs, TCAP, PABXs, Feature Group D, etc.), manufacturers and operators purposefully deviated from the specs. Sometimes this was to differentiate a product or a service to gain a market advantage; sometimes it was to overcome a technical hurdle; sometimes it was to address a physical, political, economic or legal circumstance not anticipated by the specs.

 

Regulators (not just the FCC, but even individual states) imposed rules that imposed limitations or deviations to the specs. Other organizations (e.g., ATIS) also published specifications. Any given operator’s specific implementation ended up being guided by materials from several “standards” bodies, plus regulators and equipment suppliers, and ultimately even (big) customers. Ultimately, they implemented what they felt like implementing.

 

Applying internet technology to the transport and delivery of telephone calls showed obvious promise and SIP went to the tip of everybody’s tongue. But again, while we had RFCs suggesting how this “should” (or “must”) work, in fact those RFCs are in practice only a “guide” to the implementers. 

 

Here are a few examples that are relevant, in varying degrees, to STIR:

 

RE-ORIGINATION: In theory, an end-to-end SIP call would be passed from originator to destination relatively unchanged; each network hop would add a VIA header showing the path the call took. But in fact, for the billions of calls moving through the PSTN, this isn’t how it works. Unless the call starts and ends on the same network, it will necessarily be passed between networks, often using one or more intermediary networks to get from start to finish. Each of those networks has specific economic interest in the call (they are going to get paid for it, or pay somebody for it, or both). 

 

Each network re-originates the call, making its own decisions about what headers to include (or not). The source of the call (upstream network) is purposefully obfuscated, because for competitive reasons, operators do not want their neighbors to know who is feeding them calls. The engineers on this list would of course prefer that not be done, but we don’t get to make that rule. Even if we could convince SOME operators to do it our way, monetary interests will overrule in many other cases. (There’s a further discussion about how the DIVERSION header should be used for re-originated calls, but we’ll save that for another day.)

 

INTERWORKING: Only a tiny fraction of calls today are end-to-end SIP. Most involve some interworking with SS7 or at least ISUP. And while there are RFCs that specify how that interworking “SHOULD” or “MUST” be done, in fact the gateway vendors and the network operators do it the way they want to do it. Some honor and use P-CHARGE-INFO; others do not. Some deliver X-CHARGE-NUM to the destination user; others do not. ISUP-OLI is sometimes passed in the FROM header; sometimes not. To be fully interoperable, systems that can benefit when these fields are available must be designed so they fail soft/safe when not available. While I realize STIR is intended only for the end-to-end SIP environment and thus avoids this level of interworking, there may be lessons that can be learned from how things do (or do not) actually function in the legacy world. And note how variable the performance is across operators.

 

CALLER-ID SCREENING: Even at the dawn of legacy caller-ID, there was the notion of whether that number was “authenticated” or not. The ISUP Calling Party Number information element includes a “screening” indicator with several possible values: “network provided” means that the operator (presumably a “trusted” entity, whatever that meant then or now) determined what number to send based on subscriber account information; “user provided, network screened” means that the end-user customer (probably the owner of a PABX) provided the number, but the (trusted) operator made sure, somehow, that the number was “owned” by the end-user; and “user provided, not screened” meaning that we’re just passing along whatever we got from the customer and don’t know its validity.  In theory, the screening indicator, which would be delivered to the call recipient, could be used just as we are discussing today in STIR to influence call handling at the receiving end.

 

But guess what: despite being in the spec, and even implemented in lots of equipment, the “screening” indicator gets little use. For almost all calls, the calling party number is “user provided, not screened”. Presumably it got too cumbersome to maintain the screening lists. Operators, interested in bringing on new customers, just turned off screening to expedite the onboarding process.

 

NATIONAL CONSIDERATIONS: Richard Shockey in particular has been good about highlighting where the RFCs must stop and defer to national regulatory authority (or local practice). But that means that to actually implement anything, you have to not only follow the RFC, but you also have to understand the national considerations particular to your circumstance. And it’s difficult to evaluate the practicality of a proposed RFC without also understanding how it would be deployed in the specific nationalities where you want to operate. In USA, we have the number portability database, the local exchange routing guide, the toll-free (SMS/800) database, and others. In fact, even an end-to-end internetwork SIP call can’t complete without consulting the (legacy) number portability database. In parallel with the STIR RFCs, should somebody (ATIS?) be writing a STIR implementation spec for USA/North America?

 

Reviewing 4474bis, there are numerous references to “outside the scope” and “deferred for future work”. This is no doubt all for good reason, but you can’t actually deploy anything until some of those items are addressed.

 

Summary? They say you can lead a horse to water but you can’t make him drink. And you can write specs all day long and mandate this or that, but at the end of the day, the implementers are going to decide how it really works, and forces stronger than our specs are likely going to be at work here. The ideal spec is written with enough knowledge and enough appreciation of the technical and economic realities where it will be deployed that implementers CHOOSE to fully adopt it. The spec adds value if adopting it is less painful than some other alternative. To flourish, the spec must, of course, be technically correct and, when followed, deliver on its stated objective(s). It should be well-enough thought through and sufficiently constrained that conforming to the spec is more efficient (in terms of both development and operation) than other approaches. Clearly in our environment INTEROPERATION is key – a huge advantage to following a spec should be that you are assured of interoperability with others that follow the spec. And the spec should TEACH. I think Dave Crocker has been trying to address all of these things. But even if we succeed on all that, remember that in the telecom environment, the spec must survive in an ecosystem where other forces are hard at work.

 

II) Caller-ID Number and Caller-Name: A short time after caller-ID was introduced decades ago, we got Caller Name (CNAM). This functioned then not by sending the name along with the number from the origination point. Instead, we rely only on the number being sent to the destination. Then, a database lookup is performed (“CNAM dip”) and the name associated with the number is displayed to the end-user.

 

In the beginning, a carrier could only provide name information if the call both originated and terminated on its own network; the carriers that owned phone numbers maintained their own CNAM databases. Then they decided to give each other access to their database, but demanded compensation from the terminating carrier for each dip. (Tiny carriers used aggregators to maintain their databases and handle collection and disbursement of dip charges.) Over time, the CNAM databases have evolved. There are a few large operators still mostly conforming to the original notion. But other databases are available that use hybrid information (some entries from public records, others licensed or stolen from the official sources). And of course what’s most popular on mobile phones: using the end-user’s own contact list (stored in the phone) as the database. 

 

Most mobile operators do not, by default, deliver a call-by-call CNAM to the subscriber device over the air. A few offer to do a database lookup and deliver the result, usually for an extra monthly fee (since they incur a cost for doing the dips). As usual, economics drives the reality here.

 

Most consumers care more about the name than the number; some telephone displays show only the name if it is available; the number is shown only if the name is not known. There are some more modern proposals for how the name information might be sourced (and even authenticated; see draft-peterson-stir-cnam-00) but I haven’t seen substantive discussion of that here (and 12.6 of 4474bis mostly says it is out of scope). Private SIP-to-SIP calls of course use the display name in the FROM header. For Public Network calls, either an “authenticated name” could be displayed, or for an authenticated number, a dip into one of the various databases will be done to fetch a name. But how any validity is assigned to that name is an exercise for the reader (or left for a future version of the spec). Today, many service providers let customers specify any name they want for the database entries associated with their numbers. That name can often be set via a web portal or an API and can be “Alex Hamilton” or “Bill Clinton” or “FBI” or “Bank of America” even if the owner of the number is “Joe Fraudster”.

 

My point here is that we can kick the CNAM problem down the road, but it really is what most end-users care the most about. STIR as is may be a critical stepping stone to getting there, but we should set expectations regarding what the (intermediate) result is going to be.

 

III) Expectations Regarding Robocalls – Speaking of setting expectations, there are high expectations that STIR will go a long way to dealing with the massive robocall problem. Last month, FCC Chairman Wheeler said: ““I am also calling on the carriers and standards groups to accelerate the development and deployment of technical standards that would prevent spoofing of caller ID and thus make blocking technologies more effective, as was done in the battle against spam years ago.” If he believes that STIR as proposed is going to make any measurable dent, within the next five years, in mitigating the level of actual fraud facilitated by illegal robocalls, he is sadly mistaken.

 

I think it’s acknowledged that STIR only applies to end-to-end SIP calls, and then only when all intermediate carriers propagate the necessary headers. Those calls are likely to be a tiny fraction of all calls for the next several years. One theory says that the illegal robocallers will be the last ones to authenticate their calls (because they are, in fact, not authentic). So the theory is that we’ll authenticate all OTHER (legitimate) calls, and then the illegal robocalls will stand out as the ones that aren’t authenticated.

 

But that’s preposterous. In the US, there are hundreds of millions of endpoints that can originate calls; even if we managed to get 90% of them using STIR, there would still be tens of millions of (legitimate) endpoints originating unauthenticated calls. Now, the actual count of endpoints isn’t so critical; more important is the volume of calls originated from authenticated endpoints versus non-authenticated. Lots of business-to-consumer calls are originated from PABXs and other systems connected via legacy PRI or even legacy analog lines and trunks. It seems unlikely that consumers will want to put all those (unauthenticated) calls through some CAPTCHA or similar system. It isn’t clear to me what the game plan is for dealing with what will still be the large fraction of calls that that will remain unauthenticated for some time. (How the endpoint handles such calls are outside the scope of the spec, so how Wheeler knows that it is the savior to robocalls is beyond me.)

 

Alternatively, there will probably be some illegal robocallers, and their enablers, that will jump on the STIR bandwagon if it comes to pass. There will be service providers that will solicit customers to sign up over the web, relatively anonymously, to get “authenticated” phone numbers (perhaps thousands or maybe even a million of them). They’ll be able to set their CNAM to whatever they want. They’ll place hundreds of millions of authenticated calls and then move on. The good news is that STIR will let us know who the service providers are that are making the authenticated credentials available to these robocallers, but it isn’t clear what the next steps are. I’ve seen mention of (again, out of scope) potential “reputation” metrics for providers. But it isn’t clear how a call recipient would determine the reputation of the provider, or what they would do when an authenticated call was received from somebody using credentials issued by a less-than-fully-reputable provider.

 

And all of that assumes a level of sophistication on the part of the call recipient to actually deploy some feature or filter that acts on the authentication (and reputation?) information. Robocallers almost by definition do not prey on the sophisticated; they prey on the elderly and disadvantaged and desperate, who typically don’t have the latest smartphone or the coolest VoIP service. (Yes, robocalls annoy all of us, but I promise you that nobody on this mailing list is their target.)

 

We should certainly learn everything we can from the email spam battle, but the analogy isn’t 100% applicable by any means. Email has the SIGNIFICANT advantage that filters have access not just to the headers (which include, importantly, a SUBJECT line), but also to the ENTIRE CONTENT of the message. (This is also true for SMS.) With voice calls, we have far less information available, and certainly no clue as to what the content will be. “Doing for voice calls what we did for email” is a technical fantasy.

 

So members of this list are being disingenuous if they are telling Mr. Wheeler and others to expect a dramatic near-term drop in robocall complaints once STIR (as currently envisioned) is deployed.

 

CONCLUSION? I’m not for (or against) major revisions to the document. But I do think that expectations need to be properly set. 4474bis 12.2 says in part: “…preventing the simple unauthorized claiming of an identity for the purposes of robocalling, voicemail hacking, or swatting, which is the primary scope of the current document.” The document lays some groundwork that will be useful, in part, in ultimately limiting robocalling, but nobody has connected all the dots for me on how it will actually, pragmatically be deployed to achieve that objective (same for swatting). Some of you, no doubt, will tell me THAT is beyond the scope of the document(s). If nothing else, the document could enumerate the out-of-scope dependencies upon which we are dependent before realizing any actual utility (or deployability) of the spec. And even then, the utility to the end-user is going to be severely limited until deployment reaches some critical mass and additional fundamental limitations are addressed.

 

David Frankel

ZipDX® LLC

Monte Sereno, CA USA

 


This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

_______________________________________________ stir mailing list [e-mail] https://www.ietf.org/mailman/listinfo/stir