[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anti-replay notification
John et al,
You're right about the "no changed attributes" principal. The current
proposal would necessitate an exception for a Replay Window attribute which
would have to be (asymetrically) returned by the responder. I also believe
that this adds unnecesssary complexity for little benefit.
I'm of the group who feel that anti-replay should be mandated when using
dynamic keying and that the anti-replay window size need not be specified
in our documents. It just seems obvious to me that the size of the replay
window is host implementation dependent. We don't have to mandate that it
be 64-bits or a multiple of 32-bits. We should just be recommending that.
So, here's what I think this comes down to... Does anyone have any serious
examples, other than for manual keying, of situations where not enforcing
anti-replay would make sense in an environment where you have ISAKMP/Oakley
and the current AH/ESP? If not, then I would like to see anti-replay made
mandatory for dynamic keying before we submit the current AH/ESP drafts to
the IESG.
RE: lifetime
The lifetime attribute is a different animal. What the IPSEC DOI intends
to do is to define what happens when conflicting lifetimes are specified --
each side chooses the most restrictive lifetime(s). However, this doesn't
require asymetric or conflicting attributes in the proposals. Each side
knows what they offered and what the other side wanted and they each pick
the lower value(s). This is very different from the anti-replay response.
Derrell
Follow-Ups:
References: