Re: [stir] OOB for Service Providers

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 <richard@shockey.us>
Sent: Saturday, March 14, 2020 2:02 PM
To: Jonathan Rosenberg <jdrosen@jdrosen.net>; Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org>
Cc: stir@ietf.org
Subject: Re: [stir] OOB for Service Providers

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<http://www.shockey.us>

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

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> on behalf of Jonathan Rosenberg <jdrosen@jdrosen.net<mailto:jdrosen@jdrosen.net>>
Date: Saturday, March 14, 2020 at 2:36 PM
To: "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org<mailto:jon.peterson=40team.neustar@dmarc.ietf.org>>
Cc: "stir@ietf.org<mailto:stir@ietf.org>" <stir@ietf.org<mailto:stir@ietf.org>>
Subject: Re: [stir] OOB for Service Providers

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=40team.neustar@dmarc.ietf.org<mailto:40team.neustar@dmarc.ietf.org>> 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
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir

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