In a production network it’s always a good idea to use authentication between the routers if dynamic routing is in place. It’s because if an attacker can make connection from a rogue router to one of our routers, he/she can provide false information about routes and can cause several problems. To prevent this, we use authentication: we’ll accept information from valid sources only. Every common routing protocol has a mechanism to authenticate the peers: under IPv4 of these mechanisms are different from protocol to protocol, but under IPv6 we can use a more common method. In this article we’ll look at OSPF authentication using a GNS3 lab.

The IPv4 topology is relatively simple, but we can experiment all of the authentication options:

We’ll use a self-explanatory IP addressing scheme, and routers use their ID as last octet in the IP addresses (for example R1 uses 12.0.0.1 on the connection to R2). OSPF is preconfigured in the attached GNS3 lab file, so we can concentrate to the authentication.

First some dry theory: OSPF uses three types of authentication, from Type 0 through Type 2. Type 0 or “null-authentication” is the default, and it’s a very strange “authentication” as it provides no authentication at all. So we can accept any router as our peer and accept all information from them. Type 1 authentication is a shared key, plaintext method. Unfortunately it’s not so secure. The shared password is a maximum of eight characters long, and transmitted in cleartext between the routers. Type 2 method is the most secure as it uses MD5 hashes, composed from a key ID, a key value and the content of the packet. In this case the password doesn’t traverse the network, and it’s almost impossible to guess it’s just from the hash value.

When we initially configure OSPF, the hello packets contain information about the authentication mechanisms in use. Let’s capture some traffic with Wireshark and look at a hello package. Right click, for example, on the link between R1 and R2 and choose Start capture. Wireshark will start (if not, we can start it manually from the same menu). Choose any hello packet and examine the contents:

As we can see, the OSPF header contains information about authentication also: the type and corresponding data.

Now let’s configure Type 1 authentication. There are two main steps. First we need to enable authentication globally in router configuration mode for the area, then set the parameters on the interfaces. Go to R1, and configure the connection to R2:

We have to define the password in interface configuration mode, after we enabled the plaintext method for the area, and enabled it on the interface also. This latter step is unnecessary if we use the same authentication method everywhere in the area, but this is the full form of it. Now, if we wait for awhile, we can see a console message stating that our neighbors are down because the dead timer expired. Why? The reason is simple: our router already accepts authorized packets only. The other routers, on the other hand, still use null authentication. We can easily make sure if we start a debug session:

To correct this error, go to R2 and configure its link to R1 in the same way we did on R1. The neighborship comes alive between R1 and R2, but R3 still isn’t in the club. Let’s configure the link between R2 and R3 with a different password just to demonstrate that it has local preference on a given link. Here are the necessary commands on R2:

We can observe another thing here. We didn’t specify authentication methods for the area on R3, but the neighborship established with R2, but not with R1. It means that we can define authentication on the interface level independently from the global setting. By the way, the global setting can be checked by the show ip ospf command. Issue it on R3 and search for the sentence that states “Area has no authentication”. On the other hand, on R1 or R2 it gives the following output: “Area has simple password authentication”. Now, if we set Type 1 authentication on R3 in router configuration mode, R1 will be a neighbor even if we didn’t provide any password on serial interfaces that interconnects them. It shows that an empty password is valid for Type 1, although it’s not a good practice. If we want to compare this with using a real password, make packet captures on the serial link (note that we need to select HDLC encapsulation!) and on a FastEthernet link. In the first case we’ll get the following:

While capturing traffic between R1 and R2 shows:

The difference is in the Auth Data field.

There’s one more thing to mention about Type 1 authentication. As stated before, maximum password length is eight characters, and as can be seen on the next figure, it’s a hard limit:

Next try the much more secure Type 2 authentication method. The easiest way to start with a clean slate is to close and open again our lab, this way OSPF works again without authentication. The configuration of MD5 method is similar to the simple text authentication: we need to define it under router configuration mode for the area, then on interface level. Start it on R1:

Look at the message-digest keyword. This enables Type 2 mode for the area and on the interface also. The authentication data is the key, which has a key ID from the range of 1 to 255, the type of the algorithm (in this case it’s MD5 – although you cannot choose another method, it has to be defined) and the key value, a password, which can be a maximum of 16 characters long.

At this stage, the neighbors of R1 will go down just like in the previous lab as they use different authentication modes. Check it with a debug session on R1:

Let’s configure R2, but intentionally with an error – use another key ID as on R1:

We can see that neighbor R3 went down, and neighbor R1 won’t come up, although we specified the authentication mode and the key value correctly. But we use key ID 11 instead of 1 – this is a typo we can easily make. See what debugging says in this case:

Debug is a very useful tool, isn’t it? The last row tells the reason of the error, so correct it: delete key 11 on R2 (with the no ip ospf message-digest-key 11 command), and create the correct key. When neighbors are up, make a packet capture to see a Type 2 authenticated packet:

The picture above just shows the OSPF header from a hello packet between R1 and R2, but it’s clear that we cannot easily decrypt the password from this data. OK, finally simulate another common configuration error with R3: use a wrong password value on the interface that connects it to R2 (before this, configure the password “Cisco1” on R2, but use “Cisco11” on R3). When we run debug on R2, we can see the following:

The neighborship with R1 seems to be OK, but with R3 there’s trouble. In this case we need to check the key values on both sides with the show running-config command. To correct the error, delete the key from R3 and configure the right value.

In the meantime you may have noticed that R3 became neighbors with R1, although we didn’t specify any keys on the serial link. It’s the same as we saw in Type 1 authentication, but obviously it’s not the preferred way to use Type 2 method without any key.

Finally we can mix the methods. On the serial link we use Type 1 authentication, independently from the other links. It can be done because if we specify an authentication method on an interface, it overrides the setting in router configuration mode. Configure R1 and R3 with a simple password of “Cisco2”, but don’t forget to issue the ip ospf authentication command. Without this the routers want to use Type 2 mode as defined in router configuration mode. If all is well, issue the show ip ospf interface command on R1 – this can be used to check what type of authentication has been configured on a particular interface. On f0/1 it shows the following:

while on s0/1 it says:

When we use IPv6, the way we configure authentication is rather different. Because IPv6 has a built-in security protocol called IP Security or IPSec (which is implemented for IPv4 also, but initially for IPv6), we can use that, and not only in OSPF, but with other routing protocols also. IPSec provides packet authentication and/or encryption. If we just want to authenticate the packets, we use the Authentication Header (AH). If we need encryption also, we use Encapsulated Security Payload (ESP). If you’re not familiar with these, look at the links at the end of the article.

In these days the authentication with AH is a bit deprecated, so we’ll see the ESP method used in conjunction with OSPFv3, the version for IPv6. If we need a new lab with proper IPv6 and OSPFv3 basic settings, the topology is the following:

In OSPFv3 we need to specify router IDs as IPv4 addresses, and because we have a pure IPv6 addressing scheme, we need to specify it by the router-id command (I used 1.1.1.1, 2.2.2.2 and 3.3.3.3).

Let’s configure the authentication by ESP, which supports authentication only, just like AH. We can configure authentication on an interface basis, or for the area. First we’ll configure this for the area. We need to issue the following command on every device in router configuration mode (the whole text is one line):

area 0 encryption ipsec spi 2001 esp null sha1 9FB05A29FF2E08796BD836BEC16C95AAF532D032

Examine this a bit. If we want to use ESP we need to specify the encryption keyword. The spi stands for Security Parameter Index. Think of it just like a key index in Type 2 authentication. It’s a 32-bit number in the range of 256 to 4294967295. In this case we don’t want encryption, so we specified the null keyword. At the end we specify SHA1 algorithm along with the key value as a 40 characters long hexadecimal string. You can generate this in the following way:

  • enter 20 into the field of bytes to generate (because one byte consists of 2 hexadecimal digits)
  • set the type as Hexadecimal
  • click on Get bytes, copy the result into a text editor and remove spaces.

During the configuration we can see a message just like this:

It’s normal. It just states that the neighbor router still doesn’t send an IPSec packet. After successful configuration we can check the settings. This is an excerpt from show ipv6 ospf command:

The most verbose output can be produced by the show crypto ipsec sa command.

Now try to use an even more secure method: ESP on interface basis, with encryption. We’ll use the same link as before, the serial connection between R1 and R2 to demonstrate the commands necessary, and the configuration overrides the one entered for the whole area. Although this is more complex to configure, on the links where we expect crackers to access our routers even more secure method. Enter the following command on R1 for the s0/1 interface (again, the whole text is one line):

ipv6 ospf encryption ipsec spi 2002 esp aes-cbc 192 9FB05A29FF2E08796BD836BEC16C95AAF532D032DEF3EAF5 sha1 9FB05A29FF2E08796BD836BEC16C95AAF532D032

We used another SPI value in this case, and specified an encryption method of aes-cbc (Advanced Encryption Standard – Cypher Block Chaining) which considered one of the most secure protocols, along with a 192-bit key. The key string is 48 characters long which have been generated the same way as the first example (of course, the length entered on the form was 24). We used SHA1 for data integrity check as before. Now we can see the following in the output of show ipv6 interface s0/1 command:

AES-CBC-192 encryption SHA-1 auth SPI 2002, secure socket UP (errors: 0)

We can experiment with the various settings under IPSec, but I hope that this was enough to get the idea behind configuration OSPF under IPv6.

Useful links:

The basics of IPSec: http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/16439-IPSECpart8.html

Online random generator: https://www.random.org/

OSPFv3 with ESP configuration: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-mt/iro-15-mt-book/ip6-route-ospfv3-esp.html