Re: [stir] sipcore Digest, Vol 158, Issue 1

[Paul Kyzivat <[e-mail]>]

Comments inline...

On 7/27/22 10:22 AM, [e-mail] wrote:
> In the STIR WG discussion yesterday there was commentary about having
> STIR-specific error information in REASON.
> 
> It occurred to me as people discussed what an STI-AS can do with the
> information in a REASON from an STI-VS that an STI-AS is rarely in the call
> path of an error response to the signature placed there by the STI-AS.
> 
> I point this out so that people can be thinking about this aspect.
> 
> An STI-VS doesn't typically tell the STI-AS "here's what is wrong with what
> you put in the SIP Identity header or certificate chain".
> 
> Most of the time, the STI-VS is going to be telling the originating UAC,
> "here is what is wrong with what your (3rd party) STI-AS put in the SIP
> Identity header or certificate chain".
> 
> Also note that this use of REASON has (does? will?) cause unnecessary call
> failures.
> 
> In the introduction to RFC 3326, it says:
> 
>     Clients and servers are free to ignore this header field.  It has no
>     impact on protocol processing.
> 
> The 2nd sentence is egregiously false. 

Can you give an example?

If a Reason is returned in a final response then the protocol processing 
has already failed. How would the presence or absence of Reason make it 
worse?

If it is returned in a 1xx response then the call may still succeed or 
fail. For the Reason to affect that the UAC would have to take some 
action on the subsequent call flow that was chosen due to the content of 
the Reason header. In that case you are correct that it has some impact, 
but is it egregious? If the implementer is any good, the impact is 
presumably intended to improve the call experience. But if the Reason 
header is instead ignored, then the call may well still complete.

The obvious case here is when the verifier has decided to allow the call 
to proceed even though the stir identity couldn't be verified. In this 
case the UAC could have a policy to drop the call or alert the user. 
Without processing the Reason the caller will have no clue. This kind of 
policy will be more important when used with sending Identity from UAS 
to UAC.

> And can someone explain how to code
> "free to ignore"?  Make a choice to ignore using a random number generator
> for entertainment?  Always ignore?  Never ignore?  Always write new code to
> adapt to every possible new error?

It could be anything. But the most obvious is that some implementations 
will choose to ignore the reason all the time, while others will choose 
to process it in some way that provides a better call experience.

This is the sort of thing that distinguishes better implementations.

> In my experience, a certain vendor chose to kill calls which had a
> STIR/SHAKEN 4xx in a REASON header because they could.  i.e., they didn't
> understand the 4xx but it was a 4xx which therefore indicated the expected
> final response would be a call failure, so they killed the calls.
> Calls which would have otherwise completed, instead failed because of an
> unknown 4xx in the REASON header. 

Poor quality of implementation. Sadly they can still claim conformance 
to the standard. Also, this couldn't have been with STIR reason codes, 
since those are only now being defined. It doesn't necessarily say 
anything about the processing of STIR reason codes, which is yet to be 
written.

> This caused Network Operations staff to
> write header manipulation rules which stripped the offending inbound error
> messages at the edge of the network.  An argument with the vendor about
> killing otherwise good calls led to a discussion of paying for and
> scheduling new development which, as far as I know, never happened because
> it was cheaper to strip the error messages at the edge of the network.

If that is the way you want to do business then you live with the 
consequences.

> RFC 3326 correctly observed:
> 
> ... status codes that provide information about the
>     user and about session parameters are typically useful for
>     implementing services whereas status codes intended to report errors
>     about a request are typically useful for debugging purposes.
> 
> So, I will suggest that errors in a REASON that are intended to be used for
> "debugging purposes" and which should not result in calls being killed
> unnecessarily, should only ever be 1xx.  I think this implies ALL error
> messages related to STIR/SHAKEN in a REASON should be 1xx.

Part of the problem here is leaping to the conclusion that the meanings 
of STIR reason codes are the same as SIP reason codes. They are not. At 
the least *most* SIP reason codes (which are the same as SIP response 
codes) make no sense if used as STIR reason codes. And even for the ones 
that are, their semantics will differ when used as a STIR reason code.

