Local dynamic VPN policy

A local dynamic VPN policy is required only if the IPSec negotiation is started through command-line activation using the ipsec command, or through automatic activation due to a local dynamic VPN policy update. IPSec negotiations can be initiated in one of four ways:

• On-demand

  The negotiation initiates when an outbound IP packet matches a filter rule with an ipsec action.

• Remotely

  The remote peer initiates the request, and the local IKE daemon responds.

• Command-line activation

  The ipsec command enables you to manually initiate an IPSec negotiation. (Not to be confused with manual tunnels, which do not use the IKE daemon at all.)

• Autoactivation

  The negotiation begins when either the stack or the IKE daemon initializes and both are active, or when the local dynamic VPN policy is updated.

A local dynamic VPN policy is required only in the last two cases.

A local dynamic VPN policy consists of an unordered list of local dynamic VPN rules. The negotiation for a phase 2 Security Association requires that the two communicating hosts agree on two data endpoints that the Security Association covers, the protocols the Security Association covers, and the ports that the Security Association covers. This information is then stored in the phase 2 Security Association, which is consulted each time relevant IPSec traffic needs to be encapsulated or decapsulated. The purpose of the local dynamic VPN rule is to define these requirements for each Security Association that is configured.

The following sample LocalDynVpnRule statement defines the parameters for the negotiation of a phase 2 Security Association for TN3270E Telnet server traffic between a server (9.1.1.1) and a client (9.4.4.100). A description of each line follows the sample.

1  LocalDynVpnRule      TelnetSA
2  {
3          LocalIP           9.1.1.1
4          RemoteIP          9.4.4.100
5          LocalDataPort     23
6          RemoteDataPort    0
7          Protocol          tcp
8          Autoactivate      yes
9  }

Line

Description

1

The LocalDynVpnRule keyword and user-defined name.

2

An open brace ({) marks the start of the LocalDynVpnRule statement block.

3

The local address of IP traffic that this Security Association is to protect. The address can be either a single address or a range of addresses. However, if the address is not a single address, this Security Association must be negotiated for tunnel mode.

4

The remote address of IP traffic that this Security Association is to protect. The address can be either a single address or a range of addresses. However, if the address is not a single address, this Security Association must be negotiated for tunnel mode.

5

The local ports for IP traffic that this Security Association is to protect. The port must be either a single port or all ports. A range of ports is not allowed. A value of 0 indicates all ports.

6

The remote ports for IP traffic that this Security Association is to protect. The port must be either a single port or all ports. A range of ports is not allowed. A value of 0 indicates all ports.

7

The protocol that this Security Association is to protect. This value can be numeric. It must define a single protocol or all protocols.

8

Indicates that this Security Association is to be activated when the stack and IKE daemon are active. No user intervention is required.

9

A close brace (}) marks the end of the LocalDynVpnRule statement block.

An on-demand Security Association does not require a local dynamic VPN rule definition. All of the parameters for the negotiation of an on-demand phase 2 Security Association can be inferred from one of two places, either the packet that began the on-demand activation or the filter rule on which the packet matched. The packet always provides a single value for address, protocol, port, type, and code. The filter rule, however, can allow for a range of values for IP address, protocol, port, type, or code. The granularity setting of the IpLocalStartAction statement determines whether the information is taken from the packet or from the matching filter rule. For more information regarding the IpLocalStartAction statement, see z/OS Communications Server: IP Configuration Reference.

Security Associations can be defined as wide or narrow with respect to IP addresses or ports and protocols. If a Security Association is wide with respect to IP address, the same Security Association is used to protect data between multiple endpoints. If a Security Association is wide with respect to ports and protocols, the same Security Association is used to protect multiple traffic types. Conversely, a narrowly defined Security Association can be used to protect specific data endpoints (based on IP address) or specific traffic types (based on commonly used ports and protocols for network services). Security Associations negotiated with IKEv2 can also be narrow with respect to types and codes.