[secdir] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

[Christian Huitema via Datatracker <[e-mail]>]

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

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

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.

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.