OSPFv2 Authentication Confusion
By stretch | Tuesday, June 1, 2010 at 3:49 a.m. UTC
Suppose we have two directly connected IOS routers running OSPF, configured as follows:
router ospf 1 router-id 22.214.171.124 ! interface FastEthernet0/0 ip address 192.168.0.1 255.255.255.252 ip ospf authentication message-digest ip ospf authentication-key Foo ip ospf 1 area 0
router ospf 1 router-id 126.96.36.199 ! interface FastEthernet0/0 ip address 192.168.0.2 255.255.255.252 ip ospf authentication message-digest ip ospf authentication-key Bar ip ospf 1 area 0
Notice that the two authentication keys are different. Will they form an adjacency?
The answer is yes. Let's explore why...
Recall that there are three types of OSPFv2 authentication:
- Null - No authentication (yes, this counts as a type)
- Plain - A shared string is included in each OSPF packet as plain text (extremely weak)
- MD5 - A shared secret is used to generate a hash included in each OSPF packet
For illustration, this is how a plain authentication string appears in an OSPF packet header:
Contrast this to the irreversible hash-based authentication offered by MD5:
The IOS command
ip ospf authentication is used to configure plain authentication on an interface, whereas
ip ospf authentication message-digest is used to configure MD5 authentication. Simple enough, right? However, there is a bit of dangerous ambiguity lurking here: two very different commands are used to configure the authentication keys for these two methods, which we'll cover in a moment.
The following is the output of
show ip ospf interface from R1:
R1# show ip ospf interface FastEthernet0/0 is up, line protocol is up Internet Address 192.168.0.1/30, Area 0 Process ID 1, Router ID 188.8.131.52, 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) 184.108.40.206, Interface address 192.168.0.2 Backup Designated router (ID) 220.127.116.11, Interface address 192.168.0.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:07 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 18.104.22.168 (Designated Router) Suppress hello for 0 neighbor(s) Message digest authentication enabled No key configured, using default key id 0
Note that although MD5 authentication is indeed enabled, OSPF reports that we have not configured an authentication key, so it defaults to using what is essentially a null key. Because this null key is the same on both routers, the adjacency forms successfully.
The problem here is that the wrong command has been used to specify the authentication key.
ip ospf authentication-key is used only for plain authentication. To specify an MD5 authentication key, we must use the command
ip ospf message-digest-key:
R1(config)# interface f0/0 R1(config-if)# no ip ospf authentication-key R1(config-if)# ip ospf message-digest-key 1 md5 FooBar
R2(config)# interface f0/0 R2(config-if)# no ip ospf authentication-key R2(config-if)# ip ospf message-digest-key 1 md5 FooBar
After correcting the configuration, we can verify that MD5 authentication is now in use:
R1# show ip ospf interface FastEthernet0/0 is up, line protocol is up Internet Address 192.168.0.1/30, Area 0 Process ID 1, Router ID 22.214.171.124, 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) 126.96.36.199, Interface address 192.168.0.2 Backup Designated router (ID) 188.8.131.52, Interface address 192.168.0.1 Flush timer for old DR LSA due in 00:02:51 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:05 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 184.108.40.206 (Designated Router) Suppress hello for 0 neighbor(s) Message digest authentication enabled Youngest key id is 1
This is the kind of mistake that can really trip you up, as it will appear to be working at first glance, but leaves your adjacencies wide open to hijacking.
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
June 1, 2010 at 8:41 a.m. UTC
Very interesting! Good work Stretch
June 1, 2010 at 12:44 p.m. UTC
I must admit that I fell victim to this confusion, it took me a while to figure it out, as you stated "it will appear to be working at first glance". I didn't notice the issue until I ran the show (ip ospf interface) command and saw the output "Message digest authentication enabled, No key configured, using default key id 0". After reading the documentation I finally realized my mistake.
June 1, 2010 at 12:51 p.m. UTC
wipe your eyes !-)
June 1, 2010 at 3:11 p.m. UTC
Good call! Very interesting. Thanks for the write up.
June 1, 2010 at 5:35 p.m. UTC
Yes Friends,wrong configs lead to troubles...
June 3, 2010 at 6:32 a.m. UTC
That needs to be a BSCI question ;p
June 8, 2010 at 8:40 p.m. UTC
June 23, 2011 at 2:45 p.m. UTC
Wondering... so i can form an adj with using the null key???? what is the point of putting authentication on the line/area?
June 25, 2012 at 6:13 a.m. UTC
Thanks! That really requires to be attentive!
December 16, 2012 at 6:34 a.m. UTC
July 29, 2013 at 12:35 p.m. UTC
I was only configuring these in a lab last night and made this very mistake during it before correcting it after I finished. It can be misleading that the neighbor relationship is reestablished as soon as both ends of the link are configured with MD5 but without a key chain.
August 22, 2013 at 1:12 p.m. UTC
In IOS software versions which have feature "OSPFv2 Cryptographic Authentication (RFC 5709)" this misconfiguration will produce log messages:
Aug 22 07:29:03.131: %OSPF-4-INVALIDKEY: Key ID 0 received on interface GigabitEthernet0/0/1
Aug 22 07:29:28.724: %OSPF-4-NOVALIDKEY: No valid authentication send key is available on interface GigabitEthernet0/0/1
They should alert user that something is not right.
For now we did not prohibit adjacency from being formed because someone might [unknowingly] be using this misconfiguration in their network but in a few years we may close this ambiguity.
The first software is 15.3(3)S.
February 9, 2014 at 1:46 a.m. UTC
April 14, 2014 at 9:39 p.m. UTC
Awesome! Thanks for pointing this out.
July 14, 2014 at 5:56 a.m. UTC
OSPF DR and BDR router election proces.
Which one router elect firt(DR? or BDR?) why?. from CCIE voluem I reference what i am understand is BDR is elected first and then DR is elected. it is confused meke me understand.
January 26, 2015 at 7:14 a.m. UTC
very good article! very helpful & have a good insight.
June 24, 2015 at 9:32 a.m. UTC
Good Explanation... @Satheesh, BDR will be elected first and if no other routers reports as DR then, the BDR will be promoted as DR
September 22, 2016 at 1:46 p.m. UTC
Annoyingly, this hit me with an upgrade to IOS-XE 3.16.3S, which allows you to configure both methods but only accepts the "newer" IP OSPF MD5... key