OSPFv3 with IPsec Authentication

Authentication, Cisco Systems, IPsec/VPN, IPv6, Routing, , , , , , , , , , , , , , ,

Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.

Note that I already published another lab about OSPFv3 for IPv6 with different routers and firewalls. This time I merely used three Cisco routers (2x 2851, 1x 2811, all with IOS version 15.1(4)M12a) but with IPsec authentication.

Laboratory

This is the complete lab with OSPFv3 in the middle between R4/R5 and R1:

Some notes about it:

  • single backbone area 0.0.0.0
  • passive-interface default
  • R4 and R5 distributing their default route ::/0
  • R1 is redistributing its routes learned from EIGRP, “Type-5 AS External Link States”
  • R1 also has a summary-prefix, just to have some variance in the lab. Note the “via Null0, directly connected” route in the show commands section.
  • OSPFv3 authentication via IPsec authentication header AH, manually configured on the involved interfaces with “ipv6 ospf authentication ipsec spi 2311 sha1 …”.
  • These “type 7 encrypted” stored passphrases can be reverted to its plain text values via password crackers. In my lab I used a randomly generated hex-string of 40 chars with KeePass pattern h{40}.
  • This automatically adds an IPv6 access-list. Refer to the show commands below where you can also see the appropriate IPsec crypto security associations.
  • In the trace file you’ll see the following three link-local IPv6 addresses:
    • R4: FE80::215:62FF:FE6A:FEF1
    • R5: FE80::225:45FF:FE60:17C1
    • R1: FE80::21E:7AFF:FE79:3F10

The configuration commands for all three routers are:

 

pcapng

Here you can download the zipped pcapng file. I captured in on R1 port fa0/0:

One more time I used my ProfiShark 1G for capturing the packets between the routers. See it hanging around in my lab. ;)

Analyzing the dump file with Wireshark you can see for example:

  1. The IPv6 Authentication Header. Note the “Next Header” field in the former packet, that is: the IPv6 header lists “Authentication Header” as the next header, while the authentication header lists “OSPF” as its next header.
  2. Note that OSPF is not a TCP/UDP protocol but an own IP protocol with number 89, refer to the IANA Protocol Numbers.
  3. OSPF update packet with LSA type 9 intra-area prefix LSA or
  4. OSPF update packet with LSA type 5 AS-external LSA advertising the default route ::/0 from both upstream routers in my lab, R4 and R5.

show

Finally, here are a few (many ;)) show commands from the router R1. Note the “SHA–1 authentication SPI 2311” line at the neighbor, and the automatically generated IPv6 access-list entry and crypto policy:

 

Final note: I also tried to encrypt the OSPFv3 messages with IPsec/ESP aka “ipv6 ospf encryption …” rather than “ipv6 ospf authentication …” but I did not succeed. While I was able to configure those commands on all three routers without any errors (and also saw a couple of encrypted IPsec/ESP packets on the wire), no single neighborship was formed. Some further investigation using the Cisco Feature Navigator revealed that this feature called “OSPFv3 IPSec ESP Encryption and Authentication” is not available in the IOS version I am using in my lab (15.1(4)M12a) while the authentication featured called “IPv6 Routing: OSPFv3 Authentication Support with IPsec” in fact is. Don’t know why I was able to configure those commands while not fully implemented by Cisco?!?

Have a N.I.C.E. day!

For more posts about routing/switching you can follow the “Routing” or “Switching” categories concerning various firewall/router vendors, or the “Cisco Router“/”Cisco Switch” tags for posts related to Cisco stuff.

Featured image “saentis_2017-09-21_32” by Jérôme is licensed under CC BY-NC-SA 2.0.

One thought on “OSPFv3 with IPsec Authentication”

  1. Great article, thanx Johannes!

    When I’m configuring an IPv6 routing interface, I like to statically configure the Link-Local (LL) Interface ID (IID) portion to match the same as I have for the IID portion of a GUA (and/or ULA).

    For example, on your R4 loopback interface add ‘ipv6 address fe80::14 link-local’. For R4 g0/0 add ‘ipv6 address fe80::24 link-local’. Now the interfaces v6 IID’s are the same per interface, a little easier to remember.

    Where this really provides even more value, the configuration is now portable. The normal default for most L3 switches and routers (that I have worked with) is for the IID to be auto-generated by the OS using the M-EUI-64 format, and if you configure static routes using the neighbor’s LL as required, if a physical neighbor gets replaced, the MAC address of interfaces changes and so does the M-EUI-64 generated address, which therefore means a static route definition is no longer going to work. With the static LL definition, the device configuration file is totally portable – from an IPv6 thinking view at least.

    Most L3 switch and router OS’s do support static LL config. What I have found is some firewall OS’s that support v6 routing don’t support static LL config, nor do most client OS’s and some server OS’s.

    I’ll say that while doing this is not “required” I consider it an IPv6 “best practice”.

    Thanx again…Jeff

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *