On 26-Aug-22 21:26, Toerless Eckert wrote:
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.
It just means adding a hash table to the session-id cache.
BTW, a node is already required to check for session-id reuse:
"When allocating a new Session ID, GRASP MUST check that the value is not already in
use and SHOULD check that it has not been used recently by consulting a cache of current
and recent sessions."
[RFC8990 section 2.7]
ANd it will be impossible
to do so for a newly waking up node.
True. But isn't that a general problem for all epoch mechanisms?
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).
Except that you would have to check that this new session-id has
not already been assigned. This is highly unlikely but mathematically
possible.
The reason we made the session-id pseudorandom was to make it
unpredictable. If an attacker knows that session 1234 is always followed
by 1235, it makes their life easier. Your proposal would lose that
property.
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).
I think it does:
"It MUST be generated by a pseudorandom number generator (PRNG) using a locally
generated seed that is unlikely to be used by any other device in the same network. The
PRNG SHOULD be cryptographically strong [RFC4086]."
Regards
Brian
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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
