[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: monitoring anti-replay detection in AH and ESP
> -----Original Message-----
> From: John Shriver [mailto:jas@shiva.com]
> Sent: 05 October 1999 15:09
> To: ipsec@lists.tislabs.com
> Subject: monitoring anti-replay detection in AH and ESP
> 3. Unused sequence numbers removed from window.
>
> This is essentially a count of the number of 0 (not seen) bits that
> you shift out of the bitmask when event 1 (above) happens. (Well, it
> also would increment if you shifted out a 0 on a normal "next
> expected" receive.) These are most likely lost packets, although
> there is a possibility that it is caused by large-scale reordering.
>
> This is the hardest one to implement. But it really is the best count
> of lost packets. Event 1 is quite shared between lost and reordering.
>
> The value of this counter goes up the longer the receive window for
> anti-replay is. (We'll also put the receive window in the MIB, to
> allow properly scaled interpretation of these.)
>
> This counter also helps you know if a high count of replay errors
> really represents an attack, or just high reordering that needs a
> larger window.
I'd have thought this counter would go up more slowly the longer the receive
window, theoretically at least. The longer the receive window is the less
chance there is of a reordered packet being recorded as a lost packet (and
hence as replayed out of window).
OTOH, I don't think it's so hard to implement in software at least. The
counter needs to be checked whenever the replay window is advanced. The
receive window may need to be 'pre-charged' with ones to prevent spurious
dropped packets being reported immediately after the SA is created. There
is also a need to cope with the special case of a loss of a large block of
packets.
Large quantities of duplicate packets don't necessarily mean an attack - it
may be an (un)intentional result of network routing.
Chris