[69904] in North American Network Operators' Group
Re: TCP/BGP vulnerability - easier than you think
daemon@ATHENA.MIT.EDU (Adam Rothschild)
Wed Apr 21 11:16:37 2004
Date: Wed, 21 Apr 2004 11:13:26 -0400
From: Adam Rothschild <asr+nanog@latency.net>
To: Michel Py <michel@arneill-py.sacramento.ca.us>
Cc: nanog@merit.edu
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B0DB0BB@server2003.arneill-py.sacramento.ca.us>
Errors-To: owner-nanog-outgoing@merit.edu
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
