Use of zero-length connection IDs and NAT rebinding resilience

[Cameron Steel <[e-mail]>]

Hi QUIC experts,

I've just completed a writeup of an issue I was experiencing with websites using QUIC through my ISP's CGNAT. In short, the issue was due to the CGNAT having a rather short UDP timeout of 20 seconds, in combination with the fact that Google Chrome seems to use zero-length connection IDs, which prevents connection migration.

In the process of checking the behaviour I was observing against the QUIC RFCs, I came across a few oddities that I'd like to bring up:

Both RFC 9000 and 9308 fairly plainly state that connections using zero-length IDs will not be resilient to NAT rebinding, however RFC 9000 section 5.1.1 does have this passage which vaguely implies that multiple network paths are possible with zero-length IDs:

> An endpoint that selects a zero-length connection ID during the handshake cannot issue a new connection ID. A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint over any network path.

As this is only implied the once that I can find, I'm assuming it's just ambiguous wording and that the intended behaviour is what I observed, that connection migration is not permitted when using a zero-length connection ID.

Given that, I'd be very curious to hear any insight into why Chrome has chosen not to use connection IDs.

If anyone is interested in reading my full writeup, you can find it here: https://blog.tugzrida.xyz/2024/08/04/too-quic-for-chrome-troubleshooting-udp-nat-rebinding/

Cameron Steel
he/him