Subject: [stir] For the sake of implementers, please verify errata in a timely manner

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 8 Apr 2021 05:49:56 -0700

As an implementer, each non verified errata is more work because now I have to weight the validity of these unverified errata, make a decision, remember that decision and hope that it will not be overturned later (obviously I am talking about technical errata here).

RFC 8224 has already 5 erratum, all unverified.  In an effort to help get them to be verified, here are my personal implementation decisions on them:

1. https://www.rfc-editor.org/errata/eid5390

Valid.

2. https://www.rfc-editor.org/errata/eid5391

I disagree with this errata, i.e. the iat must be built from the Date header when available.  But another errata should clearly indicate that RFC 8224 overrides the text in RFC 7518 section 4.1.6.

3. https://www.rfc-editor.org/errata/eid5715

Valid

4. https://www.rfc-editor.org/errata/eid6499

My own errata, so I consider it valid, but I would suggest to also amend the first sentence of the second paragraph after the ABNF like this:

"The signed-identity-digest contains a PASSporT encoded as specified in [RFC8225], [...]"

5. https://www.rfc-editor.org/errata/eid6499

I disagree with that -- wrong examples, especially from another SDO, should not change normative text.   In itself adding quotes around a token is puzzling.  An additional unintended consequence is that quoted strings are case-sensitive, whereas tokens are case insensitive, so that may create an additional interop issue.

For these reason my implementation decision is to ignore that errata until it is verified.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Apr 2021 01:31:03 -0400

On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <[email-masked]>
wrote:

> I disagree with that -- wrong examples, especially from another SDO,
> should not change normative text.   In itself adding quotes around a token
> is puzzling.  An additional unintended consequence is that quoted strings
> are case-sensitive, whereas tokens are case insensitive, so that may create
> an additional interop issue.
>

I actually agree with you that the ppt value token should not be quoted.
The reason I posted this as an errata was that there was a decision was
made during IETF 101 that quotes around ppt values are mandatory (
https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/). I
am also dealing with implementations that quote the value, and I need to be
absolutely sure this is incorrect when dealing with them.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Apr 2021 13:42:34 +0000

Hi,

Since the errata implements a decision that the WG has made, I don’t think it is appropriate to reject it just because one does not agree with the decision.

The WG can of course make a new decision.

Regards,

Christer

From: stir <[email-masked]> On Behalf Of Roman Shpount
Sent: perjantai 9. huhtikuuta 2021 8.31
To: Marc Petit-Huguenin <[email-masked]>
Cc: [email-masked] Mail List <[email-masked]>
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>> wrote:
5. https://www.rfc-editor.org/errata/eid6499<https://protect2.fireeye.com/v1/url?k=ef89db14-b012e23f-ef899b8f-866038973a15-fdf914a9f542a726&q=1&e=8813711f-31d5-4b19-9e71-65401444b97d&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6499>

I actually agree with you that the ppt value token should not be quoted. The reason I posted this as an errata was that there was a decision was made during IETF 101 that quotes around ppt values are mandatory (https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/). I am also dealing with implementations that quote the value, and I need to be absolutely sure this is incorrect when dealing with them.
_____________
Roman Shpount

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 9 Apr 2021 06:49:17 -0700

Hi,

> Since the errata implements a decision that the WG has made, I don’t think it is appropriate to reject it just because one does not agree with the decision.

You misread:  This is a decision I made for my code, and my code only, until the erratum is verified.  Then I'll follow the consensus.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 9 Apr 2021 13:19:26 -0400

Chirster,

For the record, RFC 8224 was published in February 2018. IETF 101 was in
March 2018. The decision was about misreading an already published RFC and
using ppt value in quotes in examples in other RFC. There is nothing in RFC
8224 that says that ppt= value should be quoted.

This makes me think errata should be filed against other documents to fix
examples.

Best Regards,
_____________
Roman Shpount

On Fri, Apr 9, 2021 at 9:42 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> Since the errata implements a decision that the WG has made, I don’t think
> it is appropriate to reject it just because one does not agree with the
> decision.
>
>
>
> *From:* stir <[email-masked]> *On Behalf Of *Roman Shpount
> *Sent:* perjantai 9. huhtikuuta 2021 8.31
> *To:* Marc Petit-Huguenin <[email-masked]>
> *Cc:* [email-masked] Mail List <[email-masked]>
> *Subject:* Re: [stir] For the sake of implementers, please verify errata
> in a timely manner
>
>
>
> On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <
> [email-masked]> wrote:
>
> <https://protect2.fireeye.com/v1/url?k=ef89db14-b012e23f-ef899b8f-866038973a15-fdf914a9f542a726&q=1&e=8813711f-31d5-4b19-9e71-65401444b97d&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6499>
>
> https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/).
> I am also dealing with implementations that quote the value, and I need to
> be absolutely sure this is incorrect when dealing with them.
>
> _____________
>
> Roman Shpount
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Apr 2021 17:23:00 +0000

Hi,

>For the record, RFC 8224 was published in February 2018. IETF 101 was in March 2018. The decision was about misreading an already published RFC and using ppt value in quotes in examples in other RFC. There is
>nothing in RFC 8224 that says that ppt= value should be quoted.

I agree.

>This makes me think errata should be filed against other documents to fix examples.

But that is not the decision that the WG took :)

Regards.

Christer

On Fri, Apr 9, 2021 at 9:42 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of Roman Shpount
Sent: perjantai 9. huhtikuuta 2021 8.31
To: Marc Petit-Huguenin <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

---

From: Chris Wendt <[email-masked]>
Date: Mon, 12 Apr 2021 15:45:42 -0400

Hi Roman,

I tried looking at the drafts/RFCs i was aware of and all of them had quoted ppt in examples.  Probably missed some, can you point to a published document that includes ppt as not quoted in examples?

Thanks.

-Chris

> On Apr 9, 2021, at 1:19 PM, Roman Shpount <[email-masked]> wrote:
> 
> Chirster,
> 
> For the record, RFC 8224 was published in February 2018. IETF 101 was in March 2018. The decision was about misreading an already published RFC and using ppt value in quotes in examples in other RFC. There is nothing in RFC 8224 that says that ppt= value should be quoted.
> 
> On Fri, Apr 9, 2021 at 9:42 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
>  
> 
> From: stir <[email-masked] <mailto:[email-masked]>> On Behalf Of Roman Shpount
> To: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> Mail List <[email-masked] <mailto:[email-masked]>>
> On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 5. https://www.rfc-editor.org/errata/eid6499 <https://protect2.fireeye.com/v1/url?k=ef89db14-b012e23f-ef899b8f-866038973a15-fdf914a9f542a726&q=1&e=8813711f-31d5-4b19-9e71-65401444b97d&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid6499>
> 
> I actually agree with you that the ppt value token should not be quoted. The reason I posted this as an errata was that there was a decision was made during IETF 101 that quotes around ppt values are mandatory (https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/ <https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/>). I am also dealing with implementations that quote the value, and I need to be absolutely sure this is incorrect when dealing with them.
> 
> _____________
> 
> Roman Shpount 
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 15:53:58 -0400

Chris,

As far as I am aware all RFCs and ATS examples have ppt quoted in examples.
At the same time, in https://tools.ietf.org/html/rfc8224#section-4

ident-type = "ppt" EQUAL token

This grammar does not allow for a quoted value. Considering that examples
are informational, I would argue RFC 8224 should take precedence.
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 3:45 PM Chris Wendt <[email-masked]>
wrote:

> Hi Roman,
>
> I tried looking at the drafts/RFCs i was aware of and all of them had
> quoted ppt in examples.  Probably missed some, can you point to a published
> document that includes ppt as not quoted in examples?
>
> Thanks.
>
> -Chris
>
>> Since the errata implements a decision that the WG has made, I don’t
>> think it is appropriate to reject it just because one does not agree with
>> the decision.
>>
>>
>>

---

From: Chris Wendt <[email-masked]>
Date: Mon, 12 Apr 2021 16:07:36 -0400

Ok, great, and before someone calls me out, the example in rcd-11 is not quoted :) but i’ve fixed that in local version, will fix on next version.

So, agreed RFC8224 is only thing that needs fixing, and I think Jon sent out note that he also agrees with errata fix for this.  

> On Apr 12, 2021, at 3:53 PM, Roman Shpount <[email-masked]> wrote:
> 
> Chris,
> 
> As far as I am aware all RFCs and ATS examples have ppt quoted in examples. At the same time, in https://tools.ietf.org/html/rfc8224#section-4 <https://tools.ietf.org/html/rfc8224#section-4>
> This grammar does not allow for a quoted value. Considering that examples are informational, I would argue RFC 8224 should take precedence.
> _____________
> Roman Shpount
> 
> 
> On Mon, Apr 12, 2021 at 3:45 PM Chris Wendt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Roman,
> 
>> On Apr 9, 2021, at 1:19 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Chirster,
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Alec Fenichel <[email-masked]>
Date: Mon, 12 Apr 2021 20:19:43 +0000

Chris,

Shouldn’t the example be changed to just not include ppt at all? It is an optional parameter that is only needed for compact form PASSporTs.

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: Monday, April 12, 2021 at 16:07
To: Roman Shpount <[email-masked]>
Cc: [email-masked] Mail List <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

Chris,

As far as I am aware all RFCs and ATS examples have ppt quoted in examples. At the same time, in https://tools.ietf.org/html/rfc8224#section-4

_____________
Roman Shpount

On Mon, Apr 12, 2021 at 3:45 PM Chris Wendt <[email-masked]> wrote:

Hi Roman,

Thanks.

-Chris

Chirster,

Best Regards,

_____________
Roman Shpount

On Fri, Apr 9, 2021 at 9:42 AM Christer Holmberg <[email-masked]> wrote:

Hi,

Regards,

Christer

On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <[email-masked]> wrote:

_____________

Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Apr 2021 20:29:31 +0000

Hi,

Unless not quoting would have a big impact on deployments, compared to quoting, I think the correct way is to change the examples.

As always, we hope that people implement the normative text – not the examples…

Regards,

Christer

From: Alec Fenichel <[email-masked]> 
Sent: maanantai 12. huhtikuuta 2021 23.20
To: Chris Wendt <[email-masked]>; Roman Shpount <[email-masked]>
Cc: [email-masked] Mail List <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; Christer Holmberg <[email-masked]>
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

Chris,

Sincerely,

Alec Fenichel

[email-masked] <mailto:[email-masked]> 

+1 (407) 760-0036

TransNexus

From: stir <[email-masked] <mailto:[email-masked]> > on behalf of Chris Wendt <[email-masked] <mailto:[email-masked]> >
Date: Monday, April 12, 2021 at 16:07
To: Roman Shpount <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  Mail List <[email-masked] <mailto:[email-masked]> >, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >, Christer Holmberg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

On Apr 12, 2021, at 3:53 PM, Roman Shpount <[email-masked] <mailto:[email-masked]> > wrote:

Chris,

_____________
Roman Shpount

On Mon, Apr 12, 2021 at 3:45 PM Chris Wendt <[email-masked] <mailto:[email-masked]> > wrote:

Hi Roman,

Thanks.

-Chris

On Apr 9, 2021, at 1:19 PM, Roman Shpount <[email-masked] <mailto:[email-masked]> > wrote:

Chirster,

Best Regards,

_____________
Roman Shpount

On Fri, Apr 9, 2021 at 9:42 AM Christer Holmberg <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

Regards,

Christer

From: stir <[email-masked] <mailto:[email-masked]> > On Behalf Of Roman Shpount
Sent: perjantai 9. huhtikuuta 2021 8.31
To: Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]>  Mail List <[email-masked] <mailto:[email-masked]> >
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

On Thu, Apr 8, 2021 at 8:50 AM Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]> > wrote:

_____________

Roman Shpount

---

From: Chris Wendt <[email-masked]>
Date: Mon, 12 Apr 2021 17:09:30 -0400

I think that’s slightly different question, historically i think maybe we included as convention just to potentially have something readable directly to indicate the type of PASSporT contained in Base64, but this is as you say optional, and implementations can’t necessarily rely on this, etc. etc.

So yes, we could leave it off, but like i said other examples we keep it on, and i believe as people tend to code to examples, most identity headers i recall seeing also contain “ppt” :)

> On Apr 12, 2021, at 4:19 PM, Alec Fenichel <[email-masked]> wrote:
> 
> Chris,
>  
> On Apr 12, 2021, at 3:53 PM, Roman Shpount <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Chris,
>  
> As far as I am aware all RFCs and ATS examples have ppt quoted in examples. At the same time, in https://tools.ietf.org/html/rfc8224#section-4 <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8224%23section-4&data=04%7C01%7Calec.fenichel%40transnexus.com%7Cc3ce1516bc694b129cd408d8fdeea848%7C8e2972a2d21d49acb00518e8ceaadee3%7C1%7C0%7C637538548777280771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AXf2UPzKbyDcaOctfF0gRP1iMtFicDoLVSopwTsoB8w%3D&reserved=0>
> 5. https://www.rfc-editor.org/errata/eid6499 <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Def89db14-b012e23f-ef899b8f-866038973a15-fdf914a9f542a726%26q%3D1%26e%3D8813711f-31d5-4b19-9e71-65401444b97d%26u%3Dhttps%253A%252F%252Fwww.rfc-editor.org%252Ferrata%252Feid6499&data=04%7C01%7Calec.fenichel%40transnexus.com%7Cc3ce1516bc694b129cd408d8fdeea848%7C8e2972a2d21d49acb00518e8ceaadee3%7C1%7C0%7C637538548777290767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2F%2BciniHt1piDh3WKBFBbNEgibPlAeGH%2Fmnbzn%2FJ3Yus%3D&reserved=0>
> 
> I actually agree with you that the ppt value token should not be quoted. The reason I posted this as an errata was that there was a decision was made during IETF 101 that quotes around ppt values are mandatory (https://mailarchive.ietf.org/arch/msg/stir/tI1dJUYPFiEvYIHBCmsBiVvQ0GE/ <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fstir%2FtI1dJUYPFiEvYIHBCmsBiVvQ0GE%2F&data=04%7C01%7Calec.fenichel%40transnexus.com%7Cc3ce1516bc694b129cd408d8fdeea848%7C8e2972a2d21d49acb00518e8ceaadee3%7C1%7C0%7C637538548777290767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FdqigXUAGjauXDnLj5d79L17I84kpDGcTpcnlc6JApQ%3D&reserved=0>). I am also dealing with implementations that quote the value, and I need to be absolutely sure this is incorrect when dealing with them.
> _____________
> Roman Shpount 
> https://www.ietf.org/mailman/listinfo/stir <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=04%7C01%7Calec.fenichel%40transnexus.com%7Cc3ce1516bc694b129cd408d8fdeea848%7C8e2972a2d21d49acb00518e8ceaadee3%7C1%7C0%7C637538548777300758%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XVdAGpoQaHssZXsEr4pa7H75sDaa6RuKpzDSx6zwTFc%3D&reserved=0>

---

From: Alec Fenichel <[email-masked]>
Date: Mon, 12 Apr 2021 21:39:39 +0000

I guess what I am trying to say is that I think we should remove ppt from the examples because as you say, people tend to code to examples and smaller Identity headers would be ideal.

I don’t mean to hijack this thread, but I have been meaning to bring this up anyways and it is related. Is there a reason I’m just overlooking for requiring the “info” parameter when a full-form PASSporT is used? If not, can we make it optional? The reason I ask is that with OOB, the transit provider receives a PASSporT out-of-band and then needs to construct an Identity header. Because of the “info” parameter requirement, the transit provider must decode the PASSporT in order to determine the “info” parameter. This is the only reason that a transit provider needs to decode the PASSporT. This isn’t difficult so it doesn’t really matter, but I figured I’d ask about potentially making the “info” parameter optional. Also, it makes the Identity header smaller which is always a good thing.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Chris Wendt <[email-masked]>
Date: Monday, April 12, 2021 at 17:09
To: Alec Fenichel <[email-masked]>
Cc: Roman Shpount <[email-masked]>, [email-masked] Mail List <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [stir] For the sake of implementers, please verify errata in a timely manner

Chris,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Chris,

_____________
Roman Shpount

Hi Roman,

Thanks.

-Chris

Chirster,

Best Regards,

_____________
Roman Shpount

Hi,

Regards,

Christer

_____________

Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 18:59:55 -0400

Alec,

I agree that we need to figure out a way to make Identity headers smaller.
As it stands right now, the Identity header with "shaken" PASSporT type
adds around 600 bytes to an INVITE message. This makes typical SIP INVITE
messages go from around 1K in size to 1.6K, which is bigger than the UDP
MTU. Going over UDP MTU causes SIP trunks to either switch to TCP (in
places where TCP was never used) or to experience sporadic call completion
problems (when a call goes over an Internet service providers that does not
deliver fragmented UDP messages). This is causing major breakage in SIP
VoIP networks right now as STIR/SHAKEN is getting deployed. It is a big
enough problem that we see a change in call completion statistics in the US.

I would argue that instead of making info parameter optional, we need to
make iat and attest claims SIP Identity header parameters and
recommend switching to compact Identity header form. We can move origid
into Session-ID header (RFC 7989). We should also make the Date header
optional since it is redundant when iat is present. This should save around
300 bytes per message which should make INVITE messages less than the UDP
MTU.

I know this is very late in the process, but I simply do not see how the
current implementation can be safely deployed in its current form.

Best Regards,
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel <[email-masked]>
wrote:

> I guess what I am trying to say is that I think we should remove ppt from
> the examples because as you say, people tend to code to examples and
> smaller Identity headers would be ideal.
>
>
>
> I don’t mean to hijack this thread, but I have been meaning to bring this
> up anyways and it is related. Is there a reason I’m just overlooking for
> requiring the “info” parameter when a full-form PASSporT is used? If not,
> can we make it optional? The reason I ask is that with OOB, the transit
> provider receives a PASSporT out-of-band and then needs to construct an
> Identity header. Because of the “info” parameter requirement, the transit
> provider must decode the PASSporT in order to determine the “info”
> parameter. This is the only reason that a transit provider needs to decode
> the PASSporT. This isn’t difficult so it doesn’t really matter, but I
> figured I’d ask about potentially making the “info” parameter optional.
> Also, it makes the Identity header smaller which is always a good thing.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>

---

From: Alec Fenichel <[email-masked]>
Date: Mon, 12 Apr 2021 23:53:39 +0000

Roman,

One of my concerns with switching to compact form is that every SIP device in the call path needs to support passing every single header used to convey signed information. If just a single header conveying signed information is lost or changed, then the PASSporT verification will fail. And every time you add a new header, the PASSporTs are unusable until every transit provider in the call path supports passing the new header.

Also, it doesn’t work for TDM calls. OOB can get the PASSporT across the TDM, but it isn’t intended to get all the SIP headers conveying signed information across TDM.

Finally, right now, we often include “rcd” “nam” claims in “shaken” PASSporTs. I don’t think you can include “rcd” information in a “shaken” PASSporT using compact form. The TSP doesn’t know that the display name was part of the PASSporT and would generate the wrong PASSporT causing the verification to fail. And you would lose the ability to use longer than 15 character “rcd” “nam” claims because putting more than 15 characters is the From/PAI display name often results in it getting truncated during transit. This would break verification as described above.

I think the Date header should be optional. I agree that we should stop duplicating information. But I think we should do this by only transmitting information in the PASSporT as opposed to only in SIP headers. I know using SIP headers would ultimately be smaller than PASSporTs, but I think it is too brittle.

Hence my comment, I think we should make “info”, “alg”, and “ppt” all optional and we should not use any of them in the examples to promote implementations not to use them. The exception being when the example shows compact form PASSporTs, obviously they need to be included.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Roman Shpount <[email-masked]>
Date: Monday, April 12, 2021 at 19:00
To: Alec Fenichel <[email-masked]>
Cc: Chris Wendt <[email-masked]>, [email-masked] Mail List <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Making STIR SIP messages smaller

Alec,

I agree that we need to figure out a way to make Identity headers smaller. As it stands right now, the Identity header with "shaken" PASSporT type adds around 600 bytes to an INVITE message. This makes typical SIP INVITE messages go from around 1K in size to 1.6K, which is bigger than the UDP MTU. Going over UDP MTU causes SIP trunks to either switch to TCP (in places where TCP was never used) or to experience sporadic call completion problems (when a call goes over an Internet service providers that does not deliver fragmented UDP messages). This is causing major breakage in SIP VoIP networks right now as STIR/SHAKEN is getting deployed. It is a big enough problem that we see a change in call completion statistics in the US.

I would argue that instead of making info parameter optional, we need to make iat and attest claims SIP Identity header parameters and recommend switching to compact Identity header form. We can move origid into Session-ID header (RFC 7989). We should also make the Date header optional since it is redundant when iat is present. This should save around 300 bytes per message which should make INVITE messages less than the UDP MTU.

I know this is very late in the process, but I simply do not see how the current implementation can be safely deployed in its current form.

Best Regards,

_____________
Roman Shpount

On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel <[email-masked]> wrote:

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 21:16:55 -0400

Alec,

I think the "info" header was required to identify the type of Identity
header so that, in the future, you can switch to something different from
JWT.

I understand the desire to pass a lot of information, including "nam" and
"rcd," when setting up the call. The problem is SIP over UDP was not
designed to pass the unlimited amount of information. A lot of current
deployments in the field support UDP only. If the INVITE message becomes
bigger than the UDP MTU, these deployments break. If you need to pass
additional data with the SIP call where you do not control the entire
network along the way, it should be passed out-of-band. In the perfect
world, we would be using SIPS right now, but this is not the case.

The other solution would be to switch everything to passing Identity OOB,
similar to PSTN, and only use the Identity header within a controlled
network where its delivery can be guaranteed despite the size.

As this solution stands right now, it is simply broken.
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 7:53 PM Alec Fenichel <[email-masked]>
wrote:

> Roman,
>
>
>
> One of my concerns with switching to compact form is that every SIP device
> in the call path needs to support passing every single header used to
> convey signed information. If just a single header conveying signed
> information is lost or changed, then the PASSporT verification will fail.
> And every time you add a new header, the PASSporTs are unusable until every
> transit provider in the call path supports passing the new header.
>
>
>
> Also, it doesn’t work for TDM calls. OOB can get the PASSporT across the
> TDM, but it isn’t intended to get all the SIP headers conveying signed
> information across TDM.
>
>
>
> Finally, right now, we often include “rcd” “nam” claims in “shaken”
> PASSporTs. I don’t think you can include “rcd” information in a “shaken”
> PASSporT using compact form. The TSP doesn’t know that the display name was
> part of the PASSporT and would generate the wrong PASSporT causing the
> verification to fail. And you would lose the ability to use longer than 15
> character “rcd” “nam” claims because putting more than 15 characters is the
> From/PAI display name often results in it getting truncated during transit.
> This would break verification as described above.
>
>
>
> I think the Date header should be optional. I agree that we should stop
> duplicating information. But I think we should do this by only transmitting
> information in the PASSporT as opposed to only in SIP headers. I know using
> SIP headers would ultimately be smaller than PASSporTs, but I think it is
> too brittle.
>
>
>
> Hence my comment, I think we should make “info”, “alg”, and “ppt” all
> optional and we should not use any of them in the examples to promote
> implementations not to use them. The exception being when the example shows
> compact form PASSporTs, obviously they need to be included.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Monday, April 12, 2021 at 19:00
> *To: *Alec Fenichel <[email-masked]>
> *Cc: *Chris Wendt <[email-masked]>, [email-masked] Mail List <
> [email-masked]>, Marc Petit-Huguenin <[email-masked]>, Christer
> Holmberg <[email-masked]>
> *Subject: *Making STIR SIP messages smaller
>
> Alec,
>
>
>

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 13 Apr 2021 02:31:03 +0000

Roman,

I’m not following how “info” would identify the header as containing a JWT. The “info” parameter contains a URL which could be used by a JWT or something else.

I don’t disagree that some implementations have issues when MTU is exceeded because they either don’t support TCP or don’t handle fragmentation properly. That being said, I wouldn’t call it broken. In my experience, most implementations handle packet fragmentation as long as the packets arrive in order. If the packets arrive out of order, they are generally discarded but then they are retransmitted because a SIP ACK is never sent. Even over the internet, packets arrive in order the vast majority of the time, so retransmissions work well. At the end of the day, calls complete without issue.

As far as TCP goes, I can only think of a one common network element that doesn’t support TCP (it actually does support TCP, but the TCP stack is broken, and the manufacturer doesn’t appear interested in fixing it). However, even that device doesn’t really count as it is a switch, so it was never intended to be used at the network edge. Fragmented UDP is used between the switch and the SBC (this isn’t a problem because packets almost always arrive in order over LAN connections and again, retransmission address anything that doesn’t). TCP can be used between the SBC and the SBC of the other network. Although again, I see fragmented UDP used more often than TCP.

But not of that really matters, the point I am trying to make is that compact form PASSporTs don’t save that much space over full form PASSporTs. So given the increased brittleness, I don’t think compact form PASSporTs are worth it. Example:

Full form (415 bytes):

Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuZXhhbXBsZS5jb20vZXhhbXBsZS5jcnQifQ.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxOTAzMjQ2OTEwMyJdfSwiaWF0IjoxNTg0OTgzNDAyLCJvcmlnIjp7InRuIjoiMTIwMTM3NzYwNTEifSwib3JpZ2lkIjoiNGFlYzk0ZTItNTA4Yy00YzFjLTkwN2ItMzczN2JhYzBhODBlIn0.EMfXHyowsI5s73KqoBzJ9pzrrwGFNKBRmHcx-YZ3DjPgBe4Mvqq9N-bThN1_HTWeSvbruAyet26fetRL1_bn1g

Compact form (231 bytes, assuming \r\n newlines and “attest=A” is used to convey attestation)

Session-ID: 4aec94e2-508c-4c1c-907b-3737bac0a80e

Identity: ..EMfXHyowsI5s73KqoBzJ9pzrrwGFNKBRmHcx-YZ3DjPgBe4Mvqq9N-bThN1_HTWeSvbruAyet26fetRL1_bn1g;info=<https://certificates.example.com/example.crt>alg=ES256;ppt="shaken";attest=A

So, for a SHAKEN PASSporT, it would save 184 bytes to use compact form. That isn’t nothing, but I don’t think it is worth it.

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Roman Shpount <[email-masked]>
Date: Monday, April 12, 2021 at 21:17
To: Alec Fenichel <[email-masked]>
Cc: Chris Wendt <[email-masked]>, [email-masked] Mail List <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: Making STIR SIP messages smaller

Alec,

I think the "info" header was required to identify the type of Identity header so that, in the future, you can switch to something different from JWT.

I understand the desire to pass a lot of information, including "nam" and "rcd," when setting up the call. The problem is SIP over UDP was not designed to pass the unlimited amount of information. A lot of current deployments in the field support UDP only. If the INVITE message becomes bigger than the UDP MTU, these deployments break. If you need to pass additional data with the SIP call where you do not control the entire network along the way, it should be passed out-of-band. In the perfect world, we would be using SIPS right now, but this is not the case.

The other solution would be to switch everything to passing Identity OOB, similar to PSTN, and only use the Identity header within a controlled network where its delivery can be guaranteed despite the size.

_____________
Roman Shpount

On Mon, Apr 12, 2021 at 7:53 PM Alec Fenichel <[email-masked]> wrote:

Roman,

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

Alec,

Best Regards,

_____________
Roman Shpount

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Apr 2021 23:20:45 -0400

Alec,

You are correct about the "info" parameter. It is completely unnecessary if
a full Identity header is used.

You are also correct that we would probably be fine with complete Identity
instead of compact identity with extra headers. If we remove all redundant
and optional data, then generated INVITE would be 1.4K, or right on the
border of max allowed MTU size. Please note that if any codecs or "rcd"
would be added, the problem will reappear. The extra 180 bytes you are
mentioning would provide some safety buffer for extra codecs or headers.

As long as SIP INVITE is below the PDU, we should be fine, but with a
full-size Identity, it is always bigger than the 1300 bytes limit for UDP
set in RFC3261 (see https://tools.ietf.org/html/rfc3261#section-18.1.1). In
general, Identity makes the SIP INVITE message 50% bigger. I am surprised I
am the first person who raised this issue.

I can go into more details regarding the issues related to going over UDP
MTU size. The several main issues here:

1. If UDP and TCP are both enabled on a SIP trunk, a SIP message should be
sent over TCP if it is within the 200 bytes of the UDP MTU size or over
1300 bytes if MTU is unknown. If the SIP request fails over TCP, it should
then retried over UDP. This causes PDD. Please see
https://tools.ietf.org/html/rfc3261#section-18.1.1

2. A major US internet service provider is dropping all fragmented UDP
messages on a number of its routes. If the SIP message ends up going
through this provider when traversing the public Internet, calls start
failing. When fragmented UDP is sent over the private interconnects, it
usually works fine.

3. TCP is stateful. This causes redundancy and fail-over issues with a lot
of implementations. Also, TCP implementations are not thought through or
tested as well as UDP.

In any case, if we can avoid switching the transport protocol, the
implementation would be much more robust.
_____________
Roman Shpount

On Mon, Apr 12, 2021 at 10:31 PM Alec Fenichel <[email-masked]>
wrote:

> Roman,
>
>
>
> I’m not following how “info” would identify the header as containing a
> JWT. The “info” parameter contains a URL which could be used by a JWT or
> something else.
>
>
>
> I don’t disagree that some implementations have issues when MTU is
> exceeded because they either don’t support TCP or don’t handle
> fragmentation properly. That being said, I wouldn’t call it broken. In my
> experience, most implementations handle packet fragmentation as long as the
> packets arrive in order. If the packets arrive out of order, they are
> generally discarded but then they are retransmitted because a SIP ACK is
> never sent. Even over the internet, packets arrive in order the vast
> majority of the time, so retransmissions work well. At the end of the day,
> calls complete without issue.
>
>
>
> As far as TCP goes, I can only think of a one common network element that
> doesn’t support TCP (it actually does support TCP, but the TCP stack is
> broken, and the manufacturer doesn’t appear interested in fixing it).
> However, even that device doesn’t really count as it is a switch, so it was
> never intended to be used at the network edge. Fragmented UDP is used
> between the switch and the SBC (this isn’t a problem because packets almost
> always arrive in order over LAN connections and again, retransmission
> address anything that doesn’t). TCP can be used between the SBC and the SBC
> of the other network. Although again, I see fragmented UDP used more often
> than TCP.
>
>
>
> But not of that really matters, the point I am trying to make is that
> compact form PASSporTs don’t save that much space over full form PASSporTs.
> So given the increased brittleness, I don’t think compact form PASSporTs
> are worth it. Example:
>
>
>
> Full form (415 bytes):
>
>
>
> Identity:
> eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0aWZpY2F0ZXMuZXhhbXBsZS5jb20vZXhhbXBsZS5jcnQifQ.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyIxOTAzMjQ2OTEwMyJdfSwiaWF0IjoxNTg0OTgzNDAyLCJvcmlnIjp7InRuIjoiMTIwMTM3NzYwNTEifSwib3JpZ2lkIjoiNGFlYzk0ZTItNTA4Yy00YzFjLTkwN2ItMzczN2JhYzBhODBlIn0.EMfXHyowsI5s73KqoBzJ9pzrrwGFNKBRmHcx-YZ3DjPgBe4Mvqq9N-bThN1_HTWeSvbruAyet26fetRL1_bn1g
>
>
>
> Identity:
> ..EMfXHyowsI5s73KqoBzJ9pzrrwGFNKBRmHcx-YZ3DjPgBe4Mvqq9N-bThN1_HTWeSvbruAyet26fetRL1_bn1g;info=<
> https://certificates.example.com/example.crt
> >alg=ES256;ppt="shaken";attest=A
>
>
>
> So, for a SHAKEN PASSporT, it would save 184 bytes to use compact form.
> That isn’t nothing, but I don’t think it is worth it.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> *Date: *Monday, April 12, 2021 at 21:17
> *Subject: *Re: Making STIR SIP messages smaller
>
> Alec,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2021 09:39:44 +0000

>I agree that we need to figure out a way to make Identity headers smaller. As it stands right now, the Identity header with "shaken" PASSporT type adds around 600 bytes to an INVITE message.
>This makes typical SIP INVITE messages go from around 1K in size to 1.6K, which is bigger than the UDP MTU.

With or without Identity, didn’t that ship sail a long time ago? :)

Regards,

Christer

On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel <[email-masked]<mailto:[email-masked]>> wrote:
I guess what I am trying to say is that I think we should remove ppt from the examples because as you say, people tend to code to examples and smaller Identity headers would be ideal.

Sincerely,

Alec Fenichel
Senior Software Architect
[email-masked]<mailto:[email-masked]>
+1 (407) 760-0036
TransNexus

---

From: Chris Wendt <[email-masked]>
Date: Tue, 13 Apr 2021 13:28:08 -0400

Yes

> On Apr 13, 2021, at 5:39 AM, Christer Holmberg <[email-masked]> wrote:
> 
>  
> On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Mary Barnes <[email-masked]>
Date: Tue, 13 Apr 2021 12:49:58 -0500

Yeah - like nearly 20 years ago when we added headers like History-Info.
 And, really if you want to use a text based protocol, you surely can't
have small message sizes as a design priority.

On Tue, Apr 13, 2021 at 4:40 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

>
>
> >I agree that we need to figure out a way to make Identity headers
> smaller. As it stands right now, the Identity header with "shaken" PASSporT
> type adds around 600 bytes to an INVITE message.
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 13:54:14 -0400

Unfortunately, the message increase caused by the Identity header causes a
call failure rate increase of at least a few percent. There is a
substantial number of deployments affected by this and unlike things like
History-Info, this feature is now required by law.
_____________
Roman Shpount

---

From: Chris Wendt <[email-masked]>
Date: Tue, 13 Apr 2021 16:14:27 -0400

Would be good to understand better why, i have not heard that feedback from the STIR/SHAKEN community lately or maybe folks have given up complaining :)  While there was much talk about it maybe 2-3 years ago, those conversations have been pretty quiet as of late. As far as i’m aware much of the equipment both commercial and open source and deployments have adapted and adjusted, but maybe there is parts of the eco-system that haven’t gotten there yet.

-Chris

> On Apr 13, 2021, at 1:54 PM, Roman Shpount <[email-masked]> wrote:
> 
> Unfortunately, the message increase caused by the Identity header causes a call failure rate increase of at least a few percent. There is a substantial number of deployments affected by this and unlike things like History-Info, this feature is now required by law. 
> _____________
> Roman Shpount
> 
> 
> On Tue, Apr 13, 2021 at 1:50 PM Mary Barnes <[email-masked] <mailto:[email-masked]>> wrote:
> Yeah - like nearly 20 years ago when we added headers like History-Info.   And, really if you want to use a text based protocol, you surely can't have small message sizes as a design priority. 
> 
> On Tue, Apr 13, 2021 at 4:40 AM Christer Holmberg <christer.holmberg=[email-masked] <mailto:[email-masked]>> wrote:
>  
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2021 20:27:09 +0000

Hi,

SIP implementations need to support TCP, and they need to support long messages. If we wanted to make SIP more compact, there are tons of things we could do.

And, if an implementations makes it or breaks it based on presence of the info parameter, that implementation is walking on very thin ice…

Regards,

Christer

From: Chris Wendt <[email-masked]>
Sent: tiistai 13. huhtikuuta 2021 23.14
To: Roman Shpount <[email-masked]>
Cc: Mary Barnes <[email-masked]>; Christer Holmberg <[email-masked]>; Alec Fenichel <[email-masked]>; Marc Petit-Huguenin <[email-masked]>; [email-masked] Mail List <[email-masked]>
Subject: Re: [stir] Making STIR SIP messages smaller

-Chris

On Apr 13, 2021, at 1:54 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 13, 2021 at 1:50 PM Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Yeah - like nearly 20 years ago when we added headers like History-Info.   And, really if you want to use a text based protocol, you surely can't have small message sizes as a design priority.

Regards,

Christer

Sincerely,

Alec Fenichel

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

---

From: Alec Fenichel <[email-masked]>
Date: Tue, 13 Apr 2021 20:33:29 +0000

My motivations from making the “info” parameter optional aren’t really about the SIP message size. When using OOB, the transit provider receives one or more PASSporTs (not Identity headers, but PASSporTs) and needs to construct one or more Identity headers. If the “info” parameter was optional, then the transit provider wouldn’t need to decode the PASSporT to extract the “x5u” to set the “info” parameter. The transit provider would also not set the “alg” and “ppt” parameters either. So,

Can we make the “info” parameter option?

Can we not include the “info”, “alg”, and “ppt” parameters in examples that show full form PASSporTs because as previously mentioned, implementors often code to the examples and the STI-VS should be implemented to support not receiving these parameters?

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

From: Christer Holmberg <[email-masked]>
Date: Tuesday, April 13, 2021 at 16:27
To: Chris Wendt <[email-masked]>, Roman Shpount <[email-masked]>
Cc: Mary Barnes <[email-masked]>, Alec Fenichel <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, [email-masked] Mail List <[email-masked]>
Subject: RE: [stir] Making STIR SIP messages smaller

Hi,

Regards,

Christer

-Chris

_____________
Roman Shpount

On Tue, Apr 13, 2021 at 1:50 PM Mary Barnes <[email-masked]> wrote:

Regards,

Christer

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 17:14:34 -0400

Hi Chris,

There are different types of people who participate in the VoIP market.
There are large phone service providers who use equipment from large
vendors and generally standard compliant (however, this does not mean SIP
TCP works for them, but it works most of the time). You have other vendors,
which are small VoIP operators using either open source or equipment from
smaller companies. They do not participate in VoIP interops, do not follow
the standards, and generally rely on their vendors to provide working
equipment. These are the people who are affected. They also often
interconnect over the public internet, making the problem with fragmented
UDP worse for them.

I know that other headers make the SIP INVITE message larger, but for the
US PSTN call coming from a traditional SIP trunk, the INVITE size is still
around 1000 bytes. Adding Identity header makes it 1600 bytes. The smaller
customers are just now dealing with the interop when larger carriers switch
on the Identity, and things are starting to fail.

The fact that SIP over the reliable transports was badly designed in
RFC3261 makes the problem worse. For some reason, RFC3261 assumed that
sending INVITE over the reliable channel does not require retransmits and
that you can send responses to INVITE over the address in VIA. Both
assumptions are wrong and cause implementation issues. Essentially UDP was
tested more, so it is more stable. The way Identity is defined, it causes
transport to switch to TCP (or fragmented UDP), even though there is no
real reason for this to implement the desired functionality. All of this
results in my company spending time tracing call failures back to
origination.
_____________
Roman Shpount

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

> Would be good to understand better why, i have not heard that feedback
> from the STIR/SHAKEN community lately or maybe folks have given up
> complaining :)  While there was much talk about it maybe 2-3 years ago,
> those conversations have been pretty quiet as of late. As far as i’m aware
> much of the equipment both commercial and open source and deployments have
> adapted and adjusted, but maybe there is parts of the eco-system that
> haven’t gotten there yet.
>
> -Chris
>
>>> I guess what I am trying to say is that I think we should remove ppt
>>> from the examples because as you say, people tend to code to examples and
>>> I don’t mean to hijack this thread, but I have been meaning to bring
>>> this up anyways and it is related. Is there a reason I’m just overlooking
>>> for requiring the “info” parameter when a full-form PASSporT is used? If
>>> not, can we make it optional? The reason I ask is that with OOB, the
>>> transit provider receives a PASSporT out-of-band and then needs to
>>> construct an Identity header. Because of the “info” parameter requirement,
>>> the transit provider must decode the PASSporT in order to determine the
>>> “info” parameter. This is the only reason that a transit provider needs to
>>> decode the PASSporT. This isn’t difficult so it doesn’t really matter, but
>>> I figured I’d ask about potentially making the “info” parameter optional.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 17:21:33 -0400

The average SIP INVITE size for the US PSTN is 1KB without Identity. This
was working great with UDP for most customers (do not confuse them with SIP
standard implementors). When these people start seeing an extra 2-3% of
call failures, they blame everybody but not their PSTN provider SBC vendor.
The only thing they care about and need is to keep their phones ringing and
calls completing.
_____________
Roman Shpount

On Tue, Apr 13, 2021 at 4:27 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> SIP implementations need to support TCP, and they need to support long
> messages. If we wanted to make SIP more compact, there are tons of things
> we could do.
>
>
>
> And, if an implementations makes it or breaks it based on presence of the
> info parameter, that implementation is walking on very thin ice…
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Chris Wendt <[email-masked]>
> *Sent:* tiistai 13. huhtikuuta 2021 23.14
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Mary Barnes <[email-masked]>; Christer Holmberg <
> [email-masked]>; Alec Fenichel <
> [email-masked]>; Marc Petit-Huguenin <
> [email-masked]>; [email-masked] Mail List <[email-masked]>
> *Subject:* Re: [stir] Making STIR SIP messages smaller
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Apr 2021 21:38:23 +0000

Hi,

...

>You have other vendors, which are small VoIP operators using either open source or equipment from smaller companies. They do not participate in VoIP interops, do
>not follow the standards, and generally rely on their vendors to provide working equipment.

So, we shall modify the standards for people who don’t follow the standards?

>The fact that SIP over the reliable transports was badly designed in RFC3261 makes the problem worse. For some reason, RFC3261 assumed that sending INVITE over the reliable channel does not
>require retransmits and that you can send responses to INVITE over the address in VIA.

RFC 3261 does say that, for reliable transports, the response is normally sent on the connection on which the request was received.

   “For reliable transports, the response is normally sent on the
   connection on which the request was received.  Therefore, the client
   transport MUST be prepared to receive the response on the same
   connection used to send the request.”

I KNOW that there exist interoperability issues with TCP. But, if people implement TCP support wrong e.g., because they misunderstand the spec, shouldn’t we then instead clarify the spec?

Regards,

Christer

On Tue, Apr 13, 2021 at 4:14 PM Chris Wendt <[email-masked]<mailto:[email-masked]>> wrote:
Would be good to understand better why, i have not heard that feedback from the STIR/SHAKEN community lately or maybe folks have given up complaining :)  While there was much talk about it maybe 2-3 years ago, those conversations have been pretty quiet as of late. As far as i’m aware much of the equipment both commercial and open source and deployments have adapted and adjusted, but maybe there is parts of the eco-system that haven’t gotten there yet.

-Chris

Regards,

Christer

Sincerely,

Alec Fenichel

---

From: Keith Drage <[email-masked]>
Date: Wed, 14 Apr 2021 01:52:41 +0100

I have memories of SIP message length being discussed way back in days 
of the SIP working group, i.e. pre SIPCORE, precisely in regard to the 
UDP versus TCP question. And all the issues relating to using TCP were 
raised at that time.

The answer at that time was essentially that when message lengths get 
long, TCP is the way to go, and that TCP is mandatory to implement in 
any case. No mileage was seen to be gained to making SIP more "UDP 
friendly".

Talking to some of my own implementors at the time, some of the problems 
identified with TCP were seen by them as just being poor software 
design, rather than inherent problems.

One point I would make is that if this is a problem, then STIR is the 
cause of the problem, rather than the body that needs to solve the 
problem. SIPCORE should be brought into the discussion.

Keith

Co-chair of the SIP WG at the time

> I KNOW that there exist interoperability issues with TCP. But, if 
> people implement TCP support wrong e.g., because they misunderstand 
> the spec, shouldn’t we then instead clarify the spec?
>
> Regards,
>
> Christer
>
> On Tue, Apr 13, 2021 at 4:14 PM Chris Wendt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Would be good to understand better why, i have not heard that
>     feedback from the STIR/SHAKEN community lately or maybe folks have
>     given up complaining :)  While there was much talk about it maybe
>     2-3 years ago, those conversations have been pretty quiet as of
>     late. As far as i’m aware much of the equipment both commercial
>     and open source and deployments have adapted and adjusted, but
>     maybe there is parts of the eco-system that haven’t gotten there yet.
>
>     -Chris
>
>
>
>         Unfortunately, the message increase caused by the Identity
>         header causes a call failure rate increase of at least a few
>         percent. There is a substantial number of deployments affected
>         by this and unlike things like History-Info, this feature is
>         now required by law.
>
>         _____________
>         Roman Shpount
>
>         On Tue, Apr 13, 2021 at 1:50 PM Mary Barnes
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Yeah - like nearly 20 years ago when we added headers like
>             History-Info.   And, really if you want to use a text
>             based protocol, you surely can't have small message sizes
>             as a design priority.
>
>             On Tue, Apr 13, 2021 at 4:40 AM Christer Holmberg
>             <christer.holmberg=[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 >I agree that we need to figure out a way to make Identity
>                 headers smaller. As it stands right now, the Identity
>                 header with "shaken" PASSporT type adds around 600
>                 bytes to an INVITE message.
>
>                 >This makes typical SIP INVITE messages go from around 1K in size
>                 to 1.6K, which is bigger than the UDP MTU.
>
>                 On Mon, Apr 12, 2021 at 5:39 PM Alec Fenichel
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                     I guess what I am trying to say is that I think we
>                     should remove ppt from the examples because as you
>                     say, people tend to code to examples and smaller
>                     Identity headers would be ideal.
>
>                     I don’t mean to hijack this thread, but I have
>                     been meaning to bring this up anyways and it is
>                     related. Is there a reason I’m just overlooking
>                     for requiring the “info” parameter when a
>                     full-form PASSporT is used? If not, can we make it
>                     optional? The reason I ask is that with OOB, the
>                     transit provider receives a PASSporT out-of-band
>                     and then needs to construct an Identity header.
>                     Because of the “info” parameter requirement, the
>                     transit provider must decode the PASSporT in order
>                     to determine the “info” parameter. This is the
>                     only reason that a transit provider needs to
>                     decode the PASSporT. This isn’t difficult so it
>                     doesn’t really matter, but I figured I’d ask about
>                     potentially making the “info” parameter optional.
>                     <mailto:[email-masked]>
>
>                     +1 (407) 760-0036
>
>                     TransNexus
>
>                 <https://www.ietf.org/mailman/listinfo/stir>
>
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 13 Apr 2021 21:34:46 -0400

<Sigh> This thread is SOOO boring.  We are all past the issue of TCP vs UDP and TCP keep alive at the edge.  Just get over it.  Resistance is futile.  Don’t be surprised if History Info is mandated over time to support Traceback. Then you will see a serious INVITE. 

The regulators are not being very forgiving these days. The FCC has issued some interesting orders re petitions for reconsideration and letters of excommunication to operators that won’t comply.

https://www.fcc.gov/document/fcc-issues-robocall-cease-and-desist-letters-six-voice-providers

https://www.fcc.gov/document/fcc-denies-stirshaken-caller-id-authentication-extension-petitions

https://www.youtube.com/watch?v=WnxJyEF4qLE

The CRTC has granted some extensions but the effect is very very clear.

https://crtc.gc.ca/eng/archive/2021/2021-123.htm

This is the #1 complaint I’ve seen in consulting with various operators for a project I’m undertaking for a well known regulator along with full Canonicalization of the E.164 number in the INVITE etc. AND AND the inability to negotiate a IP Voice interconnection agreement. 

Film at 11

— 

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 Christer Holmberg <christer.holmberg=[email-masked]>
Date: Tuesday, April 13, 2021 at 4:27 PM
To: Chris Wendt <[email-masked]>, Roman Shpount <[email-masked]>
Cc: Alec Fenichel <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Mary Barnes <[email-masked]>, "[email-masked] Mail List" <[email-masked]>
Subject: Re: [stir] Making STIR SIP messages smaller

Hi,

Regards,

Christer

-Chris

_____________
Roman Shpount

Regards,

Christer

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 22:26:24 -0400

Maybe this would be a reason to get sipcore to actually look at the TCP
(and other reliable protocols) and fix the design issues. I know this is
boring, but I could not get anyone interested in making TCP work as
reliably as UDP or to scale as well. The problem is that even though the
Identity header is mandatory due to FCC regulations, making TCP work is
not. So, carriers enable the Identity header and let calls (at least some
of them) fail. I am just trying to be practical and minimize the disruption.
_____________
Roman Shpount

On Tue, Apr 13, 2021 at 9:34 PM Richard Shockey <[email-masked]> wrote:

>
>
> <Sigh> This thread is SOOO boring.  We are all past the issue of TCP vs
> UDP and TCP keep alive at the edge.  Just get over it.  Resistance is
> futile.  Don’t be surprised if History Info is mandated over time to
> support Traceback. Then you will see a serious INVITE.
>
>
>
> The regulators are not being very forgiving these days. The FCC has issued
> some interesting orders re petitions for reconsideration and letters of
> excommunication to operators that won’t comply.
>
>
>
>
> This is the #1 complaint I’ve seen in consulting with various operators
> for a project I’m undertaking for a well known regulator along with full
> Canonicalization of the E.164 number in the INVITE etc. AND AND the
> inability to negotiate a IP Voice interconnection agreement.
>
>
>
> Film at 11
>
>
>
> —
>
> Richard Shockey
>
> Shockey Consulting LLC
>
> *From: *stir <[email-masked]> on behalf of Christer Holmberg
> <christer.holmberg=[email-masked]>
> *Date: *Tuesday, April 13, 2021 at 4:27 PM
> *To: *Chris Wendt <[email-masked]>, Roman Shpount <
> [email-masked]>
> *Cc: *Alec Fenichel <[email-masked]>, Marc Petit-Huguenin <
> [email-masked]>, Mary Barnes <[email-masked]>, "
> [email-masked] Mail List" <[email-masked]>
> *Subject: *Re: [stir] Making STIR SIP messages smaller
>
>
>
> Hi,
>
>
>
> _______________________________________________ stir mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/stir
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 13 Apr 2021 23:01:04 -0400

From: Roman Shpount <[email-masked]>
Date: Tuesday, April 13, 2021 at 10:26 PM
To: Richard Shockey <[email-masked]>
Cc: Christer Holmberg <christer.holmberg=[email-masked]>, Chris Wendt <[email-masked]>, Alec Fenichel <[email-masked]>, Marc Petit-Huguenin <[email-masked]>, Mary Barnes <[email-masked]>, "[email-masked] Mail List" <[email-masked]>
Subject: Re: [stir] Making STIR SIP messages smaller

Maybe this would be a reason to get sipcore to actually look at the TCP (and other reliable protocols) and fix the design issues. I know this is boring, but I could not get anyone interested in making TCP work as reliably as UDP or to scale as well. 

RS> Never. You have to be out of your mind. NO one is going to fix TCP.

The problem is that even though the Identity header is mandatory due to FCC regulations, making TCP work is not. So, carriers enable the Identity header and let calls (at least some of them) fail. I am just trying to be practical and minimize the disruption.

RS> I’ve personally lived with network disruption for 20 years or so. SIP itself and LNP .Look it would not take some of us a long time to write a ex parte filling to the CRTC, FCC or OFCOM asking them to mandate TCP for SIP/IMS signaling. I’m even now asking them to mandate protection of S/S data under the Code of Federal Regulations. 

I do this for a living..

https://ecfsapi.fcc.gov/file/1030722789616/Shockey%20Consulting%20FCC%20Exparte%20WC%2017-97%20March%202021%20copy.pdf

_____________
Roman Shpount

 

Film at 11

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

Hi,

Regards,

Christer

-Chris

_____________
Roman Shpount

Regards,

Christer

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2021 23:10:40 -0400

On Tue, Apr 13, 2021 at 11:01 PM Richard Shockey <[email-masked]> wrote:

> *Date: *Tuesday, April 13, 2021 at 10:26 PM
> *To: *Richard Shockey <[email-masked]>
> *Cc: *Christer Holmberg <christer.holmberg=[email-masked]>,
> Chris Wendt <[email-masked]>, Alec Fenichel <
> [email-masked]>, Marc Petit-Huguenin <
> reliably as UDP or to scale as well.
>
>
>

    I misunderstand me. I meant fixing SIP over TCP or other reliable
protocols.

>  The problem is that even though the Identity header is mandatory due to
> FCC regulations, making TCP work is not. So, carriers enable the Identity
> header and let calls (at least some of them) fail. I am just trying to be
> practical and minimize the disruption.
>
>
>
> RS> I’ve personally lived with network disruption for 20 years or so. SIP
> itself and LNP .Look it would not take some of us a long time to write a ex
> parte filling to the CRTC, FCC or OFCOM asking them to mandate TCP for
> SIP/IMS signaling. I’m even now asking them to mandate protection of S/S
> data under the Code of Federal Regulations.
>
>
>
> I do this for a living..
>
>
>
>

I know who you are and your views. I agree with a lot of them but I have to
live with the reality of existing systems. Since you think you can change
how the US telephone network operates, please make everyone use SIPS over
IPv6. It has been long overdue.
_____________
Roman Shpount

---

From: Richard Shockey <[email-masked]>
Date: Tue, 13 Apr 2021 23:18:53 -0400

+1 Keith.   I’ve heard of all the interop problems from the US and CA carriers. The UK is in process via NICC.

https://niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf

and there are reports that the French are actively involved (I’ve heard from them) though their regulators want to use ETSI to run their SDO process.

https://www.etsi.org/

South of France not totally surprising 3GPP still likes Croatia 

Sophia Antipolis?

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Keith Drage <drageke=[email-masked]>
Date: Tuesday, April 13, 2021 at 8:52 PM
To: <[email-masked]>
Subject: Re: [stir] Making STIR SIP messages smaller

I have memories of SIP message length being discussed way back in days of the SIP working group, i.e. pre SIPCORE, precisely in regard to the UDP versus TCP question. And all the issues relating to using TCP were raised at that time. 

The answer at that time was essentially that when message lengths get long, TCP is the way to go, and that TCP is mandatory to implement in any case. No mileage was seen to be gained to making SIP more "UDP friendly".

Talking to some of my own implementors at the time, some of the problems identified with TCP were seen by them as just being poor software design, rather than inherent problems.

One point I would make is that if this is a problem, then STIR is the cause of the problem, rather than the body that needs to solve the problem. SIPCORE should be brought into the discussion.

Keith

Regards,

Christer

 

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

-Chris

_____________
Roman Shpount

Regards,

Christer

Sincerely,

Alec Fenichel

+1 (407) 760-0036

TransNexus

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Apr 2021 15:12:22 +0000

Hey Marc,

Just to give my own impressions...

	1. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5390__;!!N14HnBHF!volm2Uvl1A0RaZiRMknqPXobk9w7XA4I4j5gLFDzzTnNSiHbbFyEZuA05bA$ 

I agree that the potential attack vector is not limited to DTLS-SRTP as a use case,  but I'm not sure I consider this fix "errata." The statement in the 12.1 is not normative, and as far as I can tell is a true description of the behavior of the mechanism. The fact that the signature might also protect things other than DTLS-SRTP just isn't the subject of that sentence taken in isolation.

	2. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5391__;!!N14HnBHF!volm2Uvl1A0RaZiRMknqPXobk9w7XA4I4j5gLFDzzTnNSiHbbFyEmsKno6Y$ 

We definitely decided to do it this way, it wasn't an accident, and so I don't view this as an error. I can see the argument for stating explicitly that RFC 8224 overrides the text in RFC 7518 section 4.1.6 to remove any confusion, but I'm not sure that would make a difference for me as to what behavior I put in, were I implementing it. If you don't like the override, the text still lets you use the clock at the AS to generate an "iat" value.

	3. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5715__;!!N14HnBHF!volm2Uvl1A0RaZiRMknqPXobk9w7XA4I4j5gLFDzzTnNSiHbbFyEX5bwuqc$ 

I'm sure that the language could be cleaned up in both RFC8224 and RFC8225 here. Our use of "object" vs. "array" vs. just "value", or even "claim" or "element",  was definitely a bit sloppy, and they were the subject of some last-minute wordsmithing, which didn't lead to total alignment. That much said, I'm not entirely sure what bar to implementation would be removed by tightening all this up, and it would be an exercise to figure out exactly which parts to tighten. So I'm a little lukewarm on this one.

	4. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6499__;!!N14HnBHF!volm2Uvl1A0RaZiRMknqPXobk9w7XA4I4j5gLFDzzTnNSiHbbFyEa6rqiDI$ 

That seems like actual errata to me. Fine by me to fix it.

	5. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6519__;!!N14HnBHF!volm2Uvl1A0RaZiRMknqPXobk9w7XA4I4j5gLFDzzTnNSiHbbFyEaZLX0P8$ 

This one we're discussing elsewhere, but it looks good to me.

Jon Peterson
Neustar, Inc.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 14 Apr 2021 08:37:25 -0700

Thanks Jon.  Hopefully that's enough comments to have our chairs verify/hold/reject these errata.

On 4/14/21 8:12 AM, Peterson, Jon wrote:
> 	1. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5390__;!!N14HnBHF!vB-riIssLbCue77ZKcQR5dQ9bLfLiUdeH7FpVBy5_W-tYbCEDX33sgxRwzNd2Y5CGLQ$
> 
> 	2. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5391__;!!N14HnBHF!vB-riIssLbCue77ZKcQR5dQ9bLfLiUdeH7FpVBy5_W-tYbCEDX33sgxRwzNdnkkFpis$
> 
> 	3. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5715__;!!N14HnBHF!vB-riIssLbCue77ZKcQR5dQ9bLfLiUdeH7FpVBy5_W-tYbCEDX33sgxRwzNd6Z8MYnY$
> 
> 	4. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6499__;!!N14HnBHF!vB-riIssLbCue77ZKcQR5dQ9bLfLiUdeH7FpVBy5_W-tYbCEDX33sgxRwzNdg4WYbn4$
> 
> 	5. https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6519__;!!N14HnBHF!vB-riIssLbCue77ZKcQR5dQ9bLfLiUdeH7FpVBy5_W-tYbCEDX33sgxRwzNdWn4ubGw$
>