BGP Session Hardening: GTSM, MD5 and TCP-AO

A BGP session is a TCP connection to port 179 that, if hijacked or spoofed, can blackhole or divert a large part of your traffic. Three mechanisms reduce that risk and they are cheap: TTL security (GTSM) makes off-path spoofing impractical, MD5 authentication proves the peer knows a shared secret, and TCP-AO (RFC 5925) replaces MD5 with modern MAC algorithms and key rotation. This article covers all three, in the order you should deploy them.

TTL Security (GTSM, RFC 5082)

GTSM requires packets to arrive with a TTL at least equal to 255 minus the configured hop count. A directly connected eBGP peer must arrive with TTL 255, and an off-path attacker has no way to guess the initial TTL correctly on every packet. It costs one line per neighbour and stops most blind spoofing.

! IOS-XE / IOS-XR
router bgp 65000
 neighbor 192.0.2.1 ttl-security hops 1

# Junos
set protocols bgp group EBGP neighbor 192.0.2.1 ttl 255
set protocols bgp group EBGP multihop ttl 255

# Arista EOS
router bgp 65000
 neighbor 192.0.2.1 ttl maximum-hops 1

# FRR
router bgp 65000
 neighbor 192.0.2.1 ebgp-multihop 1
 neighbor 192.0.2.1 ttl-security hops 1

For multi-hop iBGP, use the real hop count rather than 1. If you change the session to multihop later, GTSM must be updated in the same commit, otherwise the session drops.

MD5 Authentication

! Cisco
router bgp 65000
 neighbor 192.0.2.1 password 7 Sup3rSecret

! Juniper Junos
set protocols bgp group EBGP neighbor 192.0.2.1 authentication-key Sup3rSecret

! FRR
router bgp 65000
 neighbor 192.0.2.1 password Sup3rSecret

MD5 (RFC 2385) still works everywhere and stops accidental session formation, but it is weak against an attacker who can capture traffic, and most implementations only support one key at a time, which makes rotation disruptive: you must change both ends in the same maintenance window. Treat it as a stopgap.

TCP-AO (RFC 5925)

• Supports multiple simultaneous keys with a key identifier, so you can add the new key, roll traffic onto it, then remove the old one.
• Uses modern MACs (HMAC-SHA-1/256) instead of MD5.
• Protects against TCP segment replay and off-path injection, not just payload forgery.

! IOS-XR conceptual shape: define a key chain, attach to the neighbour
key chain BGP-AO
 key 1
  cryptographic-algorithm hmac-sha-256
  key-string clear Sup3rSecret
!
router bgp 65000
 neighbor 192.0.2.1
  ao keychain BGP-AO include-tcp-options

! Verification
show bgp neighbor 192.0.2.1 | include Authentication
show key chain BGP-AO

Not every platform or version supports TCP-AO yet, and interoperability between vendors is the practical blocker. Check both ends before planning a migration, and use a lab to prove the exact key identifier and MAC negotiation.

Deployment Order and Verification

• Enable GTSM first - lowest risk, no shared secret distribution.
• Add MD5 only if a compliance requirement demands authentication now, and log the requirement to remove it.
• Where both ends support TCP-AO, migrate to it and decommission MD5.
• Filter BGP peers with an ACL or prefix list as a fourth layer: only allow TCP 179 from expected addresses to the router's own address.

show ip bgp summary | include 192.0.2.1
show ip bgp neighbors 192.0.2.1 | include TTL
show bgp neighbor 192.0.2.1 | include Authentication
! failure symptoms
! GTSM mismatch -> session flaps every hold time, TTL errors in logs
! MD5 mismatch -> OpenSent/Active churn, no ESTABLISHED
! key rollover at different times -> session down for one key lifetime

Related: BGP neighbor flapping root causes for what a churning session looks like from the control plane, EOS BGP peering security best practices for a vendor-side hardening checklist, and BGP communities and AS-path filtering for the policy layer that catches what authentication cannot.

原文链接：RFC 5082 (GTSM) ｜ RFC 5925 (TCP-AO)