In order to ensure that OSPFv3 packets are not altered and re-sent to the device, causing the device to behave in a way not
desired by its system administrators, OSPFv3 packets must be authenticated. OSPFv3 uses the IPsec secure socket API to add
authentication to OSPFv3 packets. This API supports IPv6.
OSPFv3 requires the use of IPsec to enable authentication. Crypto images are required to use authentication, because only
crypto images include the IPsec API needed for use with OSPFv3.
In OSPFv3, authentication fields have been removed from OSPFv3 packet headers. When OSPFv3 runs on IPv6, OSPFv3 requires
the IPv6 authentication header (AH) or IPv6 ESP header to ensure integrity, authentication, and confidentiality of routing
exchanges. IPv6 AH and ESP extension headers can be used to provide authentication and confidentiality to OSPFv3.
To use the IPsec AH, you must enable the
authentication command. To use the IPsec ESP header, you must enable the
encryption command. The ESP header may be applied alone or in combination with the AH, and when ESP is used, both encryption and authentication
are provided. Security services can be provided between a pair of communicating hosts, between a pair of communicating security
gateways, or between a security gateway and a host.
To configure IPsec, you configure a security policy, which is a combination of the security policy index (SPI) and the key
(the key is used to create and validate the hash value). IPsec for OSPFv3 can be configured on an interface or on an OSPFv3
area. For higher security, you should configure a different policy on each interface configured with IPsec. If you configure
IPsec for an OSPFv3 area, the policy is applied to all of the interfaces in that area, except for the interfaces that have
IPsec configured directly. Once IPsec is configured for OSPFv3, IPsec is invisible to you.
The secure socket API is used by applications to secure traffic. The API needs to allow the application to open, listen,
and close secure sockets. The binding between the application and the secure socket layer also allows the secure socket layer
to inform the application of changes to the socket, such as connection open and close events. The secure socket API is able
to identify the socket; that is, it can identify the local and remote addresses, masks, ports, and protocol that carry the
traffic requiring security.
Each interface has a secure socket state, which can be one of the following:
NULL: Do not create a secure socket for the interface if authentication is configured for the area.
DOWN: IPsec has been configured for the interface (or the area that contains the interface), but OSPFv3 either has not requested
IPsec to create a secure socket for this interface, or there is an error condition.
GOING UP: OSPFv3 has requested a secure socket from IPsec and is waiting for a CRYPTO_SS_SOCKET_UP message from IPsec.
UP: OSPFv3 has received a CRYPTO_SS_SOCKET_UP message from IPsec.
CLOSING: The secure socket for the interface has been closed. A new socket may be opened for the interface, in which case
the current secure socket makes the transition to the DOWN state. Otherwise, the interface will become UNCONFIGURED.
UNCONFIGURED: Authentication is not configured on the interface.
OSPFv3 will not send or accept packets while in the DOWN state.