Production Deployment of TCP Authentication Option

TCP-AO, specified in RFC 5925, is a replacement for the MD5-based session authentication mechanism. While MD5 is available in most routing platforms, its use is inconsistent. MD5 was never widely accepted or deployed by network operators. In our experience, some networks required it (even on private, dedicated links), some refused to use it (even on shared, layer-2 internet exchange fabrics), and some would configure it if asked.

Both protocols add authentication information to a TCP segment to allow the receiver to check that the segment came from the true source - i.e. from a peer that shared the same secret information. Without an authentication extension to TCP, the receiver has no way to verify that a segment came from a trusted source, and attacks that disrupt TCP sessions are possible. For example, an attacker can send spoofed TCP resets to a victim. TCP sequence number randomisation helps mitigate this, but it is not enough. Adding authentication ensures the receiver can trust the segment came from the true source.

TCP-MD5 was standardised in 1998, and is now considered weak by modern cryptographic standards. It has been difficult to deploy because you can configure exactly ONE key for a connection. Changing keys was difficult, required close coordination, and often required an outage. TCP-AO addresses these problems by implementing more modern and secure cryptographic mechanisms and better key management. Operators can now configure multiple keys, along with setting the time period for which the keys are considered valid. Changing authentication keys no longer requires an outage.

TCP-AO is relatively new, and major network equipment vendors are currently adding support. See TCP-AO - GitHub for configuration examples. Don’t see configuration examples for your preferred platform? Contribute samples! If TCP-AO isn’t supported, ask your vendor. It can be used for more than just protecting BGP sessions. Any TCP-based application can benefit, if the underlying operating system supports AO. Juniper includes support for Label Distribution Protocol (LDP) in addition to BGP. Work is currently underway to add support in Linux, which will allow for adding authentication to rpki-to-rtr protocol (the communications channel between an RPKI validating cache and a router). Linux-based routing implementations such as Free Range Routing (FRR) are awaiting TCP-AO support in the kernel in order to offer it for routing protocols.

The George Washington University also uses the Generalised TTL Security Mechanism (GTSM). By default, eBGP sessions use a Time to Live of 1 because most eBGP peers are directly connected to each other. An attacker could originate a packet with a TTL such that it reached 1 at the target router. GTSM sets the TTL to the maximum value of 255 and causes packets with lower values to be discarded. When configured, only directly attached hosts can send traffic with the proper TTL so that it reaches the BGP application on a router. GTSM is essentially free - it uses widely available, basic features (setting the TTL on BGP sessions and packet filters).

Combining with TCP-AO and GTSM greatly reduces the attack surface of a router by limiting traffic that can reach the BGP application. GTSM discards traffic from hosts not directly connected to a router and TCP-AO ensures that traffic originates from a host sharing secret information.