IKEv2

Internet Key Exchange (IKE) is a protocol used to establish a secure connection between two parties over the internet. It is used in combination with IPSec to provide secure communication between two networks or devices. IKE automates the key management process, allowing the devices to negotiate and establish a shared secret key without manual intervention.

There are two versions of IKE, IKEv1 and IKEv2. IKEv1 is an older version and was first introduced in 1998. It is still widely used today, but IKEv2 is gradually replacing it due to its improved features and security enhancements.

IKEv2 was introduced in 2005 as an improvement over IKEv1. It is designed to be faster, more secure, and more flexible than IKEv1. One of the most significant improvements in IKEv2 is its ability to handle network address translation (NAT) traversal more efficiently. IKEv2 uses fewer messages to establish a secure connection, reducing the setup time for the connection. IKEv2 also provides more advanced features, such as the ability to perform client authentication using digital certificates.

Like IPSec, IKEv2 uses a modular CLI for configuration.

crypto ikev2 dpd (1-3600)

Set IKEv2 dead peer detection parameters. The first parameter indicates how often a liveness check is performed.

IKEv2 proposal

In IKEv2 (Internet Key Exchange version 2), a proposal is a set of cryptographic algorithms and parameters used for negotiating security associations between two endpoints. A security association (SA) is a set of policies and keys that define how to secure communication between two network entities.

A proposal contains the following parameters:

  • Encryption Algorithm: Specifies the algorithm used to encrypt data. Examples include AES, DES, and 3DES.

  • Integrity Algorithm: Specifies the algorithm used to verify the integrity of data. Examples include SHA-1, SHA-256, and MD5.

  • Diffie-Hellman Group: Specifies the Diffie-Hellman group used to establish the shared secret key. Examples include Group 2, Group 14, and Group 19.

  • PRF Algorithm: Specifies the pseudorandom function (PRF) used to generate keying material. Examples include SHA-1, SHA-256, and MD5.

IKEv2 supports multiple proposals, allowing endpoints to negotiate the best set of algorithms and parameters for a given connection. During IKEv2 negotiation, each endpoint sends a proposal to the other endpoint, and the two endpoints negotiate to agree on a common proposal.

IKEv2 proposals offer several advantages over IKEv1 proposals, including support for more modern cryptographic algorithms and the ability to negotiate multiple proposals simultaneously. This flexibility allows for greater security and better compatibility with a wider range of network devices.

Note

Currently, SoodarOS only support one set of proposals

crypto ikev2 proposal IKEPOSAL

The command is used to create an IKEv2 proposal. An IKEv2 proposal is a set of cryptographic parameters and attributes that are presented during the IKEv2 negotiation process between two devices.

  • IKEPOSAL: Indicates the name of the IKEv2 proposal being created.

encryption ALGORITHM

The encryption command is used to specify the encryption algorithm used for the IKEv2 proposal. Available encryption algorithms are:

  • aes-{128|192|256}: Specifies the AES CBC encryption algorithm with key lengths of 128, 192, or 256 bits.

  • aes-ctr-{128|192|256}: Specifies the AES CTR encryption algorithm with key lengths of 128, 192, or 256 bits.

  • aes-gcm-{128|192|256}: Specifies the AES GCM encryption algorithm with key lengths of 128, 192, or 256 bits.

Note

Only one encryption algorithm can be specified per IKEv2 proposal.

integrity ALGORITHM

The integrity command in an IKEv2 proposal is used to specify the integrity algorithm that will be used to ensure data integrity for the IKEv2 session. Available encryption algorithms are:

  • sha-96: Specifies the SHA-1 hash algorithm for data integrity.

  • sha-256: Specifies the SHA-256 hash algorithm for data integrity.

  • sha-384: Specifies the SHA-384 hash algorithm for data integrity.

  • sha-512: Specifies the SHA-512 hash algorithm for data integrity.

Note

Using a GCM algorithm for encryption makes the integrity algorithm obsolete.

group GROUP

The “group” command is used in the IKEv2 proposal configuration mode to specify the Diffie-Hellman (DH) group to be used for key exchange in the proposal. Available groups are:

  • 14: Specifies the use of Diffie-Hellman group 14, which uses a 2048-bit prime modulus.

  • 19: Specifies the use of Diffie-Hellman group 19, which uses a 256-bit elliptic curve.

  • 20: Specifies the use of Diffie-Hellman group 20, which uses a 384-bit elliptic curve.

  • 21: Specifies the use of Diffie-Hellman group 21, which uses a 521-bit elliptic curve.

  • 28: Specifies the use of Diffie-Hellman group 28, which uses a 256-bit Brainpool ECP group.

  • 29: Specifies the use of Diffie-Hellman group 29, which uses a 384-bit Brainpool ECP group.

  • 30: Specifies the use of Diffie-Hellman group 30, which uses a 512-bit Brainpool ECP group.

  • 31: Specifies the use of Diffie-Hellman group 31, which uses Curve 25519.

  • 32: Specifies the use of Diffie-Hellman group 32, which uses Curve 448.

