IpDynVpnAction statement

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.

Dynamically established security associations are created by the IKE daemon and are used to protect data sent through a dynamic VPN. Dynamic VPNs can be established in the following ways:
  • 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

Read syntax diagramSkip visual syntax diagram
>>-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.

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.

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.