Hi Scott,
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.
Exactly.
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).
I only have to add "unless transforms with implicit IV are used
(RFC 8750)".
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).
Or use the feature from G-IKEv2 draft, which enhances an
existing ESN transform to cover the case when anti-replay protection is not
used.
Regards,
Valery.
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
