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. > > I don't think your fix really helps in this scenario. > > If attacker intercepts TCP session carrying ESP packet with sequence > 0x1000 and manages to get the packet and drop the TCP session before > responder gets it, then it can create a new TCP session > sending this packet. The responder will switch to the attacker's > TCP session even with your proposal (until the initiator > creates new TCP session and sends some ESP packets with higher SN).
But he cannot take the ESP packet stolen half an hour ago, which still happens to be in 128 packet ESP replay window. Also he cannot steal 20 packets from the window, and play them one by one, every time original responder tries to get his TCP session back. We had this same problem with NAT traversal with UDP packets, i.e. attacker stealing some packets can always redirect the traffic to wrong peer, once per each stolen packet. In NAT traversal we cannot do anything, as there can be out of order packets. With MOBIKE this was fixed by using UPDATE_SA_ADDRESS notification to update the addresses. Here we can make the things better even for ESP packets, as there should not be reordered packets, thus requiring latest sequence number to update the address does not cause issues. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
