Re: [stir] OOB for Service Providers

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 <richard@shockey.us>
Date: Saturday, March 14, 2020 at 12:02 PM
To: Jonathan Rosenberg <jdrosen@jdrosen.net>, "Peterson, Jon" <jon.peterson@team.neustar>
Cc: "stir@ietf.org" <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<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

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: stir <stir-bounces@ietf.org> on behalf of Jonathan Rosenberg <jdrosen@jdrosen.net>
Date: Saturday, March 14, 2020 at 2:36 PM
To: "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>
Cc: "stir@ietf.org" <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<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-peterson-stir-servprovider-oob-00__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVWA-tY9eQ$>

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<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!togNaqJ0ImDyAEHnybJt2NI9iD9WmkDtolcx1ixhHHjntQqEyZ9_BdP-tQmQiVUVqjI_7A$>

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