[stir] Setting Expectations regarding STIR Deployment Realities

["David Frankel" <[e-mail]>]

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

ZipDXR LLC

Monte Sereno, CA USA