This feature provides an IKEv2 and IPSec framework for operators to configure the system where different peer devices can establish an IKEv2/IPSec tunnel with different set of capabilities and features. Vendor-specific crypto templates which are a subset of the IKEv2 dynamic template can be configured for each device separately. Multiple vendor templates can be grouped under a vendor policy and associated to the parent IKEv2 dynamic template. A single Gateway service (supporting IPSec) can serve different peers with different IKEv2/IPSec (pre-defined) requirements.

During IKE_SA_INIT exchange, on receiving the vendor ID payload, allocated IKE SA is updated with the configuration from both the main crypto (service) template and the vendor templates. Configuration values are then taken from IKE SA during tunnel negotiation. The priority of the configuration in the vendor template over the main crypto (service) template is decided by matching the vendor ID string associated to the vendor template (in the vendor policy) with the received vendor ID in the IKE_SA_INIT message.

If the IKE_SA_INIT message contains more than one vendor ID, all the vendor IDs will be matched with the configuration under the vendor policy. For all successful matches, the configuration parameters are taken from the vendor template and the rest of the configuration is taken from the main crypto (service) template. Matching is performed based on the precedence associated with the vendor template. When a configuration is available in more than one vendor template, the configuration is chosen based on the highest precedence in the vendor policy. A precedence value of 1 indicates the highest priority with the vendor policy for a set of associated vendor templates.

Architectural Limitations

• In a downgrade scenario for Inter-chassis session recovery, as this feature will not be available in the stand-by chassis, the IKE SA updated with the vendor template configuration will not be synced to the stand-by chassis.

Configuration Limitations

• IKE SA rekey configuration – If some of the ikev2-ikesa rekey , ikev2-ikesa rekey disallow-param-change , or ikev2-ikesa ignore rekeying requests commands exist in the main crypto (service) template configuration, and if any of these commands also exist in the vendor template, all configuration will be taken from the vendor template if the vendor ID matches.

• IPSec rekey and lifetime configuration – If any of the rekey keepalive , ignore rekeying requests , or lifetime command exists in the vendor template, all IPSec rekey configurations will be taken from the vendor template.

• Currently, only one payload configuration is effective.

Use the following configuration to create a vendor template, and get into the Crypto Template IKEv2 Vendor Configuration Mode:

config 
    context context_name 
        crypto template template_name ikev2-vendor 

Notes:

• The following commands are available under the Crypto Template IKEv2 Vendor configuration mode to configure IPSec-related parameters. Their functionalities are similar to the commands under the Crypto Template Configuration Mode.

  • configuration-payload

  • ikev2-ikesa

  • keepalive

  • payload

Use the following configuration to create a vendor policy, and associate it with the vendor template:

config 
    context context_name 
        crypto vendor-policy vendor_policy_name 
            precedence value vendor-id vendor_id vendor-template template_name 
            end 

Notes:

• A maximum of 32 vendor policies can be configured.

• A maximum of 64 vendor templates can be associated with a vendor policy.

• vendor_id must be an integer from 1 through 64.

• template_name must be an alphanumeric string from 1 to 127 characters.

Use the following configuration to associate the vendor policy to the crypto (services) template:

config 
    context context_name 
        crypto template template_name ikev2-dynamic 
            vendor-policy policy_name 
            end 

Notes:

• policy_name must be an alphanumeric string from 1 to 127 characters.