Steps for configuring IP security policy

These steps are used to configure the specific security models.

Perform the following steps to configure IP security policy.

1. 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.
2. 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.
3. Determine the data endpoints to be protected. Typically, this is both a local and remote IP address, or subnetwork.
4. Determine what level of security is needed between each set of data endpoints. The level of security can be deny, permit, or ipsec.
5. Configure an IpGenericFilterAction statement for the level of security that is required (permit, deny, ipsec), including whether the connection should be logged.
6. If IPSec is required between any two endpoints:
   1. Configure a KeyExchangePolicy statement that defines the parameters of the phase 1 negotiation:
      1. Determine the required type and strength of protection for the phase 1 Security Association.
      2. 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.
      3. 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.
      4. Configure a KeyExchangeOffer statement.
      5. Determine negotiation mode, IKEv1 Main, IKEv1 Aggressive, or IKEv2.
      6. Configure a KeyExchangeAction statement.
      7. Configure a LocalSecurityEndpoint statement and RemoteSecurityEndpoint statement.
      8. Configure a KeyExchangeRule statement that includes the two endpoints and the key exchange action.
      9. Include the KeyExchangeRule statement in the KeyExchangePolicy statement block.
   2. Configure an IpDynVpnAction statement that defines the control of the phase 2 negotiation:
      1. Determine the required type and strength of IPSec protection for the phase 2 Security Association.
      2. Determine whether tunnel or transport mode is required. For an IKEv2 negotiation, the appropriate mode is chosen based on topology.
      3. Configure an IpDataOffer statement that defines the parameters of the phase 2 negotiation.
      4. Determine which peer should be allowed to initiate the negotiation.
   3. Decide how the Security Association is to be activated:
      1. Configure an optional LocalDynVpnPolicy statement, if command-line activated or autoactivated.
      2. 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.
      3. Either create an IpFilterRule statement that allows IPSec traffic (AH and ESP), or set the global PreDecap parameter of the IpFilterPolicy statement to off.
7. 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.
8. Define an IpFilterGroup statement for each zone and include the IpFilterRule statements that belong to that zone.
9. Include the IpFilterRule statements in the IpFilterPolicy block.
10. Include all configured statements in the IP security configuration file. For more information, see:
    • Steps for configuring local IP security policy using only a common IP security configuration file
    • Steps for configuring remote IP security policy using only a common IP security configuration file
    • Steps for configuring local IP security policy using only a stack-specific IP security configuration file
    • Steps for configuring remote IP security policy using only a stack-specific IP security configuration file
    • Steps for configuring local IP security policy using both a stack-specific file and a common file
    • Steps for configuring remote IP security policy using both a stack-specific file and a common file