[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Increased sequence number in ESP/AH

Steve,

Is there a summary of your presentation you could post for those of us who 
were unable to attend the last meeting?

A couple of comments on replay and clustering.

I don't have any problem with 64-bit replay sequence numbers.  The math is 
lost in the noise and the additional sequence space will be needed very 
soon now.

Regarding clustered IPSec SA's, I like Bill's proposal, though I tend to 
want to try to solve the problem with a single SA (pair).  However, 
something like a simple negotiated replay window set is also problematic 
when you allow your clusters to dynamically resize (as we do).  You'd have 
to provide a mechanism to negotiate a new replay window when you added 
another node not present during the initial negotation.  The beauty of 
Bill's proposal is that this is just another Quick Mode.  However, this 
will cost us O(n) in IPSec SA memory usage, where 'n' is the size of a 
cluster, given our failover guarantees.  We currently achieve our 250ms 
failover in O(1) IPSec SA memory usage.  This isn't very appealing to us 
when you consider that we support 20K+ tunnels in our high end systems.  On 
the third hand (:-), it's just memory.

How about this:

	1) add a replay 'flow id' to the ESP header or trailer and include it in 
the integrity check
	2) require the receiver to support multiple replay windows, per SA, 
indexed by flow id
	3) require that the flow id be unique for the lifetime of the SA and 
forbid reuse of flow id's
	4) require the receiver to switch to a new replay window upon receipt of 
an unknown flow id

This allows the sender to start transmiting on a new replay window 
following load-balancing, failover,
or a cluster resizing/remastering.  With sufficient restrictions, there's 
no effective security risk.

I do think this is an important problem to solve.  Despite the advances in 
COTS hardware acceleration, the only way we're going to deal with increased 
pipe sizes in the near future is through parallelism/clustering.

Derrell

--On Friday, January 26, 2001 12:02 AM +0000 David Wagner 
<daw@mozart.cs.berkeley.edu> wrote:

 > 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!
Follow-Ups: References: