On Thu, Aug 25, 2022 at 11:55:13AM -0400, Michael Richardson wrote:
> Ah.
> A trusted third party would rain Epoch IDs down on all nodes, both
> transmitters and
> receivers. They could use signed M_FLOODs. yes, that creates a circular
> problem, but the EpochIDs could be arranged to be a hash list, a la S/Key.
For the base level of ANI i really love to minimize the number of dependencies
against a trusted third party. Aka: if everybody who floods information can be
responsible for replay protection of its own flooded messages, thats to me a
more
ANI philosophy compliant approach. A trusted third party could then be an
optional optimization on top.
The way i see it, whenever i hae to send another periodical instance of my own
M_FLOOD(s), then i would use a new session-id, and that would perfectly be valid
as a Epoch-ID... except that if i randomnly assign session-id as we say so now
in
rfc8990, then it will be pretty hard to discover old replays. ANd it will be
impossible
to do so for a newly waking up node.
Reading through rfc8990 i think we could do the following:
A node initially creates a pseudo-randomn session-id.
When it creates a message with its certificte to flood, it could also sign
in the same message that inital session-id together with a timestamp.
Any further messages from the same node would simply increment the session-id
(with wrap).
With whatever low periodicity it is appropriate to re-send the certificate,
it would also re-send a signed session-id with time-stamp.
I think this should make replay validation easy. It would effectively be
a per-message / per-node epoch-ID of the session-id.
I would also argue that this use of session-id is backward compatible to
rfc8990,
because nothing there says that pseudo-randomn-number N+1 can not simple the
pseudo-random-number N plus 1. (IMHO).
Cheers
Toerless
>
> > I couldn't find reasonable examples of how often epoch-ids in rats
> > would be changed, so i have a hard time coming up with a qualitative
> > comparison.
>
> It's a good question, and the answer depends upon how things will be used.
> I would envision a new Epoch every few minutes to every few hours.
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
