So now
we know (cache) why everyone has been scrabmling to implement MD5 auth on their bgp peers in the past weeks...
Now, TCP reset attacks aren't exactly a new game (see
here (cache) or even
here (cache)), but
Paul A. Watson (cache) presented why such an attack is feasible in real-world environments in his "Slipping in the Window: TCP Reset Attacks"
CanSecWest '04 paper.
Apparently he shows that for an RST (or SYN) attack on a TCP connection, you don't need to hit the exact current sequence number, but merely a range defined by the window size & window scale parameters of the connection.
If the TCP stack additionally has a weak ISN generation scheme and a predictable algorithm for the selection of ephemeral ports, there's obviously a real threat for any kind of long-living TCP connection. And then, Cisco seems to use an "insanely huge" window size.
There's also
this IETF draft (cache) with a description of the attack and possible defenses (didn't have the time to thoroughly read the text yet, though).
What makes this problem worse for BGP is the widely used practice of
flap dampening (cache), which can result in routes from your AS being not globally routed anymore after only a few successful RST attacks on the BGP connection, but other core network protocols using TCP connections are also affected. MD5 auth helps, but at the cost of additional CPU usage, which may open an additional resource starvation attack vector on the router, so filtering transit networks used for bgp peers is probably the cheaper defense.
Another potential victim are VPN connections using TCP connections, as for example with
OpenVPN or IPSEC over TCP for NAT traversal (or ssh sessions). There will shurely be a few more papers on this in the coming months...
;){kind=link}