Some notes below... > On May 31, 2022, at 4:14 AM, Valery Smyslov <s...@elvis.ru> wrote: > > Hi Joe, > > From: to...@strayalpha.com [mailto:to...@strayalpha.com] > Sent: Monday, May 30, 2022 10:57 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] Secdir last call review of > draft-ietf-ipsecme-rfc8229bis-06 > > On May 30, 2022, at 12:25 PM, Tero Kivinen <kivi...@iki.fi > <mailto:kivi...@iki.fi>> wrote: >> >> I think we need to add text explaining how to detect when the TCP >> length framing gets messed up by attacks, and how to recover (i.e., >> close down the TCP channel and recreate the TCP channel). > > The impact of RSTs can be limited for this purpose by recommending RFC5961 > for these connections. > > I’ve added a reference to RFC 5961. > > Currently the new text in the Security considerations looks like: > > TCP connections are also susceptible to RST and other spoofing > attacks [RFC4953]. This specification makes IPsec tolerant of sudden > TCP connection drops, but if an attacker is able to tear down TCP > connections, IPsec connection's performance can suffer, effectively > making this a DoS attack. > > TCP data injection attacks have no effect on application data since > IPsec provides data integrity. However, they can have some effect, > mostly as a DoS attack: > > o if an attacker alters the content of the Length field that > separates packets, then the receiver will incorrectly identify the > margins of the following packets and will drop all of them or even > tear down the TCP connection if the content of the Length field > happens to be 0 or 1 (see Section 3) > > o if the content of an IKE message is altered, then it will be > dropped by the receiver; if the dropped message is the IKE request > message, then the initiator will tear down the IKE SA after some > timeout, since in most cases the request message will not be > retransmitted (as advised in Section 6.2) and thus the response > will never be received > > o if an attacker alters the non-ESP marker then IKE packets will be > dispatched to ESP and sometimes visa versa, those packets will be > dropped > > o if an attacker modifies TCP-Encapsulated stream prefix or > unencrypted IKE messages before IKE SA is established, then in > most cases this will result in failure to establish IKE SA, often > with false "authentication failed" diagnostics > > [RFC5961] discusses how TCP injection attacks can be mitigated. > > Note, that data injection attacks are also possible on IP level (e.g. > when IP fragmentation is used) resulting in DoS attack even if TCP > encapsulation is not used. On the other hand, TCP injection attacks > are easier to mount than the IP fragmentation injection attacks, because > TCP keeps a long receive window open that's a sitting target for such > attacks. > > An attacker capable of blocking UDP traffic can force peers to use > TCP encapsulation, thus degrading the performance and making the > connection more vulnerable to DoS attacks. Note, that attacker > capable to modify packets on the wire or to block them can prevent > peers to communicate regardless of the transport being used.
Overall, that’s good, but…. > > > But if even data injection has the same impact, it’d be much better to see if > there’s a way to recover “sync” in the byte stream rather than expecting a > new connection. > > TCP connections can be closed and re-open – I don’t think this is a > big problem if IKE SA survives. Not huge, but a lot bigger than native IPsec - and that’s the issue. See my other note about re-sync. > The real problem is when IKE SA (and all Child SAs) is teared down > as result of attack. > This can happen when IKE message is corrupted or incorrectly parsed > as a result of data injection attack. > > Currently the draft says that there is no need to retransmit the > request message in case of TCP (with SHOULD NOT). > We can add a note that implementations MAY retransmit messages to > mitigate a possibility of data injection attacks. > > Regards, > Valery. > > > > Joe > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
