[core] About freshness and order of information in CoAP End-To-End Security

[Aura Tuomas <[e-mail]>]

Reading "draft-hartke-core-e2e-security-reqs-00", I started to wonder about the freshness and reordering of sensor data and actuation confirmation. The examples in section "3.1.  One Request - One Response" seem quite simple compared to potential application requirements. 

https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#section-3.1 

Example: Alarm status retrieval

* There are many kinds of freshness: Sometimes you just want to avoid replays, e.g. for counting events. Sometimes reordering of data is not allowed, e.g. if you want the latest sensor status. Sometimes the data should come causally after another event, e.g. in nonce-based freshness mechanisms that bind the sensor data causally to a specific local clock interval at the receiver. Sometimes the data needs to be recent by the wall clock time, e.g. if you have loosely synchronized clocks. 

* In the alarm status example, it may not be necessary or sufficient for the status data to be "current". In fact, I don't think you ever need to link the answer to the individual alarm status request. Sometimes it is ok to have "recent" status information, in which case caching the at the proxy for a short period is ok. Sometimes you may not want to miss alarms that were raised and then dismissed, in which case the current status is not sufficient but you need the full history. 

Example: Actuation confirmation

* Some actuation may have unique identity, e.g. admit animal number 12345 through the turnstile, and need to be confirmed individually. However, that is not necessarily the case. Some actuation is cumulative, e.g. admit one person though turnstile. Some actions are idempotent, e.g. close the door, and one confirmation may be sufficient. 

* Some actuations need to be strictly ordered, e.g. open and close the door. Some can be reordered, e.g. close door A and close door B. This could possibly be discussed in terms of causal order (the vector clocks mentioned in the ACE WG list) and how much of that order needs to be preserved in the actuation and in confirmations. 

Perhaps some of the above comments are beside the point of the draft, but it looks to me that the concepts of freshness and ordering in object or multi-hop security are more difficult to define and address than in secure end-to-end connections where data on the wire is linearly ordered in each direction.

Tuomas