BGP TTL "hack" (posted 2004-04-08)

At the NANOG 26 meeting in october 2002, Dave Meyer presented a very simple proposal to protect BGP sessions against attacks: set the TTL to 255 on outgoing packets, and check whether the TTL in received packets is equal to 255. Since routers always lower the Time To Live (or Hop Limit in IPv6) when forwarding a packet, and routers discard packets with a TTL of 0, there is no way for anyone who isn't attached to the subnet in question to inject packets with a TTL of 255 into a subnet. RFC3682 was published in february and describes the details of the "Generalized TTL Security Mechanism (GTSM)".

Cisco has now included GTSM into IOS release 12.3(7)T, as explained in the feature guide. It seems there are some interesting caveats. First of all, Cisco states that enabling the feature using the neighbor ... ttl-security command will only enable the check for incoming packets and not change any behavior as to outgoing packets. So this must mean they always use a TTL of 255 for outgoing packets now. However, older IOS versions set the TTL for BGP packets to 1 (in the absence of any ebgp-multihop settings). If this is the case, then detecting whether a neighbor is directly connected won't be very reliable right now. Then again, Cisco says the feature must be configured on both ends of an eBGP session (no support for iBGP as of yet) which seems to contradict this.

Another thing is that they look for a TTL of 254 or higher. This suggests that for incoming packets with a TTL of 255, they first decrease the TTL and then go on to process the TCP segment. Again, this is not how things work in older IOS versions, as it's perfectly possible to set the TTL to 0 and still interact with a Cisco router on the local subnet. So unless something changed in this regard as well, accepting a TTL of 254 means that there can still be a router in between!

Note that this mechanism only offers protection against attacks on port 179 of a router from "far away". Anyone on the local subnets still gets to do whatever they please and the content of the BGP sessions isn't protected any better than before.