How critical is BGP MD5 at Internet Exchange Points? Would lack of
support for MD5 authentication on route servers prevent some peers
from multilaterally connecting? Do most exchange operators support it?
Thanks!
Jay
<http://mailman.nanog.org/pipermail/nanog/2012-January/thread.html>
Search for MD5.
Most IXP route servers support it, few require it. So even if you do it on your side, doesn't mean someone else did it on their side.
I've never seen anyone refuse to connect to an IXP route server that did not, but that doesn't mean it hasn't happened.
At LONAP in London, the route-servers do not support TCP MD5 authentication for BGP. i don't think that this policy has led to anyone refusing to connect (about 80 of the 110 or so peers connected to the exchange use the Multilateral service - it is optional to connect to the MLP). We have no plans to enable TCP MD5 on this service.
Because TCP MD5 packets touch a router's CPU, using MD5 introduces a new attack vector - see nanogii passim (e.g. http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf). Don't do it. 
Andy
Andy Davidson <andy@nosignal.org> writes:
Because TCP MD5 packets touch a router's CPU, using MD5 introduces a
new attack vector - see nanogii passim
(e.g. http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf).
Don't do it.
Tom's slide deck is often misinterpreted - the salient parts are on pages 13 and 16.
The big problem is that random packets can hit the control plane - AT
ALL. One can kill it just as easily with a synflood on some other tcp
port (perhaps ssh or even one that it isn't listening on?). Hopefully
your modern exchange point router has some sort of control plane
policing. Indeed, hopefully your backbone routers have some sort of
control plane policing mechanism and you have turned it on and
subjected your policy to some scrutiny.
Blowing up un-password-protected BGP sessions by spoofing has not
turned out to be a big problem in recent years. It probably helps
that the dangers of highly predictable ISNs have become well-known
(and hopefully acted upon by router vendors but history has shown that
making blanket statements about that sort of thing on NANOG is
unwise). A read of RFC 6528 - Defending against Sequence Number Attacks may prove
instructional.
Turning on or off md5 makes minimal difference in CPU loading either
during an attack or not, but it is another thing to get wrong -
operational complexity without significant reward.
I agree with Andy's conclusion. Don't do it unless whoever you're
peering with demands it. It's not worth the complexity to set it up
in the first place, and it's not worth your time to argue against it
if someone is quite convinced that enabling md5 on your bgp session
will save the world.
-r
Hopefully your modern exchange point router has some sort of control
plane policing.
My gut feeling is that lots don't.
The behaviour of various operating systems regarding MD5 processing is
interesting. *BSD (and I assume consequently junos) checks ttl and
sequence numbers before checking md5. Linux and IOS do md5 first, and I
just wonder about the wisdom of this approach due to the slightly higher
computational overhead of calculating the hash.
In general, I'm slightly in favour of md5 at ixps, not because of session
security, but when exchange participants leave an ixp, lots of people don't
bother to remove the bgp sessions. If as a newcomer to the IXP you get a
re-used ip address, without md5 it can sometimes be possible to do
Interesting and Bad Things with old sessions from other ixp participants.
FWIW, for the INEX route server system we:
- use bsd
- implement packet filtering to accept tcp/bgp only from the ixp subnet
- generally use md5 for ipv4 sessions
- generally don't use md5 for ipv6 sessions for historical reasons
This works for us.
I agree with Andy's conclusion. Don't do it unless whoever you're
peering with demands it. It's not worth the complexity to set it up
in the first place, and it's not worth your time to argue against it
if someone is quite convinced that enabling md5 on your bgp session
will save the world.
yep, agreed. Doesn't make that much difference in real life so don't lose
sleep about it. The only real difference it makes is that it can help shut
up "security" audit people (the tick-box compliance variety) from their
ivory tower whining.
Nick