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

[[e-mail]]

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.  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?

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. 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.

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.


-----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
***************************************