Subject: [stir] OOB for Service Providers

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 13 Mar 2020 21:03:46 +0000

So we'll all be sad not to meet in Vancouver this time, but given that we're scheduling a virtual meeting, I did want to give a pointer to a new draft:

https://tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00

This draft works toward a more concrete protocol implementation of out-of-band STIR, for the case where a service provider (could be a carrier, large enterprise, or an OTT service) advertises a CPS that collects PASSporTs for calls that would terminate on its network. Because it is tightly coupled to the terminating side of the call, this flavor of CPS has a different security posture than a public CPS that is necessarily decoupled from call signaling entirely.

I know there is some talk out there about "OOB SHAKEN" these days, and to be clear, this is not an "OOB SHAKEN" draft - this looks at general tools that might ultimately support efforts to deliver SHAKEN out-of-band, but it does not limit its consideration of the problem space to the way that SHAKEN currently handles certification and signing. The plan is to deliver a mechanism that is applicable to a variety of potential policies in that regard.

If folks here are interested in working on this, let's discuss it a bit, and maybe find some agenda time for it.

Jon Peterson
Neustar, Inc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 14 Mar 2020 14:36:32 -0400

Thanks Jon - very interesting concept.

In order for this to work, a call originator needs to figure out which
carrier's CPS to send the passport to, for a given dialed number. The draft
proposes that this info can be obtained from the TNAuthList in the carriers
certificate used to sign the cps advertisement. This presumes that
terminating carriers are willing to actually enumerate the set of TNs they
own in a certificate, and make this available to enterprises, contact
centers or other entities which are going to place calls to those numbers.

I think the jury is still out on whether these certs will end up containing
actual numbers and prefixes, as opposed to OCNs. Classic inbound STIR and
OOB can work without number lists, whereas this draft requires the TN list
in order to facilitate routing (i.e., identifying the terminating cps).

So - I think the key question is whether this routing is going to be
feasible in practice or not.

Thx,
Jonathan R.

On Fri, Mar 13, 2020 at 5:04 PM Peterson, Jon <jon.peterson=
[email-masked]> wrote:

> So we'll all be sad not to meet in Vancouver this time, but given that
> we're scheduling a virtual meeting, I did want to give a pointer to a new
> draft:
>
> This draft works toward a more concrete protocol implementation of
> out-of-band STIR, for the case where a service provider (could be a
> carrier, large enterprise, or an OTT service) advertises a CPS that
> collects PASSporTs for calls that would terminate on its network. Because
> it is tightly coupled to the terminating side of the call, this flavor of
> CPS has a different security posture than a public CPS that is necessarily
> decoupled from call signaling entirely.
>
> I know there is some talk out there about "OOB SHAKEN" these days, and to
> be clear, this is not an "OOB SHAKEN" draft - this looks at general tools
> that might ultimately support efforts to deliver SHAKEN out-of-band, but it
> does not limit its consideration of the problem space to the way that
> SHAKEN currently handles certification and signing. The plan is to deliver
> a mechanism that is applicable to a variety of potential policies in that
> regard.
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: Richard Shockey <[email-masked]>
Date: Sat, 14 Mar 2020 15:02:14 -0400

The larger question is whether OOB is worth anyone’s time or could we better spend our efforts encouraging more or perhaps even mandating SIP/IMS Interconnection. 

>From a purely regulatory perspective there are lots of perverse incentives in the US and Canadian systems to discourage SIP an encourage classic TDM.   The US Intercarrier Compensation regime is one example and ongoing dilemma and lack of consensus of which methodology does the industry prefer to handle number translations.  Yes I know..6116 vs the NPAC. 

>From where I sit that question is coming up more and more.  I certainly don’t object to exploring all the options here since there its clear some jurisdictions are going to have predominantly TDM networks for the foreseeable future. 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Jonathan Rosenberg <[email-masked]>
Date: Saturday, March 14, 2020 at 2:36 PM
To: "Peterson, Jon" <jon.peterson=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] OOB for Service Providers

In order for this to work, a call originator needs to figure out which carrier's CPS to send the passport to, for a given dialed number. The draft proposes that this info can be obtained from the TNAuthList in the carriers certificate used to sign the cps advertisement. This presumes that terminating carriers are willing to actually enumerate the set of TNs they own in a certificate, and make this available to enterprises, contact centers or other entities which are going to place calls to those numbers. 

I think the jury is still out on whether these certs will end up containing actual numbers and prefixes, as opposed to OCNs. Classic inbound STIR and OOB can work without number lists, whereas this draft requires the TN list in order to facilitate routing (i.e., identifying the terminating cps).

So - I think the key question is whether this routing is going to be feasible in practice or not.

Thx,

Jonathan R.

On Fri, Mar 13, 2020 at 5:04 PM Peterson, Jon <jon.peterson=[email-masked]> wrote:

Jon Peterson
Neustar, Inc.

 

-- 

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Sun, 15 Mar 2020 19:14:11 +0000

The larger question is a good one and it’s difficult to answer, but my sense is the question can be asked in more simple euphemistic terms.  Is it better to apply a band-aid or a fork-lift?

