Re: [stir] OOB for Service Providers

[Jonathan Rosenberg <[e-mail]>]

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=
[e-mail]> 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:
>
> 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.
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>


-- 
Jonathan Rosenberg, Ph.D.
[e-mail]
http://www.jdrosen.net