Re: Demultiplexing QUIC

[Marten Seemann <[e-mail]>]

A server deployed on the public internet never knows what other protocols
the client is demultiplexing with QUIC, so the QUIC bit always needs to be
set to 1. Maybe this should even be a "MUST, unless the server has
out-of-band knowledge that the client is not demultiplexing"?

As Lucas pointed out, the fact the client is offering the Greasing the QUIC
Bit extension can be seen as an indication that the client doesn't care
about demultiplexing, but it's unlikely that the server would be able to
(or willing to) parse the transport parameters for a QUIC version that it's
going to send a Version Negotiation packet for.

On Sun, 23 Jul 2023 at 11:04, Lucas Pardue <[e-mail]>
wrote:

> Hey,
>
> On Sun, Jul 23, 2023 at 6:40 PM Kazuho Oku <[e-mail]> wrote:
>
>> 2023年7月22日(土) 15:24 Marten Seemann <[e-mail]>:
>>
>>> 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
>