Subject: [stir] DRAFT Agenda for STIR ay IETF 111

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jul 2021 20:09:29 -0400

Please send comments to the mail list.

Russ

= = = = = = 

STIR Working Group at Virtual IETF 111

1) Administrivia
   - Agenda Bashing
   - Minute Taker
   - Jabber Scribe
   - Bluesheets

2) PASSporT Extension for Rich Call Data
   - Chris Wendt and Jon Peterson
   - draft-ietf-stir-passport-rcd
   - Resolve open issues from WG Last Call

3) Secure Reporting of Update Status
   - Jon Peterson
   - draft-ietf-stir-servprovider-oob
   - Prepare for WG Last Call

4) Messaging Use Cases and Extensions for STIR
   - Jon Peterson and Chris Wendt
   - draft-ietf-stir-messaging
   - Recently adopted; progress toward WG Last Call

5) Connected Identity for STIR
   - Jon Peterson and Chris Wendt
   - draft-peterson-stir-rfc4916-update
   - Discuss open issues; get ready for WG call for adoption

6) Identity Header Error Handling
   - Chris Wendt
   - draft-wendt-stir-identity-header-errors-handling
   - Discuss open issues; get ready for WG call for adoption	

7) Any Other Business (if time permits)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Jul 2021 22:01:33 -0400

Can anyone talk about the current interop and implementation status for
STIR?
There was some discussion before about organizing a new SIPIT event that
would be focused on STIR interop. Can we discuss the status of that during
the meeting?

Thank you,
_____________
Roman Shpount

On Mon, Jul 12, 2021 at 8:10 PM Russ Housley <[email-masked]> wrote:

> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jul 2021 13:56:57 -0400

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.

Russ

> On Jul 12, 2021, at 10:01 PM, Roman Shpount <[email-masked]> wrote:
> 
> Can anyone talk about the current interop and implementation status for STIR?
> There was some discussion before about organizing a new SIPIT event that would be focused on STIR interop. Can we discuss the status of that during the meeting?
> 
> Thank you,
> _____________
> Roman Shpount
> 
> 
> On Mon, Jul 12, 2021 at 8:10 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 13 Jul 2021 14:25:36 -0400

A new SIPIT has been under active discussion for some time with a emphasis on RCD interoperability. STIR is of course a legal requirement in the US and Canada and may be mandated in the UK and France later this year.

We’re talking about a lot of that next week.

https://www.sipforum.org/2021-stir-shaken-virtual-summit/schedule/

At some point there needs to be a STIR/SHAKEN BCP. There are issues that keep coming up.  Obviously the TCP fragmentation issues. Not all network elements perform canonicalization consistently – this can result in improperly signed calls that do not get verified correctly.

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Tuesday, July 13, 2021 at 1:56 PM
To: Roman Shpount <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] DRAFT Agenda for STIR ay IETF 111

Russ

Thank you,
_____________
Roman Shpount

Russ

= = = = = = 

1) Administrivia
   - Agenda Bashing
   - Minute Taker
   - Jabber Scribe
   - Bluesheets

_______________________________________________ stir mailing list [email-masked] https://www.ietf.org/mailman/listinfo/stir

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 14:41:09 -0400

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). 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 <[email-masked]> 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.
>
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jul 2021 14:57:16 -0400

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 <[email-masked]> wrote:
> 
> 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://datatracker.ietf.org/doc/html/rfc3261#section-18.1.1>). 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 <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Jul 2021 19:34:34 +0000

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 <[email-masked]> on behalf of Russ Housley <[email-masked]>
Date: Tuesday, July 13, 2021 at 11:57 AM
To: Roman Shpount <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Interop related topics for STIR

Roman:

Russ

On Jul 13, 2021, at 2:41 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

4. When SIP message is over 1300 bytes, the request MUST be sent using a congestion-controlled transport protocol such as TCP (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc3261*section-18.1.1__;Iw!!N14HnBHF!tV4SsYwrzg8SiWaONgDCbi9U_paK408AbdaBupJMXjx-FxLuoOcdqqJRQl4$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3261*section-18.1.1__;Iw!!N14HnBHF!oAy6J5s7jZgI4_5_yZuq0vQqaQNof-Hm5As08cXc4f_4q6Ey-LKdpEIAy_v4cJVm6QTc4w$>). 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.

