OSPF Authentication
There are several ways to enable authentication for OSPF, which can make the topic a little confusing.
OSPF authentication is carried in the OSPF header of every OSPF packet. There are three OSPF authentication types:
| Type | Use |
|---|---|
Type 0 | No authentication |
Type 1 | Plain text authentication. The password is in clear text. |
Type 2 | MD5 or HMAC-SHA authentication. The password is hashed. |
In all cases, the OSPF data itself is always in clear text. You cannot encrypt the OSPF data itself.
Type 0 (No Authentication)
This is of course the default authentication method. The authentication field is always present in the OSPF header, so when you don’t use authentication you will see “Auth Type: 0” on each OSPF packet:
The only situtation in which you need to explicitly configure null authentication, is when you have enabled type 1 or type 2 authentication for the OSPF area, and you want to set null authentication on an interface. As you would expect, interface-specific configuration “overrides” area-level configuration.
If you do not set null authentication on the interface in the situation above, the interface will use type 1 authentication with no authentication key, and the OSPF adjacency will not come up.
Type 1 (Plain Text Authentication)
As the name implies, the authentication password is simply in clear text in the OSPF header. In the OSPF header, you will see “auth type 1” for plain text authentication. An attacker could easily learn the password and apply it themselves to form an adjacency with a router on your network. I can only see this as being useful in situations where you don’t want to accidentally form an adjacency with other directly connected routers.
To configure this you need to enable authentication under the interface, or under the OSPF process:
Then set the password on the interface:
The type 1 password can be a max of 8 characters
As you can see, the password is in clear text:
The authentication is present in the OSPF header, not just the Hello. So every OSPF message will be authenticated. (The other message types are: DBDs, LSUs, LSRs, and LACKs).
Also notice that the packet data itself is still clear text. This is true whether you use type 1 or type 2 authentication. The OSPF data itself is always clearly visible.
To verify in the CLI, you can use the following show command:
If one side does not have authentication enabled, you will not form an adjacency on either side. The neighbor simply won’t be listed in show ip ospf neighbor. You can see the error using debug ip ospf adj.
Type 2 (MD5/HMAC-SHA Authentication)
With MD5 authentication, the password is hashed using MD5, instead of being present in clear text. This makes it much more difficult for an attacker to form an adjacency with your router. OSPF considers MD5/HMAC-SHA authentication “Type 2.”
Enabling MD5 authentication is very similar to using a clear text password. First, enable the authentication method as MD5 for the interface or the area:
Then set the key on the interface:
The password is now MD5 hashed. The packet data is still in plain text.
You can verify whether authentication is enabled:
The debug command shows intuitive output when one side does not have authentication enabled:
Type 2 Authentication with Key Chains
To make things slightly confusing, you can achieve the same MD5 authentication configuration as above with just a key chain. A key chain allows you to rotate keys and give each key a different start time and lifetime. We will simply enable single-key key chains with infinite lifetimes to demonstrate this feature.
To enable type 2 MD5 authentication, we can simply reference a key chain which has a key-string and a crypto-algorithm of md5. You do not need to enable the authentication type when using a key chain.
A key chain is required when using HMAC-SHA for hashing (instead of MD5). RFC5709 updated type 2 authentication to be able to use either MD5 or HMAC-SHA.
The key chain in the example above is effectively no different from using the command ip ospf message-digest-key 1 md5 cisco123, because we are using MD5 for hashing.
By default, when no accept or send lifetime is specified, the key is “always valid”
You can see that the interface uses a key chain now, instead of an MD5 key configured on the interface, with the following show command:
Further Reading
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13697-25.html
Last updated
