Network devices must authenticate all BGP peers within the same or between autonomous systems (AS).
As specified in RFC 793, TCP utilizes sequence checking to ensure proper ordering of received packets. RFC 793 also specifies that RST (reset) control flags should be processed immediately, without waiting for out of sequence packets to arrive. RFC 793 also requires that sequence numbers are checked against the window size before accepting data or control flags as valid. A router receiving an RST segment will close the TCP session with the BGP peer that is being spoofed; thereby, purging all routes learned from that BGP neighbor. A RST segment is valid as long as the sequence number is within the window. The TCP reset attack is made possible due to the requirements that Reset flags should be processed immediately and that a TCP endpoint must accept out of order packets that are within the range of a window size. This reduces the number of sequence number guesses the attack must make by a factor equivalent to the active window size. Each sequence number guess made by the attacker can be simply incremented by the receiving connections window size. The BGP peering session can protect itself against such an attack by authenticating each TCP segment. The TCP header options include an MD5 signature in every packet and are checked prior to the acceptance and processing of any TCP packet--including RST flags. One way to create havoc in a network is to advertise bogus routes to a network. A rogue router could send a fictitious routing update to convince a BGP router to send traffic to an incorrect or rogue destination. This diverted traffic could be analyzed to learn confidential information of the site's network, or merely used to disrupt the network's ability to effectively communicate with other networks. An autonomous system can advertise incorrect information by sending BGP updates messages to routers in a neighboring AS. A malicious AS can advertise a prefix originated from another AS and claim that it is the originator (prefix hijacking). Neighboring autonomous systems receiving this announcement will believe that the malicious AS is the prefix owner and route packets to it.
Configure the device to authenticate all BGP peers.
Review the device configuration to determine if authentication is being used for all peers. A password or key should be defined for each BGP neighbor regardless of the autonomous system the peer belongs. Most vendors' command lines use a neighbor statement or keyword to specify a BGP peer. If BGP peers are not authenticated, this is a finding.