OSPFv3 Authentication Trailers – IPv6 Capitulations

/ Blog, IPv6, IPv6 Security

A few weeks ago, the IETF updated the newest in a long line of what I like to call “IPv6 capitulations.”  Going on a rant here – the IETF fought long and hard to have a robust, secure, and interoperable protocol with IPv6.  This is one of the many examples where it is being systematically made to “look like IPv4.”  You might be asking, “Didn’t OSPFv3 already have authentication? Wait is this an April Fool’s RFC?”  No my friend, this is basically another way to do OSPFv3 authentication, less securely.

How we used to do it and how you should still do it – IPsec

In 2006, I think all of us network engineers were very comfortable knowing that IPv6 was going to bring some pretty sweet code.  Albeit, very intimidating at first, we eventually came around that this is how the Internet SHOULD be built.  We knew using OSPF would still be one of the preferred and open interior gateway routing protocols.  We also knew that IPsec was the way to securely authenticate and and encrypt transport communications.  The folks at DARPA didn’t know this then, but we know it now.  So when the IETF approved RFC 4552 – Authentication and Confidentiality for OSPFv3, we were sure the long process of building a new secure Internet was going to be awesome.

With RFC 4552, IPv6 (with IPsec) is natively used to authenticate OSPFv3 adjacencies.  It uses the native support of the IPv6 extension header (Authentication Header) and in some cases, where supported, the Encapsulation Security Payload (ESP) header.  With the ESP header you can not only authenticate adjacencies, but encrypt all routing LSAs.  It’s a great use of integrating all the things about IPv6 together.  Take a look at the packet below to see what I mean:

ospfv3-ah

OSPFv3 Authentication Trailers

I must say this standard didn’t come out of the blue.  The earlier standard, RFC 6506, has been out since 2012.  This was likely a compromise done in the IETF to allow other routing devices to not have to implement hardware-assisted modules, like ASICs, to help drive and process all of these IPsec packets and flows.  Either way, the standard is now here.  Also, Cisco already has support for the older RFC in all of the IOS trains 15.x and up.   So I am sure it is likely included in other routing manufacturers as well.

Configuring OSPFv3 with Authentication Trailers – Cisco

Configuration snippet below from Cisco on the previous link.  First you would create the algorithm and key:

key chain ospf-1 
key 1 
   key-string ospf 
   cryptographic-algorithm hmac-sha-512

Then set the key chain to the interface and/or router ospfv3 process:

interface Ethernet 0/0
 ospfv3 1 ipv4 authentication key-chain ospf-1
 router ospfv3 1
  address-family ipv6 unicast vrf vrf1
   area 1 virtual-link 1.1.1.1 authentication key-chain ospf-chain-1
   area 1 sham-link 1.1.1.1 authentication key-chain ospf-chain-1
   authentication mode deployment

Key items to note here:

  • There is support for address families (i.e. running OSPFv3 for both IPv4 and IPv6 routes)
  • Hey, at least it’s not MD5, and has up to SHA512?
  • The authentication modes are (1) strict – expired keys cannot be used for sending or receiving packets; (2) deployment – provides adjacency between configured and unconfigured authentication devices; and (3) normal – default.

 

Scroll to Top