RIP authentication

CCIE blueprint: 3.4.a Implement and troubleshoot RIPv2

This post is part of a multipost series about RIP. Other posts in this series are:

This post will zoom in to the authentication process in RIP. This is largely the same for other protocols, so a lot of this information can be applied to other routing protocols.

First off, authentication in RIP is just that. Authentication. RIP does not support encryption of updates. This means that the updates themselves will be sent in plain text. The only way to prevent anybody from reading the updates if they are able to capture them as they cross the wires is to apply some other form of encryption like IPsec or MACsec.

Authentication in RIP comes in two variations, plain text mode and MD5 mode. The plain text mode isn’t much in the way of authentication since everybody can read the password when they perform a packet capture. However, it can help preventing ‘accidental’ routers joining the network.

Plain text authentication

We will start with looking at this plain text authentication mechanism.

First we need to configure a key chain:

key chain PLAIN_TEXT
 key 1
  key-string CISCO

Then we need to apply this key string to the interface on which we want to perform authentication:

interface g0/1
 ip rip authentication mode text
 ip rip authentication key PLAIN_TEXT

Once we’ve done this the router will start sending updates using the key. If it receives updates without the authentication key it will ignore them. On the other hand, routers that have not yet been configured for authentication will ignore authenticated packets:

*Jun  6 13:38:25.171: RIP: ignored v2 packet from 12.1.1.1 (invalid authentication)

If the key doesn’t match another debug message will be shown:

*Jun  6 13:43:35.027: RIP: received packet with text authentication CISC0
*Jun  6 13:43:35.028: RIP: ignored v2 packet from 12.1.1.2 (invalid authentication)

As you can see the logging tells you what the key is. In this case, the error is in the fact that the last O has been replaced with a 0.

In the image below you can see a packet capture. In this capture you can see the plain text authentication with the password. You can also see that the routing updates themselves are plain text as well.

RIPv2 plain text authentication

MD5 authentication

When you want a better level of security you can consider using MD5 as hashing algorithm. This ensures that an eavesdropper won’t be able to read the password (there are still options to crack an MD5 password, but the effort required is much greater unless you use a simple password like CISCO)

The configuration is actually the same, except for one interface level command:

key chain MD5_KEY
 key 1
  key-string HASH
interface g 0/2
 ip rip authentication mode MD5
 ip rip authentication key MD5_KEY

Now, as you can see in the capture the password isn’t readable anymore:

RIPv2 plain text authentication

One of the other things you might notice in the output is the reference to a key ID. When using MD5 as authentication mechanism the key ID is important. This must match between hosts. The name of the key chain is not relevant, als long as the key ID matches.

If the key ID does not match, even though the password matches the update will be ignored:

#
*Jun  6 14:11:36.402: RIP: received packet with MD5 authentication
*Jun  6 14:11:36.403: RIP: ignored v2 packet from 13.1.1.3 (invalid authentication)

Key rotation

One of the advantages of using key chains is that it is possible to use key rotation. This is a mechanism in which the key is automatically changed for another (preconfigured) key based on the date. To configure this you need to configure a life for the keys.

key chain MD5_KEY
 key 1
  key-string HASH
  accept-lifetime 00:00:00 Jun 6 2018 14:22:00 Jun 6 2018
  send-lifetime 00:00:00 Jun 6 2018 14:21:00 Jun 6 2018
 key 2
  key-string HASH2
  accept-lifetime 14:20:00 Jun 6 2018 infinite
  send-lifetime 14:21:00 Jun 6 2018 infinite

R3#show key chain 
Key-chain MD5_KEY:
    key 1 -- text "HASH"
        accept lifetime (00:00:00 UTC Jun 6 2018) - (14:22:00 UTC Jun 6 2018) [valid now]
        send lifetime (00:00:00 UTC Jun 6 2018) - (14:21:00 UTC Jun 6 2018) [valid now]
    key 2 -- text "HASH2"
        accept lifetime (14:20:00 UTC Jun 6 2018) - (infinite)
        send lifetime (14:21:00 UTC Jun 6 2018) - (infinite)

[...]

R3#show clock
*14:20:01.130 UTC Wed Jun 6 2018
R3#show key chain 
Key-chain MD5_KEY:
    key 1 -- text "HASH"
        accept lifetime (00:00:00 UTC Jun 6 2018) - (14:22:00 UTC Jun 6 2018) [valid now]
        send lifetime (00:00:00 UTC Jun 6 2018) - (14:21:00 UTC Jun 6 2018) [valid now]
    key 2 -- text "HASH2"
        accept lifetime (14:20:00 UTC Jun 6 2018) - (infinite) [valid now]
        send lifetime (14:21:00 UTC Jun 6 2018) - (infinite)

[...]

R3#show clock
*14:21:00.871 UTC Wed Jun 6 2018
R3#show key chain 
Key-chain MD5_KEY:
    key 1 -- text "HASH"
        accept lifetime (00:00:00 UTC Jun 6 2018) - (14:22:00 UTC Jun 6 2018) [valid now]
        send lifetime (00:00:00 UTC Jun 6 2018) - (14:21:00 UTC Jun 6 2018)
    key 2 -- text "HASH2"
        accept lifetime (14:20:00 UTC Jun 6 2018) - (infinite) [valid now]
        send lifetime (14:21:00 UTC Jun 6 2018) - (infinite) [valid now]

In the sequence of commands above you can see the accept and send lifetimes of the keys configured.

Once the send lifetime of a key hits the key will be used to authenticate packets. There is some overlap between the times. This is to ensure that routers whose clocks might not be exactly synchronized to rollover without any problems occurring.

In a packet capture you can see the change from key 1 to key 2:

RIPv2 key rollover

In this capture you see two packets, packet 241 and packet 248. 241 uses key 1 and 248 uses key 2 (the clock between my routers and desktop isn’t fully in sync). This did not cause any problems on R1 since R1 accepted key 2 already before R3 started sending it