Paul Jakma wrote: > On Wed, 21 Apr 2004, Iljitsch van Beijnum wrote: > > > On 21-apr-04, at 21:17, Paul Jakma wrote: > > > > > > I'm not recommending this for "small" peers as the crypto DoS risk > > > > is worse than what happens when the attack is executed > > > > successfully. > > > > > 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, 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 :).
Seems like an easy question to me - with the MD5 auth header, you have the option of validating all the (plaintext, err, plainbinary?) header components (ips, ports, sequence, etc) before checking the MD5 sum. So if properly implemented, the MD5 overhead would only be incurred if the packet was already capable of corrupting the BGP session. When combined with the TTL sanity check (which has potential flaws around TTL misgeneration/miscalcalculation eg 255 vs 254, hops which don't decrement TTL eg some MPLS routers and a very small portion of IP switch-routers and cases which it can't be used such as iBGP and multihop eBGP) this would provide a very secure system, if the MD5 is done _after_ TTL, ip, ports, sequence, etc. With ipsec, you have crypto overhead before you have any opportunity to do the basic sanity check. > > 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. A static ACL would not be granular enough in specifying valid packets to prevent crypto being executed on spoofed packets in the ipsec case. David.
