I was watching INE videos about RIP and when I reached the RIP Authentication video, I apparently forgot about the key number must match requirement when using MD5. To be honest, it wasn’t the only one I forgot about RIP. Heck, I usually forget what I read last night! It’s a constant struggle that I deal with every single day. I think I need a flash drive or the “Limitless” pill so that I can remember everything I read, but I digress.
Clear Text Method
There are two methods that can be used when enabling RIP Authentication: clear text and MD5. For security purposes, cleartext should not be used in production. This method has two requirements: key string and authentication must match for it to work. That said, even if the key number doesn’t match the routers will still exchange routes just fine. For completeness sake, the example is shown below.
Router 1 configuration and verification:
R1#sh run | se key
key chain rip
key 1
key-string cisco
ip rip authentication key-chain rip
R1#sh ip route rip | se sub
22.0.0.0/24 is subnetted, 1 subnets
R 22.22.22.0 [120/1] via 1.1.1.2, 00:00:04, GigabitEthernet1Router 2 configuration and verification:
R2#sh run | se key
key chain rip
key 2
key-string cisco
ip rip authentication key-chain rip
R2#sh ip route rip | se sub
11.0.0.0/24 is subnetted, 1 subnets
R 11.11.11.0 [120/1] via 1.1.1.1, 00:00:19, GigabitEthernet1MD5 Authentication
This method is the recommended mode in-production for obvious reasons. This method has three requirements: key number, key string, and authentication must match. We all know what it looks like when it works, but what happens when we actually introduce a fault in the configuration? In theory, it shouldn’t work, right? Well, let’s take a look.
Router 1 and Router 2 are configured with two different key string:
R1#sh run | se key key chain rip key 1 key-string cisco ip rip authentication key-chain rip R1#sh ip route rip | se sub R1# R1#debug ip rip events *Jun 15 22:59:02.665: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication) R2#sh run | se key key chain rip key 1 key-string systems ip rip authentication key-chain rip R2#sh ip route rip | se sub R2# R2#debug ip rip event *Jun 15 22:51:29.159: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)
As expected, both routers ignored the update and didn’t process the update.
Router 1 and Router 2 are configured with two different authentication mode:
R1#sh run | se mode md5|key key chain rip key 1 key-string cisco ip rip authentication mode md5 ip rip authentication key-chain rip R1#sh ip route rip | se sub R1# R1#debug ip rip event RIP event debugging is on *Jun 15 23:08:45.068: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication) R2#sh run | se mode md5|key key chain rip key 1 key-string cisco ip rip authentication key-chain rip R2#sh ip route rip | se sub R2#debug ip rip event RIP event debugging is on *Jun 15 23:08:40.623: RIP: ignored v2 packet from 1.1.1.1 (invalid authentication)
Again, it’s expected to not work.
Router 1 and Router 2 are configured with two different key number:
R1#sh run | se key|mode md5
key chain rip
key 1
key-string cisco
ip rip authentication mode md5
ip rip authentication key-chain rip
R1#sh ip route rip | se sub
R1#debug ip rip event
RIP event debugging is on
*Jun 15 23:20:33.452: RIP: ignored v2 packet from 1.1.1.2 (invalid authentication)
R2#sh run | se key|mode md5
key chain rip
key 2
key-string cisco
ip rip authentication mode md5
ip rip authentication key-chain rip
R2#sh ip route rip | se sub
11.0.0.0/24 is subnetted, 1 subnets
R 11.11.11.0 [120/1] via 1.1.1.1, 00:00:18, GigabitEthernet1
R2#debug ip rip eve
RIP event debugging is on
*Jun 15 23:23:15.984: RIP: received v2 update from 1.1.1.1 on GigabitEthernet1
*Jun 15 23:23:15.984: RIP: Update contains 1 routesNow, this is interesting output. Why did R2 process the update of R1 and installed its routing table and R1 ignored the update from R2? The only thing that makes sense is the feature of RIP (and most likely EIGRP too) that it can store multiple keys in its database to change up so that it can mitigate the keys being compromised. RFC 2082 doesn’t talk about it but it does talk about multiple keys and rollover so I think it’s related to that. I haven’t seen a Cisco doc about this specifically so please feel free to drop me a comment pointing to one that explains this behavior.
For experimentation’s sake, I decided to add another key number in R1 that matches R2’s configuration. R1 did process the RIP updates and installed it in the routing table, as one would expect since all three requirements were met.
R1#sh run | se key|md5
key chain rip
key 1
key-string cisco
key 2
key-string cisco
ip rip authentication mode md5
ip rip authentication key-chain rip
R1#sh ip route rip | se sub
22.0.0.0/24 is subnetted, 1 subnets
R 22.22.22.0 [120/1] via 1.1.1.2, 00:00:17, GigabitEthernet1
*Jun 15 23:33:49.378: RIP: received v2 update from 1.1.1.2 on GigabitEthernet1
*Jun 15 23:33:49.378: RIP: Update contains 1 routesThoughts
I wish Cisco’s documentation and/or Cisco Press’ authors covered this but I haven’t seen one that did. Even Cisco’s configuration guide, and configuration examples didn’t explain much about the keys. Perhaps, they feel like RIP shouldn’t be covered as detailed as the other routing protocols since it’s rarely used in production. What are your thoughts?
Disclosure
NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.
