Re: Demultiplexing QUIC

[Kazuho Oku <[e-mail]>]

2023年7月23日(日) 11:14 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"?
>

I think "SHOULD" as we state now might be better than a "MUST."

Version Negotiation packets are unique in the sense that "inherently not
version specific" (section 17.2.1). Rather, a Version Negotiation packet
has to abide by the specifications of all the version numbers that it
carries.

Considering that, I think it is not incorrect to state that all version 1
packets have the QUIC bit set and at the same time stating that Version
Negotiation packets might not have the bit set.


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

-- 
Kazuho Oku