Subject: [stir] Setting Expectations regarding STIR Deployment Realities

From: "David Frankel" <[email-masked]>
Date: Sun, 14 Aug 2016 18:42:31 -0700

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 15 Aug 2016 14:21:58 +0000

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.)

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.

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.

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.

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:[email-masked]]
Sent: August 14, 2016 8:43 PM
To: [email-masked]
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.

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(r) 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.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Aug 2016 07:44:09 -0700

On 8/15/2016 7:21 AM, Gorman, Pierce A [CTO] wrote:
> 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.

There is a difference between an architecture that /requires/ operation 
within the infrastructure, versus one that permits the choice of 
operation at the end-points and/or within the infrastructure.

For example, the current discussions I've heard about the operational of 
the key query/validation mechanism for STIR is that it will operate 
within the inter-provider infrastructure, with no direct access allowed 
for end-systems (that are not controlled by a participating provider.) 
That's a major architectural choice and precludes the long-term option 
of direct participation by those independent user agents.  Instead it 
requires them to be slaved to their provider.

By contrast, DKIM allows signing and/or verifying by any entity in the 
sequence, even though actual operation is (currently) entirely within 
the MTA infrastructure.

> 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.

Specification of the core information to be signed is something that 
profoundly affects the security properties of the service.  That's a 
technical point.  To the extent the specification defers this choice, it 
needs to make very clear statements about the choices and the effects of 
those choices.

> 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.

You believe there should be no standardized technical specification for 
the key management infrastructure?  This is the highest-risk component 
of the service and it needs to be interoperable at a global scale.  How 
else will that interoperability be achieved?

Also, what do you mean "how the signatures should be interpreted"?

If you mean the direct semantics of a signature, such as meaning that 
the request is valid vs. the request was processed by the signer, I'll 
strongly urge you to reconsider, since that's an essential technical 
point and needs to be standardized.  Failure to have the semantic of the 
signature -- it's 'meaning' -- be clear in the technical specification 
has demonstrably caused serious operational problems.

If you mean "how the results of a validation are used by the verifying 
entity", then yes indeed, that's an entirely separate area of work.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 11:04:45 -0400

I don’t think there is any disagreement on how we’re going to deploy stir, nor is there any specification that limits or even influences it.

We’re going to start deployment at the service provider.  We’re going to evolve to deployment on the device.  There are some participants who think deployment on the device is never going to happen, but they don’t oppose it, they are just skeptical it will happen.

All the documents we have allow generation by any entity that has a certificate valid for the TN the call is claiming to be from.  Any entity on the path can check, making an assumption that the header/body won’t be stripped (which could be a bad assumption, but there are no protocol police).

If anyone thinks there is text in any of our documents that they believe doesn’t allow that, please specify where, and I’m sure we can fix it.

The mechanism is designed to allow the origination network, or the origination device, to generate a valid signature.  It’s designed to let any element on the path check the signature (and thus the certificate used to sign it) for validity.

I have suggested that a useful way to deploy it is to have interconnection agreements between service providers modified to require a certain percentage of validly signed calls by a certain date, ratcheting up the percentage over time.  If that included checking at transit network interconnects, even if the path downstream of that network had SS7 links, we would gain most of the benefit of stir. 

Please note that while we do want to get the call treatment modified depending on the outcome of verification of the signature, the greatest value comes from the ability of the authorities to track the source of calls back to the originator.  By requiring calls to have valid signatures at network interconnections, we provide a tracking mechanism back to the origination network, and that will really help quite a bit.  It’s my opinion that if a large number of “bad” calls come from networks that permit call origination from essentially anonymous customers, that the authorities will take steps to rein in such networks, but that’s just an opinion.

Brian

> On Aug 15, 2016, at 10:44 AM, Dave Crocker <[email-masked]> wrote:
> 
> There is a difference between an architecture that /requires/ operation within the infrastructure, versus one that permits the choice of operation at the end-points and/or within the infrastructure.
> 
> For example, the current discussions I've heard about the operational of the key query/validation mechanism for STIR is that it will operate within the inter-provider infrastructure, with no direct access allowed for end-systems (that are not controlled by a participating provider.) That's a major architectural choice and precludes the long-term option of direct participation by those independent user agents.  Instead it requires them to be slaved to their provider.
> 
> By contrast, DKIM allows signing and/or verifying by any entity in the sequence, even though actual operation is (currently) entirely within the MTA infrastructure.
> 
> 
> Specification of the core information to be signed is something that profoundly affects the security properties of the service.  That's a technical point.  To the extent the specification defers this choice, it needs to make very clear statements about the choices and the effects of those choices.
> 
> 
> You believe there should be no standardized technical specification for the key management infrastructure?  This is the highest-risk component of the service and it needs to be interoperable at a global scale.  How else will that interoperability be achieved?
> 
> If you mean the direct semantics of a signature, such as meaning that the request is valid vs. the request was processed by the signer, I'll strongly urge you to reconsider, since that's an essential technical point and needs to be standardized.  Failure to have the semantic of the signature -- it's 'meaning' -- be clear in the technical specification has demonstrably caused serious operational problems.
> 
> If you mean "how the results of a validation are used by the verifying entity", then yes indeed, that's an entirely separate area of work.
> 
> 
> 
> d/
> 
> 
> -- 
> 
>  Dave Crocker
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Travis Russell <[email-masked]>
Date: Mon, 15 Aug 2016 11:15:23 -0400

Just a quick question as this sentence caught my eye:

"By requiring calls to have valid signatures at network interconnections, we provide a tracking mechanism back to the origination network, and that will really help quite a bit.  It’s my opinion that if a large number of “bad” calls come from networks that permit call origination from essentially anonymous customers, that the authorities will take steps to rein in such networks, but that’s just an opinion."

We currently have a situation in the industry where there are a number of CSPs that are selling interconnect access to anyone, and are complicit with the true purposes of these purchased interconnects (eavesdropping and location tracking have been the most widely published). When messages are received from the rogue actors,it appears as if the control message (in this case SS7) are coming from a legitimate, trusted CSP. Is there a proposed mechanism that would identify when these CSPs provide SIP connectivity fully certified?  

Travis Russell | Director, Cyber Security, Service Provider Networks | 
+1919.205.6857 (o) | +1919.412.1167 (c)
https://www.linkedin.com/in/travisrussell1

5200 Paramount Pkwy
Morrisville, NC 27560
USA

Oracle is committed to developing practices and products that help protect the environment

> On Aug 15, 2016, at 11:04 AM, Brian Rosen <[email-masked]> wrote:
>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 15 Aug 2016 15:22:00 +0000

Dave,

I was of the opinion that STIR will permit choice of operation at the endpoints and/or within the infrastructure.   As far as what's been proposed, I do think it is supposed it will be a closed carrier infrastructure to begin with.  One of the things I've wondered about is how could it be open, and what does that look like?  I don't have any good answers, but just a willingness to be open-minded that non-carrier-only implementations are desirable too.

With respect to key management, I've assumed X.509 certificates and I was specifically referring to ordinary operational considerations with respect to CA/CRL and certs.  i.e., one or a few or many? regulated? per-carrier?delegation, et cetera.

My comment about signature interpretation was with respect to ""how the results of a validation" [should be] "used by the verifying entity ".

I also think knowing, with certainty, that a calling party number is authentic and authorized for any given origination of any call type is going to approach impossible (call it a quasi-NP-Complete problem), and so I've advocated for truth-iness in signature and interpretation but a very strictly limited set of truth-iness.  (I know this weasel language is anethema but I'll just beg forgiveness rather than permission.)

I don't think it is practical to assume that carriers can know in every circumstance whether a calling number signature should represent "fully" authenticated.  A "partial" authentication (i.e., a carrier signature) is still possible and valuable, if for nothing else, forensic and legal relief purposes (against perpetrators, not carriers, unless they collude).

With regard to the SHAKEN Framework I've proposed the following (roughly):

00 = Unsigned and wholly untrusted
01 = Carrier signed, but no calling number signature (for various standard or best practice reasons) = somewhat more trusted because the carrier can be identified
10 = Carrier signed, but calling number signature is not of the highest possible quality (for various or best practice reasons) = more trusted than 00 and 01.
11 = Carrier signed, calling number signature is of the highest possible quality (most likely because it's mobile, the device authenticated to the network, and we know location, and subscriber) = most trusted

Categories 00 through 10 can be automatically filtered for real-time analytical robocall treatment.  Category 11 might only get post-processing analytics.  Category 11 should be a large majority (I think).

It's nice that I've offered this very limited interpretation, but the reasons or best practices for assigning any given interpretration are details that remain to be standardized (and wish us all luck too please).

Pierce

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]]
Sent: August 15, 2016 9:44 AM
To: Gorman, Pierce A [CTO] <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

On 8/15/2016 7:21 AM, Gorman, Pierce A [CTO] wrote:
> 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.

> 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

> As far as "out-of-scope dependencies" I'll suggest that how keys are

d/

--

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 11:22:17 -0400

This is a SIP mechanism, so, as currently defined, it doesn’t help any calls originated on an SS7 network.

If checking was implemented at an SS7 gateway, it could help stop bad calls that originate on a SIP network but transit one or more SS7 hops en route to the destination.  We have discussed and have postponed working on an “out of band” mechanism that may be able to assist in getting a valid signature on these and some other hybrid situations to the termination network/device if they too were SIP based or had upgradeable software.

Brian

> On Aug 15, 2016, at 11:15 AM, Travis Russell <[email-masked]> wrote:
> 
> https://www.linkedin.com/in/travisrussell1 <https://www.linkedin.com/in/travisrussell1>
> 
> 5200 Paramount Pkwy
> Morrisville, NC 27560
> USA
> 
> 
>> On Aug 15, 2016, at 11:04 AM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Aug 15, 2016, at 10:44 AM, Dave Crocker <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> bbiw.net <http://bbiw.net/>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "David Frankel" <[email-masked]>
Date: Mon, 15 Aug 2016 08:23:54 -0700

Thanks for that clarification, Brian. You say you "don't think there is any
disagreement on how we're going to deploy stir" but part of my challenge
(and for others too, I think) is that many of us don't know the details of
that "how" because, while the documents don't LIMIT what's done, they also
are necessarily incomplete (thanks to things like country-specific
deployment issues being out of scope).

Let me ask for your help with this example; correct me if I am wrong on any
of the below:

My telephone number is +1-212-555-1234 and my service provider is AT&T.
Presumably there is some USA-specific mechanism that says that AT&T is the
authority for the certificate for my number (based, I would think, on the
number portability database and/or the LERG).

When I place an outbound call under "normal" circumstances, AT&T will sign
that call for me and send it on its way. Anybody in the call path can see
that the call claims to be from +1-212-555-1234, do a number portability
look-up to see that it's an AT&T number, and then somehow know to go to
AT&T's certificate authority API to do what it takes to verify the
signature? (Or maybe there is a consolidated place where AT&T deposits that
information, along with other carriers, and providers along the call path
can just go there to check?)

In any case, for this part of the example, anybody along the path, including
the termination point, can know that the call is legit.

Now, I can engage a call center to make some outbound calls on my behalf. (I
know this use case has been raised many times.) The call center I have
chosen uses Verizon as their outbound carrier. So I go to AT&T and ask them
for the certificate for my number; they give that to me and I pass it to my
call center. So now they place calls, via Verizon, and either the call
center (probably) or Verizon (less likely) uses my certificate to
authenticate the outbound calls they make on my behalf, claiming
(legitimately) to be from +1-212-555-1234.

Again, anybody in the call path can authenticate the call, seeing that it is
an authorized use of my AT&T number.

When the call arrives at the terminating end, they see that the call is
legit. And although it is an AT&T number, they have no clue that it was
originated on Verizon's network.

Is that all close to correct?

David Frankel
ZipDXR LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)
Watch Our Video!

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, August 15, 2016 8:05 AM
To: [email-masked]
Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

I don't think there is any disagreement on how we're going to deploy stir,
nor is there any specification that limits or even influences it.

We're going to start deployment at the service provider.  We're going to
evolve to deployment on the device.  There are some participants who think
deployment on the device is never going to happen, but they don't oppose it,
they are just skeptical it will happen.

