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

[Christian Huitema <[e-mail]>]

On 5/30/2022 4:52 AM, Valery Smyslov wrote:
> Hi Christian,
>
> thank you for your review! Please, find my comments inline.
>
>> -----Original Message-----
>> From: Christian Huitema via Datatracker [mailto:[e-mail]]
>> Sent: Sunday, May 29, 2022 12:15 AM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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.

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. That means both on-path attackers and 
attackers that merely passively listen on traffic can do that. It is 
harder for attackers that are off path and don't actually see the 
traffic, but not impossible. They can spray one of the endpoints with 
fake traffic with a variety of port numbers and sequence numbers, and 
rely on birthday paradox to get some of it through. I agree that this is 
"just a DOS", but they could not mount that against IPSEC on UDP or IP.

-- Christian Huitema