These steps are used to configure the specific security
models.
Procedure
Perform the following steps to configure IP security
policy.
- Determine the number of zones to be protected. A zone typically
equates to a subnetwork that is reachable by the host server, but
can be any group of IP addresses that are conceptually related. The
internal network can be defined in one or several zones, while any
external network or group of networks can be placed in separate zones.
Each zone should have meaning related to the site's security policy.
If a zone maps to a physical interface, optionally assign a security
class to all interfaces in that zone.
- For each zone, determine what services are allowed and
define an IpService statement for each wanted service. Services are
defined by the protocols and well-known ports that they use.
- Determine the data endpoints to be protected. Typically,
this is both a local and remote IP address, or subnetwork.
- Determine what level of security is needed between each
set of data endpoints. The level of security can be deny, permit,
or ipsec.
- Configure an IpGenericFilterAction statement for the level
of security that is required (permit, deny, ipsec), including whether
the connection should be logged.
- If IPSec is required between any two endpoints:
- Configure a KeyExchangePolicy statement that defines
the parameters of the phase 1 negotiation:
- Determine the required type and strength of protection for the
phase 1 Security Association.
- Decide what type of peer authentication will be used:
- If digital signature, set up RACF® certificates
and certificate authority information.
- If pre-shared key, create a secret key that is known to both peers.
- Decide whether NAT traversal will be allowed. If the network topology
contains one or more NAT devices that must be traversed by the phase
1 Security Association, NAT traversal should be allowed.
- Configure a KeyExchangeOffer statement.
- Determine negotiation mode, IKEv1 Main, IKEv1 Aggressive, or IKEv2.
- Configure a KeyExchangeAction statement.
- Configure a LocalSecurityEndpoint statement and RemoteSecurityEndpoint
statement.
- Configure a KeyExchangeRule statement that includes the two endpoints
and the key exchange action.
- Include the KeyExchangeRule statement in the KeyExchangePolicy
statement block.
- Configure an IpDynVpnAction statement that defines the
control of the phase 2 negotiation:
- Determine the required type and strength of IPSec protection for
the phase 2 Security Association.
- Determine whether tunnel or transport mode is required. For an
IKEv2 negotiation, the appropriate mode is chosen based on topology.
- Configure an IpDataOffer statement that defines the parameters
of the phase 2 negotiation.
- Determine which peer should be allowed to initiate the negotiation.
- Decide how the Security Association is to be activated:
- Configure an optional LocalDynVpnPolicy statement, if command-line
activated or autoactivated.
- Configure an optional IpLocalStartAction statement, if the Security
Association is to be activated locally (that is, on-demand, command-line,
or autoactivation) and one of the security endpoints is acting as
a security gateway (that is, not a host-to-host Security Association).
Include a reference to the IpLocalStartAction statement in the IP
filter rule.
- Either create an IpFilterRule statement that allows IPSec traffic
(AH and ESP), or set the global PreDecap parameter of the IpFilterPolicy
statement to off.
- Define an IpFilterRule statement for each set of data endpoints. The rule should include the services that are allowed (one IpService
statement for each allowed service), and the level of security that
is required (a reference to the IpGenericFilterAction statement).
If IPSec is required, create an IpFilterRule statement that allows
IKE traffic (UDP, port 500). If NAT traversal is allowed, create an
IpFilterRule statement that allows IKE UDP traffic on port 4500.
Rule: To allow IKE negotiations for Security
Associations, IKE traffic (port 500, and optionally port 4500 for
NAT traversal) must be permitted in the clear.
- Define an IpFilterGroup statement for each zone and include
the IpFilterRule statements that belong to that zone.
- Include the IpFilterRule statements in the IpFilterPolicy
block.
- Include all configured statements in the IP security configuration
file. For more information, see: