Prior to installing the IPSec/9000 product, check that your
system can accommodate the following product requirements and limitations.
Memory Requirements
The total size of the memory required (run-time only) for
the IPSec/9000 product is: 1 Mbyte.
Disk Requirements
The total size of the disk space required (run-time only)
for the IPSec/9000 product is 16 Mbytes. Requirements for variable-length
user files are listed below:
Policy file: minimum of 2019 bytes
per policy file. Alternate or test policy files should be stored
in a separate directory. The default file is: /var/adm/ipsec/policies.txt.
Audit file: This file can grow very fast if Informative
auditing is turned on. HP recommends 1 Mbyte for the Alerts and
Errors level of logging, 5 Mbytes for the Warnings level, and 200
or more Mbytes for the Informative message level. Informative auditing
could generate 3--5 Mbytes per hour. Audit files should be kept
in a separate directory or file system. The default directory is: /var/adm/ipsec/.
Configuration Utility Requirements
The IPSec/9000 configuration utility, ipsec_mgr, requires
a graphical display device. This can be a graphics monitor, an X
terminal display, a PC with X Server software installed, or a Linux
workstation running an X Server.
IPSec Limitations and Constraints
IPSec general limitations and constraints are described below:
Security for multiple destination
addresses (i.e. broadcast, subnet broadcast, multicast, and anycast
addresses) is not supported.
You cannot selectively encrypt or authenticate services
that use dynamic ports, such as NFS (Network File System) mountd,
NFS lockd, NIS (Network Information Service).
Manual keying is not supported but is provided for
diagnostic purposes only as a contributed tool under:
/usr/contrib/bin/ipsec_diag
IPSec/9000 systems cannot act as IPSec gateways
(IP packets to be forwarded cannot be encrypted or authenticated).
Iterated tunneling is not supported.
If an IPSec/9000 system crashes and the system had
previously established ISAKMP SA(s) with peer IPSec system(s), the
peer IPSec system(s) will not be able to use any existing ISAKMP
and IPSec SAs to initiate communication with the rebooted IPSec
system.
If the IPSec SA(s) are configured to be "Shared" (host-based),
the peer system will not be able to initiate any communication with
the re-booted system that would use the same IPSec SAs until the existing
IPSec SAs expire.
If the IPSec SA(s) are configured to be "Exclusive" (session-based), then
the peer system will be able to initiate IPSec encrypted or authenticated
communication with the rebooted system only if the ISAKMP SA(s)
are configured to use PFS (Perfect Forward Secrecy) until the ISAKMP
SA expires.
ISAKMP Limitations and Constraints
ISAKMP limitations and constraints are described below:
For Main Mode (MM) and Quick Mode
(QM) transaction exchanges, a single transaction request will timeout
after 25 seconds (5 attempts at 5 second intervals) which in turn
will timeout or terminate the transaction negotiation.
When timeouts occur, they usually occur during heavy network
traffic congestion. The application should try to re-establish the
connection after a connection establishment failure.
Secondary IP addresses configured for a single interface
card require that you configure a route to each peer IPSec system
where the secondary IP address is specified as the gateway to the
remote system.
For example: if the sending system has IP address 192.1.1.1
and the receiving system has IP addresses 192.1.1.11 (address for
the primary interface, such as lan0:0) and
192.1.1.12 (address for the secondary interface, lan0:1)
the network administrator must add the following host route on the
receiving system:
route add host 192.1.1.1 192.1.1.12
The current product supports the PFS of both IPSec
SA keys and the identity of the ISAKMP negotiating peers. The current
product does not support the PFS of merely the keys of an IPSec
SA.
For IPv6 systems, the only type of ISAKMP authentication
supported is preshared keys.
When using certificate-based ISAKMP authentication
(RSA signatures), IPSec/9000 checks that the identity sent by the
other node in the Main Mode (MM) negotiation matches information
in the other node's certificate. IPSec/9000 always sends
its local IP address as its identity in MM exchanges. IPSec/9000
accepts the following identification types from nodes it communicates
with:
IPv4 address (ID_IPV4_ADDR)
Fully Qualified Domain Name (ID_FQDN)
User-Fully Qualified Domain Name (ID_USER_FDN)
X.500 Subject Distinguished Name (DN, ID_DER_ASN1_DN)
Product Warning for IPv4
Discarding or requiring IPv4 ICMP messages (Internet Control
Message Protocol messages, IP protocol value 1) to be encrypted
or authenticated may cause connectivity problems. Normal network
operation may require IP to exchange ICMP messages between end-to-end
hosts and between an end host and an IP gateway (including router
devices). IP may need to exchange ICMP packets with gateway nodes
even though no user (end-to-end) services are being used to the
gateways.
Be careful when configuring the default IPSec policy or IPSec
policies that affect entire subnets, because you may inadvertently
cause ICMP messages to be discarded. You may also inadvertantly
require ICMP messages being transmitted or received from a non-IPSec
gateway or router to be authenticated or encrypted, which will also
cause ICMP packets to be discarded.
IP uses ICMP messages to transmit error and control information,
such as in the following situations:
IP may periodically send ICMP Echo
messages to gateways to determine if the gateway is up ("Gateway
Probes"). If no response is received, the gateway is marked "Dead" in
the IP routing table.
This feature is controlled by the IP kernel parameter ip_ire_gw_probe.
By default, this feature is enabled on all HP-UX systems. Refer
to the ndd man page for information on checking or changing this
parameter's value.
IP may use ICMP Echo messages with the "Don't
Fragment" flag and ICMP Destination Unreachable messages
with the "Fragmentation Needed" flag to set the
Path Maximum Transmission Unit (Path MTU).
This feature is controlled by the IP kernel parameter ip_pmtu_strategy.
Refer to the ndd man page for information on checking or changing
this parameter's value.
IP may send ICMP Redirect messages to redirect traffic
to a different gateway.
The transmission of ICMP Redirect messages is controlled by
the IP kernel parameter ip_send_redirects. By default, this feature
is enabled on all HP-UX systems. Refer to the ndd man page for information
on checking or changing this parameter's value.
IP may send ICMP Source Quench messages to request
the source system to decrease its transmission rate.
The transmission of ICMP Source Quench messages is controlled
by the IP kernel parameter ip_send_source_quench. By default, this feature
is enabled on all HP-UX systems. Refer to the ndd man page for information
on checking or changing this parameter's value.
Product Warning for IPv6
To ensure proper operation of IPv6
networks, IPSec/9000 always allows the following ICMPv6 messages
to pass in clear text:
You can configure IPSec/9000 policies to authenticate,
encrypt, pass, or discard the following ICMPv6 messages: