[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
David,
>Dan Harkins wrote:
> >David Wagner wrote:
> >> 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.
>
>No, you missed the the point of my proposal. My proposal eliminates
>the need for the sender's nodes to be in sync.
>
>Imagine you have two nodes at the sender. The first node transmits
>packets with sequence numbers 0,1,2,3,...; the second uses
>2^31,2^31+1,2^31+2,...; so they don't need to be in sync. Today's
>receivers wouldn't be happy to see this, because they have only a
>single replay window. But, if we introduce two replay windows at
>the receiver, everything will be fine. The first window will be a
>32-bit bitmap of all sequence numbers seen in the range 0..31; the
>second will cover 2^31..2^31+31; and of course each window range
>will shift appropriately as packets are received.
This would work, but it violates the current specs in several ways.
We now require for the sender to increment the sequence counter by
exactly 1 for each transmitted packet. These packets could be emitted
out of order and thus a black box view of the IPsec implementation
would suggest an error. Also, as you note, the receiver has to
maintain more complex windows, which is not exactly a spec violation,
but certainly is a change. I agree with Dan that one would want to
negotiate anything like this, first, to make sure the receiver could
accommodate it, just like my proposal for extending the sequence
number space. I'm not necessarily enthusiastic about folks turning
off anti-replay, but if we did have to do that, I would want to do it
the way Dan suggested, i.e., default is that the sender generates
sequence numbers and assume the receiver checks them, and one has to
negotiate with the receiver to not generate sequence numbers.
>This proposal has several nice features. First, the security properties
>of today's IPSEC are preserved. Second, parallelization incurs no overhead
>at the sender. Third, there's not much burden on the receiver: receivers
>could start with just one replay window per SA, and introduce extra replay
>windows only as needed (up to some reasonable limit).
>
>By the way, Sommerfeld's suggestion of generating N SA's for N degrees of
>parallelism sounds even better -- it requires no changes to the standard
>whatsoever. I had thought that, for some reason, you wanted to keep all
>the traffic on the same SA, but if you're happy with with Sommerfeld's
>solution, so much the better!
I'm happy with that too.
Steve
References: