[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anti-replay notification
> From: Stephen Kent <kent@bbn.com>
>
> The current drafts only state that anti-replay must not be used for
> manually keyed SAs; they do not state the converse. I don't recall any WG
> discussion calling for mandatory use of anti-replay for automatically keyed
> SAs. However, if we did adopt that stance, it would remove the base
> requirement for a receiver to advise a sender if anti-replay were enabled
> at the receiver.
If, for automatically-keyed SA's, anti-replay may be used, then why not
just require the sender to behave conservatively and assume that it is
always being used. I.e. never cycle the counter, and don't require AR
notification.
That would have the same effect as making anti-replay mandatory (force
rekeying before overflow), but would not force thin receivers to implement
AR just for the sake of compliance with the spec.
Even if AR notification is simple to add to ISAKMP, it's just one more
detail to code, one more complication to the spec, one more
option to analyze. Philosophically, I lean toward not negotiating things
unless there's a strong benefit to doing so. In this case, the benefit
(allowing SAs to last beyond counter cycling if the receiver is not
doing AR checking) is vanishingly small.
The debugging benefits of AR window size notification also seem pretty
slim, but I'll defer to the folks with actual implementation/testing
experience to settle that point.
Follow-Ups: