Cycling OSPF Authentication without Adjacency Downtime

By stretch | Thursday, June 10, 2010 at 1:34 a.m. UTC

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

OSPF_key1.png

OSPF_key2.png

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.)

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


aconaway
June 10, 2010 at 1:42 a.m. UTC

Good stuff as usual, stretch. I'm confused, though, on how both routers detect when they only have to use the younger key. Do they just say something like "no one's used that old key in a while; I'm going to stop using it"?


AngelaZ
June 10, 2010 at 8:43 a.m. UTC

When you have X keys, you send X copies of all OSPF packets, each packet with a different authentication. This increase traffic, but when you have the new key set on both routers, you can disable the old key and then the router is going to use the only key it has.


Jefferson (guest)
June 10, 2010 at 7:16 p.m. UTC

Is there any way to do this gracefully to turn on authentication?


Paul (guest)
June 11, 2010 at 2:12 a.m. UTC

That's a very, very cool feature! Stretch, my question is can the switch over between keys be made automatic? Like military crypto, maybe you want to set it up for 'changeover' well before it actually has to happen.


Philip (guest)
June 11, 2010 at 8:40 p.m. UTC

Hi,

I once had to wait for an agreed maintenance when we wanted to add BGP MD5 authentication to an existing session. Afterwards, I came up with the following EEM script, to automate this process next time.

We are waiting for a log message like this:

May 5 19:05:51.339: %BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down BGP protocol initialization

So we configure on our router:

event manager applet BGP-PASS
event syslog occurs 1 pattern "%BGP-5-ADJCHANGE: neighbor 10.1.1.1 Down"
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "router bgp 64512"
action 1.3 cli command "neighbor 10.1.1.1 password topsecret"

Of course, this should not be done too early in advance, because if the session flaps due to other reasons, you break it with this.

But with this script, the peer just has to clear the session, and when it comes back it is encrypted.


Asim (guest)
October 31, 2011 at 10:39 a.m. UTC

Any way this could be automated to convert a normal eigrp AS to an authentication enabled one?

Comments have closed for this article due to its age.