[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anti-replay notification
David,
>
>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 is excatly what the specs require, i.e., the sender always increments
the counter and sends a sequence number. Cheryl pointed out how checking
for counter overflow at the sender causes a problem for manually keyed SAs
(where anti-replay must not be used), so the simple solution I proposed was
to supress the counter overflow error in the case of a manually-keyed SA. A
more general solution is to supress overflow checking for any SA for which
AR is not enabled. That further motivates having the receiver notify the
sender if AR is enabled.
>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.
An abiliity to support AR is mandatory, but its use is optional on a per-SA
basis, under the unilateral control of the receiver.
>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 specs do not call for AR negotiation, just notification of use of AR,
plus window size. As noted earlier, if we don't notify the sender that AR
is enabled, then we can't supress sender checking for overflow in a more
uniform fashion.
>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.
Actually, neither implementation nor testing experience is relevant here.
What is relevant is operational experience in debugging network problems,
especially from a single end of a data path, in an operational environment.
We don't have any significant data on this in the context of IPsec, but
some folks (perhaps not subscribers on this list) do have such experience.
My interactions with folks at our ISP, who do a lot of single-ended
debugging of problems, motivates the suggestion for the AR window size
notification, at least in part.
Steve
References: