The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

BGP Adjacency Security Tools

By stretch | Thursday, December 3, 2009 at 3:49 a.m. UTC

BGP has an impressive arsenal of security tools available to protect its neighbor adjacencies. Here's a list and brief description of each I could come up with; if you can think of any I've omitted please mention it in a comment. (This article is limited to discussion about actual adjacency security; the acceptance of routes and peer policy enforcement is another matter entirely.)

Explicitly Defined Neighbors and ASNs

Unlike most interior routing protocols, BGP provides no mechanism to dynamically discover neighboring routers. The idea here is that BGP adjacencies should be formed only when they have been explicitly planned (not a bad practice to apply to your interior routing protocols as well). At a minimum, BGP neighbors must be explicitly configured by both IP address and autonomous system number (ASN).

router bgp 65100
 neighbor 10.0.0.2 remote-as 65200

Packets Limited to One Hop (EBGP)

By default, packets sent to external BGP (EBGP) neighbors are sent with an IP time to live (TTL)/hop limit (IPv6) value of 1. This prevents information leakage and helps mitigate remote spoofing attacks by ensuring BGP traffic cannot reach devices further than one hop from its source.

The ebgp-multihop parameter can be appended to a neighbor statement to allow external adjacencies to neighbors more than one hop away. By default, this command raises the TTL to its maximum value of 255 (like IBGP). If this command must be used, it is recommended to specify a TTL value equal to the minimum number of hops needed to reliably reach the neighbor.

router bgp 65100
 neighbor 10.0.0.2 ebgp-multihop 2

Note that an ebgp-multihop value of at least 2 is needed when establishing adjacencies based on loopback interface addresses.

TTL Security Extension

RFC 3682 introduced an additional countermeasure which extends the prior TTL concept: TTL security. This extension essentially flips the direction in which the TTL is counted to prevent spoofed traffic from appearing to have originated from a directly-connected neighbor.

TCP MD5 Authentication

BGP on IOS supports MD5 authentication by the use of a static secret key (password):

router bgp 65100
 neighbor 10.0.0.2 password FooBar

Because of this configuration syntax, many people assume this authentication is provided by BGP itself. In actuality, MD5 authentication is provided by the underlying TCP protocol (although the MD5 TCP option itself was proposed in RFC 2385 specifically for protecting BGP sessions). BGP_MD5.cap shows an MD5-secured BGP session.

TCP Spoofing Mitigation

A lesser known security feature implemented in IOS' BGP (and certain other protocols) is a heightened resistance to TCP spoofing attacks. A TCP reset attack, for example, exploits the fact that TCP considers valid any packet with a sequence number within a session's current receive window. To guarantee hitting a successful window in an (effectively idle) TCP session with a window size of 16K, an attacker needs only to transmit around 262,000 packets (assuming the source and destination addresses and port numbers are known). This is easy to accomplish with modern bandwidth speeds, and downright trivial for anyone in control of a botnet.

Cisco has been aware of this vulnerability for some time: an Internet draft was introduced back in 2003 (and implemented in IOS code around that time) which increases the difficulty of such an attack by a large degree. As specified in the draft, TCP sessions handled by applications such as BGP need only honor resets received with the exact next expected sequence number, rather than any sequence number which falls within the receive window. This increases the number of packets an attacker would have to spoof by a factor of the session's window size.

Interestingly, this mechanism has not been enabled on all TCP-based protocols. Casual testing has shown that while implemented for BGP and MPLS sessions, it has not been implemented for Telnet access, which is presumed to be short-term and subsequently less vulnerable.

Encrypted Tunnels

While not a tool unique to BGP, it is worth mentioning that encryption and authentication such as that provided by IPsec tunneling can very reliably secure an adjacency from outside interference. IPsec authentication is potentially much stronger than the MD5 TCP feature mentioned earlier, and encryption can guarantee immunity from spoofing attacks even if they are performed on the local segment.

Posted in Routing, Security

Comments have closed for this article due to its age.