Hi Joe,
From: to...@strayalpha.com [mailto:to...@strayalpha.com] Sent: Tuesday, May 31, 2022 7:12 PM To: Tero Kivinen Cc: Valery Smyslov; Christian Huitema; sec...@ietf.org; draft-ietf-ipsecme-rfc8229bis....@ietf.org; ipsec@ietf.org; last-c...@ietf.org Subject: Re: [Last-Call] [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06 On May 31, 2022, at 8:29 AM, Tero Kivinen <kivi...@iki.fi> wrote: I think we should tear down the TCP stream immediately if we detect that length bytes can't be correct. If that’s the case, then you’re opening up this approach to a much lower bar to attacks. The design of TCP encapsulation is that IPsec survives when a TCP connection is closed for any reason, it just re-opens a new one. The performance will degrade, but that is that - TCP is not the primary transport for IPsec and should be used only when other transports (e.g. UDP) is not available. It would be significantly more useful to find a way to resync. I don’t have any particular suggestions there, except maybe when sync is lost to scan for a known byte pattern and try to resync there. If the IPsec then starts to work again, you’re set. If not, you keep scanning. This is the approach ATM used to find cell boundaries. Is there a reason not to include that as a fallback when such attacks are seen as a mitigation to avoid the restart overhead?? While this is possible (scan for known SPIs and check the ICV of the resulting packet), it will consume resources (crypto is not free), so I’m not sure it’s a better defense against injection attack. Note, that an attacker has already performed the successful attack on this TCP connection, so it did guess the correct sequence number and 4-tuple, so it can continue to inject data. With new TCP session it yet have to guess these parameters. Regards, Valery. Joe
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
