Re: Roman Danyliw's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)

[Christian Huitema <[e-mail]>]

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