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

[Christer Holmberg <[e-mail]>]

Hi,

I still think it would be good to have an explicit indicator in the request to indicate that the mechanism is supported by the sender of the Identity header field, and only then would the mechanism be used in responses.

Regards,

Christer

-----Original Message-----
From: Chris Wendt <[e-mail]> 
Sent: maanantai 11. heinäkuuta 2022 10.46
To: Christer Holmberg <[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] Comments/questions on draft-ietf-stir-identity-header-errors-handling-01

So, trying to parse the different threads on these topics i have released a -02 version that:

Adds IANA request for “ppl” parameter for PASSporT identifier Cleans up the text around “STIR” as a protocol allowing for multiple reason-headers with same protocol name Cleans up some of the compact form text and makes it the recommended form.

> On Apr 25, 2022, at 4:59 PM, Christer Holmberg <[e-mail]> 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.
> 
> Why not defining a dedicated "index" parameter? That would also act as an indicator that the AS supports the mechanism to begin with, which would also address the issue in Q5 (because the response with ppt would only be sent if the index is present in the request).
> 
> ---
>  
>>> 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.
> 
> Ok. But, you also need to include the syntax, as it is (I assume) a Reason header field reason-extension.
> 
> Another question is whether it should be called ppt. That already exists, and indicates a TYPE, which this parameter does not. Using a unique parameter name would cause less confusion.
> 
> Of course, if you used an index parameter in the request (see Q1) I guess you could use something similar in the response. "ppi" (pass port index), or something...
> 
> ---
>  
>>> 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.
> 
> Than I think you can make the text much more simple. All you need to do is to say that the error is caused based on the procedures in RFC XXXX, and that SIP response codes are still used.
> 
> ---
>  
>>> 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.
> 
> As mentioned earlier, an index parameter could be used as an indicator that the AS supports the mechanism.
> 
> ---
> 
>>> 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).
> 
> Ok, so the verification proxy would not create the provisional response - it will only piggyback the Reason header(s) in a provisional response sent by the UAS?
> 
> 
> Regards,
> 
> Christer
> 
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> stir mailing list
> mailto:[e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>