Antony Antony writes: > As an extreme example, consider the case where anti-replay protection is > disabled. Suppose the receiver first receives a packet with sequence number > 0x00000003 00000011. Then, it receives an out-of-order packet with sequence > number 0x00000000 FFFFFFF0. Although this is likely a corner case, it would > prevent the receiver from decrypting the packet correctly because it would > guess the higher-order 32 bits as 0x00000002 or, at best, 0x00000001. > Accurately guessing 0x00000000 would likely be impossible.
If your network has reordering in order of 8589934625 packets I think there is something seriously wrong. Most likely if the packet is 8589934625 packets in the past, the upper layer will not want that anymore. Even if using the 100 Gbit/s link it takes about 40 seconds for sending 8589934625 packets (assuming tiny 64 byte packets). Most of the upper layer protocols have already retransmitted stuff long before that. Also the replay window code in Appendix A assumes that replay window size is smaller than 2^31 packets, so there is no point of looking back more than that. I.e., using Bh or Tl depending on the Seql. The more common case is that you suddenly loose more than 2^32 packets, for example someone disconnect the cable and reconnects it after 30 seconds, during which there could have been 1.5 * 2^32 packets sent over the link, so your higher 32 bits might be off by value of 1 or 2. This means that when you get packet which has upper 32 bits of Seqh = 0x00000003 instead of Th = 0x00000001 and the authentication fails because of that you might try Th+1 ... Th+n where n depends on link speed, and how long the outage was. If someone disconnects the cable for 30 seconds, the device usually will notice this as there is no longer packets come in. It can assume that at maximum on 100 Gbit/s link the Th might be incremented about every 10 seconds, so it could simply try few values to see if it can sync the Th to allow it to recover from the loss. Note, that we have already lost 6442450944 packets, so loosing few more does not matter. So you could simply take one packet, drop it to slowpath (rate limited), and try to recover inside the slow path processing and after you find match, you can update the fast path with correct value for Th... You do not need to reintroduce the packet you used for testing back to the system, as whether you dropped 6442450944 or 6442450945 packets does not make real difference, and most likely you already dropped several thousands or millions while doing the testing... -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
