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