Configure BGP TTL Security

BGP TTL Security feature

Default behaviour of BGP clients is to send an BGP update messages to peer with a TTL value of 1. There are a ways to remedy this configuration with neighbor statements but we are interested in security in this blog.

This small scenario of couple of eBGP peers will let us demonstrate this security feature.

If we send an BGP update with a TTL value of 1 , this mean that the router needs to be connected directly to the peer it is homing with. It is very easy for an attacker that is simulating a SYN packet on the TCP port 179 where a BGP speaker is listening, to change the TTL value of the SYN requests. Many of these packets could bring down the peering and migitiate a serious DOS attack. This could cause harm on a production enviroment. 

We could prevent this , by configuring (we must do this on both sides) a TTL security hop count for the eBGP neighbors. This way it is very hard for an attacker to simulate a correct TTL value we have assigned to the neighbor statements.

Let us try the configuration scripts:

ISP1(config-router)#neighbor 192.168.1.2 ttl-security hops 1

And if we do and clear ip bgp * we can see in the output that we have no peering yet.

ISP1#sh ip bgp summary

BGP router identifier 1.1.1.1, local AS number 500

BGP table version is 2, main routing table version 2

2 network entries using 234 bytes of memory

2 path entries using 104 bytes of memory

6/1 BGP path/bestpath attribute entries using 744 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 1130 total bytes of memory

BGP activity 17/15 prefixes, 20/18 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

172.16.1.2      4   500     256     265        2    0    0 00:00:36        2

192.168.1.2     4     1     479     495        0    0    0 00:00:37 OpenSent

Now let us do it on the other side for the customer router. We can see that the hold down period has expired. 

*Mar  1 04:08:10.142: %BGP-3-NOTIFICATION: sent to neighbor 192.168.1.1 4/0 (hold time expired) 0 bytes

So we must put in the exact same TTL hops in the customer neighbor statement.

CUSTOMER(config-router)#neighbor 192.168.1.1 ttl-security hops 1

And after a couple of seconds we have our peering up and running.

*Mar  1 04:10:39.186: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up

So let us look a the final configs at the BGP processes. 

CUSTOMER#sh running-config | section bgp

router bgp 1

 no synchronization

 bgp router-id 10.10.10.10

 bgp log-neighbor-changes

 bgp scan-time 20

 network 50.50.50.0 mask 255.255.255.0

 network 100.100.100.0 mask 255.255.255.0

 redistribute connected

 neighbor 192.168.1.1 remote-as 500

 neighbor 192.168.1.1 ttl-security hops 1

 neighbor 192.168.1.1 timers 20 60

 neighbor 192.168.1.1 advertisement-interval 15

 no auto-summary

ISP1#sh running-config | section bgp

router bgp 500

 no synchronization

 bgp router-id 1.1.1.1

 bgp log-neighbor-changes

 network 1.1.1.1 mask 255.255.255.255

 neighbor 172.16.1.2 remote-as 500

 neighbor 172.16.1.2 next-hop-self

 neighbor 192.168.1.2 remote-as 1

 neighbor 192.168.1.2 ttl-security hops 1

 neighbor 192.168.1.2 soft-reconfiguration inbound

 no auto-summary

This feature is explained more on the RFC5082

Feel free to comment.