RIP Authentication

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, GigabitEthernet1

Router 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, GigabitEthernet1

MD5 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 routes

Now, 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 routes

Thoughts

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.