Understanding BGP TTL Security
By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) Sending BGP messages with a TTL of one requires that the peer be directly connected, or the packets will expire in transit. Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1 (or whatever value is specified by ebgp-multihop), which can help mitigate spoofing attacks.
However, there is an inherent vulnerability to this approach: it is trivial for a remote attacker to adjust the TTL of sent packets so that they appear to originating from a directly-connected peer.
By spoofing legitimate-looking packets toward a BGP router at high volume, a denial of service (DoS) attack may be accomplished.
A very simple solution to this, as discussed in RFC 5082, is to invert the direction in which the TTL is counted. The maximum value of the 8-bit TTL field in an IP packet is 255; instead of accepting only packets with a TTL set to 1, we can accept only packets with a TTL of 255 to ensure the originator really is exactly one hop away. This is accomplished on IOS with the TTL security feature, by appending ttl-security hops <count> to the BGP peer statement.
Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop count will be accepted. TTL security and EBGP multihop are mutually exclusive; ebgp-multihop is no longer needed when TTL security is in use.
About the Author
Jeremy Stretch is a freelance networking engineer, instructor, and the maintainer of PacketLife.net. He currently lives in Fairfax, Virginia, on the edge of the Washington, DC metro area. Although primarily an R&S guy, he likes to get into everything, and runs a free network training lab out of his basement for fun. You can contact him by email or follow him on Twitter.
Comments
I've got to give this a try
Its a shame this is a Cisco proprietary command since its such a wonderful security feature. And FYI For everyone, it does require IOS Version >= 12.3(7)T
In fact you should use ttl = 2 when your source of bgp update is a loopback interface.
It is a very nice explanation. I never understood the difference between ebgp-multihop and ttl-security featues...Thanks
I'd like to implement this today as well!
Should this "whatever value is specified by ebgp-multihop" read "whatever value is specified by ebgp-multihop or lower"?
Just to make sure I understand this... and I've never used or read about ttl security hop but understand and use ebgp-multihop.
Formula would be: TTL ≤ 255-h
h = actual hops
cool post, I didn't know what this feature is for. Simple and very nice explanation.
spot on, thanks for all this useful info that you give away with each of your posts.
you blog has really made me a better administrator.
thanks a ton!
As of 2007, there is new RFC 5082 describing the TTL-Security feature. The RFC You mentioned is obsolete although the idea stays the same. Just thought it would be a good idea to correct this because at the time you wrote the article, new RFC was already out ;)
Presumably this has to be configured on both peers to work, correct? Otherwise one side would still try to set the TTL to 1?
Why it would be more difficult for an attacker to craft a BGP packet to have 255 of ttl than to have a TTL of 1?
255 is the highest possible value for the TTL field, which is eight bits in length. It is illegal for a router to forward an IP packet to a new hop without decrementing the TTL value by one. Therefore, it can be deduced that any packet with a TTL of 255 was originated on the local segment.
Is there a debug cmd to verify the received TTL on a packet?
Nice tips !! Did not know that it was possible :)
thanks Jeremy