> > Isn't it easier to add a requirement that the received message must > > not be a replay? For example: > > > > It should choose the TCP > > connection on which it last received a valid and decryptable IKE or > > ESP message that is not recognized as a replay of some early message. > > No. > > Not replay == ESP packet we have not seen before that is still in > window != ESP packet which has largest sequence number. > > I.e., attacker sends RST to the tcp connection, initiator recreates > TCP session, and initiator sends one ESP packet to the TCP connection > having sequence number of 0x1000. Attacker messes up with the TCP > connection so that responder never sees the ESP 0x1000 packet, and TCP > connection is reset. For example sends RST before the actual packet > reaches the responder, but after the attacker has seen the contents of > the packet in TCP stream. > > Initiator then recreates tcp session with responder and sends some ESP > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that > TCP connection, creates completely new TCP session and replays the old > ESP message with sequence number of 0x1000 (which was not seen by the > server before). Responder will accept this as valid non replayed ESP > packet, and will move all traffic to this new TCP connection.
What then? What benefits attacker gains and how it will exploit the fact it hijacks TCP connection? The responder will eventually recreate new TCP connection and everything will continue to work. The reason I opposed your interpretation of "fresh" is that if you replace ESP with IKE in the example above and if you require the responder to ignore smaller MESSAGE_IDs if the higher are received, then the responder will ignore IKE message with ID=0x1000 in your example, because this message will be received after the responder receives 0x1001-0x1005. Since the initiator will never receive reply for ID=0x1000 it will eventually kill IKE SA. This is much more dangerous attack than the attack you described above. > The attack is not very efficient, and there are most likely easier > ways to do similar attacks, but there might be some other tricks > people might invent if we leave this thing open. Thats why I think it > is better to close it by saying that it is not enough to have valid > ESP packet which is not replay, but it must be valid ESP packet which > have sequence number that is higher than anything seen before. For IKE it'll make things worse. > One way of implementing that is to configure ESP replay window size to > be 1... That's probably OK, since TCP will provide in-order delivery. However, that will further complicate implementations, because you'll need to be able to dynamically manipulate ESP window size in case the transport changes. And IKE doesn't allow window to shrink, so we'll stick to size = 1. Not a good idea. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
