On 30-Aug-22 00:13, Toerless Eckert wrote:
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.
I hope that GRASP message density will be quite low (except during
exciting times like power fail restarts), but indeed you are correct.
The GRASP session ID is really just like a randomized TCP port number.
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.
I mean that if you write the current epoch number into non-volatile
storage and then your node sleeps for a year, the epoch number could
perhaps have cycled. However, I agree that we should not re-invent
this wheel.
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.
Right. So I'm not yet convinced we should repurpose the session ID
for this. If we're going to focus on signing objectives, maybe
we need to decouple this aspect completely from the session ID?
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.
Possibly. But from an implementer's viewpoint, the relay path doesn't
decode the message - it just decrements the loop count and resends
immediately on all the other interfaces. It's a quite separate code
path that decodes (parses) the message and would verify the signature.
I'm not saying it can't be done, but it's like the fast path/slow path
argument for routers. This puts relaying on the "slow" path.
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.
Sure, we could if we wanted.
Brian
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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
