[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A pothole in ISAKMP/Oakley
> Maybe we are talking about different attacks. The requirement for AH
> and ESP SPI generation was there before there was key management. We
> should ask why. I'd guess that the worry has been that an attacker
> could predict the SPI sequence and insert bogus messages with valid
> SPI's into the traffic stream, forcing the recipient to go through at
> least the trouble of checking the hash if not also decrypting.
I'll re-state that to clarify my view of the benefit:
Random SPI's serve a similar function as cookies: they make it harder
to do an off-path active attack against someone not in the
communication path between the peers.
Given that certain off-path active attacks (e.g., SYN floods) are
known to be in the bag of tricks in the cracker community, I think
resistance to such threats should be considered fairly important.
An ESP/AH implementation which does sequential SPI generation is
asking for trouble. It's probably OK to kludge it while you're coming
up to speed, but it should take all of a dozen lines of code in an
implementation to do random SPI generation.
(BTW, I hope the implementations doing sequential assignment are doing
collision checks against manually-configured SPI's while they're at
it..).
- Bill
References: