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

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> 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.

Actually just messing up any length octets on the wire will completely
mess up the packet structure, as there is no way of recovering that
except to tear down the TCP and start over, so this makes it easier to
attack than to attack against UDP.

For udp you would need to modify every single udp packet to cause them
to fail to authenticate. For tcp, you need to take single TCP packet,
and modify length bytes (for example simply flip one bit there), and
that will mess up the whole stream and most likely tear down the whole
IKE SA.

I.e., if you change the length bytes of 100 byte IKE packet to 200
bytes, then receiver will keep waiting until it has 100 extra bytes
after the IKE packet (from the next IKE or ESP packet in tcp tunnel),
and then try to parse the IKE packet and notices it is only 100 bytes
long (the authentication of the IKE packet will succeed, as it was not
modified, and the IKE packet has length inside, so it will know that
IKE packet was only 100 bytes long).

Now after that it will read two random bytes from the stream, and
assume they are then length field, and wait for that long and so on.
I.e., it will never really recover (except by accident).

Receiver can notice that, i.e., if it sees that there is extra data
after the IKE SA packet, or the length field of the TCP stream is less
than what is expected by the IKE packet, it knows something is wrong,
and can restart the TCP connection.

Detecting this on ESP packets is harder, but if the packets after the
length field does not look like ESP packet, then we know that
something is messed up and we need to restart the TCP stream.

And as others already pointed out, it is very easy to just send few
bytes in to the TCP stream, or just modify one frame by modifying the
length fields.

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). 
-- 
[e-mail]