4.5 Securing Routing Protocols

   

Within a network there are probably multiple routing methods . Most large networks use a combination of static routing. It is important when selecting a routing method to fully understand the potential security holes, and to take steps to address them. This section will address static routing, as well as three very common dynamic routing protocols: RIP, BGP, and OSPF.

An in-depth explanation of the configuration process for the routing options discussed in this section is beyond the scope of this book. So, while there are some configuration examples in this chapter, they are by no means intended to be complete. Most vendor websites offer configuration examples for the different protocols listed here.

4.5.1 Static vs. Dynamic Routing

If you go back and take a look at the network design presented in Figure 4.1, you will notice that the diagram presented a single link to the Internet, and a very flat network architecture. While this design may work well for smaller companies, as the complexity of a network increases it can lead to problems.

Many companies prefer to segment different departments within the company to make the management of network resources easier. Deploying this type of network design can involve the use of multiple routers, which are used to create the segments. While this is one way to provide the desired network segmentation, many networking experts recommend the use of multilayer switching rather than increasing the number of routers deployed. Multilayer switching, which is discussed in Chapter 5, has the same benefits as increasing the number of routers, while still keeping the network flat, and it generally has a lower cost.

Static routing is the simplest form of routing. It simply means that the path along which the router should direct traffic is manually configured. There are two ways of handling static routes. The first is to build a routing table defining what netblocks should be routed through an interface. For example, a router connected to ISP A, B, and C, can be configured to direct traffic destined for 10.10.0.0 through the ISP A interface, while traffic destined for the 10.100.0.0 netblock can be instructed to route through the ISP B interface.

The second way of creating a static route is to create a gateway for the router. [6] The gateway can either be configured so that all traffic is routed through it, or it can be used in conjunction with other static routes, so that it is only used if there is no static route for a destination IP address.

[6] In Cisco-speak, this is the Gateway of Last Resort.

Static route interfaces and gateways both need to be directly connected to a router. If the router cannot reach the interface it will drop the packet.

Dynamic routing, on the other hand, does not involve manual interference with the routing tables. Instead, the chosen protocol is configured on a router interface and routing tables are generated and updated automatically. In addition to involving less manual intervention, dynamic routing protocols provide better performance, because data always traverses the optimal path.

Which of the two is more secure? The answer depends on what type of attack you are protecting against. Dynamic routing protocols rely on information from other routers. Any time you are going to allow another device, even one that is controlled by you, to update equipment the risk exists of falling prey to an attack. An attacker who gains access to the network can interject bad routing statements that will be picked up by all other routers in the network.

Star Trek fans are familiar with the alien race known as the Borg. The Borg were interconnected , and they all had simultaneous access to the same information. They were defeated because the crew of the Enterprise was able to interject the command "sleep" into their collective consciousness and put them all to sleep.

Dynamic routing works in much the same way. If you do not limit the devices that have access to update routing information, then an attacker can shut down the network, or possibly route all network data through a device he or she controls, giving an attacker with a sniffer access to all information that traverses the network.

Using static routes prevents an attacker from poisoning routing tables with bad information, but presents another problem. With a single default route, a network is more susceptible to a DoS attack. If you are connected to diverse backbones and using a dynamic protocol to route traffic using the best path, it is more difficult for an attacker to launch large attacks, because there are multiple paths into and out of the network. Of course, if an attacker has access to enough bandwidth to flood a network, multiple connections are going to do little good.

All things being equal, a dynamic routing protocol used with proper security precautions will be more secure than a static routing protocol.

4.5.2 Interior and Exterior Dynamic Routing

Before discussing dynamic routing in more detail, it is important to distinguish between interior and exterior protocols, because the security approaches taken for the two types of protocols are vastly different.

Interior and exterior refer to whether a packet will be routed within or outside an autonomous system. Interior Gateway Protocols (IGP) direct traffic within an autonomous system; conversely, EGPs direct traffic between autonomous systems.

An autonomous system is a network, or series of networks, that is controlled by a single organization. Most organizations are assigned groups of IP addresses ”netblocks ”by their ISP. The organization has complete control of routing within those assigned netblocks, and only uses the ISP to hand-off traffic to the WAN.

As an organization grows, additional netblocks are added, and netblocks from other ISPs may be used. This makes it extremely difficult to use contiguous netblocks, making routing more difficult.

Fortunately, the Internet Assigned Numbers Authority (IANA) developed a system for distributing Autonomous System Numbers (ASN) in RFC 1930. An ASN is a unique identifier distributed by the three regional registries:

  1. American Registry for Internet Numbers (ARIN): www.arin.net

  2. Reseaux IP Europ ens (RIPE): www.ripe.net

  3. Asia Pacific Network Information Centre (APNIC): www.apnic.net

Each registry is assigned a block of numbers that it is responsible for maintaining. Organizations that require an ASN, and can justify the allocation of one, receive it from the appropriate registry (each registry is responsible for certain geographic areas).

An ASN is used by IGPs to route traffic within the system and can also be used with EGPs to route traffic between systems. Using an ASN versus manually editing routing tables can save network administrators enormous amounts of time.

NOTE

It is a common practice to use the acronyms AS and ASN interchangeably. However, throughout the book, if you see AS it will refer to a network controlled by a single organization. If you see the term ASN, it refers specifically to an IANA-assigned number to identify a network.


4.5.3 RIP

RIP is one of the oldest and most widely accepted protocols in use on the Internet. Xerox originally developed RIP in the 1970s; in the 1980s, it was ported to the LAN, and then the WAN.

RIP is an IGP protocol based on the Bellman-Ford algorithm. The Bellman-Ford algorithm is a method for returning the shortest path between two points; this type of algorithm is also referred to as a distance-vector algorithm. Most routing protocols use some sort of distance- vectoring algorithm to determine the distance from Point A to Point B on a network. When RIP is enabled on a router, the router is constantly examining the paths available to it, and using that information to build a routing database. All RIP-enabled routers on an autonomous system update each other with the information in their databases, using the UDP. In some instances routers can update each other as often as every 30 seconds. The standard update interval, except for core routers, is 180 seconds.

To better understand how RIP works, take a look at Figure 4.3. Let's say that Router A needs to deliver a packet to Router B , and all these routers are part of the same autonomous system. The first thing Router A will do is determine whether or not it has a direct connection to Router B . Because it does not have a direct connection, Router A will examine its routing tables to determine if it has a path for this address. If it does not, it will simply forward the packet to its default gateway.

Figure 4.3. An autonomous network

graphics/04fig03.gif

If you look at the diagram you will notice that there are multiple paths a packet can take to get from Router A to Router B . RIP determines the shortest path from Router A to Router B . In this case, Router A is three hops away from Router B : D to E to B, as shown in Figure 4.4.

Figure 4.4. The shortest path from Router A to Router B

graphics/04fig04.gif

An RIP-enabled router automatically learns new routes from the other routers in the autonomous system. The RIP routing tables will tell the router the path a packet takes to get to a destination. Take a look at this sample from the routing table of Router A:

 gw1#show ip route  R 10.10.60.0/24 [120/1] via 10.10.50.1, 00:00:6, Serial0  R 10.10.70.0/24 [120/1] via 10.10.50.1, 00:00:4, Serial0  C 10.10.10.0/24 is directly connected, Serial0  R 10.10.50.0/24 [120/1] via 10.10.10.1, 00:00:8, Serial0 

Automating the routing table updates in this manner allows the network to automatically failover in the event of a failure. The downside is that RIP does not automatically update when there is a failure ”the routers directly connected to the failed router will not notify the rest of the network until it sends out its next RIP update. If the update interval is set to 180 seconds, then the rest of the routers will continue to send traffic along the wrong path for up to three minutes after a failure.

Using the network in Figures 4.3 and 4.4, we can examine the failure process. In the next scenario Router F will fail, as shown in Figure 4.5.

Figure 4.5. A failure occurs in Router F

graphics/04fig05.gif

After Router F fails, the network has to renegotiate the routes. The first step is that Router E has to realize that it has lost connectivity to F . After it has realized that it no longer has a connection to F , Router E will update its routing tables to reflect the change in the network topology. The new routing tables are updated throughout the network the next time D sends out its routing table.

When Router A has received the new information it will renegotiate the shortest route to B . Router A will negotiate a four-hop path to Router B ( C to D to G to B ). This new path will remain in effect until a shorter path is introduced into the topology, and communicated to Router A .

RIP is the first example of an SPF protocol. Different SPF protocols have methods other than Bellman-Ford algorithm to determine the shortest path. Modern SPF protocols, like OSPF, also use distance and latency as well as hop number to determine the shortest path.

4.5.3.1 RIP Security

The original RIP protocol was deployed, as is the case with many of the original Internet protocols, with no thought to security. In fact RIP and RIP Version 1.0 have so many security holes that it is recommended that they not be run in production environments.

There are two areas where RIP security falls dangerously short:

  1. RIP does not verify the information sent to it.

  2. RIP does not include any form of authentication.

Both areas revolve around the fact that RIP has no way of verifying the authenticity of the information it has received.

The first compromise stems from the fact that RIP does not verify that the information sent to it. An attacker with a spoofed IP address and an understanding of your network and the RIP protocol would be able to inject bad routes domain. An attacker who just wanted to be spiteful could inject large routing lists that could cause the routers to crash if they are unable to process all of the information within the list. Even if the new lists did not cause the network to crash, they would continuously flood the network with traffic every time they were exchanged; this could bring the network to a crawl.

Having the network crash is actually the less costly of the two scenarios. If that same attacker were attempting to gather information about the network, he or she could simply reroute traffic to a different location and sniff through the packets looking for the desired information.

These scenarios are exacerbated by the fact that RIP and RIP Version 1.0 do not offer any way for routers to authenticate information. There is no password or public key verification capability specified within the original RIP protocol. Some vendors have attempted to add this functionality into their implementation of the protocol ” unfortunately , that raises vendor incompatibility issues.

4.5.3.2 RIP Version 2.0

RIP Version 2.0 was introduced in 1993 to address some of the security concerns inherent in the initial RIP and RIP Version 1.0 specifications. Version 2.0 is identical to previous versions in the way it handles routing failover issues, but it adds a security layer to the protocol.

RIP Version 2.0 was introduced in RFC 1388 and was updated by RFC 2453 in 1998.

Version 2.0 was introduced with password-based authentication. In order to maintain backward compatibility with older versions of RIP, the password is sent in a separate packet; if a router is only running RIP, it will ignore the password. RIP Version 2.0 devices can be configured to accept updates from older versions of RIP with no password authentication, or they can be configured to drop the packets. The problem with this, of course, is that clear text passwords are not much of a challenge to a determined attacker.

In 1997 Fred Baker and Randall Atkinson proposed, in RFC 2082, that Version 2.0 be enhanced to support keyed MD5 (message digest) encrypted passwords. The keyed MD5 algorithm is the standard method of authentication for IP headers. The keyed MD5 algorithm allows RIP Version 2.0 packets to use an encrypted key to handle authentication. While keyed MD5 encryption is not the best manner of key exchange, it is very suitable for short message segments that expire quickly ”which is why it is a good match for Version 2.0.

4.5.4 OSPF

OSPF is a routing IGP protocol developed, in part, to address many of the limitations of RIP. OSPF Version 2.0, the current version, is specified in RFC 2328.

OSPF is, by design, much more secure than RIP and provides increased functionality and performance on larger networks. Some of the advantages of OSPF include:

  • No limit to the number of hops a router will support (RIP has a limit of 15).

  • OSPF sends out updates using a multicast address, so that only routers listening for OSPF updates will receive the packets, helping to conserve bandwidth.

  • OSPF has faster convergence than RIP; changes in network topology are communicated instantly; and only the changes are communicated, not the entire routing table.

  • OSPF is very useful for load balancing traffic between routers.

  • When selecting a route, OSPF calculates a cost based on available bandwidth as well as hop count.

OSPF determines the path to take through the network using the Dijkstra algorithm. As with RIP, OSPF uses the algorithm to determine a cost for each link. Each router builds a unique network topology based on its location within the autonomous system, while maintaining the same link-state information as the rest of the network.

Figure 4.6 shows a network similar to the one used to illustrate RIP. However, link speeds have been added between the different routers. Again, we want to see how Router A will get to Router B.

Figure 4.6. An OSPF network

graphics/04fig06.gif

The first step in determining the route is to examine links costs, also called metrics. OSPF uses a very simple formula to determine the cost of a link:

 Cost = 100000000/Bandwidth (expressed in bits per second) 

Take a look at the top of the diagram. Each of those routers are connected via a 100-megabit link. 100 megabits is the same as 100 million bits, so the cost for a 100-megabit link would be calculated like this:

 Cost = 100000000/100000000=1 

Each cost in the path has to be added together. The cost from A to C is 1, the cost from C to D is 1, and the cost of D to B is 1, so the total cost of traversing from A to B using the top group of routers is 3. You'll notice, using this calculation, that even though A is directly connected to B , the cost for that link is actually higher, with a value of 10. Of course it seems pointless to have a direct link that is not used, so OSPF assigns a cost of 0 to networks that are directly connected. In this case, even though the top route has a lower cost, traffic will still traverse the direct A to B link.

