TCP-AO strengthens BGP sessions, but key lifecycle remains the hard part
BGP sessions often last for months, so authenticating the TCP connection is an operational control rather than a one-time setup task. TCP Authentication Option (TCP-AO), defined in RFC 5925, replaces TCP MD5 with stronger message authentication codes, traffic keys derived from a master key tuple, a key identifier and protection against replay on long-lived connections.
That improvement does not make BGP routing secure by itself. TCP-AO authenticates TCP segments between configured peers. It does not decide whether a route is valid, whether an origin is authorized or whether a prefix leak is acceptable. Route filtering, RPKI origin validation and maximum-prefix controls remain separate decisions.
The peer is a security boundary
Each TCP-AO association needs matching algorithms and key material on both routers. The master key tuple identifies a send key, a receive key and a key identifier used on the wire. A mismatch usually appears as a failed connection or a peer that drops during a change, not as a useful routing error. Teams should inventory every peer before changing authentication.
Record the peer address, autonomous system, interface, address family, configured key identifier, algorithm, owner and last change for each session. Include route reflectors, transit links and internal peer groups that are easy to forget. The inventory should identify which side controls each key and where an emergency replacement can be obtained.
Rotation needs overlap
A safe rotation accepts the old key identifier while adding the new one, then cuts over the session and removes the old key after verification. The exact vendor sequence differs, but the principle is consistent: both ends must recognize the same key identifier and algorithm during the transition. A simultaneous replacement with no overlap creates a self-inflicted outage.
RFC 5925 does not define an in-band key-management protocol. Key distribution is external, which means configuration management systems, change records and backups become part of the trust path. Encrypt stored key material, restrict read access to router configuration and avoid putting keys into tickets, chat or unprotected templates.
Verify the session, not just the configuration
After a change, confirm that the BGP session is established, that the expected key identifier is active and that the peer is still receiving the expected route count. Check logs for authentication failures and monitor for flapping. A perfect configuration file is not proof that the live session uses the intended association.
Prepare rollback before the maintenance window. The rollback should restore reachability without requiring a second untested key. Test the procedure in a lab or a non-production peer group, including the case where one side receives the new key before the other.
TCP-AO is a useful upgrade from MD5. Its security value depends on disciplined key custody, staged deployment and independent verification of the live peer state.
Top comments (0)