My new BGP book: 'Internet Routing with BGP' by Iljitsch van Beijnum BGPexpert My BGP book from 2002: 'BGP' by Iljitsch van Beijnum

Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My New BGP Book

BGP (advertisement)
Update - BGP/TCP countermeasures (posted 2004-04-21)

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?

  1. 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.

  2. 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.

  3. 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:

    !
    interface gigabit3/0
     hold-queue 2048 in
    !
    router bgp 12345
     timers bgp 1 180
    !
    
  4. 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.

  5. 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.)