Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt

[Chris Wendt <[e-mail]>]

Hi Pierce,

This is text in RFC8224, not in this document and i think your comment is regarding sending 4xx error codes as stated in 8224, not just reason headers with cause codes as an alternative, so i just want to clarify what action you think i should take.

-Chris

> On Sep 15, 2022, at 4:09 PM, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Chris,
>  
> Thank you for the response.  I got an additional response from another engineer for whom I also have great respect (meaning he and you both) and he also questioned some of what I was sharing.  Without naming names I’ll just say my experience includes “good” calls (I was told) failing because of ATIS-1000074 4xx reason codes in REASON headers (and I agree, implementation specific).  But that is a distraction not worth rehashing on any level and I’m sorry I elaborated on it.  I am in favor of this I-D and the protocol approach it defines.
>  
> The main point I wanted to emphasize is that it is misleading to say “the authentication service will receive a SIP 4xx status code in the backwards direction”.
>  
> How about instead, “the network which authenticated the call will receive a SIP 4xx status code in the backwards direction”?
>  
> Best regards,
>  
> Pierce
>  
> From: Chris Wendt <[e-mail]> 
> Sent: Thursday, September 15, 2022 2:45 PM
> To: [e-mail]
> Cc: Robert Sparks <[e-mail]>; Ben Campbell <[e-mail]>; IETF STIR Mail List <[e-mail]>; STIR Chairs <[e-mail]>
> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>  
> Hi Pierce,
>  
> I sympathize with your concern and why you bring it up, but what service providers strip and don’t strip is not necessarily a problem for this document in IETF. If there is concern about SIP UAC/UAS receiving/using Reason headers more generally that we can’t use Reason headers as a tool in IETF specifications, than isn’t that something that needs to be addressed in higher level documents?  (I don’t believe its a problem)  Isn’t it already defined in ATIS-1000074? Wasn’t there just a big discussion about specifically adding a Reason header to 603 in IPNNI that got a lot of support by major US service providers (hopefully they aren’t stripping Reason headers for that use-case)?  I think if Reason headers are being dropped/ignored by implementations, that is an implementation issue, not a spec issue.
>  
> I think most of your issues discuss 8224 and FCC mandates etc, however, I’m not completely following your logic relative to this document. Just to repeat, we added the Reason header alternative, because we didn’t want to send error codes back and end the call, but we wanted to signal (if the originating provider wants to know) that there was a verification error.  This is the point of this draft to have the mechanism defined on IETF side and give it the formal support for multiple errors if they happen.  I don’t think this is a mandated functionality, i think it is optional, if the service provider wants to strip Reason Headers and doesn’t want to know when there is verification errors, they are free to do it.  But i also don’t think we should go back to sending the 4xx and killing the call either.  I think the decision to block should be in CVT logic using verification result and other information (like analytics or DNO or other info).
>  
> As to where in the network you implement any of the 8224 or 1000074 functionality, this is all implementation decisions.  AS/VS are logical functions that some have implemented in a single box, some have implemented between a SIP box and an HTTP service, there is probably a number of other variations, but they all need to conform to the specs as an overall solution.  We don’t change the specs because people didn't implement things or decided to strip headers they don’t like.
>  
> -Chris
> 
> 
>> On Aug 26, 2022, at 1:12 PM, [e-mail] <mailto:[e-mail]> wrote:
>>  
>> Hi Chris,
>>  
>> My concern with the “sent to the authentication service” language is a nit.  Keeping or eliminating the language doesn’t change the protocol work in the draft.  That said, I’m going to reinforce what I’ve been saying on this assumption of an AS seeing VS errrors.
>>  
>> Couple of things on the RFC 8224 definition of authentication service.
>>  
>>    o  Authentication Service: A logical role played by a SIP entity that
>>       adds Identity headers to SIP requests.
>>  
>> I assume “SIP entity” implies a SIP UAC/UAS element.
>>  
>> Something worth noting here is an Authentication Service acts as a UAC.  In practice the UAS of most Authentication Service implementations will not see a REASON header coming back from the UAC of a Verification Service.
>>  
>> Section 6.1 says, “It is also possible that the authentication service role might be instantiated by an entity that acts as a redirect server, but that is left as a topic for future work.”
>>  
>> Everything before “, but that is left as a topic for future work“ is technically correct and worth noting because it casually notes what I assert is the dominant form of Authentication Service implementations.  This has material consequences.
>>  
>> Section 6.1.1 makes a mistake when it says:
>>  
>> 6.1.1 <https://www.rfc-editor.org/rfc/rfc8224.html#section-6.1.1>.  Handling Repairable Errors
>>  
>>    Also, in some cases, a request signed by an authentication service
>>    will be rejected by the verification service on the receiving side,
>>    and the authentication service will receive a SIP 4xx status code in
>>    the backwards direction, such as a 438 ("Invalid Identity Header")
>>    response indicating a verification failure.
>>  
>> The part I highlighted in yellow is at least frequently incorrect.
>>  
>> Calls will routinely fail because of REASON headers with SIP 403, 436, 437, and 438 errors which the Authentication Service never receives, but which are received by UAs in the network which then kill otherwise valid calls because their SIP stacks have not been updated to recognize those codes but which do, however, recognize those are 4xx codes and therefore kill the calls because their SIP stacks do support RFC 3326 which suggests those calls can be killed because they have REASON to believe are unlikely to complete by reason of the 4xx category.
>>  
>> FCC mandates now require nearly all US voice service providers to authenticate calls by June 2023.  Given that the great majority of the 3,500 to 4,500 (or whatever the number is) US service providers will not directly implement authentication services on their network, the highlighted part is misleading and will (continue to) cause SIP call processing failures on calls that should otherwise complete regardless of the state of verification.
>>  
>> When “good” calls fail because of Verification Service 4xx errors in REASON headers, network operators are likely to do two things.
>>  
>> First, they will strip the offending REASON headers on inbound calls so that normal call processing can continue to complete as before.  The Sprint network did this.
>>  
>> Secondly, they will (if they’re diligent) investigate getting software updates on the vulnerable UAs so that the UAs know they should ignore those particular REASON headers (unless the UA is an Authentication Service).  Given those UAs can include originating mobile devices and IP PBXs, as well as VoIP-capable softswitches and CSCFs in the network, it is not a trivial second step.
>>  
>> The problem I’m complaining about (which is assuming an AS is receiving VS 4xx errors and acting on them) is serious enough I almost think it warrants its own discussion point in the I-D.
>>  
>> Service providers implementing STIR/SHAKEN need to be looking for those VS 4xx errors, but they most likely need to be looking for them on their Session Border Controller where they will most likely need to be stripping the ATIS-1000074 VS REASON headers unless they’ve update the SIP stacks on all of their, and their subscribers’, SIP “entities” to recognize those particular errors and handle them appropriately.
>>  
>> The main reason I am heartily in favor of this I-D is because adding “STIR” as a protocol in the REASON header should help all those existing UAs that currently support “SIP” and “Q.850” protocols to safely ignore Verification Service failure codes which are almost certainly meaningless to them.
>>  
>> Best regards,
>>  
>> Pierce
>>  
>>  
>> From: Chris Wendt <[e-mail] <mailto:[e-mail]>> 
>> Sent: Friday, August 26, 2022 6:35 AM
>> To: [e-mail] <mailto:[e-mail]>
>> Cc: Christer Holmberg <christer.holmberg=[e-mail] <mailto:christer.holmberg=[e-mail]>>; Robert Sparks <[e-mail] <mailto:[e-mail]>>; Ben Campbell <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>>  
>> Hi Pierce,
>>  
>> I think in the context of this specification, we really need to view authentication service as the RFC8224 defined authentication service.  Beyond that is industry and implementation specific.  Recall that ATIS-1000074 has same Reason header requirements, so I would claim that current implementations ignored this if they can’t support this functionality as a split SIP/HTTP based “authentication service” implementation as you are defining it.
>>  
>> -Chris
>> 
>> 
>> 
>>> On Aug 25, 2022, at 11:25 AM, [e-mail] <mailto:[e-mail]> wrote:
>>>  
>>> The text "in the next provisional or final responses sent to the authentication service" assumes the STI-AS will receive those responses and can do something with them. E.g., include them in a log.
>>>  
>>> This is not a good assumption.  Many (most?) AS/VS designs use an outboard server which is called using SIP INVITE or HTTPS and which responds using SIP 302 or HTTPS.  In both of those cases an AS may never see responses from verification services.
>>>  
>>> I recommend removing the language “sent to the authentication service” as being unnecessary and potentially misleading.
>>>  
>>> Pierce
>>>  
>>>  
>>> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Christer Holmberg
>>> Sent: Thursday, August 25, 2022 9:41 AM
>>> To: Robert Sparks <[e-mail] <mailto:[e-mail]>>; Ben Campbell <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
>>> Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>>>  
>>> Hi,
>>>  
>>> Yes, I meant Reasonse+STIR. It also seems I forgot the background information for my question in my previous e-mail. Sorry for that.
>>>  
>>> RFC 3326 says:
>>>  
>>>    "Initially, the Reason header field defined here appears to be most
>>>    useful for BYE and CANCEL requests, but it can appear in any request
>>>    within a dialog, in any CANCEL request and in any response whose
>>>    status code explicitly allows the presence of this header field."
>>>  
>>> So, my reading it needs to be explicitly indicated for which SIP response status codes Reason can be included.
>>>  
>>> For example, RFC 6432, which defines the Reason Q.850 protocol says:
>>>  
>>> "This document allows SIP responses to carry Reason header fields as
>>>    follows:
>>>  
>>>       Any SIP Response message, with the exception of a 100 (Trying),
>>>       MAY contain a Reason header field with a Q.850 [Q.850] cause code."
>>>  
>>> Regards,
>>>  
>>> Christer
>>>  
>>>  
>>>  
>>>  
>>> -----Original Message-----
>>> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Robert Sparks
>>> Sent: torstai 25. elokuuta 2022 17.21
>>> To: Christer Holmberg <[e-mail] <mailto:[e-mail]>>; Ben Campbell <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
>>> Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>>>  
>>> (Assuming you meant Reason+STIR below, and wearing no hats):
>>>  
>>> It isn't clear to me that there's a need to say anything more here than what RFC3326 says. Perhaps the text can be clear that this uses the rules for where the header can occur as RFC3326. I don't think we want something _different_, and I don't want to try to restate those rules in this document.
>>>  
>>> RjS
>>>  
>>>  
>>> On 8/25/22 9:05 AM, Christer Holmberg wrote:
>>> > Hi,
>>> > 
>>> > When the STIR protocol is used, in which SIP response codes can the Reason header(s) be included?
>>> > 
>>> > I can only find the following statement: "in the next provisional or final responses sent to the authentication service.".
>>> > 
>>> > That is not every explicit. If we want to allow Reason+SIP with *any* SIP response code it would be good to say so.
>>> > 
>>> > Regards,
>>> > 
>>> > Christer
>>> > 
>>> > -----Original Message-----
>>> > From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Ben Campbell
>>> > Sent: maanantai 22. elokuuta 2022 2.50
>>> > To: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
>>> > Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
>>> > Subject: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>>> > 
>>> > Hi,
>>> > 
>>> > This starts a STIR working group last call for draft-ietf-stir-identity-header-errors-handling-03. Please send feedback tot he authors and the STIR list by September 7. Note that we added a couple of days to the WGLC period due to the US Labor Day holiday.      
>>> > 
>>> > As always,any constructive feedback, including feedback to the effect of “I’ve read this and it is ready to go” is helpful.
>>> > 
>>> > Thanks!
>>> > 
>>> > Ben (For the STIR chairs)
>>> > 
>>> > 
>>> >> On Aug 19, 2022, at 11:10 AM, [e-mail] <mailto:[e-mail]> wrote:
>>> >> 
>>> >> 
>>> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> >> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.
>>> >> 
>>> >>         Title           : Identity Header Errors Handling
>>> >>         Author          : Chris Wendt
>>> >>   Filename        : draft-ietf-stir-identity-header-errors-handling-03.txt
>>> >>   Pages           : 7
>>> >>   Date            : 2022-08-19
>>> >> 
>>> >> Abstract:
>>> >>    This document extends STIR and the Authenticated Identity Management
>>> >>    in the Session Initiation Protocol (SIP) error handling procedures to
>>> >>    include the mapping of verification failure reasons to STIR defined
>>> >>    4xx codes so the failure reason of an Identity header field can be
>>> >>    conveyed to the upstream authentication service when local policy
>>> >>    dictates that the call should continue in the presence of a
>>> >>    verification failure.  This document also defines procedures that
>>> >>    enable enable a failure reason to be mapped to a specific Identity
>>> >>    header for scenarios that use multiple Identity header fields where
>>> >>    some may have errors and others may not and the handling of those
>>> >>    situations is defined.
>>> >> 
>>> >> 
>>> >> The IETF datatracker status page for this draft is:
>>> >> https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/ <https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/>
>>> >> 
>>> >> There is also an htmlized version available at:
>>> >> https://datatracker.ietf.org/doc/html/draft-ietf-stir-identity-header-errors-handling-03 <https://datatracker.ietf.org/doc/html/draft-ietf-stir-identity-header-errors-handling-03>
>>> >> 
>>> >> A diff from the previous version is available at:
>>> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-identity-header-errors-handling-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-identity-header-errors-handling-03>
>>> >> 
>>> >> 
>>> >> Internet-Drafts are also available by rsync at rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
>>> >> 
>>> >> 
>>> >> _______________________________________________
>>> >> stir mailing list
>>> >> [e-mail] <mailto:[e-mail]>
>>> >> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>>> > _______________________________________________
>>> > stir mailing list
>>> > [e-mail] <mailto:[e-mail]>
>>> > https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>>>  
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>