Valery Smyslov writes: > Agree, that's what is in the suggested text: > > 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) I think we should tear down the TCP stream immediately if we detect that length bytes can't be correct. I.e., if the length in TCP stream and length in IKE packet do not match. We can authenticate the IKE packet, and if it passes the authentication but tcp indicates wrong length, then we know that someone messed up the TCP stream, and we have no way of recovering from that other than restarting the TCP stream. > > 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). > > I'm not sure we must go so far and this complication is really > needed. Let us make a distinction between on-the-path attackers and > off-the-path ones. On-the-path attackers who are able to read, > modify and inject (or even drop) packets can do a lot of bad things > and modifying specifically the length field is not the easiest way > to disrupt communication between peers. On contrast, it's quite a > hard task for the off-the-path attacker, who cannot read the TCP > stream, to modify exactly those two bytes in the stream where the > Length sits. So, most probably a larger part of the stream will be > corrupted, that will cause some packets drop, and, in case these are > IKE packets, most probably the IKE SA will be teared down by the > peers (due to timeout). It does not need to modify exactly those two bytes, it just needs to insert about 1500 bytes of data anywhere to the TCP stream. Most likely that 1500 bytes will contain at least one TCP packet boundary, and if we just insert random data there that will cause tcp packet boundaries to get messed up from that point forward. Most of the traffic in the stream will be ESP traffic, not IKE traffic, quite often you do not have any IKE traffic there as there is no need for it. If this attack is done on host B, then host B can't receive any packets from A, but A will still receive packets from B. After few tens of seconds the IKE of B will start liveness check using IKE packet and after few minutes that will fail, and then IKE SA is teared down. I.e., recover from that will take several minutes (i.e., in order of 5 minutes). On the other hand B will almost immidiately notice it is getting 100% of garbage from the ESP packets it is receiving from the tcp stream, so it should be very easy for it to detect that something is wrong (this of course assumes there is traffic going through the connection). As there is no way of recover from this kind of situation I think B should close the TCP connection almost immediately when it starts getting too many ESP packets which fail authentication or even basic sanity checks. If it can it can then reconnect or wait for the other end to reconnect (depending which role it had originally). It might also end up in situation where host B has received length that is quite long (for example close to 64kB), and is buffering incoming frames until it reaches that limit, and if there is little traffic between hosts this might take long time, but luckily if there is no traffic between, then the normal recover that takes few minutes will kick in, and long recovery does not matter, as there is no traffic... > Moreover, from my reading of RFC 5961, in many cases the result of > data injection attack will be that RST will be sent by one of the > peers (due to ACK war). > > So, I'm not sure we should advise implementers to complicate their > code for this specific case, because the final result will be the > same. I think that it is enough if we mention the possibility of > this event (as in the suggested text). I do not think the result is same. Without special code, anybody who can insert data to the TCP stream will be able to cause disruption which takes several minutes to recover. With code that checks that if sanity checks for incoming packets (IKE packet lengths, IKE authentication, ESP sanity checks, ESP authentication) fails for several packets in a row and closes the TCP connection, that will drop that outage to seconds (few seconds to detect, and few seconds to recreate TCP connection). -- kivinen@xxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
