IpDataOffer statement

Use the IpDataOffer statement to define a data offer for a dynamic VPN. An IP data offer indicates one acceptable way to protect data sent through a dynamic VPN. An IpDataOffer statement can be referenced by an IpDynVpnAction statement.

Syntax


>>-IpDataOffer--+------+--| Put Braces and Parameters on Separate Lines |-><
                '-name-'                                                    

Put Braces and Parameters on Separate Lines

|--+-{--------------------------+-------------------------------|
   +-| IpDataOffer Parameters |-+   
   '-}--------------------------'   

IpDataOffer Parameters

   .-HowToEncap--Tunnel--------.   
|--+---------------------------+-------------------------------->
   '-HowToEncap--+-Tunnel----+-'   
                 '-Transport-'     

   .-HowToEncrypt--AES_CBC KeyLength 128------------.   
>--+------------------------------------------------+----------->
   '-HowToEncrypt--+-DES--------------------------+-'   
                   +-3DES-------------------------+     
                   +-AES--------------------------+     
                   +-AES_CBC KeyLength keylen ----+     
                   +-AES_GCM_16 KeyLength keylen -+     
                   '-DoNot------------------------'     

   .-HowToAuth ESP HMAC_SHA1----------------------.   
>--+----------------------------------------------+------------->
   '-HowToAuth----+-AH--+-+-Null--------------+---'   
                  '-ESP-' +-AES_GMAC_128------+       
                          +-AES_GMAC_256------+       
                          +-AES128_XCBC_96----+       
                          +-HMAC_MD5----------+       
                          +-HMAC_SHA----------+       
                          +-HMAC_SHA1---------+       
                          +-HMAC_SHA2_256_128-+       
                          +-HMAC_SHA2_384_192-+       
                          '-HMAC_SHA2_512_256-'       

   .-RefreshLifetimeProposed 240----------.   
>--+--------------------------------------+--------------------->
   '-RefreshLifetimeProposed proposedtime-'   

   .-RefreshLifetimeAccepted 120 480---------.   
>--+-----------------------------------------+------------------>
   '-RefreshLifetimeAccepted mintime maxtime-'   

   .-RefreshLifesizeProposed None-------------.   
>--+------------------------------------------+----------------->
   '-RefreshLifesizeProposed-+-proposedsize-+-'   
                             '-None---------'     

   .-RefreshLifesizeAccepted None----------------.   
>--+---------------------------------------------+--------------|
   '-RefreshLifesizeAccepted-+-minsize maxsize-+-'   
                             '-None------------'

Parameters

name

A string 1 - 32 characters in length specifying the name of this IpDataOffer statement.

Rule: If this IpDataOffer statement is not specified inline within another statement, a name value must be provided.

If a name is not specified for an inline IpDataOffer statement, a nonpersistent system name is created.

HowToEncap

The encapsulation mode of the dynamic VPN's security associations when IKE version 1 is used. The default is tunnel mode.

Tunnel: Specifies that the security association operates in tunnel mode, which protects the entire IP packet. This mode must be used for a secure tunnel between two security gateways or between a security gateway and a remote system. One or both of the communication endpoints can be on different systems than the security endpoints.
Transport: Specifies that the security association operates in transport mode, which protects only the transport-layer headers and data (for example, TCP or UDP packet) inside an IP packet. This mode can be used only when the endpoints of the security association are the two communicating systems (that is, neither system acts as a gateway).

Restriction: HowToEncap is ignored for dynamic VPNs that are negotiated using IKE version 2. The encapsulation mode for IKE version 2 security associations is determined by the HowToEncapIKEv2 parameter on the IPDynVpnAction statement.

HowToEncrypt

Encryption is done using the ESP protocol. Specify the encryption algorithm used to provide data confidentiality. The default is AES_CBC KeyLength 128.

DES

DES encryption is used with a 56–bit key and a 64–bit initialization vector.

Restriction: DES is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.

3DES

Triple DES runs the DES encryption algorithm three times and uses 192-bits, including 24 parity bits.

Rule: If 3DES is specified but is not supported by the system, the Policy Agent fails the policy.

AES

Deprecated and treated as a synonym for AES_CBC KeyLength 128.

Rule: If AES is specified but AES encryption in CBC mode is not supported by this TCP/IP stack, Policy Agent fails the policy.

AES_CBC

The Advanced Encryption Standard (AES) algorithm is used in Cipher Block Chaining (CBC) mode.

Rules:

The key length is measured in bits, and a keylen of either 128 or 256 must be specified.
If AES_CBC is specified but AES encryption in CBC mode is not supported by this TCP/IP stack, Policy Agent fails the policy.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

AES_GCM_16

The AES algorithm is used in Galois Counter Mode (GCM) and with a 16-byte Integrity Check Value (ICV). Galois Counter Mode is a combined-mode algorithm that performs both encryption and authentication simultaneously.

Rules:

The key length is measured in bits, and a keylen of either 128 or 256 must be specified.
HowToAuth ESP NULL must be specified if AES_GCM_16 is specified.
If AES_GCM_16 is specified but AES encryption in Galois Counter Mode is not supported by this TCP/IP stack, Policy Agent fails the policy.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details.

DoNot

No encryption is used.

If the HowToEncrypt value DoNot is specified with a HowToAuth ESP value, the ESP header is present, but the payload is not encrypted (ESP_NULL).

HowToAuth

The desired authentication policy indicating which protocol and which algorithm to use when authenticating data. The default is Start of change

ESP HMAC_SHA1 End of change

AH

Carry authentication in AH headers.

ESP

Carry authentication in ESP headers.

AES_GMAC_128

Use the AES_GMAC algorithm to encode authentication data in either AH or ESP headers, with 128-bit keys. AES_GMAC functions as a combined-mode algorithm that provides authentication without encryption.

Rule: AES_GMAC_128 may be specified only in combination with HowToEncrypt DoNot.

Tip: If you want a combined-mode algorithm that provides both authentication and encryption, choose HowToEncrypt AES_GCM_16.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details.

AES_GMAC_256

Use the AES_GMAC algorithm to encode authentication data in either AH or ESP headers, with 256-bit keys. AES_GMAC functions as a combined-mode algorithm that provides authentication without encryption.

Rule: AES_GMAC_256 may be specified only in combination with HowToEncrypt DoNot.

Tip: If you want a combined-mode algorithm that provides both authentication and encryption, choose HowToEncrypt AES_GCM_16.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details.

AES128_XCBC_96

Use the AES128_XCBC algorithm to encode authentication data in either AH or ESP headers, with 128-bit keys and hash truncation to 96 bits.

Restriction: AES128_XCBC_96 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

HMAC_MD5

Use the HMAC_MD5 algorithm to encode authentication data in either AH or ESP headers.

Restriction: HMAC_MD5 is not accepted when the TCP/IP stack is configured for FIPS 140 mode on the IpFilterPolicy statement.

HMAC_SHA

Deprecated and treated as a synonym for HMAC_SHA1.

HMAC_SHA1

Use the HMAC_SHA1 algorithm to encode authentication data in either AH or ESP headers.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

HMAC_SHA2_256_128

Use the HMAC_SHA2_256 algorithm to encode authentication data in either AH or ESP headers, with 256-bit keys and hash truncation to 128 bits.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

HMAC_SHA2_384_192

Use the HMAC_SHA2_384 algorithm to encode authentication data in either AH or ESP headers, with 384-bit keys and hash truncation to 192 bits.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

HMAC_SHA2_512_256

Use the HMAC_SHA2_512 algorithm to encode authentication data in either AH or ESP headers, with 512-bit keys and hash truncation to 256 bits.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

Null

Use no authentication.

Rule: NULL may only be specified with HowToAuth ESP and only in combination with HowToEncrypt AES_GCM_16.

Restriction: This value is valid only for V1R12 and later releases. See General syntax rules for Policy Agent for details

Restriction: HowToAuth AH may be specified in combination with HowToEncrypt only if the security association is negotiated using IKE version 1 because IKE version 2 does not permit the combining of AH and ESP. If this combination is specified for an IKE version 2 security association, the IPDataOffer is ignored.

RefreshLifetimeProposed

The security association lifetime in minutes. For IKE version 1, this value is proposed when acting as the initiator of a key exchange negotiation. For IKE version 2, this value determines the refresh lifetime.The default is 240.

proposedtime: The lifetime proposed (for IKE version 1) or used (for IKE version 2) for the phase 2 tunnel. Valid values are in the range 1 - 9 999. The proposed lifetime value should be within the range specified by the RefreshLifetimeAccepted parameter.

Tip: For IKE version 2 security associations, if the RefreshLifetimeProposed value is longer than that of the ReauthInterval on the associated KeyExchangeAction, the reauthentication will usually occur before the re-keying occurs.

RefreshLifetimeAccepted

A range of acceptable security association lifetimes in minutes. This range is accepted when acting as the responder of IKE version 1 key exchange negotiation. The default is 120 480.

mintime: The minimum lifetime that can be accepted.
maxtime: The maximum lifetime that can be accepted. This value must be ≥ to the mintime value.

Valid values for each option are in the range 1 - 9 999.

Restriction: This parameter is ignored for IKE version 2 SAs.

RefreshLifesizeProposed

The security association lifesize in Kbytes. If a proposedsize value is specified, then this value is proposed when acting as the IKE version 1 initiator of a key exchange negotiation. For IKE version 2, this value determines the refresh lifesize. If None is specified, then no lifesize is proposed for IKE version 1 or used for IKE version 2. The default is None.

proposedsize: The proposed lifesize for the negotiation. Valid values are in the range 1 - 4 194 300. The proposed lifesize value should be within the range specified by RefreshLifesizeAccepted parameter, if that parameter is not specified as None.
None: No lifesize should be proposed for IKE version 1 or used for IKE version 2. If this parameter is specified as None, then RefreshLifesizeAccepted parameter should also be specified as None.

RefreshLifesizeAccepted

The security association lifesize in Kbytes. If minsize and maxsize values are specified, then this range is accepted when acting as the responder of an IKE version 1 key exchange negotiation. If None is specified, then no lifesize is accepted when acting as the responder of a key exchange negotiation. The default is None.

Result: The IKED accepts a proposed lifesize greater than 4 194 300, only if a maxsize of exactly 4 194 300 is specified. If the IKED accepts a lifesize greater than 4 194 300, it assigns an actual lifesize of 4 194 300 to the security association.

minsize: The minimum lifesize that can be accepted.
maxsize: The maximum lifesize that can be accepted. This value must be ≥ to the minsize value.
None: No lifesize is accepted. If this parameter is specified as None, then RefreshLifesizeProposed value should also be specified as None.

Valid values for the minsize and maxsize options are 1 - 4 194 300.

Restriction: This parameter is ignored for IKE version 2 SAs.

Rules:

The IpDataOffer statement allows for 0 - 1 authentication proposals and 0 - 1 encryption proposals. Multiple authentication proposals or multiple encryption proposals cannot be specified in the same IpDataOffer statement.
To propose authentication using only the ESP header, specify HowToEncrypt DoNot and HowToAuth ESP xxx where xxx represents a valid authentication algorithm.. The ESP header is present, but the payload is not encrypted.

Result: If both HowToAuth AH and HowToEncrypt are specified when using IKE version 1, then for outbound traffic the encryption proposal is always applied before the authentication proposal (IKE version 2 does not permit combining AH and ESP). For example, if HowToEncrypt DES and HowToAuth AH HMAC_SHA are specified, this is understood to mean that data is first encrypted and the results are then authenticated and carried in an AH header.