North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: TCP/BGP vulnerability - easier than you think
On 2004-04-21-10:35:27, Michel Py <[email protected]> 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
|