Zero-lenght Client Connection IDs

[backkem]

I'm trying to connect from a client using google/quiche to a server using quic-go. The latter errors out the connection with Error occurred handling initial packet: too short connection ID.

It seems that quiche allows clients to use a zero-lenght client connection IDs. If I read RFC 9000 correctly, it also seems to allow for this. Some relevant excerpts:

5.1. Connection ID
A zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint.

5.1.1. Issuing Connection 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.

5.2.1. Client Packet Handling
Clients that choose to receive zero-length connection IDs can use the local address and port to identify a connection. Packets that do not match an existing connection -- based on Destination Connection ID or, if this value is zero length, local IP address and port -- are discarded.

5.2.2. Server Packet Handling
Packets with a supported version, or no Version field, are matched to a connection using the connection ID or -- for packets with zero-length connection IDs -- the local address and port. These packets are processed using the selected connection; otherwise, the server continues as described below.

7.3. Authenticating Connection IDs
If a zero-length connection ID is selected, the corresponding transport parameter is included with a zero-length value.

If I patch (s *baseServer) handleInitialImpl to allow either zero or sufficient length Connection IDs, the connection seems to progress.

I'm happy to put together a PR in line with this. However, I wanted to see if there is initial feedback or any gotchas to watch out for in this regard?

[marten-seemann]

Hi @backkem, thank you for opening this well-researched issue!

I assume that you're referring to this check in handleInitialImpl:

quic-go/server.go

Lines 545 to 552 in e1e5b62

	func (s *baseServer) handleInitialImpl(p receivedPacket, hdr *wire.Header) error {
	if len(hdr.Token) == 0 && hdr.DestConnectionID.Len() < protocol.MinConnectionIDLenInitial {
	if s.tracer != nil && s.tracer.DroppedPacket != nil {
	s.tracer.DroppedPacket(p.remoteAddr, logging.PacketTypeInitial, p.Size(), logging.PacketDropUnexpectedPacket)
	}
	p.buffer.Release()
	return errors.New("too short connection ID")
	}

This code implements the check required by section 7.2 of RFC 9000, which says:

When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value. This Destination Connection ID MUST be at least 8 bytes in length. Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection.

This only applies to the initial packet, for packets later in the connection a zero-length CID can be negotiated. In fact, that's what quic-go does when you use quic.Dial.

To further debug this, could you record a tcpdump of the packets that are being sent here?

[backkem]

Ah, thanks for the pointers! In this case the C++ client may be the one misbehaving. Let me check on that first.