All the documents we have allow generation by any entity that has a
certificate valid for the TN the call is claiming to be from.  Any entity on
the path can check, making an assumption that the header/body won't be
stripped (which could be a bad assumption, but there are no protocol
police).

If anyone thinks there is text in any of our documents that they believe
doesn't allow that, please specify where, and I'm sure we can fix it.

The mechanism is designed to allow the origination network, or the
origination device, to generate a valid signature.  It's designed to let any
element on the path check the signature (and thus the certificate used to
sign it) for validity.

I have suggested that a useful way to deploy it is to have interconnection
agreements between service providers modified to require a certain
percentage of validly signed calls by a certain date, ratcheting up the
percentage over time.  If that included checking at transit network
interconnects, even if the path downstream of that network had SS7 links, we
would gain most of the benefit of stir. 

Please note that while we do want to get the call treatment modified
depending on the outcome of verification of the signature, the greatest
value comes from the ability of the authorities to track the source of calls
back to the originator.  By requiring calls to have valid signatures at
network interconnections, we provide a tracking mechanism back to the
origination network, and that will really help quite a bit.  It's my opinion
that if a large number of "bad" calls come from networks that permit call
origination from essentially anonymous customers, that the authorities will
take steps to rein in such networks, but that's just an opinion.

Brian

> There is a difference between an architecture that /requires/ operation
within the infrastructure, versus one that permits the choice of operation
at the end-points and/or within the infrastructure.
> For example, the current discussions I've heard about the operational of
the key query/validation mechanism for STIR is that it will operate within
the inter-provider infrastructure, with no direct access allowed for
end-systems (that are not controlled by a participating provider.) That's a
major architectural choice and precludes the long-term option of direct
participation by those independent user agents.  Instead it requires them to
be slaved to their provider.
> By contrast, DKIM allows signing and/or verifying by any entity in the
sequence, even though actual operation is (currently) entirely within the
MTA infrastructure.
> You believe there should be no standardized technical specification for
the key management infrastructure?  This is the highest-risk component of
the service and it needs to be interoperable at a global scale.  How else
will that interoperability be achieved?
> If you mean the direct semantics of a signature, such as meaning that the
request is valid vs. the request was processed by the signer, I'll strongly
urge you to reconsider, since that's an essential technical point and needs
to be standardized.  Failure to have the semantic of the signature -- it's
'meaning' -- be clear in the technical specification has demonstrably caused
serious operational problems.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 15 Aug 2016 15:23:57 +0000

+1

Pierce

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: August 15, 2016 10:05 AM
To: [email-masked]
Cc: Gorman, Pierce A [CTO] <[email-masked]>; [email-masked]
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

I don't think there is any disagreement on how we're going to deploy stir, nor is there any specification that limits or even influences it.

We're going to start deployment at the service provider.  We're going to evolve to deployment on the device.  There are some participants who think deployment on the device is never going to happen, but they don't oppose it, they are just skeptical it will happen.

All the documents we have allow generation by any entity that has a certificate valid for the TN the call is claiming to be from.  Any entity on the path can check, making an assumption that the header/body won't be stripped (which could be a bad assumption, but there are no protocol police).

If anyone thinks there is text in any of our documents that they believe doesn't allow that, please specify where, and I'm sure we can fix it.

The mechanism is designed to allow the origination network, or the origination device, to generate a valid signature.  It's designed to let any element on the path check the signature (and thus the certificate used to sign it) for validity.

Please note that while we do want to get the call treatment modified depending on the outcome of verification of the signature, the greatest value comes from the ability of the authorities to track the source of calls back to the originator.  By requiring calls to have valid signatures at network interconnections, we provide a tracking mechanism back to the origination network, and that will really help quite a bit.  It's my opinion that if a large number of "bad" calls come from networks that permit call origination from essentially anonymous customers, that the authorities will take steps to rein in such networks, but that's just an opinion.

Brian

---

From: Travis Russell <[email-masked]>
Date: Mon, 15 Aug 2016 11:24:02 -0400

Thanks Brian, 

But I was thinking more along the lines of a SIP service provided by a rogue CSP where they would be complicit with rogue actors (as they are today in the SS7 domain). Hence providing certified SIP identities that should not be certified (if that makes sense?).

