RFC 7252, "The Constrained Application Protocol (CoAP)", June 2014

Note: This RFC has been updated by RFC 7959, RFC 8613, RFC 8974, RFC 9175

Errata ID: 5429
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Marian Buschsieweke
Date Reported: 2018-07-18
Rejected by: Francesca Palombini
Date Rejected: 2023-01-18

Section 4.4 says:

An Acknowledgement or Reset message is related to a Confirmable
message or Non-confirmable message by means of a Message ID along
with additional address information of the corresponding endpoint.
The Message ID is a 16-bit unsigned integer that is generated by the
sender of a Confirmable or Non-confirmable message and included in
the CoAP header.  The Message ID MUST be echoed in the
Acknowledgement or Reset message by the recipient.

The same Message ID MUST NOT be reused (in communicating with the
same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).

Implementation Note:  Several implementation strategies can be
  employed for generating Message IDs.  In the simplest case, a CoAP
  endpoint generates Message IDs by keeping a single Message ID
  variable, which is changed each time a new Confirmable or Non-
  confirmable message is sent, regardless of the destination address
  or port.  Endpoints dealing with large numbers of transactions
  could keep multiple Message ID variables, for example, per prefix
  or destination address.  (Note that some receiving endpoints may
  not be able to distinguish unicast and multicast packets addressed
  to it, so endpoints generating Message IDs need to make sure these
  do not overlap.)  It is strongly recommended that the initial
  value of the variable (e.g., on startup) be randomized, in order
  to make successful off-path attacks on the protocol less likely.

It should say:

An Acknowledgement or Reset message is related to a Confirmable
message or Non-confirmable message by means of a Message ID along
with additional address information of the corresponding endpoint.
The Message ID is a 16-bit unsigned integer that is generated by the
sender of a Confirmable or Non-confirmable message and included in
the CoAP header.  Message IDs of subsequence messages send to the
same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending
(wrapping around at a value of 65535).  Additionally, two
subsequently send Message IDs to the same endpoint SHOULD have a
difference of at most 16.  The Message ID MUST be echoed in the
Acknowledgement or Reset message by the recipient.

The same Message ID MUST NOT be reused (in communicating with the
same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2).

Implementation Note:  Several implementation strategies can be
  employed for generating Message IDs.  In the simplest case, a CoAP
  endpoint generates Message IDs by keeping a single Message ID
  variable, which is incremented each time a new Confirmable or Non-
  confirmable message is sent, regardless of the destination address
  or port.  Endpoints dealing with large numbers of transactions
  could keep multiple Message ID variables, for example, per prefix
  or destination address.  (Note that some receiving endpoints may
  not be able to distinguish unicast and multicast packets addressed
  to it, so endpoints generating Message IDs need to make sure these
  do not overlap.)  It is strongly recommended that the initial
  value of the variable (e.g., on startup) be randomized, in order
  to make successful off-path attacks on the protocol less likely.

Notes:

Without any restrictions on how Message IDs are generated, an implementation of CoAP duplication detection must be prepared to receive a random sequence of Message IDs.
One simple implementation strategy would be to store the received Message IDs along with a timestamp when they were received.
If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID would be required.
If additionaly a CoAP server expects requests to be received at a rate of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB have to be allocated per client.
A class 1 (see RFC 7228 Section 3) server could handle at most 10 clients in parallel, if anything apart duplicate detection could be implemented without using any memory at all.

If instead Message IDs have to be generated by incrementing a (global or per endpoint/network prefix/...) counter variable, duplicate detection can be implemented in a time and memory efficient way without limiting the rate of the message exchange between to nodes.
--VERIFIER NOTES--
In rejecting this Errata report I note that the reported error is not a typo, but a deliberate decision of the authors and working group. The change, therefore, if it is to be applied needs to be achieved through a consensus document.

Report New Errata