jiebi/CodeConvo huggingface dataset:
Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might <del> lead to blocking or other interference by network elements such as firewalls that rely on the port number for application identification. </del> <ins> lead to blocking or other changes to the forwarding behavior by network elements such as firewalls that use the port number for application identification. </ins> 7.
13. <del> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </del> <ins> QUIC version 1 does not specify a version negotation mechanism in the base spec but I-D.draft-ietf-quic-version-negotiation proposes an extension.  This process assumes that the set of versions that a server supports is fixed.  This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in </ins> clusters. A server that rolls out a new version of QUIC can do so in three
a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate <del> amplification attacks (see section 9 of QUIC-TRANSPORT).  An NAT </del> <ins> amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT </ins> function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and
to use smaller packets, so that the limited reassembly capacity is not exceeded. <del> For TCP, MSS clamping (Section 3.2 of {?RFC4459}}) is often used to </del> <ins> For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to </ins> change the sender's maximum TCP segment size, but QUIC requires a different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery
14. <del> 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. </del> <ins> I-D.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. </ins> QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable
cause long timeout-based delays before this problem is detected by the endpoints and the connection can potentially be re-established. <del> 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. </del> 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-
impacted by QUIC. QUIC is an end-to-end transport protocol.  No information in the <del> protocol header, even that which can be inspected, is meant to be mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del> <ins> protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer <del> information.  However, it does imply that in-network operations that depend on modification of data are not possible without the cooperation of a QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </del> <ins> information.  However, it means in-network operations that depend on modification of data are not possible without the cooperation of an QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks
which type of header is present.  The purpose of this bit is invariant across QUIC versions. <del> The long header exposes more information.  In version 1 of QUIC, it is used during connection establishment, including version negotiation, retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. </del> <ins> The long header exposes more information.  It contains a version number, as well as source and destination connection IDs for associating packets with a QUIC connection.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. In version 1 of QUIC, the long header is used during connection establishment to transmit crypto handshake data, perform version negotiation, retry, and send 0-RTT data. </ins> Short headers contain only an optional destination connection ID and the spin bit for RTT measurement.  In version 1 of QUIC, they are
identifies the packet as a Version Negotiation packet.  QUIC version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various <del> Internet experiments, future standards, and greasing.  All deployed versions are maintained in an IANA registry (see </del> <ins> Internet experiments, future standards, and greasing (RFC7801). All deployed versions are maintained in an IANA registry (see </ins> Section 22.2 of QUIC-TRANSPORT). source and destination connection ID: short and long packet
packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path <del> observers.  The offset of the packet number is encoded in long </del> <ins> observers.  The offset of the packet number can be decoded in long </ins> headers, while it is implicit (depending on destination connection ID length) in short headers.  The length of the packet number is cryptographically obfuscated.
Server Initial datagram as shown in fig-server-initial typically containing three packets: an Initial packet with the beginning of the server's side of the TLS handshake, a Handshake packet with the rest <del> of the server's side of the TLS handshake, and initial 1-RTT data, if </del> <ins> of the server's side of the TLS handshake, and 1-RTT data, if </ins> present. The Client Completion datagram contains at least one Handshake packet
3.2. <del> This document focuses on QUIC version 1, and this section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </del> <ins> This document focuses on QUIC version 1, and this Connection Confirmation section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </ins> Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain
detected using heuristics similar to those used to detect TLS over TCP.  A client initiating a connection may also send data in 0-RTT packets directly after the Initial packet containing the TLS Client <del> Hello.  Since these packets may be reordered in the network, 0-RTT </del> <ins> Hello.  Since packets may be reordered or lost in the network, 0-RTT </ins> packets could be seen before the Initial packet. Note that in this version of QUIC, clients send Initial packets
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the
Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data before new data, unless indicated differently by the application. <del> Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </del> <ins> When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </ins> 4.3.
length connection ID is also strongly recommended when migration is supported. <del> Currently QUIC only supports the use of a single network path at a time, which enables failover use cases.  Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. </del> <ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at 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
QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or <del> because the information is intended to be used by the network.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </del> <ins> because the information is intended to be used by the network.  For more information on manageability of QUIC see also I-D.ietf-quic- manageability.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </ins> The connection ID can be zero length.  Zero length connection IDs can be chosen on each endpoint individually, on any packet except the
default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <del> 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. 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 RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "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. </del> Given the prevalence of the assumption in network management practice that a port number maps unambiguously to an application, the use of ports that cannot easily be mapped to a registered service name might
network elements such as firewalls that use the port number for application identification. <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 RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" Application-Layer Protocol Negotiation (ALPN) RFC7301 token. ALPN 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 are required to register an ALPN token for use in the TLS handshake. As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version.  So far no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general.  Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions.  Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3. </ins> 9. QUIC supports connection migration by the client.  If an IP address
5. <ins> As QUIC is a general purpose transport protocol, there are no requirements that servers use a particular UDP port for QUIC in general.  Instead, the same port number is used as would be used for the same application over TCP.  In the case of HTTP the expectation is that port 443 is used, which has already been registered for "http protocol over TLS/SSL".  However, QUIC-HTTP also specifies the use of Alt-Svc for HTTP/QUIC discovery which allows the server to use and announce a different port number. In general, port numbers serves two purposes: "first, they provide a demultiplexing identifier to differentiate transport sessions between the same pair of endpoints, and second, they may also identify the application protocol and associated service to which processes connect" RFC6335.  Note that the assumption that an application can be identified in the network based on the port number is less true today, due to encapsulation, mechanisms for dynamic port assignments as well as NATs. However, whenever a non-standard port is used which does not enable easy mapping to a registered service name, this can lead to blocking by network elements such as firewalls that rely on the port number as a first order of filtering. 6. </ins> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] <del> 6. </del> <ins> 7. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established,
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 8. </del> <ins> 9. </ins> This document has no actions for IANA. <del> 9. </del> <ins> 10. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for
QUIC is an end-to-end transport protocol.  No information in the protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire <del> image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del> <ins> image WIRE-IMAGE.  Encryption of most transport-layer control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer
it describes what is and is not possible with the QUIC transport protocol as defined. <ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on observation with active measurement techniques, for example, is therefore out of scope.  A more generalized treatment of network management operations on encrypted transports is given in RFC9065. </ins> QUIC-specific terminology used in this document is defined in QUIC- TRANSPORT.
The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to <del> present a certificate based on that name.  It may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </del> <ins> present a certificate based on that name.  SNI information is available to unidirectional observers on the client-to-server path, if present. The TLS ClientHello may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </ins> Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,
semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to <del> encrypt all payload data and most control information.  Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible. </del> <ins> encrypt all payload data and most control information. Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not meant to be mutable by the network, and is therefore integrity- protected.  While less information is visible to the network than for TCP, integrity protection can also simplify troubleshooting because none of the nodes on the network path can modify the transport layer information. </ins> This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to