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

[Valery Smyslov <[e-mail]>]

Hi Joe,

 

From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, June 02, 2022 5:41 PM
To: Valery Smyslov
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [secdir] [Last-Call] [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

 

See below...

—

Dr. Joe Touch, temporal epistemologist

www.strayalpha.com





On Jun 1, 2022, at 9:53 AM, Valery Smyslov <[e-mail]> wrote:

 

Hi Joe,

 

From: secdir [ <mailto:[e-mail]> mailto:[e-mail]] On Behalf Of  <mailto:[e-mail]> [e-mail]
Sent: Wednesday, June 01, 2022 5:43 PM
To: Valery Smyslov
Cc:  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail]
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.

 

         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