[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anti-replay notification
I find this argument convincing:
At 09:08 AM 8/20/97 -0400, dpkemp@missi.ncsc.mil (David P. Kemp) wrote:
>> From: Stephen Kent <kent@bbn.com>
[ ... ]
>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
[ ... ]
1. Consider what it means to the sender, if the receiver might notify the
sender it is implementing Anti-Replay:
The Initiator has an optional ability to keep sending without checking the
counter coming near rollover, but, if it gets notice of AR, then it is
going to check the counter and rekey, near rollover at the latest.
Why would anyone implement ability to not check the counter, while
including the option to yes check it and do re-key?
As for manual rekey, I believe everyone is in agreement that the sender
which did manual rekey knows that this is the case, and of course can't
re-key, so this is a separate case not relevant to the with-Key-Management
case.
2. Heads up! The proposal that the receiver notifies the sender about
Replay checking, implies the ISAKMP Responder might send the Anti-Replay
attribute in response when not sent by the Initiator.
I think it has been the principle in ISAKMP/Oakley, so far, that a
Responder returns an SA with an attribute list that includes all attributes
in one offered transform, none changed, none added; I believe many have
expressed this on this list. To the contrary I do remember, that some have
suggested lifetimes can be negotiated downward, but as I remember this was
not generally agreed to, and some responded stating this no-changes
principle. So I think the "no changed attributes" principle has stood so
far, but please correct me, anyone who understands otherwise.
We're not opposed to negotiated attributes here; it always seemed strange
to me to rule out a priori all negotiation, when some, like lifetime, are
obvious and not problematic. But people presumably have implemented on
this no-change basis and now would have to alter such logic.
To me this suggests that such a change at this late date is not worth
trouble in altering the drafts, nor in implementors racing to get another
complication included for coming interoperability tests, when many are near
a working standard implementation.
John Burke
jburke@cylink.com
Follow-Ups: