[stir] WG LC Comments: draft-ietf-stir-passport-divert-05

[Eric Burger <[e-mail]>]

Most of my comments and nits have been identified and mostly addressed already. Here’s what’s ‘new’:

Section 4.1:
Is there a scenario where the terminating verification service WOULD NOT do verification? There’s a bunch of text on how the diverting platform might or might not do verification and the terminating platform might or might not do verification.

Would it not be better to point out the diverting platform would really, really, really (SHOULD?) want to verify the inbound call, because it will be the reputation of the diverting platform on the line if it signs the diversion on a bad call?

Conversely, why would any terminating provider EVER trust a diversion from a PBX? I.e., would not a terminating provider really, really, really (SHOULD?) want to verify all of the signatures in the chain?

Towards the end of 4.1 we talk about RPH. Is there any issue of forwarding an RPH call? One would think that once a priority call hits a PBX, it will lose its priority. I am not stating a fact that I know, but for those in the RPH world, what is your understanding? Also, this paragraph is dense and a bit confusing. An example would go a long way in providing clarity.


Section 4.2:
Why would a failure in the verification chain EVER result in anything other than a failed verification, other than the obvious, “the certificate expired three minutes ago”? Remember, MAY = Never Will Happen.

Section 4.2, Fifth step
What is a “multiple based PASSporTs”?

Section 5:
As Ben pointed out in his review, div-o seems to be a different beast that might better be addressed in a separate document. In fact, if the only purpose of it is to support OOB, I would insist it go into a separate document. Conversely, if div-o will be the mechanism to support TN-PoP, then say so. Of course, if that is what div-o is about, again perhaps it would be better served in a separate document or as part of the eventual mechanism that allows the originating caller to sign a call (classic STIR) as well as an authentication service signing the call (SHAKEN).

Section 7:
Why would we EVER allow a caller to pickup a signature from a 302 redirecting server? The text goes to great lengths to explain *how* to do it, but never says *why*. I’m having trouble groking the use case. A spammer sends INVITEs to a number, gets back a (set of) signed PASSporTs to include in their spam calls? Why would I ever care if the spammer found my current contact from a redirect from a registrar instead of guessing my current contact directly? Is there a double-secret use case hiding here?

Section [Missing]: Privacy Considerations
Sprinkled throughout the document are privacy considerations, like how this mechanism is inappropriate for anonymization services (see, e.g., the last paragraph of Section 4.2).