Re: [stir] Interop related topics for STIR

Agree with Jon and Christer's comments, 1 we all agree on as discussed in meeting, but 2-3 and 5 are news to me, 2 is an important part of replay attack, could it be done in other ways, perhaps, but i think it’s a little late for that conversation at this point.  In US at least, there is a highly significant percentage of calls being signed as we speak, particularly after the June 30 deadline and these issues haven’t surfaced in IPNNI discussions, interop forums and real-world usage to my knowledge and i’ve been paying pretty close attention to this :)

-Chris

> On Jul 13, 2021, at 4:03 PM, Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi,
>  
> Regarding 4), I agree with Jon. As I’ve said before, a SIP message can exceed 1300 bytes even without STIR. If the usage of TCP for SIP needs to be better explained, that belongs to 3261 (or, perhaps a generic TCP-for-SIP draft).
>  
> Regards,
>  
> Christer
>  
> From: stir <stir-bounces@ietf.org> On Behalf Of Peterson, Jon
> Sent: tiistai 13. heinäkuuta 2021 22.35
> To: Russ Housley <housley@vigilsec.com>; Roman Shpount <roman@telurix.com>
> Cc: IETF STIR Mail List <stir@ietf.org>
> Subject: Re: [stir] Interop related topics for STIR
>  
>  
> I think 1 needs to be fixed as an errata; it’s an actual bug in the current spec.  From my perspective, 2 and 3 are more “it would be nice” sorts of issues that we’d explore if we had some more substantial motivations to do an rfc8224bis – I don’t think they are worth doing a bis for on their own merits, especially not given the current state of deployment. 4 is not really a STIR issue, just a 20-year-old SIP issue that STIR is the latest thing to exacerbate. And as for 5, I’m not sure what the issue is… elaborate?
>  
> Jon Peterson
> Neustar, Inc.
>  
> From: stir <stir-bounces@ietf.org <mailto:stir-bounces@ietf.org>> on behalf of Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>
> Date: Tuesday, July 13, 2021 at 11:57 AM
> To: Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>>
> Cc: IETF STIR Mail List <stir@ietf.org <mailto:stir@ietf.org>>
> Subject: Re: [stir] Interop related topics for STIR
>  
> Roman:
>  
> Assuming that others agree with the way forward, it seems that 1-3 are the start of 8224bis, and it seems that 4 might be a new Operational Considerations in 8224bis.
>  
> Again, assuming agreement on the way forward, 8226bis should reflect real implementation.  That said, 8226 also envisions finer granularity than we have seen so far.
>  
> I think a STIR Torture Test document would be very valuable.
>  
> Russ
>  
>  
> 
> On Jul 13, 2021, at 2:41 PM, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> wrote:
>  
> I am moving this into a new thread.
>  
> So far the following RFC8224 issues were identified:
>  
> 1. Errata regarding quotes in ppt value (Errata ID: 6519). Need to verify that both ppt values with and without quotes are supported when Identity header is received
>  
> 2. Date header is required. It should probably be optional since the information there is redundant when the Full-Form PASSportT is used. Several known implementations omit it.
>  
> 3. Should it be possible to omit ident-info and ident-info-params when the Full-Form PASSportT is used? All implementations I have seen include it, but there are occasional mismatches.
>  
> 4. When SIP message is over 1300 bytes, the request MUST be sent using a congestion-controlled transport protocol such as TCP (https://datatracker.ietf.org/doc/html/rfc3261#section-18.1.1 <https://protect2.fireeye.com/v1/url?k=903fe637-cfa4ded5-903fa6ac-86073b36ea28-33d90488cafd9ba9&q=1&e=0b2e7635-bc78-4316-8051-c8abb27c2107&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3261%2Asection-18.1.1__%3BIw%21%21N14HnBHF%21oAy6J5s7jZgI4_5_yZuq0vQqaQNof-Hm5As08cXc4f_4q6Ey-LKdpEIAy_v4cJVm6QTc4w%24>). Considering that the Identity header is typically around 1000 bytes, this requires all networks to start using reliable protocols which is not currently the case. There is a way to work around this for the private links where MTU is under vendor control, but for links over the public internet, this needs to be clearly stated and tested.
>  
> 5. I do not think RFC8226 reflects the actual practices for STIR certificates.
>  
> We should also consider an informational document with STIR Torture test messages as well as BCP.
> _____________
> Roman Shpount
>  
>  
> On Tue, Jul 13, 2021 at 1:57 PM Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> I think that a SIPIT would be a very good thing, but that is not and IRTF activity.  That said, I would be very happy to use this list to know about a SIPIT once it is organized.
> Are there other interoperability or ops-orient topics about STIR that needed to be discussed?  If so, please start a thread.
>  
>  
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir