Section 9.1. Routing Protocol Vulnerabilities

9.1. Routing Protocol Vulnerabilities

As you are sure to know, routing protocols can be classified as either interior or exterior gateway protocols (IGPs or EGPs). For routing IP, Border Gateway Protocol (BGP) is the only EGP currently in widespread use; all other commonly used IP routing protocolsincluding OSPF and IS-ISare IGPs. Although the mission of both types of routing protocols is to exchange route information, how they go about the information exchange differs significantly. Like any device outside of your administrative domain, external routers must be considered untrusted. BGP is designed to work in conjunction with complex routing policies so that you have detailed control over what information is shared and accepted from external peers. IGPs on the other hand, because they are intended to run inside of your administrative domain, assume that all routers within the routing domain can be trusted. So, IGPs are designed to make peering and information sharing as easy and as open as possible.

Most attacks launched against routing protocols target BGP because it is the "publicfacing" protocol and therefore most accessible from the outside. But you should never assume that your IGP is safe just because it is internal to your network. Malicious assaults against IGPs can and do occur, but the very nature of an IGP, to make information exchange as transparent as possible, can open the protocol to a number of accidental problems, too.

9.1.1. Malicious Threats

An attack against a routing protocol attempts to alter the normal behavior of the protocol in one of four ways:^[1]

^[1] Abbie Barbir, Sandy Murphy, and Yi Yang, "Generic Threats to Routing Protocols," draft-ietf-rpsec-routing-threats-06.txt, April 2004.

• Disclosure The target protocol divulges network information to the attacker. This information can then be studied to further exploit weaknesses in the network.

• Deception The target protocol is tricked into accepting routing messages from the attacker, believing the messages to come from a legitimate peer.

• Disruption The target protocol is prevented from functioning correctly. This might be the result of a denial-of-service attack in which messages are flooded to a router, overwhelming its resources, or it might be the result of simply disconnecting or breaking something.

• Usurpation The attacker gains control over the routing protocol process in one or more network routers. Disclosure, deception, or disruption can then be accomplished by causing packets to be routed to an illegitimate device or just blackholed.

A routing protocol might be compromised by an attacker gaining physical access to a link or a router. Such access can result in simple damage, or in the insertion of an illegitimate device into the protocol domain. Physical access almost always is the result of an "inside" attacker.

A routing protocol can also be compromised logically, for example by an attacker sending faked or malformed protocol messages, or by gaining logical access (such as Telnet or SNMP) to a router. Logical attacks can be launched either from inside or from outside of the protocol domain.

An attack can be aimed at one or more functional components of OSPF or IS-IS:

• The Hello protocol A bogus Hello message with one or more intentionally incorrect fields can be used to break or hijack an adjacency to a legitimate peer.

• The flooding process Sending spoofed LSAs or LSPs, which claim to be from existing routers in the domain, can trigger heavy flooding and SPF calculations as routers resend legitimate LSAs or LSPs.

• The link state database Sending spoofed LSAs or LSPs from "phantom" routers can cause the LSAs or LSPs to be accepted into the LS database, causing incorrect routing. Or, the database can simply be filled up with spoofed LSAs or LSPs, causing memory overflow.

• Aging Sending spoofed LSAs or LSPs that claim to be from legitimate peers and that have been "aged out" can cause legitimate LSAs or LSPs to be temporarily flushed from the LS database.

• Sequence numbers Spoofed LSAs or LSPs that claim to be from legitimate peers can contain a maximum sequence number value, causing sequence number rollover.

• DR or DIS process A bogus Hello with a null or illegitimate DR/BDR or DIS field, or with a high priority value, can trigger reelection or even cause other routers to accept a nonexistent DR or DIS, making the associated broadcast or NBMA link unavailable.

• Options flags Spoofed options flags can cause broken adjacencies or acceptance of illegitimate information. For example, a "phantom" OSPF router sending Hellos with the E bit set causes the router to be accepted as an ASBR, which in turn allows it to inject illegitimate external routing information.

A "phantom" routeran illegitimate router or logical entity that establishes an adjacency with one or more legitimate routers in the networkcan also mount attacks on OSPF and IS-IS. Creating a phantom router normally requires access to one of the network links.

Software for probing and attacking routing protocols is readily available for download. One well-known example is the Internetwork Routing Protocol Attack Suite (IRPAS), which provides a set of applications for active and passive scanning of protocol activity and for custom-building routing protocol packets.

9.1.2. Non-Malicious Threats

Non-malicious threats to routing protocols are the result of either misconfiguration or an implementation problem. When a non-malicious problem alters protocol behavior, the result is almost always disruption of some sort. However, the result might also be to open the protocol to a malicious attack.

In many cases, the result of a configuration mistake is harmless. For example, when bringing a new router into the network an incorrect configuration might prevent all the expected adjacencies from coming up. The missing neighbors are apparent, and the problem can be quickly identified and corrected. Other problems might be more subtle. An incorrect interface metric might result in suboptimal routing; incorrect timers might not have any effect at all until the protocol becomes unable to correctly respond to a network problem.

On the other hand, a configuration mistake can be disastrous. Failure to enable authentication or filtering might leave a door open for an attacker. Policy mistakes can bring the protocol down. The most glaring example of a policy problem, and one that still occurs with surprising frequency, is redistributing full Internet routes from BGP into OSPF or IS-IS. Such a mistake might happen on only one router, but the result is usually a system-wide meltdown as tens of thousands of external prefixes are flooded throughout the domain. Correcting the problem is not a matter of just eliminating the misconfigured policy or "pulling the plug" at the Internet-peering interface. In a large network, where clearing the prefixes from LS databases across the domain requires a systematic shutdown and reactivation of the protocol on many routers, recovery means hours of hard workall while the network is down and all under a barrage of calls from angry customers and executives. It's not pretty.

Implementation problems are the fault of the coder or vendor of routing software. The problem might be a generally poor implementation or a bug in an otherwise stable protocol implementation. The result can be poor performance or a high failure rate. And attackers are quick to identify and exploit poor or buggy implementations.