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