Hi Joe, From: touch@xxxxxxxxxxxxxx [mailto:touch@xxxxxxxxxxxxxx] See below... — Dr. Joe Touch, temporal epistemologist On Jun 1, 2022, at 9:53 AM, Valery Smyslov <svan@xxxxxxxx> wrote: Hi Joe, From: secdir [mailto:secdir-bounces@xxxxxxxx] On Behalf Of touch@xxxxxxxxxxxxxx Hi, all, Overall, it seems sufficient to: - highlight how much more vulnerable this tunnel makes IPsec to DOS attacks i.e., that single packets can cause the entire connection to need to be reset Already in the draft. - indicate that there IS a way to avoid that hit by re-syncing the sync requires a scan, but that in some cases such a scan can be more efficient in than starting a new connection, although it does mean that such an attack may be more likely moving forward (note: restarting a connection might provide useful information to an attacker, where continuing may hide the impact of such an attack too, so resync has cons and pros). I’ve added some text about the possibility of a resync. About information for an attacker – if we talk about off-the-path attacker, then in general it is unaware of the results of its attack, it may only guess them indirectly. And since resync will take some time and thus introduce some delay, that may be visible to attacker, I’m not sure which method is preferable in this context – everything depends on specific conditions for the attacker. Yes, but a connection restart is much more potentially visible to an external viewer than a few IPsec packets inside the transfer being discarded. There may be other considerations. If the attack is successful, then the attacker has already guessed the correct sequence number and 4-tuple, so it is likely that it continues to inject data. So, you generally don’t know whether the stream you are using while trying to resync is genuine, and in fact the resync can never happen or will take a long time, during which the IKE SA will be closed by timeout. In contrast, re-creating TCP connection will stop the current attack, the attacker will need to start over. So I prefer the resync to be a MAY and the close to be a SHOULD. Regards, Valery. Joe |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