My assumption is SHAKEN OOB will end up being fairly quickly deployable without a large and time-consuming upfront investment on behalf of the TDM-based service providers.

And, I don’t know what anybody else’s view is on consolidation, but I suspect 5G rural wireless broadband is going to dramatically re-paint the landscape, perhaps even before ICC is resolved.  i.e., a fork-lift may be the wrong tool.

Pierce

From: Richard Shockey <[email-masked]>
Sent: Saturday, March 14, 2020 2:02 PM
To: Jonathan Rosenberg <[email-masked]>; Peterson, Jon <jon.peterson=[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] OOB for Service Providers

—

Richard Shockey

Shockey Consulting LLC

www.shockey.us<http://www.shockey.us>

www.sipforum.org<http://www.sipforum.org>

richard<at>shockey.us

PSTN +1 703-593-2683

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Jonathan Rosenberg <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 14, 2020 at 2:36 PM
To: "Peterson, Jon" <jon.peterson=[email-masked]<mailto:jon.peterson=[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] OOB for Service Providers

Thx,
Jonathan R.

On Fri, Mar 13, 2020 at 5:04 PM Peterson, Jon <jon.peterson=[email-masked]<mailto:[email-masked]>> wrote:
So we'll all be sad not to meet in Vancouver this time, but given that we're scheduling a virtual meeting, I did want to give a pointer to a new draft:

I know there is some talk out there about "OOB SHAKEN" these days, and to be clear, this is not an "OOB SHAKEN" draft - this looks at general tools that might ultimately support efforts to deliver SHAKEN out-of-band, but it does not limit its consideration of the problem space to the way that SHAKEN currently handles certification and signing. The plan is to deliver a mechanism that is applicable to a variety of potential policies in that regard..

Jon Peterson
Neustar, Inc.

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

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net
_______________________________________________ stir mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/stir

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 Mar 2020 00:58:15 +0000

Well, the draft today sketches a couple of ways that CPS discovery might happen, which in the short term could be just bilateral agreements. Indeed, if we’re willing to assume a monolithic CPS serving a particular closed service provider community, you could easily solve this with a flat file. That might prove the easiest way to get something like this started.

A mature architecture would need some more universal CPS discovery mechanism. This is indeed analogous to the call routing problem: industry databases exist today that let you looking up the OCN’s associated with called numbers, so even if the CPS advertisement is signed with an OCN cert, that might actually be sufficient for relying parties with access to those databases. The extent that we expect relying parties to look behind the OCNs at individual numbers is still controversial in some circles, but at the end of the day, I think we need to get there one way or another.

For example, an RFC8226 certificate can hold a URL pointing to a by-reference list of telephone numbers associated with the certificate (which may indeed be nothing but a shim layer in front of the aforementioned databases), and at the time of certification, such a by-reference list could be added, which could allow a calling party to figure out if CPS advertisements are legitimate or not. So we have a couple ways to do this that may have some promise. What will work for a given environment may vary. For an IETF spec anyway – even one headed for standards track - I think we may want to enumerate approaches, some of which are mandatory-to-implement, but leave it to deployment profiles to narrow in on particular solutions.

Jon Peterson
Neustar, Inc.

From: Jonathan Rosenberg <[email-masked]>
Date: Saturday, March 14, 2020 at 11:37 AM
To: "Peterson, Jon" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] OOB for Service Providers

Thx,
Jonathan R.

https://tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbZLfCnog$>

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbVIpJxmQ$>

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net<https://urldefense.com/v3/__http:/www.jdrosen.net__;!!N14HnBHF!vycse32NSVgY87Yd4_4liS413HMx-_Y1pOERQmzLoYDyvuZTsVrmbxuMlPQwOxbMEtLRUQ$>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 20 Mar 2020 00:59:39 +0000

I do agree that universal in-band end-to-end SIP connectivity is the endgame, and it would obviate the need for a STIR OOB mechanism. This is just a question of whether, given the aggressive timeframes out there, we could use a fallback to deal with the tactical problem of beating robocalls. Like you, I fear that we are going to have to cope with TDM in the network for the foreseeable future.

Jon Peterson
Neustar, Inc.

From: Richard Shockey <[email-masked]>
Date: Saturday, March 14, 2020 at 12:02 PM
To: Jonathan Rosenberg <[email-masked]>, "Peterson, Jon" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] OOB for Service Providers

—

Richard Shockey

Shockey Consulting LLC

www.shockey.us<https://urldefense.com/v3/__http:/www.shockey.us__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVWcRlokmQ$>

www.sipforum.org<https://urldefense.com/v3/__http:/www.sipforum.org__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVUnOjhrKA$>

richard<at>shockey.us

PSTN +1 703-593-2683

Thx,
Jonathan R.

https://tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVWA-tY9eQ$>

Jon Peterson
Neustar, Inc.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVUVqjI_7A$>

--
Jonathan Rosenberg, Ph.D.
[email-masked]<mailto:[email-masked]>
http://www.jdrosen.net<https://urldefense.com/v3/__http:/www.jdrosen.net__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVVIplG86A$>
_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVUVqjI_7A$>