RIP MD5 authentication – mismatch in key ID
This is an interesting fact I just found out. When we configure MD5
authentication for RIP they key-ID and key-string must match, this is
well known. But what happens if we actually configure the wrong key-ID?
Take a look at the following config.
R1#sh run | s key chain key chain RIP key 1 key-string cisco
R2#sh run | s key chain key chain RIP key 2 key-string cisco
So R2 has a higher key-ID. No routes should be passing right? Wrong.
R2 will accept routes from R1 because it has the higher ID however
R1 will not accept routes from R2.
R1#show ip route rip RIP: ignored v2 packet from 10.10.1.2 (invalid authentication)
R2#show ip route rip 220.127.116.11/24 is subnetted, 1 subnets R 18.104.22.168 [120/1] via 10.10.1.1, 00:00:26, FastEthernet0/0 RIP: received packet with MD5 authentication
The only thing I can think of why this works is that it is some form
of rollover process where they older key-ID is accepted until routers
have been migrated to the new ID. It is strange that it works though
since key-ID 1 does not exist on R2.
If we change the password on R1 then the authentication will fail on R2
RIP: ignored v2 packet from 10.10.1.1 (invalid authentication)
So the password is surely checked but they key-ID is ignored if a higher
key-ID is locally configured.
If anyone has some background on this I would be very interested. All I
could find was a RFC for MD5 for RIP. It mentioned something about key rollover
but nothing definite.