[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: monitoring anti-replay detection in AH and ESP
Comments inline...
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: Tuesday, October 05, 1999 11:25 AM
> To: jas@shiva.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: monitoring anti-replay detection in AH and ESP
>
>
> I don't particularly like anything that adds overhead to the normal
> processing case. The things you propose partly can be done in the
> "error" path, but it seems to me you're adding at least a few
> instructions to the normal path. For example, the "unused sequence
> numbers removed from window" and "reordering within the window" cases
> seem to require that. It looks to me like your counters 1..3 are
> problematic for this reason, while counters 4 and 5 are ok.
>
Yes, they aren't free. On the other hand, the events that cause them
shouldn't be "first order" in terms of common-ness. (The exception is
shifting out one bit of 0.)
Perhaps we can put them in as optional? (Theoretically: let the market
decide?)
There certainly is always comparing the packet counters at the transmitting
and receiving SA's. But that assumes that you are granted SNMP access to
the sender's SA MIB entries. No assurance of that, you may only have access
to the reciever.
> Another small point:
>
> Many replays can be detected without doing packet authentication
> first. So the "replay in window" and "replay out of window" cases
> actually have three possible causes, not just two: duplication or
> major resequencing; replay; packet forgery. That last case can be
> distinguished by doing the integrity check, but doing that on a packet
> already known to be unacceptable would be a bit silly.
>
Yeah, that level of diagnosis is probably excessive. There are other tools
that come into play when forgery is detected...
> paul
>