Valery Smyslov writes: > I still think that it's better to put the text about resync into the > Security considerations. I think this method is specific for Length > corruption which most probably will happen as a result of injection > attack. So, the new para in the Security considerations would look > like: > > If an attacker successfully mounts an injection attack on a TCP > connection encapsulating IPsec traffic, and a Length field in the TCP > stream is changed as a result of this attack, then the receiver in > most cases will not be able to correctly identify the boundaries of > the following packets in the stream, because it will try to parse an > arbitrary data (the result of encryption) as ESP (or IKE) header. > This will fail and for this reason all the following packets will be > dropped. Eventually the situation should self-recover, but it may > take several minutes and may result in IKE SA deletion and re- > creation. To speed up the recovery implementations are advised to > follow recommendations in Section 6.1 and to reset TCP connection in > case incoming packets contain an ESP SPI which doesn't correspond to > any incoming ESP SA they have. Once the TCP connection is reset it > will be re-created by TCP Originator as described in Section 6.1. > Alternatively, implementations MAY try to re-sync after they received > unknown SPI by searching the TCP stream for a 64 bit binary vector > consisting of a combination of some SPI they know (first 32 bits) and > a valid (E)SN for this SPI (another 32 bits) and try to validate the > ICV of a packet candidate taking the preceding 16 bits as a Length > field. They can also search for 4 bytes of zero (non-ESP marker) > followed by 128 bits of IKE SPIs of IKE SA associated with this > stream and try to validate ICV of this IKE message candidate taking > the preceding 16 bits as a Length field. Works for me. -- kivinen@xxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
