Keeping observations alive after KUDOS?

[rikard-sics]

Check comments from Christian during IETF 112 CoRE session.

[rikard-sics]

Never silently forgot observations.

Always explicitly de-register (cancel) the observations with a CON.

If the server still doesn't ack the cancellation...

[rikard-sics]

Problem is that the client may perpetually having some values of SSN in its list of ongoing observations, this means always needing to jump to those values (and losing many SSNs). (As the server may not ACK the cancellation request).

One idea is to associate an epoch-age to each value in the list, then after for instance 10 epochs (KUDOS executions), these observations are always terminated from both client and server.

[rikard-sics]

CA: You need to take into account any observation that the server has not yet acknowledged as terminated, not just the current ones.

CB: You can have a choice for the device between terminating and long-jumping. Otherwise preference for "long-jumping" rather than "skipping" (which sounds onerous for each and every request). CB: Rekeying is disruptive anyway, we need to understand what this means for an application, especially one thinking real-time. Describe how desctructive it is. RH: And what should not be done while rekeying. CB: Yes. The above is useulf to reduce disruptiveness, specifically as to observations. CA (on the disruption not only to observations while this runs): Gotta go over the document again, but I think we can make it continuously usable. (So that at every point in time the device can send a message, even if it's using the intermediary context) RH: Right, most about understanding which OSCORE context to use to protect messages in the meanwhile.

==> This can practically become:

• The client never silently forget about observations
• The client that wants to cancel an observations always does that through a CON request with Observe:1
• ...
• But even by doing so, the client may never become secure about the server having actually cancelled an observation. This is the case if cancellation requests are lost, even after the maximum retransmission.
• Then, to be conservative, the client would not free up the corresponding Sender Sequence Number, and will jump forward beyond it, thus shrinking more and more the amound of available Sender Sequence Numbers to use as Partial IV.

Possible way forward: give a maximum lifetime in epochs to every Sender Sequence Number used in an Observation Request of whatever epoch for which there was no confirmation of cancellation from the server. Then, at the beginning of every epoch before the last permitted one, the client MUST attempt to cancel if observation again. If a new epoch start beyond the lifetime limit, both client and server remove the observation.

[rikard-sics]

https://mailarchive.ietf.org/arch/msg/core/Bh81qE65N6zn6IefyoS3rOr3U_0/

• The 'p' to indicate PFS or no-PFS mode may not be beside the 'd' bit, but rather in the 'x' field intended to signal the size of the 'id detail' field (which would still be up to 127 bytes, while 8 bytes is the common recommendation).

• Using yet another bit 'b' as above, the client may signal the server about its own intention of preserving old observations in a safe way, i.e., by long-jumping (or skipping, though unpreferred) the SSN value.

• The same bit 'b' would be useful for the server to set in the KUDOS message it sends, to confirm that it is also indeed preserving old observations.

• The bit 'b' totally needs to be authenticated! One way to do that can be deriving the new Security Context by taking as input not only the concatenation of N1 and N2 transported as 'id detail', but also the value of those bits (or, for simplicity, of the whole 'x' field including those bits).

[rikard-sics]

We now have a section in the draft on how to accomplish preservation of observations, including how to signal it.