On Tue, Jul 13, 2021 at 1:57 PM Russ Housley <[email-masked]<mailto:[email-masked]>> 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.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Jul 2021 20:03:00 +0000

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 <[email-masked]> On Behalf Of Peterson, Jon
Sent: tiistai 13. heinäkuuta 2021 22.35
To: Russ Housley <[email-masked]>; Roman Shpount <[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Interop related topics for STIR

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]<mailto:[email-masked]>> on behalf of Russ Housley <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 13, 2021 at 11:57 AM
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Interop related topics for STIR

Roman:

Russ

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.

---

From: Chris Wendt <[email-masked]>
Date: Tue, 13 Jul 2021 16:28:57 -0400

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=[email-masked]> wrote:
> 
> Hi,
>  
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Russ Housley <[email-masked] <mailto:[email-masked]>>
> To: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> Cc: IETF STIR Mail List <[email-masked] <mailto:[email-masked]>>
> On Jul 13, 2021, at 2:41 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 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.
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 13 Jul 2021 17:16:44 -0400

> On Jul 13, 2021, at 4:28 PM, Chris Wendt <[email-masked]> wrote:
> 
> Agree with Jon and Christer's comments, 1 we all agree on as discussed in meeting

If that is the case, can we wrap up the errata.

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 13 Jul 2021 21:23:05 +0000

It would be beneficial to address number 3. It provides no value when full form PASSporTs are used. It makes the Identity header bigger. It also makes the generation of the Identity header more complicated when converting a call from TDM to SIP and using OOB or Extending SHAKEN over TDM (the two ATIS standards for TDM calls). I think all Identity header parameters should be optional if the PASSporT is in full form.

Sincerely,

Alec Fenichel

Senior Software Architect

[email-masked]

+1 (407) 760-0036

TransNexus

From: stir <[email-masked]> on behalf of Chris Wendt <[email-masked]>
Date: Tuesday, July 13, 2021 at 16:32
To: Christer Holmberg <christer.holmberg=[email-masked]>
Cc: IETF STIR Mail List <[email-masked]>, Peterson, Jon <jon.peterson=[email-masked]>, Russ Housley <[email-masked]>, Roman Shpount <[email-masked]>
Subject: Re: [stir] Interop related topics for STIR

-Chris

Hi,

Regards,

Christer

Jon Peterson

Neustar, Inc.

Roman:

Russ

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

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 17:46:45 -0400

Regarding 2 (SIP Message Date header), since the signature date is
already present in the Full-Form Passport, the additional Date header on
the actual message is completely redundant. Also, the Date header can be
modified or removed by equipment down the line from the SIP signer, so the
SIP message can be verified even if the Date header is not present. I
cannot claim that I've participated in every interop event, but this issue
has caused problems with OpenSIPS, Kamailio, Asterisk, and Ribbon SBC
(which affected most of the large US LD carriers). A lot of singed calls do
not currently insert the Date header even though it is required.
_____________
Roman Shpount

On Tue, Jul 13, 2021 at 4:29 PM Chris Wendt <[email-masked]>
wrote:

> 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=[email-masked]> 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 <[email-masked]> *On Behalf Of *Peterson, Jon
> *Sent:* tiistai 13. heinäkuuta 2021 22.35
> *To:* Russ Housley <[email-masked]>; Roman Shpount <
> [email-masked]>
> *Cc:* IETF STIR Mail List <[email-masked]>
> *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 <[email-masked]> on behalf of Russ Housley <
> [email-masked]>
> *Date: *Tuesday, July 13, 2021 at 11:57 AM
> *To: *Roman Shpount <[email-masked]>
> *Cc: *IETF STIR Mail List <[email-masked]>
> *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.
>
> 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.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 13 Jul 2021 22:41:52 +0000

The stuff in full form PASSporTs is also redundant with the To, the From and/or PAID, and I gather a bunch of 3GPP headers. Full form was designed to be redundant with things that appear elsewhere in a SIP request. If we want to explore how to save twenty or thirty octets in SIP messages when STIR is involved, I think there are a number of potential ways to try to achieve that. I’m not sure how pressing that is, though.

Moreover, as there are about a zillion calls being signed per day now, I think we need to be cautious about jettisoning things that RFC822X told implementors to expect to be there. It’s one thing if we gave confusing guidance (per issue 1) and another thing if the guidance was clear but some people aren’t doing it. We can make significant changes in the long term, but I expect we’ll be more motivated by either fixing things that don’t work as written or enabling new things we want to do that we can’t enable without surgery – even if it would potentially break existing implementations. The bar for that is fairly high, I think.

Jon Peterson
Neustar, Inc.

