Update - BGP/TCP countermeasures
In an article in Wired
(Flaw Could Cripple Entire Net)
Paul Watson is said to claim that he can reset TCP sessions " with as few as four attempts". I have a hard time believing
this, but we'll have to see thursday, when all will be revealed. An attacker still needs to know the IP addresses for both
sides and the appropriate TTL (simple) and the port numbers used on both sides. The latter may or may not be trivial:
routers typically start using ephemeral ports at a fixed number after booting, so for the first few BGP sessions this should
be relatively easy to guess. However, a router that has been running for a while and has lots of BGP sessions (which is common
on internet exchanges), these port numbers are well randomized within the range used by the system, which is typically
at least 4000 ports.
So if Paul Watson is correct it may be possible to reset sessions with less than a hundred to a few thousand packets.
This takes only moments. If he isn't, but the
router has few BGP sessions, port numbers are easily guess-able and the default window size of a little less than 16k
makes it possible to reset sessions with about 250 thousand packets per port combination, which is in line with reports
that people were able to do this in the lab within about half an hour. This is short enough to incur flap dampening
difficulties if it happens repeatedly.
So what can we do?
Use the BGP TTL hack / GTSM. Attackers that are several hops away can't spoof a TTL of 255 or 254 so sessions
are protected without wasting much CPU time. However, GTSM isn't widely available yet.
Use the RFC 2385 BGP TCP MD5 option. This is widely (but not universally) implemented, and should work well
against this type of attack. Unfortunately, implementing MD5 passwords is a significant amount of work and in
many cases sessions break. Cisco routers don't reset the session when a password is applied in recent versions,
but older IOSes and many other vendors still do. And the change must happen on both ends at the same time
for sessions to remain up.
The MD5 option is also a double edged sword because it opens the door to CPU exhaustion based denial of
service attacks. In theory the crypto should only be done when the packet passes all regular TCP checks, but
in reality this isn't the case so making the CPU burn cycles on MD5 hashing should be easier to do for an
attacker than sending a successful RST. Based on the information I have right now, I believe the upsides of
having MD5 on peering sessions with relatively small peers over exchanges don't outweigh the downsides, as the
work and the MD5 DoS risks are the same for small peers, but the damage when a session breaks is fairly negligible.
For very large peers and especially transit connections, the situation is different: the instability caused by
session resets can be significant, so MD5 is a good idea here.
If a router actually starts receiving lots of spoofed RSTs, the input queues fill up and legitimate BGP packets
may be dropped. So it helps to increase the input queue, reset the BGP hold time to the default 180 seconds
(I normally advise lowering it to detect outages sooner), but lower the keepalive time to arrive
at a better real-to-spoofed BGP packet ratio. On a Cisco:
hold-queue 2048 in
router bgp 12345
timers bgp 1 180
Don't be part of the problem: make sure your customers can't pollute the net with packets with
spoofed source addresses. Use anti-spoofing filters or Unicast RPF (uRPF) for this.
Last but not least, you can filter out TCP RST packets to/from the BGP port (179). Filtering all RSTs is a very
bad idea as they are necessary to make sure that when two hosts are communicating, and one loses its state
(for instance, it reboots), the other doesn't keep sending traffic at high speed until eventually the TCP session
times out. However, for BGP this isn't much of an issue because TCP doesn't generate all that much traffic
and an expired hold time will take care of one-sided sessions soon enough.
Lines in a Cisco access list for filtering BGP TCP RSTs look like this:
access-list 123 deny tcp any any eq bgp rst log-input
access-list 123 deny tcp any eq bgp any rst log-input
(Note that some legitimate hits are possible if a BGP session is only configured on one router.)
These must be applied on input on interfaces that may received spoofed RSTs (i.e., external connections,
but also customer facing connections if those don't have proper anti-spoofing filters). The log-input
keyword makes sure the interface and sometimes the MAC address of the system that sent the offending packet are logged.
This is very useful on shared/switched media interfaces such as internet exchanges. Don't worry about
overwhelming the router with logging information too much, as this is rate limited. (However, having log-input
in place when a full-fledged DoS attack is in progress isn't advisable either.)
(See below (when reading this on the main page) or above (in the archives) for information about the MD5
and TTL protection mechanisms.)