3. <del> QUIC provides for 0-RTT connection establishment.  This presents opportunities and challenges for applications using QUIC. 3.1. </del>  A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. <del> Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </del>  <del> 3.2. </del>  Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same partial or even complete replay protection, which could be used to manage replay risk. <del> 3.3. </del>  Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes

This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)

3.  <ins> QUIC provides for 0-RTT connection establishment.  Though the same facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for applications using QUIC. </ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive.  <ins> An application needs to deliberately choose to use 0-RTT, as 0-RTT carries a risk of replay attack.  Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP- REPLAY. </ins>  <ins> 3.1. </ins> Retransmission or (malicious) replay of data contained in 0-RTT packets could cause the server side to receive two copies of the same partial or even complete replay protection, which could be used to manage replay risk.  <ins> 3.2. </ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short network idle timeouts.  Deployed stateful middleboxes


packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server <del> Hello, and some Initial Completion) must be at least 1200 octets long.  This protects against amplification attacks and verifies that the network path meets minimum Maximum Transmission Unit (MTU) requirements.  This is usually accomplished with either the addition of PADDING frames to the Initial packet, or coalescing of the Initial Packet with packets from other encryption contexts. </del>  The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the

This seeks to address issue: "MTU or Min QUIC Packet Size? "
Sect 2.4: says: “the network path meets minimum Maximum Transmission Unit (MTU) requirements. “ There is text in the QUIC transport spec that the WG perfected a little in the final stages, and I think this use of MTU in sect 2.3 is suspect. As I see it, the requirements in QUIC are for a minimum supported QUIC packet size... not the MTU required to send this on an interface. ... This nuanced might be a really important detail for operations staff - where there is frequently a need to consider encapsulations and tunnels on interfaces of devices. ... A cross reference to the QUIC Spec may also help here.
NAME can you propose text?
Thought to be addressed in PR
PR merged
I think there are only 3 ways to fill up the space, so maybe enumerate them? I also wonder if we need to caution against stripping unused UDP payload or splitting up packets within a UDP datagram?

packet and some also include an Initial packet. Datagrams that contain a QUIC Initial Packet (Client Hello, Server  <ins> Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. </ins> The content of QUIC Initial packets are encrypted using Initial Secrets, which are derived from a per-version constant and the


application to make the mapping of data to streams dependent on this information. <del> While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily expose stream identifiers to the application (see, for example, QUIC- HTTP, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </del>  4.1.

I believe it is sane to not assume a specific ID ordering, but I do not think it is right to require that all applications do not so. You can easily have applications that benefit from knowing and controlling the ID sequencing in detail, but such applications may not be implementable on the majority of QUIC library implementations. Ops should only make this a guidance for designing new app level protocols, not a requirement.
I would see everything in the ops docs as a recommendation and not a requirement. However this PR is already merged. Can you open a new issue (and ideally propose some wording or say more specifically where you think the current wording is too restrictive)?
NAME done
Follow up to comment on The current text: might vary between transport implementations. Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. For example, HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way in which they are assigned. Specifically "An application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. " This highly depends on the application protocol, not the QUIC transport API. It may be that a given QUIC transport protocol is unable to support the requirements of a QUIC application protocol, but it is the app protocol that decides. If a given QUIC transport API only supports "OpenNextStreamOfType(x)" that might be enough to support HTTP/3. But it should be be that all app protocols follow the same constraints. However, it is reasonable to recommend that application level protocols attempts to avoid a dependency on a specific stream ID in order to be able to target a broader range of QUIC transport libraries and to avoid unnecessary dependencies while at the same time permitting this for specific use cases.
I not sure what you are missing here or what you think should be changed. For me the text is inline with what you say, which basically is: to be on the safe side you better make no assumption about how non-yet assigned ID will be used because there is no unified way how this is specified in the protocol spec. So, basically saying even if the interface seem to provide that, be careful here!
The text "An application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated. " basically says that you should not design protocols that rely on stream IDs have any particular meaning. But you could easily design such protocols safely, but it will only work for transport libraries that permit such close coordination. Personally I think it is best to avoid such dependencies in most cases, but that shouldn't prevent special purpose protocols from existing. For example, a telemetric protocol might define that streams 1 through 100 (modulo stream type) each indicate a log level of implied severity.
This is a recommendation not a normative SHOULD. We are only trying to provide guidance but if you are a specialised application and you know what you are doing you can of course do that.
NAME can we close this issue or would you like to propose a wording change?
Seeing no further action/suggestion, closing. Please reopen if there's a concrete change to make.
The ops draft currently says: to send data on separate streams, it does not necessarily expose stream identifiers to the application (see, for example, {{QUIC-HTTP}}, Section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. I don't see anything in Section 6 of HTTP/3 to support that claim. In fact, HTTP/3 uses Stream IDs in the GOAWAY frame to indicate the last request the server processed; both client and server will require access to the identifiers of streams, or that information is impossible to generate and useless to receive. The constraint that I tried to use when writing the HTTP draft was that the application layer has no control over the assignment of Stream IDs. However, once it has requested and been given a stream, it can retrieve the ID of that stream and use it to reference the stream at the application layer. By the same token, the application layer shouldn't assume it understands the relationship between stream types and Stream IDs; that may change in a future QUIC version, and it should rely on querying the stream properties to identify types.
Actually writing these constraints/assumptions down would be nice. Can you try to create a PR, NAME ?
That captures it.

application to make the mapping of data to streams dependent on this information.  <ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way in which they are assigned. </ins> 4.1.


13.  This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 14. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 15. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

I updated the text of the second paragraph. If people could have another look that would be welcome. But I believe we are ready to merge (after the meeting).
So far we don't mention any extension in the ops drafts, however, datagrams actually require a different interface and as such are important for an application to know about, therefore, I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC.
Agreed, mentioning datagram seems very useful.

13. <ins> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC connection. 14. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations.  <ins> 15. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well.  <ins> 16. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture


If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by <del> the receiver.  Therefore it can be valuable to expose the maximum number of allowed, currently open, and currently used streams to the application to make the mapping of data to streams dependent on this information. </del>  QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream

The proposed wording makes sentence stronger, more list a SHOULD requirement. Therefore we wanted to check with others before we merge.
Seems simpler and clearer. I don't see this as normative.

If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by  <ins> the receiver.  Therefore, an application can use the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams. </ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream


identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection <del> ID with a given flow, and can associate a known flow with a new flow when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. </del>  However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is

This is branched of . NAME said: "However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty."
NAME I created PR . Does that address this point sufficiently?

identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection  <ins> ID, if present, with a given flow, and can associate a known flow with a new flow when when observing a packet sharing the same connection ID in the same direction between client and server and sharing one endpoint address (IP address and port) with the known flow. </ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is


difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and <del> network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </del>  Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If

I don't think this sentence was accurate. TFO isn't analogous to 0-RTT session resumption, but it's needed to achieve the same application effect.
maybe analogous wasn't the right term but I'm also not sure about the word "true" here...
NAME "true" meaning "actual", i.e. you can resume a session without a round trip. We could specify that further but it probably has to be more wordy.

difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and  <ins> network paths often do not support the Fast Open option RFC7413, which enables sending of payload data together with the first control packet of a new connection as also provided by 0-RTT session resumption in QUIC.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to- end, it is limited to a single packet of TLS handshake and application data, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If


stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually <del> reset the QUIC connection. </del>  Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general

Reset is a directional stream semantic, not a connection one.
Actually the idea here was not necessarily talk about the semantics of how a connection is closed. So maybe using something else like "abort" would avoid any confusion here...?
Oh, I see. Yeah maybe abort is better. For me reading this "reset" made me think of TCP connection and or QUIC stream semantics, which is probably not the intention.

stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually  <ins> terminate the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general


least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. <del> QUIC probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </del>  Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

addresses
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
Phrasing suggestion.

least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact.  <ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to


depending on application requirements. RFC4787 requires a timeout that is not less than 2 minutes for most <del> UDP traffic.  However, in pratice, timers are often lower, in the range of 15 to 30 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well-defined closure semantics.  For network devices that are QUIC-aware, it is recommended to also use longer timeouts for QUIC traffic, as QUIC is connection-oriented.  As such, a handshake packet from the server indicates the willingness of the server to communicate with the client. </del>  The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC

This PR replaces (while retaining the semantics of all of its changes); no longer merges due to major changes to the NAT and Connection ID text.
as well
Should RFC7857 also be cited? (NAT update BCP) Should RFC4787 also be cited? (behaviour for UDP NAT)
Not sure. We cite RFC4787 in the manageability doc. In this doc we refer to RFC8085 instead which then refers to RFC4787. I'd say that's about right. However, I'm open to add more information if people think that's helpful. If so, what more do we need to say where?
In 3.5 the ID currently states: " According to a 2010 study ([Hatonen10]), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity." Whereas in RFC 4787 (BCP) Requirement 6 states: " REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies. a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port. b) The value of the NAT UDP mapping timer MAY be configurable. c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED." I suggest we directly refer to this RFC before or after the above sentence, before the ID then continues in the next sentence to discuss the topic of keep alive (aka RFC8085).
There was always a reference to RFC4787. Text is >{{?RFC4787}} requires a timeout that is not less than 2 minutes for most UDP traffic. However, in pratice, timers are often lower, in the range of 15 to 30 seconds. What else should be added?
I suggested changing the latter from "15 to 30 seconds" to "30 seconds to 1 minute," or something like Gorry's quote: "According to a 2010 study ([Hatonen10]), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity."
When I review "experience" reported in OPS drafts, I usually try to avoid wording that might convey the IETF endorses the reported behaviour, rather than be aware of the reported behaviour. I suggest this is one of these cases. So suggest a style something like: {{?RFC4787}} requires a timeout that is not less than 2 minutes for most UDP traffic. However, protocols traversing NATs should be aware of systems using lower values, in the range of 15 to 30 seconds. A study in 2010 study ([Hatonen10]), reported that UDP applications can experience that NAT binding or other state entries expire after just thirty seconds of inactivity.
There is new proposed text on this part in PR - Can review and comment any proposed changes there...? NAME NAME
Sect 4.8: Reducing the timeout on UDP NATs “Reducing the timeout on UDP NATs might be tempting in light of this property, but not all QUIC server deployments will be robust to rebinding.” so now, I did not understand what was being discouraged here. Is this somehow linked to section 4.6’s discussion of holding state? (perhaps related to issue )
Yes, this is connected to the advise in section 4.1 but I agree this could be clarified. NAME can you have a look at this?
I can certainly write up something here, but I think we should decide what the actual guidance is before I write it. The NAT UDP timeout is traditionally short; should it be (1) even shorter; (2) remain the same; or (3) become longer? A legacy NAT that is not parsing QUIC headers at all can probably leave the timeout as it is; QUIC should be pretty robust to NAT rebindings for several reasons, and we don't want to mess with existing UDP flows. Maybe my "don't use connection ID at all" guidance has an exception? A QUIC-aware NAT that detects QUIC via a consistent CID field could use a even shorter timeout. But ultimately we're somewhat stuck by "QUIC is robust to NAT rebinding but sometimes it isn't." So I would propose that we recommend that UDP timeouts remain the same. I could be convinced that NATs could reduce the timeout even further if they're reasonably sure the flow is QUIC. What do people think?
There is also text about NAT time-outs in section 4.8 (see also issue ), recommending a longer timeout than UDP. If this recommendation is not right, please comment there. I was pinging you (NAME because you wrote the sentence cited here and wanted to see if we can actually better align it with section 4.8.
Shorter NAT timeouts hurt applications where either side can initiate communication, since once the NAT times out, only one side can initiate communication. Hanging GETs are the typical example in HTTP, but I expect this could be a much larger issue in non-HTTP use cases. The only solution is to send packets(ie: PINGs) to keep the NAT active. I think 2 minutes is reasonable. Expecting anything longer without some explicit endpoint-to-path signaling seems overly optimistic to me, but I could be wrong.
NAME I agree the language is inconsistent and I am happy to write it up. I would just like clear consensus on what it should say. I'm registering NAME 's comment as "keep the UDP timeout as it is"
If you look at section 4.1., the problem is that RFC4787 says MUST NOT be less than 2 minutes but in reality it's usually only 30 or 15 seconds. So I think Ian says 2 (or more) minutes are fine but only 30 sec as often used for UDP is not. Therefore I think it's important to make the point that will with QUIC is even more reasonable to use 2 minutes or more because it's connection-oriented and you can be sure that when you see the handshake from both ends that those ends are actually trying to have a valid communication. Please note that I also have created PR to align the language correctly to RFC4787 in section 4.1.. So if you want to change something in section 4.1. please use as starting point.
I agree with NAME point that for QUIC it's even more reasonable to actually use at least 2 minutes because it's connection-oriented. I don't have any evidence the timeout is commonly under 30 seconds, but it is commonly less than 2 minutes. We have seen extremely short timeouts, and it's believed these are NATs that are running close to saturation so the idle timeout shrinks very low. But it's hard to know for sure.
OK so the message here is, "yes QUIC is 'robust' to NAT rebinding but still don't reduce the timeout." This might be sound advice, but it seems like a bit of waste given our effort surrounding NAT rebinding. I have to think about this some more, but I suppose whatever value we recommend here turns into an effective bound on the QUIC idle timeout in real deployments. I'll just wait till lands to make changes.
It would seem OK to motivate suggesting an increase in the NAT timeout, but saying this is "because it's connection-oriented" ... isn't really enough. Other UDP protocols can also be connection oriented and they might also have observable closing packets - to release the NAT state under normal usage. I think the rationale just needs a little explanation, perhaps in terms of the benefits to QUIC of a larger NAT timeout.
I am happy to take this issue but am glad that NAME put this on the agenda to discuss. I guess I'll wait till after 110 to write a PR?
no, if you can propose some concrete text that would be helpful for the meeting. It's only that we won't merge before the meeting.
I am not sure about NAME 's concerns about one endpoint being blocked from restarting the connection. Having throught it through more, I'll make these assertions: There is a tension between the most endpoint-friendly choice (infinite timeouts!) and what implementers are actually willing to do. A ridiculous requirement is likely to be ignored, so being as generous as possible, given QUIC's salutary features, would be wise. Given how hard we've made it for intermediaries, it would be good internet citizenship to give them something that makes their lives easier if it doesn't compromise performance or privacy. We really do need to make sure that (UDP timeout > 3 PTO) for all plausible PTO values, as this is the minimum idle timeout. NAME problem is arguably solved by judicious use of the idle timeout. If we set a reasonably low recommended idle-timeout for clients and servers (which can be different!), and put the recommended UDP timeout above that value, a few things happen: (a) the server can discard state relatively quickly (b) if the server can't handle NAT rebinding, it can set an aggressive idle-timeout (c) in general, it's the client that will try to keep connections alive (d) the client will be aware of the minimum of the two timeouts -- if they want the connection to survive, they will send PINGs when necessary according to 10.1 of quic-transport. (e) IIUC, both client-side and server-side NAT/Firewalls will accept "new" connections if initiated by the client. So I'm recommending the following: The "intermediary UDP timeout" should be the smallest possible value that is always > 3PTO. Someone tell me what the number is! 10 seconds? Clients should set an idle-timeout value that is a bit less than the recommended intermediary UDP timeout unless they are sure they aren't behind a NAT. Servers should set an idle-timeout according to the following principles: (a) if known to not be robust to rebinding (i.e load balanced without QUIC-LB), just below the intermediary UDP timeout. This is true whether the server knows if it is behind a NAT or not (b) otherwise, use any value you want Thoughts? If people agree with this logic, I'll revise the PR or write another one.
I disagree with your suggestion of recommending a NAT timeout smaller than 2 minutes. I'd prefer something along the lines of NAME previous suggestion of really try to use 2 minutes and we can add text about how clients will have to use PINGs if the timeout is too short, if that's helpful. 5 minute long hanging GETs are a common thing today, and WebTransport may make the case where either side initiates communication more common. Longer timeouts aren't hard, they just require state. Special cases for QUIC are more difficult. This is not always good for either application performance or CPU(ie: more handshakes). Agreed, but that's not my concern as much as the server's inability to contact the client. The client doesn't know what the NAT timeout is, which seems like the important thing here. I'm not sure what you mean by server-side NAT/Firewalls? There's no max to PTO, so 3PTO is technically an infinite value. But if you're assuming typical RTTs on the existing internet with a max in the seconds, it's ~9 RTT. 2g has an RTT in the 2 second range, so if we assume RTTs above 4 seconds are uncommon, then you'd be recommending 36 seconds.
Sure, my language was imprecise. The model here is that we propose a standard NAT timeout that they can live with it, and clients can set idle-timeouts based on the assumption that NATs are following it. I'm referring to things devices in the server infrastructure that rewrite the source address and port on inbound packets to make sure all outbound packets are routed correctly. I understand. Although I'm not going to insist on this, a standard on the order of 30-45 seconds would meet the objective quite well.
Sect 4.1 : This contains a statement on the recommendations for middleboxes and NATs, that I can’t understand, and this concerns me. i.e. to me, the present text suggests that the advice in BCP 127 (aka RFC4787) should be changed for QUIC. I don’t recall this being discussed - was it? I don’t actually follow the rationale that says this follows from QUIC being connection-oriented. If the connection close was visible to the device, and it could release state - then this might make sense, but that isn’t exactly what is explained. I’m left unsure how a “QUIC-aware” middlebox is supposed to track this state. I'm also unsure how say a NAPT could know the traffic was QUIC, is this suggesting a port-based change. I think I need to understand this proposal.
Actually we don't change the recommendation of RFC4748 as it says "A NAT UDP mapping timer MUST NOT expire in less than two minutes" However, we cite this wrongly, which is now addressed in PR . The reason for recommending longer time-outs for QUIC is because you can be sure that there is handshake and the other end did confirm its willingness to communicate. Of course having a stopping indication would be better but we don't have it. We don't recommend a specific value, nor do we say one should use equally long timers as for TCP. However, given you know there is valid communication on-going between the two peers a longer timer (of at least a couple if minutes) would probably be useful in a lot of cases. Do we need more text here? NAME do you want to propose something? Or should I? Otherwise we can also discuss this at the next meeting!
Some suggestions, but overall quite good.

depending on application requirements. RFC4787 requires a timeout that is not less than 2 minutes for most  <ins> UDP traffic.  However, in practice, timers are sometimes lower, in the range of 30 to 60 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection- oriented protocol with well- defined closure semantics. Even though QUIC has explicitly been designed tolerate NAT rebindings, decreasing the NAT timeout is not recommended, as it may negatively impact application performance or incentivize endpoints to send very frequent keep-alive packets.  Instead it is recommended, even when lower timers are used for other UDP traffic, to use a timer of at least two minutes for QUIC traffic. While QUIC has no clear network-visible end-of-connection signal and therefore does require timer-based state removal, the QUIC handshake indicates confirmation by both ends of a valid bidirectional transmission.  If state is removed too early, this could lead to black-holing of incoming packets after a short idle period.  To detect this situation, a timer at the client needs to expire before a re-establishment can happen (if at all), which would lead to unnecessary long delays in an otherwise working connection. Furthermore, not all endpoints use routing architectures where connections will survive a port or address change.  So even when the client revives the connection, a NAT rebinding can cause a routing mismatch where a packet is not even delivered to the server that might support address migration.  For these reasons, the limits in RFC4787 are important to avoid black-holing of packets (and hence avoid interrupting the flow of data to the client), especially where devices are able to distinguish QUIC traffic from other UDP payloads. </ins> The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC


default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP.  Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the <del> "h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </del>  Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of

First stab;
Sorry I missed this during the WGLC. URL contains a lot of good stuff but it seems like it could say more about ALPN. 1) As an editorial comment ALPN is mentioned without expanding the acronym. The term is used, which doesn't seem to be defined anywhere other than the HTTP/3 specification (which might be a problem or not) 2) More substantial, there isn't really mention about any of the TLS or negotiation aspects of ALPN. We might see people try to offer multiple Application Protocols on the same UDP port, and using ALPN to select from them. Maybe this is more likely when QUIC can operate as both a stream-based and datagram-based protocol. 3) Related to 2, new application protocols over QUIC need an ALPN protocol identifier. This is distinct from the Alt-Svc discussion in Section 6; since other protocols won't use Alt-Svc, they might overlook things. The ALPN space is large but we might benefit from some text that gives people pointers on how to register the ALPN IDs they want to use before someone gets them. For reference, I started a list of protocols at URL Not all of those need formal registration but it is a nice illustration.
I'm unfortunately not coming up with some useful/actionable text here. Maybe NAME or NAME has some insight that could help?
It feels like the best way to incorporate this is to expand the "protocol doesn't imply port" discussion to also include "port doesn't imply protocol" before concluding with "not being able to safely make this inference is hard." has a first stab at this, though it doesn't cover as much as NAME first suggested. Feel free to expand on it.

default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <ins> Additionally, Application-Layer Version Negotiation RFC7301 permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered. Applications using QUIC should register an ALPN token for use in the TLS handshake. </ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the  <ins> "h3" ALPN token.  Note that HTTP/3's ALPN token ("h3") identifies not only the version of the application protocol, but also the version of QUIC itself; this approach allows unambiguous agreement between the endpoints on the protocol stack in use. </ins> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of


streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as <del> those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </del>  Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data

for signaling priority, such as those defined for HTTP/2 First, if we retain this comment, it should probably have a reference to RFC 7540 and the appropriate section. However, as NAME noted in reply to a previous issue, this document is about QUIC, not TCP; the use of HTTP/2 as an exemplar seems out-of-place, particularly since we're actively deprecating that priority scheme. Perhaps a reference to draft-ietf-httpbis-priority would be more appropriate?
I agree that a reference to draft-ietf-httpbis-priority would be more appropriate.
Yes, sounds good. I'll create a PR if no-one else does it before me.

streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as  <ins> those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </ins> Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data


Today, UDP is the most prevalent DDoS vector, since it is easy for compromised non-admin applications to send a flood of large UDP packets (while with TCP the attacker gets throttled by the congestion <del> controller) or to craft reflection and amplification attacks. Networks should therefore be prepared for UDP flood attacks on ports used for QUIC traffic.  One possible response to this threat is to police UDP traffic on the network, allocating a fixed portion of the network capacity to UDP and blocking UDP datagram over that cap. The recommended way to police QUIC packets is to either drop them all or to throttle them based on the hash of the UDP datagram's source and destination addresses, blocking a portion of the hash space that corresponds to the fraction of UDP traffic one wishes to drop.  When the handshake is blocked, QUIC-capable applications may failover to TCP (at least applications using well-known UDP ports).  However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer from severe packet loss. </del>  4.7.

and
Comment from NAME from PR on UDP Policing about this phrase: "The extra words don't really help here. If anything, you need to highlight the need to block only a subset of addresses rather than a subset of packets."
I'd like to question whether arbitrarily applying a limit to UDP flows is a sensible recommendation over the coming years. QUIC will dominate internet traffic (I will estimate 85% or more, by bandwidth, mainly due to HTTP/3). In that end state what is the protective value of setting a ceiling on the amount of UDP? Yes it permits continuation of service for some during an unmitigated UDP DDoS, if they can switch to TCP. But in the presence of active mitigation, perhaps a limit is unwise?
This document is not at all recommending to set such a limit. It's just saying that if you really think you need that limit, here is the way to do it right. However, maybe we should be more clear that this is not a recommendation for such a limit.
Proposed some wording updates in
Comment from PR from NAME on UDP policing: "This is recommending something that relies on the 4-tuple, but particularly if there's another NAT involved, the 4-tuple may not be stable. So this puts connections in a situation where the handshake completes, they use the connection for a bit, a NAT rebind occurs, and then the connection is blackholed. There are defenses against this problem, but this seems like a fairly dangerous recommendation."
NAME said in PR on the section title "UDP Policing": "Policing has a slightly different meaning(token bucket policer) that's widely used, so can we find a different term in this context?"
Looks like will resolve this.
Yes, is supposed to resolve this. Not sure why this is not correctly linked...
is merged
You should really cite the port avoidance prior art: avoid-v4-udp-ports. bind9 implemented this in which was implemented to avoid the problems that occurred after UDP/1434 was filtered by providers in response to the SQL Slammer attacks and the long term filtering that was left in place after this. Is there a described technique or measurement to determine what ports may be problematic? Many operators have had to mitigate the damage of UDP based protocols on their networks and in attempt to limit the impact to well behaving ports and protocols deployed things in a limited scope, eg: URL URL Large and small network operators are known to block or restrict ports and protocols due to the impact. Akamai also has this implemented at our network edge in some locations today. We have seen other protocols, eg: NTP start to move from 123 123 communication eg: draft-ietf-ntp-port-randomization which will face similar issues. Is there a way to provide feedback of what ports may be limited or should be avoided? How would an operator signal or configure this?
Currently most QUIC implementations are HTTP/3 and therefore use the https port 443. However QUIC is a general purpose transport protocol and therefore future application will likely use different ports. Also ports are not really meaningful to identify applications and as such I don't think there is any good advise we could give here. Or what are you missing? Can you maybe propose text? Please also note that PR proposes a (mostly) editorial update of this section.
NAME can we close this issue?
I think this is a very interesting question, but it's a bit outside the scope of this document (as a user's manual for the wire image)...
At your own peril I guess. The question here of how this protocol will work long distance on networks that have had to deal with abusive applications is still a going concern. I'll review the changes that went in via but ignoring how other UDP based applications have had to avoid ports but doing it at a protocol level will result in poor performance for some flows. network operators deployed these only after the pain from the protocol and application users reached a tipping point where it was no longer feasible to operate a network without these protections. It's unclear to me how this transport will work reliably as more ports are likely to be added to operator policers over time.
I agree with Brian and Mirja. This is an interesting question but since there is no single port number for the QUIC transport, I find that the question verges into an applicability / deployment concern. We (the QUIC WG) don't really have a document that covers that aspect of things today and I don't think we have enough experience with QUIC deployments to write an answer to the question yet. If the market figures out that, for example, any port other that UDP 443 is slow, then that seems an ok outcome while we figure things out. There is no transport-level mechanism defined by QUIC for service discovery. QUIC requires Application Protocol Layer Negotiation (ALPN) be used when opening a connection, so listening applications can share the same port number and dynamically dispatch QUIC flows based on the selected application. The reduces some of the concerns about QUIC-based applications competing for UDP numbers.
Generally speaking, this is OK. I have a few suggestions however.

Today, UDP is the most prevalent DDoS vector, since it is easy for compromised non-admin applications to send a flood of large UDP packets (while with TCP the attacker gets throttled by the congestion  <ins> controller) or to craft reflection and amplification attacks.  Some networks therefore block UDP traffic.  With increased deployment of QUIC, there is also an increased need to allow UDP traffic on ports used for QUIC.  However, if UDP is generally enabled on these ports, UDP flood attacks may also use the same ports.  One possible response to this threat is to throttle UDP traffic on the network, allocating a fixed portion of the network capacity to UDP and blocking UDP datagrams over that cap.  As the portion of QUIC traffic compared to TCP is also expected to increase over time, using such a limit is not recommended but if done, limits might need to be adapted dynamically. Further, if UDP traffic is desired to be throttled, it is recommended to block individual QUIC flows entirely rather than dropping packets randomly.  When the handshake is blocked, QUIC-capable applications may failover to TCP However, blocking a random fraction of QUIC packets across 4-tuples will allow many QUIC handshakes to complete, preventing a TCP failover, but the 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 policing should be stateless to avoid problems with stateful treatment of QUIC flows (see sec-stateful), for example blocking a portion of the space of values of a hash function over the addresses and ports in the UDP datagram.  While QUIC endpoints are often able to survive address changes, e.g. by NAT rebindings, blocking a portion of the traffic based on 5-tuple hashing increases the risk of black-holing an active connection when the address changes. </ins> 4.7.


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, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del>  4.3.

NAME said in PR on section "Passive Network Performance Measurement and Troubleshooting": "I think the caution against using Connection ID needs to be a lot stronger. Things will break, users will notice. I realize that implementations have to use this to enforce that, but I believe some already are. See a comment below as well."
NAME is PR better? Note that you should also review the previous paragraphs as I believe the problems are described there clearly already.

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-  <ins> filtering), which potentially triggers a fallback to TCP.  Use of the 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. </ins> 4.3.


