Hi Christian,
thank you for your review! Please, find my comments inline.
-----Original Message-----
From: Christian Huitema via Datatracker [mailto:nore...@ietf.org]
Sent: Sunday, May 29, 2022 12:15 AM
To: sec...@ietf.org
Cc: draft-ietf-ipsecme-rfc8229bis....@ietf.org; ipsec@ietf.org;
last-c...@ietf.org
Subject: Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
Reviewer: Christian Huitema
Review result: Has Nits
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.
This draft is ready, with a single nit: I wish the security section mentioned
data injection attacks over TCP, not just SYN flooding and RST attacks.
This draft is a bis version of RFC 8229, which describes how to encapsulate IKE
and IPSEC in TCP. The new text adds precisions on how to handle TCP specific
issues, which taken together help making the the specification more robust. The
changes from RFC 8229 include:
* added section 7.2, retransmission, specify that UDP-style retransmission
logic of IKE should be replaced by simple detection of failure over timers, and
that if an initiator wants to retry an exchange, they have to start a new
connection.
* added section 7.3, cookies and puzzles, points out that source address
spoofing is already prevented by the 3-ways handshake of TCP, and that cookies
SHOULD NOT be sent, unless a puzzle is also sent.
* added section 7.4, error handling in IKE_SA_INIT. RFC 7296 says "Because all
error notifications are completely unauthenticated, the recipient should
continue trying for some time before giving up. Draft says that if an attacker
manages to insert a fake error message in a TCP connection, then the initiator
will never receive correct messages on that flow and should act on the error
immediately -- unless the error can be corrected by repeating the request with
amended parameters.
* moved section 10 to section 7.6, Considerations for Keep-Alives and Dead Peer
Detection, with an addition that IKEv2 exchange of informational messages
should be used instead of TCP keep-alive. (Note that moving the section means
the reviewer cannot use "diff" to find what changed, and that's not nice.)
We understand this, but we think that the new document has more logical
structure.
* moved section 8 to section 8.1. Added clarifications for cases when moving
from a path that supported UDP to one that required TCP, and vice versa.
* added section 8.2 for IKE redirect, with clarification on what happens when
redirecting from a path that supported UDP to one that required TCP, and vice
versa.
* moved last paragraphs of section 8 to section 8.3 on IKEv2 Session Resumption
* renumbered section 10 and higher as section 9 and higher.
* updated IANA considerations
Security considerations are unchanged from RFC 8229. This is a missed
opportunity. The security considerations correctly state that "IKE Responders
that support TCP encapsulation may become vulnerable to new Denial-of-Service
(DoS) attacks that are specific to TCP", citing SYN flooding attacks, and later
mentions TCP Reset attacks against both initiators and responders. The security
section does not mention packet injection attacks against TCP connections,
although this kind of attack is actually discussed in section 7.3.
In general packet injection attacks have no effects on applications, since both
ESP and IKE
provide data integrity and will ignore packets that fail ICV check.
However, I agree that in some cases the attack may have some effect:
- 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 happen to be 0 or 1
- if the content of an IKE message is changed, 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 timeout, since in most cases the request message will
not be retransmitted
(as advised in section 7.2)
- 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
- if an attacker modifies IKE messages while new IKE SA is being established
(i.e. in the IKE_SA_INIT exchange), then in most cases this will result in
failure to establish IKE SA
In other words, the result of packet injection attack will be some kind of DoS
attack.
We can add these considerations into the Section 11.
Note, that if an attacker is so powerful, that it is able to modify packets
on the wire, then it may mount DoS attack on IPsec regardless on the transport
being used.
TCP specific attacks are not an issue as long as TCP encapsulation is only used
on network paths that do not support UDP. On the other hand, since TCP is more
vulnerable to denial of service than UDP, we have potential downgrade attacks
in which an attacker somehow convinces the initiator that UDP is not available,
when in fact it is. The initiator will move to using TCP, and the attacker can
then attack the TCP connection. It might be worth mentioning this in the
security section, and how the guidance provided in section 6.1 mitigates such
attacks.
We can add a sentence that an attacker can force TCP encapsulation by blocking
UDP.
Of course, IKE and IPSEC are already protected against UDP or IP packet
injection attacks, which are much easier to mount than TCP injection attacks.
However, UDP or IP packet injection will generally not affect the state of the
security associations. TCP packet injection attacks will force initiators and
responders to abandon the TCP connection, as explained for example in section
7.3. It might be worth mentioning that the defenses against RST injection also
apply against other forms of packet injection.
If the TCP connection is abandoned (for any reason) and the associated IKE SA
is still up, then the IKE initiator will re-create it. So, it is not a big
deal, but definitely
can influence performance. On the other hand, an attacker who is able to alter
the packets on the wire (TCP, UDP, any) can make IKE peers to tear down IKE SA
(e.g. by spoiling every packet). So, I'm not sure using TCP gives significant
advantages for an attacker here, in most cases it will result in DoS.
