[Rats] remote attestation Epoch ID distribution in IPv6 and GRASP

[Michael Richardson <[e-mail]>]

As explained at:
  https://www.ietf.org/archive/id/draft-ietf-rats-reference-interaction-models-05.html#name-uni-directional-remote-atte

and also referenced at:
  https://www.ietf.org/archive/id/draft-ietf-rats-architecture-21.html#name-example-3-epoch-id-based-pa
  (which has a cool SVG diagram)

one of the key ways to get freshness for remote attestation mechanisms is to have
some entity send a series of Epoch IDs to all parties.  They are
non-repeating, non-deterministic nonces that wind up being included in the
signed Evidence produced by Attesters.
draft-birkholz-rats-epoch-markers imagines reuse of RFC3161 TimeStampTokens
as one example.

In bilateral systems where TLS is used as a transport (such as in BRSKI
onboarding), then it possible to use tls-unique^WTLS Exporter to get
something which is fresh.  In other scenarios where Evidence will be
shared with a Verifier that did not participate in the TLS connection (such
as in background check model, which is what BRSKI would need to use) then
the Epoch ID mechanism may be a better way.

When working on this freshness model in the RATS architecture, one
distribution mechanism that we envisioned was some kind of rain from
("heaven") above of Epoch IDs.  Such as having them embedded in a GPS or 3G
signal/beacon.  This has advantages for uni-directional attestation where no
signals are allowed into the nuclear power plant, yet fresh attestations need
to be emitted.

Much more mundane scenarios just need to have the EpochID distributed in an
efficient manner.

One thought is an RA option. The universal RA option comes to mind, but the
EpochID is not a constant, so it does not entirely fit into one concept of
universal RA where it's something that can just get inserted verbatim into a
router configuration.
(I was going to CC 6man, but I'm not doing that yet)

A second thought is to do this via GRASP (RFC8990) M_FLOOD.
ANIMA's ACP operators will want to do regular attestation of routing
platform, so we will need such a thing.  A GRASP M_FLOOD could be forwarded
through the ACP, and if an Enterprise situation, could be then multicasted on
the normal links for hosts that need the EpochID.

As GRASP is just CBOR over UDP, sometimes multicast on IPv6-LL, it's not
more complicated than an RA.  As draft-birkholz-rats-epoch-markers seems to
be defining a signed EpochID in CBOR format, the match seems quite good.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide