RETIRE_CONNECTION_ID with invalid DestinationConnectionId

[WesleyRosenblum]

While testing the Kwik client, Kwik sent a RETIRE_CONNECTION_ID frame with Sequence: 0, using the Destination Connection ID referred to by Sequence ID 0. This is prohibited by RFC 9000 §19.16:

The sequence number specified in a RETIRE_CONNECTION_ID frame MUST NOT refer to the Destination Connection ID field of the packet in which the frame is contained.

The invalid RETIRE_CONNECTION_ID frame was received in response to the server sending two NEW_CONNECTION_ID frames, each with Retire Prior To set to 1.

    QUIC Short Header DCID=551da9400f5df100 PKN=2
        Destination Connection ID: 551da9400f5df100
        Packet Number: 2
    NEW_CONNECTION_ID
        Frame Type: NEW_CONNECTION_ID (0x0000000000000018)
        Sequence: 1
        Retire Prior To: 1
        Connection ID Length: 16
        Connection ID: 5d85502aec55ed8353dadfeef312dcbd
        Stateless Reset Token: e269a195ef8062b70da779053a8fbc1c
    NEW_CONNECTION_ID
        Frame Type: NEW_CONNECTION_ID (0x0000000000000018)
        Sequence: 2
        Retire Prior To: 1
        Connection ID Length: 16
        Connection ID: c2d3ecf9baa79bcaab11be1110319b59
        Stateless Reset Token: b8c029034e90fddc9ee9444fa8d5c6cd

Kwik responds with:

    QUIC Short Header DCID=f056bb77e1f2a374733029cd0985f75d PKN=3
        Destination Connection ID: f056bb77e1f2a374733029cd0985f75d
        Packet Number: 3
    RETIRE_CONNECTION_ID
        Frame Type: RETIRE_CONNECTION_ID (0x0000000000000019)
        Sequence: 0

Since Destination Connection ID: f056bb77e1f2a374733029cd0985f75d is the connection ID referred to by Sequence: 0, this is not valid. The Destination Connection should be either 5d85502aec55ed8353dadfeef312dcbd or c2d3ecf9baa79bcaab11be1110319b59

I didn't see anything obviously wrong in the Kwik code, but perhaps there is a race condition where the connection ID is being retired and the RETIRE_CONNECTION_ID frame is sent before the currentConnectionId can be updated?

Thanks for considering this issue and let me know if you need any further information!

[ptrd]

Hi,
Thanks for your bug report. I'll investigate.

[ptrd]

I cannot explain this. As you said, the code seems to be ok, setting retired status on the connection id before selecting the new connection id to use before sending the retire frame. Also, I could not spot any possible source for race-conditions; the connection id registry uses a concurrent map and the byte array reference storing the current cid is volatile..... What could be improved is to make two fields final (destConnectionIds in QuicClientConnectionImpl and the connectionIds map in ConnectionIdRegistry), but even without these being final, I cannot explain how a retired cid can be used by the sender.

Did you notice this just once? Of did it happen multiple times? I could not reproduce it myself...

In the mean time, the client code has been refactored and now uses the (new) ConnectionIdManager, which centralises connection ID management. However, as long as I cannot explain how it could occur in the "old" code, I cannot guarantee it will not happen with the new..... ;-(

[WesleyRosenblum]

Thanks for looking into it. I don't think I've seen it recently, I'm ok if you want to close this. I'll keep an eye out if it happens again

[ptrd]

Ok, cool. Please let me know if you ever see it again.

[WesleyRosenblum]

I'm seeing this happen again with the latest Kwik image

[ptrd]

😳
Thanks for reporting. I'll investigate again.