[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay window
Darrell.
As the initial proponet of including a window size negotiation, let
me explain the rationale behind the anti-replay technique in more detail.
First, it is not a requirement that an anti-replay implementation
accept packets only in order. In fact, I'd consider such an implementation
to be inapopropriate since it violates the normal IP layer assumptions
about ordering. The goal of anti-replay facilities in IPSEC is to detect
and reject duplicate packets and a windowing mechanism is included to
facilitate this task. Without a window at the receiver, and given the goal
of allowing out of order packet arrival, it is not generally feasible to
detect and reject replayed packets. So, the window is used to allow the
receiver to delcare some range of packets to be old enough to be rejected,
without needing to keep track of the packets actually received after some
point in time.
Window negotiation allows for two forms of flexibility. The
receiver can declare what window size it is willing to deal with, and the
transmitter can declare what size it thinks might be appropriate, based on
some knowledge of the type of traffic (e.g., on a per-association basis).
I don't know if this will really turn out to be needed in practice, but it
seems like an appropriate facility to include. I don't think leaving the
window size purely to the receiving implementation is a good idea. For one
thing, it makes it harder to test and determine if the system is working
properly.
Finally, just a nit about your closing comments. The sequence
number is not always encrypted, and it is not signed. Since ESP now offers
options for connectionless integrity, anti-replay features, data origin
authentication, and confidentiality options, one might not encrypt the
sequence numbers. The defined algorithms for connectionless integrity do
not currently include signature algorithms, only keyed hash algorithms.
Steve
Follow-Ups: