[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
On 25 Jan 2001 08:50:29 GMT you wrote
> Dan Harkins wrote:
> >Of course. The single 32-bit add is noise. But keeping that counter in
> >sync is not.
>
> How about the following alternate proposal? Does it satisfy your needs?
>
> The suggestion is to have receivers be more sophisticated about managing
> their replay windows. Rather than keeping a single, 32-bit window for
> 32 consecutive sequence numbers, how about keeping N independent
> (appropriately spaced out) replay windows, where N counts the degree of
> parallelism you want at the sender?
The problem I'm (having trouble) describing is on the sender side. The
sender must keep its counter in sync among all the active nodes to whom
the work load can be dynamically load-balanced or actively failed-over.
A node to whom a workload has just been reassigned has to have fairly
accurate knowledge of the counter so it can do that very simple and
inexpensive 32bit add (new sequence number = X + 1 but what is X?).
Making sure that knowledge is there becomes increasingly expensive at
higher throughputs.
> What I like about this approach is that it doesn't introduce any risk
> of replay attacks. And, since the original proposal (make replay detection
> optional & negotiable) already requires changed to both endpoints, this
> approach is not really any worse in that respect.
Replay detection is already optional for the receiver and there is a way
for the receiver to notify the sender that anti-replay has been disabled
but regardless the sender must continue to increment the counter. And
that (the sender side) is where the problem lies.
> But I probably didn't quite understand your requirements. Will this work?
I actually think Bill Sommerfeld's suggestion to negotiate multiple
equivalent SAs (N SAs for N degrees of parallelism) is better. The trouble
of parallelizing the processing is taken out of IPsec and left in the
loadbalanceing code. That's seems cleaner and doesn't require changing
anything: the receive window and receiver processing is as it was, the
sender just does his simple 32bit add for the SA he owns, and IKE can
already negotiate N SAs for a particular flow.
I'll shelve my proposal for now. Thanks,
Dan.
Follow-Ups:
References: