Securing BGP Lab: GTSM

Introduction

This lab is focused on taking our existing infrastructure and implementing some of the BGP Best Practices to secure the configuration on the router, as covered in the BGP BCP presentation earlier.

The lab work looks at 4 essential configuration features necessary to secure BGP operations on a router:

1. Limiting the maximum AS-PATH length for received prefixes

2. Protecting the EBGP Peerings from receiving more than the expected number of prefixes

3. Generalised TTL Security Mechanism - how to prevent remote attackers from disrupting EBGP sessions

4. Preventing the propagation of private AS numbers to the Internet

Lab Topology

The diagram below is a reminder of the lab topology:

Lab 3: Generalised TTL Security Mechanism (GTSM)

The next exercise is looking at a technique for protecting BGP sessions between routers from being attacked by a third party. This protection is in addition to using a password on the EBGP session, as we configured during the setup stages of this workshop.

Background

An EBGP session between two directly connected peers means a TTL hop count of 1 is set on the originating router, with the destination router expecting the packet to arrive with TTL of 0. However, an attacker elsewhere on the Internet can also send a packet which will arrive with TTL of 0, and potential disrupt the BGP session between the two peers.

GTSM works by setting TTLs between EBGP speakers to be 255, as described in the BGP Best Practices presentation. This way, a third party can only be at least one more hop away; it cannot send a BGP packet with TTL which the local peer router would be able to use, because the TTL would be incorrect. If they tried to send a packet with TTL 255, and they were one hop beyond the source router, the packet would arrive on the destination router with a TTL of 253, two hops away, an incorrect value and therefore ignored. (In fact, the attacker would have to be on the same physical media used between the two peers meaning that, in the case of an IXP, they’d have to be on the IXP LAN itself - not entirely impossible!)

Some operators require GTSM on any EBGP session they set up - so the purpose of this exercise is to show how it is done. Both operators need to implement GTSM on the peering link, which means coordination is required.

Exercise

We are now going to implement GTSM on the EBGP session with the upstream provider, and on the private peering link between the adjacent groups. We won’t implement it with the IXP peers.

For the upstream provider, coordinate with the lab instructors regarding enabling GTSM on the IPv4 and IPv6 EBGP peerings with the transit router.

Here is an example for the Border Router, peering with the upstream provider:

router bgp X0
!
 address-family ipv4
  neighbor <ipv4-ptp> ttl-security hops 1
!
 address-family ipv6
  neighbor <ipv6-ptp> ttl-security hops 1
!

Likewise, when you are ready to set up with your private peer, coordinate with them, so you can implement the GTSM configuration at the same time on both ends of the session. The configuration needed on the Peering Router has the same construction as in the example above.

Testing

Once you have configured GTSM on these two peerings, it is time to do some testing. What does the command:

show ip bgp neigh <ipv4-ptp>

on the border router show you now?

Verify that you see, in the detailed output from the command, something like this¹:

Mininum incoming TTL 254, Outgoing TTL 255
Local host: 100.121.0.1, Local port: 41103
Foreign host: 100.121.0.2, Foreign port: 179 

The lab instructors already use GTSM between the two Transit Routers, and the output above is from the BGP session between the two. Your’s should look very similar.

Also verify you see the same on the EBGP session with your private peer.

GTSM is now configured and operational.

Note: Cisco IOS uses hops 1 in its configuration construct - this may be counterintuitive given we are setting TTL to 255, but it seems the Cisco developers are focusing on describing what is actually allowed. Other vendor implementations have configuration letting operators set the TTL value - care is needed here!

Conclusion

This lab has shown how to implement GTSM on EBGP peerings. Its use needs to be considered in the general context of securing EBGP peerings, and some operators will not peer with other networks without this feature being configured.