Hi Tero, > 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. Thinking a bit more about the problem: - IPsec stream consists mostly of random data (as result of encryption) with uniform distribution - if an attacker manages to overwrite a single Length field, then the beginning of the next packet (including the next Length field) will be this random data So: - with probability 1-1/2^32 all subsequent packets will be treated as ESP packets, and not as IKE packets (the probability for non-ESP marker to be non-zero) - the "SPIs "of these "ESP" packets will be random, so unless the receiver has very large number of active ESP SAs (say > 2^31), these "SPIs" will be unknown to the receiver So, it's enough to check whether the SPI of the received ESP packet is valid. This is a simple check that will work in most cases. If an SPI is invalid, the receiver should immediately reset TCP connection. I think that receiving a single invalid SPI is enough reason to do this, since this should never happen in normal conditions. Any thoughts? Regards, Valery. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
