Protecting Your Network Edge with TTL Security

If a Bad Guy launches an attack against a routing protocol in your network, the attack is almost certainly going to be against EBGP. After all, that’s the protocol that’s running at the edge of your network, and therefore the protocol that is most readily accessible to an attacker.

This is why, as I wrote a few posts ago, it’s essential that you authenticate every EBGP session, and use a separate password for every neighbor. But while authentication can prevent an attacker from connecting to your BGP port (TCP port 179), there are other approaches he can take: By flooding packets at the BGP port, causing a tremendous number of authentication failures over a short period of time, the attacker can cause your router’s CPU to spike; this can cause the legitimate BGP connection at the target interface to fail, or can cause the entire BGP process to fail, or can even cause a complete system crash.  

There’s a TTL hack you can use, based on the Generalized TTL Security Mechanism (GTSM, RFC 3682), to reduce your vulnerability to such DoS attacks against BGP. To understand the hack, you have to first understand the default behavior of most BGP implementations. BGP sends packets to external neighbors with a TTL of 1 and accepts packets from external neighbors with a TTL of 0 or higher (as measured after the local router has decremented the TTL of the incoming packet). The TTL of 1 in originated packets insures that your router cannot establish an EBGP session with a neighbor that is not directly connected.

But because your BGP process by default accepts packets with a TTL of 0 or higher, packets can be sent to it from many router hops away as long as their TTL is set high enough when originated.

The TTL hack changes this default behavior by having BGP originate packets with a TTL of 255 and accepting packets only with a TTL of 254 or higher. Again, the TTL value of 254 is measured after the local router has decremented the TTL of the received packet.

Now, even if an attacker originates packets with a maximum TTL of 255 the packets cannot get to your BGP if the attacker is not directly connected; a single router hop decrements the TTL of his packets to 254, and when the packets hit your router the TTL is decremented to 253, below the acceptable value, and are quietly discarded (that is, dropped without generating an ICMP error message).

You can configure this TTL hack in Cisco’s IOS with a simple configuration statement: neighbor neighbor-address ttl-security hops 254. The one statement causes both the quiet discard of incoming BGP packets with TTL values below 254 and the setting of the TTL value of outgoing packets to 255. Of course, if you require a received TTL value of 254 or higher you’ve got to be sure your neighbor is sending packets with a TTL of 255; so the configuration statement must be used on both neighbors.