Hey, On Sun, Jul 23, 2023 at 6:40 PM Kazuho Oku <[email protected]> wrote:
> 2023年7月22日(土) 15:24 Marten Seemann <[email protected]>: > >> RFC 9443 defines how to demultiplex QUIC from a whole range of other >> protocols. Packets in the range 128..191 (i.e. all packets starting with >> 0b10xxxxxx) are supposed to be forwarded to RTP/RTCP. >> >> This mostly works, since QUIC v1 packets (both short and long header) >> define the "QUIC bit", the second bit (0x40) to be set to 1. On the other >> hand, Version Negotiating packets are defined as 0b1xxxxxxx, where the last >> 7 bits are an arbitrary value. RFC 8999 defines these bits as unused, and >> it's up to the server to decide how to set these bits. Specifically, it's a >> valid strategy to set them to a fixed value. If that value starts with a 0, >> Version Negotiation packets would be consistently mis-classified as RTP >> packets. >> >> Section 17.2.1 of RFC 9000 says that servers SHOULD set the first of the >> unused bits to 1 "where QUIC might be multiplexed with other protocols". >> This advice is fine for some deployments, but in the general case, the >> server has no way of knowing what other things the client is demultiplexing >> on the same UDP socket. >> > > I actually think that this "where QUIC might be multiplexed other > protocols" could be an error in RFC 9000. FWIW, this condition was > introduced very late, in https://github.com/quicwg/base-drafts/pull/4744. > > I think what we really wanted to mean here is "unless an endpoint knows > that the peer is not demultiplexing." > I tend to agree with this. Interestingly, the Greasing the QUIC Bit RFC claims "The second-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 [QUIC <https://www.rfc-editor.org/rfc/rfc9287.html#RFC9000>]." but that is clearly not true for the Version Negotiation packet because the requirement is only a SHOULD. I don't think the grease setting really applies though, because the server wouldn't know to apply it. Therefore if a sever knows the client doesn't need the bit for demultiplexing, perhaps it "SHOULD set the QUIC Bit to an unpredictable value"? Cheers Lucas
