Hi Joe, Christian,
From: to...@strayalpha.com [mailto:to...@strayalpha.com] Sent: Monday, May 30, 2022 6:21 PM To: Christian Huitema Cc: Valery Smyslov; 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 8:00 AM, Christian Huitema <huit...@huitema.net> wrote: The bar against TCP injection attacks might be lower than you think. An attacker that sees the traffic can easily inject TCP packet with sequence number that fit in the flow control window and are ahead of what the actual sender produced. It might be useful to be more specific about the issue. Data injection attacks on TCP connections interfere with the IPsec stream in a similar way to IP or UDP fragment attacks on IP or UDP tunnels that use fragmentation. In all three cases, attackers can corrupt in-transit packets via IP packet attacks, which is not possible with an unfragmented IPsec message. In all three cases, this happens when an injection can overwrite a portion of an IPsec message. Data isn’t injected to the user, though. I suggest we add the following text to the Security considerations: 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 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. (The text is still a draft, I’ve been waiting for Tommy to review it). Regards, Valery. Joe
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
