We know that two OSPF routers will become neighbours if they can agree on certain parameters (see my previous post for details) and this is great, but suppose the bad guys were able to connect their own router to the same data link and then cause OSPF routing mayhem – how do we stop this???
Authentication is the answer, and here’s how we do it.
With authentication enabled, every OSPF message sent between routers is authenticated using a pre-shared key. If authentication fails then routers will drop the hello packets, meaning an adjacency cannot form.
Authentication is enabled either per interface or per area, and there are three types of OSPF authentication
- type 0 – none
- type 1 – clear text
- type 2 – MD5
The first example is per interface, type 2 authentication (type 1 is pointless anyway!). Here’s our configuration on R1 (with a matching config on R2):
interface Ethernet0/0 ip address 10.0.0.1 255.255.255.252 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 CCNPBABY!
To verify this, the show ip ospf interface command will show us that MD5 authentication is enabled and the id of the key being used:
R1#show ip ospf interface
Ethernet0/0 is up, line protocol is up
Internet Address 10.0.0.1/30, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
Backup Designated router (ID) 1.1.1.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:04
Supports Link-local Signaling (LLS)
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 4 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
We can also turn on some debugging of ospf packets to verify. The output below shows that type 2 authentication is being used with key id 1:
R1#debug ip ospf packet
OSPF packet debugging is on
R1#
*Mar 1 00:18:00.455: OSPF: rcv. v:2 t:1 l:48 rid:2.2.2.2
aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x3C7EC8A1 from Ethernet0/0
The second example is per area, type 2 authentication. Here’s our configuration on R1 (with a matching config on R2):
! router ospf 1 router-id 1.1.1.1 log-adjacency-changes area 0 authentication message-digest network 10.0.0.0 0.0.0.3 area 0 ! ! interface Ethernet0/0 ip address 10.0.0.1 255.255.255.252 ip ospf message-digest-key 1 md5 CCNPBABY! full-duplex
Use the same debugging and show commands as for the per interface config to verify, and you can now sleep a whole lot better at night knowing your OSPF network is secure!
I hope this has been a useful explanation. Thanks for reading, and good luck with your CCNP studies!
Rich
Follow Rich on Twitter