OSPFv3 AH authentication IOS-XR

Five ospf routers goes to Kalbin McCormick's bar.  Who get's the car keys?  The designated router !

Okay a lame joke  : )


OSPFv3 supports either Authentication or Encryption for OSPFv3.  OSPFv3 supports both unicast address families for ipv4 and ipv6. If you recall theses earlier posts of mine where I discuss a simple OSPFv3 configuration.

http://socpuppet.blogspot.com/2013/12/ipv4-ospf-routing-with-ospfv3.html

http://socpuppet.blogspot.com/2012/11/exploring-ipv6-ospf-routing-on-cisco-asa.html



In this blog I will show you just how easy it is to  craft a SPI and ipsec for IOS-XR using authentication. Here's a basic OSPFv3 configuration with no authentication.

1st you will need to define a SPI values. Here's I'm using a SPI #256 with the password defined.

trick: use  the unix md5 hasher  to build a string if you don't want to count out the characters. This can save a lot of time and you can easily define a value if you define not enough character the command will failed when you try to commit.

 Now the show command will net the  details for the interface and you can see the  SPI# and that authentication is enabled.

A tip;  the ospfv3 protocol requires a  defined ipv4  "router-id" value. So that means it will select a ipv4 address and if a loopback access, it will use that address. But what if you have a ipv6 only network, and no ipv4 interface? You can "define" any ipv4 address regardless if it's a real in-use address on the router.

Now by using  tshark and by displaying a packet.capture, here's how your ospf header looks like now. Notice the value are not encrypted because we have authentication-header enabled.

And here's a ospf  header with no authentication-header attached;

note: the use of authentication header  #51 will increase the packet size by 24bytes.

If you want to use SHA1, the cfg is similar just the hash needs to be 40 characters. You can use a sha1 generator if it helps with crafting the  hash value.

In all setups, the OSPFv3 with AH  will allow you inspect the OSPF_header and you can trouble-shooting 99% of the neighbor_adj issues by looking at the AH and OSPF headers.

Just like with ipv4 and OSPF you will need to ensure the following;

•    OSPF timer match hello/dead
•    router-id are set and unique for all ospfv3-speakers
•    SPI# number match ( for Authentication ipsec )
•    AH authentication type matches ( all devices need to be  the same algo md5 or sha1)
•    AH hash ( aka password value is the same across all OSPFv3 speakers )
•     and finally the same OSPF area type ( stub , backbone, NSSA, etc.......) 

 keep in mind if you use encryption you can't  see these issues since the packets are encrypted. With IPSEC-AH you can easily diagnose most OSPFv3 issues with ease & without access to the router/firewall.


With in cisco IOS/IOS-XR all OSPFv3 log messages are listed with the ipv4 router-id. So IMHO if you don't run  ipv4 natively you want to ensure your router-id matches the ipv6 address to same degree

e.g
ipv6 == 2001:db8:199::1   ipv4 == x.x.x.1
ipv6 == 2001:db8:199::2   ipv4 == x.x.x.2
ipv6 == 2001:db8:199::3   ipv4 == x.x.x.3

It's hard enough trying to match devices  to what router went down/up  by the log messages when you have a ipv4 address that's not carried or known readily .

A sample  show neighborship command ASR9001;

Ken Felix
NSE ( network security expert) and Route/Switching Engineer
kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^
=(  @  @ )=
         o 
        /  \