Echo freshness

[chrysn]

This is an initial rough and overly variable suggestion to address the issues discussed as a follow-up to the DTLS replay window comments.

The approaches all have their up- and downsides, and I'm not sure yet which are worth keeping.

• The nice thing about ETag is that it should be largely uncontroversial in its semantics, well established, and resource specific. The only downside is that we'd have to mandate that the client send it every time, for otherwise there's no way of recovery. (And recovery is needed: Think of what happens if the client sends a request, the server updates the ETag and returns it with a response that gets lost. Client retransmits, but the request is idempotent and thus not deduplicated, and the client gets a 4.12. Or can that carry an ETag? It probably intends to tag a representation. And can the server 4.12 when ETag is missing?)

• Echo is what we talked about in the last interim, and largely straightforward. It's really about freshness and not about resource state, and thus may need to play nicely with other users of Echo on the same server.

• Introspecting OSCORE sequence numbers ... do we want to go there? (And if yes, can we do anything for DTLS where sequence numbers are usually not exposed through the libraries?)

  It wouldn't be fully without precedent because the sequence numbers are used to order observe notifications, and were under consideration (but insufficient for) atomic block reassembly. However, these were about CoAP options and not applications. How to tell the client to re-encrypt at seqno failure is open (although Echo:anything-but-the-current-value would practically suffice). Further questions arise when there are multiple OSCORE contexts all admissible for interaction with that resource.

• Unique Registration Resource names are just in there for completeness, they don't give a full solution.

[chrysn]

Now has text reflecting the decision to go with Echo.

Not something I'd consider handing out (ie. I haven't even had a second look after writing), but good enough to check into version control.

[chrysn]

Please review based, ideally based on the github delta at https://github.com/core-wg/resource-directory/pull/291/files. (The diffs of the rendered texts advertised on the github page are currently unreliable; won't investigate there before the cut-off).

[gselander]

I only have little time before cut-off, but I've read the diff in question. Without knowing the details, the reasoning in the request freshness section looks right.

I didn't understand the basic assumption in the "skipping freshness checks" section:
Why can RD based applications be built in which request freshness checks are not performed (unless freshness is not required, in which case this isn't a problem)?

Please let me know what more I should do.

A syntax error: {{example-freshness}

[chrysn]

Without knowing the details, the reasoning in the request freshness section looks right. Please let me know what more I should do.

Thanks, that is helpful as it is.

Why can RD based applications be built in which request freshness checks are not performed (unless freshness is not required, in which case this isn't a problem)?

There is only a SHOULD for the checks that leaves the door a gap open for applications where none of the consequences matter. In particular, I envision that heavily SCHC'd LoRA devices would update their registrations with an implied No-Response and thus radio silence from their RD (and thus freshness assertions for the keepalives can become difficult). The "skipping" section is there to ensure that in these cases, users are aware of the consequences.

[petervanderstok]

HI Chris,

thanks for all the work,
I am not quite familiar with the echo request and freshness concept.
Reading your text, I would assume that a full serialized approach would do.
That means the RD can only handle sequential accesses one after the other.

If you want more interleaving of request, some serializability algorithms should be applied. BUt that is very tme consuming.

Sorry, not being able to give mor reeasobnable feedback quickly.

Peter

[chrysn]

If you want more interleaving of request, some serializability algorithms should be applied. BUt that is very tme consuming.

The door is open for an RD to do that, by means of the "... that altered that state in a conflicting way".

Sorry, not being able to give mor reeasobnable feedback quickly.

I'm appreciating it already as it is :-), thanks