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--DES-----------------------------.
>--+-----------------------------------------------+------------>
'-HowToEncrypt--+-DES-------------------------+-'
+-3DES------------------------+
+-AES-------------------------+
+-AES_CBC KeyLength keylen ---+
+-AES_GCM_16 KeyLength keylen +
'-DoNot-----------------------'
.-HowToAuth ESP HMAC_MD5-----------------------.
>--+----------------------------------------------+------------->
'-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 DES.
- 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 ESP
HMAC_MD5.
- 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.