BGP MD5 at IXP

Sat Mar 10 11:24:35 UTC 2012

Andy Davidson <andy at 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 http://tools.ietf.org/html/rfc6528 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