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

Some notes below...

> On May 31, 2022, at 4:14 AM, Valery Smyslov <svan@elvis.ru> wrote:
> 
> Hi Joe,
>  
> From: touch@strayalpha.com [mailto:touch@strayalpha.com] 
> Sent: Monday, May 30, 2022 10:57 PM
> To: Tero Kivinen
> Cc: Valery Smyslov; Christian Huitema; secdir@ietf.org; draft-ietf-ipsecme-rfc8229bis.all@ietf.org; ipsec@ietf.org; last-call@ietf.org
> Subject: Re: [Last-Call] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
>  
> On May 30, 2022, at 12:25 PM, Tero Kivinen <kivinen@iki.fi <mailto:kivinen@iki.fi>> wrote:
>>  
>> I think we need to add text explaining how to detect when the TCP
>> length framing gets messed up by attacks, and how to recover (i.e.,
>> close down the TCP channel and recreate the TCP channel). 
>  
> The impact of RSTs can be limited for this purpose by recommending RFC5961 for these connections.
>  
>           I’ve added a reference to RFC 5961.
>  
>           Currently the new text in the Security considerations looks like:
>  
>    TCP connections are also susceptible to RST and other spoofing
>    attacks [RFC4953].  This specification makes IPsec tolerant of sudden
>    TCP connection drops, but if an attacker is able to tear down TCP
>    connections, IPsec connection's performance can suffer, effectively
>    making this a DoS attack.
>  
>    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
>  
>    [RFC5961] discusses how TCP injection attacks can be mitigated.
>  
>    Note, that data injection attacks are also possible on IP level (e.g.
>    when IP fragmentation is used) resulting in DoS attack even if TCP
>    encapsulation is not used.  On the other hand, TCP injection attacks
>    are easier to mount than the IP fragmentation injection attacks, because
>    TCP keeps a long receive window open that's a sitting target for such
>    attacks.
>  
>    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.

Overall, that’s good, but….

>  
>  
> But if even data injection has the same impact, it’d be much better to see if there’s a way to recover “sync” in the byte stream rather than expecting a new connection.
>  
>           TCP connections can be closed and re-open – I don’t think this is a big problem if IKE SA survives.

Not huge, but a lot bigger than native IPsec - and that’s the issue. See my other note about re-sync.

>           The real problem is when IKE SA (and all Child SAs) is teared down as result of attack.
>           This can happen when IKE message is corrupted or incorrectly parsed as a result of data injection attack.
>  
>           Currently the draft says that there is no need to retransmit the request message in case of TCP (with SHOULD NOT).
>           We can add a note that implementations MAY retransmit messages to mitigate a possibility of data injection attacks.
>  
>           Regards,
>           Valery.
>  
>  
>  
> Joe
>  
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call