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:
Networking, Cloud, and Cybersecurity Solutions - Cisco
This one seems much worse than the TCP RST problem.
Relatively easy to filter though.
Michel.
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
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