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

Re: Increased sequence number in ESP/AH

On Tue, 23 Jan 2001 17:05:07 EST you wrote
> In message <200101232142.NAA19223@potassium.network-alchemy.com>, Dan Harkins
> w
> rites:
> >On Tue, 23 Jan 2001 15:17:43 EST you wrote
> >> >   While we're on the subject of sequence numbers and IKE negotiation
> >> > I'd like to make use of them negotiable. Right now the sender must alway
>s
> >> > send them even if the recipient is not using them. Parallelization of
> >> > IPsec processing is much easier if both sides can agree to forgo the
> >> > benefits of the anti-replay check.
> >> 
> >> If all you care about is performance, it's even faster if you leave
> >> out the crypto. :-)
> >
> >Yuck, yuck. Actually, no it's not; crypto is not the bottleneck. There
> >is a point of diminishing returns for complying with the anti-replay 
> >requirement.
> 
> For your application, what is the bottleneck?  We're talking about a
> single 32-bit addition, which I assume is quite fast. 

For now it's the 100Mb/s wire. Crypto will become the bottleneck again
with faster media though.

The problem is that the box provides 250ms active session failover from 
device to device and keeping the replay window in sync at very high 
bitrates gets to be expensive.

> >> If you want to avoid multiple crypto engines single-threading on the
> >> counter increment, negotiate multiple equivalent SA's and load-balance
> >> across the SA's..
> >
> >That's one way to do it. But if the recipient has already said she isn't
> >going to be inspecting the counter, for whatever reason, why mandate that 
> >the sender keep sending it? 
> 
> If you're going to have N encryptors, assign them each a separate
> counter starting at [0,N-1], with each incrementing by N instead
> of 1.  I would expect that most reasonable distributions of packet
> sizes would result in most packets not arriving too much out of
> sequence, and certainly well within the window.
> 
> Besides -- leaving out the replay counter is *dangerous*.  I'd really
> like to avoid reopening that can of worms.  (Folks may recall that I
> opposed the notion of making the check by the receiver optional.)

If it is possible to authenticate, decrypt and decapsulate packets faster 
than they can be delivered what is the danger in getting a packet which 
will either fail the authentication check or which had previously been 
delivered? Sorry, I don't recall your opposition.

  Dan.
References: