Draft: draft-ietf-core-echo-request-tag

Commentary: Proposed resolution to Francesca 's review comments on Section 2 .
Paragraph (version A):
When receiving an Echo option in a request, the server MUST be able
to verify when the Echo option value was generated.  This implies
that the server MUST be able to verify that the Echo option value was
generated by the server or some other party that the server trusts.
Depending on the freshness requirements the server may verify exactly
when the Echo option value was generated (time-based freshness) or
verify that the Echo option was generated after a specific event
(event-based freshness).  As the request is bound to the Echo option
value, the server can determine that the request is not older that
the Echo option value.
Paragraph (version B):
When receiving an Echo option in a request, the server MUST be able
to verify that the Echo option value (a) was generated by the server
or some other party that the server trusts, and (b) fulfills the
freshness requirements of the application.  Depending on the
freshness requirements the server may verify exactly when the Echo
option value was generated (time-based freshness) or verify that the
Echo option was generated after a specific event (event-based
freshness).  As the request is bound to the Echo option value, the
server can determine that the request is not older that the Echo
option value.
Paragraph (version A):
If a certain request is required to be fresh, the request does not
contain a fresh Echo option value, and the server cannot verify the
freshness of the request in some other way, the server MUST NOT
process the request further and SHOULD send a 4.01 Unauthorized
response with an Echo option.  The server MAY include the same Echo
option value in several different responses and to different clients.
Paragraph (version A):
The server may use request freshness provided by the Echo option to
verify the aliveness of a client or to synchronize state.  The server
may also include the Echo option in a response to force a client to
demonstrate reachability at its claimed network address.
Paragraph (version B):
If a certain request is required to be fresh, the request does not
contain a fresh Echo option value, and the server cannot verify the
freshness of the request in some other way, the server MUST NOT
process the request further and SHOULD send a 4.01 Unauthorized
response with an Echo option.  The server MAY include the same Echo
option value in several different response messages and to different
clients.  Examples of this could be time-based freshness when several
responses are sent closely after each other or event-based freshness
with no event taking place between the responses.
Paragraph (version B):
The server may use request freshness provided by the Echo option to
verify the aliveness of a client or to synchronize state.  The server
may also include the Echo option in a response to force a client to
demonstrate reachability at its claimed network address.  Note that
the Echo option does not bind a request to any particular previous
response, but provides an indication that the client had access to
the previous response at the time when it created the request.
Paragraph (version A):
Upon receiving a request with the Echo option, the server determines
if the request is required to be fresh.  If not, the Echo option MAY
be ignored.  If the request is required to be fresh and the server
cannot verify the freshness of the request in some other way, the
server MUST use the Echo option to verify that the request is fresh
enough.  If the server cannot verify that the request is fresh
enough, the request is not processed further, and an error message
MAY be sent.  The error message SHOULD include a new Echo option.
Paragraph (version A):
One way for the server to verify freshness is that to bind the Echo
value to a specific point in time and verify that the request is not
older than a certain threshold T.  The server can verify this by
checking that (t1 - t0) < T, where t1 is the request receive time and
t0 is the time when the Echo option value was generated.  An example
message flow is illustrated in echo-figure.
Paragraph (version A):
When used to serve freshness requirements (including client aliveness
and state synchronizing), CoAP messages containing the Echo option
MUST be integrity protected between the intended endpoints, e.g.
using DTLS, TLS, or an OSCORE Inner option (RFC8613).  When used to
demonstrate reachability at a claimed network address, the Echo
option SHOULD contain the client's network address, but MAY be
unprotected.
Paragraph (version B):
Upon receiving a request with the Echo option, the server determines
if the request is required to be fresh.  If not, the Echo option MAY
be ignored.  If the request is required to be fresh and the server
cannot verify the freshness of the request in some other way, the
server MUST use the Echo option to verify that the request is fresh.
If the server cannot verify that the request is fresh, the request is
not processed further, and an error message MAY be sent.  The error
message SHOULD include a new Echo option.
Paragraph (version B):
One way for the server to verify freshness is that to bind the Echo
value to a specific point in time and verify that the request is not
older than a certain threshold T.  The server can verify this by
checking that (t1 - t0) < T, where t1 is the request receive time and
t0 is the time when the Echo option value was generated.  An example
message flow is shown in echo-figure-time.
Paragraph (version B):
Another way for the server to verify freshness is to maintain a cache
of values associated to events.  The size of the cache is defined by
the application.  In the following we assume the cache size is 1, in
which case freshness is defined as no new event has taken place.  At
each event a new value is written into the cache.  The cache values
MUST be different for all practical purposes.  The server verifies
freshness by checking that e0 equals e1, where e0 is the cached value
when the Echo option value was generated, and e1 is the cached value
at the reception of the request.  An example message flow is shown in
echo-figure-event.
Paragraph (version B):
When used to serve freshness requirements (including client aliveness
and state synchronizing), the Echo option value MUST be integrity
protected between the intended endpoints, e.g. using DTLS, TLS, or an
OSCORE Inner option (RFC8613).  When used to demonstrate reachability
at a claimed network address, the Echo option SHOULD contain the
client's network address, but MAY be unprotected.
Paragraph (version A):
A server may use the Echo option to synchronize state or time with
a requesting client.  A server MUST NOT synchronize state or time
with clients which are not the authority of the property being
synchronized.  E.g. if access to a server resource is dependent on
time, then the client MUST NOT set the time of the server.
Paragraph (version B):
A server may use the Echo option to synchronize properties (such
as state or time) with a requesting client.  A server MUST NOT
synchronize a property with a client which is not the authority of
the property being synchronized.  E.g. if access to a server
resource is dependent on time, then server MUST NOT synchronize
time with a client requesting access unless it is time authority
for the server.