For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.


4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY <del> support RFC7252 and the OSCORE option without supporting RFC7641. </del> <ins> support RFC7252 and the OSCORE option without supporting RFC7641, in which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. </ins> The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). <del> To support proxy operations, OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a request and notifications would not reach the endpoint.  Moreover, intermediaries are allowed to cancel observations at any time; forbidding this behavior would also result in notifications being dropped. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  It is worth noting that although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </del> <ins> This section specifies Observe processing associated to the Partial IV (observe-partial-iv) and Observe processing in the presence of RFC7641-compliant intermediaries (observe-option-processing). In contrast to e.g. block-wise, the Inner and Outer Observe option are not processed independently.  Outer Observe is required to support Observe operations in intermediaries, but the additional use of Inner Observe is needed to protect Observe registrations end-to- end (see observe-option-processing). observe-without-intermed specifies a simplified Observe processing which is applicable in the absence of intermediaries. Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. 4.1.3.4.1. To support proxy operations, the CoAP client using Observe with OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a non-Observe request and notifications would not reach the client.  Moreover, intermediaries are allowed to cancel observations and inform the server; forbidding this may result in processing and transmission of notifications on the server side which do not reach the client. </ins> In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was <del> requested by the client, thereby avoiding unnecessary overhead (processing and transmission of notifications) on the server, since such notifications would not benefit the client. Note that, as defined in Section 3.1 of RFC7641, the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE.  This means that several clients registering to the same protected resource via an intermediary, when using OSCORE, will be effectively registering to different target resources.  The intermediary may then register to the protected resource (different target resources) once per each client. The processing of the CoAP Code for Observe messages is described in coap-header. </del> <ins> requested by the client, thereby avoiding unnecessary processing and transmission of notifications, since such notifications would not benefit the client. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  Although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </ins> The Outer Observe option in the CoAP request may be legitimately <del> removed by a proxy or ignored by the server.  In these cases, the </del> <ins> removed by a proxy or ignored by a server.  In these cases, the </ins> server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the


Outer Observe value, it stops processing the message, as specified in ver-res. <del> It the server accepts the Observe registration, a Partial IV must be </del> <ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses. 4.1.3.4.2. It the server accepts an Observe registration, a Partial IV must be </ins> included in all notifications (both successful and error).  To secure the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is


Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- <del> protection.  The client MAY ignore the Observe option value. </del> <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 <del> Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </ins> 4.1.3.5.


The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  The Outer Code SHALL be set to 0.02 (POST) or 0.05 (FETCH) for requests.  For non-Observe requests the client SHALL set the Outer Code to 0.02 (POST).  For responses, the sending endpoint SHALL respond with Outer Code 2.04 (Changed) to 0.02 (POST) requests, and with Outer Code 2.05 (Content) to 0.05 (FETCH) requests.  Using FETCH with Observe allows OSCORE to be compliant with the Observe processing in OSCORE-unaware intermediaries.  The choice of POST and FETCH RFC8132 allows all OSCORE messages to have payload. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del> <ins> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the


Additionally to the previous section, the following applies when Observe is supported. <del> Observe allows re-registration of observations (see 3.3.1 of RFC7641).  A server receiving an Observe registration identical to a previously stored one (including Partial IV and Token) SHALL treat it as valid and reply with the last notification sent. </del> <ins> 7.4.1.1. </ins> A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that <del> Observe registration.  Observe reordering MUST be linked to OSCORE's ordering of notifications.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  If the verification of the response succeeds, and the received Partial IV was greater than the </del> <ins> Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the </ins> Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been


replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. <ins> 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, Kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, Kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </ins> 7.5. To prevent reuse of an AEAD nonce with the same key, or from


For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. <ins> Replace step 3 in ver-req with: B.  If Observe is present in the received message, and has value 0, check if the Token, Kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> Insert the following steps between step 6 and 7 of ver-req: <del> B.  If Observe was present in the received message (in step 1): </del> <ins> C.  If Observe was present in the received message (in step 1): </ins> If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, <del> discard the Outer Observe; </del> <ins> discard the Outer Observe.  If the Token, Kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; </ins> Otherwise, discard both the Outer and Inner (if present) <del> Observe options. </del> <ins> Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> <del> If the value of Observe in the Outer message is not 0, discard </del> <ins> If the value of Observe in the Outer message is not 0, discard the </ins> decrypted Observe option if present. <del> Insert the following steps between step 6 and 7 of ver-req: C.  If the message is an Observe registration, store it in memory for later comparison with re-registrations (see replay-protection). D.  If the message is an Observe cancellation, delete from memory the previously stored registration related to that observation (see replay-protection). </del> 8.3. If a CoAP response is generated in response to an OSCORE request, the


Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. <del> Add the following step after step 5: B.  If the message is an Observe notification, store it in memory for use with re-registrations (see replay-protection), and delete from memory any older one previously stored. </del> 8.4. A client receiving a response containing the OSCORE option SHALL


options. An Outer Max-Age message field is used to avoid unnecessary caching <del> of OSCORE error responses at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to OSCORE error responses, which are described in Sections replay- protection, ver-req, and ver-res.  Such a message field is then processed according to outer-options. </del> <ins> of error responses caused by OSCORE processing at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to such error responses, described in Sections replay-protection, ver-req, and ver-res, since these error responses are cacheable, but subsequent OSCORE requests would never create a hit in the intermediary caching it.  Setting the Outer Max-Age to zero relieves the intermediary from uselessly caching responses. </ins> Successful OSCORE responses do not need to include an Outer Max-Age <del> option since the responses are non-cacheable by construction (see coap-header). </del> <ins> option since the responses appear to the OSCORE-unaware intermediary as 2.04 Changed responses, which are non-cacheable (see coap-header). The Outer Max-Age message field is processed according to outer- options. </ins> 4.1.3.2.


Every time a client issues a new Observe request, a new Partial IV MUST be used (see cose-object), and so the payload and OSCORE option are changed.  The server uses the Partial IV of the new request as <del> the 'request_piv' of all associated notifications (see AAD).  The Partial IV of the registration is also used as 'request_piv' of associated cancellations (see AAD). </del> <ins> the 'request_piv' of all associated notifications (see AAD). </ins> Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or


the request (see cose-object). request_piv: contains the value of the 'Partial IV' in the COSE <del> object of the request (see cose-object), with one exception: in case of protection or verification of Observe cancellations, the request_piv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see observe- registration). </del> <ins> object of the request (see cose-object). </ins> options: contains the Class I options (see outer-options) present in the original CoAP message encoded as described in Section 3.1


