Use the IpDynVpnAction statement to indicate how selected data traffic between two security endpoints should be protected utilizing dynamically established security associations. An IpDynVpnAction statement contains inline definitions or references to IpDataOffer statements, or both.
- Automatically established when the TCP/IP stack comes up or when the IKE daemon comes up, or both. This is known as an autoactivation.
- Established with an ipsec command. This is known as a command-line activation.
- Automatically established with an outbound IP packet. This is known as an on-demand activation.
- Established with a phase 2 IKE negotiation initiated by a remote security endpoint. This is known as a remote activation.
Syntax
>>-IpDynVpnAction--name--| Put Braces and Parameters on Separate Lines |->< Put Braces and Parameters on Separate Lines |--+-{-----------------------------+----------------------------| +-| IpDynVpnAction Parameters |-+ '-}-----------------------------' IpDynVpnAction Parameters .-Pfs None---------. .-Initiation Either----------. |--+------------------+--+----------------------------+---------> '-Pfs--+-Group1--+-' '-Initiation--+-LocalOnly--+-' +-Group2--+ +-RemoteOnly-+ +-Group5--+ '-Either-----' +-Group14-+ '-None----' .-VpnLife 1440-. .-InitiateWithPfs None---------. >--+--------------+--+------------------------------+-----------> '-VpnLife n----' '-InitiateWithPfs--+-Group1--+-' +-Group2--+ +-Group5--+ +-Group14-+ +-Group19-+ +-Group20-+ +-Group21-+ +-Group24-+ '-None----' .--------------------------------. V .-AcceptablePfs None---------. | >----+----------------------------+-+---------------------------> '-AcceptablePfs--+-Group1--+-' +-Group2--+ +-Group5--+ +-Group14-+ +-Group19-+ +-Group20-+ +-Group21-+ +-Group24-+ '-None----' .-HowToEncapIKEv2 Either---------. >--+--------------------------------+---------------------------> '-HowToEncapIKEv2--+-Tunnel----+-' +-Transport-+ '-Either----' .-PassthroughDF Yes----------------. >--+----------------------------------+-------------------------> | .-Clear-. | '-PassthroughDF--+-No--+-------+-+-' | +-Set---+ | | '-Clear-' | '-Yes-----------' .-------------------------. .-PassthroughDSCP Yes------. V | >--+--------------------------+----+-IpDataOffer---------+-+----| '-PassthroughDSCP--+-No--+-' '-IpDataOfferRef name-' '-Yes-'
Parameters
- name
- A string 1 - 32 characters in length specifying the name of this IpDynVpnAction statement. The name cannot start with a dash (-) or contain any commas (,).
- Pfs
- Specifies whether perfect forward secrecy (PFS) is used when negotiating
the security association, and if so, what Diffie-Hellman group is
used. The default is None.
- None
- Do not use perfect forward secrecy.
- Group1
- Modular exponentiation group with a 768-bit modulus.
Restriction: Group 1 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group2
- Modular exponentiation group with a 1024-bit modulus.
Restriction: Group 2 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group5
- Modular exponentiation group with a 1536-bit modulus.
Restriction: Group 5 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group14
- Modular exponentiation group with a 2048-bit modulus.
Guideline: If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 5,14,19,20, or 24. If you are using encryption or authentication algorithms with a key length of 256 bits or greater, use Diffie-Hellman group 21.
Rule: Pfs is deprecated. Use InitiateWithPfs and AcceptablePfs parameters instead. If you use Pfs, then InitiateWithPfs and AcceptablePfs are set to the Pfs value.
Restriction: Do not use the Pfs parameter in conjunction with the InitiateWithPfs or AcceptablePfs parameters.
- Initiation
- Specifies which system can initiate the security associations
for this dynamic tunnel. The default is Either.
- LocalOnly
- Specifies that this system must initiate the negotiation.
- RemoteOnly
- Specifies that another system must initiate the negotiation.
- Either
- Specifies that this system can either initiate a negotiation or respond to a negotiation initiated by another system.
- VpnLife
- Maximum length of time that phase 2 SAs should continue to be refreshed, in minutes. The VpnLife parameter is set for a dynamic VPN tunnel when the first SA is established for the tunnel. The VpnLife value for a dynamic VPN tunnel can be changed by deactivating the tunnel, changing the configured VpnLife value, and then activating the tunnel. Valid values are in the range 0 - 525 600 minutes. Specifying a value of 0 means that the maximum lifetime is infinite. The default is 1440 minutes. In any case, regardless of the VpnLife setting, SAs that are configured with AllowOnDemand Yes may cease to be refreshed if they have not protected any network traffic during their previous refresh interval.
- AcceptablePfs
- Specifies acceptable Diffie-Hellman groups to use for perfect
forward secrecy (PFS). The default is None.
- None
- Do not use perfect forward secrecy.
- Group1
- Modular exponentiation group with a 768-bit modulus.
Restriction: Group 1 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group2
- Modular exponentiation group with a 1024-bit modulus.
Restriction: Group 2 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group5
- Modular exponentiation group with a 1536-bit modulus.
Restriction: Group 5 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group14
- Use modular exponentiation group with a 2048-bit modulus.
- Group19
- Random 256-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group20
- Random 384-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group21
- Random 521-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group24
- Modular exponentiation group with a 2048-bit modulus and 256-bit
prime order subgroup.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
Result: For negotiations using IKE version 1, the AcceptablePfs list is used when the z/OS® IKE daemon is the responder for a security association. For negotiations using IKE version 2, the AcceptablePfs list is used in both initiator and responder modes.
Guideline: If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 5,14,19,20, or 24. If you are using encryption or authentication algorithms with a key length of 256 bits or greater, use Diffie-Hellman group 21.
Rule: The InitiateWithPfs Diffie-Hellman group must be specified as one of the values in the AcceptablePfsList parameter.
Restriction: Do not use the Pfs parameter in conjunction with the InitiateWithPfs or AcceptablePfs parameters.
- InitiateWithPfs
- Specifies whether perfect forward secrecy (PFS) is used as initiator
of the security association, and if so, what Diffie-Hellman group
is used. The default is None.
- None
- Do not use perfect forward secrecy.
- Group1
- Modular exponentiation group with a 768-bit modulus.
Restriction: Group 1 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group2
- Modular exponentiation group with a 1024-bit modulus.
Restriction: Group 2 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group5
- Modular exponentiation group with a 1536-bit modulus.
Restriction: Group 5 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.
- Group 14
- Modular exponentiation group with a 2 048-bit modulus.
- Group19
- Random 256-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group20
- Random 384-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group21
- Random 521-bit elliptic curve group.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- Group24
- Modular exponentiation group with a 2048-bit modulus and 256-bit
prime order subgroup.
Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
Result: For negotiations using IKE version 1, the InitiateWithPfs selection is used when sending the proposal. For negotiations using IKE version 2, all PFS selections specified on the AcceptablePfs list are included when sending the proposal, but the InitiateWithPfs selection is sent as the first choice.
Guideline: If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 5,14,19,20, or 24. If you are using encryption or authentication algorithms with a key length of 256 bits or greater, use Diffie-Hellman group 21.
- HowToEncapIKEv2
- Specifies the encapsulation mode to use when establishing IKE
version 2 security associations. The default is Either.
- Either
- Support both tunnel and transport mode. When initiating the security
association, the choice is made based on the topology of the connection.
Specifically:
- If both IKE peers are hosts, then a transport mode SA is proposed.
If the peer accepts the use of transport mode, then transport mode
is used for the SA. If the peer responds requiring tunnel mode, then
tunnel mode is used for the SA.
Tip: Specify the Transport keyword on the HowToEncapIKEv2 parameter if you want to reject the SA if the peer responds requiring tunnel mode.
- If either IKE peer is a gateway, then tunnel mode is used.
Use the mode proposed by the initiator when responding to a negotiation that was initiated by an IKE peer.
- If both IKE peers are hosts, then a transport mode SA is proposed.
If the peer accepts the use of transport mode, then transport mode
is used for the SA. If the peer responds requiring tunnel mode, then
tunnel mode is used for the SA.
- Transport
- Supports only transport mode security associations. When initiating
the SA, the behavior depends on the topology of the connection. Specifically:
- If both IKE peers are hosts, then a transport mode SA is proposed.
If the peer accepts the use of transport mode, then transport mode
is used for the SA. If the peer responds requiring tunnel mode, then
the SA is deactivated and an error message logged.
Tip: Specify the Either keyword on the HowToEncapIKEv2 parameter if you want to propose transport mode but are willing to use tunnel mode if the peer responds requiring tunnel mode.
- If either IKE peer is a gateway, the local activation fails and an error message is logged.
When responding to a remote initiation, if the initiator requests tunnel mode, the negotiation is rejected with a NO_PROPOSAL_CHOSEN notification.
- If both IKE peers are hosts, then a transport mode SA is proposed.
If the peer accepts the use of transport mode, then transport mode
is used for the SA. If the peer responds requiring tunnel mode, then
the SA is deactivated and an error message logged.
- Tunnel
- Supports only tunnel mode security associations. When initiating, only tunnel mode is proposed. When responding to a remote initiation, if the initiator requests transport mode, IKE responds without acknowledging the transport mode notification, thus forcing a tunnel mode SA to be established.
Restriction: The HowToEncapIKEv2 parameter is ignored when negotiating IKE version 1 tunnels. The encapsulation mode for IKE version 1 security associations is determined by the HowToEncap value on the selected IpDataOffer.
Restriction: This parameter is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details
- PassthroughDF
- When this parameter is set to No, the do not fragment bit is set
to 0 (if the value Clear is specified) or 1 (if the value Set is specified)
on the outer IP header for an IPv4 tunnel mode SA. When this parameter
is set to Yes, the do not fragment bit is copied from the inner IP
header to the outer IP header for an IPv4 tunnel mode SA. This parameter's
setting is ignored for IPv6 or transport mode SAs.
Restriction: This parameter is valid only for V1R10 and later releases. See General syntax rules for Policy Agent for details.
- PassthroughDSCP
- When this parameter is set to No, the Differentiated Services
Code Point (DSCP) field is set to 0 on the outer IP header for a tunnel
mode SA. When this parameter is set to Yes, the DSCP field is copied
from the inner IP header to the outer IP header for a tunnel mode
SA. This setting is ignored for transport mode SAs.
Restriction: This parameter is valid only for V1R10 and later releases. See General syntax rules for Policy Agent for details.
- IpDataOffer
- An inline specification of an IpDataOffer statement to be used
when initiating a phase 2 negotiation.
Restriction: A IpDynVpnAction statement is limited to a maximum of 48 IpDataOffer or IpDataOfferRef statements.
- IpDataOfferRef
- The name of a globally defined IpDataOffer statement to be used
when initiating a phase 2 negotiation.
Restriction: A IpDynVpnAction statement is limited to a maximum of 48 IpDataOffer or IpDataOfferRef statements.