OSPFv2 Authentication Confusion

Suppose we have two directly connected IOS routers running OSPF, configured as follows:

R1

router ospf 1
 router-id 1.1.1.1
!
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

R2

router ospf 1
 router-id 2.2.2.2
!
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 1.1.1.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) 2.2.2.2, Interface address 192.168.0.2
  Backup Designated router (ID) 1.1.1.1, 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 2.2.2.2  (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 1.1.1.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) 2.2.2.2, Interface address 192.168.0.2
  Backup Designated router (ID) 1.1.1.1, 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 2.2.2.2  (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.