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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