In Figure 4.7 the direct A “B link has been removed, and all bandwidth has been set to 100 megabits.

Figure 4.7. Revised OSPF network

graphics/04fig07.gif

In this newly redesigned network the cost of getting from Router A to Router B is equal for both paths. OSPF can handle this situation in one of two ways:

  1. If left on its own, it will automatically load balance traffic between the two paths. Some traffic will use the C “D path, while other traffic will use the E “F path.

  2. If load balancing is not desired, OSPF allows you to manually set the cost for each connection. You can increase the cost of the A “E connection, so it raises the cost of the E “F path and traffic will be routed along the C “D path, unless there is a failure.

OSPF also allows you to create areas. Rather than receive updates from all routers on the network, you may want to group the routers in smaller units. The routers will only share OSPF information with other routers in their area.

The primary area for an OSPF network is Area 0. This area should be at the logical center of your network, with other areas touching it. Areas are defined on the interface of the router, and routers that belong to two areas are considered border routers (see Figure 4.8).

Figure 4.8. OSPF areas

graphics/04fig08.gif

Figure 4.8 shows an OSPF network with areas enabled. By limiting the number of routers in each area, you can limit the number of broadcasts that each router has to process, and make routing across the network easier.

4.5.4.1 OSPF Security

You have already seen one of the best security features that OSPF offers: areas. When an OSPF-enabled interface on a router receives an update from another device that has a different area, it ignores it. Of course, because OSPF packets are sent as clear text, it would be trivial for a determined attacker to find the area number and inject bad routes into a network, so other measures of security are needed.

In addition to defining OSPF areas, network administrators can also explicitly state who the OSPF neighbors in a network are. OSPF is a broadcast protocol by default. More specifically, it is a multicast protocol, so an OSPF-enabled interface will send out routing updates to all interested parties whenever there is a change. You can lessen this problem by forcing OSPF to send directed updates. This is a two-part process: (1) disable broadcast and (2) manually configure the OSPF neighbors. This will limit the number of network devices that the router will send to and receive OSPF information from.

OSPF has password authentication enabled. Unfortunately, the default is usually set to no password. There are two types of password authentication supported natively in OSPF: plain text and MD5.

While plain text authentication does have some serious limitations, if authentication also requires a specific area, and is from one of the trusted neighbors, it may provide enough security for your organization. This is actually one of the really nice features about OSPF security: If the authentication header does not meet all of the predefined security parameters, it will be rejected by the router. This allows network administrators to layer the security measures used in the network, making things more difficult for an attacker.

MD5 authentication provides a greater level of security. To enable MD5 authentication, the same password must be defined on all router interfaces participating in an OSPF area. When a network device sends routing updates to other devices in the same area, it includes a message based on the key, the key-ID, and the OSPF packet. The receiving device translates the message, and matches it against the password it has stored; if the two passwords match, the router accepts the update. At no point is the password sent; instead, the message in the header is deciphered by the receiving device to see if it matches the password.

Because OSPF areas reside within controlled networks, security is sometimes not strictly enforced on OSPF devices. This is a bad strategy; a good security policy has to work at many levels to be effective. Protecting the internal network is a good first line of defense in the battle to keep servers and your data protected.

The next protocol ”BGP ”is an exterior gateway protocol, and it has a whole new set of security concerns.

4.5.5 BGP

BGP, like OSPF and RIP, is used to exchange routing information, but BGP is unique because it can be used as both an IGP (IBGP) and an EGP (EBGP), though it is most often used as EBGP. Figure 4.9 shows a simplified BGP configuration.

Figure 4.9. A BGP network

graphics/04fig09.gif

The original specification for BGP was published in 1991 under RFC 1267. The current version of BGP, BGP Version 4.0, is outlined in RFC 1771 and 1772.

In Figure 4.9, AS1 represents a typical ISP backbone, while AS2 and AS3 are either smaller ISPs or enterprise customers of that ISP. AS2 and AS3 will run EBGP with AS1, and AS1 runs an IGP on its internal network.

As you would expect, the routing process is automated; AS2 and AS3 will automatically update AS1 with any changes in the network, and AS2 and AS3 will receive any changes in network topology that occur within AS1.

A BGP-enabled network device will only communicate changes in its routing tables to other devices, and a BGP device only defines a single path ”the best one ”to a destination on its network.

BGP is very robust; the number of advertised routes on the Internet has gone from fewer than 20,000 in 1994 to more than 100,000 today. This means that the routing table for a core Internet router can contain more than 100,000 entries.

