HP-UX IPSec version A.02.01 Administrator's Guide
Troubleshooting HP-UX IPSec
IPsec Operation
Chapter 7 195
For the IPsec SAs to be successfully established, both systems must
agree on the type of transform (AH, ESP), including the
authentication or encryption algorithm used. They must also
negotiate SA lifetimes.
5. Add IPsec SAs to the Kernel SA Database
The IPsec SAs are added to the kernel SA database by the IKE
daemon. Each SA includes an SPI (Security Parameters Index) a
number assigned by the receiving system to reference the SA. The
SPI for outbound data is assigned by the remote system, while the
SPI for the inbound data is established by the local system. The SPI
is included in the AH or ESP header so that the destination system
can process inbound packets with the correct SA parameters
including encryption key(s).
Inbound Data
• AH or ESP Packet
If the inbound packet has an Authentication Header (AH) and/or an
Encapsulating Security Payload (ESP), HP-UX IPSec checks the
kernel SA database for inbound packets for an entry with the same
SPI and source IP address. If one exists, it uses the information in
the SA to properly decrypt or authenticate the packet. If the inbound
packet has multiple SPIs (a nested AH and ESP packet), HP-UX
IPSec searches the kernel SA database for each SPI.
If no matching entry exists, HP-UX IPSec will check if there is an
IKE policy that applies to the remote system. If there is not, this is
an error and possible intrusion attempt. HP-UX IPSec sends an
audit message to the audit daemon. HP-UX IPSec discards the
packet.
If the local system has an IKE policy that applies to the remote
system, HP-UX IPSec will assume that a valid IPsec SA previously
existed, but the SPI entry no longer exists because the local system
has re-booted. The local system will attempt to establish a new IKE
SA with the remote system, and to send an ISAKMP
INITIAL-CONTACT notify message. The INITIAL-CONTACT notify
message notifies the remote system that the local system has
re-started IPsec. The remote system may delete its information for
all SAs established with the local node and attempt to re-establish a
new SAs. If the remote system does not delete the SAs, an
administrator on the remote system must manually delete the SAs.