Subject: [stir] PASSporT Diverted: implications of nesting

From: Eric Burger <[email-masked]>
Date: Wed, 18 Jul 2018 11:21:40 -0400

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.

---

From: Eric Burger <[email-masked]>
Date: Wed, 18 Jul 2018 16:11:32 -0400

Presuming we go with MUST in the other thread, I would (editorially) suggest letting implementors know the motivation are all the stated use cases by Christer et al. OOB support is a nice side effect, as opposed to the rationale for the mechanism.

> On Jul 18, 2018, at 1:55 PM, williw <[email-masked]> wrote:
> 
> Eric,
> Fully agree and lets wait what comes out of this “experimental" state ;-)
> 
> IMHO, going the passport way is over engineering anyhow. We have headers and SIP messages signed with a valid TN certificate. These Signed SIP messages can also be stored in the CPS (encrypted and ZIP'ed if needed) for OOB. Later on these SIP messages can be reused for following SIP-links after the the PSTN link …
> This would be fully compliant to LTE interworking after PSTN as well.
> I do not really understand why this JWT passports have been introduced at all.
> I might be missing something here. Lets see what we learn today.
> 
> Willi
> 
> 
>> On 18. Jul 2018, at 17:21, Eric Burger <[email-masked]> wrote:
>> 
>> Signed PGP part

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 18 Jul 2018 20:14:41 +0000

There are implementation issues w div

Martin C Dolly
AT&T
Lead Member of Technical Staff
Core Network & Gov’t Regulatory Standards
+1 609 903 3360

> On Jul 18, 2018, at 4:11 PM, Eric Burger <[email-masked]> wrote:
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 18 Jul 2018 21:03:06 +0000

We've said for some time that more than one <insert credential here> would be a likely consequence of non-basic call flows.

DoS attacks using <insert credential here> has not been discussed much, but only the most naïve have ignored the possibility (likelihood?).

My suggestion is to find lightweight ways to nest/list or ONLY use the most basic orig/term assumptions.  i.e., consider that some carriers may by policy choose to block traffic with nested/list credentials because of the concerns of DoS and TL:DR.

Pierce

-----Original Message-----
From: DOLLY, MARTIN C [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 3:15 PM
To: Eric Burger <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] PASSporT Diverted: implications of nesting

Martin C Dolly
AT&T
Lead Member of Technical Staff
Core Network & Gov't Regulatory Standards
+1 609 903 3360

>> Fully agree and lets wait what comes out of this "experimental" state
>> ;-)
>>
>> IMHO, going the passport way is over engineering anyhow. We have
>> headers and SIP messages signed with a valid TN certificate. These Signed SIP messages can also be stored in the CPS (encrypted and ZIP'ed if needed) for OOB.. Later on these SIP messages can be reused for following SIP-links after the the PSTN link ... This would be fully compliant to LTE interworking after PSTN as well.
>>> 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.
>>>
>>> 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.
>>>

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Richard Shockey <[email-masked]>
Date: Wed, 18 Jul 2018 17:10:57 -0400

+1 

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 7/18/18, 4:11 PM, "stir on behalf of Eric Burger" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Jul 2018 14:04:26 +0000

Hi,

Based on what I've heard and read, the issue regarding multiple header fields versus nesting seem to be mainly cosmetic (at least as far as in-band in concerned).

However, Section 3.1 says:

   "In some use cases, instead of having multiple unconnected PASSporTS
   associated with a single call, it makes more sense to nest the
   PASSporTs, explicitly relating two PASSporTs to one another."

What exactly does "relating" mean? What will we lose if we do NOT use nesting?

Regards,

Christer

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: 18 July 2018 22:11
To: Eric Burger <[email-masked]>; [email-masked]
Subject: Re: [stir] PASSporT Diverted: implications of nesting

+1 

— 
Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Thu, 19 Jul 2018 14:15:30 +0000

@Willi - Your comments questioning passports and JWT would have been potentially helpful about 2 or 3 years ago.  Questioning the effort and complexity is understandable, but in the US anyway my assumption is we are way too far down the road in terms of developed and issued ATIS standards and keen US Govt interest in SHAKEN to entertain the questions in earnest (although perhaps you don't intend that).

The US Govt interest is most noticeable in active FCC investigative work for regulatory rulings including an FCC-commissioned report by the Call Authentication Trust Anchor (CATA) working group of the North American Numbering Council (NANC) on implementing a SHAKEN Governance Framework.

OOB STIR is interesting and a reasonable suggestion for a way to integrate non-SHAKEN capable legacy networks with a SHAKEN-enabled PSTN.  And, for the presumably "small, mostly rural" carriers that would be the presumed primary target of US federal regulation regarding OOB mechanisms, perhaps not too much of a burden (because of the relatively small amount of orig/term traffic ).  I do wonder what interesting operational (and security?) issues will occur during the "experimental" state, especially for the larger transit or incumbent carriers who will be more impacted by the aggregate of OOB traffic.

Discussion of complex new functions in SIP (or SIP + HTTP + certs + zip) can be a touchy subject as US carriers, at least, are subject to existing federal regulation on rural termination rates, post-dial delay, and reportable outages all of which may be negatively impacted during the "experimental" state.

All that said, in general, from a personal perspective I will heartily agree with any concerns expressed about increased complexity (pronounced "fragility") of call processing.

Pierce

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 3:12 PM
To: [email-masked]
Subject: Re: [stir] PASSporT Diverted: implications of nesting

> headers and SIP messages signed with a valid TN certificate. These Signed SIP messages can also be stored in the CPS (encrypted and ZIP'ed if needed) for OOB. Later on these SIP messages can be reused for following SIP-links after the the PSTN link … This would be fully compliant to LTE interworking after PSTN as well.