Hi Michael,
similar to a MUD URL, an Epoch ID (or epoch marker, see:
https://www.ietf.org/id/draft-birkholz-rats-epoch-markers-01.html) can
be conveyed via many vehicles. As MUD URLs can, for example, be included
in LLDP payload, it seems like a low hanging fruit to me to distribute
Epoch IDs via router advertisements or M_FLOOD.
If there is interest in this application of a source for freshness, we
can certainly make that happen.
And while we are at it: If ANIMA has any requirements on potential
payloads of an epoch marker, please say so :-)
Viele Grüße,
Henk
On 19.08.22 18:41, Michael Richardson wrote:
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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
