present. The long header exposes more information.  It is used during <del> connection establishment, including version negotiation, server retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. Short headers are used after connection establishment.  The only information they contain for inspection on the path is an optional, variable-length destination connection ID. As of draft version 13 of the QUIC transport document, the following information may be exposed in QUIC packet headers: header type: the long header has a 7-bit packet type field </del>  following the Header Form bit.  Header types correspond to stages <del> of the handshake; see Section 4.1 of QUIC-TRANSPORT. </del>  <del> version number: The version number is present in the long header, and identifies the version used for that packet.  Note that during Version Negotiation (see version, and Section 4.3 of QUIC- </del>  TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation packet. <del> source and destination connection ID: The source and destination connection IDs are variable-length fields that can be used to identify the connection associated with a QUIC packet, for load- balancing and NAT rebinding purposes; see sec-loadbalancing and rebinding.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long packet headers.  The destination connection ID, if present, is present on both long and short header packets.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </del>  length: the length of the remaining quic packet after the length field, present on long headers.  This field is used to implement coalesced packets during the handshake (see coalesced). <del> packet number: Every packet has an associated packet number; </del>  however, this packet number is encrypted, and therefore not of use <del> to on-path observers.  This packet number has a fixed location and length in long headers, and an implicit location and encrypted variable length in short headers. </del>  <del> key phase: The Key Phase bit, present in short headers identifies the key used to encrypt the packet during key rotation. </del>  2.2. connection ID for the lifetime of the connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See <del> Section 6.1 of QUIC-TRANSPORT. </del>  2.7. flow is using QUIC based upon a UDP port number may therefore not hold; see also RFC7605 section 5.  3.1.1. An in-network observer assuming that a set of packets belongs to a 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before <del> the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </del>  3.3. when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. <del> The connection ID to be used for a long-running flow is chosen by the server (see QUIC-TRANSPORT section 5.6) during the handshake.  This value should be treated as opaque; see sec-loadbalancing for caveats regarding connection ID selection at servers. </del>  3.5. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the <del> handshake, as illustrated in handshake. </del>  In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS necessarily includes any transport and application layer delay at both sides. <del> The spin bit experiment, detailed in QUIC-SPIN, provides an additional method to measure intraflow per-flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit described in that document changes value once per round-trip time (RTT).  An on-path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del>  An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit

Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.

present. The long header exposes more information.  It is used during  <ins> connection establishment, including version negotiation, retry, and 0-RTT data.  It contains a version number, as well as source and destination connection IDs for grouping packets belonging to the same flow.  The definition and location of these fields in the QUIC long header are invariant for future versions of QUIC, although future versions of QUIC may provide additional fields in the long header QUIC-INVARIANTS. Short headers are used after connection establishment, and contain only an optional destination connection ID and the spin bit for RTT measurement. The following information is exposed in QUIC packet headers: demux bit: the second most significant bit of the first octet every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. header type: the long header has a 2 bit packet type field </ins> following the Header Form bit.  Header types correspond to stages  <ins> of the handshake; see Section 17.2 of QUIC-TRANSPORT. </ins>  <ins> version number: the version number present in the long header, and identifies the version used for that packet.  Note that during Version Negotiation (see version, and Section 17.2.1 of QUIC- </ins> TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation packet.  <ins> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field that can be used to identify the connection associated with a QUIC packet, for load-balancing and NAT rebinding purposes; see sec- loadbalancing and rebinding.  Long packet headers additionally carry a source connection ID.  The source connection ID corresponds to the destination connection ID the source would like to have on packets sent to it, and is only present on long packet headers.  On long header packets, the length of the connection IDs is also present; on short header packets, the length of the destination connection ID is implicit. </ins> length: the length of the remaining quic packet after the length field, present on long headers.  This field is used to implement coalesced packets during the handshake (see coalesced).  <ins> spin bit: the spin bit supports passive measurement of RTT, and is present on QUIC short packet headers.  See sec-rtt. token: Initial packets may contain a token, a variable-length opaque value optionally sent from client to server, used for validating the client's address.  Retry packets also contain a token, which can be used by the client in an Initial packet on a subsequent connection attempt.  The length of the token is explicit in both cases. Retry and Version Negotiation packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: packet number: Most packets (with the exception of Version Negotiation and Retry packets) have an associated packet number; </ins> however, this packet number is encrypted, and therefore not of use  <ins> to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit (depending on Destination Connection ID length) in short header packets.  The length of the packet number is cryptographically obfuscated. </ins>  <ins> key phase: The Key Phase bit, present in short headers, specifies the keys used to encrypt the packet, supporting key rotation.  The Key Phase bit is cryptographically obfuscated. </ins> 2.2. connection ID for the lifetime of the connection.  Connection IDs for either endpoint may change during the lifetime of a connection, with the new connection ID being negotiated via encrypted frames.  See  <ins> Section 5.1 of QUIC-TRANSPORT. </ins> 2.7. flow is using QUIC based upon a UDP port number may therefore not hold; see also RFC7605 section 5. <ins> While the second most significant bit (0x40) of the first octet is always set to 1 in QUIC packets of the current version, this is not a recommended method of recognizing QUIC traffic, as it only provides one bit of information and is quite prone to collide with UDP-based protocols other than those that this static bit is meant to allow multiplexing with. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before  <ins> the Initial packet. Note that clients send Initial packets before servers do, servers send Handshake packets before clients do, and only clients send Initial packets with tokens, so the sides of a connection can be generally be confirmed by an on-path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet. </ins> 3.3. when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow.  <ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is encrypted, packets with the same 5-tuple but different connection IDs may or may not belong to the same connection. The connection ID value should be treated as opaque; see sec- loadbalancing for caveats regarding connection ID selection at servers. </ins> 3.5. Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the  <ins> handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in QUIC-SPIN. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS necessarily includes any transport and application layer delay at both sides.  <ins> The spin bit provides an additional method to measure intraflow per- flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit on short header packets changes value once per round-trip time (RTT).  An on- path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end- to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </ins> An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit


1.1. <del> The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document.  It's not shouting; when these words are capitalized, they have a special meaning as defined in RFC2119. </del>  2. 4.5.  [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on

...addressing NAME
Middlebox vendors (and others as well) used to TCP want to assume that the smallest packet might be ack packets. This is not true in QUIC, and manageabiity draft may want to say something about it.
Thanks for writing this up!

1.1.  <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2. 4.5. <ins> Some deployed in-network functions distinguish pure-acknowledgment (ACK) packets from packets carrying upper-layer data in order to attempt to enhance performance, for example by queueing ACKs differently or manipulating ACK signaling.  Distinguishing ACK packets is trivial in TCP, but not supported by QUIC, since acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. 4.6. </ins> [EDITOR'S NOTE: this is a bit speculative; keep?] QUIC does not provide any additional information on requirements on


every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. <del> latency spin bit: the third most significant bit of first octet. However, the is only used in short packet headers.  There it will be set alternatingly to 0 or 1 by the endpoints such that tracking edge transistions can be used to passively monitor the connection RTT, see spin-usage for further details. </del>  header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages

Review and update text in -manageability to reflect BKK spin bit consensus: single spin bit is in the protocol spec now endpoints may opt out (discuss why; this is for any reason, not just proxies as suggested in ), endpoints should probabilistically out out to provide cover for endpoints opting out
I am working on this.
NAME what about having a privacy consideration section ?
I'm not sure this fits in the scope of the document: can you say more about what you propose to be in this section? The -manageability document is meant to be an independent user's guide to the wire image, so information on the spin bit here will be more about how to measure it, not additional guidelines on how to generate it and when not to (though such text might belong in -applicability) Please coordinate with NAME who will also be proposing text on spin measurement to bring over from draft-ietf-quic-spin-exp.
see PR
closed by merge of and

every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols.  <ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such that tracking edge transitions can be used to passively observe end-to-end RTT.  See spin-usage for further details. </ins> header type: the long header has a 2 bit packet type field following the Header Form bit.  Header types correspond to stages


6. <del> [EDITOR'S NOTE: give some guidance here about the steps an application should take; however this is still work in progress] </del>  7.

This section was still empty so far. This PR also address issue .
This is related to quicwg/base-drafts and depends on the outcome there.
PR now indicated that the idle timeout could be exposed to the application. However, we should probably say a bit more what to do with it. I guess the minimum would be to say that the keep-alive frequency needs to be clearly smaller than the idle timeout, e.g. half the timeout. Is there anything more we could say? NAME NAME any thoughts? Or text you can provide?
PR provides some more guidance now but it still doesn't discuss suitable value or ranges. What values are used in current implementations? Should we say more?
See also PR
merged
This is good, modulo typos (all edits as suggestions)

6.  <ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead to connection closure, and one for closures initiated by the application.  An application using QUIC can define application- specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of a grateful shut-down initiated by the application after application layer negotiation, a NO_ERROR code is expected.  Further, the CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code.  Note that QUIC RESET_STREAM and STOP_SENDING frames provide similar capablities.  Usually application error codes are defined to be applicabile to all three frames. Alternatively, a QUIC connection will be silently closed by each endpoint separately after an idle timeout.  The idle timeout is announce for each endpoint during connection established and should be accessible by the application.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. </ins> 7.


7.  QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. <del> 8. </del>  QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established, Connection IDs), the short header exposes at most only a single Connection ID. <del> 8.1. </del>  QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 8.2. </del>  While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 8.3. </del>  QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 9. </del>  Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 10. </del>  QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted. <del> 11. </del>  This document has no actions for IANA. <del> 12. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 13. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos

7. <ins> QUIC supports connection migration.  Even if lower-layer addresses (usually the 4-tuple of IP addresses and ports) changes, QUIC packets can still be associated with an existing connection based on the Connection ID (see also section connid) in the QUIC header, if present.  This supports cases where address information changes due to e.g.  NAT rebinding or change of the local interface.  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and as soon as the new path is validated all traffic will be switched over to the next path. 8. </ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be send keep-alives messages.  See {#resumption-v-keepalive} for further guidance.  <ins> 9. </ins> QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established, Connection IDs), the short header exposes at most only a single Connection ID.  <ins> 9.1. </ins> QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  <ins> 9.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means.  <ins> 9.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new that the load balancer will redirect the next Client Initial packet to a different server in that pool.  <ins> 10. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes.  <ins> 11. </ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server version in Version Negotiation packets, then the old version is no longer accepted.  <ins> 12. </ins> This document has no actions for IANA.  <ins> 13. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  <ins> 14. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture


also discusses how common network management practices will be impacted by QUIC. <del> Of course, network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be </del>  impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, In this section, we discusses those aspects of the QUIC transport protocol that have an impact on the design and operation of devices <del> that forward QUIC packets.  Here, we are concerned primarily with QUIC's unencrypted wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </del>  protocol, the wire image of the header format can also change from version to version.  However, at least the mechanism by which a receiver can determine which version is used and the meaning and

Feel free to close this if it's out of scope, but creating a proxy that attempts to passively observe QUIC is much more complex and potentially problematic than TLS over TCP. For example, all major OS's have mature TCP implementations, whereas a MITM would have to pull in its own QUIC implementation. If it does so, it would be important that's it's both conformant to IETF specifications and have good performance. This is the full L7 termination case, which is possible, but a lot of work, and we should heavily encourage anyone doing this to use an existing("good") implementation. A potential MITM option is to attempt to terminate the handshake, but then only observe ApplicationData packets. However, this could go wrong in many ways, so I believe it should be strongly discouraged. QUIC is designed as an end-to-end protocol and efforts to change that are likely to end very poorly. For example, if the length of the CID changes, then the offset of the header changes and a middlebox who doesn't track all CIDs both peers may be unable to decrypt packets. I'm sure there are more gotchas, particularly with the introduction of extensions. It may also be worth pointing out that QUIC frames are not TLV, so any frames(ie: extensions) that are not understood cause all other frames to be unparseable. Thanks to NAME for the specific examples of ways this could fail.
Still trying to figure out what my thinking is her, but it sounds a bit like you propose something like "If you want to implement a QUIC MITM, please terminate the whole connection up to L7 and use an existing library." Note sure that is actually giving quite there right message....
As a user's guide to the wire image, one of the base assumptions we make is that access to the wire image is read only. We should definitely be more explicit about this. We also need an explicit statement that MITM is out of scope for this doc and if you want to, terminate at L7 and congrats, now everything in -transport and -tls (and, realisitically, -http) applies.

also discusses how common network management practices will be impacted by QUIC.  <ins> Since QUIC's wire image WIRE-IMAGE is integrity protected and not modifiable on path, in-network operations are not possible without terminating the QUIC connection, for instance using a back-to-back proxy.  Proxy operations are not in scope for this document.  QUIC proxies must be fully-fledged QUIC endpoints, implementing the transport as defined in QUIC-TRANSPORT and QUIC-TLS as well as proxy- relevant semantics for the application(s) running over QUIC (e.g. HTTP/3 as defined in QUIC-HTTP). Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be </ins> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, In this section, we discusses those aspects of the QUIC transport protocol that have an impact on the design and operation of devices  <ins> that forward QUIC packets.  Here, we are concerned primarily with the unencrypted part of QUIC's wire image WIRE-IMAGE, which we define as the information available in the packet header in each QUIC packet, and the dynamics of that information.  Since QUIC is a versioned </ins> protocol, the wire image of the header format can also change from version to version.  However, at least the mechanism by which a receiver can determine which version is used and the meaning and


either through timers or through least-recently-used eviction, depending on application requirements.  4.2. Limited RTT measurement is possible by passive observation of QUIC

addresses issue
See .
ISTM that this might also be an applicability thing as the "easy" solution involves the firewall to share state with the LB/frontend (with all the scalability impact that entails).
PR add a little more text here. Please provide another PR if you think more text is needed!
PR merged Hello WG, Consider, please, the following use case in your spare time: An access network (to simplify things) doesn't host any listening ports but rather just provides access to individual users. Some of the users, or the network itself, have DDoS attacks in their threat model. To address that, the network deploys a stateful firewall on or close to its border, far away from the last mile that could get congested. The said firewall doesn't allow incoming traffic towards the user machines, except for the packets belonging to connections initiated from the inside. For the sake of simplicity, let's treat the bandwidth on the border and computational resources of the firewall to be sufficient for processing any incoming traffic. With the Internet transport protocols of 1970s, one of the possible attack scenarios would then be to generate a large number of packers per second with a 5-tuple equal to a connection already existing on the firewall. In real life scenarios, an off-path attacker already knows 4 of 5-tuple parameters and just needs to guess the source port number a client has chosen to connect. The entropy is then generally limited to just 15 bits, which is believed to be not enough for proper protection of long-living sessions given the attack bandwidth levels observed today. In theory, the attacker also needs a side channel to figure out whether or not they have guessed the port already. In practice, the attacker usually does have such a side channel. E.g. during an online gaming tournament if one of the competing players experiences a connectivity problem it almost immediately becomes obvious for anyone. However, with TCP, we have SEQ and ACK numbers, which both add greatly to the entropy of a 5-tuple. (And, yes, in reality you cannot rely on proper SEQ randomness of a network client or server, but that's another story). The issue might be UDP, but in practice either the UDP "session" is expected to be very short-lived (DNS, NTP, etc.), or the protocol is not mission critical, or the protocol exposes a stable part in the layer 7 header which could also be used for reliable connection tracking. You'll have, however, to implement specific modules for each such a protocol. (In fact, the rest of the protocols you don't know what to do with could then just go through a fixed pipe with a bandwidth rate limit much below anything that you might have at the last mile.) What I was going to ask for is an advice on how could such a threat model be addressed if a client connects to a QUIC server. My first intention was to write down connection IDs, but it turns out those may change at will. The rest of the (long, let alone short) header is fixed. (I'm also present onsite in BKK, if that's easier for someone to ask for any clarifications or explanations this way) Thanks, | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: EMAIL | fb: ximaera | telegram: ximaera | skype: ximaera | tel. no: +7 916 515 49 58

either through timers or through least-recently-used eviction, depending on application requirements. <ins> The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the Connection ID is present and what length it has. </ins> 4.2. Limited RTT measurement is possible by passive observation of QUIC


The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has. </del>  4.2.

At Gorry's suggestion I put the NAT guidance into a different draft: URL Sorry, I thought the notification went out automatically. Regardless, this change is fine.
The manageability draft should talk a little bit about NATS for QUIC. The laziest thing to do is just continue to have NAT mapping be by 4-tuple, as it is today. This is actually fine. However, someone might attempt to be clever and use the CID as well. For example, client A and client B could share the same serverside address and port and the NAT can initially distinguish between the two because they have different CIDs. This appears to save address space, but doesn't actually work because the server could switch to a new client connection ID. In this case, the NAT won't be able to determine which client to route to.
I think it's also worth mentioning that using just the CID only is similarly broken, the fundamental underlying concept here is that subsequent CIDs are exchanged in a manner that the NAT cannot see -- the only time it's okay to use CIDs is if you're colluding with one of the endpoints, as in QUIC LB.
At least recommend to use longer binding lifetimes for identified QUIC connections?
See PR
Fixed in this doc by
Looks good to me. It might be worth adding a bit more (see my detailed comment).

The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the  <ins> Connection ID is present and what length it has.  However, Connection IDs may be renegotiated during a connection, and this renegotiation is not visible to the path.  Keying state off the Connection ID may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  Use of Connection ID specifically discouraged for NAT applications. </ins> 4.2.


routability.  Therefore changing these information will also cause the connection to fail.  3. This section addresses the different kinds of observations and

when merged.
See also issue quicwg/base-drafts
Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible. However, if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version (similar as TLS1.3 does); of course there is a performance/overhead trade-off. With the uncertainty about what will happen in respect to ossification, it might not be worth is to try and solve the problem now and pay the complexity up front.
does not appear as though the discussion on the list has converged yet; will wait to see at happens in the base drafts before addressing this one in ops.
Consensus to handle "weak" version ossification via a mechanism in the transport; holding this issue open until that converges, but probably not useful to have text in manageability.
This converged in Singapore to no-action in v1.
Fixed by
My comments left the lines >80 characters, but otherwise LGI'm wondering if we should use even stronger language; not that anything can really enforce it.

routability.  Therefore changing these information will also cause the connection to fail. <ins> QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed in the Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the multi-year timeframe so therefore not recommended. </ins> 3. This section addresses the different kinds of observations and


classification step. Note that the use of a connection ID to support connection migration <del> renders 5-tuple based filtering insufficient, and requires more state to be maintained by DDoS defense systems, and linkability resistance in connection ID update mechanisms means that a connection ID aware DDoS defense system must have the same information about flows as the load balancer. However, it is questionable if connection migrations needs to be supported in a DDOS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  However, a defense system might simply rely on the fast resumption mechanism provided by QUIC. </del>  4.5.

This PR describes how a stateful DDoS system may link flows after a NAT rebinding event. Also, the PR adds a section on how to police QUIC packets to minimize disruption to application that are able to failover to TCP. Namely, avoid blocking a random fraction of UDP packets and, instead, focus on either blocking all packets from a subset of users or none at all. This is related to areas discussed in .
There's no mention of the QUIC Retry mechanism here. At the very least, for long header packets, a cooperating DDoS protection device can maintain a white-list of peer IP addresses, and only let through those addresses that successfully go through the Retry scenario. The question then is what to do with short header packets. The backend server will not have any connection state for any junk short header packets, so the server should either quickly discard the packet silently or send a stateless reset if it happens to look like a valid QUIC packet. Assuming the short header packet traffic is enough to overwhelm the server, then this PR's text would come into play. Though it'd be interesting to see some perf numbers on what kind of CPU cost there is to just reject these packets. From my previous tests with the QUIC server running in the Windows kernel, the network was the limiting factor in these type of attacks, not the CPU. So if the network is the bottleneck, does it really matter if you drop it at the server or just in front of it?
NAME I think this section could be expanded a lot more, and Retry mechanism with a cooperating DDoS protection device definitely has a place. I am happy to give it a try in a different PR, or I can leave it to you, since you've likely thought more about this topic. The cooperation should include an agreement on the format of the Token to: For a Retry tokens generated by DDoS protection device, decode originaldestinationconnectionid. DDoS protection device to understand and validate server's token provided by a NEWTOKEN frame DDoS protection device to understand and validate server's Retry tokens As for the CPU cost, this consideration only comes into play, if the attack was allowed to reach backend servers. Volumetric DDoS can saturate network links and/or be targeting networking infrastructure and not just backend servers. As NAME is saying in , volumetric attacks are often mitigated further away from the edge of the network. This kind of mitigation is the focus of UDP Policing section.
Looks like URL is an excellent discussion of Retry mechanics. It definitely deserves a reference from this doc. The Retry mechanisms described in LB draft are all cooperating boxes, and servers are aware of them. Unfortunately, Retry system protects only server's memory state and some CPU cycles spent on crypto. (Servers still need to decrypt CID to decide it is invalid, and if the attacker is clever enough to establish one valid connection and use that CID in a flood, the server will also be decrypting packets.) Retry does nothing to protect network resources. This PR is about transparent boxes that try to mitigate volumetric attacks.
As noted in discussion on .
Quoting:
PR
This is not how it works. A few examples: URL URL
I'm not sure I see support for "this is not how it works" in your examples: SYN cookies on their own are a 1990s technique for end-system DoS prevention, which, while useful at transport-terminating front ends as part of a larger DoS prevention strategy, aren't really usable on their own at scale. The paper you link to here (from ICWET, and itself a decade old) primarily deals with the separation of good from bad flows at layer 7, not necessarily how the front-end handles these flows once classified. But you're definitely right that this is not only how it works: the DoS mitigation landscape is wide and varied (even if at the end of the day the only strategy we have found to work at scale is "eat the DoS". That said, this text could be improved: it discounts detection and classification mechanisms other than based on flow designators derived from passive measurement, does not mention protocols other than IPFIX and the flow model that comes along with it when classifying traffic, etc. The text should also be more applicable to UDP reflection DoS, which is a primary concern in wire image differentiation in QUIC (and which also isn't otherwise addressed in the document or in this issue). Adding a path-observable SYN cookie equivalent to QUIC, while useful, seems difficult to achieve given the working group's history of consensus about path-observable wire image features, so other classification mechanisms are what we'll be left with.
Exactly my point. The passive measurements are generally only useful to prevent the collateral damage to the network infrastructure of an ISP or a datacenter network under an attack. While the infrastructure impact of QUIC is itself an intriguing research topic, DDoS affects not only transit networks but also the endpoints in ways that could not be prevented with any passive flow classification.
The intent of this section is to cover DoS mitigation on the "downstream" segment, all the way from transit to endpoint, with access and front-end networks in between; the further you get from the endpoint the harder classification is, but the larger the impact of filtering operations. AIUI transit networks generally only get involved at the BGP level (i.e., when an affected destination prefix is temporarily announced via a mitigation/filtering network to route traffic for scrubbing), but we shouldn't look at just the endpoint/frontend, either, This document probably shouldn't go all the way down the DoS prevention architecture rabbithole (note to self: check to see whether DOTS has something we can refer to here). But I'll put some effort into making this more general.
This is more of an "e.g." than "i.e.", but fine. I must say this is also a place where the infrastructure could be affected by the HTTP protocol upgrade. E.g. if the risk model assumes large transport layer floods, then the optical links towards the scrubbing center should be upgraded to carry ~22x more traffic.
actually, no; improve section 4.4 as well.
Err. "Current practices in detection and mitigation of Distributed Denial of Service (DDoS) attacks generally involves classification of incoming traffic (as packets, flows, or some other aggregate) into "good" (productive) and "bad" (DDoS) traffic" No. It generally does not. There are active and passive countermeasures, there are SYN cookies, truncated DNS responses, captchas, etc. The draft is still missing all of those.
I think what is still missing is to note that this document is generally scoped to in-network manageability and therefore does not discuss measures that can be applied directly at the end hosts. Maybe we can clarify this by add one simple word like this: s/Current practices in detection and mitigation/Current in-network practices in detection and mitigation/ ?
No, this is still not fair. Active countermeasures like SYN proxying still belong to the network. Probably the only way to do this properly would be to say that "Current practices in passive detection and mitigation" do whatever they do, and to add later in the section that there are also practices in active mitigation which are not supported by the protocol (the last paragraph basically sums it up) when the endpoint is not cooperating. It'd be also a good idea to highlight the impact of the lack of active mitigation features, and to hint to how the endpoint could cooperate.

classification step. Note that the use of a connection ID to support connection migration  <ins> renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in client's endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as the load balancer. It is questionable if connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. 4.4.1. UDP is the most prevalent DDoS vector, since it is easy for compromised non-admin applications to send a flood of large UDP packets (while with TCP the attacker gets throttled by the congestion controller).  Networks should be prepared for UDP flood attacks that masquerade as QUIC traffic. If attack classification fails, a possible response is to police UDP traffic on the network, allocating a fixed portion of the network capacity to UDP.  Blindly blocking a significant fraction of QUIC packets will allow many QUIC handshakes to complete, preventing a TCP failover, but the connections will suffer a severe packet loss.  As long as all QUIC-capable applications can failover to TCP (at least applications using well-known UDP ports), the recommended way to drop QUIC packets is to either drop them all or to police them based on the hash of the UDP datagram's source and destination addresses, blocking a portion of the hash space that corresponds to the fraction of UDP traffic one wishes to drop. </ins> 4.5.


Authentication credential: set of information associated with an entity, including that entity's public key and parameters associated with the public key.  Examples of authentication <del> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets (CCSs) </del>  RFC8392, X.509 certificates RFC7925 and C509 certificates I- D.ietf-cose-cbor-encoded-cert.  Further details about authentication credentials are provided in sec-pub-key-format. "subjectPublicKeyAlgorithm" element, respectively. If authentication credentials are CBOR Web Tokens (CWTs) or CWT <del> Claims Sets (CCSs) RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </del>  Authentication credentials are used to derive pairwise keys (see key- derivation-pairwise) and are included in the external additional For example, an X.509 certificate is provided as its direct binary serialization.  If C509 certificates or CWTs are used as authentication credentials, each is provided as the binary <del> serialization of a (possibly tagged) CBOR array.  If CCSs are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </del>  If authentication credentials are CWTs, then the untagged CWT associated with an entity is stored in the Security Context and used

So far, it was used 1x in abbreviated form, and 2x as "CWT Claims Sets (CCS)". The abbreviation was problematic the way it was used while being a reference into RFC8392, it was not defined there. I'm not 100% happy with dropping the term "CCS" because it having an abbreviation is a good pointer for users to see that this is an established, good and compact thing to use (right?), but I'd rather spare readers the confusion of clicking through to 8392 and not finding the letters "CCS". I'd be happy with any better handling of the possible confusion, this is just the best I'm coming up with.

Authentication credential: set of information associated with an entity, including that entity's public key and parameters associated with the public key.  Examples of authentication  <ins> credentials are CBOR Web Tokens (CWTs) and CWT Claims Sets </ins> RFC8392, X.509 certificates RFC7925 and C509 certificates I- D.ietf-cose-cbor-encoded-cert.  Further details about authentication credentials are provided in sec-pub-key-format. "subjectPublicKeyAlgorithm" element, respectively. If authentication credentials are CBOR Web Tokens (CWTs) or CWT  <ins> Claims Sets RFC8392, the public key algorithm is fully described by a COSE key type and its "kty" and "crv" parameters. </ins> Authentication credentials are used to derive pairwise keys (see key- derivation-pairwise) and are included in the external additional For example, an X.509 certificate is provided as its direct binary serialization.  If C509 certificates or CWTs are used as authentication credentials, each is provided as the binary  <ins> serialization of a (possibly tagged) CBOR array.  If CWT Claims Sets are used as authentication credentials, each is provided as the binary serialization of a CBOR map. </ins> If authentication credentials are CWTs, then the untagged CWT associated with an entity is stored in the Security Context and used


ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis.  12. Note to RFC Editor: Please replace all occurrences of "[[this

Not a grave issue, but it's a leak of information that can be reduced to leaking unexpected reboots vs. leaking any reboot by being aware of it.
Thanks NAME , I am just confused by the term "clean shutdown" here. What do you mean by that? If I understand correctly the rest of your text, you are suggesting that to avoid leaking information about accidental reboots, the device keeps track of the node's state constantly, so that when an accidental reboot happens, the node can re-instate the right seq. When does clean shutdown come into the picture?
Typical devices can not tolerate the flash wear of writing the sequence number state on any package transmission (that's why there's the "Seq + K" part in 6.3.1), and that limitation won't go away just because it has privacy consequences. Accidental reboots will thus be leaked, but deliberate ones can be hidden by storing the fine-grained seqno state on flash. For example: Initial boot, everything is 0 Before sending package 1, write "seqno=1000" Send 999 more packages w/o writing Before sending package 1001, write "seqno=2000" Send some more packages w/o writing Zap, reboot! Before sending seqno 2001, write "seqno=3000" (this is a hard to prevent leak) Send 49 more packages Shutdown requested, write "seqno=2050" Reboot Before sending seqno=2051, write "seqno=3050" (no reboot leaked)

ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. <ins> Using the mechanisms described in seqno-replay-state reveals when a device goes through a reboot.  This can be mitigated by the device storing the precise state of sender sequence number and recipient replay window on a clean shutdown. </ins> 12. Note to RFC Editor: Please replace all occurrences of "[[this


option is critical, safe to forward, part of the cache key, and not repeatable. <del> The Object-Security option contains the OSCORE flag byte and for requests, the Sender ID (see compression).  If the flag byte is all zero (0x00) the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </del>  A successful response to a request with the Object-Security option SHALL contain the Object-Security option.  Whether error responses 8.1. The value of the Object-Security option SHALL contain the OSCORE flag <del> byte and the kid parameter as follows: </del>  The first byte (= the OSCORE flag byte) encodes a set of flags and the length of the Partial IV parameter. <del> The three least significant bits, n, encode the Partial IV length.  If n = 0 then the Partial IV is not present in the </del>  compressed COSE object.  The values n = 6 and n = 7 is reserved. The sixth-eighth least significant bits are reserved and SHALL be set to zero when not in use.  The remaining bytes encode the value of the kid, if the kid is present (k = 1)  The presence of Partial IV and kid in requests and responses is specified in cose-object, and summarized in fig-byte-flag. 8.2. <del> The payload of the OSCORE message SHALL be encoded as follows: The first n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint), s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). The remaining bytes encode the ciphertext. </del>  8.3.

This implements the change I suggested in , ie move everything but the ciphertext from CoAP payload to the option value. The text about kid being the last field is a draft, please modify if you have any better formulation.

option is critical, safe to forward, part of the cache key, and not repeatable.  <ins> The Object-Security option contains the OSCORE flag byte, the Sender Sequence Number and the Sender ID when present, (see compression). If the flag byte is all zero (0x00) and no other fields are present, the Option value SHALL be empty (Option Length = 0).  An endpoint receiving a CoAP message without payload, that also contains an Object-Security option SHALL treat it as malformed and reject it. </ins> A successful response to a request with the Object-Security option SHALL contain the Object-Security option.  Whether error responses 8.1. The value of the Object-Security option SHALL contain the OSCORE flag  <ins> byte, the Partial IV parameter, the Context Hint parameter (length and value), and the kid parameter as follows: </ins> The first byte (= the OSCORE flag byte) encodes a set of flags and the length of the Partial IV parameter.  <ins> The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the </ins> compressed COSE object.  The values n = 6 and n = 7 is reserved. The sixth-eighth least significant bits are reserved and SHALL be set to zero when not in use. <ins> The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). The following 1 byte encode the length of the Context Hint (context-hint) s, if the Context Hint flag is set (h = 1). The following s bytes encode the Context Hint, if the Context Hint flag is set (h = 1). </ins> The remaining bytes encode the value of the kid, if the kid is present (k = 1) <ins> Note that the kid MUST be the last field of the object-security value, even in case reserved bits are used and additional fields are added to it. </ins> The presence of Partial IV and kid in requests and responses is specified in cose-object, and summarized in fig-byte-flag. 8.2.  <ins> The payload of the OSCORE message SHALL encode the ciphertext. </ins> 8.3.


in inner-options. The Outer Max-Age option is used to avoid unnecessary caching of <del> OSCORE responses at OSCORE unaware intermediary nodes.  A server MAY set a Class U Max-Age option with value zero to Observe responses (see Section 5.6.1 of RFC7252) which is then processed according to outer-options.  The Outer Max-Age option value SHALL be discarded by the OSCORE client. </del>  <del> Non-Observe OSCORE responses do not need to include a Max-Age option </del>  since the responses are non-cacheable by construction (see coap- header). In order to protect from replay of requests, the server's Recipient Context includes a Replay Window.  A server SHALL verify that a Partial IV received in the COSE object has not been received before. <del> If this verification fails and the message received is a CON message, the server SHALL respond with a 5.03 Service Unavailable error message with the inner Max-Age option set to 0.  The diagnostic payload MAY contain the "Replay protection failed" string.  The size and type of the Replay Window depends on the use case and lower protocol layers.  In case of reliable and ordered transport from endpoint to endpoint, the server MAY just store the last received Partial IV and require that newly received Partial IVs equals the last received Partial IV + 1. </del>  Responses to non-Observe requests are protected against replay as they are cryptographically bound to the request. either the decompression or the COSE message fails to decode, the server SHALL respond with a 4.02 Bad Option error message.  The diagnostic payload SHOULD contain the string "Failed to decode COSE". the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server SHALL respond with a 4.01 Unauthorized error message.  The  diagnostic payload MAY contain the string "Security context not found". If decryption fails, the server MUST stop processing the request and, if the request is a CON message, the server MUST <del> respond with a 4.00 Bad Request error message.  The diagnostic </del>  payload MAY contain the "Decryption failed" string. If decryption succeeds, update the Replay Window, as described

on server side. Also, error is unprotected (as all other OSCORE errors) see
RFC7252 specifies that 5.03 uses Max-Age. Now when we use 4.01, I think Max-Age should (need to) be removed.
NAME This was an oversight on my part. One question though: what was the reason to say: Why do we specify for Observe responses? A server MAY set an outer Max-Age=0 with all responses (as an indication to the proxy not to cache), also for error responses (not protected with Object-Security) to an OSCORE request.
The reason why we talked about Max-Age is to avoid caching by a OSCORE unanaware proxy. This was not needed for 2.04. if we change to only 2.04 we should remove this completely.
Ok, because 2.04 is non cacheable. but error responses are cacheable, so following the same logic we should say that the server MAY set max-age = 0 for error responses, no?
Yes, that makes sense.
(This issue takes some context from issue ). The current draft states that replay protection violation triggers a 5.03 with Max-Age 0 (Section 6.4). While this is a practical solution to issue (which is not mitigated by encrypting the code because FETCH is still safe), it could still be caught by a proxy that'd try to be smart about it (and would, AFAICT, be within its rights). I suggest that the response code be 4.01 Unauthorized with Max-Age=0. The semantics of Unauthorized are "SHOULD NOT repeat the request without first improving its authentication status to the server", and while it's a bit of a stretch to say that increasing the sequence number is sufficient to improve the authentication status, the Max-Age gives a good hint ("Come on, try again right away, don't look for other keys"), and clients can use the presence of the Max-Age option as a discriminator to tell "Sorry, no such context" apart from "Retry with a new seqno".
We also just identified this response code as not appropriate. The proposal is good, unless it results in overloading the semantics of Max-Age=0. There is already at least one requirement when Max-Age has to be zero: RFC7252, Section 5.6.1: "If an origin server wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds." Is there a setting where the the server would not want the response 4.01 to be cached even though it is not a replay? (Obviously we have to differentiate between Inner and Outer 4.01, but is that enough?)
I don't know. I briefly thought about using an Echo here, but an HTTP proxy would react to that as a CoAP proxy would to 5.03,Max-Age=0. (See comments 2ff). I did give that some thought, and considering the Echo option thought about whether the server should just reply with an encrypted ,Max-Age=0 (or Echo=short). I decided against suggesting that because responding to a possibly fraudulent message with an owned partial IV means that any adversary that has one valid-but-used message can thus drive any server into partial-IV exhaustion.
By the way, just FYI, that Max-Age=0 with 5.03 means "service unavailable, retry in 0 seconds", which is wrong (and not what we want). (see: URL)
The current text where there MAY be a Max-Age of 0 both on "4.01, Security context not found" and on "4.01, Security context not found" means that a client can not know any more which is the case (and it should not look into the message). I see the reason for the MAY set Max-Age for most error cases in , but a client needs to keep those apart (otherwise it'd need to so something like try 3 times with a new PIV, and if the server still responds the same, assume that it doesn't know the KID). I suggest that for those two responses, the Max-Age values are enforced as "MUST NOT set a Max-Age option" and "MUST set the Max-Age option to 0", or find any other discriminator, but an implementation should be able to tell them apart.
Granted, with the current setup of POST and FETCH there are much fewer cases where replay protection errors can happen (they'd only legally happen under particular package loss situations when starting an observation via a proxy that does not support observation but does do optimizations for safe requests), but I still think that there'd be more clarity if there were a discriminant between the two error cases.

in inner-options. The Outer Max-Age option is used to avoid unnecessary caching of  <ins> OSCORE error responses at OSCORE unaware intermediary nodes.  A server MAY set a Class U Max-Age option with value zero to OSCORE error responses described in replay-protection, ver-req and ver-res, which is then processed according to outer-options. </ins>  <ins> Non-error OSCORE responses do not need to include a Max-Age option </ins> since the responses are non-cacheable by construction (see coap- header). In order to protect from replay of requests, the server's Recipient Context includes a Replay Window.  A server SHALL verify that a Partial IV received in the COSE object has not been received before.  <ins> If this verification fails the server SHALL stop processing the message and, in case of CON respond with a 4.01 Unauthorized error message.  The server MAY set an Outer Max-Age option with value zero. The diagnostic payload MAY contain the "Replay protection failed" string.  The size and type of the Replay Window depends on the use case and lower protocol layers.  In case of reliable and ordered transport from endpoint to endpoint, the server MAY just store the last received Partial IV and require that newly received Partial IVs equals the last received Partial IV + 1. </ins> Responses to non-Observe requests are protected against replay as they are cryptographically bound to the request. either the decompression or the COSE message fails to decode, the server SHALL respond with a 4.02 Bad Option error message. <ins> The server MAY set an Outer Max-Age option with value zero. </ins> The diagnostic payload SHOULD contain the string "Failed to decode COSE". the server fails to retrieve a Recipient Context with Recipient ID corresponding to the 'kid' parameter received, the server SHALL respond with a 4.01 Unauthorized error message.  The <ins> server MAY set an Outer Max-Age option with value zero.  The </ins> diagnostic payload MAY contain the string "Security context not found". If decryption fails, the server MUST stop processing the request and, if the request is a CON message, the server MUST  <ins> respond with a 4.00 Bad Request error message.  The server MAY set an Outer Max-Age option with value zero.  The diagnostic </ins> payload MAY contain the "Decryption failed" string. If decryption succeeds, update the Replay Window, as described


The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security <del> in the mapped request or response.  The value of the field is the value of the Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding).  The value of the payload is the OSCORE payload oscore-payl, also base64url-encoded without padding. </del>  Example:

