jiebi/CodeConvo huggingface dataset:
Change:
Add a section about being careful with timing with respect to CID migration if you actually care about linkability.
Linkability across CID changes is in the common case so trivial that protocol features to defeat linkability through other means risk being useless. "Find CID y where delay < d between last packet for CID x and first packet for CID y on 2-tuple {a,p}, given {x,a,p}" is an operation which requires zero additional state and a simple O(kn log n) search for any large on-path (passive surveillance) device that's halfway smart about keeping per-flow state -- i.e., it's basically a free operation, and its utility is baked into the physics of CIDs -- after all, this is what CIDs are for. The ease of this analysis can only be mitigated by increasing the size of the anonymity set: ensuring that for any given delay window d, a minimum number of CIDs x transition on any given {a,p}. This seems like good operational advice for servers with enough traffic to build such anonymity sets (should they have interest in preventing client linkability, of course) -- small servers are probably out of luck though. Applicability should call this out as a problem, manageability should suggest a solution space.
-quic-transport section 6.11.5. begins to address this now, but aside from the following... URL still seems to pretend that coordinated CID migration is sufficient to fix linkability. So I still think we need something in -applicability. Will throw together a PR today.
addressed in

Discussion:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <ins> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </ins> 7. Versioning in QUIC may change the protocol's behavior completely,
Change:
Using the Spin Bit for Passive RTT Measurement ... Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of [acm] suggest s/any/all/ ... Since the spin bit logic at each endpoint considers only samples from packets that advance the largest packet number, signal generation itself is resistant to reordering. However, reordering can cause problems at an observer by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT estimates, if reordering occurs across a spin-bit flip in the stream. [acm] thanks for mentioning this! ... Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT. RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). [acm] (let's avoid the clocky term "jitter", and clarify) Suggest: (which over-estimates one-way packet delay variance as seen by an application end-point).

Discussion:
Handshake RTT can be measured by adding the client-to-observer and observer-to-server RTT components together.  This measurement <del> necessarily includes any transport- and application-layer delay at </del> <ins> necessarily includes all transport- and application-layer delay at </ins> both endpoints. 3.8.2.

in IPIM. Note that this measurement, as with passive RTT measurement for TCP, <del> includes any transport protocol delay (e.g., delayed sending of </del> <ins> includes all transport protocol delay (e.g., delayed sending of </ins> acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the

application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) <del> and RTT variance (which approximates jitter as seen by the application). </del> <ins> and RTT variance (which approximates one-way packet delay variance as seen by an application end-point). </ins> 4.
Change:
Per Al Morton's opsdir review, review the use of these three terms and correct where appropriate.

Discussion:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP.  Use of the </del> <ins> filtering), which potentially triggers TCP fallback.  Use of the </ins> connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes.

is desired.  Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision to whether or not filter later packets in the same connection.  QUIC <del> applications are encouraged to fail over to TCP if early packets do </del> <ins> applications are encouraged to fall back to TCP if early packets do </ins> not arrive at their destination QUIC-APPLICABILITY, as QUIC is based on UDP and there are known blocks of UDP traffic (see sec-udp-1312). Admitting a few packets allows the QUIC endpoint to determine that

Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets indiscriminately.  When the handshake is blocked, QUIC-capable <del> applications may fail over to TCP.  However, blocking a random </del> <ins> applications may fall back to TCP.  However, blocking a random </ins> fraction of QUIC packets across 4-tuples will allow many QUIC <del> handshakes to complete, preventing a TCP failover, but these </del> <ins> handshakes to complete, preventing TCP fallback, but these </ins> connections will suffer from severe packet loss (see also sec- filtering).  Therefore, UDP throttling should be realized by per-flow policing, as opposed to per-packet policing.  Note that this per-flow
Change:
lgtm
IMO the PR is clearer (and better reflects the intent / my understanding of WG consensus), so I'd merge it then continue the discussion after the submission cutoff.

Discussion:
flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- <del> QUIC traffic for purposes of network admission control should admit all QUIC traffic regardless of version. </del> <ins> QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continious version-based evolution and avoid unnecessary deployment delays. </ins> 3.
Change:
Addresses OPSDIR comment discussion.
hi NAME -- does this better clarify language about recommendations in the introduction? PTAL, thanks!!
Looks good to me.
I'm not sure if this is actually fully true. We use the terms "recommended" or "recommendation" multiple times in this document and I don't see a reason to remove it. I think these are the things that the quic group recommends, of course if anybody follows those recommendations is another questions.
so I'm not removing the recommendations elsewhere (modulo ), just changing the language here to say "don't think we think it's a good idea for you just because we wrote it in general), which I think is indeed more true than what was here before...

Discussion:
Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be <del> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, it describes what is and is not possible with the QUIC transport protocol as defined. </del> <ins> impermissible on other networks without those requirements.  The presence of a particular practice in this document should therefore not be construed as a recommendation to apply it.  For each practice, this document describes what is and is not possible with the QUIC transport protocol as defined. </ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on
Change:
Instead of making an explicit policy recommendation with respect to version recognition, clarify the downsides of doing so.
NAME I think this addresses the objection to policy recommendations on version recognition; PTAL. thanks!!
I can live with the latest wording here, thanks! And I didn't imagine that "traditional" was non-inclusive language; traditions are an inexorable aspect of many cultures...
I can see how some uses of the word tradition or traditional are non-inclusive. The occurences here do not strike me that way and the alternatives presented weaken the point of the text. We can proceed with an open mind to whether the term needs to be changed in response to wider review via subsequent review in the process.
My understanding is that "traditional" is also flagged because it's usually not a clear term in technical documents and I think that's the case here as well. There is no tradition about deploying certain protocols. We could just say "older" or "other protocols used so far" or something like this.
If you editors would like to replace it with a different term that conveys your intent, that's fine by me. Perhaps switch traditional for "other commonly used"
s/traditional/most other/g?
other commonly used is also good, but requires a manual rewrap. :)
thanks for addressing the in-solidarity bot

