[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
On Tue, 23 Jan 2001 19:29:44 EST you wrote
> In message <200101240014.QAA19763@potassium.network-alchemy.com>, Dan Harkins
> w
> rites:
>
> >>
> >> 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.
>
> Right -- but a single 32-bit add is going to be much faster than any of
> the crypto, no matter what.
Of course. The single 32-bit add is noise. But keeping that counter in
sync is not.
> >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.
> >
> But you can send state updates rather infrequently; the bound is the
> window in which you're willing to accept the attack I outline below.
> (There's always some risk. For example, the enemy could divert *all*
> packets from an SA, and replay the stream in its entirely later.) I'm
> not convinced that this is a pressing enough need to warrant
> complicating everyone else's stacks.
If you send them infrequently then you have to "guess" what the new node
who has gotten the failed-over workload should use as a sequence number
for packets it starts sending. It's hard to know how many packets have
been sent by the now-failed node since the last update unless the updates
are relatively frequent. One can make the guess absurdly high but absurdly
high on one link is absurdly low on another. And regardless of the media
it's really the pps that is the governing factor. It's possible to use
an adaptive update heuristic but now the complexity of just doing that
single 32-bit add is pretty big. If the possibility of the attack you
described is remote enough then I think the point of diminishing returns
has been reached.
Dan.
Follow-Ups:
References: