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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/30/2022 8:28 AM, Valery Smyslov wrote:
Hi Joe, Christian,

...
           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).

That text works. The main point is to be clear that IPSEC over TCP is significantly more fragile than IPSEC over UDP or IP, and the text does that. My only reservation is that you describe TCP injection as altering the packet, as if an attacker catches a packet in flight, changes some of the content, and then forwards it. That's not what they typically do. Attackers simply send TCP packets with a sequence number that is "in windows", so the receiver accepts the content of that packet instead of the genuine bytes sent by the peer at that same sequence number.

-- Christian Huitema


--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux