On 21-apr-04, at 22:00, Paul Jakma wrote:
Why would MD5 be more of a crypto DoS risk with IPSec AH headers than with bgp tcp-md5?
Beats me. But why do you bring up IPsec?
The paragraph is quoted is your advice against using IPSec,
Unless I was really sleep-typing I didn't say anything about IPsec, just about "crypto", which as far as I'm concerned includes MD5, which we were talking about.
I dont see why an MD5 auth header IPSec protected sessions would have more risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The risk is due to MD5, not IPSec :).
As Crist Clark just pointed out: the presence of the SPI and replay counter actually makes it harder to do a crypto DoS against IPsec than the TCP MD5 option (assuming the traffic can't be sniffed). Makes you wonder if those TDM guys weren't on to something with out of band signalling, doesn't it?
Anyway, what needs to happen is a form of crypto where the expensive algorithms are only executed for good packets and not for all packets.
So configure ipsec to authenticate packets between the peers allowing only md5 or somesuch. I dont know about other IOS, but other implementations do allow one to specify security associations on a per port basis.
Another advantage of IPsec is that it allows for key changes in a sane way. I'm not sure I'd want my routers to run IKE, though. However, note that even a relatively light-weight check such as an HMAC-MD5 can blow away a typical router CPU at orders of magnitude below line rate, so it is essential that attackers don't get to bypass the non-crypto checks for than a tiny fraction of the packets they spoof.