nanog mailing list archives
RE: TCP/BGP vulnerability - easier than you think
From: "David Luyer" <david () luyer net>
Date: Thu, 22 Apr 2004 10:06:15 +1000
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.
Current thread:
- Re: TCP/BGP vulnerability - easier than you think, (continued)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Daniel Roesen (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Daniel Roesen (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Daniel Roesen (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Paul Jakma (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Paul Jakma (Apr 21)
- RE: TCP/BGP vulnerability - easier than you think David Luyer (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Crist Clark (Apr 22)
- Re: TCP/BGP vulnerability - easier than you think John Kristoff (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think E.B. Dreger (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 22)
- Re: TCP/BGP vulnerability - easier than you think Paul Jakma (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think E.B. Dreger (Apr 21)
- Message not available
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 23)
- Message not available
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Leo Bicknell (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Petri Helenius (Apr 23)