Cycling OSPF Authentication without Adjacency Downtime

Last week, we highlighted an important detail with regard to OSPF MD5 authentication. Along a similar same vein, today we'll look at how OSPF authentication keys can be safely swapped out on a live OSPF adjacency without causing interruption.

Suppose to routers R1 and R2 have the following interface configurations:

R1

interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.252
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 Alpha
 ip ospf 1 area 0

R2

interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.252
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 Alpha
 ip ospf 1 area 0

Now suppose that it's time (as mandated by our organization's security policies) to refresh the authentication strings used to secure OSPF adjacencies across the network. For the purposes of this article, we'll use the string "Bravo" in place of the original string, "Alpha".

Now, we could simply replace the old string with the new one, but we risk the adjacency timing out if we're not quick enough on both routers. Further, even if the strings are changed at both ends before the dead timer expires, individual route advertisements may be dropped between the two peers within that window of time when the strings differ.

Fortunately, we can instead simply add a second authentication key to be used along with the first one:

R1(config-if)# ip ospf message-digest-key 2 md5 Bravo

This triggers R1 to begin sending two copies of each OSPF packet: one with key 1, and another with key 2. R2 will continue to accept OSPF packets with key 1, while ignoring those with key 2, which it has not yet been configured to honor.

R1# show ip ospf interface
FastEthernet0/0 is up, line protocol is up 
  Internet Address 10.0.0.1/30, Area 0 
  Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 10
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 10.0.0.2, Interface address 10.0.0.2
  Backup Designated router (ID) 10.0.0.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:03
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 10.0.0.2  (Designated Router)
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 2

Then, we add the second to R2 as well:

R2(config-if)# ip ospf message-digest-key 2 md5 Bravo

Once both routers have both keys configured, they will automatically detect the youngest key in use and revert to sending only a single copy of each packet, using only the newer key. We can now remove the first key from the configurations of both routers without worrying about the state of the adjacency.

R1(config-if)# no ip ospf message-digest-key 1

R2(config-if)# no ip ospf message-digest-key 1

Other Routing Protocols

This same concept can be extended to other routing protocols as well. RIP and EIGRP on IOS utilize key chains consisting of one or more authentication keys which can be set to initiate or expire at certain times, to help automate the process of key maintenance.

(If anyone knows of a similar, graceful solution for BGP, please share it in the comments.)