RE: TCP/BGP vulnerability - easier than you think
Adam Rothschild wrote: Which begs the question, what is one to do, shy of moving (private) peering/transit/customer /31's and /30's into non-routable IP space, which opens up an entirely new can of worms?
Insist that the peer uses "ip verify unicast reverse-path" on all interfaces, or similar command for other vendors.
Fact of the matter is, MD5 computation/verification is not cheap, and many Cisco and Juniper platforms aren't designed to handle a barrage of MD5-hashed TCP packets. All things considered, I think MD5 authentication will lower the bar for attackers, not raise it. I'm sure code optimizations could fix things to some degree, but that's just not the case today.
Certainly the best reason not to MD5 I have heard so far.
Mikael Abrahamsson wrote: http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml This one seems much worse than the TCP RST problem.
Relatively easy to filter though. Michel.
On 2004-04-21-10:35:27, Michel Py <michel@arneill-py.sacramento.ca.us> quoted me out of order as saying:
Which begs the question, what is one to do, shy of moving (private) peering/transit/customer /31's and /30's into non-routable IP space, which opens up an entirely new can of worms?
Insist that the peer uses "ip verify unicast reverse-path" on all interfaces, or similar command for other vendors.
Not a bad idea in general, where practical, but not necessarily a fix for the problem at hand. We tested hitting a Cisco box w/ ebgp-multihop configured with MD5/BGP packets sourced from a random host not configured as a peer, and the results weren't exactly pretty. I consider this test to be of at least some real-world relevance, as there are transit providers who will put customers on one L3 customer-attach device, and have them multihop-peer with another router further upstream. Of course, only allowing tcp/179 from configured peers is a good idea. But unless you've got something that allows you to easily filter traffic to a router's interface IP's, such as Juniper with loopback filtering, or Cisco 7500/12000 with receive path ACL's, or you have an army of tools developers on salary, maintaining the requisite access-lists can be an administrative burden. (IMO, Cisco implementing rACL-like functionality on lesser routers would be a step in the right direction. But I've been of this opinion for a while now, long before this particular vulnerability came to light...) -a
On Wed, 21 Apr 2004 07:35:27 -0700, "Michel Py" <michel@arneill-py.sacramento.ca.us> said: Insist that the peer uses "ip verify unicast reverse-path" on all interfaces, or similar command for other vendors.
I sure hope there are no asymmetric paths on the Internet that will bite you when you turn on strict RPF on your peering interfaces </sarcasm> Seriously, if you do turn RPF on on peering interfaces, please let your peers know (plea from circa 1999) Aditya
participants (3)
-
Adam Rothschild -
Aditya -
Michel Py