handshake packet from the server indicates the willingness of the server to communicate with the client. <del> The QUIC header optionally contains a connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the connection ID is present and what length it has.  However, connection IDs may be renegotiated during after the handshake, and this renegotiation is not visible to the path.  Using the connection ID as a flow key field for stateful treatment of flows may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  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-filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del>  4.3.

Comment from PR from NAME on UDP policing: "This is recommending something that relies on the 4-tuple, but particularly if there's another NAT involved, the 4-tuple may not be stable. So this puts connections in a situation where the handshake completes, they use the connection for a bit, a NAT rebind occurs, and then the connection is blackholed. There are defenses against this problem, but this seems like a fairly dangerous recommendation."
LG, some editorial comments.

handshake packet from the server indicates the willingness of the server to communicate with the client.  <ins> The QUIC header optionally contains a connection ID which could provide additional entropy beyond the 5-tuple.  The QUIC handshake needs to be observed in order to understand whether the connection ID is present and what length it has.  However, connection IDs may be renegotiated after the handshake, and this renegotiation is not visible to the path.  Therefore using the connection ID as a flow key field for stateful treatment of flows is not recommended as connection ID changes will cause undetectable and unrecoverable loss of state in the middle of a connection.  Specially, the use of the connection ID for functions that require state to make a forwarding decison is not viable as it will break connectivity or at minimum cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. QUIC endpoints support address migration and a QUIC connection can survive a change of the IP address or ports by mapping the connection ID, if present, to an existing connection.  Ideally a new connection ID is used at the same time when the address/port changes to avoid linkability.  As new connection IDs belonging to the same connection are not known to on-path devices, network devices are not able to map QUIC connections after a 4-tuple change.  As such, when the 4-tuple changes, stateful devices lose their state and break connectivity if state is required for forwarding, while the endpoints would otherwise survive such a change. 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- filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </ins> 4.3.


QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection. <del> Server-generated connection IDs should seek to obscure any encoded routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the connection ID in the connection ID itself, instead of remembering it. QUIC_LB further specifies possible algorithms to generate connection IDs at load balancers. </del>  2.7.

repeats requirements from the transport spec unnecessarily. It might be easier to just strike this.
This is supposed to give advice to network operators e.g. in a load balancing setup where connection IDs are maybe generated centrally and distributed to the servers.
The surrounding text does. This paragraph does not.
I didn't think network operators who are in control of one of the endpoints would be considered in scope for this I-D. Surely the whole point is to advise network operators about what they should do with traffic they cannot hope to decrypt? If server endpoint operators are in scope, the Introduction should be revised. If they are not in scope, I could propose some words that essentially say "Don't bother trying to infer information from specific parts of the connection ID, for these reasons."
Okay, I think I see the problem now. Is better?
This is fine, but it presumes a lot about the outcome of things that aren't completely resolved in QUIC-LB. I think that I would like to see more of this left to QUIC-LB to deal with, especially if we are planning to publish this before QUIC-LB (which seems likely). That might mean being a lot more aggressive about cutting text here.

QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection.  <ins> QUIC_LB specifies algorithms for encoding the server mapping in a connection ID in order to share this information with selected on- path devices such as load balancers.  Server mappings should only be exposed to selected entities.  Uncontrolled exposure would allow linkage of multiple IP addresses to the same host if the server also supports migration which opens an attack vector on specific servers or pools.  The best way to obscure an encoding is to appear random to any other observers, which is most rigorously achieved with encryption.  As a result any attempt to infer information from specific parts of a connection ID is unlikely to be useful. </ins> 2.7.


Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If <del> TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </del>  In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not

