On Sat, Aug 27, 2022 at 09:41:20AM +1200, Brian E Carpenter wrote:
> > 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]
Sure, but that scheme is designed, and good enough to discover
looping packets within a window of maybe a few seconds. An implementation
that does that would not recognize that a 4 hour or several day old message
is being replayed.
And an attempt to store that many old messages through a hash table would not
scale.
Thats why for the replay protection you need some numerically increasing
mechanism and
then i think link it to some rough timestamps.
> > 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?
I don't really know what "all epoch" mechanisms would mean. Ideally
we would look for the most easily adopted replay protection mechanism that
had in some othr protocol passed IETF SEC standards approval. Whether its
called epoch or not.
> > 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.
all assignments are only local to a node given how we also have the
initiator field.
> 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.
So, the question is what attack vector we would open up if we used
sequential session-ids. Given how the signature protects the message,
i will claim there is no new attack vector as long as the signature is
checked.
But if GRASP forwarders do not check the signature, then the sequential
allocation could increase the risk that an attacker tries to stop
valid flooded messages by "pre-flooding" faked messages with the
guessed session-ids.
Now, some part of this "pre-flooding" risk exists today: If i am
a bad ANI node, i receive the valid flood-message, and i have a
second connection to another part of the network, i can pre-flood
a broken message and stop that the real message makes it to that
part of the network.
Aka: This is an argument to actually do check signature when flooding
them.
The argument, why checking signature would be 'free' is that for
most flooded messages the ANI node would not only be flooding, but
also receivign/using. And those nodes would need to check signature
anyhow.
> 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]."
Well, maybe there is something that can be read out of rfc4086, but
we are also always free to update rfc8990 for the case session-id
is used in conjunction with signatures.
Cheers
toerless
> 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
> > >
> > >
> > >
> > >
> >
> >
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