It may be worth creating a completely new name space (number space) for 
STIR reason codes just to avoid this confusion. But that isn't strictly 
necessary. But some text somewhere describing how the STIR reason codes 
SHOULD/SHOULD NOT be used is something that should be done.

	Thanks,
	Paul

> -----Original Message-----
> From: sipcore <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Tuesday, July 26, 2022 2:00 PM
> To: [e-mail]
> Subject: sipcore Digest, Vol 158, Issue 1
> 
> Send sipcore mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/sipcore
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of sipcore digest..."
> 
> 
> Today's Topics:
> 
>     1. I-D Action: draft-ietf-sipcore-multiple-reasons-00.txt
>        ([e-mail])
>     2. Re: I-D Action: draft-ietf-sipcore-multiple-reasons-00.txt
>        (Robert Sparks)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 25 Jul 2022 13:31:37 -0700
> From: [e-mail]
> To: <[e-mail]>
> Cc: [e-mail]
> Subject: [sipcore] I-D Action:
> 	draft-ietf-sipcore-multiple-reasons-00.txt
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Session Initiation Protocol Core WG of the
> IETF.
> 
>          Title           : Multiple SIP Reason Header Field Values
>          Author          : Robert Sparks
>    Filename        : draft-ietf-sipcore-multiple-reasons-00.txt
>    Pages           : 4
>    Date            : 2022-07-25
> 
> Abstract:
>     The SIP Reason Header Field as defined in RFC 3326 allows only one
>     Reason value per protocol value.  Practice shows it is useful to
>     allow multiple values with the same protocol value.  This update to
>     RFC 3326 allows multiple values for an indicated registered protocol
>     when that protocol defines what the presence of multiple values
>     means.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sipcore-multiple-reasons/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-sipcore-multiple-reasons-00.html
> 
> 
> Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 25 Jul 2022 17:05:19 -0500
> From: Robert Sparks <[e-mail]>
> To: [e-mail]
> Subject: Re: [sipcore] I-D Action:
> 	draft-ietf-sipcore-multiple-reasons-00.txt
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Resending from the correct address:
> 
> On 7/25/22 4:07 PM, Robert Sparks wrote:
>> Hello sipcore:
>>
>> This is just the renaming of draft-sparks-sipcore-multiple-reasons to
>> draft-ietf-sipcore-multiple-reasons.
>>
>> There has been a lot of feedback about some short things to add, and I
>> am working on those as a 01. This -00 is here to make comparisons
>> later easier.
>>
>> Right now, I'm keeping the source at
>> https://github.com/rjsparks/draft-ietf-sipcore-multiple-reasons. PRs
>> are welcome. I'm happy to move that repo to a sipcore github
>> organization should the group choose to have one.
>>
>> RjS
>>
>> On 7/25/22 3:31 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Session Initiation Protocol Core WG
>>> of the IETF.
>>>
>>> ???????? Title?????????? : Multiple SIP Reason Header Field Values
>>> ???????? Author????????? : Robert Sparks ?? Filename??????? :
>>> draft-ietf-sipcore-multiple-reasons-00.txt
>>> ?? Pages?????????? : 4
>>> ?? Date??????????? : 2022-07-25
>>>
>>> Abstract:
>>> ??? The SIP Reason Header Field as defined in RFC 3326 allows only
>>> one ??? Reason value per protocol value.? Practice shows it is useful
>>> to ??? allow multiple values with the same protocol value.? This
>>> update to ??? RFC 3326 allows multiple values for an indicated
>>> registered protocol ??? when that protocol defines what the presence
>>> of multiple values ??? means.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-sipcore-multiple-reasons/
>>>
>>> There is also an HTML version available at:
>>> https://www.ietf.org/archive/id/draft-ietf-sipcore-multiple-reasons-0
>>> 0.html
>>>
>>>
>>>
>>> Internet-Drafts are also available by rsync at
>>> rsync.ietf.org::internet-drafts
>>>
>>>
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
> 
> 
> ------------------------------
> 
> End of sipcore Digest, Vol 158, Issue 1
> ***************************************
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir