From: to...@strayalpha.com [mailto:to...@strayalpha.com]
Sent: Monday, May 30, 2022 7:00 PM
To: Valery Smyslov
Cc: 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
It might be useful to add that most of those injection attacks are similar to
the kind of attack possible when IPsec is carried inside IP tunnels or UDP
tunnels when IPsec messages are split across tunnel messages. In those cases,
the vulnerability depends on the predictability of the fragment identifier,
which can be much smaller than the predictability of being within the TCP
receive window sequence space, esp. for long-lived TCP connections.
Do you mean that fragmented packets will never be re-assembled at
receiving end and thus dropped?
We can add the following sentence after the list in the text below:
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.
Regards,
Valery.
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
On May 30, 2022, at 8:28 AM, Valery Smyslov <s...@elvis.ru> wrote:
Hi Joe, Christian,
From: <mailto:to...@strayalpha.com> to...@strayalpha.com [
<mailto:to...@strayalpha.com> mailto:to...@strayalpha.com]
Sent: Monday, May 30, 2022 6:21 PM
To: Christian Huitema
Cc: Valery Smyslov; <mailto:sec...@ietf.org> sec...@ietf.org;
<mailto:draft-ietf-ipsecme-rfc8229bis....@ietf.org>
draft-ietf-ipsecme-rfc8229bis....@ietf.org; <mailto:ipsec@ietf.org>
ipsec@ietf.org; <mailto:last-c...@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 < <mailto:huit...@huitema.net>
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
--
last-call mailing list
<mailto:last-c...@ietf.org> last-c...@ietf.org
<https://www.ietf.org/mailman/listinfo/last-call>
https://www.ietf.org/mailman/listinfo/last-call
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