I couldn't immediately parse, and I'm assuming this is a NiT, but I can always be surprised by nuances in security-related text, so I'm writing this as an issue: /If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable./ If TLS over TCP cannot be supported, the connection should be aborted, and the application should present a suitable prompt to the user that secure communication is unavailable./
I guess we can remove the "instead" but why did you change the "in order to"? The reason to abort instead of just moving on without security is, so that the application recognises and can tell the user.
NAME ?
OK on removing instead Is this better?: /If TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable./

Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If  <ins> TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable. </ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not


4.7. <del> Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, and then differential treatment of this traffic to forward only good traffic.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Key to successful DDoS mitigation is efficient classification of this traffic in the mitigation environment.  Limited first-packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </del>  Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT <del> rebinding, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </del>  4.8.

thanks NAME for the text.
talks at length about detecting and mitigating against (D)DoS attacks, but this is written with the assumption of an uncooperative endpoint (likely to be, but unstated, a server). All except the Retry text where the design specifically forces interventions to be cooperative. It is entirely reasonable for DoS classification to be done with full knowledge of valid connection IDs or at least valid connection ID lengths. If you allow for cooperation, the text might then explain how this might allow established flows to be separated from spoofed flows and new connection attempts.
+1 Perhaps either approach could be reasonable depending on the specific case? - Which DoS/DDoS mitigation fits best for an enterprise/user might vary depending on many things - including the role played by the endpoint and who controls the network and devices.
Can someone propose text?
In the last paragraph, it may be worth mentioning the 3x amplification limit during the handshake as well. Post-handshake DoS/DDoS is usually an application-level property which could affect TCP as much as QUIC, so the whole 5-tuple/CID aspect seems like it could be ignored commonly post-handshake. Is there a DoS expert we could ask to look at this text to see if it made sense, since I worry none of us are that person?
NAME with TCP, the handshake could be completed by the DDoS "classification" engine without passing a bit of an information to the endpoint. That's called "SYN proxying". That was, uh, a cool feature since otherwise the endpoint would've been flooded by handshake attempts. Even though TCP wasn't cooperating, this feature was powerful enough to allow to build an impenetrable DDoS mitigation infrastructure. Please see also .
I was thinking of something a little like this (and can make a PR if this is heading in a useful direction: "On-path observation of the transport headers of packets can be used for various security functions. For example, Denial of Service (DOS) and Distributed DOS (DDOS) attacks against the infrastructure or against an endpoint can be detected and mitigated by characterising anomalous traffic. Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions. When using an encrypted transport, it is possible for endpoints to directly support these security functions; another method could use an on-path network device that relies on pattern inferences in the traffic and heuristics or machine learning instead of processing observed header information." Thoughts?
I think this text still doesn't address MT's original point fully - that an endpoint could even cooperate with an on-path device directly by e.g. sharing information about connection IDs.
Yes. Would happily add that the endpoint can "cooperate with an on-path device directly by e.g. sharing information about connection IDs". Is there more?
Re: NAME comment above: SYN proxying won't work in QUIC for the obvious crypto reasons, but a related approach that dynamically starts sending Retry over a certain rate limit might be almost as good. Retries are already partially covered in section 4.7. In this regime one could also drop 0RTT packets. Is this something it'd make sense to add to this document, or in QUIC-LB instead?
I don't like where this was taken. As NAME said, it is not responsive to my comments about cooperation. It still firmly assumes that DoS mitigation is being performed without cooperation from endpoints. That might be unavoidable for good reasons, but we should be clearer about the consequences of that AND we should recommend that DoS mitigation be performed with cooperation from endpoints.

4.7.  <ins> On-path observation of the transport headers of packets can be used for various security functions.  For example, Denial of Service (DOS) and Distributed DOS (DDOS) attacks against the infrastructure or against an endpoint can be detected and mitigated by characterising anomalous traffic.  Other uses include support for security audits (e.g., verifying the compliance with ciphersuites); client and application fingerprinting for inventory; and to provide alerts for network intrusion detection and other next generation firewall functions. Current practices in detection and mitigation of DDoS attacks generally involve classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic, and then differential treatment of this traffic to forward only good traffic.  This operation is often done in a separate specialized mitigation environment through which all traffic is filtered; a generalized architecture for separation of concerns in mitigation is given in DOTS-ARCH. Efficient classification of this DDoS traffic in the mitigation environment is key to the success of this approach.  Limited first- packet garbage detection as in sec-garbage and stateful tracking of QUIC traffic as in sec-stateful above may be useful during classification. </ins> Note that the use of a connection ID to support connection migration renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT  <ins> rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can cooperate with an in-network device directly by e.g.  sharing information about connection IDs. Another potential method could use an on-path network device that relies on pattern inferences in the traffic and heuristics or machine learning instead of processing observed header information. However, it is questionable whether connection migrations must be supported during a DDoS attack.  However, for unintentional mitigations, as is usually the case for NAT rebindings, the connection ID can be used to track connections (see sec-flow- association).  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state.  However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.8.


examine each of the datagrams in detail. The QUIC handshake can normally be recognized on the wire through at <del> least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in fig-handshake. </del>  Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello. <del> A typical handshake starts with the client sending of a QUIC Client Hello datagram as shown in fig-client-hello, which elicits a QUIC Server Hello datagram as shown in fig-server-hello typically containing three packets: an Initial packet with the Server Hello, a Handshake packet with the rest of the server's side of the TLS </del>  handshake, and initial 1-RTT data, if present. <del> The Initial Completion datagram contains at least one Handshake packet and some also include an Initial packet. </del>  <del> Datagrams that contain a QUIC Initial Packet (Client Hello, Server Hello, and some Initial Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial </del>  packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used. <del> The content of QUIC Initial packets are encrypted using Initial </del>  Secrets, which are derived from a per-version constant and the client's destination connection ID; they are therefore observable by any on-path device that knows the per-version constant.  They are Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The <del> Initial Completion fig-init-complete and the Handshake Completion fig-hs-complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. </del>  <del> The Client Hello datagram exposes version number, source and </del>  destination connection IDs without encryption.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  Note that the location of PADDING is implementation-dependent, and PADDING frames might not appear in a coalesced Initial packet. <del> The Server Hello datagram also exposes version number, source and </del>  destination connection IDs in the clear; information in the TLS Server Hello message is obfuscated using the Initial secret. <del> The Initial Completion datagram does not expose any additional </del>  information; however, recognizing it can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt. <del> Similar to Initial Completion, Handshake Completion also exposes no </del>  additional information; observing it serves only to determine that the handshake has completed. When the client uses 0-RTT connection resumption, 0-RTT data may also <del> be seen in the QUIC Client Hello datagram, as shown in fig-client- hello-0rtt. In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Hello datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, </del>  typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). 2.5.

least four datagrams we'll call "QUIC Client Hello", "QUIC Server Hello", and "Initial Completion", and "Handshake Completion", for purposes of this illustration, as shown in {{fig-handshake}}. I mean, you can call them that for reference purposes, but there's no such thing as a "QUIC Client Hello" (or ClientHello). Calling something "Initial Completion" when it might not contain any Initial packets might confuse people when they go looking for more details. Maybe "Client Initial," "Server Initial," "Client Finished," and "Server Finished"? It mixes layers, but those are at least things that occur in the referenced packets.
Or, to avoid using TLS message names consistently, s/Finished/Confirmation
Should I conclude from the absence of comment since February that we are all reasonably content with "Client Initial", "Server Initial", "Client Completion", and "Server Completion"? If so I'm happy to create the PR to save Brian a job. But I don't want to do that if these are not the best names.
This was assigned to Brian has he wanted to take a stab.
That's fine I'll leave it to Brian.

examine each of the datagrams in detail. The QUIC handshake can normally be recognized on the wire through at  <ins> least four datagrams we'll call "Client Initial", "Server Initial", and "Client Completion", and "Server Completion", for purposes of this illustration, as shown in fig-handshake. </ins> Packets in the handshake belong to three separate cryptographic and transport contexts ("Initial", which contains observable payload, and its Client Hello, and the server can send 1-RTT data as soon as it has sent its Server Hello.  <ins> A typical handshake starts with the client sending of a Client Initial datagram as shown in fig-client-initial, which elicits a Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the Server Initial, a Handshake packet with the rest of the server's side of the TLS </ins> handshake, and initial 1-RTT data, if present.  <ins> The Client Completion datagram contains at least one Handshake packet and some also include an Initial packet. </ins>  <ins> Datagrams that contain a Client Initial Packet (Client Initial, Server Initial, and some Client Completion) contain at least 1200 octets of UDP payload.  This protects against amplification attacks and verifies that the network path meets the requirements for the minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This is accomplished by either adding PADDING frames within the Initial </ins> packet, coalescing other packets with the Initial packet, or leaving unused payload in the UDP packet after the Initial packet.  A network path needs to be able to forward at least this size of packet for QUIC to be used.  <ins> The content of Client Initial packets are encrypted using Initial </ins> Secrets, which are derived from a per-version constant and the client's destination connection ID; they are therefore observable by any on-path device that knows the per-version constant.  They are Initial, Handshake, and the Short Header packets transmitted after the handshake belong to cryptographic and transport contexts.  The  <ins> Client Completion fig-init-complete and the Server Completion fig-hs- complete datagrams finish these first two contexts, by sending the final acknowledgment and finishing the transmission of CRYPTO frames. </ins>  <ins> The Client Initial datagram exposes version number, source and </ins> destination connection IDs without encryption.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  Note that the location of PADDING is implementation-dependent, and PADDING frames might not appear in a coalesced Initial packet.  <ins> The Server Initial datagram also exposes version number, source and </ins> destination connection IDs in the clear; information in the TLS Server Hello message is obfuscated using the Initial secret.  <ins> The Client Completion datagram does not expose any additional </ins> information; however, recognizing it can be used to determine that a handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt.  <ins> Similar to Client Completion, Server Completion also exposes no </ins> additional information; observing it serves only to determine that the handshake has completed. When the client uses 0-RTT connection resumption, 0-RTT data may also  <ins> be seen in the Client Initial datagram, as shown in fig-client- initial-0rtt. In a 0-RTT Client Initial datagram, the PADDING frame is only present if necessary to increase the size of the datagram with 0RTT data to at least 1200 bytes.  Additional datagrams containing only 0-RTT protected long header packets may be sent from the client to the server after the Client Initial datagram, containing the rest of the 0-RTT data.  The amount of 0-RTT protected data that can be sent in the first round is limited by the initial congestion window, </ins> typically around 10 packets (see Section 7.2 of QUIC-RECOVERY). 2.5.


classification. Note that the use of a connection ID to support connection migration <del> renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </del>  It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can learning instead of processing observed header information. However, it is questionable whether connection migrations must be <del> supported during a DDoS attack.  However, for unintentional mitigations, as is usually the case for NAT rebindings, the connection ID can be used to track connections (see sec-flow- association).  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del>  Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS

We recently added this sentence but the text two paragraphs up already says this. Here is my proposed change, however, maybe we can shorten this paragraph even further.

classification. Note that the use of a connection ID to support connection migration  <ins> renders 5-tuple based filtering insufficient to detect active flows and requires more state to be maintained by DDoS defense systems if support of migration of QUIC flows is desired.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </ins> It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can learning instead of processing observed header information. However, it is questionable whether connection migrations must be  <ins> supported during a DDoS attack.  While unintended migration without a connection ID change can be more easily supported, it might be acceptable to not support migrations of active QUIC connections that are not visible to the network functions performing the DDoS detection.  As soon as the connection blocking is detected by the client, the client may be able to rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS


4.5. RFC4787 describes possible packet filtering behaviors that relate to <del> NATs.  Though the guidance there holds, a particularly unwise </del>  behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at

These two sections are slightly redundant, and could easily be merged because the advice they give is more or less identical.
I think better to group these two! The current filtering text describes "possible packet filtering behaviors that relate to NATs". I suggest an initial series of packet ALSO traverse other domain edge devices (such as DDOS detection, NIDS, etc) in the same way, so we should be clear that NAT/NAPT is an example:-)
discussion on 19 April editor's meeting: there's been a lot of minor editorial refactoring that improves the flow of the doc, making this merge less necessary. Still need to make sure we have examples other than NAT, though.
multiple-examples fixed in

4.5. RFC4787 describes possible packet filtering behaviors that relate to  <ins> NATs but is often also used is other scenarios where packet filtering is desired.  Though the guidance there holds, a particularly unwise </ins> behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at


QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line <del> blocking between streams, associated at a point in time with a single five-tuple.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </del>  Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a

It is sort of redundant (because it says connection) and maybe sort of misleading (QUIC connections only use a single 5-tuple at a time, so it is maybe correct, but also maybe not).

QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line  <ins> blocking between streams.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </ins> Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a


of allowed, currently open, and currently used streams when determining how to map data to streams. <del> QUIC assigns a numerical identifier to each stream, called the Stream </del>  ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, <del> the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream </del>  ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, <del> HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way </del>  in which they are assigned Section 6 of QUIC-HTTP). 4.1.

This is the editorial convention we adopted for connection ID and what the RFC editor correctly inferred also.

of allowed, currently open, and currently used streams when determining how to map data to streams.  <ins> QUIC assigns a numerical identifier to each stream, called the stream </ins> ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional,  <ins> the stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the stream </ins> ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example,  <ins> HTTP/3 uses stream IDs to refer to streams that have already been opened, but makes no assumptions about future stream IDs or the way </ins> in which they are assigned Section 6 of QUIC-HTTP). 4.1.


2.5. <del> [Editor's note: text needed.] 2.6. </del> Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided in the list of version in the Version Negotiation packet will be

Section 2.5 needs content.
This actually seems to be superceded by §8.4 in transport-13

2.5.  Version negotiation is not protected, given the used protection mechanism can change with the version.  However, the choices provided in the list of version in the Version Negotiation packet will be


QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing <del> transport connection using the destination connection ID field (see also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </del>  Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-

You can associate packets with connections without a connection ID. So rather than say something that is factually incorrect, let's just leave the next paragraph to establish the right impression (that a connection ID is highly recommended). This text works without talking about zero-length connection IDs.

QUIC supports connection migration by the client.  If an IP address changes, a QUIC endpoint can still associate packets with an existing  <ins> transport connection using the Destination Connection ID field (see also connid) in the QUIC header.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the server for a preferred address to be used. </ins> Use of a non-zero-length connection ID for the server is strongly recommended if any clients are behind a NAT or could be.  A non-zero-


QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path <del> characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </del>  Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

The text here mentioned the decision to use a new path twice. Also, probing packets almost always include padding frames now: we require that the datagram is full-sized when probing so that we can probe for MTU, and probing is almost certainly done with short header packets, where padding has to be inside the packet.

QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path  <ins> characteristics.  Probing packets cannot carry application data but likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to


11.3. <del> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </del>  Section 4 of RFC5077 describes an example approach for constructing TLS resumption tickets that can be also applied for validation

No real changes here, just noting that "Server Retry" isn't really a thing. Retry is, and servers use it, that's all.

11.3.  <ins> QUIC provides a Retry packet that can be sent by a server in response to the client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another client Initial packet with the server-selected connection ID.  This mechanism can be used to redirect a connection to a different server, e.g., due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC. In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Retry packet such that the load balancer will redirect the next Initial packet to a different server in that pool. Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </ins> Section 4 of RFC5077 describes an example approach for constructing TLS resumption tickets that can be also applied for validation


Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the <del> connection ID is zero length, all packets of the 5-tuple belong to the same QUIC connection. </del>  2.4.

Probably, but not certain Especially if you got it wrong regarding the connection ID.
If there is no connection is how would an endpoint identify connection on the same 5-tuple then (for QUICv1)?
It is possible to run multiple connections on the same tuple with trial decryption.

Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the  <ins> connection ID is zero-length, all packets of the 5-tuple likely belong to the same QUIC connection. </ins> 2.4.


QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 <del> uses UDP port 443 by default, although URLs referring to resources available over HTTP/3 may 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>  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-

No client currently attempts to use UDP port 443 for HTTP/3 without first having been told to do so, most often by AltSvc or HTTPS records. Technically we can also use the URL to decide to use QUIC, but that doesn't currently happen. With HTTPS records, that might never be necessary.
This is not entirely true. As we have HTTPS records and Alternative Services, there is no case where HTTP/3 goes without a means of signaling a port number. So there is no real "default" as far as it goes. It's just that we reserved the number and we tend to use that port number by convention.
For what it's worth, NAME and I were talking about this wrt URL in MOPS, so the timing of this issue in QUIC was very helpful. Thank you for that. I'm using "by convention", at his suggestion.

QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3  <ins> uses UDP port 443 by convention but various methods can be used to 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. </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-


3.1. The QUIC wire image is not specifically designed to be <del> distinguishable from other UDP traffic. </del>  The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other

NAME thank you for your help with this.
It is specifically designed to allow for multiplexing of QUIC with real-time protocols. See RFC 7983.
NAME is this issue conflating what endpoints can distinguish and what anyone else can distinguish? I'm guessing that's the case, but it would be good to be clear about this, especially in the ops drafts. Again, I'm being informed here about what NAME issue being addressed in URL in MOPS should say. So thank you for opening the issue here!
NAME you are right to point that out. If we consider this about observers, then this text is probably OK. I would say that it needs qualification to be properly correct though. We might reasonably assume that the statement applies only to "a passive observer in the network", as noted in the top of the section, but the risk that this statement be taken out of context is strong (it's a nice clear sound bite). The same section later mentions RFC 7983. That text could also be improved in this regard.

3.1. The QUIC wire image is not specifically designed to be  <ins> distinguishable from other UDP traffic by a passive observer in the network. </ins> The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other