Routing Protocol Authentication - Router and Routing Security - CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)

CCNP Routing and Switching ROUTE 300-101 Official Cert Guide (2015)

Part V. Router and Routing Security

Chapter 17. Routing Protocol Authentication

This chapter covers the following subjects:

Image Authentication Methods: This section contrasts different approaches to routing protocol authentication, including simple password authentication and hashing authentication. Routing protocol authentication can be used to prevent a malicious user from forming a neighborship between his router and a production router.

Image EIGRP Authentication: This section examines the operation and configuration of EIGRP authentication, including EIGRP for IPv4, EIGRP for IPv6, and Named EIGRP.

Image OSPF Authentication: Similar to the concepts presented in the preceding “EIGRP Authentication” section, this section demonstrates how to authenticate OSPF neighbor relationships, using a variety of approaches.

Image BGP Authentication: This section explains the threat of session hijacking in a BGP environment and demonstrates how to configure authentication between BGP peers.

Protocols such as Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OPSF), using multicasts, can dynamically form neighborships with adjacent routers. The ease with which neighborships can be formed is a concern from a security perspective.

For example, consider a malicious user that introduces his router into a network. If that router successfully forms one or more neighborships, that rogue router could inject false routing information into a corporate network, perhaps causing corporate data traffic to flow through the rogue router, thus allowing the malicious user to capture that traffic. To help mitigate such a situation, this short chapter begins with a comparison of authentication methods followed by a discussion of the operation and configuration of EIGRP and OSPF authentication.

Unlike the dynamic neighbor formation of EIGRP and OSPF, Border Gateway Protocol (BGP) requires neighbors to be statically configured. Therefore, the previous scenario of injecting a rogue router with the intent of manipulating routing tables is less likely with BGP. However, session hijacking can still occur, where a router takes over an existing TCP session between two routers that have already formed a BGP neighborship. Therefore, this chapter concludes with examples of BGP authentication, including IPv4 and IPv6 environments.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read the entire chapter. If you miss no more than one of these eight self-assessment questions, you might want to move ahead to the “Exam Preparation Tasks” section. Table 17-1 lists the major headings in this chapter and the “Do I Know This Already?” quiz questions covering the material in those headings so that you can assess your knowledge of these specific areas. The answers to the “Do I Know This Already?” quiz appear in Appendix A.

Image

Table 17-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Identify possible approaches that Cisco IOS uses to authenticate neighboring routers. (Choose two.)

a. Plain text authentication

b. Two-factor authentication

c. Hashing authentication

d. Biometric authentication

2. Two neighboring routers are each configured with a key chain. What element(s) of the key chain must match for the two routers to mutually authenticate? (Choose all that apply.)

a. Key chain name

b. Key number

c. Key string

d. Accept-lifetime

e. Send-lifetime

3. What types of neighbor authentication does Named EIGRP support? (Choose all that apply.)

a. Plain text authentication

b. MD5 hashing authentication

c. SHA hashing authentication

d. PAP authentication

4. What command can be used to view the configuration of a key chain used by EIGRP?

a. show key chain

b. show key-chain

c. show authentication key chain

d. show eigrp key chain

5. Routers R1 and R2 are both running OSPFv2, and they are currently authenticated with one another, using MD5, over their Fa 0/0 interfaces. Interface Fa 0/0 on Router R1 is participating in area 0. However, you notice that the OSPF router configuration on Router R1 does not contain the area 0 authentication message-digest command. What command must have been configured under Router R1’s Fa 0/0 interface?

a. area 0 authentication md5

b. ip ospf authentication message-digest

c. ip ospf authentication 0 md5

d. area 1 authentication message-digest

6. Identify the valid types of OSPFv3 authentication supported in Cisco IOS. (Choose all that apply.)

a. SHA

b. MD5

c. PAP

d. Clear text

7. BGP can use what type of authentication?

a. SHA

b. Clear text

c. MD5

d. DH Group 1

8. Because BGP neighborships require neighbors to be statically configured, what is the most likely approach that an attacker would take to inject a rogue router into a network and have that rogue router form a BGP neighborship with a production router?

a. Man-in-the-middle attack

b. Denial of service (DoS) attack

c. Session hijacking

d. Distributed DoS (DDoS) attack

Foundation Topics

Authentication Methods

Cisco routers support a couple of different approaches to authenticating route advertisements received from a neighboring router:

Image Plain text authentication

Image Hashing authentication

Both of these approaches require routers to have matching passwords (also referred to as keys); however, Cisco recommends the use of hashing authentication.

Plain text authentication, as the name suggests, simply sends a password from one router to another in clear text. This leads to the security concern of having a malicious user capture authentication traffic containing a password and then injecting her own router, which could use the compromised password to authenticate with one of the network’s production routers.

Hashing authentication is preferred over plain text authentication, because it never sends the password over the network. Instead, a mathematical algorithm is run on the password, and the result of that algorithm (called a hash digest) is sent from one router to its neighbor. That neighboring router also runs the hashing algorithm on its configured password, and if its hash digest matches the hash digest it receives from the first router, it can conclude that the passwords match.

The two hashing algorithms that you can select from (depending on the routing protocol) include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA). SHA is generally considered to be somewhat more secure than MD5; however, either algorithm is vastly superior to using plain text authentication.

Plain Text Authentication

The plain text authentication process follows a procedure that can generally be summarized as follows:

Step 1. A routing update is sent from one router to another. That routing update includes a key (that is, a password) and a key number, because some routing protocols support the configuration of multiple keys. Note that if a routing protocol does not support multiple keys, the key number associated with a routing update is 0.

Step 2. A neighboring router receives the routing update. That router determines whether the received key matches its configured key (with a matching key number).

Step 3. If the neighboring router determines that the keys match, it accepts the routing update. However, the routing update is rejected if the keys do not match.

The only routing protocols supported in Cisco IOS that you can configure with plain text authentication are

Image Routing Information Protocol version 2 (RIPv2)

Image Open Shortest Path First version 2 (OSPFv2)

Image Intermediate System–to–Intermediate System (IS-IS)

Hashing Authentication

The basic operation of hashing authentication bears some similarity to plain text authentication. Notably different, however, is how hashing authentication never transmits a key across a network, instead sending the hash digest (that is, the result of running a hashing algorithm on a router’s configured password).

The hashing authentication process follows a procedure that can generally be summarized as follows:

Image

Step 1. A hashing algorithm is run on a routing update along with a router’s configured key. The result of the hashing algorithm (that is, the hash digest) is added to the end of the routing update, which is then sent to a neighboring router.

Step 2. The neighboring router receives the update and runs a hashing algorithm on the routing update combined with its locally configured key, which results in a hash digest.

Step 3. If the locally configured hash digest matches the received hash digest, the receiving router accepts the packet. If the independently calculated hash digest values do not match, the update is rejected.

Hashing authentication using MD5 can be configured for the following protocols within Cisco IOS:

Image RIPv2

Image EIGRP

Image OSPFv2

Image OSPFv3

Image IS-IS

Image BGP

SHA authentication is supported by the following protocols:

Image RIP next generation (RIPng)

Image Named EIGRP

Image OSPFv2 (see note)

Image OSPFv3

Image IS-IS (see note)


Note

While RFC 5709 states that OSPFv2 can support SHA authentication, this feature is not widely deployed in Cisco IOS. Therefore, depending on your version of Cisco IOS, you might not have the option of configuring SHA authentication for OSPFv2. The same holds true for IS-IS (as described in RFC 5310).

Also note that RIPng and OSPFv3, used for routing in IPv6 networks, do not have any native authentication features. Instead, they rely on IPsec to handle their authentication.


Key Chains

Having two routers each configured with an identical key (called a shared secret key) is a basic requirement for routing protocol authentication. However, if that shared secret key were learned, that might permit a malicious user to introduce a rogue router into a network and have that router form one or more neighborships with existing routers. The probability that a shared secret key will be learned increases with time. Therefore, Cisco recommends that you frequently change your keys.

Fortunately, you can configure time-based key chains. A key chain is a collection of keys, each identified with a key ID, that is associated with an interface. A time-based key chain not only includes a collection of keys and key IDs, but it also includes key lifetimes. These lifetimes dictate the periods of time when a router will send a specific key and when a router will accept a specific key. The period of time during which a router will accept a specific key is called the accept lifetime, while the period of time during which a router will send a specific key is called the send lifetime.


Note

To make sure that there is never a period of time when no key is active, you should configure your key lifetimes to overlap. If a router sends an update at a time when multiple keys are active, the router uses the key with the lowest key ID.


To better understand the concept and configuration of time-based key chains, consider Example 17-1. This example shows the configuration for the two routers pictured in Figure 17-1.

Image

Figure 17-1 Two Routers Configured with Time-Based Key Chains

Image

Example 17-1 Time-Based Key Chain Configuration


!Configuration on Router R1
R1# conf term
R1(config)# key chain R1KEYCHAIN
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string PRIMARY_KEY
R1(config-keychain-key)# accept-lifetime 01:00:00 April 1 2014 01:00:00 May 2 2014
R1(config-keychain-key)# send-lifetime 01:00:00 April 1 2014 01:00:00 May 2 2014
R1(config-keychain-key)# exit
R1(config-keychain)# key 2
R1(config-keychain-key)# key-string SECONDARY_KEY
R1(config-keychain-key)# accept-lifetime 01:00:00 May 1 2014 infinite
R1(config-keychain-key)# send-lifetime 01:00:00 May 1 2014 infinite
R1(config-keychain-key)# end
R1#

!Configuration on Router R2
R2# conf term
R2(config)# key chain R2KEYCHAIN
R2(config-keychain)# key 1
R2(config-keychain-key)# key-string PRIMARY_KEY
R2(config-keychain-key)# accept-lifetime 01:00:00 April 1 2014 01:00:00 May 2 2014
R2(config-keychain-key)# send-lifetime 01:00:00 April 1 2014 01:00:00 May 2 2014
R2(config-keychain-key)# exit
R2(config-keychain)# key 2
R2(config-keychain-key)# key-string SECONDARY_KEY
R2(config-keychain-key)# accept-lifetime 01:00:00 May 1 2014 infinite
R2(config-keychain-key)# send-lifetime 01:00:00 May 1 2014 infinite
R2(config-keychain-key)# end
R2#


In Example 17-1, a key chain with a name of R1KEYCHAIN is created on Router R1. This key chain is then configured with two keys, key 1 and key 2. The value of the first key was set to PRIMARY_KEY, and the value of the second key was set to SECONDARY_KEY.

The configuration also specifies that the first key is valid, for both sending and receiving, for a time period beginning at 1:00 a.m. on April 1, 2014, and ending at 1:00 a.m. on May 2, 2014. The second key becomes valid, for both sending and receiving, at 1:00 a.m. on May 1, 2014, but theinfinite keyword in the accept-lifetime and send-lifetime commands means that when the second key becomes valid, it will stay valid indefinitely.

A nearly identical key chain configuration is then created for Router R2, with the only difference being the name of the key chain. On R2, the key chain name is R2KEYCHAIN.

In the example, key 1 stays valid for one day after key 2 becomes valid. Using overlapping time periods for key lifetimes helps ensure that there will not be a period of time when no key is valid.


Note

This key chain configuration will be used in the next section of this chapter.


EIGRP Authentication

EIGRP authentication causes routers to authenticate every EIGRP message. To do so, the routers should use the same preshared key (PSK) and generate an MD5 digest for each EIGRP message based on that PSK. If a router configured for EIGRP authentication receives an EIGRP message, and the message’s MD5 digest does not pass the authentication checking based on the local copy of the key, the router silently discards the message. As a result, when authentication fails, two routers cannot become EIGRP neighbors, because they ignore each other’s EIGRP Hello messages.

From a design perspective, EIGRP authentication helps prevent denial of service (DoS) attacks, but it does not provide any privacy. The device that physically receives the bits can read the EIGRP messages. Note that on LANs, the updates flow to the 224.0.0.10 multicast IP address, so any attacker could join the 224.0.0.10 multicast group and read the packets. However, authentication prevents attackers from forming neighborships with legitimate routers, thus preventing the advertisement of incorrect routing information.

This section examines EIGRP authentication configuration generically, followed by examples of authentication configurations for EIGRP for IPv4, EIGRP for IPv6, and Named EIGRP.

EIGRP for IPv4 Authentication

The EIGRP for IPv4 authentication configuration process requires a few steps, which are summarized as follows:

Image

Step 1. Create a key chain. (This procedure was discussed in the earlier section “Authentication Methods.”)

Step 2. Enable EIGRP MD5 authentication on an interface, for a particular EIGRP autonomous system number (ASN), using the ip authentication mode eigrp asn md5 interface subcommand.

Step 3. Refer to the correct key chain to be used on an interface using the ip authentication key-chain eigrp asn name-of-chain interface subcommand.

The configuration in Step 1 is fairly detailed, but Steps 2 and 3 are relatively simple. Essentially, Cisco IOS configures the key values separately (Step 1) and then requires an interface subcommand to refer to those key values. To support the capability to have multiple keys, and even multiple sets of keys, the configuration includes the concept of a key chain and multiple keys on each key chain.

To illustrate this configuration further, consider Example 17-2, which shows the configuration of the routers in Figure 17-2.

Image

Figure 17-2 Two Routers Configured with EIGRP for IPv4 Authentication

Image

Example 17-2 EIGRP for IPv4 Authentication Configuration


!Configuration on Router R1
key chain R1KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface Serial1/0
ip address 10.1.1.1 255.255.255.252
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 R1KEYCHAIN
!
router eigrp 1
network 0.0.0.0


!Configuration on Router R2
key chain R2KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface Serial1/0
ip address 10.1.1.2 255.255.255.252
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 R2KEYCHAIN
!
router eigrp 1
network 0.0.0.0


Example 17-2 builds on the key chain configuration shown in Example 17-1. Specifically, Router R1 has a key chain named R1KEYCHAIN, and Router R2 has a key chain named R2KEYCHAIN. In interface configuration mode for each of the routers, the ip authentication mode eigrpasn md5 command was issued for EIGRP autonomous system 1. Then, the ip authentication key-chain eigrp asn name-of-chain command was issued in interface configuration mode to specify which key chain the interface would use for its MD5 authentication.

The show key chain command can be used to view the details of any configured key chains. Also, you can issue the show ip eigrp neighbors command to confirm that expected EIGRP neighborships have been formed. Example 17-3 shows sample output from Router R1 and confirms that key 1 is currently valid.

Example 17-3 Verifying EIGRP for IPv4 Authentication


R1# show key chain
Key-chain R1KEYCHAIN:
key 1 -- text "PRIMARY_KEY"
accept lifetime (01:00:00 UTC Apr 1 2014) - (01:00:00 UTC May 2 2014) [valid
now]
send lifetime (01:00:00 UTC Apr 1 2014) - (01:00:00 UTC May 2 2014) [valid
now]
key 2 -- text "SECONDARY_KEY"
accept lifetime (01:00:00 UTC May 1 2014) - (infinite)
send lifetime (01:00:00 UTC May 1 2014) - (infinite)
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.1.2 Se1/0 12 01:01:05 79 474 0 7


EIGRP for IPv6 Authentication

Configuring authentication for EIGRP for IPv6 is nearly identical to configuring authentication for EIGRP for IPv4. The only difference is the ip authentication mode eigrp asn md5 and ip authentication key-chain eigrp asn name-of-chain commands have ip replaced with ipv6. These steps can be summarized as follows:

Image

Step 1. Create a key chain. (This procedure was discussed in the earlier section “Authentication Methods.”)

Step 2. Enable EIGRP MD5 authentication on an interface, for a particular EIGRP ASN, using the ipv6 authentication mode eigrp asn md5 interface subcommand.

Step 3. Refer to the correct key chain to be used on an interface using the ipv6 authentication key-chain eigrp asn name-of-chain interface subcommand.

Consider Example 17-4, based on the topology in Figure 17-3. Note how the configuration closely mirrors Example 17-2, which showed how to configure authentication for EIGRP for IPv4.

Image

Figure 17-3 Two Routers Configured with EIGRP for IPv6 Authentication

Image

Example 17-4 EIGRP for IPv6 Authentication Configuration


!Configuration on Router R1
key chain R1KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface Serial1/0
ipv6 address 2002::1/64
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 R1KEYCHAIN
!
ipv6 router eigrp 100
eigrp router-id 1.1.1.1


!Configuration on Router R2
key chain R2KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface Serial1/0
ipv6 address 2002::2/64
ipv6 eigrp 100
ipv6 authentication mode eigrp 100 md5
ipv6 authentication key-chain eigrp 100 R2KEYCHAIN
!
ipv6 router eigrp 100
eigrp router-id 2.2.2.2


In Example 17-4, the previously configured key chains were used to configure authentication for EIGRP for IPv6. The ipv6 authentication mode eigrp asn md5 and ipv6 authentication key-chain eigrp asn name-of-chain commands were issued in interface configuration mode, to make the interface authenticate any received EIGRP messages using the specified key chain for EIGRP autonomous system 100.

Example 17-5 shows how to verify your configuration. The show key chain command displays the details of the key chain, while the show ipv6 eigrp neighbors command confirms that a neighborship has formed.

Example 17-5 Verifying EIGRP for IPv6 Authentication


R1# show key chain
Key-chain R1KEYCHAIN:
key 1 -- text "PRIMARY_KEY"
accept lifetime (01:00:00 UTC Apr 1 2014) - (01:00:00 UTC May 2 2014) [valid
now]
send lifetime (01:00:00 UTC Apr 1 2014) - (01:00:00 UTC May 2 2014) [valid
now]
key 2 -- text "SECONDARY_KEY"
accept lifetime (01:00:00 UTC May 1 2014) - (infinite)
send lifetime (01:00:00 UTC May 1 2014) - (infinite)
R1# show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Se1/0 11 00:35:12 38 228 0 3
FE80::C801:17FF:FE94:0


Named EIGRP Authentication

The configuration of Named EIGRP authentication is very similar to the authentication configuration of EIGRP for IPv4. After configuring a key chain, you enter the authentication mode {md5 | hmac-sha-256} command in address family interface configuration mode. Finally, still in address family interface configuration mode, you enter the authentication key-chain name-of-chain command. Following are the steps:

Image

Step 1. Create a key chain.

Step 2. Enable authentication for Named EIGRP in address family interface configuration mode, using the command authentication mode {md5 | hmac-sha-256}.

Step 3. Refer to the correct key chain to be used, while still in address family interface configuration mode, with the command authentication key-chain name-of-chain.

Example 17-6 demonstrates the configuration of Named EIGRP authentication for the topology shown in Figure 17-4.

Image

Figure 17-4 Two Routers Configured with EIGRP for IPv6 Authentication

Image

Example 17-6 Named EIGRP Authentication Configuration


!Configuration on Router R1
key chain R1KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface Serial1/0
ip address 10.1.1.1 255.255.255.252
!
router eigrp AUTH_DEMO
!
address-family ipv4 unicast autonomous-system 2
!
af-interface Serial1/0
authentication mode md5
authentication key-chain R1KEYCHAIN
exit-af-interface
!
topology base
exit-af-topology
network 0.0.0.0
exit-address-family

!Configuration on Router R2
key chain R2KEYCHAIN
key 1
key-string PRIMARY_KEY
accept-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
send-lifetime 01:00:00 Apr 1 2014 01:00:00 May 2 2014
key 2
key-string SECONDARY_KEY
accept-lifetime 01:00:00 May 1 2014 infinite
send-lifetime 01:00:00 May 1 2014 infinite
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
interface Serial1/0
ip address 10.1.1.2 255.255.255.252
!
router eigrp AUTH_DEMO
!
address-family ipv4 unicast autonomous-system 2
!
af-interface Serial1/0
authentication mode md5
authentication key-chain R2KEYCHAIN
exit-af-interface
!
topology base
exit-af-topology
network 0.0.0.0
exit-address-family


Verification can be performed with the same show key chain and show ip eigrp neighbors command used for verifying a classic EIGRP for IPv4 configuration. Note that the authentication mode specified in Example 17-6 is md5. However, hmac-sha-256 is another supported authentication mode.

OSPF Authentication

OSPF authentication causes routers to authenticate every OSPF message. To do so, the routers use the same preshared key value. This key might be in plain text, or it might be a hash digest from either the MD5 hashing algorithms (although SHA might also be supported depending on the type and version of Cisco IOS you are running). Table 17-2 lists the authentication types supported by OSPF.

Image

Image

Table 17-2 OSPF Authentication Types

On a router, OSPF authentication can be enabled on individual interfaces or an entire area. This section begins by examining plain text and hashing authentication for OSPFv2. Then, the section concludes with a look at hashing authentication for OSPFv3. Interestingly, OSPFv3 relies on the authentication features provided by IPsec, rather than any authentication function natively built into OSPFv3.

Plain Text OSPFv2 Authentication

Plain text authentication (also known as clear text authentication or simple password authentication) for OSPFv2 requires neighboring OSPF routers to be preconfigured with the same authentication key (that is, a shared secret password). The steps to configure plain text OSPFv2 authentication are as follows:

Image

Step 1. Plain text authentication must be enabled for either an interface or an OSPF area:

Image Enable per interface using the ip ospf authentication interface subcommand.

Image Enable on all interfaces in an area by changing the area-wide authentication setting using the area area-number authentication subcommand under OSPF router configuration mode.

Step 2. The authentication keys must be configured per interface, using the ip ospf authentication-key name-of-key interface subcommand.


Note

OSPFv3 does not support the plain text authentication supported by OSPFv2.


Example 17-7 illustrates the configuration of OSPFv2 plain text authentication for the topology shown in Figure 17-5.

Image

Figure 17-5 Two Routers Configured with OSPFv2 Plain Text Authentication

Image

Example 17-7 OSPFv2 Plain Text Authentication Configuration


!Configuration on Router R1
interface Serial1/0
ip address 10.1.1.1 255.255.255.252
ip ospf authentication-key KEYLIME
!
router ospf 1
area 0 authentication
network 0.0.0.0 255.255.255.255 area 0

!Configuration on Router R2
interface Serial1/0
ip address 10.1.1.2 255.255.255.252
ip ospf authentication
ip ospf authentication-key KEYLIME
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0



Note

The maximum length of the authentication key is eight characters. If you enter a longer key, it will automatically be truncated to eight characters.


Example 17-7 shows two approaches for configuring plain text authentication for OSPF. The ip ospf authentication-key key-string command is issued in interface configuration mode on both Routers R1 and R2. However, Router R1 uses the area area_number authentication command in router configuration mode to enable authentication for all its interfaces participating in area 0, while Router R2 uses the ip ospf authentication command in interface configuration mode to enable authentication for an individual interface. These two approaches are compatible with one another, and a neighborship successfully forms.

The show ip ospf interface interface_identifier command can be used to confirm that plain text authentication (referred to as simple password authentication in Cisco IOS command output) is enabled on an interface. Of course, you could also use the show ip ospf neighbor command to confirm that a neighborship exists between two routers. Example 17-8 offers sample output from these commands issued on Router R1.

Example 17-8 Verifying OSPFv2 Plain Text Authentication


R1# show ip ospf interface s 1/0
Serial1/0 is up, line protocol is up
Internet Address 10.1.1.1/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 172.16.1.1, Network Type POINT_TO_POINT, Cost: 64
Topology-MTID Cost Disabled Shutdown Topology Name
0 64 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 4 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.1.1
Suppress hello for 0 neighbor(s)
Simple password authentication enabled
R1# show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 0 FULL/ - 00:00:32 10.1.1.2 Serial1/0


OSPFv2 MD5 Authentication

Unlike EIGRP for IPv4 MD5 authentication, OSPFv2 MD5 authentication does not allow the configuration of a key chain with time-based authentication keys. However, multiple keys can be configured on an interface, each with a different key number, called a key ID. To migrate to a new key, you would first configure a new key value on all routers in a subnet and then delete the configuration of the old keys. To avoid having network failures during this cutover, OSPF actually sends and accepts messages that use all the currently configured authentication keys on an interface.

Unlike OSPFv2 plain text authentication (which has a maximum key length of eight characters), OSPFv2 MD5 authentication allows a key length of 16 characters. This key, along with the key ID, is used to calculate the MD5 hash for each OSPF packet. As with OSPFv2 plain text authentication, you can enable OSPFv2 MD5 authentication on a per-interface basis or on an area-wide basis (which applies to all router interfaces belonging to the specific area). Also, you could (but are not required to) have a separate key string for each interface. The configuration steps can be summarized as follows:

Image

Step 1. Plain text authentication must be enabled for either an interface or an OSPF area:

Image Enable per interface using the ip ospf authentication message-digest interface subcommand.

Image Enable on all interfaces in an area by changing the area-wide authentication setting using the area area-number authentication message-digest subcommand under OSPF router configuration mode.

Step 2. The authentication keys must be configured per interface, using the ip ospf message-digest-key key-id md5 name-of-key interface subcommand.

Example 17-9 illustrates the configuration of OSPFv2 MD5 authentication between Routers R1 and R2 pictured in Figure 17-6.

Image

Figure 17-6 Two Routers Configured with OSPFv2 MD5 Authentication

Image

Example 17-9 OSPFv2 MD5 Authentication Configuration


!Configuration on Router R1
interface Serial1/0
ip address 10.1.1.1 255.255.255.252
ip ospf message-digest-key 1 md5 KEYLIME
!
router ospf 1
area 0 authentication message-digest
network 0.0.0.0 255.255.255.255 area 0
!

!Configuration on Router R2
interface Serial1/0
ip address 10.1.1.2 255.255.255.252
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 KEYLIME
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0


In Example 17-9, both Routers R1 and R2 have the ip ospf message-digest-key key-id md5 key-string command entered in interface configuration mode. However, Router R1’s configuration enables authentication for all the router’s interface participating in area 0, using the area area-number authentication message-digest command in router configuration mode. Conversely, Router R2’s configuration enables authentication at the interface level, with the ip ospf message-digest-key key-id md5 key-string command issued in interface configuration mode.

The same verification commands used for OSPFv2 plain text authentication apply to OSPFv2 MD5 configuration. However, the output of the show ip ospf interface interface_identifier command, as shown in Example 17-10, shows that message digest authentication is enabled, along with the youngest key ID. So, if a router is configured with multiple keys, the youngest key ID will be used when sending authenticated OSPF packets.


Note

The youngest key ID appearing in the output of the show ip ospf interface interface_identifier command is not necessarily the lowest key ID. Rather it is the key that has been most recently configured, regardless of its key ID.


Example 17-10 Verifying OSPFv2 MD5 Authentication


R1# show ip ospf interface s 1/0
Serial1/0 is up, line protocol is up
Internet Address 10.1.1.1/30, Area 0, Attached via Network Statement
Process ID 1, Router ID 172.16.1.1, Network Type POINT_TO_POINT, Cost: 64
Topology-MTID Cost Disabled Shutdown Topology Name
0 64 no no Base
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:02
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 4 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 192.168.1.1
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1


OSPFv3 Authentication

OSPFv3 has no authentication field in its headers. So, rather than using any authentication mechanism natively built into OSPFv3, it relies on IPsec to provide authentication. Interestingly, IPsec is capable of encrypting messages in addition to authenticating them. The Authentication Header (AH) encapsulation type for IPsec provides authentication services, but no encryption, while Encapsulating Security Payload (ESP) provides both authentication and encryption services.

The ipv6 ospf authentication command enables the use of AH to provide authentication, while the ipv6 ospf encryption command enables authentication and encryption services through ESP.

In addition to specifying whether you want to just perform authentication or also perform encryption, you need to specify an identifier called the security policy index (SPI) and a key string. The combination of an SPI and a key string is called a security policy. As with OSPFv2 authentication, OSPFv3 authentication (and encryption) can be performed on a per-interface or per-area basis; however, Cisco recommends the per-interface approach for enhanced security.

Unlike configuring OSPFv2 authentication, OSPFv3 authentication can be accomplished with a single command, as illustrated in Example 17-11 for the topology in Figure 7-7.

Image

Figure 17-7 Two Routers Configured for OSPFv3 SHA1 Authentication

Image

Example 17-11 OSPFv3 Authentication Configuration


!Configuration on Router R1
interface Serial1/0
ipv6 address 2002::1/64
ipv6 ospf 2 area 0
!
ipv6 router ospf 2
router-id 1.1.1.1
area 0 authentication ipsec spi 256 sha1 0123456789012345678901234567890123456789
!