Abstract This memo defines Object Security of CoAP (OSCOAP), a method for <del> application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format.  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </del> <ins> application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE).  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding.  OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </ins> 1. <del> The Constrained Application Protocol (CoAP) RFC7252 is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </del> <ins> The Constrained Application Protocol (CoAP) is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP RFC7252 references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </ins> This memo defines Object Security of CoAP (OSCOAP), a data object based security protocol, protecting CoAP message exchanges end-to- end, across intermediary nodes.  An analysis of end-to-end security for CoAP messages through intermediary nodes is performed in I- D.hartke-core-e2e-security-reqs, this specification addresses the <del> forwarding case. </del> <ins> forwarding case.  In addition to the core features defined in RFC7252, OSCOAP supports Observe RFC7641 and Blockwise RFC7959. </ins> <del> The solution provides an in-layer security protocol for CoAP which does not depend on underlying layers and is therefore favorable for providing security for "CoAP over foo", e.g.  CoAP messages passing over both unreliable and reliable transport I-D.ietf-core-coap-tcp- tls, CoAP over IEEE 802.15.4 IE I-D.bormann-6lo-coap-802-15-ie. </del> <ins> OSCOAP is designed for constrained nodes and networks and provides an in-layer security protocol for CoAP which does not depend on underlying layers.  OSCOAP can be used anywhere that CoAP can be used, including unreliable transport RFC7228, reliable transport I- D.ietf-core-coap-tcp-tls, and non-IP transport I-D.bormann-6lo-coap- 802-15-ie. </ins> OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf- <del> cose-msg, providing end-to-end encryption, integrity, and replay protection.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added.  We call the result the "protected" CoAP message.  Thus OSCOAP is a security protocol based on the exchange of protected CoAP messages (see oscoap-ex). OSCOAP provides protection of CoAP payload, certain options, and header fields, as well as a secure binding between CoAP request and response messages.  OSCOAP provides replay protection, but like DTLS, OSCOAP only provides relative freshness in the sense that the sequence numbers allows a recipient to determine the relative order of messages.  For applications having stronger demands on freshness (e.g. control of actuators), OSCOAP needs to be augmented with mechanisms providing absolute freshness I-D.mattsson-core-coap- actuators. </del> <ins> cose-msg, providing end-to-end encryption, integrity, replay protection, and secure message binding.  The use of OSCOAP is signaled with the CoAP option Object-Security, defined in obj-sec- option-section.  OSCOAP provides protection of CoAP payload, certain options, and header fields.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added, see oscoap-ex. </ins> OSCOAP may be used in extremely constrained settings, where DTLS cannot be supported.  Alternatively, OSCOAP can be combined with


meanings. Readers are expected to be familiar with the terms and concepts <del> described in RFC7252 and RFC7641.  Readers are also expected to be familiar with RFC7049 and understand I-D.greevenbosch-appsawg-cbor- cddl.  Terminology for constrained environments, such as "constrained device", "constrained-node network", is defined in RFC7228. </del> <ins> described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE I-D.ietf-cose-msg, CBOR RFC7049, CDDL I-D.greevenbosch-appsawg-cbor- cddl, and constrained environments RFC7228. </ins> 2.


use for encryption.  Its value is immutable once the security context is established. <del> Base Key (master_secret).  Variable length, uniformly random byte string containing the key used to derive traffic keys and IVs. Its value is immutable once the security context is established. </del> <ins> Master Secret.  Variable length, uniformly random byte string containing the key used to derive traffic keys and IVs.  Its value is immutable once the security context is established. Master Salt (OPTIONAL).  Variable length byte string containing the salt used to derive traffic keys and IVs.  Its value is immutable once the security context is established. </ins> The Sender Context contains the following parameters:


messages received. The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction <del> Identifier (Tid), and SHALL be unique for each Base Key. The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </del> <ins> Identifier (Tid), and SHALL be unique for each Master Secret.  The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </ins> 3.2.


Context Identifier (Cid) <del> Base Key (master_secret) </del> <ins> Master Secret </ins> The following input parameters MAY be pre-established.  In case any of these parameters is not pre-established, the default value


Defaults are 0x01 for the endpoint initially being client, and 0x00 for the endpoint initially being server <ins> Master Salt Default is the empty string </ins> Key Derivation Function (KDF) Default is HKDF SHA-256


where: <del> master_secret is defined above </del> <ins> salt is the Master Salt as defined above </ins> <del> salt is a string of zeros of the length of the hash function output in octets </del> <ins> IKM is the Master Secret is defined above </ins> info is a serialized CBOR array consisting of: <del> output_length is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer </del> <ins> L is the key/IV size of the AEAD algorithm in octets without leading zeroes. </ins> For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in <del> I-D.ietf-cose-msg) is used, output_length for the keys is 128 bits and output_length for the IVs is 56 bits. </del> <ins> I-D.ietf-cose-msg) is used, L is 16 bytes for keys and 7 bytes for IVs. </ins> 3.2.2.


5. <del> This section defines how to use the COSE format I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm. </del> <ins> This section defines how to use COSE I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the untagged COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm.  The key lengths, IV lengths, and maximum sequence number are algorithm dependent.  The maximum sequence number SHALL be 2^(nonce length in bits - 1) - 1. </ins> The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I- D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the <del> length of Sender Key and Recipient Key SHALL be 128 bits, the length of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the untagged version of the COSE_Encrypt0 structure (Section 2. of I- D.ietf-cose-msg).  If the COSE object has a different structure, the recipient MUST reject the message, treating it as malformed. </del> <ins> length of Sender Key and Recipient Key is 128 bits, the length of nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum Sequence Number is 2^55 - 1. The nonce is constructed as described in Section 3.1 of I-D.ietf- cose-msg, i.e. by padding the partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV).  The first bit in the Sender IV or Recipient IV SHALL be flipped in responses. </ins> We denote by Plaintext the data that is encrypted and integrity protected, and by Additional Authenticated Data (AAD) the data that <del> is integrity protected only, in the COSE object. The fields of COSE_Encrypt0 structure are defined as follows (see example in sem-auth-enc). </del> <ins> is integrity protected only. </ins> <del> The "Headers" field is formed by: </del> <ins> The COSE Object SHALL be a COSE_Encrypt0 object with fields defined as follows </ins> <del> The "protected" field, which SHALL include: </del> <ins> The "protected" field includes: </ins> <del> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV is a byte string (type: bstr), and SHOULD be of minimum length needed to encode the sequence number. </del> <ins> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV SHALL be of minimum length needed to encode the sequence number.  This parameter SHALL be present in requests, and MAY be present in responses. </ins> <del> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section). </del> <ins> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section).  This parameter SHALL be present in requests. </ins> <del> The "unprotected" field, which SHALL be empty. </del> <ins> The "unprotected" field is empty. </ins> The "ciphertext" field is computed from the Plaintext (see plaintext) and the Additional Authenticated Data (AAD) (see AAD) <del> and encoded as a byte string (type: bstr), following Section 5.2 of I-D.ietf-cose-msg. </del> <ins> following Section 5.2 of I-D.ietf-cose-msg. The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </ins> 5.1. The Plaintext is formatted as a CoAP message without Header (see plaintext-figure) consisting of: <del> all CoAP Options present in the unprotected message which are encrypted (see coap-headers-and-options), in the order as given by the Option number (each Option with Option Header including delta to previous included encrypted option); and </del> <ins> all CoAP Options present in the unprotected message that are encrypted (see coap-headers-and-options).  The options are encoded as described in Section 3.1 of RFC7252, where the delta is the difference to the previously included encrypted option); and </ins> <del> the CoAP Payload, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </del> <ins> the Payload of unprotected CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </ins> 5.2. <del> The Additional Authenticated Data ("Enc_structure") as described is Section 5.3 of I-D.ietf-cose-msg includes: the "context" parameter, which has value "Encrypted" </del> <ins> The external_aad SHALL be a CBOR array as defined below: </ins> <del> the "protected" parameter, which includes the "protected" part of the "Headers" field; the "external_aad" is a serialized CBOR array aad where the exact content is different in requests (external_aad_req) and responses (external_aad_resp).  It contains: ver: uint, contains the CoAP version number, as defined in Section 3 of code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </del> <ins> where: </ins> <del> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section); </del> <ins> ver: uint, contains the CoAP version number, as defined in Section 3 of RFC7252. </ins> <del> id : bstr, is the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </del> <ins> code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </ins> <del> seq : bstr, is the value of the "Partial IV" in the COSE object of the request (see Section 5). </del> <ins> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section). </ins> <del> tag-previous-block: bstr, contains the AEAD Tag of the message containing the previous block in the sequence, as enumerated by Block1 in the case of a request and Block2 in the case of a response, if the message is fragmented using a block option RFC7959. </del> <ins> request_id : bstr, contains the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </ins> <del> The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </del> <ins> request_seq : bstr, contains the value of the "Partial IV" in the COSE object of the request (see Section 5). </ins> 6.


