Hi Tero, > > 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.
So what? If an attacker is so powerful that it can steal ESP packets, block delivering them to the responder and replay these packets later, it doesn't really matter whether it is latest ESP packet (with the highest SN) or some previous packet. The attacker can easily manipulate values in IP and TCP headers of stolen packets, so that the responder will try to send packet back to probably non-existing address/port. > 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. Sure, but it won't help against this kind of attack. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
