Sunday 17 May 2015

BGP TTL security

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.
ttl-security1.png
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.
ttl-security2.png
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.