This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring EIGRP Authentication
You can prevent your router from receiving fraudulent route updates by configuring neighbor router authentication. You can configure EIGRP neighbor authentication (also called neighbor router authentication or route authentication) such that routers can participate in routing based on predefined passwords.
This section first describes router authentication in general, followed by a discussion of how to configure and troubleshoot EIGRP Message Digest 5 (MD5) authentication.
Router Authentication
Neighbor router authentication can be configured such that routers only participate in routing based on predefined passwords.
By default, no authentication is used for routing protocol packets. When neighbor router authentication has been configured on a router, the router authenticates the source of each routing update packet that it receives. This is accomplished by the exchange of an authentication key (also called a password) that is known to both the sending and the receiving router.
The router uses two types of authentication:
- Simple password authentication (also called plain text authentication)—Supported by Integrated System-Integrated System (IS-IS), Open Shortest Path First (OSPF), and Routing Information Protocol Version 2 (RIPv2)
- MD5 authentication—Supported by OSPF, RIPv2, BGP, and EIGRP
Both forms of authentication work in the same way, with the exception that MD5 sends a message digest instead of the authenticating key itself. The message digest is created using the key (and a key ID with some protocols) and a message, but the key itself is not sent, preventing it from being read while it is being transmitted. Simple password authentication sends the authenticating key itself over the wire.
With simple password authentication, a password (key) is configured on a router; each participating neighbor router must be configured with the same key.
MD5 authentication is a cryptographic authentication. A key (password) and key ID are configured on each router. The router uses an algorithm based on the routing protocol packet, the key, and the key ID to generate a message digest (also called a hash) that is appended to the packet. Unlike the simple authentication, the key is not exchanged over the wire—the message digest is sent instead of the key, which ensures that nobody can eavesdrop on the line and learn keys during transmission.
EIGRP MD5 Authentication
By default, no authentication is used for EIGRP packets. You can configure EIGRP to use MD5 authentication.
When EIGRP neighbor authentication has been configured on a router, the router authenticates the source of each routing update packet that it receives. The MD5 keyed digest in each EIGRP packet prevents the introduction of unauthorized or false routing messages from unapproved sources.
For EIGRP MD5 authentication, you must configure an authenticating key and a key ID on both the sending router and the receiving router. Each key has its own key ID, which is stored locally. The combination of the key ID and the interface associated with the message uniquely identifies the authentication algorithm and MD5 authentication key in use.
EIGRP allows keys to be managed using key chains. Each key definition within the key chain can specify a time interval for which that key will be activated (known as its lifetime). Then, during a given key's lifetime, routing update packets are sent with this activated key. Only one authentication packet is sent, regardless of how many valid keys exist. The software examines the key numbers in order from lowest to highest, and it uses the first valid key it encounters.
Keys cannot be used during time periods for which they are not activated. Therefore, it is recommended that for a given key chain, key activation times overlap to avoid any period of time for which no key is activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail.
Configuring MD5 Authentication
To configure MD5 authentication for EIGRP, complete the following steps:
- Step 1 Enter configuration mode for the interface on which you want to enable authentication.
- Step 2 Specify MD5 authentication for EIGRP packets using the ip authentication mode eigrp autonomous-system md5 interface configuration command. The autonomous-system is the EIGRP autonomous system number in which authentication is to be used.
- Step 3 Enable the authentication of EIGRP packets with a key specified in a key chain by using the ip authentication key-chain eigrp autonomous-system name-of-chain interface configuration command. The autonomous-system parameter specifies the EIGRP autonomous system number in which authentication is to be used. The name-of-chain parameter specifies the name of the authentication key chain from which a key is to be obtained for this interface.
- Step 4 Enter the configuration mode for the key chain using the key chain name-of-chain global configuration command.
- Step 5 Identify a key ID to use and enter configuration mode for that key using the key key-id key-chain configuration command. The key-id is the ID number of an authentication key on a key chain. The range of keys is from 0 to 2147483647; the key ID numbers need not be consecutive.
- Step 6 Identify the key string (password) for this key using the key-string key key-chain-key configuration command. The key is the authentication key-string that is to be used to authenticate sent and received EIGRP packets. The key string can contain from 1 to 80 uppercase and lowercase alphanumeric characters, except that the first character cannot be a number.
- Step 7 Optionally specify the time period during which this key will be accepted for use on received packets using the accept-lifetime start-time {infinite | end-time | duration seconds} key-chain-key configuration command. Table 3-3 describes the parameters for this command.
Table 3-3. accept-lifetime Command Parameters
Parameter
Description
start-time
Beginning time that the key specified by the key command is valid for use on received packets. The syntax can be either of the following:
hh:mm:ss month date year hh:mm:ss date month year hh—hours mm—minutes ss—seconds month—first three letters of the month date—date (1-31) year—year (four digits)
The default start time and the earliest acceptable date is January 1, 1993.
infinite
Indicates the key is valid for use on received packets from the start-time value on.
end-time
Indicates the key is valid for use on received packets from the start-time value until the end-time value. The syntax is the same as that for the start-time value. The end-time value must be after the start-time value. The default end time is an infinite time period.
seconds
Length of time (in seconds) that the key is valid for use on received packets. The range is from 1 to 2147483646.
- Step 8 Optionally specify the time period during which this key can be used for sending packets using the send-lifetime start-time {infinite | end-time | duration seconds} key-chain-key configuration command. Table 3-4 describes the parameters for this command.
Table 3-4. send-lifetime Command Parameters
|
Parameter |
Description |
|
start-time |
Beginning time that the key specified by the key command is valid to be used for sending packets. The syntax can be either of the following: hh:mm:ss month date year hh:mm:ss date month year hh—hours mm—minutes ss—seconds month—first three letters of the month date—date (1-31) year—year (four digits) The default start time and the earliest acceptable date is January 1, 1993. |
|
infinite |
Indicates the key is valid to be used for sending packets from the start-time value on. |
|
end-time |
Indicates the key is valid to be used for sending packets from the start-time value until the end-time value. The syntax is the same as that for the start-time value. The end-time value must be after the start-time value. The default end time is an infinite time period. |
|
seconds |
Length of time (in seconds) that the key is valid to be used for sending packets. The range is from 1 to 2147483646. |
MD5 Authentication Configuration Example
Figure 3-26 shows the network used to illustrate the configuration, verification, and troubleshooting of MD5 authentication.
)
Figure 3-26 Network for EIGRP Authentication Configuration Example
Example 3-13 shows the configuration of the R1 router.
Example 3-13. Configuration of Router R1 in Figure 3-26
R1#show running-config <output omitted> key chain R1chain key 1 key-string firstkey accept-lifetime 04:00:00 Jan 1 2006 infinite send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006 key 2 key-string secondkey accept-lifetime 04:00:00 Jan 1 2006 infinite send-lifetime 04:00:00 Jan 1 2006 infinite <output omitted> interface FastEthernet0/0 ip address 172.16.1.1 255.255.255.0 ! interface Serial0/0/1 bandwidth 64 ip address 192.168.1.101 255.255.255.224 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 R1chain ! router eigrp 100 network 172.16.1.0 0.0.0.255 network 192.168.1.0 auto-summary
MD5 authentication is configured on the serial 0/0/1 interface with the ip authentication mode eigrp 100 md5 command. The ip authentication key-chain eigrp 100 R1chain command specifies that the key chain R1chain is to be used.
The key chain R1chain command enters configuration mode for the R1chain key chain. Two keys are defined. Key 1 is set to firstkey with the key-string firstkey command. This key is acceptable for use on packets received by R1 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. However, the send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006 command specifies that this key was only valid for use when sending packets for 1 minute on January 1, 2006; it is no longer valid for use in sending packets.
Key 2 is set to secondkey with the key-string secondkey command. This key is acceptable for use on packets received by R1 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.
R1 will therefore accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. All other MD5 packets will be dropped. R1 will send all EIGRP packets using key 2, because key 1 is no longer valid for use when sending packets.
Example 3-14 shows the configuration of the R2 router.
Example 3-14. Configuration of Router R2 in Figure 3-26
R2#show running-config <output omitted> key chain R2chain key 1 key-string firstkey accept-lifetime 04:00:00 Jan 1 2006 infinite send-lifetime 04:00:00 Jan 1 2006 infinite key 2 key-string secondkey accept-lifetime 04:00:00 Jan 1 2006 infinite send-lifetime 04:00:00 Jan 1 2006 infinite <output omitted> interface FastEthernet0/0 ip address 172.17.2.2 255.255.255.0 ! interface Serial0/0/1 bandwidth 64 ip address 192.168.1.102 255.255.255.224 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 R2chain ! router eigrp 100 network 172.17.2.0 0.0.0.255 network 192.168.1.0 auto-summary
MD5 authentication is configured on the serial 0/0/1 interface with the ip authentication mode eigrp 100 md5 command. The ip authentication key-chain eigrp 100 R2chain command specifies that the key chain R2chain is to be used.
The key chain R2chain command enters configuration mode for the R2chain key chain. Two keys are defined. Key 1 is set to firstkey with the key-string firstkey command. This key is acceptable for use on packets received by R2 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.
Key 2 is set to secondkey with the key-string secondkey command. This key is acceptable for use on packets received by R2 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.
R2 will therefore accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. R2 will send all EIGRP packets using key 1, because it is the first valid key in the key chain.
Verifying MD5 Authentication
Example 3-15 provides the output of the show ip eigrp neighbors and show ip route commands on the R1 router depicted in the network in Figure 3-26. The neighbor table indicates that the two routers have successfully formed an EIGRP adjacency. The routing table verifies that the 172.17.0.0 network has been learned via EIGRP over the serial connection. Example 3-15 also shows the results of a ping to the R2 Fast Ethernet interface address to illustrate that the link is working.
Example 3-15. Output on Router R1 in Figure 3-26
R1#
*Apr 21 16:23:30.517: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0/
0/1) is up: new adjacency
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.102 Se0/0/1 12 00:03:10 17 2280 0 14
R1#show ip route
<output omitted>
Gateway of last resort is not set
D 172.17.0.0/16 [90/40514560] via 192.168.1.102, 00:02:22, Serial0/0/1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:31:31, Null0
C 172.16.1.0/24 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.96/27 is directly connected, Serial0/0/1
D 192.168.1.0/24 is a summary, 00:31:31, Null0
R1#ping 172.17.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/16 ms
Troubleshooting MD5 Authentication
This section provides some examples of how to troubleshoot EIGRP MD5 authentication.
Example of Successful MD5 Authentication
Example 3-16 shows output from the debug eigrp packets command on R1, which displays that R1 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 1, from R2.
Example 3-16. debug eigrp packets Command Output on Router R1 in Figure 3-26
R1#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
*Apr 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Apr 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Apr 21 16:38:51.745: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/
rely 0/0
Similarly, the output of the debug eigrp packets command on R2 shown Example 3-17 illustrates that R2 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from R1.
Example 3-17. debug eigrp packets Command Output on Router R2 in Figure 3-26
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:38:38.321: EIGRP: received packet with MD5 authentication, key id = 2
*Apr 21 16:38:38.321: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.101
*Apr 21 16:38:38.321: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/
rely 0/0
Example of Troubleshooting MD5 Authentication Problems
For this example, the key string for router R1's key 2, the one that it uses when sending EIGRP packets, is changed to be different from the key string that router R2 is expecting. Example 3-18 shows the changes to the configuration for R1.
Example 3-18. Changes to the Configuration of Router R1 in Figure 3-26
R1(config-if)#key chain R1chain R1(config-keychain)#key 2 R1(config-keychain-key)#key-string wrongkey
The output of the debug eigrp packets command on R2 shown in Example 3-19 illustrates that R2 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from R1, but that there is an authentication mismatch. The EIGRP packets from R1 are ignored, and the neighbor relationship is declared to be down. The output of the show ip eigrp neighbors command confirms that R2 does not have any EIGRP neighbors.
Example 3-19. Output on Router R2 in Figure 3-26
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Apr 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opcode = 5
(invalid authentication)
*Apr 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Apr 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1
*Apr 21 16:50:18.749: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Apr 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101
(Serial0/0/1) is down: Auth failure
R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
R2#
The two routers keep trying to reestablish their neighbor relationship. Because of the different keys used by each router in this scenario, R1 will authenticate hello messages sent by R2 using key 1. When R1 sends a hello message back to R2 using key 2, however, an authentication mismatch exists. From R1's perspective, the relationship appears to be up for a while, but then it times out, as illustrated by the messages received on R1 shown in Example 3-20. The output of the show ip eigrp neighbors command on R1 also illustrates that R1 does have R2 in its neighbor table for a short time.
Example 3-20. Output on Router R1 in Figure 3-26
R1#
*Apr 21 16:54:09.821: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0
/0/1) is down: retry limit exceeded
*Apr 21 16:54:11.745: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0
/0/1) is up: new adjacency
R1#show ip eigrp neighbors
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.102 Se0/0/1 13 00:00:38 1 5000 1 0