Hi Lucas, Tommy, Christian, Thank you for raising your concerns. As also mentioned by Tommy, let me clarify that draft-ietf-ippm-explicit-flow-measurements is not defining any standard, or allocating any code points in QUIC. It is an informational document and it aims to define transport agnostic methodologies that can theoretically be applicable to any transport-layer protocols between collaborative client and server. We are following the approach of RFC 8321 and RFC 8889, which were elevated to standards track when the methods were considered more mature (i.e. RFC 9341 and RFC 9342). As noted, different techniques and variants are described in this draft, but this does not mean that all the methods must be implemented in a single protocol. The assumption is that the possible future standards track documents, which could apply these methods to a specific protocol, will consolidate the design into fewer bits according to the particular application scenario. A first example is in CoAP (https://datatracker.ietf.org/doc/draft-ietf-core-coap-pm/). In summary, the QUIC implementation of these methods is out of scope for this draft. I think your concerns about QUIC are reasonable, but they can be taken into account only for the specific application to QUIC, that would eventually be defined in a separate draft. If there is the consensus in QUIC WG, we are interested to further discuss the implementation in QUIC at the IETF 117. For what concerns draft-ietf-ippm-explicit-flow-measurements, to avoid misunderstanding, we agreed to revise section 6 without saying explicitly which particular bits can be used in QUIC or TCP. As an alternative, section 6 can simply be removed and we can also reduce the references to QUIC documents in the whole draft. Please note that we plan to review the draft soon.
Regards, Giuseppe (on behalf of the coauthors) -----Original Message----- From: ippm <ippm-boun...@ietf.org> On Behalf Of Christian Huitema Sent: Thursday, May 11, 2023 9:38 AM To: Lucas Pardue <lucaspardue.2...@gmail.com>; Tommy Pauly <tpa...@apple.com> Cc: IETF IPPM WG <i...@ietf.org>; QUIC WG <quic@ietf.org> Subject: Re: [ippm] QUIC concerns relating to draft-ietf-ippm-explicit-flow-measurements On 5/10/2023 7:35 PM, Lucas Pardue wrote: > Hey Tommy, > > On Thu, May 11, 2023 at 3:00 AM Tommy Pauly<tpa...@apple.com> wrote: > >> The document is describing how bits*could* be used, not actually >> suggesting reserving specific ones at this point. >> >> This same feedback did come up in IESG review, and I believe that >> there will be an update to remove details that refer to specific bit >> ranges to avoid this danger. >> >> I’ll let the authors chime in more =) >> > > To summarize the issue, there's only 7 bits that any QUIC version > compatible with the Invariants can ever use. Unless client, server and > observers all agree what those bits might mean, there's no way to > actually use them assuredly. The draft doesn't pay enough attention to > highlighting this deployment problem, so there's a risk that the work > done to define the bits in the abstract is for nought because the next > steps of trying this out for real are unclear. Relying on some private > agreements of what the bits might mean isn't safe for several reasons. I addition to Lucas' concerns, let me express my own concern with the mention of the "UDP surplus space". This is the same concern that I have with the proposal to define "UDP options". These options would define an unencrypted trailer of QUIC packet. The idea is that the IP packet length is longer than UDP header length plus UDP payload length, leaving bits at the end that are not covered by the QUIC encryption. These bits create a clear text "side channel", which can be easily used to compromise the security of QUIC. I think this a serious security hole, which should be blocked. One way to block it is to immediately drop any QUIC packet for which IP length and UDP length don't match. Many firewalls do that already. Doing that will penalize any attempt to add a side channel to QUIC -- any application that used such a channel would cause packets to be dropped, making this kind of channels very unattractive. -- Christian Huitema _______________________________________________ ippm mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ippm
