[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
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 always
>> > 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.
>
>> 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.)
Follow-Ups: