Monday, July 14, 2008

BGP - TTL security

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.


On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor ttl-security hops 5

After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 4/0 (hold time expired) 0 bytes

The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor Up

In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor ebgp-multihop 251
R5(config-router)#neighbor ttl-security hops 5

After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor Up

You can verify like this:

R6#show ip bgp neighbors | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255

I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.


  1. First, "R5 -router)# ... ebgp-multihop 250" didn't work because the packet TTL is decremented at EACH hop, so even if R6 was as little as 1 hop away, BGP packets would arrive at R6 with TTL 249. Invoking "ttl-security 5" at R6 insists that TTL be no smaller than (255-5) or 250, so the arriving packet fails this test and is discarded.

    Also, the parameter for "ttl-security" is the maximum number of hops between peers, for all possible routes (in case there's path redundancy), so if R5 and R6 are known to be directly-connected, "ttl-security 1" should be used (not 5).

    Regardless, configuring "ebgp-multihop x" where x is a large number like 250 or 251, etc, is a BAD idea as it subverts the whole reason for deploying "ttl-security" at all.

    These 3 scenarios are ALL you could possibly have:

    Case 1: If you're not concerned about security, and R5 and R6 are co-reachable via a single directly connected path, neither "ebgp-multihop" nor "ttl-security" are required at either router.

    Case 2: If you're not concerned about security, and R5 and R6 are co-reachable via multiple paths, the longest of which is n hops, then configure "ebgp-multihop n" at both ends.

    Case 3: If you ARE concerned about security, and R5 and R6 are co-reachable via any number of paths, the longest of which is m hops, then configure "ttl-security m" at both ends. Of course, m=1 if R5 and R6 are ONLY directly connected.

    David :)

    P.S. For more discussion, email me at:
    David -dot- Bray "at" algonquincollege -dot- com

  2. Great explanation and summary. Thanks!

  3. ref


Note: Only a member of this blog may post a comment.