From: Roman Shpount <[email-masked]>
Date: Tuesday, July 13, 2021 at 2:48 PM
To: Chris Wendt <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, "Peterson, Jon" <[email-masked]>, Russ Housley <[email-masked]>, IETF STIR Mail List <[email-masked]>
Subject: Re: [stir] Interop related topics for STIR

Regarding 2 (SIP Message Date header), since the signature date is already present in the Full-Form Passport, the additional Date header on the actual message is completely redundant. Also, the Date header can be modified or removed by equipment down the line from the SIP signer, so the SIP message can be verified even if the Date header is not present. I cannot claim that I've participated in every interop event, but this issue has caused problems with OpenSIPS, Kamailio, Asterisk, and Ribbon SBC (which affected most of the large US LD carriers). A lot of singed calls do not currently insert the Date header even though it is required.
_____________
Roman Shpount

On Tue, Jul 13, 2021 at 4:29 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
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=[email-masked]<mailto:christer.holmberg=[email-masked]>> wrote:

Hi,

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Peterson, Jon
Sent: tiistai 13. heinäkuuta 2021 22.35
To: Russ Housley <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: IETF STIR Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] Interop related topics for STIR

Jon Peterson
Neustar, Inc.

Roman:

Russ

4. When SIP message is over 1300 bytes, the request MUST be sent using a congestion-controlled transport protocol such as TCP (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc3261*section-18.1.1__;Iw!!N14HnBHF!s3wkdF-CPSzQ5Dj_xE-bIU-BYRIo1_DTm68Zwtemz11lc175-u2pEnXxEk8$ <https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJQ!!N14HnBHF!szFDEdAqnJ7qCB8YhW3a3ZVGX1xptKX3SY7GNVMOnf3QlLaIDopLVaOvAWw0z6i1ocGhzQ$>). 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.

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!s3wkdF-CPSzQ5Dj_xE-bIU-BYRIo1_DTm68Zwtemz11lc175-u2p3-U0qYA$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!szFDEdAqnJ7qCB8YhW3a3ZVGX1xptKX3SY7GNVMOnf3QlLaIDopLVaOvAWw0z6iFMXB1vQ$>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Jul 2021 00:04:51 -0400

Jon,

All I am saying is that according to the current specification the Date
header must be included by the signer but it is optional when the message
is verified. You are not going to break anything if you say that the Date
header is optional for the signer. This is not about saving a few bytes. It
is about decreasing the test area.

Another thing to consider is how many of the calls signed today do not have
the Date header? I have done several interops with carriers and I did not
see a Date header in any of the calls. All I want is for the specification
to reflect the actual usage.
_____________
Roman Shpount

On Tue, Jul 13, 2021 at 6:41 PM Peterson, Jon <[email-masked]>
wrote:

>
>
> The stuff in full form PASSporTs is also redundant with the To, the From
> and/or PAID, and I gather a bunch of 3GPP headers. Full form was designed
> to be redundant with things that appear elsewhere in a SIP request. If we
> want to explore how to save twenty or thirty octets in SIP messages when
> STIR is involved, I think there are a number of potential ways to try to
> achieve that. I’m not sure how pressing that is, though.
>
>
>
> Moreover, as there are about a zillion calls being signed per day now, I
> think we need to be cautious about jettisoning things that RFC822X told
> implementors to expect to be there. It’s one thing if we gave confusing
> guidance (per issue 1) and another thing if the guidance was clear but some
> people aren’t doing it. We can make significant changes in the long term,
> but I expect we’ll be more motivated by either fixing things that don’t
> work as written or enabling new things we want to do that we can’t enable
> without surgery – even if it would potentially break existing
> implementations. The bar for that is fairly high, I think.
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Tuesday, July 13, 2021 at 2:48 PM
> *To: *Chris Wendt <[email-masked]>
> *Cc: *Christer Holmberg <[email-masked]>, "Peterson, Jon"
> <[email-masked]>, Russ Housley <[email-masked]>, IETF
> STIR Mail List <[email-masked]>
> <https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJQ!!N14HnBHF!szFDEdAqnJ7qCB8YhW3a3ZVGX1xptKX3SY7GNVMOnf3QlLaIDopLVaOvAWw0z6i1ocGhzQ$>).
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!N14HnBHF!szFDEdAqnJ7qCB8YhW3a3ZVGX1xptKX3SY7GNVMOnf3QlLaIDopLVaOvAWw0z6iFMXB1vQ$>
>
>
>
>