[stir] PASSporT Diverted: implications of nesting

[Eric Burger <[e-mail]>]

I was thinking about nesting PASSporTs that represent diversion versus listing PASSporTs. What got me thinking was the statement in draft-ietf-stir-passport-divert-03 that says:

	However, nested PASSPorTs could result in lengthy Identity headers, and some operational experience is needed to ascertain how viable multiple layers of nesting will be.

My immediate thought was, “That is OK, so long as the expected status for the draft will be Experimental, not Proposed Standard.” Of course, that thought did not sit well with me. The idea that we are going to standardize something we *hope* will work does not sound responsible.

That got me thinking with my Evil Hat(tm) on: it would be pretty trivial to setup a call forwarding chain to build a VERY long Identity header. Given how software gets done, I could imagine a rather nice and easy denial of service attack vector being created here.

Then I looked at the rationale for the nested object in the first place: for storage for out-of-band Call Placement Service.

How about this: instead of nested PASSporTs to support OOB, with the concomitant risk for DoS, we say we will standardize on a list of Identity headers. STIR OOB then could define how to package the list of identity headers into a single object for OOB. I would offer the issues are orthogonal. While it is ‘nice’ to have the same object bits for OOB as for the rest of the STIR ecosystem, how an OOB-aware system packages and stores the objects need not impact STIR itself.

A zero-order model for OOB might be to ZIP the headers first, sign them, and then store them at the CPS. When retrieved, the CPS would send the compressed object to the requestor, who by definition would know how to unzip and order the Identity headers.

Just a thought.