Re: [stir] Making STIR SIP messages smaller

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
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
>
>
>
> 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
>
>
>
>