Hi Rob, thanks for your review.
Yes, quic was designed minimize exposure and therefore there is also no explicit support to make QUIC distinguishable. But believe me this was discussed a lot in the group. And yes there is a risk of blocking. However, there already have been cases where traffic was restricted to some earlier version of google's QUIC based on a bit that was not supposed to be fixed and let to unintentional blocking when it was changed. So whatever we do, these problems persists. I guess the strategy is to keep QUIC as a moving target. Also, port blocking is already really common, however, I think that becomes more and more meaningless because you can never be sure what's inside an encrypted protocol.... anyway, I agree, we will see... To your other points, we created an issue for point 1 and PRs for the other two! Thx! Mirja On 21.04.22, 15:51, "Robert Wilton via Datatracker" <[email protected]> wrote: Robert Wilton has entered the following ballot position for draft-ietf-quic-manageability-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document that is well written and gives a lot of detail about various aspects of the QUIC. I would also like to thank Al Morton for his review and for the authors diligently working with Al to reach a consensus position. I have to confess that I find some aspects of this document to be a bit of a odd duck, which I think that is based on the underlying design goals of QUIC to maximize privacy and prevent interference. I.e., a lot of the sections seem to end up implying that "you can't really do that in easy/reliable way with QUIC, or you shouldn't do it". From my reading of this doc, I get the overriding feeling that QUIC is not really designed to be easily distinguishable from regular UDP traffic, and at the same time, there seem to be some recommendations or suggestions about how QUIC traffic should be handled potentially differently from other UDP traffic under some circumstances. It will be interesting to see how QUIC deployment evolves over time, and whether some operators will restrict its usage to a few well known ports. Hopefully not. A few specific minor comments: 1. Section 1 states: No information in the protocol header, even that which can be inspected, is mutable by the network. This is enforced through integrity protection of the wire image [WIRE-IMAGE]. Section 2.1 states: Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or protected in any way. Do these two statements conflict: re protection? 2. On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. I presume that it is implicit in the sense that each endpoint knows how long the connection IDs are? 3. 2.6. Connection ID and Rebinding Further it can be used by in-network devices to ensure that related 5-tuple flows are appropriately balanced together. When I read this, I thought that you were talking about ECMP and L2 load-balancing over LAG, but I presume that is not the intention here, and that you are referring to application layer load balancing? Regards, Rob