5200 Paramount Pkwy
Morrisville, NC 27560
USA

> On Aug 15, 2016, at 11:22 AM, Brian Rosen <[email-masked]> wrote:
> 
>> On Aug 15, 2016, at 11:15 AM, Travis Russell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>>> 
>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>> 
>

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 15 Aug 2016 15:29:55 +0000

David,

It you want to understand how it is going to be deployed look at the ATIS PTSC/NGIIF and ATIS - SIP Forum documents.

Regards,

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360
Email: [email-masked]

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of David Frankel
Sent: Monday, August 15, 2016 11:24 AM
To: 'Brian Rosen' <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Gorman, Pierce A [CTO]' <[email-masked]>
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

Thanks for that clarification, Brian. You say you "don't think there is any disagreement on how we're going to deploy stir" but part of my challenge (and for others too, I think) is that many of us don't know the details of that "how" because, while the documents don't LIMIT what's done, they also are necessarily incomplete (thanks to things like country-specific deployment issues being out of scope).

Let me ask for your help with this example; correct me if I am wrong on any of the below:

My telephone number is +1-212-555-1234 and my service provider is AT&T.
Presumably there is some USA-specific mechanism that says that AT&T is the authority for the certificate for my number (based, I would think, on the number portability database and/or the LERG).

When I place an outbound call under "normal" circumstances, AT&T will sign that call for me and send it on its way. Anybody in the call path can see that the call claims to be from +1-212-555-1234, do a number portability look-up to see that it's an AT&T number, and then somehow know to go to AT&T's certificate authority API to do what it takes to verify the signature? (Or maybe there is a consolidated place where AT&T deposits that information, along with other carriers, and providers along the call path can just go there to check?)

In any case, for this part of the example, anybody along the path, including the termination point, can know that the call is legit.

Now, I can engage a call center to make some outbound calls on my behalf. (I know this use case has been raised many times.) The call center I have chosen uses Verizon as their outbound carrier. So I go to AT&T and ask them for the certificate for my number; they give that to me and I pass it to my call center. So now they place calls, via Verizon, and either the call center (probably) or Verizon (less likely) uses my certificate to authenticate the outbound calls they make on my behalf, claiming
(legitimately) to be from +1-212-555-1234.

Again, anybody in the call path can authenticate the call, seeing that it is an authorized use of my AT&T number.

When the call arrives at the terminating end, they see that the call is legit. And although it is an AT&T number, they have no clue that it was originated on Verizon's network.

David Frankel
ZipDXR LLC
Monte Sereno, CA USA

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, August 15, 2016 8:05 AM
To: [email-masked]
Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

Brian

> There is a difference between an architecture that /requires/ 
within the infrastructure, versus one that permits the choice of operation at the end-points and/or within the infrastructure.
> For example, the current discussions I've heard about the operational 
the key query/validation mechanism for STIR is that it will operate within the inter-provider infrastructure, with no direct access allowed for end-systems (that are not controlled by a participating provider.) That's a major architectural choice and precludes the long-term option of direct participation by those independent user agents.  Instead it requires them to be slaved to their provider.
> By contrast, DKIM allows signing and/or verifying by any entity in the
sequence, even though actual operation is (currently) entirely within the MTA infrastructure.
> Specification of the core information to be signed is something that
profoundly affects the security properties of the service.  That's a technical point.  To the extent the specification defers this choice, it needs to make very clear statements about the choices and the effects of those choices.
> You believe there should be no standardized technical specification 
the key management infrastructure?  This is the highest-risk component of the service and it needs to be interoperable at a global scale.  How else will that interoperability be achieved?
> the
request is valid vs. the request was processed by the signer, I'll strongly urge you to reconsider, since that's an essential technical point and needs to be standardized.  Failure to have the semantic of the signature -- it's 'meaning' -- be clear in the technical specification has demonstrably caused serious operational problems.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 11:49:35 -0400

> On Aug 15, 2016, at 11:23 AM, David Frankel <[email-masked]> wrote:
> 
This really is country specific, but stir is based on the notion that in every country, there is a delegation process for telephone numbers, and whether that is entirely controlled by the regulator, or has some informal mechanisms as well, delegation happens in a way that we can exploit, by issuing or modifying a credential when that delegation happens.

