Sysplex-Wide Security Associations and IP security
z/OS® IP security supports Sysplex-Wide Security Associations (SWSA). In a sysplex environment, SWSA distributes IPSec Security Associations (SAs) to the target stacks of distributed DVIPAs. To enable this support for IPv4 DVIPAs, you must code IPCONFIG IPSECURITY in the TCP/IP profile and DVIPSEC in the IPSEC block. To enable this support for IPv6 DVIPAs, you must code IPCONFIG6 IPSECURITY, in addition to IPCONFIG IPSECURITY and DVIPSEC.
You should add DVLOCALFLTR, the DVIPSEC subparameter,
to the IPSEC statement block of the TCP/IP profile when intra-sysplex
traffic should be protected by security associations. DVLOCALFLTR
enables IP filtering and IPSec protection of TCP traffic between a
client and an IPv4 dynamic VIPA that are defined on the same TCP/IP
stack, when the traffic is forwarded to another TCP/IP stack. When
the DVLOCALFLTR parameter is configured, ensure that the IPSec policy
accounts for all local TCP traffic with an IPv4 dynamic VIPA endpoint.
Traffic that does not match a configured IP filter rule is denied.- The IKEv1 protocol cannot be used to negotiate a tunnel between a client and an IPv4 dynamic VIPA that are defined on the same TCP/IP stack. You must use the IKEv2 protocol to negotiate a tunnel to protect the traffic. Use HowToInitiate IKEv2 on the KeyExchangePolicy statement or a specific KeyExchangeAction statement to indicate that the IKEv2 protocol must be used when this system starts key negotiations.
- A tunnel cannot be negotiated if the source and destination IP addresses for client connections are the same dynamic VIPA. To help avoid this scenario, do not code a dynamic VIPA that can be used as a destination IP address on the TCPCONFIG TCPSTACKSOURCEVIPA or SRCIP statement in the TCP/IP profile.
In a sysplex environment, the IKE daemon can detect movement of a DVIPA to or from an IP security stack. To reestablish the Security Associations of a DVIPA, the DVIPSEC parameter must be specified in the TCP/IP profile of the stack from which the DVIPA is being moved and in the TCP/IP profile of the stack to which the DVIPA is being moved. For details about this movement, see Sysplex-Wide Security Associations. For information about the IPCONFIG, IPCONFIG6, and IPSEC statements that need to be added to the TCP/IP profile to configure this support, see z/OS Communications Server: IP Configuration Reference.
When a DVIPA is moved from one IP security stack in a sysplex to another IP security stack, and both stacks have the DVIPSEC option specified, an attempt is made to automatically reestablish Security Associations on the backup stack. The IKE daemon on the system that is assuming control of the DVIPA attempts to renegotiate new Security Associations to replace the ones that were on the system that previously owned the DVIPA. If these attempts fail due to configuration errors or connectivity errors, manual intervention might be required. Phase 1 Security Association or phase 2 Security Association negotiations that were in progress at the time of the DVIPA movement are lost. However, if these negotiations were for a refresh, a new negotiation is started in the process of assuming control of the DVIPA.
When a DVIPA is moved from one IP security stack in a sysplex to another IP security stack, and one or both stacks do not have the DVIPSEC option specified, the Security Associations that are associated with that DVIPA must be reestablished by issuing the ipsec command, on-demand activation, or by a peer initiation.
- If a DVIPA is manually deleted and that address has no backup, the IKE daemon might not be able to terminate the tunnels in which the DVIPA is a security endpoint. To avoid this problem, use the ipsec command to deactivate the DVIPA's IKE tunnels before manually deleting the DVIPA.
- This support does not address the dynamic relocation of static filter rules and VPN policy definitions to the target system in the sysplex. It is up to you to ensure that the necessary filter rules and IP security policy definitions exist on all participating systems in the sysplex. If the necessary filter rules and IP security policy definitions do not exist, the IKE daemon might not be able to reestablish all Security Associations. For a description of the SWSA function, see Sysplex-Wide Security Associations.