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:
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
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.)
Posted in Routing
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"?
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.
June 10, 2010 at 7:16 p.m. UTC
Is there any way to do this gracefully to turn on authentication?
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.
June 11, 2010 at 8:40 p.m. UTC
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.
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?