I just went through this draft, and I think the problem (which is "why do we avoid rekeying after 2^32 packets if replay is not enabled") is actually simpler than what the authors expect.
Solution 1: The note about ESN and antireplay is (section 3.3.3) If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Note that this states "SHOULD NOT", not "MUST NOT". We have the option of ignoring the SHOULD NOT, and if we do, there's no issue (and no protocol changes are needed in this case). Of course, this works only if both sides use this convention. Solution 2: The actual requirements about rekeying from RFC 4303 is (section 2.2, the non-ESN section) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. (Emphesis added). Not that, if anti-replay is not enabled, there is no such requirement (nor is there any security issue; wrapping around could mean that the attacker could reissue a previous packet with the same counter, however this is a replay, which we are explicitly allowing). Hence, I believe that this draft can be simplified to a notification that "I'm not doing replay checking, you don't need to rekey on a wrap" (which means you don't need ESN in the first place).
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