As suggested in
Need to update example as well
Not on expert on HTPP header formats, but are single quotes '' correct? I think I have only seen double quotes "" in HTTP.
should be fixed now
"The value of the payload" It is called body in HTTP
Jim suggested to not have an empty HTTP header (legal but likely to create problems), instead use: ""

The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security  <ins> in the mapped request or response.  The value of the field is: "" (empty string) if the CoAP Object-Security option is empty, or the value of the CoAP Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding). The value of the body is the OSCORE payload oscore-payl. </ins> Example:


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 MUST verify the response as a non-Observe response. <del> If the OSCORE client reveives a response to a non-Observe request </del>  with an Outer Observe value, the processing is covered in processing.  4.2.3.5. The Object-Security option is only defined to be present in OSCORE older than its request.  For responses without Observe, this gives strong absolute freshness.  For responses with Observe, the absolute freshness gets weaker with time, and it is RECOMMENDED that the <del> client regularly restart the observation. </del>  For requests, and responses with Observe, OSCORE also provides relative freshness in the sense that the received Partial IV allows a (Optional) In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.  9. The use of OSCORE MAY be indicated by a target attribute "osc" in a

as discussed some hours ago. Notes about proxies go to the mailing list for further routing. Closes: URL
The mailing list discussion that the kind of extension is not covered by observation. Could you try to sit together with Klaus to talk this out? (I'd be happy to join in, but as both all of you and Klaus are in Singapore right now, you might want to grab any short-term occasion to talk to the man who wrote the boo^WRFC on observation)
There is no mention of observation renewal (cf. ) in OSCORE, and I think there should be, because there are two possible interpretations, hinging on "All options MUST be identical to those in the original request except for the set of ETag Options": The ETag is encoded in the message, thus the message may change and be encrypted with a new nonce. There is no ETag in an OSCORE observe, therefore the only valid renewal is renewal with the very message with the same nonce (it's not nonce reuse when the message is identical) can be sent. Either is consistent with the current text; option 2 would be the easy path because the text addition would just say that "Renewal of the observation and updating of the ETags is not supported at OSCORE level. The underlying transport's observation can be renewed, but its Object-Security options and FETCH payload can not be different from the original request". Advantages of 1: The set of ETags can be updated as with regular Observation. A new request PartIV is sent to the server, so the client can have freshness of new messages relative to the renewal operation without stopping the observation and starting a new one. Disadvantages of 1: A proxy might be tripped up by an option that is not an ETag changing in an update. (Though it shouldn't, really -- given that the observation cancellation could have been lost, it should just view such an event as the cancellation of an old and the establishing of a new observation, and forward it accordingly.) Nonce ambiguity: The client needs to be prepared to receive updates with the old nonce (which would read as AEAD decryption failures) after having renewed an observation, and mustn't be upset by them (read: must not send anything back to the server that would jeopardize the observation). I think I'd prefer 1, but would be fine with either given the ambiguity-of-nonce point.
I don't understand the concept of observe renewal. I have always treated this as a new observe and not as a renewal.
I'd describe observe renewal as another Request message on the same token that should elicit a more immediate response to confirm that the observation is still on (and if it wasn't, register one anew transparently). It is practically answered either by a piggybacked ACK 2.05 Content, or by an empty ACK, in which case there is no message that's explicitly "the" response to the refresh, but the client will still expect something back on that token within however long it is ready to wait for an initial response. That one can update the set of ETags while doing so is a practical feature and at the same time an extreme load the request/response model (now not only can an exchange have multiple responses, it can also have multiple requests), so I prefer to read it as the second request implicitly canceling the first silently ("The token was re-used, so obviously it has been retired by the client") and establishing a new observation, which is so much easier on the request/response model and looks exactly the same on the wire. (Those considerations also made me propose 1). Christian Amsüss wrote: It's not the client alone who decides when a token is no longer in use. Right. If the proxy finds that the new observation request from the client is (almost) identical to the previous observation request from the client, then this behavior is exactly the one intended. The proxy could also try to do it when the requests are not identical, but this would violate the "MUST be identical" client requirement, although it might technically work due to the "MUST replace or update the existing" server requirement. I wouldn't assume that any proxy does it in this case. At first glance, I don't see any. Klaus

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 MUST verify the response as a non-Observe response.  <ins> If the OSCORE client receives a response to a non-Observe request </ins> with an Outer Observe value, the processing is covered in processing. <ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and Object- Security option) change.  The server uses the new request's Partial IV as the "request_piv" of new responses. </ins> 4.2.3.5. The Object-Security option is only defined to be present in OSCORE older than its request.  For responses without Observe, this gives strong absolute freshness.  For responses with Observe, the absolute freshness gets weaker with time, and it is RECOMMENDED that the  <ins> client regularly re-register the observation. </ins> For requests, and responses with Observe, OSCORE also provides relative freshness in the sense that the received Partial IV allows a (Optional) In case any of the previous erroneous conditions apply: the client SHALL stop processing the response. <ins> An error condition occuring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure in step 7 by re-registering the observation immediately. </ins> 9. The use of OSCORE MAY be indicated by a target attribute "osc" in a


Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE <del> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl, and constrained environments RFC7228. </del>  The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or

I believe this is about the minimum change that we can make to avoid the need for a normative reference to draft-ietf-cbor-cddl, which might hold up the document in the RFC editor queue.
Thank you NAME the only thing I can think of is adding a reference to CBOR in the appendix too, but that's it.

Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE  <ins> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl as summarized in cddl- sum, and constrained environments RFC7228. </ins> The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or


the Partial IV parameter, the kid context parameter (length and value), and the kid parameter as follows: <del> The first byte of flag bits encodes the following set of flags and the length of the Partial IV parameter: </del>  The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the to 1 the message is considered to be malformed and decompression fails as specified in item 3 of ver-req.  The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message.  The OSCORE payload cannot be understood without the OSCORE option value and the security context.

Solves issue (from review comments by NAME : URL) Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.

the Partial IV parameter, the kid context parameter (length and value), and the kid parameter as follows:  <ins> The first byte, called OSCORE Octet, encodes the following set of flag bits and the length of the Partial IV parameter: </ins> The three least significant bits encode the Partial IV length n.  If n = 0 then the Partial IV is not present in the to 1 the message is considered to be malformed and decompression fails as specified in item 3 of ver-req. <ins> The flag bits are registered in the OSCORE Octet registry specified in oscore-octet. </ins> The following n bytes encode the value of the Partial IV, if the Partial IV is present (n > 0). OSCORE payload is defined for potential future use cases and SHALL NOT be used in the OSCORE message.  The OSCORE payload cannot be understood without the OSCORE option value and the security context. <ins> 13.7. It is requested that IANA create a new registry entitled "OSCORE Octet".  The registry should be created with the Expert Review policy.  Guidelines for the experts are provided in exp-instr. The columns of the registry are: bit position: This indicates the position of the bit in the OSCORE Octet, starting at 0 for the most significant bit.  The bit position must be an integer or a range of integers, in the range 0 to 63. name: The name is present to make it easier to refer to and discuss the registration entry.  The value is not used in the protocol.  Names are to be unique in the table. description: This contains a brief description of the use of the bit. specification: This contains a pointer to the specification defining the entry. The initial contents of the registry can be found in _table-flagbyte. The specification column for all rows in that table should be this document.  Additionally, the entry with Bit Position of 0 is to be marked as 'Reserved'.  This entry is going to be specified in a future document, and will be used to expand the OSCORE Octet in obj- sec-value, so that entries 8-63 of the registry are defined. 13.8. The expert reviewers for the registry defined in this document are expected to ensure that the usage solves a valid use case that could hardly be solved in a different way, that it is not going to duplicate one that is already registered, and that the registered point is likely to be used in deployments.  They are furthermore expected to check the clarity of purpose and use of the requested code points.  Experts should take into account the expected usage of entries when approving point assignment, and the length of the encoded value should be weighed against the number of code points left that encode to that size and the size of device it will be used on.  Experts should block registration for entries 8-63 until these points are defined (i.e. until the mechanism for the OSCORE Octet expansion via bit 0 is specified). </ins>


