Tony Cheneau escribió:
Hi Marcelo,
I don't know if when are up to do packet fragmentation in order to
support more Public Keys or if there is even a need for that.
couldn't parse this one....
I just meant to say: if we want for some usage more that 10 keys, we
might have to handle/use NDP packet fragmentation. NDP packet
fragmentation may be undesired here, but we have may have to state it
explicitly.
i think fragmentation should be avoided.
I woudl preffer sending multiple ND messages than fragment
> mmm, but the point is that if the attacker can drop ONE packet
and fake > the error message, it would render send inactive between
the nodes for > as long as the information is stored in the cache
(Which can be a long > time if the nodes talk to each other
frequently)
Maybe a node shouldn't store/update a cache when it can't talk to a
node.
Does it serve a purpose ?
but in this case it was able to talk to him and he obtained a reply
that contains the error message
So, i guess that you are suggesting is that we don't cache the error
message when it is not secured...
I guess we need to check how send works when dealing with plain ND
messages, I understand that SEND always rewrites plain ND, but i
don't rememebr how this works when ND has a cached data....
What I wanted to say was: the attacker can drop some ND packet, so he
can virtually drop anything. If he block on NDP packet and send an error
message in order to shutdown a communication, I don't see any difference
(the new attack effects are not worst if we consider that we won't
update any cache upon reception of an untrusted error message).
the difference is that if the receiver caches the error information, it
will not retry again, and the attacker will be able to disable send with
just dropping one message and forging an error.
in other words, the difference is the tiem frame of the impact of the
attack.
In the current situation, the attacker needs to be intercepting the
messages for the whiole duration of the attack, If the attacker leaves
the location and stop dropping the packet, the attack is over.
In this other situation, if the attacker manages that the reciever
caches the error information and makes it beleive that the receiver does
not support send, then send will not be used as lomng as the cached
information is preserved. Even if the attacker leaves the attack
position, the impact of the attack still applies
is this clearer?
> So, this would imply that dropping one packet and generating an
error > message (which is unprotected) would deactivate send
between two > nodes... right?
The error message should be protected (so a third party can check the
message during forensic).
how?
the whole point of the error message it to handle the case that there
is no common crypto suite between the two communicating nodes
So, by definition, the receiver cannot validate the error message
The receiver might not, but a third party could. An administrator could
place probes inside his network that will tell him an attack is
undergoing.
agree, for tracing purposes, this is useful
regards, marcelo
Note that the message could be understood by
the node. If the error message only state something like "you are
using
too short keys", it wouldn't prevent the receiver to verify the
message.
right, in this case i agree
but this opens the door to downgrading attacks though
I mean, would the error would sign by the long key or the short key?
The short key error in this case is caused by the node that will receive
the error. But it is true that it might be difficult to trust the error
message in some cases.
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
