Routing is an essential element in keeping networking infrastructures up and running. Due to the major role that routing protocols play in network infrastructures, this chapter is devoted to detailing some commonly used routing protocols and which built-in functionality exists to effectively secure them (at least to the extent possible today). Most of the mechanisms to provide security have been available for years but have not been widely deployed or are not clearly understood (probably leading to the nondeployment issue). This chapter focuses on most of the routing protocols used in deploying IP routing architectures: RIP, EIGRP, OSPF, IS-IS, and BGP. It is not intended to be a tutorial on routing protocols but rather a brief introduction followed by some explicit details on configurable security provisions built in to each of the protocols.
Routing is the method by which a host or router decides where to send a datagram. It may be able to send the datagram directly to the destination, if that destination is on one of the networks that is directly connected to the host or router. However, the interesting case is when the destination is not directly reachable. In this case, the host or router attempts to send the datagram to a router that is nearer the destination. The goal of a routing protocol is very simple: to supply the information needed to do routing.
NOTE
In earlier literature, the terms router and gateway were often interchangeable. In today's networking environment, however, the term gateway is a generic term for a device that joins two or more networks together and can operate at any level of the OSI model from application protocols to low-level signaling. The term router has replaced gateway when used to describe a device that interconnects multiple networks at the Layer 3 (network layer) of the OSI model.
Routers are devices that direct traffic between hosts. Routers collect information on all the paths to all the destinations they know how to reach and build a routing table from this information. They both announce and receive route information from other routers, and each router uses this information to modify its routing tables. Routers use the following four primary mechanisms to create and modify their routing tables:
Direct connection—. Any network connection to which the router is directly connected is automatically added to the routing table. Of course, the link must be up.
Static routing—. Manual entries can be configured on routers to instruct the router to use a given route to get to a particular destination.
Dynamic routing—. Router messages are announced and received. These update messages are used to create routes in the routing table. The routing algorithm associated with a particular routing protocol determines the optimal path to a particular destination and updates the route table. It can automatically adapt to changes in the network.
Default routing—. A manually entered route is used as a last-resort method to reach a destination when the route is not known by any other routing mechanism.
NOTE
If a routing table has routes from multiple sources, such as static routes and some dynamic routing protocol routes, there is always a hierarchy of preference defining which route is more preferable if there are two ways to reach a destination. The order of preference can vary depending on router manufacturer, and the order is user configurable. As a default, static routes typically always take precedence over any other routes.
Routing protocols can be classified into two separate groups: interior and exterior routing protocols. An Interior Gateway Protocol (IGP) is used for exchanging routing information between gateways within an autonomous system. An Exterior Gateway Protocol (EGP) is used for exchanging routing information between different autonomous systems.
In large nationwide corporate networks such as financial institutions or government facilities, it is very unlikely that a single routing protocol will be used for the whole network. Rather, the network will be organized as a collection of autonomous systems. An autonomous system is a group of networking components that will in general be administered by a single entity, or at least will have some reasonable degree of technical and administrative control. Each autonomous system will have its own routing technology. This may well differ for different autonomous systems. The routing protocol used within an autonomous system is referred to as an IGP. A separate protocol is usually used to interface among the autonomous systems.
The four most common routing protocols used as IGPs are as follows:
Routing Information Protocol (RIP)—. RIP is a distance vector–based IGP. It maintains a list of distances to other networks measured in hops, the number of routers a packet must traverse to reach its destination. It has a maximum hop limitation of 15 hops, which only makes it suitable for smaller-scale networks. Routing updates are broadcast every 30 seconds to all neighboring RIP neighbors. In RIPv1, each update is a full routing table. RIPv2 added many enhancements, including triggered updates and authentication.
Enhanced Interior Gateway Routing Protocol (EIGRP)—. EIGRP is a proprietary Cisco IGP. It maintains a complex set of metrics to determine the distance to other networks. It integrates the capabilities of link-state protocols into distance vector protocols and saves not only the least-cost route but up to eight routes to a destination. EIGRP updates are sent only upon a network topology change; updates are not periodic.
Open Shortest Past First (OSPF)—. OSPF is a link-state IGP. It uses a link speed-based metric to determine paths to other networks. Each router maintains a simplified map of the entire network. Updates are sent via multicast and are sent only when the network configuration changes. Each update only includes changes to the network.
Intermediate System-to-Intermediate System (IS-IS)—. IS-IS is similar to OSPF and is also a link-state IGP. Instead of an area concept like OSPF, IS-IS has two levels: level 1 (areas) and level 2 (backbones). The IS-IS backbone is just a contiguous collection of level 2-capable routers linking level 1 areas together. Most networks use level 2 only because there is little benefit in the extra complexity that running both level 1 and level 2 offers. IS-IS does not use IP for transport; it uses Connectionless Network Service (CLNS). This could make IS-IS harder to attack because CLNS is rarely routed across the Internet.
The decision of which IGP to use depends significantly on both the customer's experience with and the technical capabilities of the routing protocols. Engineers with more experience with IS-IS will always choose IS-IS. Engineers with a strong background in OSPF will always choose OSPF. The rule of thumb seems to be that beginners to interior routing choose RIP or EIGRP because it is easier to get started. However, OSPF is a better choice because it forces good IGP design to ensure that the network will scale. Those who are very experienced tend to choose IS-IS because it allows for better scaling with more configuration options than the other IGPs.
The Border Gateway Protocol version 4 (BGP-4) is a distance vector–based EGP. It employs a set of sophisticated rules to maintain paths to other networks. Updates are sent over TCP connections between specifically identified peers. BGP-4 supports route aggregation to support very large network. (Most of the Internet core deploys BGP-4.) A large enterprise network comprised of multiple autonomous systems should look at deploying BGP-4 in its backbones.
The kind of damage that can be done in an unsecured routing infrastructure is discussed in more detail in Chapter 5, “Threats in an Enterprise Network.” This chapter focuses on what security mechanisms are available to secure routing updates. Of course, it goes hand-in-hand in protecting the physical routers themselves.
A major concern is to avoid false routing update packets that falsely modify routing tables. Often, this is due more to misconfiguration rather than malicious intent. Two basic approaches for protecting routing table integrity are as follows:
Use only static routes—. This works for very small networks but will become an administrative nightmare for networks with more than 5 to 10 entries.
Authenticate routing updates—. All dynamic routing protocols have mechanisms to provide some sort of route authentication (that is, ensuring that router updates came from legitimate sources).
NOTE
Currently, there is not a good way to ensure that the routing updates included from the legitimate source were updates the source was authorized to send. This is a difficult problem and still under research in the routing community.
Most routing protocols incorporate neighbor authentication to protect the integrity of the routing domain. Authentication occurs when two neighboring routers exchange routing information and ensures that the receiving router incorporates into its tables only the route information that the trusted sending neighbor really intends to send. Authentication prevents a legitimate router from accepting and then using unauthorized, malicious, or corrupted routing updates that may compromise the security or availability of the network (for example, having an unauthorized device send a routing update that makes the legitimate router believe that the best route for certain traffic is via an alternative path that may or may not exist). Such a compromise would lead to rerouting of traffic, a denial of service, or just giving access to certain packets of data to an unauthorized person.
When neighbor authentication is configured, the router authenticates the source of each routing update packet it receives. This is accomplished by the exchange of an authentication key (sometimes referred to as a shared secret) that is known to both the sending and the receiving routers. Two types of neighbor authentication are typically used: plaintext authentication and cryptographic authentication (typically using the keyed Message Digest 5 [MD5] checksum that was discussed in Chapter 2, “Security Technologies”).
Each participating router must share an authentication key. This key must be specified in each router's configuration. Multiple keys can be specified with some protocols; each key must be identified with a key number. Figure 4-1 illustrates how plaintext authentication is used for routing updates.
The following steps are carried out:
A router sends a routing update with a key and the corresponding key number to the neighbor router. For protocols that can have only one key, the key number is always zero.
The receiving (neighbor) router checks the received key against the same key stored in its own memory.
If the two keys match, the receiving router accepts the routing update and incorporates the route information into its routing tables. If the two keys do not match, the routing update is rejected.
MD5 authentication works similarly to plaintext authentication, except that the key is never sent over the wire. Instead, the router uses the combination of a shared secret key and the routing update as input to the MD5 algorithm to produce a message digest (also called a hash). The shared secret between the sending and receiving routers must typically be manually preconfigured. Figure 4-2 illustrates the sequence of events involved for routing protocol authentication for the originating router.
The preconfigured shared secret and the routing update are the input to the MD5 algorithm, which results in a message digest (hash). This message digest is appended to the routing update packet and sent out the appropriate interface.
Figure 4-3 illustrates the sequence of events for routing protocol authentication at the destination router.
The receiving router takes the routing update and, along with its preconfigured shared secret, uses this as input to the MD5 algorithm to produce a message digest. If this new digest matches the one that was received, the neighbor is authenticated and the routing update is incorporated into the router's routing table.
It is possible to use IPsec to protect your routing protocol infrastructure. This would give the added benefits of confidentiality and replay protection. In most cases, the overhead involved in configuring IPsec for routing protocols far outweighs any practical benefits. It is more important that no one sends or spoofs routing updates. Therefore, IPsec is not commonly used to further protect routing updates because all routing protocols have extensions built in to address the authentication piece.
It is widely thought that in current routing infrastructures, confidentiality is not a major issue; and in all routing protocols themselves, there have been no extensions provided for confidentiality. As noted later in this chapter, however, some routing protocols that have working documents for IPv6 specify using IPsec as their inherent security mechanism.
Although all routing protocols generally implement neighbor authentication in a similar manner, there are some differences in each. This section provides more detail on each routing protocol, first describing an overview of the protocol and then detailing how the neighbor authentication is incorporated into each protocol. In addition, it describes the current work in progress for any additional security functionality for the various routing protocols, if it exists. The reader is encouraged to track these ongoing efforts in the particular working groups in the routing area of the Internet Engineering Task Force (IETF), which is located at http://ietf.org/html.charters/wg-dir.html.
Some people think that RIP is obsolete, given that other IGPs are more robust and flexible. However, RIP does have some advantages over newer IGP routing protocols such as OSPF, IS-IS, and EIGRP. Primarily, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time. RIP is also very easy to implement, especially in relation to the newer IGPs. RIP was designed to work with moderate-size networks using reasonably homogeneous technology. Therefore, it is suitable as an IGP for many campuses and for regional networks using serial lines whose speeds do not vary widely. It is not intended for use in more complex environments.
RFC 1058 details the original RIP specification. RIPv1 is a distance vector protocol that uses User Datagram Protocol (UDP), port 520, as its transport protocol. Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all the destinations within the system. Generally, information about all entities connected to one network is summarized by a single entry, which describes the route to all destinations on that network.
Every routing entity keeps a routing database with one entry for every possible destination in the system. Each entry in the RIP routing database includes the following about each destination:
Address—. The IP address of the host or network. RIP is used to convey information about routes to destinations, which may be individual hosts, networks, or a special destination used to convey a default route. (The special address 0.0.0.0 is used to describe a default route. A default route is used when it is not convenient to list every possible network in the RIP updates, and when one or more closely connected gateways in the system are prepared to handle traffic to the networks that are not listed explicitly.)
Router—. The first next-hop router along the route to the destination.
Interface—. The physical network that must be used to reach the first next-hop router.
Metric—. A number indicating the distance to the destination. RIP uses a metric referred to as hop count that just counts how many routers a message must go through to reach its final destination. For individual hops, this metric is represented as the sum of “costs” for individual hops.
Timer—. The amount of time since the entry was last updated.
Information is only exchanged among entities that are adjacent—that is, entities that share a common network. As a default, the routing update exchange occurs every 30 seconds, with provisions to ensure that synchronization does not occur. The exchange can also be triggered by a routing table update.
The RIP protocol makes no formal distinction between networks and hosts. It just describes the exchange of information about destinations, which may be either networks or hosts. If every host on a given network or subnet is accessible through the same routers, there is no reason to mention individual hosts in the routing tables. However, networks that include point-to-point lines sometimes require routers to keep track of routes to certain hosts. Whether this feature is required depends on the addressing and routing approach used in the system. Therefore, some implementations may choose not to support host routes. If host routes are not supported, they are to be dropped when they are received in response messages.
Each entity that participates in the routing scheme sends update messages that describe the routing database as it currently exists in that entity. For the protocol to provide complete information on routing, every router in the system must participate in it. However, provisions in the protocol allow silent RIP processes. A silent process is one that normally does not send out any messages. However, it listens to messages sent by others. This would allow for an entity to maintain a routing table without participating in the routing process itself.
Figure 4-4 shows the packet format.
The first four octets of a RIP message contain the RIP header. Several values of the Command field had been defined in the initial implementations, but effectively RIP is supposed to consider only two of them: a request code of value 1 and a response code of value 2. The Version field is set to 1. The remainder of the message is composed of 1 to 25 route entries (20 octets each). The intent of RIPv1 was to carry routing information for several different protocols. Therefore, each entry has an Address Family Identifier to indicate what type of address is specified in that entry. The Address Family Identifier for IP is 2. The IP address is the usual IP address, stored as four octets in network order. The address portion was meant to be extensible for other protocols that used a larger address space; in practice, however, RIP has not been used to support protocols other than IP. The Metric field must contain a value between 1 and 15, inclusive, specifying the current metric for the destination, or the value 16, which indicates that the destination is not reachable. Each route sent by a gateway supersedes any previous route to the same destination from the same gateway.
The maximum datagram size is 512 octets. This includes only the portions of the datagram previously described. It does not count the IP or UDP headers.
Entities that use RIP are assumed to use the most specific information available when routing a datagram. That is, when routing a datagram, its destination address must first be checked against the list of host addresses. Then it must be checked to see whether it matches any known subnet or network number. Finally, if none of these matches, the default route is used.
RFC 1723 defines RIPv2, which provides extensions to the message format to allow routers to share important additional information. Because the RIPv1 packet format had a number of Must Be Zero fields, these fields were modified in RIPv2 to add more enhanced routing functionality. Figure 4-5 shows the new RIPv2 packet.
One significant improvement RIPv2 offers over RIPv1 is the addition of an authentication mechanism. Essentially, it is the same extensible mechanism provided by OSPF, described in a later section. In RFC 1723, only a plaintext password is defined for authentication. However, more sophisticated authentication schemes can easily be incorporated into RIPv2 as they are defined. A cryptographic authentication scheme was defined in RFC 2082.
Because authentication is a per-message function, and because any reasonable authentication scheme requires more than the two-octet field available in the message header, the authentication scheme for RIPv2 uses the space of an entire RIP entry. If the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, the remainder of the entry contains the authentication key. This means that there can be, at most, 24 RIP entries in the remainder of the message. If authentication is not in use, no entries in the message should have an Address Family Identifier of 0xFFFF. Figure 4-6 illustrates the RIPv2 packet format when plaintext authentication is used.
The format of the authentication option was carefully chosen to maximize compatibility. Because an authentication entry is marked with an Address Family Identifier of 0xFFFF, a RIPv1 system would skip this entry because it would belong to an address family other than IP, and proceed with the 24 remaining entries. Note, therefore, that use of authentication will not prevent RIPv1 systems from seeing RIPv2 messages.
If a router is not configured to authenticate RIPv2 messages, RIPv1 and unauthenticated RIPv2 messages will be accepted; authenticated RIPv2 messages will be discarded. If the router is configured to authenticate RIPv2 messages, RIPv1 messages and RIPv2 messages that pass authentication testing will be accepted; unauthenticated and failed authentication RIPv2 messages will be discarded. In many routers, an administrator can mandate authentication of all packets and request that the RIP process ignore any unauthenticated messages.
A cryptographic authentication mechanism for RIPv2 is defined in RFC 2082. Keyed MD5 is proposed as the standard authentication algorithm, but the mechanism is intended to be algorithm independent.
The basic RIPv2 message format provides for an 8-byte header with an array of 20-byte records as its data content. When keyed MD5 is used, the same header and content are used, except that the 16-byte Authentication Key field is reused to describe a Keyed Message Digest trailer, as illustrated in Figure 4-7.
RIPv2 MD5 authentication uses the following fields:
The authentication type is Keyed Message Digest algorithm, indicated by the value 3. (1 and 2 indicate IP route and plaintext password, respectively.)
A 16-bit offset from the RIPv2 header to the MD5 digest (if no other trailer fields are ever defined; this value equals the RIPv2 data length).
An unsigned 8-bit field that contains the key identifier or key ID. This identifies the key used to create the authentication data for this RIPv2 message. A key is associated with an interface.
An unsigned, 8-bit field that contains the length in octets of the trailing Authentication Data field. The presence of this field permits other algorithms (for instance, Keyed Secure Hash Algorithm [SHA]) to be substituted for keyed MD5 if desired.
An unsigned, 32-bit sequence number. The sequence number is nondecreasing for all messages sent with the same key ID.
The authentication data, which is the output of the Keyed Message Digest algorithm. When the authentication algorithm is keyed MD5, the output data is 16 bytes.
During digest calculation, the authentication data is effectively followed by a Pad field and a Length field as defined by RFC 1321. The trailing pad is not actually transmitted, because it is entirely predictable from the message length and algorithm in use. Figure 4-8 illustrates the trailer that is kept in memory and is appended by the MD5 algorithm and treated as though it were part of the message.
The RIPv2 authentication key is selected by the sender based on the outgoing interface. Each key has a lifetime associated with it, and no key is ever used outside its lifetime. The following steps depict what happens at the sending router to generate an authenticated RIP update:
The Authentication Data Offset, Key Identifier, and Authentication Data size fields are appropriately filled in.
The 16-byte keyed MD5 RIPv2 authentication key is appended to the data. For all algorithms, the RIPv2 authentication key is never longer than the output of the algorithm in use.
The trailing Pad and Length fields are added and the digest calculated using the indicated algorithm. When keyed MD5 is the algorithm in use, these are calculated per RFC 1321.
The digest is written over the RIPv2 authentication key. When MD5 is used, this digest is 16 bytes long.
There is also a trailing pad as previously shown. This is not actually transmitted, because it is entirely predictable from the message length and algorithm in use.
When the message is received, the process is reversed:
The digest is kept in memory.
The appropriate algorithm and key are determined from the value of the Key Identifier field.
The RIPv2 authentication key is written into the appropriate number of bytes starting at the indicated offset. With keyed MD5, 16 bytes are used.
Appropriate padding is added as needed, and then a new digest is calculated using the indicated algorithm.
If the calculated digest does not match the received digest, the message is not processed and is discarded. If the neighbor has been heard from recently enough to have viable routes in the route table and the received sequence number is less than the last one received, the message is also discarded unprocessed.
The RIPv2 MD5 authentication specification also has a number of key management requirements:
Storage of more than one key at the same time, although it is recognized that only one key will normally be active on an interface.
Associate a specific lifetime (that is, date/time first valid and date/time no longer valid) and a key identifier with each key.
Support manual key distribution (for instance, the privileged user manually typing in the key, key lifetime, and key identifier on the router console).
Keys that are out of date can be deleted at will by the implementation without requiring human intervention. Manual deletion of active keys can also be supported.
When updating the RIP routers with new keys, a smooth rollover can be ensured if network administrators update all communicating RIPv2 systems with the new key several minutes before the current key expires and several minutes before the new key lifetime begins. The new key should have a lifetime that starts several minutes before the old key expires. This gives time for each system to learn of the new RIPv2 authentication key before that key will be used. It also ensures that the new key will begin being used and the current key will go out of use before the current key's lifetime expires. For the duration of the overlap in key lifetimes, a system may receive messages using either key and authenticate those messages. The key ID in the received message is used to select the appropriate key for authentication.
The specification also recommends that implementations not revert to unauthenticated conditions in the event that the last key associated with an interface expires. It suggests that the router should send a “last authentication key expiration” notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
NOTE
It is prudent to check how a particular vendor actually implements key sequence number rollover and key persistence in the event of device or routing failures.
It is strongly desirable to use a key management protocol to distribute RIPv2 authentication keys among communicating RIPv2 implementations. However, an integrated key management protocol technique was deliberately omitted from the RIPv2 MD5 specification because at the time of the writing of the specification there did not exist a robust enough key management protocol. At the time of this writing, this perception has not changed.
RIPng (RIP next generation) for IPv6 is specified in RFC 2080. The main goal was to make the minimum necessary changes to RIPv2 to support IPv6 networks. With RIPng, a smaller, simpler, distance vector protocol can be used in environments that require authentication or the use of variable-length subnet masks, but that are not of a size or complexity that would require the use of a larger, more complex, link-state protocol.
In essence, the IPv4 address was expanded into an IPv6 address, the IPv4 subnet mask was replaced with an IPv6 prefix length, the Next Hop field was eliminated but the functionality has been preserved, and the Route Tag field has been preserved. Authentication was removed. The maximum diameter of the network (the maximum metric value) is 15; 16 still means infinity (unreachable).
The basic RIP header is unchanged. However, the size of a routing packet is no longer arbitrarily limited. Because routing updates are never forwarded, the routing packet size is now determined by the physical media and the sizes of the headers that precede the routing data (that is, media maximum transmission unit [MTU] minus the combined header lengths). The number of routes that may be included in a routing update is the routing data length divided by the size of a routing entry.
Authentication, which was added to RIPv2 because RIPv1 did not have it, has been dropped from RIPng. It just specifies that because RIPng runs over IPv6, IPsec authentication header (AH) and Encapsulating Security Payload (ESP) will be used to provide the necessary integrity and authentication/confidentiality of routing exchanges.
The Enhanced Interior Gateway Protocol (EIGRP) is a Cisco proprietary routing protocol, referred to as an advanced distance vector protocol. It integrates the capabilities of link-state protocols into distance vector protocols. Traditional distance vector protocols such as RIP exchange periodic routing updates with all their neighbors, saving the best metric and the next hop for each destination. EIGRP differs in that it saves not only the least-cost route but up to eight routes to a destination. Further, EIGRP updates are sent only upon a network topology change; updates are not periodic.
EIGRP uses the following key technologies:
Neighbor discovery/recovery
Reliable Transport Protocol (RTP)
The DUAL finite-state machine
The neighbor discovery/recovery mechanism enables routers to dynamically learn about other routers on their directly attached networks and to discover when their neighbors become unreachable or inoperative. This process is achieved by periodically sending small hello packets. As long as a router receives hello packets from a neighboring router, it assumes that the neighbor is functioning, and the two can exchange routing information.
Reliable Transport Protocol (RTP) is used for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast or unicast packets. All transmissions use IP with the protocol type field set to 88. The IP multicast address used is 224.0.0.10. For efficiency, only certain EIGRP packets are transmitted reliably. On a multiaccess network that has multicast capabilities, such as Ethernet, it is not necessary to send hello packets reliably to all neighbors individually. For that reason, EIGRP sends a single multicast hello packet containing an indicator that informs the receivers that the packet need not be acknowledged. Other types of packets, such as updates, indicate in the packet that acknowledgment is required. Neighbors acknowledge the receipt of updates; and if an acknowledgment is not received, EIGRP retransmits the update. RTP contains a provision for sending multicast packets quickly when unacknowledged packets are pending, which helps ensure that convergence time remains low in the presence of varying speed links.
The Diffusing Update algorithm (DUAL), developed at SRI International by Dr. J. J. Garcia-Luna-Aceves, embodies the decision process for all route computations by tracking all routes advertised by all neighbors. DUAL uses distance information to select efficient, loop-free paths and selects routes for insertion in a routing table based on feasible successors. A feasible successor is a neighboring router used for packet forwarding that is a least-cost path to a destination that is guaranteed not to be part of a routing loop. When a neighbor changes a metric, or when a topology change occurs, DUAL tests for feasible successors. If one is found, DUAL uses it to avoid recomputing the route unnecessarily. When no feasible successors exist but neighbors still advertise the destination, a recomputation (also known as a diffusing computation) must occur to determine a new successor. DUAL requires guaranteed and sequenced delivery for some transmissions. This is achieved using acknowledgments and sequence numbers. So, for example, update packets (containing routing table data) are delivered reliably (with sequence numbers) to all neighbors using multicast. Acknowledgment packets—with the correct sequence number—are expected from every neighbor. If the correct acknowledgment number is not received from a neighbor, the update is retransmitted as a unicast.
EIGRP relies on neighbor tables, topology tables, route states, and route tagging. Each of these is summarized in the following sections.
When a router discovers a new neighbor, it records the neighbor's address and interface as an entry in the neighbor table. One neighbor table exists for each protocol-dependent module. When a neighbor sends a hello packet, it advertises a hold time, which is the amount of time that a router treats a neighbor as reachable and operational. If a hello packet is not received within the hold time, the hold time expires and DUAL is informed of the topology change.
The neighbor table entry also includes information required by RTP. Sequence numbers are used to match acknowledgments with data packets, and the last sequence number received from the neighbor is recorded so that out-of-order packets can be detected. A transmission list is used to queue packets for possible retransmission on a per-neighbor basis. Round-trip timers are kept in the neighbor table entry to estimate an optimal retransmission interval.
The topology table contains all destinations advertised by neighboring routers. The protocol-dependent modules populate the table, and the table is acted on by the DUAL finite-state machine. Each entry in the topology table includes the destination address and a list of neighbors that have advertised the destination. For each neighbor, the entry records the advertised metric, which the neighbor stores in its routing table. An important rule that distance vector protocols must follow is that if the neighbor advertises this destination, it must use the route to forward packets.
The metric that the router uses to reach the destination is also associated with the destination. The metric that the router uses in the routing table, and to advertise to other routers, is the sum of the best-advertised metric from all neighbors and the link cost to the best neighbor.
A topology table entry for a destination can exist in one of two states: active or passive. A destination is in the passive state when the router is not performing a recomputation; it is in the active state when the router is performing a recomputation. If feasible successors are always available, a destination never has to go into the active state, thereby avoiding a recomputation.
A recomputation occurs when a destination has no feasible successors. The router initiates the recomputation by sending a query packet to each of its neighboring routers. The neighboring router can send a reply packet, indicating that it has a feasible successor for the destination, or it can send a query packet, indicating that it is participating in the recomputation. While a destination is in the active state, a router cannot change the destination's routing table information. After the router has received a reply from each neighboring router, the topology table entry for the destination returns to the passive state, and the router can select a successor.
EIGRP supports internal and external routes. Internal routes originate within an EIGRP autonomous system. Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the EIGRP autonomous system. External routes are learned by another routing protocol or reside in the routing table as static routes. These routes are tagged individually with the identity of their origin.
EIGRP uses the following packet types:
Hello and acknowledgment
Update
Query and reply
Hello packets are multicast for neighbor discovery/recovery and do not require acknowledgment. An acknowledgment packet is a hello packet that has no data. Acknowledgment packets contain a nonzero acknowledgment number and always are sent by using a unicast address. Neither hellos nor acknowledgments are sent reliably.
Update packets are used to convey reachability of destinations. When a new neighbor is discovered, unicast update packets are sent so that the neighbor can build up its topology table. In other cases, such as a link-cost change, updates are multicast. Updates always are transmitted reliably.
Query and reply packets are sent when a destination has no feasible successors. Query packets are always multicast. Reply packets are sent in response to query packets to instruct the originator not to recompute the route because feasible successors exist. Reply packets are unicast to the originator of the query. Both query and reply packets are transmitted reliably.
EIGRP supports only keyed MD5 cryptographic checksums to provide authentication of routing updates. Each key has its own key identifier, which is stored locally. The combination of the key identifier and the interface associated with the message uniquely identifies the authentication algorithm and MD5 authentication key in use.
EIGRP MD5 authentication supports multiple keys with lifetimes. Only one authentication packet is sent, regardless of how many valid keys exist. The key numbers are examined in order from lowest to highest, and EIGRP MD5 authentication uses the first valid key it encounters.
OSPFv2, defined in RFC 2328, is a link-state routing protocol that is designed to be run internal to a single autonomous system. In a link-state routing protocol, each router maintains a database describing the autonomous system's topology. This database is referred to as the link-state database. Each participating OSPF router has an identical database. Each individual piece of this database is a particular router's local state (for instance, the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the autonomous system by flooding.
All routers run the exact same algorithm (the Dijkstra algorithm), in parallel. From the link-state database, each router constructs a routing table that is calculated by constructing a shortest-path first (SPF) tree, with itself as root. This SPF tree gives the route to each destination in the autonomous system. When several equal-cost routes to a destination exist, traffic is distributed equally among them. The cost of a route is described by a single dimensionless metric.
OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of an area is hidden from the rest of the autonomous system. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network.
OSPF enables the flexible configuration of IP subnets. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (that is, different subnet masks). This is commonly referred to as variable-length subnetting. A packet is routed to the best (that is, longest or most specific) match. Host routes are considered to be subnets whose masks are “all 1s” (0xffffffff).
All OSPF protocol exchanges are authenticated. This means that only trusted routers can participate in the autonomous system's routing. A variety of authentication schemes can be used; in fact, separate authentication schemes can be configured for each IP subnet.
Externally derived routing data (for example, routes learned from another IGP or an EGP such as BGP) is advertised throughout the autonomous system. This externally derived data is kept separate from the OSPF protocol's link-state data. Each external route can also be tagged by the advertising router, enabling the passing of additional information between routers on the boundary of the autonomous system.
All OSPF protocol exchanges are authenticated. The OSPF packet header illustrated in Figure 4-9 includes an Authentication Type field, and 64 bits of data for use by the appropriate authentication scheme.
Most fields within this common header have obvious meanings. The version number is set to 2 to indicate OSPFv2 and the type is the OSPF packet type (hello, database description, link-state request, link-state update, and link-state acknowledgment). The packet length is the number of bytes in the packet. The router ID is the IP address selected for identifying the router, and the area ID is the identification of the area. The value zero is reserved for the backbone area. It is common practice to choose an IP network number for identifying an area. The checksum is computed over the whole OSPF packet, excluding the 8-byte Authentication field.
The Authentication Type field identifies the authentication algorithm. Three values are defined in the RFC 2328 standard: null authentication, simple password authentication, and cryptographic authentication. The authentication type is configurable on a per-interface (or equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis.
Use of the null authentication type means that routing exchanges over the network/subnet are not authenticated. The 64-bit Authentication field in the OSPF header can contain anything; it is not examined on packet reception. When null authentication is used, the entire contents of each OSPF packet (other than the 64-bit Authentication field) are checksummed to detect data corruption.
Using the simple password authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit Authentication field. This essentially serves as a “clear” 64-bit password. In addition, the entire contents of each OSPF packet (other than the 64-bit Authentication field) are checksummed to detect data corruption.
Plaintext authentication uses a shared secret key known to all the routers on the network segment. When a sending router builds an OSPF packet, it signs the packet by placing the key as plaintext in the OSPF header. The receiving router then compares the received key against the key in memory. If the keys match, the router accepts the packet. Otherwise, the router rejects the packet.
NOTE
Simple password authentication guards against routers inadvertently joining the routing domain; each router must first be configured with its attached networks' passwords before it can participate in routing. However, simple password authentication is vulnerable to passive attacks where anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain.
In cryptographic authentication, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a “message digest” that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Because the secret key is never sent over the network in the clear, protection is provided against passive attacks where intruders can eavesdrop on a network.
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. Most implementations use the MD5 algorithm.
To protect against replay attacks, a nondecreasing sequence number is included in each OSPF protocol packet. This provides long-term protection; however, it is still possible to replay an OSPF packet until the sequence number changes. To implement this feature, each neighbor data structure contains a new field called the Cryptographic Sequence Number. This field is initialized to zero, and is also set to zero whenever the neighbor's state transitions to “down.” Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number. Because the cryptographic sequence number field is 32 bits in length, rollover issues should not be a problem unless a vendor has a particularly poor implementation.
When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined, as illustrated in Figure 4-10.
The new field definitions are as follows:
Key ID—. Identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key identifiers are unique per interface (or equivalently, per subnet).
Auth Data Length—. The length in bytes of the message digest appended to the OSPF packet.
Cryptographic Sequence Number—. An unsigned, 32-bit nondecreasing sequence number; used to guard against replay attacks.
The message digest is not included in the OSPF header's packet length because it is not considered part of the OSPF protocol packet. However, it is included in the packet's IP header Length field.
Each key is identified by the combination of interface and key ID. An interface may have multiple keys active at any one time to enable smooth transition from one key to another. Each key has four time constants associated with it. These time constants can be expressed in terms of a time-of-day clock or in terms of a router's local clock (for instance, number of seconds since last reboot).
KeyStartAccept—. The time that the router will start accepting packets that have been created with the given key.
KeyStartGenerate—. The time that the router will start using the key for packet generation.
KeyStopGenerate—. The time that the router will stop using the key for packet generation.
KeyStopAccept—. The time that the router will stop accepting packets that have been created with the given key.
The OSPFv2 specification states that keys should persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is not acceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a “last authentication key expiration” notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
The OSPF Working Group in the IETF is working on specifications for using OSPF in IPv6 networks, and their work may at some point evolve into a standard. This work is still in progress, but for completeness, the most recent proposal is detailed in this section. Be aware that some of the information could change; therefore, you should track this effort by referring to the documents in progress in the OSPF Working Group.
OSPFv2 is a specification only for IPv4 networks. OSPFv3 is the protocol defined for IPv6 networks. The current proposal for providing inherent security to OSPFv3 requires the use of the AH/ESP extension headers (that is, IPsec). All OSPFv3 packets must be authenticated using either AH or ESP and confidentiality can be used as an option.
OSPFv3 requires transport mode security associations to be used because the protocol packets are exchanged between routers that act like end hosts. ESP with NULL encryption in transport mode is required, which will provide authentication to only higher-layer protocol data and not to the IPv6 header, extension headers, and options. AH in transport mode can optionally be provided and will provide authentication to higher-layer protocols, selected portions of the IPv6 header, selected portions of extension headers, and selected options. OSPF packets received in clear text or received with an incorrect AH integrity check value are required to be dropped when authentication is enabled.
Providing confidentiality to OSPFv3 in addition to authentication is optional. Confidentiality, if provided, must use the ESP extension header of IPv6. It is required that ESP with non-NULL encryption in transport mode be used when providing confidentiality to OSPFv3.
HMAC-MD5-96 must be implemented as the authentication algorithm and DES-CBC must be implemented as the encryption algorithm.
OSPFv3 exchanges both multicast and unicast packets. While running OSPFv3 over a broadcast interface, the authentication/confidentiality required is “one to many.” Because Internet Key Exchange (IKE) is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required “one to many” authentication/confidentiality. Manual keying is required to be used for this purpose. In manual keying, security associations (SAs) are statically installed on the routers, and these static SAs are used to encrypt/authenticate the data.
Because SAs are directional, different security associations are generally used for inbound and outbound processing for providing higher security. To provide the “one-to-many” security, however, the same security associations need to be used for both inbound and outbound processing.
IS-IS for use in TCP/IP environments is defined in RFC 1195. The protocol design is based on the OSI intradomain IS-IS routing protocol defined in “Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473),” ISO DP 10589, February 1990. In the early 1990s, some people thought that OSI and TCP/IP would coexist and this protocol provided for a means to accomplish “integrated” routing where IS-IS would be the single routing protocol to simultaneously provide an efficient routing protocol for TCP/IP and OSI environments. However, OSI has become a historical artifact, and IS-IS is primarily used as an IGP in TCP/IP only environments.
The integrated IS-IS is a dynamic routing protocol, based on the SPF (Dijkstra) routing algorithm. Similar to OSPF, it is a link-state protocol where each router maintains a database describing the autonomous system's topology. This database is referred to as the link-state database. Each participating IS-IS router has an identical database. Each individual piece of this database is a particular router's local state (for instance, the router's usable interfaces and reachable neighbors). The router distributes its local state throughout the autonomous system by flooding.
All routers run the exact same algorithm (the Dijkstra algorithm), in parallel. From the link-state database, each router constructs a routing table that is calculated by constructing a shortest-path tree (SPF) with itself as root. This shortest-path tree gives the route to each destination in the autonomous system. When several equal-cost routes to a destination exist, traffic is distributed equally among them.
The IP address structure allows networks to be partitioned into subnets, and allows subnets to be recursively subdivided into smaller subnets. IS-IS does not require any specific relationship between IP addresses and the area structure. This was a conscious decision on behalf of the protocol designers because in many cases it was believed that the routers would be installed into existing environments, which already had assigned IP addresses. In addition, even if IP addresses were not already pre-assigned, the address limitations of IP constrain what addresses may be assigned. However, greater efficiency and scaling of the routing algorithm can be achieved if there is some correspondence between the IP address assignment structure and the area structure.
IS-IS routing makes use of two-level hierarchical routing. A routing domain is partitioned into areas. Within an area, level 1 routers exchange link-state packets (LSPs), which identify the IP addresses reachable by each router. Specifically, zero or more [IP address, subnet mask, metric] combinations may be included in each LSP. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations, which are reachable on each interface. A level 1 router routes as follows:
If a specified destination address matches an [IP address, subnet mask, metric] combination reachable within the area, the packet is routed via level 1 routing.
If a specified destination address does not match any [IP address, subnet mask, metric] combination listed as reachable within the area, the packet is routed toward the nearest level 2 router.
An area (and by implication a routing domain) may simultaneously make use of a variety of different address masks for different subnets in the area (or domain). Generally, if a specified destination address matches more than one [IP address, subnet mask] pair, the more specific address is the one routed toward (the one with more 1 bits in the mask; this is known as best-match routing).
Level 1 routers maintain the topology within the area, and can route directly to IP destinations within the area. However, IP-capable level 1 routers do not maintain information about destinations outside of the area. Traffic to destinations outside of the area is forwarded to the nearest level 2 router. Because IP routes to subnets, rather than to specific end systems, IP routers do not need to keep nor distribute lists of IP host identifiers. (Note that routes to hosts can be announced by using a subnet mask of all 1s.)
Level 2 routers include in their level 2 LSPs a complete list of [IP address, subnet mask, metric] combinations specifying all IP addresses reachable in their area. This information may be obtained from a combination of the level 1 LSPs (obtained from level 1 routers in the same area), or by manual configuration. In addition, level 2 routers may report external reachability information, corresponding to addresses that can be reached via routers in other routing domains (autonomous systems).
Default routes may be announced by use of a subnet mask containing all 0s. Default routes should be used with great care, because they can result in “black holes.” Default routes are permitted only at level 2 as external routes (that is, included in the IP External Reachability Information field). Default routes are not permitted at level 1.
The integrated IS-IS has a provision for carrying authentication information in all IS-IS packets. This is extensible to multiple authentication mechanisms. However, the use of this field is optional.
An Authentication field in the IS-IS header allows each IS-IS packet to contain information used to authenticate the originator and contents of the packet. This field is used to authenticate the entire packet, including the IP headers. If a router is configured to use authentication and a packet is received that contains invalid authentication information, the entire packet is discarded. If an IS-IS packet is split into multiple packets, each is authenticated independently.
Use of the Authentication field is optional. Routers are not required to be able to interpret authentication information. If a router is not configured to use authentication, it ignores any Authentication field that may be present in an IS-IS packet.
The IS-IS header is shown in Figure 4-11.
The authentication information is encoded as a type-length-value (TLV) tuple. The type of the TLV is specified as 10. The length of the TLV is variable. The value of the TLV depends on the authentication algorithm and related secrets being used. The first octet of the value is used to specify the authentication type. Type 0 is reserved, type 1 indicates a cleartext password, and type 255 is used for routing domain private authentication methods. The remainder of the TLV value is known as the authentication value. Currently, the only defined mechanism in the IS-IS protocol specification is a simple password, transmitted in the clear without encryption.
NOTE
The use of a simple password does not provide useful protection against intentional misbehavior. Rather, this should be thought of as a weak protection against accidental errors such as inadvertent misconfiguration.
Using this authentication type, a variable-length password is passed in the clear (that is, not encrypted) in the Authentication Information field.
The password can be configured on a per-link, per-area, and per-domain basis. Specifically, when the simple password form of authentication is used
IS-IS hello packets contain the per-link password.
Level 1 LSPs contain the per-area password.
Level 2 LSPs contain the per-domain password.
Level 1 sequence number packets contain the per-area password.
Level 2 Sequence number packets contain the per-domain password.
Each of the three passwords is configured with a transmit password, whose value is a single password, and receive passwords, whose value is a set of passwords. The transmit password value is always transmitted. However, any password contained in the receive password set will be accepted on receipt. This method allows the graceful changing of passwords without temporary loss of connectivity.
Because the use of cleartext passwords is not very secure, there is work in progress to define a more secure form of cryptographic authentication using the HMAC-MD5 algorithm.
Some of the following details could change, so you should keep up with any ongoing work in this area by following the work in the IS-IS Working Group in the IETF.
In this particular specification, which is widely implemented in many routers, the authentication type used for HMAC-MD5 is 54, the length of the authentication value for HMAC-MD5 is 16, and the Length field in the TLV is 17.
The HMAC-MD5 algorithm requires two parameters as input: a key K, which is the password for the packet type as specified in ISO 10589, and text T, which is the IS-IS packet to be authenticated (with the Authentication Value field inside the authentication information TLV set to 0). Before authentication is computed, the authentication type is set to 54 and the length of the TLV is set to 17. When LSPs are authenticated, the Checksum and Remaining Lifetime fields are set to zero before authentication is computed. The result of the algorithm is placed in the Authentication Value field.
If a router is configured to use the HMAC-MD5 authentication and receives authentication information, the router will not accept the IS-IS packet if the authentication value is incorrect. Also, to provide a mechanism to incrementally change passwords in a network, a set of passwords can be defined when verifying the authentication value, similar to the plaintext authentication scheme. This specification also has restrictions for implementations that prevent malicious users from initiating purges without knowing the authentication password.
NOTE
It is prudent to check how a particular vendor actually implements key sequence number rollover and key persistence in the event of device or routing failures.
This authentication mechanism does not prevent replay attacks; however, such attacks would trigger existing mechanisms in the IS-IS protocol that would effectively reject old information.
The HMAC-MD5 proposal is widely implemented in many routers. Changes to the authentication mechanism were considered, primarily to add a Key ID field such as in OSPFv2 and RIPv2. However, these were ultimately rejected because the improvement provided was not great enough to justify the change, given the installed base and lack of interest in deploying the proposed revised mechanism.
Future considerations for securing IS-IS include the following:
A different authentication mechanism that is designed for use with a key management protocol could be added if and when a key management protocol appears that is both widely implemented and easily deployed to secure routing protocols.
The use of a full digital signature if a stronger authentication were believed to be required. At this time, it is believed that the computational burden of full digital signatures is much higher than is reasonable given the current threat environment in operational commercial networks.
The Border Gateway Protocol version 4 (BGP-4) is specified in RFC 1771. It is a complex EGP whose primary function is to allow the exchange network reachability information with all BGP-speaking systems.
BGP uses TCP as its transport protocol, which eliminates the need to implement explicit update fragmentation, retransmission, acknowledgment, and sequencing. Any authentication scheme used by the transport protocol may be used in addition to BGP's own authentication mechanisms. The error notification mechanism used in BGP assumes that the transport protocol supports a “graceful” close—that is, all outstanding data will be delivered before the connection is closed.
Two BGP systems that want to communicate form a transport protocol connection (using TCP port 179) between one another. They exchange messages to open and confirm the connection parameters. The initial data flow is the entire BGP routing table. Incremental updates are sent as the routing tables change. BGP does not require periodic refresh of the entire BGP routing table. Therefore, a BGP speaker must retain the current version of the entire BGP routing tables of all of its peers for the duration of the connection. Keepalive messages are sent periodically to ensure the liveness of the connection. Notification messages are sent in response to errors or special conditions. If a connection encounters an error condition, a notification message is sent, and the connection is closed.
A BGP speaker advertises to its peers (other BGP speakers which it communicates with) in neighboring autonomous systems only those routes that it uses itself. Routing information exchanged via BGP supports only the destination-based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet.
A peer in a different autonomous system is referred to as an external peer, whereas a peer in the same autonomous system is referred to as an internal peer. Internal BGP and external BGP are commonly abbreviated IBGP and EBGP.
BGP is primarily used for routing in the Internet. Due to its complexity, more detailed specification is beyond the scope of this chapter. For a more complete description of BGP, refer to the book Internet Routing Architectures, Second Edition, by Sam Halabi (Cisco Press, 2000).
Authentication for BGP-4 is specified in RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option.
Every BGP-4 packet sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to these items in the following order:
The TCP pseudo-header (in the order of source IP address, destination IP address, zero-padded protocol number, and segment length)
The TCP header, excluding options, and assuming a checksum of zero
The TCP segment data (if any)
An independently specified key or password, known to both BGP speakers and presumably connection-specific
It is up to the TCP implementation in the BGP-speaking router to determine what the application can specify as the key.
Upon receiving a signed packet, the receiver must validate it by calculating its own MD5 digest from the same data (using its own key) and comparing the two digests. If the two digests match, the packet is processed; if they don't match, the packet is just dropped. The specification does remark that logging the failure is advisable.
In response to the increasing requirement of securing network infrastructures and the security limitations in existing routing protocols, the IETF has formed the Routing Protocols Security Requirements Working Group, to analyze security in routing systems, including BGP.
Several methods of securing the information carried within BGP have been proposed. Secure BGP (S-BGP) is based on work that was started as early as 1999 to produce a more secure BGP protocol. The Internet drafts produced in the ensuing years have since expired, although there are still some strong proponents for this protocol.
One of the major obstacles with S-BGP is that it requires the use of a public key infrastructure (PKI). This PKI is used to support the authentication of ownership of IP address blocks, ownership of autonomous system numbers, an autonomous system's identity, and a BGP router's identity and its authorization to represent an autonomous system. Although the intent is that the PKI parallels the IP address and autonomous system number assignment system and takes advantage of the existing infrastructure (Internet registries and so forth), in practice there are still many operational obstacles to overcome to create this trusted PKI.
S-BGP defines a new, optional, BGP transitive path attribute to carry digital signatures covering the routing information in a BGP routing update. These signatures along with certificates from the S-BGP PKI would enable the receiver of a BGP routing update to verify the address prefixes and path information that it contains. Also, S-BGP specifies that IPsec be used to provide data and partial sequence integrity, and to enable BGP routers to authenticate each other for exchanges of BGP control traffic.
S-BGP has not been widely deployed or implemented, and analysis on S-BGP has been limited. Keep in mind that the efforts to define this protocol are principally done with large Internet service provider networks in mind. To track ongoing efforts with S-BGP, go to http://www.net-tech.bbn.com/sbgp/sbgp-index.html.
In recent years, there has been another proposal to secure BGP, named Secure Origin BGP (SOBGP). Rather than require a huge infrastructure change, as with S-BGP, SOBGP only requires incremental changes to the BGP infrastructure. Unlike S-BGP, SOBGP mainly focuses on the origin of a route and not the entire BGP path. Signatures and certificates still need to be generated in the same way as for S-BGP, but the propagation of information differs. For SOBGP, instead of relying on an out-of-band database, the certificates are advertised using a new type of BGP message, the BGP security message.
How BGP and other routing protocols will be secured in the future and which proposals might become eventual Internet standards is still very much work in progress. Interested readers should follow the work in the IETF working group at http://www.ietf.org/html.charters/rpsec-charter.html.
This chapter covered some commonly used routing protocols and the built-in functionality that exists within each protocol to provide some measure of security. Each of the routing protocols discussed—RIP, EIGRP, OSPF, IS-IS, and BGP-4—has incorporated neighbor authentication that uses either a plaintext password or a cryptographic authentication scheme. The plaintext authentication should be avoided because it is inherently insecure. All protocols support a keyed MD5 algorithm for their cryptographic neighbor authentication scheme, and all users are encouraged to configure this feature in their routers. Because privacy is not thought to be a great concern in routing infrastructures, confidentiality concerns are not addressed. Most routing protocols that have work in progress to address IPv6 networks are relying on the inherent IPsec capabilities to provide for routing protocol authentication, integrity, and confidentiality.
The following questions provide you with an opportunity to test your knowledge of the topics covered in this chapter. You can find the answers to these questions in Appendix E, “Answers to Review Questions.”