On 7/23/2023 10:40 AM, Kazuho Oku wrote:
2023年7月22日(土) 15:24 Marten Seemann<martenseem...@gmail.com>:
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, inhttps://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 think there are few deployments today that multiplex several protocols
on the same UDP port. I would be reluctant to do that personally,
especially multiplexing QUIC with a cleartext protocol. It seems that
would significantly increase the attack surface.
-- Christian Huitema
