[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay attacks
> I would think 16 bits would be insufficient. To avoid replay attacks,
> I would presume the sequence space should be large enough to handle
> the round-trip bandwidth-delay product for "worst case" delay and
> bandwidth.
16 bits is probably insufficient. (unless you plan to always rekey
after every 2^16 datagrams!)
Basing your sequence number space on bandwidth-delay products is
fine for protocols like TCP which ignore adversaries -- but the
IPSEC requirements are totally different.
With IPSEC, I don't see any way to safely reuse sequence numbers
unless you rekey. (If legitimate endpoints are reuseing sequence
numbers, then how will they tell if an adversary replays an old packet?)
Also, note that you don't need to keep *that* much state in the
receiving end if you assume that most IP datagrams don't get
reordered significantly. Keep a small amount of state recording
the last few sequence numbers received, and a low water mark;
when a datagram arrives with sequence number less than the low
water mark, drop it; whenever your state table fills up, throw
away the smallest few sequence numbers and bump up the low water
mark. This will drop a few valid datagrams, but presumably
they'll get retransmitted. (Just how *much* state you need is
a question for some measurement...)
References: