Valery Smyslov writes: > > 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.
As I said this is not serious, but it is vulnerability, which is easy to fix. There might be tricks you can do (for example forward multigigabyte video stream from server to some unsuspecting client, while the original recipient is just wondering where is my video, until after few minutes it times out and tries to recreate the TCP session, or sends new packet through the TCP session. > 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. IKE will not have this issue, as every single IKE frame will require response, thus if the original initiator did not get IKE response to his request when the attacker killed the connection, then it will retransmit when it recreates the TCP session. This only really affects ESP, not IKE. Also in IKE the window size is quite often also 1. And, I am not saying they should ignore the messages, I say they should not consider the messages as fresh, meaning they should not turn old traffic to that new TCP session until they see fresh message. > > 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. And I was talking about ESP. Not IKE. For IKE there is no problem there as there is always response, thus blackholes are detected. For ESP there can be problems. > > 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. Again, I do not think this is needed for IKE, I think it is needed for ESP. With ESP it is possible for the attacker to redirect the packets from the server to wrong address for long time, by just sending few packets, and the situation might be fixed only after the original initiator wonders where his packets are and starts to do corrective actions. (and IKE window can shrink, as rekey resets the window size to 1). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
