Subject: [stir] PASSporT Diverted: MUST or SHOULD nest

From: Eric Burger <[email-masked]>
Date: Wed, 18 Jul 2018 15:57:09 -0400

The very next paragraph:

   The "opt" extension is RECOMMENDED for use within in-band SIP use
   cases as well.  The alternative, having multiple Identity headers in
   a SIP request, could be confusing for some verification services.
   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.

This is a way of saying that diverted calls SHOULD use nested PASSporTs, not iterative Identity headers.

Experience for SHOULD is SHOULD = MAY = not done. However, someone always decides to do it anyway, that breaks things, increases software complexity, etc.

Hums in the room over the past few IETFs was there was a need for nested PASSporTs and it would make diversion easier to generate and process, especially in forking scenarios. Conversely, as noted in the document, we could end up with *extremely* long SIP *headers*, not just SIP messages. The likelihood of buffer overflows, etc. grows in this situation.

I would offer we CHOSE one or the other: either :-

1. Only have iterative PASSporTs. Don’t bother with nested PASSporTs.

2. Allow nested PASSporTs, and *mandate* (MUST) using nested PASSporTs for diversion.

If we go with #2, be sure to note in the Security Considerations section the risk of overly long headers. That would make me happy on that issue.

What say the list?

---

From: Mary Barnes <[email-masked]>
Date: Wed, 18 Jul 2018 15:00:03 -0500

I'm in favor of option #2.

Regards,
Mary

On Wed, Jul 18, 2018 at 2:57 PM, Eric Burger <[email-masked]>
wrote:

> Experience for SHOULD is SHOULD = MAY = not done. However, someone always
> decides to do it anyway, that breaks things, increases software complexity,
> etc.
>
> Hums in the room over the past few IETFs was there was a need for nested
> PASSporTs and it would make diversion easier to generate and process,
> especially in forking scenarios. Conversely, as noted in the document, we
> could end up with *extremely* long SIP *headers*, not just SIP messages.
> The likelihood of buffer overflows, etc. grows in this situation.
>
> If we go with #2, be sure to note in the Security Considerations section
> the risk of overly long headers. That would make me happy on that issue.
>
> What say the list?
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>
>