The choice of Diffie-Hellman group affects the strength of the generated keys, with larger groups providing stronger security but also requiring more computational resources.

Example :

soodar(config)# crypto ikev2 proposal sample-proposal
soodar(config-ikev2-proposal)# encryption aes-192
soodar(config-ikev2-proposal)# integrity sha-96
soodar(config-ikev2-proposal)# group 28

The given commands configure an IKEv2 proposal named “sample-proposal” with the following attributes:

  • Encryption algorithm: AES-192

  • Integrity algorithm: SHA1-96

  • Key exchange group: 28

IKEv2 keyring

IKEv2 Keyring is a configuration element that defines a set of preshared keys or digital certificates that can be used during the negotiation process of the Internet Key Exchange (IKEv2) protocol to establish a secure tunnel between two endpoints.

In an IKEv2 VPN, the keyring is used to authenticate the identity of the remote endpoint and to establish a secure connection. The keyring can store multiple authentication methods (pres shared keys or digital certificates), and they are assigned to a specific peer during the configuration.

crypto ikev2 keyring IKEKEYRING

The command is used to configure the IKEv2 keyring, which is a repository for preshared keys (PSKs) and digital certificates used to authenticate peers during IKEv2 negotiation.

  • IKEKEYRING: Specifies the keyring name.

peer PEER

The peer command in IKEv2 keyring configuration mode is used to create a remote peer.

  • PEER: Specifies the peer name. This name is used locally and has nothing to do with peer’s identity.

Note

The peer command can be used multiple times under a single keyring to specify multiple remote peers. In this case, each peer is identified by a unique name.

Note

The peer command must be followed by other IKEv2 keyring configuration commands that specify the pre-shared key or certificate authentication and identity for the peer.

pre-shared-key LINE

The pre-shared-key command specifies a pre-shared key (PSK) used for authentication between IKE peers.

  • psk: Specifies the pre-shared key value for authentication.

Note

Currently, the same PSK is used for both remote and local authentication. This could change in future releases.

identity address <A.B.C.D|X:X::X:X>

It is used to specify the identity of the remote peer as an IPv4 or IPv6 address for which the keyring is being configured. This address is used by the local device to identify the remote peer during the IKE negotiation process.

  • <A.B.C.D>: is the IPv4 address identity of the remote peer.

  • <X:X::X:X>: is the IPv6 address identity of the remote peer.

identity fqdn FQDN

The command is used to specify the Fully Qualified Domain Name (FQDN) of the remote peer. This FQDN is used by the local device to identify the remote peer during the IKE negotiation process.

  • FQDN: The Fully Qualified Domain Name of the remote peer

identity email MAIL

The command is used to specify the email address identity of a remote peer. This command can be useful when establishing VPN connections with peers that are identified by their email addresses.

  • MAIL: is the email address of the remote peer.

Example :

soodar(config)# crypto ikev2 keyring keyring-1
soodar(config-ikev2-keyring)# peer PC-1
soodar(config-ikev2-keyring-peer)# identity email home@sweet.home
soodar(config-ikev2-keyring-peer)# pre-shared-key 123@321
soodar(config-ikev2-keyring)# peer PC-2
soodar(config-ikev2-keyring-peer)# identity address 1.1.1.1
soodar(config-ikev2-keyring-peer)# pre-shared-key ITSAHARDPASSWD!!

The commands configure an IKEv2 keyring named “keyring-1” with two peers, “PC-1” and “PC-2”, using different identities and pre-shared keys for authentication.

The first peer, “PC-1”, is configured with an email identity of “home@sweet.home” and a pre-shared key of “123@321”. The second peer, “PC-2”, is configured with an address identity of “1.1.1.1” and a pre-shared key of “ITSAHARDPASSWD!!”. When an IKEv2 tunnel is initiated with either of these peers, the local device will attempt to authenticate the remote device using the pre-shared key specified in the keyring configuration. If the remote device can authenticate successfully, the tunnel will be established and traffic can be encrypted and sent between the two devices.

IKEv2 profile

IKEv2 profiles provide a flexible and scalable way to define and control how the IKEv2 protocol is used in a specific context. They allow administrators to tailor IKEv2 to the needs of their specific VPN implementations.

match address local A.B.C.D

The “match address local” command is used in IKEv2 profiles to specify the local address to use for the negotiation process with a remote peer. This command ensures that the local device’s address is matched with the address specified in the command for the negotiation process.

This command is useful when the local device has multiple interfaces and IP addresses, and you want to specify a particular IP address to use for IKEv2 negotiations with a remote peer.

  • A.B.C.D: Specifies the IP address of the local device.

Note

It’s a good practice to set local addresses explicitly. It can prevent problems caused by changes in routes, leading to a change in the source IP address of packets and being rejected by an IKEv2 peer.

identity local address <A.B.C.D|X:X::X:X>

The command is used in the configuration of an IKEv2 profile to specify the local identity of the router in the form of an IP address.