Discussion:
QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the <del> Internet more often than with traditional Internet- and transport- layer protocols.  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, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continuous version-based evolution and avoid unnecessary deployment delays. </del> <ins> Internet more often than with other commonly deployed Internet- and transport-layer protocols.  Use of the version number field for traffic recognition will therefore behave differently than with these protocols.  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. </ins> 3.
Change:
-manageablility has guidelines on how to select ConnIDs at a server, which is really more an -applicability thing. This fixes that.

Discussion:
In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to <del> the load balancers. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server are able to identify and discard packets featuring an invalid MAC. </del> <ins> the load balancers.  Guidance on assigning connection IDs is given in QUIC-APPLICABILITY. </ins> 4.4.
Change:
AFAIK Microsoft's SMB-over-QUIC also uses 443.
Not sure we explicitly need to add that...?
It does underscore the point that HTTP/3 != 443, and 443 != HTTP/3. I think it's useful to add.
The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation, mechanisms for dynamic port assignments, and NATs. NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)
There's an example in that makes this true enough for QUIC that I'd like to say something about it: UDP 443 doesn't mean QUIC, and it doesn't even mean HTTP/3 over QUIC, and HTTP/3 over QUIC doesn't imply UDP 443 because... well, of HTTP semantics (but I do think Paul is right here -- "appearing in a URL" is probably the most widely used form of dynamic port assignment today).
I've sent a reply to Paul by email and waiting for a response now.
For the record this is my mail reply: "[MK] There is actually an example: Microsoft's SMB-over-QUIC uses 443. I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443. However, do you think any changes to the text are needed? If so, can you be more concrete?"
RFC6335 also says this I removed NAT as we only talk about dest port here and added another reference to RFC6335 in PR

Discussion:
known at the time of writing to have active Internet deployments, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 uses UDP port 443 by convention but various methods can be used to <del> specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del> <ins> specify alternate port numbers.  Other applications (e.g., Microsoft's SMB over QUIC) also use UDP port 443 by default. Therefore, simple assumptions about whether a given flow is using QUIC, or indeed which application it might be using QUIC, based solely upon a UDP port number may not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-
Change:
From review by NAME
it’s worth noting that compatible version negotiation can cause the version to change mid-handshake. The true signal is a server-chosen version field echoed in a client packet.
Should this reference the compatible version negotiation piece of QUIC-VN?

Discussion:
An in-network observer assuming that a set of packets belongs to a QUIC flow might infer the version number in use by observing the <del> handshake: for QUIC version 1, if the version number in the Initial packet from a client is the same as the version number in the Initial packet of the server response, that version has been accepted by both endpoints to be used for the rest of the connection. </del> <ins> handshake.  If the version number in an Initial packet of the server response is subsequently seen in a packet from the client, that version has been accepted by both endpoints to be used for the rest of the connection (see Section 2 of I-D.ietf-quic-version- negotiation). </ins> The negotiated version cannot be identified for flows for which a handshake is not observed, such as in the case of connection
Change:
From NAME review.
This PR now as well.
cryptographically obfuscates An odd term. I see obfuscation to be non-cryptographic and cryptographic transformation to not be as weak as to be seen as obfuscation (but as encryption or secure hashing)
I replied by mail to Paul and explained that the header protection is kind of weak, so cryptographically protected might be too strong and this was his reply: Maybe the only thing is finding a better term for “cryptographically obfuscates”? I understand your reasoning but I still feel a little that this is doing a disservice to “cryptography”. But it was a comment, so I will leave it up to the authors. But maybe we can find a better term...?
Also a related comment on the same section from Eric Vyncke:
Note that PR is also editing this same part of the text.
I would say "protects" instead of "obfuscates". We have an analysis to support this claim (now cited in RFC 9001), we don't need to hedge. We used to be less certain (we did basically just invent this off the cuff at an interim meeting), but we're far more confident in stronger claims now.
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?
retry packets are actually protected by the Retry Integrity Tag. However not sure about version negotiations...?
The text in section 2.1. is already covered by issue and fixed by PR respectively. However, the text in section 1 needs fixing as well as VN packets are not really protected...
Retry and VN packets “are not encrypted or protected in any way.” While this is made clear later in the document, it would be good to way that Retry packets are (forgibly) integrity-protected and that QUIC TPs later authenticate most of the contents of these packets.

Discussion:
explicit in both cases. Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation <del> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or protected in any way.  For other kinds of packets, version 1 of QUIC cryptographically obfuscates other information in the packet headers: </del> <ins> (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted.  Retry packets are (forgibly) integrity protected.  Transport parameters are used authenticate the contents of Retry packets later in the handshake.  For other kinds of packets, version 1 of QUIC cryptographically protects other information in the packet headers: </ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet
Change:
Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?

Discussion:
As a result, client implementations are encouraged to avoid using source ports associated with protocols known to be vulnerable to <del> reflection attacks.  Note that the list above is not exhaustive; other source ports might be considered reflection vectors as well. </del> <ins> reflection attacks.  Note that following the general guidance for client implementations given in RFC6335, to use ephemeral ports in the range 49152-65535, has the effect of avoiding these ports.  Note that other source ports might be reflection vectors as well. </ins> 9.
Change:
The last two paragraphs of the security considerations section were for a (much earlier, probably pre-WG) version of the document. Now that -manageability is basically a wire image users' guide, they don't belong. So let's cut them.

Discussion:
tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. <del> Some of the properties of the QUIC header used in network management are irrelevant to application-layer protocol operation and/or user privacy.  For example, packet number exposure (and echo, as proposed in this document), as well as connection establishment exposure for 1-RTT establishment, make no additional information about user traffic available to devices on path. At the other extreme, supporting current traffic classification methods that operate through the deep packet inspection (DPI) of application-layer headers are directly antithetical to QUIC's goal to provide confidentiality to its application-layer protocol(s); in these cases, alternatives must be found. </del> 7. This work is partially supported by the European Commission under