HP-UX IPSec Version A.03.00 Administrator's Guide

automatically establish IPsec SAs with the adoptive node as needed, without operator
intervention.
• HP-UX IPSec is compatible with redundant network interfaces. If Serviceguard fails over
from a primary interface to a standby interface, HP-UX IPSec will continue operating and
use the standby interface with no change in the operation of the Security Associations (SAs).
• HP-UX IPSec includes a monitor script, /var/adm/ipsec/ipsec_status.sh , that an
Serviceguard package can use as a package service to monitor HP-UX IPSec. You can
configure the package to fail or fail over if HP-UX IPSec is unavailable.
Client Failover Detection
If a package fails over to an adoptive node and a package client had IPsec SAs established with
the original package node, it is the responsibility of the client to detect the dead peer (the failure
of the original package node), and flush all IKE and IPsec SAs previously established with the
original node. Subsequent packets to the package address will trigger new IKE and IPsec SA
negotiations.
If a package fails over to an adoptive node and a package client had IPsec SAs established with
the original package node, the adoptive node will send INITIAL-CONTACT notify messages to
the package client. In this situation, the intention of the INITIAL-CONTACT notify message is
to notify the package client that it should delete existing SA information for the package address,
and establish new SAs as needed.
If the IKEv1 protocol is used, the expected sequence of events is as follows:
1. The client sends a cryptographically protected packet to the adoptive node using an IPsec
or IKE SA established with the original package node.
2. The adoptive node does not recognize the Security Parameters Index (SPI). This causes the
adoptive node to send an INITIAL-CONTACT notify message to the client.
3. The client interprets the INITIAL-CONTACT notify message as an indication that the peer
was down and has now restarted. The client deletes any existing SA information for the
package address. Subsequent packets to the package address trigger new IKE and IPsec SA
negotiations.
If a package client is an HP-UX system using a version of HP-UX IPSec released prior to
A.01.07, or if it is not an HP-UX system, the package client may not delete SA information
when it receives the INITIAL-CONTACT notify message. In these cases, an administrator
must manually delete the SAs on the package client.
If the IKEv2 protocol is used, the expected sequence of events is as follows:
1. The client sends a cryptographically protected packet to the adoptive node using an IPsec
or IKE SA established with the original package node.
2. The adoptive node does not recognize the Security Parameters Index (SPI). This causes the
adoptive node to send an unencrypted IKEv2 Notify payload indicating an invalid SPI.
3. The client starts a liveness test with the adoptive node by sending an empty
INFORMATIONAL message (an IKE header followed by an encrypted payload that contains
no payloads) that requires an acknowledgement.
4. The adoptive node does not respond because it does not have any SAs established with the
client. The client's INFORMATIONAL message times out. The client presumes that the
original peer (the original package node) is dead based on the repeated failures to receive
acknowledgements.
The client deletes all IKE and IPsec SAs it had previously established with the original packet
node. Subsequent packets to the package address trigger new IKE and IPsec SA negotiations.
Introduction 223