!Configuration on Router R2
interface Serial1/0
ipv6 address 2002::2/64
ipv6 ospf authentication ipsec spi 256 sha1
0123456789012345678901234567890123456789
ipv6 ospf 2 area 0
!
ipv6 router ospf 2
router-id 2.2.2.2


Note that OSPFv3 authentication can be configured on a router with a single command. In Example 17-11, Router R1 has OSPFv3 authentication configured for an area, while Router R2 has OSPFv3 authentication configured for an interface.

In router configuration mode, the command to enable authentication is

area area_number authentication ipsec spi security_policy_index [md5 | sha1]
{0 | 7} key-string

Notice that you can specify either md5 or sha1 as your hashing algorithm. After specifying the algorithm you want to use, you can enter a 0 to indicate that you do not want your key string encrypted when it appears in your router’s running configuration. Alternately, you can select a 7 if you do want it to appear encrypted. Finally in this command, you enter the key string, which is a hexadecimal number. If you are using MD5 as your hashing algorithm, the key string must be 32 hexadecimal digits. However, if you selected SHA1, the key string must be 40 hexadecimal characters.

If you are configuring OSPFv3 authentication in interface configuration mode, then the command you issue is

ipv6 ospf authentication ipsec spi security_policy_index [md5 | sha1] {0 | 7}
key-string

Because OSPFv3 authentication is based on IPsec, you can verify the authentication configuration with the command show crypto ipsec sa interface interface_identifier. Example 17-12 illustrates sample output from this command from Router R1.

Example 17-12 Verifying OSPFv3 Authentication


R1# show crypto ipsec sa interface s 1/0

interface: Serial1/0

IPsecv6 policy name: OSPFv3-256

protected vrf: (none)
local ident (addr/mask/prot/port): (FE80::/10/89/0)
remote ident (addr/mask/prot/port): (::/0/89/0)
current_peer FF02::5 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 517, #pkts encrypt: 517, #pkts digest: 517
#pkts decaps: 517, #pkts decrypt: 517, #pkts verify: 517
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: FE80::C800:8FF:FEA4:0,
remote crypto endpt.: FF02::5
path mtu 1500, ipv6 mtu 1500, ipv6 mtu idb Serial1/0
current outbound spi: 0x100(256)
PFS (Y/N): N, DH group: none
inbound esp sas:

inbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 1, flow_id: 1, sibling_flags 80000011, crypto map:
Serial1/0-OSPF-MAP
sa timing: remaining key lifetime (sec): (0)
Kilobyte Volume Rekey has been disabled
replay detection support: N
Status: ACTIVE(ACTIVE)

inbound pcp sas:

outbound esp sas:

outbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: 2, sibling_flags 80000011, crypto map:
Serial1/0-OSPF-MAP
sa timing: remaining key lifetime (sec): (0)
Kilobyte Volume Rekey has been disabled
replay detection support: N
Status: ACTIVE(ACTIVE)

outbound pcp sas:
Crypto map tag: Serial1/0-OSPF-MAP, local addr FE80::C800:8FF:FEA4:0


Notice that the transform sets shown in the output use ah-sha-hmac. This indicates that the configuration is using Authentication Header (AH) for authentication (as opposed to Encapsulating Security Payload [ESP] for authentication and encryption). It also indicates that Secure Hash Algorithm (SHA) is the specific hashing algorithm being used for authentication (as opposed to Message Digest 5 [MD5]).

BGP Authentication

Unlike EIGRP and OSPF, which can (in some configurations) dynamically form neighborships, BGP requires neighboring routers to be explicitly configured. Therefore, the threat of someone maliciously forming a neighborship with your BGP router is far less likely, as compared to OSPF or EIGRP.

However, imagine that your BGP-speaking router had already established a TCP session with a configured BGP peer. In such a scenario, an attacker could possibly hijack that existing TCP session and proceed to corrupt the BGP table on your router. To help mitigate such a threat, you can configure authentication for BGP. This authentication is going to be through MD5. There is no Cisco IOS support for plain text or SHA authentication for BGP.

BGP does not require a series of configuration steps. Rather, BGP can be enabled on a router with a single command, as demonstrated next.

IPv4 BGP Authentication

To configure BGP authentication between two neighboring BGP neighbors, enter the neighbor neighbor-ip password key command in BGP router configuration mode on each router.

Example 17-13 shows a BGP authentication configuration for an IPv4 network, the topology for which is provided in Figure 17-8.

Image

Figure 17-8 Two Routers in an IPv4 Network Configured for BGP Authentication

Image

Example 17-13 IPv4 BGP Authentication Configuration


!Configuration on Router R1
router bgp 65001
network 172.16.1.0 mask 255.255.255.0
neighbor 10.1.1.2 remote-as 65002
neighbor 10.1.1.2 password KEYNOTE

!Configuration on Router R2
router bgp 65002
network 192.168.1.0
neighbor 10.1.1.1 remote-as 65001
neighbor 10.1.1.1 password KEYNOTE


There is no BGP command to specifically troubleshoot BGP authentication; however, you can issue the show ip bgp summary command to determine whether a neighborship is currently up, as demonstrated in Example 17-14. If the neighborship is not up, you can check the keys on each neighbor to make sure that they match, just like the key of KEYNOTE matches on Routers R1 and R2 in Example 17-13.

Example 17-14 Verification of IPv4 BGP Authentication


R1# show ip bgp summary
BGP router identifier 172.16.1.1, local AS number 65001
BGP table version is 5, main routing table version 5
2 network entries using 288 bytes of memory
2 path entries using 160 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 744 total bytes of memory
BGP activity 7/5 prefixes, 7/5 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.2 4 65002 9 10 5 0 0 00:05:21 1


IPv6 BGP Authentication

The procedure to configure BGP authentication on an IPv6 network is identical to the procedure previously seen for IPv4. Specifically, you issue the neighbor neighbor-ip password key command in BGP router configuration mode; however, the neighbor-ip value will be an IPv6 address, as opposed to an IPv4 address.

Example 17-15 shows a sample BGP authentication for the IPv6 network illustrated in Figure 17-9.

Image

Figure 17-9 Two Routers in an IPv6 Network Configured for BGP Authentication

Image

Example 17-15 IPv6 BGP Authentication Configuration


!Configuration on Router R1
router bgp 65001
bgp router-id 1.1.1.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2002::2 remote-as 65002
neighbor 2002::2 password KEYNOTE
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2001::/64
network 2002::/64
neighbor 2002::2 activate
exit-address-family


!Configuration on Router R2
router bgp 65002
bgp router-id 2.2.2.2
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2002::1 remote-as 65001
neighbor 2002::1 password KEYNOTE
!
address-family ipv4
exit-address-family
!
address-family ipv6
network 2002::/64
network 2003::/64
neighbor 2002::1 activate
exit-address-family


Example 17-16 shows output from the show bgp ipv6 unicast summary command, confirming that Router R1 has a BGP neighborship with Router R2.

Example 17-16 Verification of IPv6 BGP Authentication


R1# show bgp ipv6 unicast summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 6, main routing table version 6
3 network entries using 504 bytes of memory
4 path entries using 416 bytes of memory
2/2 BGP path/bestpath attribute entries using 272 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1216 total bytes of memory
BGP activity 6/3 prefixes, 8/4 paths, scan interval 60 secs

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2002::2 4 65002 10 10 6 0 0 00:04:56 2


Exam Preparation Tasks

Planning Practice

The CCNP ROUTE exam expects test takers to review design documents, create implementation plans, and create verification plans. This section provides some exercises that can help you to take a step back from the minute details of the topics in this chapter so that you can think about the same technical topics from the planning perspective.

For each planning practice table, simply complete the table. Note that any numbers in parentheses represent the number of options listed for each item in the solutions in Appendix F, “Completed Planning Practice Tables.”

Design Review Table

Table 17-3 lists several design goals related to this chapter. If these design goals were listed in a design document, and you had to take that document and develop an implementation plan, what implementation options come to mind? For any configuration items, a general description can be used, without concern about the specific parameters.

Image

Table 17-3 Design Review

Implementation Plan Peer Review Table

Table 17-4 shows a list of questions that others might ask, or that you might think about, during a peer review of another network engineer’s implementation plan. Complete the table by answering the questions.

Image

Table 17-4 Notable Questions from This Chapter to Consider During an Implementation Plan Peer Review

Create an Implementation Plan Table

To practice skills useful when creating your own OSPF implementation plan, list in Table 17-5 configuration commands related to the configuration of the following features. You might want to record your answers outside the book, and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.

Image

Image

Table 17-5 Implementation Plan Configuration Memory Drill

Choose Commands for a Verification Plan Table

To practice skills useful when creating your own OSPF verification plan, list in Table 17-6 all commands that supply the requested information. You might want to record your answers outside the book, and set a goal to complete this table (and others like it) from memory during your final reviews before taking the exam.

Image

Table 17-6 Verification Plan Memory Drill


Note

Some of the entries in this table might not have been specifically mentioned in this chapter but are listed in this table for review and reference.


Review All the Key Topics

Review the most important topics from inside the chapter, noted with the Key Topic icon in the outer margin of the page. Table 17-7 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 17-7 Key Topics for Chapter 17

Complete the Tables and Lists from Memory

Print a copy of Appendix D, “Memory Tables,” (found on the CD) or at least the section for this chapter, and complete the tables and lists from memory. Appendix E, “Memory Tables Answer Key,” also on the CD, includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary.

authentication

key chain

Message Digest 5 authentication

Secure Hash Algorithm (SHA)

shared key