[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few observations about the replay issue

Folks,

In thinking about the issues and tradeoffs, a new (to me :-) issue came
up.  What do we really mean by "manual configuration".  Reading between
the lines seems to indicate that some folks might use the "manual API"
with some non-ISAKMP key management protocol.  If this is the case, and
it seems like a reasonable way to connect other key management protocols
to the system, then the question arises of whether anti-replay must not
be used with things installed using the "manual API", or whether we need
a way to indicate "really manual" or "automatic, non-ISAKMP" in the API.
(Or alternatively, a way to say "cannot use anti-replay with this SA").

If such a mechanism were to exist (what have the implementors done?),
then we could use the following rules.

At sender and receiver,
	The anti-replay field is always present.
	The anti-replay counter is initialized to zero when the SA is
		created.

At sender,
	For each packet to be sent, the counter is incremented by one.
	If the SA does not have the "cannot use anti-replay with this
		SA" flag set, and the counter is zero, an error event
		has occurred, drop the packet.
	Otherwise, place the incremented counter in the packet and ...
		send it.

At receiver,
	For each packet received, if the "cannot use anti-replay with
		this SA" flag set, ignore the anti-replay field.
	Otherwise, perform anti-replay processing -- window check, etc.

Would this set of rules satisfy everyone's requirements?  Note that these
rules do not require any notification from the receiver to the sender to
work, but does require that any SAs that do not have the "cannot use anti-
replay with this SA" flag set are restricted to sending no more than
2**32 - 1 packets before "rekeying".

	When we say "rekey" do we mean that a SA with a new SPI is
	created?  To make rollover work, it seems like one would either
	need two SAs, with different SPIs, or else a single SA with two
	keys and an anti-replay counter associated with each key.
	Is this an implementor's choice, or does the architecture doc
	need to mandate which way must be implemented?

Any comments?
Charlie
Follow-Ups: