Internet Key Exchange | Junos OS (2024)

Introduction to IKE

Internet Key Exchange (IKE) is a secure key management protocol that is used to set up a secure, authenticated communications channel between two devices.

IKE does the following:

Negotiates and manages IKE and IPsec parameters
Authenticates secure key exchange
Provides mutual peer authentication by means of shared secrets (not passwords) and public keys
Provides identity protection (in main mode)
Employs Diffie-Hellman methods and is optional in IPsec (the shared keys can be entered manually at the endpoints).

IKE Versions

Two versions of the IKE standards are available:

IKE version 1 - IKE protocol defined in RFC 2409.
IKE version 2 - IKE version 2 (IKEv2) is the latest version of the IKE protocol defined in RFC 7296.

Internet Key Exchange version 2 (IKEv2) is the latest version of the Internet Key Exchange (IKE) protocol defined in RFC 7296. A VPN peer is configured as either IKEv1 or IKEv2. When a peer is configured as IKEv2, it cannot fall back to IKEv1 if its remote peer initiates IKEv1 negotiation.

The advantages of using IKEv2 over IKEv1 are as follows:

Replaces eight initial exchanges with a single four-message exchange.
Reduces the latency for the IPsec SA setup and increases connection establishment speed.
Increases robustness against DOS attacks.
Improves reliability through the use of sequence numbers, acknowledgments, and error correction.
Improves reliability, as all messages are requests or responses. The initiator is responsible for retransmitting if it does not receive a response.

Interaction Between IKE and IPSec

IPsec can establish a VPN in either of the following way:

Internet Key Exchange (IKE) protocol— IPsec supports automated generation and negotiation of keys and security associations using the IKE protocol. Using IKE to negotiate VPNs between two endpoints provides more security than the manual key exchange.
Manual key exchange—IPsec supports using and exchanging of keys manually (example: phone or email) on both sides to establish VPN.

IKEv1 Message Exchange

IKE negotiation includes two phases:

Phase 1—Negotiate exchange of proposals for how to authenticate and secure the channel.
Phase 2—Negotiate security associations (SAs) to secure the data that traverses through the IPsec tunnel.
See Also
Understand IPsec IKEv1 Protocol The Danger of IKEv1 Information Disclosure Vulnerability IKEV2 IKEV1 Compatibilty Disable Aggresive Mode

Phase 1 of IKE Tunnel Negotiation

Phase1 of an AutoKey InternetKey Exchange (IKE) tunnel negotiation consists of the exchange ofproposals for how to authenticate and secure the channel. The participantsexchange proposals for acceptable security services such as:

Encryption algorithms—Data Encryption Standard (DES), triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). (See IPsec Overview.)
Authentication algorithms—Message Digest 5 (MD5 ) and Secure Hash Algorithm (SHA). (See IPsec Overview.)
Diffie-Hellman (DH) group. (See IPsec Overview.)
Preshared key or RSA/DSA certificates. (See IPsec Overview.)

A successful Phase1 negotiation concludeswhen both ends of the tunnel agree to accept at least one set of thePhase1 security parameters proposed and then process them. JuniperNetworks devices support up to four proposals for Phase1 negotiations,allowing you to define how restrictive a range of security parametersfor key negotiation you will accept. JunosOS provides predefined standard, compatible, and basic Phase 1 proposalsets. You can also define custom Phase1 proposals.

Phase1 exchanges can take place in eithermain mode or aggressive mode. You can choose your mode during IKEpolicy configuration.

This topic includes the following sections:

Main Mode
Aggressive Mode

Main Mode

In main mode, the initiator and recipient sendthree two-way exchanges (six messages total) to accomplish the followingservices:

First exchange (messages 1 and 2)—Proposes and acceptsthe encryption and authentication algorithms.
Second exchange (messages 3 and 4)—Executes a DHexchange, and the initiator and recipient each provide a pseudorandomnumber.
Third exchange (messages 5 and 6)—Sends and verifiesthe identities of the initiator and recipient.

The information transmitted in the third exchangeof messages is protected by the encryption algorithm established inthe first two exchanges. Thus, the participants’ identitiesare encrypted and therefore not transmitted “in the clear.”

Aggressive Mode

In aggressive mode, the initiator and recipientaccomplish the same objectives as with main mode, but in only twoexchanges, with a total of three messages:

First message—The initiator proposes the securityassociation (SA), initiates a DH exchange, and sends a pseudorandomnumber and its IKE identity.
When configuring aggressive mode with multiple proposals forPhase 1 negotiations, use the same DH group in all proposals becausethe DH group cannot be negotiated. Up to four proposals can be configured.
Second message—The recipient accepts the SA; authenticatesthe initiator; and sends a pseudorandom number, its IKE identity,and, if using certificates, the recipient's certificate.
Third message—The initiator authenticates the recipient,confirms the exchange, and, if using certificates, sends the initiator'scertificate.

Because the participants’ identities areexchanged in the clear (in the first two messages), aggressive modedoes not provide identity protection.

Main and aggressive modes applies only to IKEv1 protocol. IKEv2protocol does not negotiate using main and aggressive modes.

Phase 2 of IKE Tunnel Negotiation

After the participants have establisheda secure and authenticated channel, they proceed through Phase2,in which they negotiate security associations (SAs) to secure thedata to be transmitted through the IPsec tunnel.

Similar to the process for Phase1, the participantsexchange proposals to determine which security parameters to employin the SA. A Phase2 proposal also includes a security protocol—eitherEncapsulating Security Payload (ESP) or Authentication Header (AH)—andselected encryption and authentication algorithms. The proposal canalso specify a Diffie-Hellman (DH) group, if Perfect Forward Secrecy(PFS) is desired.

Proxy IDs

In Phase 2, the peers exchange proxy IDs. A proxyID consists of a local and remote IP address prefix. The proxy IDfor both peers must match, which means that the local IP address specifiedfor one peer must be the same as the remote IP address specified forthe other peer.

Perfect Forward Secrecy

PFS is a method for deriving Phase2 keysindependent from and unrelated to the preceding keys. Alternatively,the Phase1 proposal creates the key (the SKEYID_d key) fromwhich all Phase2 keys are derived. The SKEYID_d key can generatePhase2 keys with a minimum of CPU processing. Unfortunately,if an unauthorized party gains access to the SKEYID_d key, all yourencryption keys are compromised.

PFS addresses this security risk by forcing a newDH key exchange to occur for each Phase2 tunnel. Using PFS isthus more secure, although the rekeying procedure in Phase2might take slightly longer with PFS enabled.

Replay Protection

A replay attack occurs when an unauthorized personintercepts a series of packets and uses them later either to floodthe system, causing a denial of service (DoS), or to gain entry tothe trusted network. Junos OS provides a replay protection featurethat enables devices to check every IPsec packet to see if it hasbeen received previously. If packets arrive outside a specified sequencerange, Junos OS rejects them. Use of this feature does not requirenegotiation, because packets are always sent with sequence numbers.You simply have the option of checking or not checking the sequencenumbers.

IKEv2 Message Exchange

IKE version 2 is the successor to the IKEv1 method. It provides a secure VPN communication channel between peer VPN devices and defines negotiation and authentication for IPsec security associations (SAs) in a protected manner.

IKEv2 does not include phase 1 and phase 2 similar to IKEv1, but there are four message exchanges occur to negotiate an IPsec tunnel with IKEv2. The message exchange in IKEv2 are:

Negotiates the security attributes to establish the IPsec tunnel. This includes exchanging the protocols/parameters used, and Diffie-Hellman groups.
Each peer establishes or authenticates their identities while the IPsec tunnel is established.
Peers to create additional security associations between each other.
Peers perform liveliness detection, removing SA relationships, and reporting error messages.

IKEv2 Configuration Payload
IKEv2 Rekeying and Reauthentication
IKEv2 Fragmentation
Traffic Selectors for IKEv2

IKEv2 Configuration Payload

Configuration payload is an IKEv2 option offered to propagate provisioning information from a responder to an initiator. IKEv2 configuration payload is supported with route-based VPNs only.

RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2), defines 15 different configuration attributes that can be returned to the initiator by the responder.

IKEv2 Rekeying and Reauthentication

With IKEv2, rekeying and reauthentication are separate processes.

Rekeying establishes new keys for the IKE security association (SA) and resets message ID counters, but it does not reauthenticate the peers.

Reauthentication verifies that VPN peers retain their access to authentication credentials. Reauthentication establishes new keys for the IKE SA and child SAs; rekeys of any pending IKE SA or child SA are no longer needed. After the new IKE and child SAs are created, the old IKE and child SAs are deleted.

IKEv2 reauthentication is disabled by default. You enable reauthentication by configuring a reauthentication frequency value between 1 and 100. The reauthentication frequency is the number of IKE rekeys that occurs before reauthentication occurs. For example, if the configured reauthentication frequency is 1, reauthentication occurs every time there is an IKE rekey. If the configured reauthentication frequency is 2, reauthentication occurs at every other IKE rekey. If the configured reauthentication frequency is 3, reauthentication occurs at every third IKE rekey, and so on.

IKEv2 Fragmentation

When certificate-based authentication is used, IKEv2 packets can exceed the path MTU if multiple certificates are transmitted. If the IKE message size exceeds the path MTU, the messages are fragmented at the IP level. Some network equipment, such as NAT devices, does not allow IP fragments to pass through, which prevents the establishment of IPsec tunnels.

IKEv2 message fragmentation, as described in RFC 7383, Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, allows IKEv2 to operate in environments where IP fragments might be blocked and peers would not be able to establish an IPsec security association (SA). IKEv2 fragmentation splits a large IKEv2 message into a set of smaller ones so that there is no fragmentation at the IP level. Fragmentation takes place before the original message is encrypted and authenticated, so that each fragment is separately encrypted and authenticated. On the receiver, the fragments are collected, verified, decrypted, and merged into the original message.

Traffic Selectors for IKEv2

You can configure traffic Selectors in IKEv2 used during IKE negotiation. A traffic selector is an agreement between IKE peers to permit traffic through a VPN tunnel if the traffic matches a specified pair of local and remote addresses. Only the traffic that conforms to a traffic selector is permitted through the associated security association (SA). Traffic selectors are used during the tunnel creation to set up the tunnel and to determine what traffic is allowed through the tunnel.

Proxy ID

A proxy-ID is used during phase 2 of Internet Key Exchange (IKE) Virtual Private Network (VPN) negotiations. Both ends of a VPN tunnel either have a proxy-ID manually configured (route-based VPN) or just use a combination of source IP, destination IP, and service in a tunnel policy. When phase 2 of IKE is negotiated, each end compares the configured local and remote proxy-ID with what is actually received.

Traffic Selectors

Proxy ID is supported for both route-based and policy-based VPNs. However, the multi-proxy ID is supported for only route-based VPNs. The multi-proxy ID is also known as traffic selector. A traffic selector is an agreement between IKE peers to permit traffic through a tunnel, if the traffic matches a specified pair of local and remote addresses. You define a traffic selector within a specific route-based VPN, which can result in multiple Phase 2 IPsec SAs. Only traffic that conforms to a traffic selector is permitted through an SA. The traffic selector is commonly required when remote gateway devices are non-Juniper Networks devices.

Network Address Translation-Traversal (NAT-T)

Network Address Translation-Traversal (NAT-T) is a method for getting around IP address translation issues encountered when data protected by IPsec passes through a NAT device for address translation.

Any changes to the IP addressing, which is the function of NAT, causes IKE to discard packets. After detecting one or more NAT devices along the data path during Phase 1 exchanges, NAT-T adds a layer of User Datagram Protocol (UDP) encapsulation to IPsec packets so they are not discarded after address translation. NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port. Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.

The location of a NAT device can be such that:

Only the IKEv1 or IKEv2 initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices. Initiators can also connect to the responder through multiple NAT devices.
Only the IKEv1 or IKEv2 responder is behind a NAT device.
Both the IKEv1 or IKEv2 initiator and the responder are behind a NAT device.

Suite B and PRIME Cryptographic Suites

Suite B is a set of cryptographic algorithms designated by the U.S. National Security Agency to allow commercial products to protect traffic that is classified at secret or top secret levels. Suite B protocols are defined in RFC 6379, Suite B Cryptographic Suites for IPsec. The Suite B cryptographic suites provide Encapsulating Security Payload (ESP) integrity and confidentiality and should be used when ESP integrity protection and encryption are both required. Protocol Requirements for IP Modular Encryption (PRIME), an IPsec profile defined for public sector networks in the United Kingdom, is based on the Suite B cryptographic suite, but uses AES-GCM rather than AES-CBC for IKEv2 negotiations.

The following cryptographic suites are supported:

Suite-B-GCM-128
- ESP: Advanced Encryption Standard (AES) encryption with 128-bit keys and 16-octet integrity check value (ICV) in Galois Counter Mode (GCM).
- IKE: AES encryption with 128-bit keys in cipher block chaining (CBC) mode, integrity using SHA-256 authentication, key establishment using Diffie-Hellman (DH) group 19, and authentication using Elliptic Curve Digital Signature Algorithm (ECDSA) 256-bit elliptic curve signatures.
Suite-B-GCM-256
- ESP: AES encryption with 256-bit keys and 16-octet ICV in GCM for ESP.
- IKE: AES encryption with 256-bit keys in CBC mode, integrity using SHA-384 authentication, key establishment using DH group 20, and authentication using ECDSA 384-bit elliptic curve signatures.
PRIME-128
- ESP: AES encryption with 128-bit keys and 16-octet ICV in GCM.
- IKE: AES encryption with 128-bit keys in GCM, key establishment using DH group 19, and authentication using ECDSA 256-bit elliptic curve signatures.
PRIME-256
- ESP: AES encryption with 256-bit keys and 16-octet ICV in GCM for ESP.
- IKE: AES encryption with 256-bit keys in GCM, key establishment using DH group 20, and authentication using ECDSA 384-bit elliptic curve signatures.

Suite-B cryptographic suites support IKEv1 and IKEv2. PRIME cryptographic suites only support IKEv2.