Re: [Last-Call] [secdir] [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

["touch@xxxxxxxxxxxxxx" <touch@xxxxxxxxxxxxxx>]

See below...

—

Dr. Joe Touch, temporal epistemologist

www.strayalpha.com

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
Sent: Wednesday, June 01, 2022 5:43 PM
To: Valery Smyslov
Cc: draft-ietf-ipsecme-rfc8229bis.all@xxxxxxxx; secdir@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [secdir] [Last-Call] [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

 

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.

Joe

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call