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

[[e-mail]]

Snippet from Section 5.3.2 of ATIS-1000074.v2

----- BEGIN of snippet -----

If any of the above error conditions are detected, the terminating network shall convey the response code and
reason phrase back to the originating network, indicating which one of the five error scenarios has occurred, as
follows:

 If local policy dictates that the call should not proceed due to the error, then the terminating network shall
include the error response code and reason phrase in the status line of a final 4xx error response sent to
the originating network.

 If local policy dictates that the call should continue, then the terminating network shall include the error
response code and reason phrase in a Reason header field (defined in IETF RFC 3326, The Reason
Header Field for the Session Initiation Protocol [SIP]) in the next provisional or final response sent to the
originating network as a result of normal terminating call processing.

Example of Reason header field:
Reason: SIP ;cause=436 ;text="Bad Identity Info"
In addition, if any of the base claims or SHAKEN extension claims are missing from the PASSporT claims, the
verification service shall treat this as a 438 ‘Invalid Identity Header’ error and proceed as defined above.

----- END of snippet ----- 

As far as I know, there are no instances of a local policy which fails calls because of STIR/SHAKEN verification failure.  If so, that is also egregious.  SHAKEN call verification routinely fails for lots of reasons (no pun intended).  

Here is why.

Perhaps the most common reason is number normalization in the telephone numbers in the From and/or To where a '+' symbol and/or a '1' are added or stripped somewhere in the call path between the AS and the VS.  Another common reason is improperly constructed certificate chain.  Another common reason for failed verification is an uncached newly minted certificate verification where download and validation takes longer than common VS implementations will allow, so calls are permitted to proceed without verification.  In the case of a certificate used with calls issued by an autodialer such as is used for sending emergency alerts to a significant community, it can result in dozens or hundreds of calls failing verification before the cert is cached and verifications complete successfully.

So the local policy that I assume is used in virtually every STI-VS implementation is the 2nd one in the list from ATIS-1000074.  i.e., it uses an RFC 3326 REASON header, per the SHAKEN standard.

Pierce

-----Original Message-----
From: Paul Kyzivat <[e-mail]> 
Sent: Wednesday, July 27, 2022 11:41 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [stir] sipcore Digest, Vol 158, Issue 1

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