So, if AT&T was delegated a block of numbers from the regulator, and delegated that number to you, then it would have a credential for your number, and, hopefully, at least at some point, so will you.

> can just go there to check?)
Again, part of this is country specific because of the ways delegation is done, but the idea is that you can determine from the credential used to sign the call whether that certificate is good for that number.  You can query the signer of the cert, and it can tell you if that cert is valid for that number.  And of course since it is a PKI, you can do the same with the signer of the CA’s cert, and track back to the root CA for the country the number is part of.

> the termination point, can know that the call is legit.
Yes, as long as by “legit” you mean that the signaling contains a signature using a credential valid for the TN the call claims to be from.

> (legitimately) to be from +1-212-555-1234.
If we get to where we want to get to, you ask AT&T for a cert valid for the number they delegated to you, and then you sign a cert for the call center using your cert, or maybe you ask the CA that issued your cert to do that.

As a practical matter, you ask AT&T to issue (or cause to be issued) a credential to the call center that they use to send calls on the Verizon network.

> an authorized use of my AT&T number.
Yes

> originated on Verizon's network.
Yes, assuming that the call center signed the call, rather than Verizon on behalf of the call center.  I think that most networks probably won’t want to sign for the call center, but they probably will accept, possibly check, and forward the Identity header and body from the call center.

> Is that all close to correct?
Uh huh

---

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Aug 2016 11:45:52 -0400

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 +1 703-593-2683

From: stir <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, August 15, 2016 at 10:21 AM
To: David Frankel <[email-masked]>, "[email-masked]" <[email-masked]>
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.  

 

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. 

Pierce

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.

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.

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. 

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 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”.

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.

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

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 15 Aug 2016 16:05:32 +0000

IMHO per-TN certs are not cacheable, and CRLs would/will be unusable and the result would/will be horrible.

From:  www.infoworld.com/article/3000574/security/the-sorry-state-of-certificate-revocation.html

"To most users, one of the biggest problems with PKI is invisible: the broken certificate revocation process. Digital certificates are supposed to be revoked when their private keys become compromised or for some other reason shouldn't be trusted or used, as determined by the certification authority (CA) that authorized the certificate. A revoked certificate is supposed to be the same as no certificate.

But what actually happens is that most CA admins never revoke certificates, even when they should. Alternatively, people keep using revoked certificates and no one notices. Even more common, the certificate gets revoked, but the software (or the user) doesn't bother to check. Worse still, the software looks to see if the certificate is revoked, can't validate it one way or another, then fails open as if the certificate is good and valid (when the opposite is supposed to happen)."

What seems workable to me is per-carrier certs with few CAs (two?) and limited delegation, and limited/variable application depending upon the level of trustworthiness of the calling number as determined by standard and/or industry best practice.  If a subscriber's device can be authenticated to the network with a high-degree of certainty, then it's calling number(s) should receive the highest "level" of authenticity and not otherwise.

Is it possible, using STIR, to apply multiple signatures?  It seems possible a terminating (or even transit) carrier might want to change or at least apply a different level of authenticity, while still preserving the originating carrier identity.

Pierce

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: August 15, 2016 10:50 AM
To: David Frankel <[email-masked]>
Cc: [email-masked]; [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

> Thanks for that clarification, Brian. You say you "don't think there
> is any disagreement on how we're going to deploy stir" but part of my
> challenge (and for others too, I think) is that many of us don't know
> the details of that "how" because, while the documents don't LIMIT
> what's done, they also are necessarily incomplete (thanks to things
> like country-specific deployment issues being out of scope).
>
> Presumably there is some USA-specific mechanism that says that AT&T is
> the authority for the certificate for my number (based, I would think,
> on the number portability database and/or the LERG).

>
> When I place an outbound call under "normal" circumstances, AT&T will
> sign that call for me and send it on its way. Anybody in the call path
> can see that the call claims to be from +1-212-555-1234, do a number
> portability look-up to see that it's an AT&T number, and then somehow
> know to go to AT&T's certificate authority API to do what it takes to
> verify the signature? (Or maybe there is a consolidated place where
> AT&T deposits that information, along with other carriers, and
> providers along the call path can just go there to check?)

>
> In any case, for this part of the example, anybody along the path,
> including the termination point, can know that the call is legit.

>
> Now, I can engage a call center to make some outbound calls on my
> behalf. (I know this use case has been raised many times.) The call
> center I have chosen uses Verizon as their outbound carrier. So I go
> to AT&T and ask them for the certificate for my number; they give that
> to me and I pass it to my call center. So now they place calls, via
> Verizon, and either the call center (probably) or Verizon (less
> likely) uses my certificate to authenticate the outbound calls they
> make on my behalf, claiming

>
> Again, anybody in the call path can authenticate the call, seeing that
> it is an authorized use of my AT&T number.
Yes

>
> When the call arrives at the terminating end, they see that the call
> is legit. And although it is an AT&T number, they have no clue that it
> was originated on Verizon's network.

Uh huh

> I don't think there is any disagreement on how we're going to deploy
> stir, nor is there any specification that limits or even influences it.
>
> We're going to start deployment at the service provider.  We're going
> to evolve to deployment on the device.  There are some participants
> who think deployment on the device is never going to happen, but they
> don't oppose it, they are just skeptical it will happen.
>
> certificate valid for the TN the call is claiming to be from.  Any
> entity on the path can check, making an assumption that the
> header/body won't be stripped (which could be a bad assumption, but
> there are no protocol police).
>
> If anyone thinks there is text in any of our documents that they
> believe doesn't allow that, please specify where, and I'm sure we can fix it.
>
> origination device, to generate a valid signature.  It's designed to
> let any element on the path check the signature (and thus the
> certificate used to sign it) for validity.
>
> I have suggested that a useful way to deploy it is to have
> interconnection agreements between service providers modified to
> require a certain percentage of validly signed calls by a certain
> date, ratcheting up the percentage over time.  If that included
> checking at transit network interconnects, even if the path downstream
> of that network had SS7 links, we would gain most of the benefit of stir.
>
> depending on the outcome of verification of the signature, the
> greatest value comes from the ability of the authorities to track the
> source of calls back to the originator.  By requiring calls to have
> valid signatures at network interconnections, we provide a tracking
> mechanism back to the origination network, and that will really help
> quite a bit.  It's my opinion that if a large number of "bad" calls
> come from networks that permit call origination from essentially
> anonymous customers, that the authorities will take steps to rein in such networks, but that's just an opinion.
>
> Brian
>
>>> 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.
>>
> within the inter-provider infrastructure, with no direct access
> allowed for end-systems (that are not controlled by a participating
> provider.) That's a major architectural choice and precludes the
> long-term option of direct participation by those independent user
> agents.  Instead it requires them to be slaved to their provider.
>>
>>> be as big mess as you've tried to warn.  And of course these
>>> critical pieces will not be provided here.
>>
> technical point.  To the extent the specification defers this choice,
> it needs to make very clear statements about the choices and the
> effects of those choices.
>>
>>
>>> managed, what is signed, and how the signatures should be
>>> interpreted are the big 3 that occur to me.
>>
> of the service and it needs to be interoperable at a global scale.
> How else will that interoperability be achieved?
>>
> request is valid vs. the request was processed by the signer, I'll
> point and needs to be standardized.  Failure to have the semantic of
> the signature -- it's 'meaning' -- be clear in the technical
> specification has demonstrably caused serious operational problems.
>>

---

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Aug 2016 12:10:26 -0400

On 8/15/16, 11:23 AM, "stir on behalf of David Frankel" <[email-masked] on behalf of [email-masked]> wrote:

    

RS> We are not there yet but the mechanisms are in place right now that can identify any TN and its underlying LRN to the service provider of authority. OCN whatever.  That’s how LEA’s trace calls. Binding that to a private key will be the task at hand for the industry to agree to.  In general, that generally holds true for numbers assigned to 2nd parties in the wholesale carrier market. That is how SKYPE and others get numbers.  Vonage is different in the US it has direct access to the NANP by Report and Order of the FCC and the procedure for non-facilities based carriers to get NANP numbers is now a routine administrative  procedure.  Don’t even get me started about 800 toll free.  Who gets phone numbers and why is the exclusive plenary authority of nation states. I can quote you chapter and verse of the relevant statutes.   

Dave you know all of this ☺   but it’s a useful reminder to those that are fundamentally unaware of how the phone system is fundamentally different from other internet protocols. 

RS> TBD but we do think that many of the public keys will be cached under mutually acceptable terms and conditions. TTL etc.

RS> Correct.

RS>  You are going too far too fast.  How that scenario might be enabled is an operational profile yet to be determined.  It’s understood but we are trying to build rings of defense here. It is not necessary to outline every single corner case on Day 1 and in any event none of those decisions will NOT be made in the IETF.  First lets get the core protocols wrapped up then hopefully hit PAUSE so we can get some operational experience here.

    
    
    David Frankel
    ZipDXR LLC
    Monte Sereno, CA USA
    
    -----Original Message-----
    From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
    Sent: Monday, August 15, 2016 8:05 AM
    To: [email-masked]
    Cc: [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>
    Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

    

    

    Brian

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 15 Aug 2016 16:16:30 +0000

IP-NNI SHAKEN uses a pool of certs per operator, not cert per TN

I believe there may be certain TBD use cases that may warrant cert for those TNs

Martin C. Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: +1.609.903.3360<tel:+1.609.903.3360>
Email: [email-masked]<mailto:[email-masked]>

On Aug 15, 2016, at 12:11 PM, Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>> wrote:

identity.

---

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Aug 2016 12:32:26 -0400

On 8/15/16, 12:05 PM, "stir on behalf of Gorman, Pierce A [CTO]" <[email-masked] on behalf of [email-masked]> wrote:

RS> +1  

    

RS> You are absolutely correct. And that vision is exactly what some of us think will happen.  How that will happen will require a whole bunch of us engineers to suit up, lawyer up and sit down with our regulatory friends. There are any number structural vehicles that could work and of course it’s complicated due to the nature of the NANP itself.  What our Canadian Caribbean friends want to do is entirely up to them.  How the UK wants to participate is again entirely up to Her Majesties Government and its duly constituted NRA. 

RS>  There are some highly unique corner cases where multiple claims can be applied to the same number by multiple entities, which is just one more reason the STIR construct is superior to any form of DKIM/DANE.  

    Pierce

    -----Original Message-----
    From: Brian Rosen [mailto:[email-masked]]
    Sent: August 15, 2016 10:50 AM
    To: David Frankel <[email-masked]>
    Cc: [email-masked]; [email-masked]; Gorman, Pierce A [CTO] <[email-masked]>
    Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

    

    

    Yes

    Uh huh

---

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Aug 2016 12:44:25 -0400

+1

The design of the mechanism lets the holder of the cert decide how many TNs are associated with it.

A carrier could have one, or it could have one per TN, or it could have something in between that.  It’s most likely the latter, and dependent on how the network is built.

Note that this doesn’t matter to anyone other that the carrier and whoever gives the carrier the certs.

We are relying on OCSP to tell us whether a cert is currently valid for a specific TN.

Here, we are much more concerned about change in delegation that compromise of keys.  We have to have procedures to manage compromise of keys, but change in delegation will happen all the time, and key compromise is, albeit non-zero, at least fairly rare.

Another variable that is also outside of IETF work is the lifetime of the keys.  Given the level of automation that will be required to make the mechanism work well, it’s probably possible to have a relatively short cert expiration, which limits the damage key compromise engenders.

Brian

> On Aug 15, 2016, at 12:16 PM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Cell: +1.609.903.3360 <tel:+1.609.903.3360>
> Email: [email-masked] <mailto:[email-masked]>
>  
> 
> On Aug 15, 2016, at 12:11 PM, Gorman, Pierce A [CTO] <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> identity.

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 15 Aug 2016 16:46:12 +0000

+1

Pierce

From: Brian Rosen [mailto:[email-masked]]
Sent: August 15, 2016 11:44 AM
To: DOLLY, MARTIN C <[email-masked]>
Cc: Gorman, Pierce A [CTO] <[email-masked]>; David Frankel <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [stir] Setting Expectations regarding STIR Deployment Realities

+1

Brian

On Aug 15, 2016, at 12:16 PM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote: