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

Re: Increased sequence number in ESP/AH



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.
>
>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.
>> 
>> 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.

Under certain circumstances, there's a simple but very devastating 
attack if there's no replay check:  the enemy waits till your process is
done, and then binds to the same port and replays the packets.  Why 
crack the crypto when the kernel will decrypt it for you?

		--Steve Bellovin, http://www.research.att.com/~smb




Follow-Ups: