Re: Use of zero-length connection IDs and NAT rebinding resilience

[Christian Huitema <[e-mail]>]

On 8/4/2024 3:37 PM, Cameron Steel wrote:
> 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.

It is a bit more complicated than that. First, let's get the naming 
right. "Connection migration" describes a voluntary action in which the 
client tries to reach the server using a different 5-tuple and a 
different connection ID. What you are encountering here is "NAT 
Rebinding", i.e., the effect of an uncoordinated decision by the NAT to 
forget the binding between the 5-tuple used by the client and the 
"external" 5-tuple.

After the NAT rebinding, all packets sent by the server to the old 
5-tuple will be lost: there is no mapping for that and packet are 
dropped by the NAT, or maybe the mapping has been reused for a new 
client and packet are dropped by that client because they cannot be 
decrypted.

The solution is for the server to somehow learn the new value of the 
client's 5-tuple. It can only do that by receiving packets from the 
client. All the packets sent after the NAT rebinding and before a new 
packet is received by the client will be lost, whether connection IDs 
are used or not. For example, if the application pattern is to send a 
request, then wait some long time before the server replies, the long 
wait will increase the risk of NAT rebinding, and the eventual response 
of the server will be lost.

If the traffic is series of HTTP GET triggering immediate responses, 
there is hope. The server could learn the new 5-tuple when receiving the 
GET command. But it needs to associate the arriving packet with the old 
connection, and it can only do that if the old packet carries a 
connection ID.

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

NAT Traversal will work if connection IDs are used in the client to 
server direction. I was under the impression that Chrome uses 0-length 
CID in the server to client direction, but Google servers use 8 bytes 
CID in the client to server direction. If that's the case, NAT rebinding 
should work.

> 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/

Can you attach some kind of packet log so we can see what is really 
happening? QLOG would be great.

-- Christian Huitema