forwarding by intermediary nodes. The server SHALL include a new Partial IV in responses (with or <del> without the Observe option) to Observe registrations. </del>  RFC7252 does not specify how the server should act upon receiving the same Token in different requests.  When using OSCORE, the server 4.1.3.5.2. If the server accepts an Observe registration, a Partial IV MUST be <del> included in all notifications (both successful and error).  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. </del>  For notifications, the Inner Observe value MUST be empty (see Section 3.2 of RFC7252).  The Outer Observe in a notification is as the freshest, regardless of the order of arrival.  In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least <del> significant bytes of the Partial IV. </del>  4.1.3.6. The Notification Number is initialized to the Partial IV of the first successfully verified notification in response to the registration <del> request.  A client receiving a notification SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received.  Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </del>  If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client If Observe is supported, insert the following step between step 2 and 3 of prot-res: <del> A.  If the request was a registration, encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </del>  8.4. A.  If the request was an Observe registration, then: <del> If the Partial IV is not present in the response, and either the client has previously received a successful notification to the registration (active observation) or Inner Observe is present, then go to 8. </del>  If the Partial IV is present in the response and Inner Observe is present, then follow the processing described in notifications and

Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.

forwarding by intermediary nodes. The server SHALL include a new Partial IV in responses (with or  <ins> without the Observe option) to Observe registrations, except for the first response where Partial IV MAY be omitted. </ins> RFC7252 does not specify how the server should act upon receiving the same Token in different requests.  When using OSCORE, the server 4.1.3.5.2. If the server accepts an Observe registration, a Partial IV MUST be  <ins> included in all notifications (both successful and error), except for the first one where Partial IV MAY be omitted.  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration.  Further details of replay protection of notifications are specified in replay-notifications. </ins> For notifications, the Inner Observe value MUST be empty (see Section 3.2 of RFC7252).  The Outer Observe in a notification is as the freshest, regardless of the order of arrival.  In order to support existing Observe implementations the OSCORE client implementation MAY set the Observe value to the three least  <ins> significant bytes of the Partial IV; such an implementation needs to make sure that the Observe value for an observe notification without Partial IV is smaller than a notification with Partial IV. </ins> 4.1.3.6. The Notification Number is initialized to the Partial IV of the first successfully verified notification in response to the registration  <ins> request.  A client MUST only accept at most one Observe notifications without Partial IV, and treat it as the oldest notification received. A client receiving a notification containing a Partial IV SHALL compare the Partial IV with the Notification Number associated to that Observe registration.  The client MUST stop processing notifications with a Partial IV which has been previously received. Applications MAY decide that a client only processes notifications which have greater Partial IV than the Notification Number. </ins> If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number then the client If Observe is supported, insert the following step between step 2 and 3 of prot-res:  <ins> A.  If the response is an observe notification: If the response is the first notification: compute the AEAD nonce as described in nonce: Either use the nonce from the request, or Encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. Then go to 4. If the response is not the first notification: encode the Partial IV (Sender Sequence Number in network byte order) and increment the Sender Sequence Number by one. Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV, then go to 4. </ins> 8.4. A.  If the request was an Observe registration, then:  <ins> If the Partial IV is not present in the response, and Inner Observe is present, and the nonce from the request was already used once, then go to 8. </ins> If the Partial IV is present in the response and Inner Observe is present, then follow the processing described in notifications and


To prevent reuse of an AEAD nonce with the same AEAD key, or from accepting replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as <del> the Sender Sequence Number, Replay Window, and Notification Numbers. These are typically stored in RAM and therefore lost in the case of e.g. an unplanned reboot.  There are different alternatives to recover, for example: </del>  The endpoints can run a key exchange protocol providing forward secrecy resulting in a fresh Master Secret, from which an entirely new Security Context is derived.  This requires a good source of randomness, and additionally, the transmission and processing of <del> the protocol may have a non-negligible cost in terms of, e.g., </del>  power consumption. <del> An alternative is to use a trusted-third party assisted key establishment protocol such as I-D.ietf-ace-oscore-profile, which may be more lightweight and may not require additional randomness. The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts.  This typically requires a good source of randomness and a message exchange, but not as large performance impact as a key exchange protocol, and no trusted third party.  See master-secret-multiple for an example. Under certain circumstances an endpoint can reuse an existing Security Context with updated Sender Sequence Number, Replay Window, and Notification Numbers.  This requires that the mutable parts of the security context are available throughout the lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see master-secret-once for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The choice of method may depend on capabilities of the devices deployed and the solution architecture.  This document RECOMMENDS the use of a key exchange protocol. </del>  8.

According to NAME 's comments: remove notification numbers changed the order of the list added one method: use of echo to update replay window (when server does not uses its own sender sequence number in responses) editorial (Jim apparently I cannot ask you to review via github, maybe because you are not part of the CoRE WG github organization? But yes, if you could check that this answers your comments, that'd be great)
I reviewed and made the following changes: Jim's method move as number 2 Some clarifications of that method Changing motivations which made less sense when the methods were is reverse order Moved the details of Jim's method to B.1 where other detailed methods are Grouped non-volatile methods under one heading in appendix B, and changed reference (So I violated the name of this PR since it extends to appendix B.1)

To prevent reuse of an AEAD nonce with the same AEAD key, or from accepting replayed messages, an endpoint needs to handle the situation of losing rapidly changing parts of the context, such as  <ins> the Sender Sequence Number, and Replay Window.  These are typically stored in RAM and therefore lost in the case of e.g. an unplanned reboot.  There are different alternatives to recover, for example: The endpoints can reuse an existing Security Context after updating the mutable parts of the security context (Sender Sequence Number, and Replay Window).  This requires that the mutable parts of the security context are available throughout the lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see seq- numb and reboot-replay for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The endpoints can only update the server's Replay Window by using the Echo option I-D.ietf-core-echo-request-tag, see reboot-replay for an example.  This method only updates the Replay Window and does not update the server's Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using seq-numb) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used if the client can not guarantee non- reuse of its own Sender Sequence Numbers (e.g. by using seq-numb). The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see master-secret- multiple for an example.  This typically requires a good source of randomness. The endpoints can use a trusted-third party assisted key establishment protocol such as I-D.ietf-ace-oscore-profile.  This requires the execution of three-party protocol and may require a good source of randomness. </ins> The endpoints can run a key exchange protocol providing forward secrecy resulting in a fresh Master Secret, from which an entirely new Security Context is derived.  This requires a good source of randomness, and additionally, the transmission and processing of  <ins> the protocol may have a non-negligible cost, e.g. in terms of </ins> power consumption.  <ins> The endpoints need to be configured with information about which method is used.  The choice of method may depend on capabilities of the devices deployed and the solution architecture.  Using a key exchange protocol is necessary for deployments that require forward secrecy. </ins> 8.


3.2.2. <del> The Sender Sequence Number is initialized to 0.  The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </del>  3.3. This parameter SHALL be present in requests.  The Partial IV SHALL be present in responses to Observe registrations (see observe-registration), otherwise the Partial IV will not <del> typically be present in responses. </del>  The 'kid' parameter.  The value is set to the Sender ID.  This parameter SHALL be present in requests and will not typically updating the mutable parts of the security context (Sender Sequence Number, and Replay Window).  This requires that the mutable parts of the security context are available throughout the <del> lifetime of the device, or that the device can recover security context data based on careful use of non-volatile memory, see seq- numb and reboot-replay for an example.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. The endpoints can update the server's Replay Window by using the Echo option I-D.ietf-core-echo-request-tag, see reboot-replay for an example.  This method only updates the Replay Window and does not update the server's Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using seq-numb) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using seq- numb). </del>  The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see master-secret-

Addressing issue : Reverting to previous method of updating replay window (section B.1.2, text was previously in 7.5) Removing item 2 in section 7.5
Hi, I do not think that the new suggested Echo procedure specified in 7.5 and B.1.2 is secure with GCM. The procedure intentionally reuses a nonce. As the Plaintext and/or AAD changes, I think the nonce reuse will allow an attacker to calculate the GCM authentication key H, therefore compromising integrity for all following messages the server receives. I don't think we want a procedure that is dependant on the AEAD algorithm. Are there any ways to fix this or should we revert to the previous procedure where the server first need to make sure that it uses a fresh nonce and then send Echo? What do you think NAME ? In Section 7.5, bullet 2 The endpoints can update the server’s Replay Window by using the Echo option [I-D.ietf-core-echo-request-tag], see Appendix B.1.2 for an example. This method only updates the Replay Window and does not update the server’s Sender Sequence Number, so it MUST be complemented by a method for updating the Sender Sequence Number (e.g. by using Appendix B.1.1) if the application allows for the server to encode the AEAD nonce using its Sender Sequence Number in responses to regular requests, or if the server supports Observe. This method MUST NOT be used unless the client can guarantee that its own Sender Sequence Numbers are not reused (e.g. by using Appendix B.1.1). In Appendix B.1.2
Yes you are correct. I was only thinking of the use of CCM which does not have this problem.
I merged PR - reverting to the processing in -15.
I close this issue now, if there are still comments we can reopen it.

3.2.2.  <ins> The Sender Sequence Number is initialized to 0. The supported types of replay protection and replay window length is application specific and depends on how OSCORE is transported, see replay-protection.  The default is DTLS-type replay protection with a window size of 32 initiated as described in Section 4.1.2.6 of RFC6347. </ins> 3.3. This parameter SHALL be present in requests.  The Partial IV SHALL be present in responses to Observe registrations (see observe-registration), otherwise the Partial IV will not  <ins> typically be present in responses (for one exception, see reboot-replay). </ins> The 'kid' parameter.  The value is set to the Sender ID.  This parameter SHALL be present in requests and will not typically updating the mutable parts of the security context (Sender Sequence Number, and Replay Window).  This requires that the mutable parts of the security context are available throughout the  <ins> lifetime of the device, or that the device can establish safe security context after loss of mutable security context data. Examples is given based on careful use of non-volatile memory, see seq-numb, and additionally the use of the Echo option, see reboot- replay.  If an endpoint makes use of a partial security context stored in non-volatile memory, it MUST NOT reuse a previous Sender Sequence Number and MUST NOT accept previously received messages. </ins> The endpoints can reuse an existing shared Master Secret and derive new Sender and Recipient Contexts, see master-secret-