tcp md5 bgp attacks?

Wed Aug 15 01:42:23 UTC 2018

On 8/14/18 2:38 PM, Randy Bush wrote:
> so we started to wonder if, since we started protecting our bgp
> sessions with md5 (in the 1990s), are there still folk trying to
> attack?
To recap for the purpose of my own edification and because hopefully
someone will relieve me of my assumptions.

The purpose of  of rfc 2385 tcp md5 digests is to keep in-window, tcp
segments that are spoofed from being ingested into the tcp stack. At the
time of it's writing (1998) some popular network operating systems did
not check  that the sequence number was in fact inside the window (so
that any tcp packet matching the 4 tupple would be ingested whether it
was in-window or not. Variously this improvement was supplemented with
the checking the TTL (https://tools.ietf.org/html/draft-gill-btsh-02),
checking whether the packet is actually in window, by ACLs that would
limit the impacts of  spoofing from off path attackers (you can't target
my multihop infracture sessions from outside my network for example),
and by filters that would limit the sort of thing you could inject into
bgp (rendering prefix hijacking moot) ).  I see broad evidence that MD5
values are extensively shared between sessions and effectively never
rekeyed (including cases where I've changed employers and the same asn
is using the same values for new peers). given the existance of
effective mitigations for the ibgp case, I've need seen a reason  to
employ it internally or to explore support for rfc 4808 mechnisms since
key rolling is effectively an external coordination problem.

Due to window checking and the ttl hack, the best vantage point for
launching an attack against a single hop ebgp sessions is as an on path
attacker (such that you would be able to identify source port and
window), layer-2 exchanges which flood unicast traffic (a hub I guess or
any public exchange with broken mac learning) would seem particularly
vulnerable since there are many on path neighbors. That is no longer a
normal topology. :/
> we were unable to find bgp mib counters.  there are igp interface
> counters, but that was not our immediate interest.  we did find
> that md5 failures are logged.
I can't quite get there either.

md5 failures I see quite a lot of, as peers that formerly have it
configured fail either temporarily or over longer timescales. md5
failures for unestablished connections aren't very interesting in this
case.

I have thousands of establish connections that last a very long time at
public exchange points, so the threat of tcp rsts to sessions is clearly
not being realized.
>
> looking at my logs for a few years, i find essentially nothing;
> two 'attackers,' one my own ibgp peer, and one that noted evildoer
> rob thomas, bgprs01.ord08.cymru.com.
>
> we would be interested in data from others.
>
> note that we are neither contemplating nor suggesting removing md5
> from [y]our bgp sessions.
>
> randy
>