[OpenTRV-dev] Very basic backhaul thoughts

[Damon Hart-Davis]

I made some notes in Messaging.h.


DHD20150403: messaging thoughts including integrity.

Assume messaging maximum possible frame size will generally be 64 bytes or less,
and will vary significantly with the options chosen below.

Assume that the leaf end is a low-powered CPU and so has to be simple.

Assume that some of the data carried may be sensitive, eg privacy related or for driving actuators.

Assume that the raw messaging transport is by default:
  * one way
  * lossy
  * noisy
  * bandwidth limited and/or expensive
  * overhearable, eg over ISM radio or similar.

(Some variants like TinyHAN are two way, some transports may be radically different such as HTTPS over a LAN.)

Have one or more backhaul layers available at run-time leaf (with superset at concentrator)
with some constant capabilities, ie that can be checked/selected at pref at compile time, such as:

  * Frame formats that can be carried on this channel (1 or more):
      * JSON (compact ASCII7 superset, printable only 32--126 with no linebreaks or other control).
      * Whitened binary (with no 0x00 or 0xff bytes), so limited-length runs of either bit, and both values possible as delimiters.
      * Structured binary (as interpretted by underlying channel eg with TinyHAN).
      * Pure binary.

  * Ability to mark some frames as 'important' (bool), eg containing changed values, with extra efforts at delivery (eg double TX).

  * Maximum data integrity protection available from the channel (enum / small int):
      * NONE: None (sent with no checksum, etc, clear text): may be OK for underlying reliable/secure medium and/or non-critical data.
      * CHECK: Simple check value applied and verified, eg typically 7--16 bit check sum or CRC.
      * SEQ: Above plus small frame sequence number.
      * AUTH: Above plus crypto-based authentication.
      * ENC: Above plus encryption.
    (Data receiver should usually check data for semantic/syntactic integrity etc also, especially if a low level is used here.)

All systems should support at least JSON and whitened binary formats with a simple (CHECK) integrity check.

All systems with privacy-related data must support encyption (ENC) or the ability not to send sensitive data,
and/or the underlying backhaul can guarantee ENC-level integrity itself (eg tunelling over https).

At run time (and possibly at compile time) it must be possible to discover the maximum data frame size possible
with the selected parameters.

Note that for higher integrity levels keys may have to have been pre-shared for example,
and any modes not supported by the concentrator may have to be removed to the 'available' list.

At run time it should be possible to specify above parameters with each frame to send from leaf,
and those parameters plus some associated values (eg sequence numbers/range) should be recoverable.
Data that fails integrity checks is in normal circumstances not available nor are crypto keys used,
though parameters such as algorithm and strength may be).