On 6/1/2022 5:51 AM, Mirja Kuehlewind wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Barry Leiba for the SECDIR review.
Thank you for this companion document considering the operational view of
the
wire image. It is a model to pattern for other protocols.
** Section 2.8
Using a particular version number to recognize valid QUIC
traffic is likely to persistently miss a fraction of QUIC flows, and
completely fail in the near future. Reliance on the version number
field for the purposes of admission control is similarly likely to
rapidly lead to unintended failure modes. Admission of QUIC traffic
regardless of version avoids these failure modes, avoids unnecessary
deployment delays, and supports continuous version-based evolution.
-- True, but this guidance seems a bit too strong. Operators may choose to
explicitly exclude traffic from particular “experimental versions" and
should
likely be curating their ACLs/admission control practices.
[MK] This was discussed quite heavily and last revised during IETF LC based on
the opsdir review, see here:
https://github.com/quicwg/ops-drafts/pull/467/files
[MK] The comment from the opsdir review was basically say that this document should not try
"tell operators what to do". (Sorry if I paraphrasing this to strongly). So we tried to
rather explain than givng concrete guidance. However, the whole point is that using version is a
problem and we have a strong that is should not be done. Yes, we understand that operator have a
desire to distinguish "valid" QUIC traffic (whatever) that means, but QUIC has been
designed to reveal as little information as possible and trying to (mis-)use any of the existing
exposed information for that purpose has problems. Given this was just revised and discussed
extensively, I rather not change the text again. Please let me know if you feel strong that some
more adaption is required here.
-- Consider if the text "... likely to rapidly lead to unintended failure
modes” will age well.
[MK] I don't think this is specific tot eh current version but rather the
general design principle that version are expected to change quickly.
-- Would there be an opportunity to fingerprint a unique application using
a
specific experimental version number (in an ecosystem of continuous
evolution
and experimentation suggested above)?
[MK] I guess that is the whole point here and I think the answer is no. You
might see new experimental version that come and go quickly and are deployed
only by one vendor but I don't think that will give you necessarily much
insights about the application within the encrypted payload. Also experimental
version are expected to be around for short times only and change quickly, thus
you would be very busy to adapt your fingerprinting continuously. That's why
the recommendation is to not do it.
Application developers will try to evolve the version number. If that
cause the packets to be somehow discarded, this will have a very
predictable result: all QUIC implementations will set the version number
to 1 in the clear text header, while the "real" version number will be
negotiated as part of the encrypted payload. If we follow that path, the
network managers will not have any usable signal about the QUIC version,
and the application developers will have to use more complex software
and carry four useless bytes in the initial packets. Truth is, this is
most likely what will happen, given natural trends. I don't know whether
the text in the applicability statement will be enough to avoid that fate.
-- Christian Huitema
