OSPFv3 authentication
By stretch | Wednesday, September 3, 2008 at 7:26 a.m. UTC
Most IPv4 routing protocols support some form of neighbor authentication, provided by either a plaintext password or MD5 HMAC. However, OSPFv3 (OSPF for IPv6) doesn't include any authentication capabilities of its own; instead, it relies entirely on IPsec to secure communications between neighbors. This is beneficial in simplifying the OSPFv3 protocol and standardizing its authentication mechanism.
Continuing from our OSPFv3 configuration lab, we can identify several points in the network where adding authentication would be prudent. In the real world, of course, it's considered best practice to implement authentication for all adjacencies, regardless of the apparent need.
First, because end users may be present in the 2001:db8:0:12::/64 subnet connecting R1 and R2, adjacency authentication in this subnet is critical. Second, since a diligent network engineer never trusts his service provider, we'll also implement authentication across the frame relay network. The IPsec Authentication Header (AH) protocol will be used to preserve packet integrity. Unfortunately, IOS doesn't currently support IPsec payload encryption via Encapsulating Security Payload (ESP). ESP can be configured with null encryption, but this has the same affect as configuring AH. (For reference, the OSPFv3 IPsec configuration guide for IOS can be found here.)
Enabling Authentication on the Interface
Currently, IOS requires IPsec for OSPFv3 be configured separate from the normal configuration of an IPsec policy; fortunately the entire configuration is accomplished with one line. As with legacy authentication, IPsec authentication can be configured either per-interface or per-area. We'll configure per-interface authentication between R1 and R2.
The first parameter to specify is the Security Policy Index (SPI). The SPI functions similarly to key numbers in a key chain, but is communicated via AH and must match between both ends of the adjacency. The SPI number is arbitrary, but must be between 256 and 4,294,967,295 (the 32-bit ceiling). We'll use the SPI of 256 for our lab.
Next we must decide on the type of authentication and the key string to use. AH provides authentication via either MD5 or SHA1, with a string length of 128 or 160 bits, respectively. Since SHA1 is the stronger algorithm, we'll choose it, and specify a random bit string as our key. Note that the key lengths must be exact: 40 hex digits (or 32 for MD5). For reasons outlined in section 7 of RFC 4552, the same keying is used for the SA in each direction between two OSPFv3 neighbors; this is in contrast to normal IPsec implementations, in which each unidirectional SA is built from its own unique keying via IKE.
R1(config-if)# ipv6 ospf authentication ipsec spi 256 sha1 24e692732d80fac4f6dc2b9abfb73678ef660bab
If you're feeling especially lazy, you can generate an SHA1 hash from random data with dd
and sha1sum
on a Linux or UNIX box:
LinuxBox$ dd if=/dev/urandom count=1024 | sha1sum 954644a966d69bc14f6148b0be865b803f3bc9c9 - 1024+0 records in 1024+0 records out 524288 bytes (524 kB) copied, 0.0940048 s, 5.6 MB/s
After configuring authentication on FastEthernet0/1 at both routers, you may notice the OSPFv3 adjacency drop and reform. The OSPFv3 interface display verifies that SHA1 authentication is in use:
R1# show ipv6 ospf interface f0/1 FastEthernet0/1 is up, line protocol is up Link Local Address FE80::1, Interface ID 5 Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 Network Type BROADCAST, Cost: 10 SHA1 authentication SPI 256, secure socket UP (errors: 0) Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 2.2.2.2, local address FE80::2 Backup Designated router (ID) 1.1.1.1, local address FE80::1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 6, maximum is 6 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 (Designated Router) Suppress hello for 0 neighbor(s)
Incidentally, we can also verify the state of the IPsec AH security associations in use:
R1# show crypto ipsec sa interface: FastEthernet0/1 Crypto map tag: (none), local addr FE80::1 IPsecv6 policy name: OSPFv3-1-256 IPsecv6-created ACL name: FastEthernet0/1-ipsecv6-ACL ... inbound ah sas: spi: 0x100(256) transform: ah-sha-hmac , in use settings ={Transport, } conn id: 1, flow_id: SW:1, crypto map: (none) no sa timing replay detection support: N Status: ACTIVE ... outbound ah sas: spi: 0x100(256) transform: ah-sha-hmac , in use settings ={Transport, } conn id: 2, flow_id: SW:2, crypto map: (none) no sa timing replay detection support: N Status: ACTIVE
To see what the AH-secured OSPF packets look like on the wire, check out this packet capture. Look for the AH extension in the IPv6 header.
Enabling Authentication for the Area
Configuring authentication for an area follows the same logic as for an interface. First we enter OSFPv3 router configuration, then specify the authentication parameters for the area:
R1(config)# ipv6 router ospf 1 R1(config-rtr)# area 0 authentication ipsec spi 500 sha1 954644a966d69bc14f6148b0be865b803f3bc9c9
Again, the SPI is an arbitrary value, and the key string must be the appropriate length for whichever hashing method (MD5 or SHA1) is chosen. The above configuration enables IPsec authentication for all of R1's interfaces in area 0 (which in our case is just Serial1/0). We can use the show ipv6 ospf interface
and show crypto ipsec sa
commands as we did in the first section to verify OSPFv3 authentication is in use. The show crypto ipsec policy
also provides a convenient overview of the authentication policies in use:
R1# show crypto ipsec policy Crypto IPsec client security policy data Policy name: OSPFv3-1-256 Policy refcount: 1 Inbound AH SPI: 256 (0x100) Outbound AH SPI: 256 (0x100) Inbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Outbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Transform set: ah-sha-hmac Crypto IPsec client security policy data Policy name: OSPFv3-1-500 Policy refcount: 1 Inbound AH SPI: 500 (0x1F4) Outbound AH SPI: 500 (0x1F4) Inbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Outbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Transform set: ah-sha-hmac
Posted in Routing
Comments
October 10, 2010 at 9:27 a.m. UTC
doesnt work :/ IPSECV6-4-RECVD_PKT_NOT_IPSECV6
May 10, 2011 at 12:54 p.m. UTC
Hi,
I tried this in my lab (simulated 72xx with IOS 15.1(4)M), but did not succeed. Neither authentication nor encryption does work. I tried it with interface-bound IPSEC-configuration, e.g.
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:1:12::/64 eui-64
ipv6 ospf 4711 area 0
ipv6 ospf encryption ipsec spi 256 esp 3des 79B6CE82C3E9C90F66CF5032E71A465282F11CE112312312 sha1 79B6CE82C3E9C90F66CF5032E71A465282F11CE1
end
"show ipv6 ospf interface fastEthernet 0/0" gives no errors:
FastEthernet0/0 is up, line protocol is up
[...]
3DES encryption SHA-1 auth SPI 256, secure socket UP (errors: 0)
[...]
debug output shows hellos going out, but no being received. As soon as I remove the encryption-command, everything works again.
Any clues?
Thanks,
airflow
June 7, 2011 at 10:55 p.m. UTC
@airflow Just tried your config in GNS3 "3700 Software (C3725-ADVENTERPRISEK9-M), Version 12.4(15)T14" and had no errors
February 8, 2015 at 12:53 a.m. UTC
I have the same issue as Airflow using the same IOS version on a 7206 in GNS3. I cannot seem to find a resolution either. All I see online related to this are users disabling the hardware on the router using "no crypto engine onboard 0" command and then "clear crypto sa" to fix it.
April 27, 2016 at 2:01 p.m. UTC
Excellent breakdown of the implementation of authentication for v6 OSPF deployment. Thank you for sharing.