Re: [stir] Making STIR SIP messages smaller

[Alec Fenichel <[e-mail]>]

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

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: Roman Shpount <[e-mail]>
Date: Monday, April 12, 2021 at 21:17
To: Alec Fenichel <[e-mail]>
Cc: Chris Wendt <[e-mail]>, [e-mail] Mail List <[e-mail]>, Marc Petit-Huguenin <[e-mail]>, Christer Holmberg <[e-mail]>
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.

 

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

_____________
Roman Shpount

 

 

On Mon, Apr 12, 2021 at 7:53 PM Alec Fenichel <[e-mail]> 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

Senior Software Architect

[e-mail]

[phone]

TransNexus

 

From: Roman Shpount <[e-mail]>
Date: Monday, April 12, 2021 at 19:00
To: Alec Fenichel <[e-mail]>
Cc: Chris Wendt <[e-mail]>, [e-mail] Mail List <[e-mail]>, Marc Petit-Huguenin <[e-mail]>, Christer Holmberg <[e-mail]>
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 <[e-mail]> 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

Senior Software Architect

[e-mail]

[phone]

TransNexus