Re: [stir] Comments/questions on draft-ietf-stir-identity-header-errors-handling-01

> On Apr 22, 2022, at 4:49 PM, Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi,
>  
> I took a look at draft-ietf-stir-identity-header-errors-handling-01, and I have some questions and comments.
>  
> ---
>  
> Q1: The draft uses a ppt parameter to associated a Reason header field with an Identity header field. That sounds very “clumsy” in my opinion. Also, how exactly is the parameter value compared with the PassPORT? Byte by byte? How does that work if you use a compact form?

Comparing as a JWT Base64 encoded string value whether full or compact.  We just needed a unique value that the AS (or originating side) would know about, so either full PASSporT or just the signature is unique enough for the AS to reference on which identity header passed in the INVITE caused the error.

>  
> ---
>  
> Q2: Where is the ppt parameter defined? I see no Reason header field reason-extension defined for it, and no IANA registration.

This is the document that defines it, but yes i did now look that i should request IANA registeration as Header Field Parameters and Parameter Values.  I will add that request to the document.

>  
> ---
>  
> Q3: The definition of the “STIR” protocol in Section 3 is very confusing.
>  
> For example, the text says:
>  
>    “This will differentiate current protocols, specifically
>    "SIP" which is currently in wide industry usage, from the [RFC8224]
>    defined error cause codes”
>  
> Differentiate SIP from what protocol? The error cause codes defined in 8224 are SIP cause codes, so what protocol does “STIR” refer to?
>  
> If the semantics of “STIR” is identical to “SIP”, with the only difference being that it allows you to use multiple Reason header fields with “STIR”, why not say so?

The intent is that STIR is another “protocol” just like Q.850 and SIP differentiate a class of reasons.  We are simply defining another type of reasons specific to STIR, so that existing implementations aren’t confused.  We discussed this pretty extensively in past meetings as likely best option.

>  
> ---
>  
> Q4: The text says:
>  
>    “The "ppt" parameter
>    for the Reason header field is optional, but RECOMMENDED, in
>    particular for cases that a SIP INVITE contains multiple Identity
>    header fields.” 
>  
> And if it is not included? How will things work then?
>  
> ---

The intent is that if you only have one identity header/identity header error you don’t need to include ppt.  I could clarify that and make it mandatory if you have more than one identity header.

>  
> Q5: Section 7 says that the Authentication Server MUST remove the Reason header field from the response. But, what if the Authentication Server is an 8224-only implementation? In that case it might pass on the Reason header field. Section 10 does say something about the Reason header field being passed beyond the Authentication Server, but I am not sure whether it talks about the same case.
>  
> ---

That is always the case for any specification that comes in the future.  I think we are early enough that scenarios for multiple identity headers is only starting to appear and would like to adopt this in SHAKEN. This may be a good reason to adopt stronger language about using compact form/only signature as identifier.

>  
> Q6: The text talks about including the Reason header in a provisional response, in case local policy dictates that the session setup shall continue.
>  
> First, I am not sure whether that is how 3326 defines usage of Reason in provisional responses. It is used to help in forking scenarios, when final responses sent on different early dialogs are dropped by the forking proxy.
>  
> Second, there is no text on how this provisional response is created. Is the sender of the Reason header field going to generate a To tag? Does that mean the sender of the Reason header field is acting as a B2BUA?
>  
> ---

First, this is the same scheme we already have defined in ATIS-1000074, but the provisional response is created just like any provisional response (so yeah, the UAS sending the provisional response would have add a To tag to complete the early dialog). As the response travels toward the UAC, it's going to arrive at a proxy who knows if and why verification failed (e.g., the IBCF, or maybe the STI-VS itself in the case where the verification API is SIP), and that proxy will add the proper Reason header(s).

>  
> I may have more comments/questions later, but I will start with these.
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> stir mailing list
> stir@ietf.org <mailto:stir@ietf.org>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>