Preventing Route Spoofing

To prevent spoofing in situations like the case study, you have the following two primary options:

•  Stop using RIP passively on routers.

•  Use passive RIP carefully on routers.

One way to prevent RIP spoofing is to remove Central Computing routers from passive participation in RIP and use some other routing protocol between them. The Central Computing routers are still active participants in RIP, broadcasting routing information to hosts every 30 seconds. Thus, misinformation from rogue RIP broadcasts is not propagated throughout the entire organization’s network. However, individual hosts are still susceptible to attack via RIP if they are passive participants in RIP.

Actually, the problem is not in RIP itself, but in trusting the source of RIP information. To be secure, the passive participant in RIP must only use RIP information from trustworthy sources. The RIP daemon usually distributed with Unix is routed, which is overly trusting. A replacement for the standard RIP daemon is GateD, developed at Carnegie-Mellon University (CMU). This program consults a configuration file when it starts. The configuration file, among other things, specifies the IP address(es) of trustworthy RIP information.

The GateD software is no longer available directly from CMU. GateD updates are now available from the GateD Consortium at Merit Networking, Inc. The most recent version may be obtained from the World Wide Web at http://www.gated.org or ftp://ftp.gated.merit.edu/net-research/gated.

Rather than abandoning passive participation in RIP, you can use GateD or the equivalent on the routers and hosts. Each router is configured to restrict its sources of trusted RIP information to trusted routers. Similarly, GateD is used on hosts that passively participate in RIP to protect them from rogue RIP broadcasts.

Central Computing in the preceding example still needs to decide if it will configure the router closest to Computer Science to accept the RIP information sent to it from non-Central Computing routers. If it does not, the workstation/router can send IP datagrams from the new departmental subnet to the router. The router, unless specially configured not to do so, will proceed to forward these datagrams to their destinations. When the destination host is ready to send a reply, it will not find the Computer Science network in its routing table. The routing table for the destination host will probably have a default router to use in such a case and send the IP datagram containing the reply to it.

The default router will also not have an entry in its routing table for the destination of the reply. If it does not have a default router to use for such a case, it will send an ICMP message back to the host that was attempting to send back the reply and discard the IP datagram containing the reply. If the routers do have default routers to use, the reply may be sent through a long sequence of routers until it hits one that does not have a default or the time-to-live field on the IP datagram hits zero and the datagram is discarded. In any case, the reply is dropped by a router, an ICMP message goes to the machine that sent the reply, and no reply reaches the Computer Science network.

If the Computer Science workstation/router is ignored by the central routers, it can still be used. In particular it can exchange data between the Computer Science network and the hosts on the Central Computing subnet directly connected to the Computer Science router. The only problem is in getting data from subnets beyond the Central Computing controlled routers.

To give Computer Science access to the rest of the network, Central Computing has several options. First, manual entries for the Computer Science network can be added to the routers closest to the Computer Science router and continue to ignore RIP broadcasts originating from it. This is simple, neat, and clean. However, if the central routers are using a link-state routing protocol rather than RIP to communicate among themselves, a manual entry for the Computer Science router may make it appear that the route to the Computer Science network is always up when, if fact, the route will occasionally be down.

A second option is to have the Central Computing router pay attention to RIP broadcasts from the Computer Science router but limit the information extracted from the broadcast. Specifically, the only thing that the central router really needs to know is if the workstation/router has a working route to the Computer Science network. Even if the Central Computing routers use a link-state protocol among themselves, the router nearest to Computer Science can use a hybrid approach to manage the oddball workstation/router that is not participating in the link-state protocol.