There is always the consideration for securing or authenticating the Control Plan between routing protocols and RIP is no exception. RIPv1 doesn’t support authentication, however RIPv2 supports both clear text and Message Digest 5 or MD5 authentication. Just to be clear we’re not talking about encrypting the payload or the routes themselves, but rather the authentication of the Control Plane. RIPv2 uses a Key Chain definition or basically a pre-shared key that’s exchange between Routers in order to accomplish this.

RIPv1 vs. RIPv2

  • V1 Supports clear text authentication
  • V1 Supports MD5 authentication
  • V2 Supports clear text authentication
  • V2 Supports MD5 authentication

RFCs

  • 4822 – Cryptographic Authentication
  • 2082 – MD5 Authentication

The obvious major benefit of authentication with regards to any dynamic routing protocol is the ability to control or protect who, and who cannot form adjacency ultimately exchanging prefixes. RIP doesn’t actually form adjacency like other IGP’s such as EIGRP and OSPF, however authentication still accomplishes the same result.

The WAN interfaces along with the loopbacks have already been configured on both R1 and R2, so the the first thing we need to do simply get RIP up and running between Routers. Will start off by configuring R1 with RIP version 2 making sure to advertise classful networks.

R1#configure terminal
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#network 1.0.0.0
R1(config-router)#network 10.0.0.0
R1(config-router)#no auto-summary
R1(config-router)#end
R1#

Lets jump over to R2 and do the same thing on the other side.

R2#configure terminal
R2(config)#router rip 
R2(config-router)#version 2 
R2(config-router)#network 2.0.0.0 
R2(config-router)#network 10.0.0.0 
R2(config-router)#no auto-summary 
R2(config-router)#end 
R2#

Now lets make sure that we’re exchanging routes between R1 and R2 be checking the RIP database.

R1#show ip rip database 2.2.2.2 255.255.255.255
2.2.2.2/32
    [1] via 10.1.2.2, 00:00:23, FastEthernet0/0
R1#

Just to be sure lets verify that R2 is sending and receiving from R1.

R2#show ip rip database 1.1.1.1 255.255.255.255
1.1.1.1/32
    [1] via 10.1.2.1, 00:00:10, FastEthernet0/0
R2#

At this point we have RIPv2 is up and running between both R1 and R2. Both the WAN and loopback interfaces are exchanging via RIPv2 advertisements, and we have complete connectivity between the loopbacks. For the sack of simplicity I’m going to be using vary simple key chain password which in a real world deployment wouldn’t be advisable for obvious reasons.

R1#configure terminal
R1(config)#key chain ABC
R1(config-keychain)#key 1
R1(config-keychain-key)#key-string abc123
R1(config-keychain-key)#exit
R1(config-keychain)#exit
R1(config)#

Lets jump over to R2 and complete the same key chain configuration. It’s important that the key chain name itself matches on both sides. In my example I simply used ABC as the name of the key chain. Numeric values are also supported.

R2#configure terminal 
R2(config)#key chain ABC 
R2(config-keychain)#key 1 
R2(config-keychain-key)#key-string abc123 
R2(config-keychain-key)#exit
R2(config-keychain)#exit
R2(config)#

We’re finally at the point we’re we can actually secure or authenticate the Control Plane between R1 and R2. We have a couple of options available regarding the type of authentication one being plan text and the other being MD5. The major advantage of using MD5 is the hash that is negotiated between R1 and R2. In other words the password is no longer in plan text.

R1(config)#interface fastEthernet0/0
R1(config-if)#ip rip authentication key-chain ABC
R1(config-if)#ip rip authentication mod md5
R1(config-if)#end
R1#

Now lets jump over to R2 and do same thing.

R2(config)#interface fastEthernet0/0
R2(config-if)#ip rip authentication key-chain ABC
R2(config-if)#ip rip authentication mod md5
R2(config-if)#end
R2#

Lets check the routing table from R1’s perspective. I could also check the CEF table on both sides just as easily.

R1#show ip route rip | begin Gateway
Gateway of last resort is not set

2.0.0.0/32 is subnetted, 1 subnets
R 2.2.2.2 [120/1] via 10.1.2.2, 00:00:23, FastEthernet0/0
R1#

Last but not least lets check the routing table from R2’s perspective.

R2#show ip route rip | begin Gateway
Gateway of last resort is not set

1.0.0.0/32 is subnetted, 1 subnets
R 1.1.1.1 [120/1] via 10.1.2.1, 00:00:03, FastEthernet0/0
R2#

I hope you found this post on RIP Control Plane Security helpful and informative. Be sure to let me know what you think by leaving suggestions, and feedback in the comments section below. You can find out more about these and other articles be checking out recent posts and archives. To learn more about me be sure to check out the About page. And as always thanks again for visiting The Packet.