Attempting to share more than 100,000 routes between every router on the Internet would be a waste of bandwidth, and completely unnecessary, so BGP allows users to restrict the amount of information that is propagated to other routers. These restrictions are called attributes and are defined as part of the protocol.

BGP transmits information over TCP, using port 179 rather than using the direct connection model supported by OSPF and RIP. Because BGP runs over a reliable transport protocol, rather than UDP as OSPF does, error control and retransmission are automatically done and do not need to be addressed within the protocol.

When two BGP-enabled routers establish communication, the first thing they do is exchange full routing information about their respective networks. Each router uses this information to build a network map of the remote AS. The remote network is built using the path to each destination along with attributes about that path. The path attributes for each destination are stored in a table, like Table 4.1, that contains required and optional information.

Table 4.1. AS Path Attributes

Path Attribute

Function

Optional or Mandatory

ORIGIN

AS from where the path originated.

Mandatory

AS_PATH

List of AS segments the packet has to traverse.

Mandatory

NEXT_HOP

The next border router in the path.

Mandatory

MULTI_EXEC_DISC

In cases where there are multiple exit points to an AS, this allows you to weight them.

Optional

LOCAL_PREF

Used within an AS to define a router's preference for a route.

Optional

ATOMIC_AGGREGATE

Used within an AS to share that a less-specific route will be advertised.

Optional

AGGREGATOR

Contains the last AS of an aggregate route and the IP address of the router that formed the route.

Optional

The path attributes serve two purposes aside from determining the route to a destination: to help prevent routing loops and to detect changes in the network topology of the remote AS.

After the initial connection between two BGP-enabled devices has been made, there are four different types of messages that can be sent:

  1. Open: Used to establish the BGP parameters between the two devices. The devices exchange BGP version, AS numbers, hold time values, and identifier (usually the device's IP address).

  2. Update: Contain information about reachability within the AS, as well as connectivity with other AS.

  3. Keepalive: Sent out periodically to ensure that both devices are responding properly. The message contains the BGP header, with no additional information.

  4. Notification: Sent when an error occurs between the two devices. After a notification message is issued, no further BGP information will be exchanged between the two devices until the error is resolved and connectivity is re-initiated between the two devices.

Unless otherwise specified, an AS with multiple connections will always choose the optimal path. If there is a tie between two paths, the path with the lower IP address will be chosen. This is not always an optimal solution, as it creates the problem of an unused BGP device [7] , while the other BGP device is probably overburdened. You can resolve this by load balancing your BGP connections.

[7] Most likely, an expensive one.

4.5.5.1 BGP Security

BGP has some built-in security measures that prevent it from accepting multiple routes to the same AS, and are used to control what other devices a BGP-enabled device will share information with. Overall, BGP provides very poor security.

There are several areas in which BGP is lacking in security:

  • There is no authentication of BGP packets.

  • All data is sent clear text across the WAN.

  • There is no verification of the route information that is exchanged.

  • A misconfiguration by one of the BGP peers can cause traffic to be black holed, or lead to replay attacks, where routes are continuously fed into a router, causing a routing loop that can crash the router.

As with RIP and OSPF, an extension has been added to BGP to support authentication of BGP headers using MD5 encryption. This is outlined in RFC 2385. While this increases the level of security between BGP neighbors, it does not address the problems associated with bad routes being interjected across AS, nor does it address misconfiguration errors.

With security performance this poor, you may wonder why BGP is used so widely. The truth is that there is not another protocol that is robust enough to handle the number of routes that BGP is able to support. In addition, because BGP is so widely deployed, it would take a complete reengineering of the Internet backbone to implement another protocol.

Rather than throwing out BGP, several engineers from BBN have developed an enhanced version of the BGP protocol, Secure BGP (S-BGP). S-BGP builds on the fundamentals of the BGP protocol, but adds several security enhancements.

The creators of the S-BGP protocol advocate taking several steps to relieve the security problems inherent in BGP. The underlying methodology for securing BGP would be a series of Public Key Infrastructure (PKI) certificates that could be used to verify the authenticity of a BGP neighbor, the advertised IP blocks, the AS, and that the router is authorized to share information about the AS.

S-BGP has a lot of potential to resolve many of the issues currently associated with BGP, and to vastly improve the security of the core Internet backbone. At this time, none of the major router vendors have implemented support for S-BGP, so its widespread deployment is at least several years out.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net