In IKEv2, the local identity is used during the authentication process to identify the router to the remote peer. The IP address specified in this command is used as the local identity when the router initiates an IKEv2 session with a remote peer.

  • A.B.C.D: Specifies the IPv4 address of the local identity.

  • X:X::X:X: Specifies the IPv4 address of the local identity.

Note

It’s important to note that the identity used in IKEv2 negotiations may differ from the actual source IP address used in the IPsec traffic that follows.

identity local fqdn FQDN

The command is used to specify the fully qualified domain name (FQDN) for the local identity of the router. The FQDN is a unique name that identifies a device on the network and is composed of the device name and the domain name. The remote peer uses this identity to verify the identity of the local router during the negotiation process.

  • FQDN: Specifies the fully qualified domain name of the local router

identity local email MAIL

The command is used to specify the email address of the local endpoint identity.

  • MAIL: Specifies the email address of the local endpoint.

authentication local rsa-sig

Specify the local authentication method for the router. This command specifies that the router will use RSA digital signature authentication for IKEv2 connections.

RSA signatures provide a more secure method of authentication than PSKs because they rely on the exchange of digital certificates instead of a shared secret. With RSA signatures, each endpoint has its own private key and a public key certificate that can be verified by the other endpoint. The certificate exchange and signature verification process is more complex than using a PSK, but it provides stronger security guarantees.

Note

Since the chosen certificate to use is the one that has the same SAN as local identity, It is better to use RSA digital signature authentication with the FQDN identity.

Note

Note that in order to use RSA signatures for IKEv2 authentication, both endpoints must have a valid digital certificate issued by a trusted Certificate Authority (CA).

authentication local pre-share

The command is used to specify that pre-shared key authentication will be used for local authentication in IKEv2 negotiations.

Note

By default, IKEv2 uses a pre-shared key (PSK) for authentication

authentication remote rsa-sig

This command is used to specify that the remote endpoint must authenticate using RSA digital signatures.

Note

Certificate SAN field is as remote FQDN identity and should be available in keyring.

authentication remote pre-share

The command is used to specify that pre-shared key authentication will be used for remote authentication in IKEv2 negotiations.

match identity remote address <A.B.C.D|X:X::X:X>

This command is used in the IKEv2 profile configuration to match the identity of the remote peer during the IKEv2 negotiation. If the remote peer’s identity matches the specified address, the negotiation process continues. If the remote peer’s identity does not match the specified address, the negotiation process is terminated.

  • A.B.C.D: specifies an IPv4 address identity of the remote peer.

  • X:X::X:X: specifies an IPv6 address identity of the remote peer.

Other information about this peer( like PSK) is looked up in the keyring.

match identity remote fqdn FQDN

This command is used to specify the fully qualified domain name (FQDN) of the remote peer that the profile should match.

This command is useful in situations where the remote peer is authenticated using RSA signature. the FQDN value should be the same as the received certificate SAN.

  • FQDN: specifies the fully qualified domain name of the remote peer that the profile should match.

Other information about this peer( like PSK) is looked up in the keyring.

match identity remote email EMAIL

specify the email address of the remote identity that the router or firewall is attempting to establish a connection with.

  • EMAIL: is the email address of the remote identity.

Other information about this peer( like PSK) is looked up in the keyring.

match certificate

Match against DN fields and values as peer identity. using wildcards is allowed

Note

The peer should use RSA Digital Signature as authentication method, and it should use its DN as identity.

Example:

soodar(config-ikev2-profile)# match certificate C=IR, CN=*.temp.ir

Match against all peers that have DN as their identity and this certificate is issued from Iran and is a sub-domain of temp.ir

keyring local IKEKEYRING

The keyring local command is used to specify the local keyring that contains the preshared key information for authenticating during IKE negotiations.

  • IKEKEYRING: Specifies the name of the keyring that contains the preshared key information.

proposal IKEPOSAL

The “proposal” command in the IKEv2 profile configuration mode is used to specify the IKEv2 proposal to be used for the IKEv2 negotiation.

  • IKEPOSAL: Specifies the name of the IKEv2 proposal previously configured.

lifetime <120-86400>

The lifetime command is used in the configuration of IKEv2 profiles and specifies the duration of the security association (SA) in seconds. When the lifetime of the SA expires, a new one is negotiated between the peers.

  • <120-86400>: Specifies the number of seconds the SA should remain active, ranging from 120 to 86400 seconds.

Note

Default lifetime for an IKEv2 SA is 14400 seconds.

Example :

soodar(config)# crypto ikev2 profile VPN
soodar(config-ikev2-profile)# identity local 192.168.1.1
soodar(config-ikev2-profile)# match identity remote home@sweet.home
soodar(config-ikev2-profile)# keyring local keyring-1
soodar(config-ikev2-profile)# proposal sample-proposal

This configuration creates an IKEv2 profile named “VPN” on the device. It specifies the local identity for this profile to be 192.168.1.1, and remote identity to be “home@sweet.home”. It then specifies that the “keyring-1” should be used for authentication purposes. Finally, it references an IKEv2 proposal named “sample-proposal” to be used for this profile.