been changed, then the original value will already be in the OHB, so no update to the OHB is required. <ins> A Media Distributor that decrypts, modifies, and re-encrypts packets in this way MUST use an independent key for each recipient, SHOULD use an independent salt for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of GCM. </ins> 5.3. To decrypt a packet, the endpoint first decrypts and verifies using


1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the HTTP/3 and QPACK protocols.  This document is based on draft-34 of the HTTP/3 I-D QUIC-HTTP and draft-21 of the QPACK I-D QUIC-QPACK.  QUIC events are defined in a separate document QLOG-QUIC. </del> <ins> "event") and "data" fields and their semantics for HTTP/3 RFC9114 and QPACK QPACK. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that


1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the QUIC protocol. This document is based on draft-34 of the QUIC I-Ds QUIC-TRANSPORT, QUIC-RECOVERY, and QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </del> <ins> "event") and "data" fields and their semantics for QUIC; see QUIC- TRANSPORT, QUIC-RECOVERY, and QUIC-TLS. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that


treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. <del> Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del> <ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> A server MUST respect the value it previously provided for the grease_quic_bit transport parameter if it accepts 0-RTT.  A client


resulting in connection failures. A server MUST clear the QUIC bit only after processing transport <del> parameters from a client.  A server cannot remember that a client </del> <ins> parameters from a client.  A server MUST NOT remember that a client </ins> negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <del> An endpoint cannot clear the QUIC Bit without knowing whether the </del> <ins> An endpoint MUST NOT clear the QUIC Bit without knowing whether the </ins> peer supports the extension.  As Stateless Reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on


1. <del> QUIC RFC9000 has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </del> <ins> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </ins> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to


3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in RFC9000, RFC9001, and RFC9002, with the </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002, with the </ins> following changes: The version field of long headers is TBD.  Note: Unless this


provisional value 0xff020000, which might change with each edition of this document. <del> The salt used to derive Initial keys in Sec 5.2 of RFC9001 changes to </del> <ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </ins> <del> The labels used in RFC9001 to derive packet protection keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to </del> <ins> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to </ins> "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the <del> guidance for new versions in Section 9.6 of that document. </del> <ins> guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </ins> <del> The key and nonce used for the Retry Integrity Tag (Sec 5.8 of RFC9001) change to: </del> <ins> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.


QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header <del> (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </del> <ins> (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </ins> 0x00000001. <del> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to inspect the contents of these packets, which include the TLS Client Hello and Server Hello messages.  Again, middleboxes may ossify on </del> <ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in Section 5.2 of QUIC-TLS.  Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages.  Again, there is the potential for middleboxes to ossify on </ins> the version 1 key derivation and packet formats. Finally QUIC-VN provides two mechanisms for endpoints to negotiate


to implement version negotiation to protect against downgrade attacks. <del> I-D.duke-quic-version-aliasing is a more robust, but much more complicated, proposal to address these ossification problems.  By design, it requires incompatible version negotiation.  QUICv2 enables exercise of compatible version negotiation mechanism. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes. </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </ins> 3.1. <del> The version field of long headers is 0x709a50c4. </del> <ins> The Version field of long headers is 0x709a50c4. </ins> 3.2. <del> Initial packets use a packet type field of 0b01. 0-RTT packets use a packet type field of 0b10.  Handshake packets use a packet type field of 0b11.  Retry packets use a packet type field of 0b00. </del> <ins> All version 2 long header packet types are different.  The Type field values are: Initial: 0b01 0-RTT: 0b10 Handshake: 0b11 Retry: 0b00 </ins> 3.3.


TLS session tickets and NEW_TOKEN tokens are specific to the QUIC version of the connection that provided them.  Clients SHOULD NOT use <del> a session ticket or token from a QUICv1 connection to initiate a QUICv2 connection, or vice versa. </del> <ins> a session ticket or token from a QUIC version 1 connection to initiate a QUIC version 2 connection, or vice versa. </ins> Servers MUST validate the originating version of any session ticket or token and not accept one issued from a different version.  A


6. QUIC version 2 provides protection against some forms of <del> ossification.  Devices that assume that all long headers will contain encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. </del> <ins> ossification.  Devices that assume that all long headers will encode version 1, or that the version 1 Initial key derivation formula will remain version-invariant, will not correctly process version 2 packets. </ins> However, many middleboxes such as firewalls focus on the first packet in a connection, which will often remain in the version 1 format due


This version of QUIC provides no change from QUIC version 1 relating to the capabilities available to applications.  Therefore, all Application Layer Protocol Negotiation (ALPN) (RFC7301) codepoints <del> specified to operate over QUICv1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUICv2. </del> <ins> specified to operate over QUIC version 1 can also operate over this version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUIC version 2. </ins> All QUIC extensions defined to work with version 1 also work with version 2.


version of QUIC.  In particular, both the "h3" I-D.ietf-quic-http and "doq" I-D.ietf-dprive-dnsoquic ALPNs can operate over QUIC version 2. <del> All QUIC extensions defined to work with version 1 also work with version 2. </del> <ins> Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2. </ins> 8.


1. <del> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </del> <ins> QUIC version 1QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in QUIC-TLS.  Protecting Initial packets


and validate the version_information transport parameter specified in QUIC-VN to prevent version downgrade attacks. <del> Note that version 2 meets that document's definition of a compatible </del> <ins> Note that version 2 meets the QUIC-VN definition of a compatible </ins> version with version 1, and version 1 is compatible with version 2. Therefore, servers can use compatible negotiation to switch a connection between the two versions.  Endpoints that support both


If the server sends a Retry packet, it MUST use the original version. The client ignores Retry packets using other versions.  The client <del> MUST NOT use a different version in the subsequent Initial that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </del> <ins> MUST NOT use a different version in the subsequent Initial packet that contains the Retry token.  The server MAY encode the QUIC version in its Retry token to validate that the client did not switch versions, and drop the packet if it switched. </ins> QUIC version 2 uses the same transport parameters to authenticate the Retry as QUIC version 1.  After switching to a negotiated version


3.1. <del> The Version field of long headers is 0x709a50c4.  This randomly chosen value is meant to avoid creating patterns in specified version numbers. </del> <ins> The Version field of long headers is 0x6b3343cf.  This was generated by taking the first four bytes of the sha256sum of "QUICv2 version number". </ins> This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility.


The salt used to derive Initial keys in QUIC-TLS changes to: <ins> This is the first 20 bytes of the sha256sum of "QUICv2 salt". </ins> 3.3.2. The labels used in QUIC-TLS to derive packet protection keys


The key and nonce used for the Retry Integrity Tag (QUIC-TLS) change to: <ins> The secret is the sha256sum of "QUICv2 retry secret".  The key and nonce are derived from this secret with the labels "quicv2 key" and "quicv2 iv", respectively. </ins> 4. QUIC version 2 is not intended to deprecate version 1.  Endpoints


2.1.2. <ins> A dynamic table entry is considered blocking and cannot be evicted until its insertion has been acknowledged and there are no outstanding unacknowledged references to the entry.  In particular, a dynamic table entry that has never been referenced can still be blocking. A blocking entry is unrelated to a blocked stream, which is a stream that a decoder cannot decode as a result of references to entries that are not yet available.  Any encoder that uses the dynamic table has to keep track of blocked entries, whereas blocked streams are optional. </ins> An encoder MUST NOT insert an entry into the dynamic table (or <del> duplicate an existing entry) if doing so would evict an entry with unacknowledged references.  For header blocks that might rely on the newly added entry, the encoder can use a literal representation. </del> <ins> duplicate an existing entry) if doing so would evict a blocking entry.  In this case, the encoder can send literal representations of header fields. </ins> To ensure that the encoder is not prevented from adding new entries, the encoder can avoid referencing entries that are close to eviction.


Determining which entries are too close to eviction to reference is an encoder preference.  One heuristic is to target a fixed amount of available space in the dynamic table: either unused space or space <del> that can be reclaimed by evicting unreferenced entries.  To achieve </del> <ins> that can be reclaimed by evicting non-blocking entries.  To achieve </ins> this, the encoder can maintain a draining index, which is the smallest absolute index in the dynamic table that it will emit a reference for.  As new entries are inserted, the encoder increases


Knowledge that a header block with references to the dynamic table has been processed permits the encoder to evict entries to which no <del> unacknowledged references remain, regardless of whether those references were potentially blocking (see blocked-insertion).  When a </del> <ins> unacknowledged references remain (see blocked-insertion).  When a </ins> stream is reset or abandoned, the indication that these header blocks <del> will never be processed serves a similar function; see stream- cancellation. </del> <ins> will never be processed serves a similar function (see stream- cancellation). </ins> The decoder chooses when to emit Insert Count Increment instructions (see insert-count-increment).  Emitting an instruction after adding


Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (table capacity - size of new entry) or <del> until the table is empty.  The encoder MUST NOT evict a dynamic table entry unless it has first been acknowledged by the decoder. </del> <ins> until the table is empty.  The encoder MUST NOT evict a blocking dynamic table entry (see blocked-insertion). </ins> If the size of the new entry is less than or equal to the dynamic table capacity, then that entry is added to the table.  It is an


connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of entries with outstanding references (see reference-tracking).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.4.


4.2.4. The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a <del> server push prior to the push stream being created.  The CANCEL_PUSH </del> <ins> server push prior to the push stream being received.  The CANCEL_PUSH </ins> frame identifies a server push by Push ID (see frame-push-promise), encoded as a variable-length integer.


acknowledgement is received that establishes loss or delivery of packets. <del> When an ACK frame is received that establishes loss after a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc-consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </del> <ins> When an ACK frame is received that establishes loss of all in-flight packets sent prior to a threshold number of consecutive PTOs (pto_count is more than kPersistentCongestionThreshold, see cc- consts-of-interest), the network is considered to be experiencing persistent congestion, and the sender's congestion window MUST be reduced to the minimum congestion window (kMinimumWindow).  This response of collapsing the congestion window on persistent congestion is functionally similar to a sender's response on a Retransmission Timeout (RTO) in TCP RFC5681. </ins> 7.6.


Consequently, a Version Negotiation packet consumes an entire UDP datagram. <ins> A server MUST NOT send more than one Version Negotiation packet in response to a single UDP datagram. </ins> See version-negotiation for a description of the version negotiation process.


A server MAY send Retry packets in response to Initial and 0-RTT packets.  A server can either discard or buffer 0-RTT packets that it receives.  A server can send multiple Retry packets as it receives <del> Initial or 0-RTT packets. </del> <ins> Initial or 0-RTT packets.  A server MUST NOT send more than one Retry packet in response to a single UDP datagram. </ins> A client MUST accept and process at most one Retry packet for each connection attempt.  After the client has received and processed an


4. <del> As discussed above, frames are carried on QUIC streams and used on control streams, request streams, and push streams.  This section describes HTTP framing in QUIC.  For a comparison with HTTP/2 frames, see h2-frames. </del> <ins> HTTP frames are carried on QUIC streams, as described in stream- mapping.  HTTP/3 defines three stream types: control stream, request stream, and push stream.  This section describes HTTP/3 frame formats and the streams types on which they are permitted; see stream-frame- mapping for an overiew.  A comparison between HTTP/2 and HTTP/3 frames is provided in h2-frames. </ins> 4.1.


mapping for an overiew.  A comparison between HTTP/2 and HTTP/3 frames is provided in h2-frames. <ins> Certain frames can only occur as the first frame of a particular stream type; these are indicated in stream-frame-mapping with a (1). Specific guidance is provided in the relevant section. </ins> 4.1. All frames have the following format:


packets arrive.  If a peer could timeout within an Probe Timeout (PTO, see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test for liveness before sending any data that cannot be retried safely. <ins> Note that it is likely that only applications or application protocols will know what information can be retried. </ins> 10.3.


can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST pad UDP datagrams that contain only Initial packets to at least 1200 bytes.  Once a client has received an acknowledgment </del> <ins> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment </ins> for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.


for responses in request-response.  Due to reordering, data on a push stream can arrive before the corresponding PUSH_PROMISE, in which case both the associated client request and the pushed request <del> headers are unknown.  Clients which receive a new push stream with an </del> <ins> headers are unknown.  Clients that receive a new push stream with an </ins> as-yet-unknown Push ID can buffer the stream data in expectation of the matching PUSH_PROMISE.  A client can use stream flow control (see section 4.1 of QUIC-TRANSPORT) to limit the amount of data a server


19.4. An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly <del> terminate a stream. </del> <ins> terminate the sending part of a stream. </ins> After sending a RESET_STREAM, an endpoint ceases transmission and retransmission of STREAM frames on the identified stream.  A receiver


The final size is the amount of flow control credit that is consumed by a stream.  Assuming that every contiguous byte on the stream was sent once, the final size is the number of bytes sent.  More <del> generally, this is one higher than the largest byte offset sent on the stream. </del> <ins> generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent. </ins> For a stream that is reset, the final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final size is the offset plus the


Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A <del> fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC. </del> <ins> fatal unsupported_extension alert MUST be sent by an implementation that supports this extension if the extension is received when the transport is not QUIC. </ins> 8.3.


maximum value for a Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit set by the QUIC <del> MAX_STREAM_ID frame. </del> <ins> MAX_STREAMS frame. </ins> The MAX_PUSH_ID frame is always sent on the control stream.  Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a


of the connection.  An endpoint that completes a graceful shutdown SHOULD use the HTTP_NO_ERROR code when closing the connection. <ins> If a client has consumed all available bidirectional stream IDs with requests, the server need not send a GOAWAY frame, since the client is unable to make further requests. </ins> 6.3. An HTTP/3 implementation can immediately close the QUIC connection at


permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control <del> stream.  If the control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </del> <ins> stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </ins> A pair of unidirectional streams is used rather than a single bidirectional stream.  This allows either peer to send data as soon


The DUPLICATE_PUSH frame carries a single variable-length integer that identifies the Push ID of a resource that the server has <del> previously promised (see frame-push-promise). </del> <ins> previously promised (see frame-push-promise), though that promise might not be received before this frame.  A server MUST NOT use a Push ID that is larger than the client has provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST treat receipt of a DUPLICATE_PUSH that contains a larger Push ID than the client has advertised as a connection error of type HTTP_MALFORMED_FRAME. </ins> This frame allows the server to use the same server push in response to multiple concurrent requests.  Referencing the same server push


A TCP connection error is signaled with QUIC RESET_STREAM frame.  A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of <del> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it detects an error with the stream or the QUIC connection. </del> <ins> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </ins> 4.3.


bytes associated with an HTTP request or response payload. DATA frames MUST be associated with an HTTP request or response.  If <del> a DATA frame is received on either control stream, the recipient MUST </del> <ins> a DATA frame is received on a control stream, the recipient MUST </ins> respond with a connection error (errors) of type HTTP_WRONG_STREAM. 7.2.2.


HTTP/3 endpoint is authoritative for other origins without an explicit signal. <ins> Prior to making requests for an origin whose scheme is not "https," the client MUST ensure the server is willing to serve that scheme. If the client intends to make requests for an origin whose scheme is "http", this means that it MUST obtain a valid "http-opportunistic" response for the origin as described in RFC8164 prior to making any such requests.  Other schemes might define other mechanisms. </ins> A server that does not wish clients to reuse connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in


An optional reference to a specification that describes the use of the setting. <ins> The value of the setting unless otherwise indicated.  SHOULD be the most restrictive possible value. </ins> The entries in the following table are registered by this document. Additionally, each code of the format "0x1f * N + 0x21" for integer


To entities other than its intended recipient, a stateless reset will appear to be a packet with a short header.  For the stateless reset <del> to appear as a valid QUIC packet and be smaller than the received packet, the Unpredictable Bits field needs to include at least 46 bits of data (or 6 bytes, less the two fixed bits).  To ensure the stateless reset packet is not smaller than other packets received on the connection, an endpoint SHOULD also ensure the total packet length is at least the minimum chosen CID length plus 22 bytes.  22 bytes allows for 1 type byte, 4 packet number and data bytes, 16 bytes for AEAD expansion, and an extra byte to allow the peer to send a smaller stateless reset than the packet it receives. The Stateless Reset Token corresponds to the minimum expansion of the packet protection AEAD.  More unpredictable bytes might be necessary if the endpoint could have negotiated a packet protection scheme with a larger minimum AEAD expansion. An endpoint SHOULD NOT send a stateless reset that is significantly larger than the packet it receives.  Endpoints MUST discard packets that are too small to be valid QUIC packets.  With the set of AEAD functions defined in QUIC-TLS, packets that are smaller than 21 bytes are never valid. </del> <ins> to appear as a valid QUIC packet, the Unpredictable Bits field needs to include at least 38 bits of data (or 5 bytes, less the two fixed bits). A minimum size of 21 bytes does not guarantee that a stateless reset is difficult to distinguish from other packets if the recipient requires the use of a connection ID.  To prevent a resulting stateless reset from being trivially distinguishable from a valid packet, all packets sent by an endpoint SHOULD be padded to at least 22 bytes longer than the minimum connection ID that the endpoint might use.  An endpoint that sends a stateless reset in response to packet that is 43 bytes or less in length SHOULD send a stateless reset that is one byte shorter than the packet it responds to. These values assume that the Stateless Reset Token is the same as the minimum expansion of the packet protection AEAD.  Additional unpredictable bytes are necessary if the endpoint could have negotiated a packet protection scheme with a larger minimum expansion. An endpoint MUST NOT send a stateless reset that is three times or more larger than the packet it receives to avoid being used for amplification.  reset-looping describes additional limits on stateless reset size. Endpoints MUST discard packets that are too small to be valid QUIC packets.  With the set of AEAD functions defined in QUIC-TLS, packets that are smaller than 21 bytes are never valid. </ins> Endpoints MUST send stateless reset packets formatted as a packet with a short header.  However, endpoints MUST treat any packet ending


endpoint that occasionally uses different connection IDs might introduce some uncertainty about this. <del> Finally, the last 16 bytes of the packet are set to the value of the Stateless Reset Token. </del> This stateless reset design is specific to QUIC version 1.  An endpoint that supports multiple versions of QUIC needs to generate a stateless reset that will be accepted by peers that support any


delay SHOULD NOT be considered an RTT sample. Until the server has validated the client's address on the path, the <del> amount of data it can send is limited, as specified in Section 8.1 of QUIC-TRANSPORT.  Data at Initial encryption MUST be retransmitted before Handshake data and data at Handshake encryption MUST be retransmitted before any ApplicationData data.  If no data can be sent, then the PTO alarm MUST NOT be armed until data has been received from the client. </del> <ins> amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no data can be sent, then the PTO alarm MUST NOT be armed. </ins> Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to


ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. <del> It is possible that the sender has no new or previously-sent data to send.  As an example, consider the following sequence of events: new </del> <ins> When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent.  Data that was previously sent with Initial encryption MUST be sent before Handshake data and data previously sent at Handshake encryption MUST be sent before any ApplicationData data. It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new </ins> application data is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and then the original transmission is <del> acknowledged.  In the absence of any new application data, a PTO timer expiration now would find the sender with no new or previously- sent data to send. When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. </del> <ins> acknowledged.  When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. </ins> Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark any packets still in flight as lost.  Doing so avoids


versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most


4.5. <del> In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket message that contains the "early_data" extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </del> <ins> To communicate their willingness to process 0-RTT data, servers send a NewSessionTicket message that contains the "early_data" extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  Servers MUST NOT send the "early_data" extension with a max_early_data_size set to any value other than 0xffffffff.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </ins> A client that wishes to send 0-RTT packets uses the "early_data" extension in the ClientHello message of a subsequent handshake (see


migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.


not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys. <del> All frames besides ACK or PADDING are considered ack-eliciting. </del> <ins> All frames other than ACK, PADDING, and CONNECTION_CLOSE are considered ack-eliciting. </ins> Packets that contain ack-eliciting frames elicit an ACK from the receiver within the maximum ack delay and are called ack-eliciting


performance of the QUIC handshake and use shorter timers for acknowledgement. <del> Packets that contain only ACK frames do not count toward congestion control limits and are not considered in-flight. </del> <ins> Packets containing frames besides ACK or CONNECTION_CLOSE frames count toward congestion control limits and are considered in- flight. </ins> PADDING frames cause packets to contribute toward bytes in flight without directly causing an acknowledgment to be sent.


UDP datagram.  Multiple QUIC packets can be encapsulated in a single UDP datagram. <del> A QUIC packet that contains frames other than ACK and PADDING. These cause a recipient to send an acknowledgment (see sending- acknowledgements). </del> <ins> A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment (see sending-acknowledgements). </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types


Each endpoint advertises its own idle timeout to its peer.  An endpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted <del> when sending a packet containing frames other than ACK or PADDING (an ack-eliciting packet; see QUIC-RECOVERY), but only if no other ack- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </del> <ins> when sending an ack-eliciting packet (see QUIC-RECOVERY), but only if no other ack-eliciting packets have been sent since last receiving a packet.  Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the


13.2. Endpoints acknowledge all packets they receive and process.  However, <del> only ack-eliciting packets (see QUIC-RECOVERY) trigger the sending of an ACK frame.  Packets that are not ack-eliciting are only </del> <ins> only ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay.  Packets that are not ack-eliciting are only </ins> acknowledged when an ACK frame is sent for other reasons. When sending a packet for any reason, an endpoint should attempt to


The endpoint accepting incoming QUIC connections. <ins> When used without qualification, the tuple of IP version, IP address, UDP protocol, and UDP port number that represents one end of a network path. </ins> An opaque identifier that is used to identify a QUIC connection at an endpoint.  Each endpoint sets a value for its peer to include in packets sent towards the endpoint.


associated with an existing connection, or - for servers - potentially create a new connection. <del> Hosts try to associate a packet with an existing connection.  If the packet has a non-zero-length Destination Connection ID corresponding to an existing connection, QUIC processes that packet accordingly. Note that more than one connection ID can be associated with a connection; see connection-id. </del> <ins> Endpoints try to associate a packet with an existing connection.  If the packet has a non-zero-length Destination Connection ID corresponding to an existing connection, QUIC processes that packet accordingly.  Note that more than one connection ID can be associated with a connection; see connection-id. </ins> If the Destination Connection ID is zero length and the packet <del> matches the local address and port of a connection where the host </del> <ins> matches the local address and port of a connection where the endpoint </ins> used zero-length connection IDs, QUIC processes the packet as part of that connection.


perform this process as part of packet processing, but this creates a timing signal that can be used by an attacker to learn when key updates happen and thus the value of the Key Phase bit in certain <del> packets.  Endpoints SHOULD instead defer the creation of the next set of receive packet protection keys until some time after a key update </del> <ins> packets.  Endpoints MAY instead defer the creation of the next set of receive packet protection keys until some time after a key update </ins> completes, up to three times the PTO; see old-keys-recv. Once generated, the next set of packet protection keys SHOULD be


Clients MUST discard Retry packets that contain an Original Destination Connection ID field that does not match the Destination Connection ID from its Initial packet.  This prevents an off-path <del> attacker from injecting a Retry packet. </del> <ins> attacker from injecting a Retry packet.  A client MUST discard a Retry packet with a zero-length Retry Token field. </ins> The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection


4.2. <del> This document leaves when and how many bytes to advertise in a MAX_STREAM_DATA or MAX_DATA frame to implementations, but offers a few considerations.  These frames contribute to connection overhead. Therefore frequently sending frames with small changes is undesirable.  At the same time, larger increments to limits are necessary to avoid blocking if updates are less frequent, requiring larger resource commitments at the receiver.  Thus there is a trade- off between resource commitment and overhead when determining how large a limit is advertised. </del> <ins> Implementations decide when and how much credit to advertise in MAX_STREAM_DATA and MAX_DATA frames, but this section offers a few considerations. To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or MAX_DATA frame multiple times within a round trip or send it early enough to allow for recovery from loss of the frame. Control frames contribute to connection overhead.  Therefore, frequently sending MAX_STREAM_DATA and MAX_DATA frames with small changes is undesirable.  On the other hand, if updates are less frequent, larger increments to limits are necessary to avoid blocking a sender, requiring larger resource commitments at the receiver. There is a trade-off between resource commitment and overhead when determining how large a limit is advertised. </ins> A receiver can use an autotuning mechanism to tune the frequency and amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes <del> data, similar to common TCP implementations.  As an optimization, sending frames related to flow control only when there are other frames to send or when a peer is blocked ensures that flow control doesn't cause extra packets to be sent. If a sender runs out of flow control credit, it will be unable to send new data and is considered blocked.  It is generally considered best to not let the sender become blocked.  To avoid blocking a sender, and to reasonably account for the possibility of loss, a receiver should send a MAX_DATA or MAX_STREAM_DATA frame at least two round trips before it expects the sender to get blocked. A receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending MAX_STREAM_DATA or MAX_DATA, since doing so will mean that a sender will be blocked for at least an entire round trip, and potentially for longer if the peer chooses to not send STREAM_DATA_BLOCKED or DATA_BLOCKED frames. </del> <ins> data, similar to common TCP implementations.  As an optimization, an endpoint could send frames related to flow control only when there are other frames to send or when a peer is blocked, ensuring that flow control does not cause extra packets to be sent. A blocked sender is not required to send STREAM_DATA_BLOCKED or DATA_BLOCKED frames.  Therefore, a receiver MUST NOT wait for a STREAM_DATA_BLOCKED or DATA_BLOCKED frame before sending a MAX_STREAM_DATA or MAX_DATA frame; doing so could result in the sender being blocked for the rest of the connection.  Even if the sender sends these frames, waiting for them will result in the sender being blocked for at least an entire round trip. When a sender receives credit after being blocked, it might be able to send a large amount of data in response, resulting in short-term congestion; see Section 6.9 in QUIC-RECOVERY for a discussion of how a sender can avoid this congestion. </ins> 4.3.


acknowledgment (see sending-acknowledgements). A packet that does not increase the largest received packet number <del> for its packet number space by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </del> <ins> for its packet number space (packet-numbers) by exactly one.  A packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types


An endpoint can verify support for Explicit Congestion Notification (ECN) in the first packets it sends, as described in ecn-validation. <del> The CRYPTO frame can be sent in different packet number spaces.  The sequence numbers used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in each packet number space. </del> <ins> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The sequence numbers used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in each packet number space. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol


The Frame Type field uses a variable length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient implementations of frame parsing, a frame type MUST use the shortest <del> possible encoding.  Though a two-, four- or eight-byte encoding of the frame types defined in this document is possible, the Frame Type field for these frames is encoded on a single byte.  For instance, though 0x4001 is a legitimate two-byte encoding for a variable-length integer with a value of 1, PING frames are always encoded as a single byte with the value 0x01.  An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION. </del> <ins> possible encoding.  For frame types defined in this document, this means a single-byte encoding, even though it is possible to encode these values as a two-, four- or eight-byte variable length integer. For instance, though 0x4001 is a legitimate two-byte encoding for a variable-length integer with a value of 1, PING frames are always encoded as a single byte with the value 0x01.  This rule applies to all current and future QUIC frame types.  An endpoint MAY treat the receipt of a frame type that uses a longer encoding than necessary as a connection error of type PROTOCOL_VIOLATION. </ins> 13.


server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, <del> clients SHOULD send a packet upon a probe timeout, as described in </del> <ins> clients MUST send a packet upon a probe timeout, as described in </ins> QUIC-RECOVERY.  If the client has no data to retransmit and does not <del> have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet


the server is not overly constrained by the amplification restriction. <del> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, clients MUST send a packet upon a probe timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets.  A deadlock could occur when the server reaches its anti- amplification limit and the client has received acknowledgements for all the data it has sent.  In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address.  To prevent this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section 5.3 of QUIC-RECOVERY).  Specifically, the client MUST send an Initial packet in a UDP datagram of at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet


6.6. During the handshake, some packet protection keys might not be <del> available when a packet arrives.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive, and 1-RTT packets cannot be processed until the handshake completes. Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the peer has packet protection keys to process those packets. </del> <ins> available when a packet arrives and the receiver can choose to drop the packet.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive and 1-RTT packets cannot be processed until the handshake completes.  Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived before the peer had packet protection keys to process those packets. Endpoints MUST NOT ignore the loss of packets that were sent after the earliest acknowledged packet in a given packet number space. </ins> 6.7.


layer.  By providing reliability at the stream level and congestion control across the entire connection, it has the capability to improve the performance of HTTP compared to a TCP mapping.  QUIC also <del> incorporates TLS 1.3 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open RFC7413. </del> <ins> incorporates TLS 1.3 TLS13 at the transport layer, offering comparable security to running TLS over TCP, with the improved connection setup latency of TCP Fast Open TFO. </ins> This document defines a mapping of HTTP semantics over the QUIC transport protocol, drawing heavily on the design of HTTP/2.  While


unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an <del> acknowledgement for one of its Handshake or 1-RTT packets. </del> <ins> acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to


An ACK frame SHOULD be generated for at least every second ack- eliciting packet.  This recommendation is in keeping with standard <del> practice for TCP RFC5681. </del> <ins> practice for TCP RFC5681.  A receiver could decide to send an ACK frame less frequently if it has information about how frequently the sender's congestion controller needs feedback, or if the receiver is CPU or bandwidth constrained. </ins> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet


An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously <del> received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID. </del> <ins> received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. </ins> 19.16.


connection ID when the client initiates migration to the preferred address. <ins> The Connection ID and Stateless Reset Token fields of a preferred address are identical in syntax and semantics to the corresponding fields of a NEW_CONNECTION_ID frame (frame-new-connection-id).  A server that chooses a zero-length connection ID MUST NOT provide a preferred address.  Similarly, a server MUST NOT include a zero- length connection ID in this transport parameter.  A client MUST treat violation of these requirements as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> The active connection ID limit is an integer value specifying the maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received


approach 2^(-L/2), that is, the birthday bound.  For the algorithms described in this document, that probability is one in 2^64. <del> In some cases, inputs shorter than the full size required by the packet protection algorithm might be used. </del> To prevent an attacker from modifying packet headers, the header is transitively authenticated using packet protection; the entire packet header is part of the authenticated additional data.  Protected


A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  An endpoint MAY <del> send multiple GOAWAY frames indicating different identifiers, but MUST NOT increase the identifier value they send, since clients might already have retried unprocessed requests on another connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </del> <ins> send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another connection.  Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </ins> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible


receipt by sending one or more ACK frames containing the packet number of the received packet. <ins> An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. </ins> 13.2. Endpoints acknowledge all packets they receive and process.  However,


receiver's max_ack_delay value in determining timeouts for timer- based retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY. <del> An ACK frame SHOULD be generated for at least every second ack- eliciting packet.  This recommendation is in keeping with standard practice for TCP RFC5681.  A receiver could decide to send an ACK frame less frequently if it has information about how frequently the sender's congestion controller needs feedback, or if the receiver is CPU or bandwidth constrained. </del> <ins> Since packets containing only ACK frames are not congestion controlled, an endpoint MUST NOT send more than one such packet in response to receiving an ack-eliciting packet. An endpoint MUST NOT send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet.  This avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  Non-ack-eliciting packets are eventually acknowledged when the endpoint sends an ACK frame in response to other events. </ins> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet


codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. <del> As an optimization, a receiver MAY process multiple packets before sending any ACK frames in response.  In this case the receiver can determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING frames might cause the sender to become limited by the congestion controller with no acknowledgments forthcoming from the receiver. Therefore, a sender SHOULD ensure that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver. </del> <ins> The algorithms in QUIC-RECOVERY are expected to be resilient to receivers that do not follow guidance offered above.  However, an implementer should only deviate from these requirements after careful consideration of the performance implications of doing so. </ins> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgements are


be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to bundle an ACK frame with outgoing frames. <del> The algorithms in QUIC-RECOVERY are resilient to receivers that do not follow guidance offered above.  However, an implementor should only deviate from these requirements after careful consideration of the performance implications of doing so. Packets containing only ACK frames are not congestion controlled, so there are limits on how frequently they can be sent.  An endpoint MUST NOT send more than one ACK-frame-only packet in response to receiving an ack-eliciting packet.  An endpoint MUST NOT send a non- ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet.  Limiting ACK frames avoids an infinite feedback loop of acknowledgements, which could prevent the connection from ever becoming idle.  However, the endpoint acknowledges non-ACK-eliciting packets when it sends an ACK frame. </del> <ins> 13.2.2. </ins> <del> An endpoint SHOULD treat receipt of an acknowledgment for a packet it did not send as a connection error of type PROTOCOL_VIOLATION, if it is able to detect the condition. </del> <ins> A receiver determines how frequently to send acknowledgements in response to ack-eliciting packets.  This determination involves a tradeoff. </ins> <del> 13.2.2. </del> <ins> Endpoints rely on timely acknowledgment to detect loss; see Section 5 of QUIC-RECOVERY.  Window-based congestion controllers, such as the one in Section 6 of QUIC-RECOVERY, rely on acknowledgments to manage their congestion window.  In both cases, delaying acknowledgments can adversely affect performance. On the other hand, reducing the frequency of packets that carry only acknowledgements reduces packet transmission and processing cost at both endpoints.  It can also improve connection throughput on severely asymmetric links; see Section 3 of RFC3449. A receiver SHOULD send an ACK frame after receiving at least two ack- eliciting packets.  This recommendation is general in nature and consistent with recommendations for TCP endpoint behavior RFC5681. Knowledge of network conditions, knowledge of the peer's congestion controller, or further research and experimentation might suggest alternative acknowledgment strategies with better performance characteristics. A receiver MAY process multiple available packets before determining whether to send an ACK frame in response. 13.2.3. </ins> When an ACK frame is sent, one or more ranges of acknowledged packets are included.  Including older packets reduces the chance of spurious


acknowledgments to be lost.  A sender cannot expect to receive an acknowledgment for every packet that the receiver processes. <del> 13.2.3. </del> <ins> 13.2.4. </ins> When a packet containing an ACK frame is sent, the largest acknowledged in that frame may be saved.  When a packet containing an


algorithm could cause spurious retransmits, but the sender will continue making forward progress. <del> 13.2.4. </del> <ins> 13.2.5. </ins> A receiver limits the number of ACK Ranges (ack-ranges) it remembers and sends in ACK frames, both to limit the size of ACK frames and to


that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. <del> 13.2.5. </del> <ins> 13.2.6. </ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the


NOT include delays that it does not control when populating the Ack Delay field in an ACK frame. <del> 13.2.6. </del> <ins> 13.2.7. </ins> ACK frames MUST only be carried in a packet that has the same packet number space as the packet being ACKed; see packet-protected.  For


Note that the same limitation applies to other data sent by the server protected by the 1-RTT keys. <ins> 13.2.8. Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Packets containing only PADDING frames therefore consume congestion window but do not generate acknowledgments that will open the congestion window.  To avoid a deadlock, a sender SHOULD ensure that other frames are sent periodically in addition to PADDING frames to elicit acknowledgments from the receiver. </ins> 13.3. QUIC packets that are determined to be lost are not retransmitted


opening of either the send or receive side causes the stream to open in both directions. <del> An endpoint MUST open streams of the same type in increasing order of stream ID. </del> These states are largely informative.  This document uses stream states to describe rules for when and how different types of frames can be sent and the reactions that are expected when


a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. <del> Note that receipt on a different local address does not result in path validation failure, as it might be a result of a forwarded packet (see off-path-forward) or misrouting.  It is possible that a valid PATH_RESPONSE might be received in the future. </del> 8.6. Path validation only fails when the endpoint attempting to validate


Receiving acknowledgments for data sent on the new path serves as proof of the peer's reachability from the new address.  Note that since acknowledgments may be received on any path, return <del> reachability on the new path is not established.  To establish return </del> <ins> reachability on the new path is not established.  No method is provided to establish return reachability, as endpoints independently determine reachability on each direction of a path.  To establish </ins> reachability on the new path, an endpoint MAY concurrently initiate <del> path validation migrate-validate on the new path or it MAY choose to wait for the peer to send the next non-probing frame to its new address. </del> <ins> path validation migrate-validate on the new path.  An endpoint MAY defer path validation until after a peer sends the next non-probing frame to its new address. </ins> 9.3.


4.1.4. <del> As keys for new encryption levels become available, TLS provides QUIC with those keys.  Separately, as keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del> <ins> As keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </ins> TLS provides QUIC with three items as a new encryption level becomes available:


CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting <del> amplification attack, such endpoints MUST reduce the frequency with which it sends packets containing a CONNECTION_CLOSE frame.  To minimize the state that an endpoint maintains for a closing </del> <ins> amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing </ins> connection, endpoints MAY send the exact same packet. Allowing retransmission of a closing packet is an exception to the


likely the receiver will be able to process all the packets in a single pass.  A packet with a short header does not include a length, so it can only be the last packet included in a UDP datagram.  An <del> endpoint SHOULD NOT coalesce multiple packets at the same encryption level. </del> <ins> endpoint SHOULD include multiple frames in a single packet if they are to be sent at the same encryption level, instead of coalescing multiple packets at the same encryption level. </ins> Receivers MAY route based on the information in the first packet contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets


the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT. <del> Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, clients can </del> <ins> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can </ins> coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.


outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. <ins> A sender SHOULD avoid retransmitting information from packets once they are acknowledged.  This includes packets that are acknowledged after being declared lost, which can happen in the presence of network reordering.  Doing so requires senders to retain information about packets after they are declared lost.  A sender can discard this information after a period of time elapses that adequately allows for reordering, such as a PTO (Section 6.2 of QUIC-RECOVERY), or on other events, such as reaching a memory limit. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.


be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. <ins> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </ins> 13.2.2. A receiver determines how frequently to send acknowledgements in