Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Internet Key Exchange (IKE) for IPsec VPN

Internet Key Exchange version 2 (IKEv2) is an IPsec based tunneling protocol that provides a secure VPN communication channel between peer VPN devices and defines negotiation and authentication for IPsec security associations (SAs) in a protected manner.

IKE and IPsec Packet Processing

IKE provides tunnel management for IPsec and authenticates end entities. IKE performs a Diffie-Hellman (DH) key exchange to generate an IPsec tunnel between network devices. The IPsec tunnels generated by IKE are used to encrypt, decrypt, and authenticate user traffic between the network devices at the IP layer.

IKE Packet Processing

When a cleartext packet arrives on a Juniper Networks device that requires tunneling, and no active Phase 2 SA exists for that tunnel, Junos OS begins IKE negotiations and drops the packet. The source and destination addresses in the IP packet header are those of the local and remote IKE gateways, respectively. In the IP packet payload, there is a UDP segment encapsulating an ISAKMP (IKE) packet. The format for IKE packets is the same for Phase 1 and Phase 2. See Figure 1.

Meanwhile, the source host has sent the dropped packet again. Typically, by the time the second packet arrives, IKE negotiations are complete, and Junos OS protects the packet and all subsequent packets in the session—with IPsec before forwarding it.

Figure 1: IKE Packet for Phases 1 and 2 IKE Packet for Phases 1 and 2

The Next Payload field contains a number indicating one of the following payload types:

  • 0002—SA Negotiation Payload contains a definition for a Phase 1 or Phase 2 SA.

  • 0004—Proposal Payload can be a Phase 1 or Phase 2 proposal.

  • 0008—Transform Payload gets encapsulated in a proposal payload that gets encapsulated in an SA payload.

  • 0010—Key Exchange (KE) Payload contains information necessary for performing a key exchange, such as a DH public value.

  • 0020—Identification (IDx) Payload.

    • In Phase 1, IDii indicates the initiator ID, and IDir indicates the responder ID.

    • In Phase 2, IDui indicates the user initiator, and IDur indicates the user responder.

    The IDs are IKE ID types such as FQDN, U-FQDN, IP address, and ASN.1_DN.

  • 0040—Certificate (CERT) Payload.

  • 0080—Certificate Request (CERT_REQ) Payload.

  • 0100—Hash (HASH) Payload contains the digest output of a particular hash function.

  • 0200—Signature (SIG) Payload contains a digital signature.

  • 0400—Nonce (Nx) Payload contains some pseudorandom information necessary for the exchange).

  • 0800—Notify Payload.

  • 1000—ISAKMP Delete Payload.

  • 2000—Vendor ID (VID) Payload can be included anywhere in Phase 1 negotiations. Junos OS uses it to mark support for NAT-T.

Each ISAKMP payload begins with the same generic header, as shown in Figure 2.

Figure 2: Generic ISAKMP Payload Header Generic ISAKMP Payload Header

There can be multiple ISAKMP payloads chained together, with each subsequent payload type indicated by the value in the Next Header field. A value of 0000 indicates the last ISAKMP payload. See Figure 3 for an example.

Figure 3: ISAKMP Header with Generic ISAKMP Payloads ISAKMP Header with Generic ISAKMP Payloads

IPsec Packet Processing

After IKE negotiations complete and the two IKE gateways have established Phase 1 and Phase 2 security associations (SAs), all subsequent packets are forwarded using the tunnel. If the Phase 2 SA specifies the Encapsulating Security Protocol (ESP) in tunnel mode, the packet looks like the one shown in Figure 4. The device adds two additional headers to the original packet that the initiating host sends.

As shown in Figure 4, the packet that the initiating host constructs includes the payload, the TCP header, and the inner IP header (IP1).

Figure 4: IPsec Packet—ESP in Tunnel Mode IPsec Packet—ESP in Tunnel Mode

The router IP header (IP2), which Junos OS adds, contains the IP address of the remote gateway as the destination IP address and the IP address of the local router as the source IP address. Junos OS also adds an ESP header between the outer and inner IP headers. The ESP header contains information that allows the remote peer to properly process the packet when it receives it. This is shown in Figure 5.

Figure 5: Outer IP Header (IP2) and ESP Header Outer IP Header (IP2) and ESP Header

The Next Header field indicates the type of data in the payload field. In tunnel mode, this value is 4, indicating an IP packet is contained within the payload. See Figure 6.

Figure 6: Inner IP Header (IP1) and TCP Header Inner IP Header (IP1) and TCP Header

Introduction to IKE in Junos OS

IKE provides ways to exchange keys for encryption and authentication securely over an unsecured medium such as the Internet. IKE enables a pair of security gateways to: Dynamically establish a secure tunnel over which security gateways can exchange tunnel and key information. Set up user-level tunnels or SAs, including tunnel attribute negotiations and key management. These tunnels can also be refreshed and terminated on top of the same secure channel. IKE employs Diffie-Hellman methods and is optional in IPsec (the shared keys can be entered manually at the endpoints).

IKEv2 includes support for:

  • Route-based VPNs.

  • Site-to-site VPNs.

  • Dead peer detection.

  • Chassis cluster.

  • Pre-shared key authentication.

  • Certificate-based authentication.

  • Child SAs. An IKEv2 child SA is known as a Phase 2 SA in IKEv1. In IKEv2, a child SA cannot exist without the underlying IKE SA.

  • AutoVPN.

  • Dynamic endpoint VPN.

  • EAP is supported for Remote Access using IKEv2.

  • Traffic selectors.

IKEv2 does not support the following features:

  • Policy-based VPN.

  • VPN monitoring.

  • IP Payload Compression Protocol (IPComp).

Configuring IKEv2 in Junos OS

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. By default, Juniper Networks security devices are IKEv1 peers.

Use the version v2-only configuration statement at the [edit security ike gateway gw-name] hierarchy level to configure IKEv2.

The IKE version is displayed in the output of the show security ike security-associations and show security ipsec security-associations CLI operational commands.

Juniper Networks devices support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a range of tunnel parameters you will accept. Junos OS provides predefined standard, compatible, and basic Phase 2 proposal sets. You can also define custom Phase 2 proposals.

Understanding IKEv2 Configuration Payload

Configuration payload is an Internet Key Exchange version 2 (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. Table 1 describes the IKEv2 configuration attributes supported on SRX Series Firewalls.

Table 1: IKEv2 Configuration Attributes

Attribute Type

Value

Description

Length

INTERNAL_IP4_ADDRESS

1

Specifies an address on the internal network. Multiple internal addresses can be requested. The responder can send up to the number of addresses requested.

0 or 4 octets

INTERNAL_IP4_NETMASK

2

Specifies the internal network's netmask value. Only one netmask value is allowed in the request and response messages (for example, 255.255.255.0), and it must be used only with an INTERNAL_IP4_ADDRESS attribute.

0 or 4 octets

INTERNAL_IP4_DNS

3

Specifies an address of a DNS server within the network. Multiple DNS servers can be requested. The responder can respond with zero or more DNS server attributes.

0 or 4 octets

INTERNAL_IP4_NBNS

4

Specifies an address of a NetBIOS name server (NBNS), for example, a WINS server, within the network. Multiple NBNS servers can be requested. The responder can respond with zero or more NBNS server attributes.

0 or 4 octets

INTERNAL_IP6_ADDRESS

8

Specifies an address on the internal network. Multiple internal addresses can be requested. The responder can send up to the number of addresses requested.

0 or 17 octets

INTERNAL_IP6_DNS

10

Specifies an address of a DNS server within the network. Multiple DNS servers can be requested. The responder can respond with zero or more DNS server attributes.

0 or 16 octets

For the IKE responder to provide the initiator with provisioning information, it must acquire the information from a specified source such as a RADIUS server. Provisioning information can also be returned from a DHCP server through a RADIUS server. On the RADIUS server, the user information should not include an authentication password. The RADIUS server profile is bound to the IKE gateway using the aaa access-profile profile-name configuration at the [edit security ike gateway gateway-name] hierarchy level.

Starting in Junos OS Release 20.3R1, on SRX5000 line with SPC3 and vSRX Virtual Firewall running iked process, we’ve improved IKEv2 configuration payload to:

  • Support for IPv4 and IPv6 local address pool. You can also assign a fixed IP address to a peer.

    During IKE establishment, the initiator requests for an IPv4 address, IPv6 address, DNS address, or WINS address from the responder. After the responder has authenticated the initiator successfully, it assigns an IP address either from a local address pool or through RADIUS server. Depending on the configuration, this IP address is either assigned dynamically each time when a peer connects or assigned as a fixed IP address. If the RADIUS server responds with a framed pool, Junos OS assigns an IP address or information based on configuration from it's corresponding local pool. If you configure both local address pool and RADIUS server, the IP address allocated from RADIUS server takes precedence over the local pool. If you configure local IP address pool and the RADIUS server did not return any IP address, then local pool assigns the IP address to the request.

  • Additional option, none introduced for authentication-order. See authentication-order (Access Profile).

  • RADIUS accounting start and stop messages inform the state of the tunnel or peer to the RADIUS server. These messages can be used for tracking purposes or notifications to subsystems such as a DHCP server.

    Ensure that the RADIUS server support accounting start or stop messages. Also ensure that both the SRX Series Firewalls and the RADIUS server have appropriate settings to track these messages.

  • Introduction of IPv6 support allows dual stack tunnels using configuration payload. During login process, IKE requests for both IPv4 and IPv6 addresses. AAA allow login only if all requested addresses have been allocated successfully. IKE terminates the negotiation if the requested IP is not allocated.

In a route-based VPN, secure tunnel (st0) interfaces operate in either point-to-multipoint or point-to-point mode. Address assignment through the IKEv2 configuration payload is now supported for point-to-multipoint or point-to-point mode. For point-to-multipoint interfaces, the interfaces must be numbered and the addresses in the configuration payload INTERNAL_IP4_ADDRESS attribute type must be within the subnetwork range of the associated point-to-multipoint interface.

Starting in Junos OS Release 20.1R1, you can configure a common password for IKEv2 configuration payload requests for an IKE gateway configuration. The common password in the range of 1 to 128 characters allows the administrator to define a common password. This password is used between the SRX Series Firewall and the RADIUS server when the SRX Series Firewall requesting an IP address on behalf of a remote IPsec peer using IKEv2 configuration payload. RADIUS server matches the credentials before it provides any IP information to the SRX Series Firewall for the configuration payload request. You can configure the common password using config-payload-password configured-password configuration statement at [edit security ike gateway gateway-name aaa access-profile access-profile-name] hierarchy level.

Both the SRX Series Firewall and the RADIUS server must have the same password configured and the radius server should be configured to use Password Authentication Protocol (PAP) as the authentication protocol. Without this, tunnel establishment will not be successful.

Figure 7 shows a typical workflow for a IKEv2 Configuration Payload.

Figure 7: Typical IKEv2 Configuration Payload WorkflowTypical IKEv2 Configuration Payload Workflow

The IKEv2 configuration payload feature is supported for both point-to-multipoint secure tunnel (st0) interfaces and point-to-point interfaces. Point-to-multipoint interfaces must be numbered, and the addresses provided in the configuration payload must be within the subnetwork range of the associated point-to-multipoint interface.

Starting in Junos OS Release 20.1R1, we support IKEv2 configuration payload feature with point-to-point interfaces on SRX5000 line and vSRX Virtual Firewall running iked.

Understanding Pico Cell Provisioning

IKEv2 configuration payload can be used to propagate provisioning information from an IKE responder, such as an SRX Series Firewall, to multiple initiators, such as LTE pico cell base stations in a cellular network. The pico cells ship from the factory with a standard configuration that allows them to connect to the SRX Series Firewall, but the pico cell provisioning information is stored on one or more provisioning servers within a protected network. The pico cells receive full provisioning information after establishing secure connections with the provisioning servers.

The workflow required to bootstrap and provision a pico cell and introduce it to service includes four distinct stages:

  1. Initial addresses acquisition—The pico cell ships from the factory with the following information:

    • Configuration for the secure gateway tunnel to the SRX Series Firewall

    • Digital certificate issued by the manufacturer

    • Fully qualified domain name (FQDN) of the provisioning servers that lie within the protected network

    The pico cell boots up and acquires an address to be used for IKE negotiation from a DHCP server. A tunnel is then built to the secure gateway on the SRX Series Firewall using this address. An address for Operation, Administration, and Management (OAM) traffic is also assigned by the DHCP server for use on the protected network.

  2. Pico cell provisioning—Using its assigned OAM traffic address, the pico cell requests its provisioning information—typically operator certificate, license, software, and configuration information—from servers within the protected network.

  3. Reboot—The pico cell reboots and uses the acquired provisioning information to make it specific to the service provider’s network and operation model.

  4. Service provision—When the pico cell enters service, it uses a single certificate that contains distinguished name (DN) and subject alternative name values with a FQDN to build two tunnels to the secure gateway on the SRX Series Firewall: one for OAM traffic and the other for Third-Generation Partnership Project (3GPP) data traffic.

IKE Proposal

The IKE configuration defines the algorithms and keys used to establish the secure IKE connection with the peer security gateway. You can configure one or more IKE proposals. Each proposal is a list of IKE attributes to protect the IKE connection between the IKE host and its peer.

To configure an IKE proposal, include the proposal statement and specify a name at the [edit security ike ] hierarchy level:

IKE Policy

An IKE policy defines a combination of security parameters (IKE proposals) to be used during IKE negotiation. It defines a peer address and the proposals needed for that connection. Depending on which authentication method is used, it defines the preshared key for the given peer or the local certificate. During the IKE negotiation, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation sends all its policies to the remote peer, and the remote peer tries to find a match. A match is made when both policies from the two peers have a proposal that contains the same configured attributes. If the lifetimes are not identical, the shorter lifetime between the two policies (from the host and peer) is used. The configured preshared key must also match its peer.

First, you configure one or more IKE proposals; then you associate these proposals with an IKE policy.

To configure an IKE policy, include the policy statement and specify a policy name at the [edit security ike] hierarchy level:

Rekeying and Reauthentication

Overview

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.

You configure the reauthentication frequency with the reauth-frequency statement at the [edit security ike policy policy-name] hierarchy level. Reauthentication is disabled by setting the reauthentication frequency to 0 (the default). Reauthentication frequency is not negotiated by peers, and each peer can have its own reauthentication frequency value.

Supported Features

IKEv2 reauthentication is supported with the following features:

  • IKEv2 initiators or responders

  • Dead peer detection (DPD)

  • Virtual routers and secure tunnel (st0) interfaces in virtual routers

  • Network Address Translation traversal (NAT-T)

  • Chassis clusters in active-active and active-passive mode for SRX5400, SRX5600, and SRX5800 devices

  • In-service software upgrade (ISSU) on SRX5400, SRX5600, and SRX5800 devices

  • Upgrade or insertion of a new Services Processing Unit (SPU) using the in-service hardware upgrade (ISHU) procedure

Limitations

Note the following caveats when using IKEv2 reauthentication:

  • With NAT-T, a new IKE SA can be created with different ports from the previous IKE SA. In this scenario, the old IKE SA might not be deleted.

  • In a NAT-T scenario, the initiator behind the NAT device can become the responder after reauthentication. If the NAT session expires, the NAT device might discard new IKE packets that might arrive on a different port. NAT-T keepalive or DPD must be enabled to keep the NAT session alive. For AutoVPN, we recommend that the reauthentication frequency configured on the spokes be smaller than the reauthentication frequency configured on the hub.

  • Based on the reauthentication frequency, a new IKE SA can be initiated by either the initiator or the responder of the original IKE SA. Because Extensible Authentication Protocol (EAP) authentication and configuration payload require the IKE SA to be initiated by the same party as the original IKE SA, reauthentication is not supported with EAP authentication or configuration payload.

IKE Authentication (Certificate-Based Authentication)

Multilevel Hierarchy for Certificate Authentication

Certificate-based authentication is an authentication method supported on SRX Series Firewalls during IKE negotiation. In large networks, multiple certificate authorities (CAs) can issue end entity (EE) certificates to their respective end devices. It is common to have separate CAs for individual locations, departments, or organizations.

When a single-level hierarchy for certificate-based authentication is employed, all EE certificates in the network must be signed by the same CA. All firewall devices must have the same CA certificate enrolled for peer certificate validation. The certificate payload sent during IKE negotiation only contains EE certificates.

Alternatively, the certificate payload sent during IKE negotiation can contain a chain of EE and CA certificates. A certificate chain is the list of certificates required to validate a peer’s EE certificate. The certificate chain includes the EE certificate and any CA certificates that are not present in the local peer.

The network administrator needs to ensure that all peers participating in an IKE negotiation have at least one common trusted CA in their respective certificate chains. The common trusted CA does not have to be the root CA. The number of certificates in the chain, including certificates for EEs and the topmost CA in the chain, cannot exceed 10.

Starting with Junos OS Release 18.1R1, validation of a configured IKE peer can be done with a specified CA server or group of CA servers. With certificate chains, the root CA must match the trusted CA group or CA server configured in the IKE policy

In the example CA hierarchy shown in Figure 8, Root-CA is the common trusted CA for all devices in the network. Root-CA issues CA certificates to the engineering and sales CAs, which are identified as Eng-CA and Sales-CA, respectively. Eng-CA issues CA certificates to the development and quality assurance CAs, which are identified as Dev-CA and Qa-CA, respectively. Host-A receives its EE certificate from Dev-CA while Host-B receives its EE certificate from Sales-CA.

Figure 8: Multilevel Hierarchy for Certificate-Based AuthenticationMultilevel Hierarchy for Certificate-Based Authentication

Each end device needs to be loaded with the CA certificates in its hierarchy. Host-A must have Root-CA, Eng-CA, and Dev-CA certificates; Sales-CA and Qa-CA certificates are not necessary. Host-B must have Root-CA and Sales-CA certificates. Certificates can be loaded manually in a device or enrolled using the Simple Certificate Enrollment Process (SCEP).

Each end device must be configured with a CA profile for each CA in the certificate chain. The following output shows the CA profiles configured on Host-A:

The following output shows the CA profiles configured on Host-B:

IKE Protection from DDoS Attacks

SUMMARY Read this topic to understand how Juniper protects IPsec VPN IKE implementations from distributed denial-of-service (DDoS) attacks and monitors the implementations.

Denial of service (DoS) is one of the most common yet serious attacks in an insecure IPsec VPN network. A DoS attack provides a quick and easy way to grab the network as it doesn’t require much toehold in the network infrastructure. Cyberattackers choose this method to take control of the network.

What happens in a DoS attack?

The attacker tries to flood and gradually crash the network with too much traffic, depleting the network resources, and further taking control of the device resources such as memory and CPU. If the attacker tries to control using multiple orchestrated systems, synchronously attacking a single target, it is called Distributed DoS (DDoS) attacks.

DDoS Vulnerabilities on IKE Implementations

When the remote peer (initiator) sends an SA_INIT message, the local peer (responder) replies and allocates memory for the message structure. We call the session a half-open IKE session until authentication happens with the help of the IKE_AUTH message. After the peers establish an IKE security association (SA), the session becomes a full-open IKE session.

To understand the IKEv2 DDoS vulnerabilities, let's look at some of the ways an attacker can create an easy attack vector against the IKE SAs:

  • Send a large number of SA_INIT messages (without IKE_AUTH messages) for which the attacker can create half-open IKE security association structures. The attack causes the device to utilize the resources and run out of memory.

  • Send a large number of junk IKE_AUTH packets with the correct SPI_i and SPI_r on the initiator and the responder, respectively. The device runs out of memory while trying to decrypt the packets.

  • Send SA_INIT packets continuously. The device runs out of memory while trying to generate keys for the encrypted packets.

  • Send a large number of rekey requests per second during full open IKE sessions.

  • Send a large number of messages with distinct message identifiers (IDs). The device queues all incoming IKE messages and runs out of memory.

How to safeguard the IKE implementations

We provide a robust infrastructure to mitigate and to monitor DDoS attacks for both IKEv1 and IKEv2 protocols. You can protect against the attacks on IKE implementations when your firewall runs the iked process (in the junos-ike package) for the IPsec VPN service.

Note:

For details about DDoS protection for IKEv2, see RFC 8019, Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks. We provide similar protection for IKEv1 when your firewall runs the IPsec VPN service using the iked process. We do not support the client puzzle mechanism that the RFC presents.

Protection Against DDoS Attacks

You can enable multiple defense mechanisms against the DDoS attacks during the IKE security association creation process. These mechanisms include configuration of rate limiting and a retention period for the half-open IKE SAs, and further managing the incoming exchange rates for the rekey requests. We provide the following measures to ensure protection against DDoS attacks on IKE SAs:

  • Protection measures for half-open IKE SAs:
    • The responder does not allow configuration of half-open IKE SAs for a certain duration. You can set this limit so that the responder does not configure the SAs until it reaches the timeout duration. For more details, see session (Security IKE) for the option timeout.

    • You can set a limit on the maximum allowed half-open IKE SAs on the responder. When the total number of half-open IKE SAs reaches the maximum count, the responder rejects new connections for both IKEv1 and IKEv2 SAs. For more details, see the max-count option insession (Security IKE).

    • The responder enforces threshold values on the session count for half-open IKE SAs. When the total number of half-open IKE SAs reaches the threshold values:

      • In case of IKEv2 SAs, the responder invokes cookie mechanism for any new connections.

      • In case of IKEv1 SAs, the responder rejects new connections.

      For more details, see the thresholds, send-cookie and reduce-timeout options in session (Security IKE).

    • The responder can discard duplicate sessions. For more details, see the discard-duplicate option in session (Security IKE).

    • You can set backoff timeouts for authentication failure and initiation failure phases. For more details, see session (Security IKE) for the options backoff-timeouts, init-phase-failure and auth-phase-failure.

  • For full open IKE SAs:

    • You can configure maximum incoming rekey request rates to throttle the requests in a scaled scenario. For more details, see the incoming-exchange-max-rates option in session (Security IKE).

  • The responder can block an incoming IKE session from peers based on the peer IKE ID. For more details, see blocklists (Security IKE).

  • For dynamic gateways, you can set a limit for the number of connections at the IKE gateway configuration level using the option connections-limit. For more details, see gateway (Security IKE).

For further details on how to configure these options, see Configure Protection Against IKE DDoS Attacks.

We do not support:

  • DDoS protection with IPsec VPN service based on the kmd process.

  • Protection against Hash and URL certificate encoding attacks as we do not support these encoding types.

Ways to Monitor DDoS Attacks

We provide the following mechanisms to monitor the DDoS attacks:

  • Use the show security ike security-associations command to list down all the matured and non-matured IKE security associations. For more details, see show security ike security-associations.

  • Use the show security ike stats command to display global IKE statistics of the IPsec VPN tunnel, such as in-progress, established, expired statistics. For more details, see show security ike stats.

  • Use the show security ike active-peer command to display details of the successful IKE negotiations with the remote peers. For more details, see show security ike active-peer.

  • Use the show security ike peers in-progress command to display the details of in progress IKE SAs, including the half open IKE SAs. For more details, see show security ike peers. You can also see the details of the blocked, failed, and backoff peers using this command.

  • Use the clear security ike peers command to clear the IKE peers that are backed off, blocked, failed or in progress. For more details, see clear security ike peers.

  • To delete an existing IKE security association with peers that needs to be blocked from further communications, use the clear security ike security-associations command. For more details, see clear security ike security-associations.

  • The iked system log (syslog) messages IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF and IKE_GATEWAY_PEER_FAILED provide details about the blocked, backed-off, and failed IKE negotiations with the remote peers, respectively.

  • For additional security, Junos OS provides services to users for protection against packet-based system attacks such as filtering, session count, and rate limiting. For more details, see the show firewall command and the ids-option statement at the [edit security screen ids-option screen-name] hierarchy level.

Configure Protection Against IKE DDoS Attacks

SUMMARY See this section to understand how to configure protection against DDoS attacks on IKE protocol.

Preprequisites

Before configuring protection against the IKE DDoS attacks, ensure that you meet the following prerequisites:

  • SRX Series Firewall that supports junos-ike package to run the IPsec VPN service using the iked process.

  • SRX Series Firewall that serves as the local endpoint (the responder) is reachable to the remote IKE peer (the initiator).

  • An IKE policy that can associate an IKE blocklist.

Following actions are involved in configuring protection against the IKE DDoS attacks:

  • Manage the incoming half open IKE SAs.

  • Manage the incoming full open IKE SAs.

  • Configure multiple blocking methods in order to block the incoming IKE sessions from various peers and associate one of the blocklists with an IKE peer.

See the following tasks to configure these actions.

Configure the IKE Session for Half Open IKE SAs

Overview

Ensure you meet all the prerequisites discussed above.

In this section, you'll see how to configure the timeouts, maximum count and thresholds for the half open IKE SAs. The configuration changes are applicable to the new sessions, while the existing sessions continue to use the default values when not configured explicitly earlier. The scope of these configurations at the [edit security ike session half-open] hierarchy level is applicable at global level and not per peer level.

Configuration

  • To set the responder lifetime parameter using the option timeout seconds:

    During this period, the responder does not allow the configuration of half open IKE SAs till it reaches the timeout duration. The initiator can continue to have 60 seconds timeout duration irrespective of the responder's configuration.

  • To set the responder maximum count parameter using the option max-count value:

    The option sets the maximum numbers of half open IKE sessions on the responder. The default value is 300, if you do not specify. The max-countconfiguration disables all thresholds. In such cases, you need to expliclty configure thresholds to enforce them.

  • Specify the different types of actions using the option threshold when the responder's session count reaches the limit.

    • To set the minimum number of half open IKE sessions to enforce cookie action using the option send-cookie count:

      This specifies the threshold limit from which the responder requests the remote peers to retry the session initiation with a cookie sent back to the peer in the initial response. Here, when the half open IKE session count limit reaches 500, the iked process employs a cookie mechanism for the new IKE sessions.

    • To set the minimum number of half open IKE sessions to enforce reduced timeout action using the option reduced-timeout count timeout seconds:

      This specifies the limit from which the iked process reduces the lifetime of the new half open IKE SAs. Once the half open responder IKE session count reduces below the threshold, the half open responder IKE sessions use the default timeout value again.

  • To set the option discard-duplicate in order to discard the duplicate half open IKE sessions without sending response back to the initiator:

    For a duplicate session initiation request (SA_INIT) that comes from the same peer, with a different initiator cookie for which there is no IKE SA while the negotiation is in progress, the responder discards the packet.

  • You can set the backoff timeouts using the option backoff-timeouts.

    This gives some time for the remote peer to back off in the event of a session initiation failure, ensuring that the same peer cannot initiate a new session during that period. After the backoff timeout, the peer can initiate a new session. The session initiation can fail at two phases—the initialization phase and the authentication phase.

    • To set the backoff timeout when there's a failure during the IKE_AUTH phase using the option backoff-timeouts auth-phase-failure value:

      When you configure auth-phase-failure, any remote peer that is blocklisted, backsoff even when you do not configure backoff as an action for the target blocklist rule. The timeout for the backoff is the one configured for auth-phase-failure. In this example, the device initiates a new session after 150 seconds. To overwrite this backoff timeout for a particular rule, you can explicitly configure the backoff action for the blocklist rule mentioning the timeout at the [edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level.

    • To set the backoff timeout when there's a failure during the SA_INIT phase using the option backoff-timeouts init-phase-failure value:

      In this example, the device initiates a new session after 160 seconds.

    • To set the responder lifetime parameter using the option timeout seconds:

      During this period, the responder does not allow the configuration of half open IKE SAs till it reaches the timeout duration. The initiator can continue to have 60 seconds timeout duration irrespective of the responder's configuration.

Configure the IKE Session for Full Open IKE SAs

Overview

Ensure you meet all the prerequisites discussed above.

In this section, you'll see how to configure various incoming request rates for the full open IKE SAs using the option incoming-exchange-max-rates at the [edit security ike session full-open] hierarchy level.

Configuration

Configure the incoming-exchange-max-rates option to set the maximum rates for various exchanges initiated by the remote peer after establishing an IKE SA. You can configure three types of exchange rates—IKE rekey, IPsec rekey and keepalive (also known as Dead Peer Detection).

  • To set the incoming peer initiated IKE rekey maximum rate using the option incoming-exchange-max-rates ike-rekey value:

    The option is applicable to IKEv2 rekey on a per peer basis with an existing peer where an IKE SA is already present.

  • To set the incoming peer initiated IPsec SA rekey maximum rate using the option incoming-exchange-max-rates ipsec-rekey value:

    The limit is applicable on a per tunnel basis.

  • To set the incoming peer initiated keepalive maximum rate using the option incoming-exchange-max-rates keepalive value:

    The limit is applicable on a per peer basis.

Configure the IKE Session Blocklists

Overview

Ensure you meet all the prerequisites discussed above.

To block an incoming IKE session from peers based on the peer IKE ID, you need to configure one or more blocklists. Each blocklist contains one or more rules. Each rule has a match criteria and an action.

Consider the following criteria when configuring the blocklists:

  • Blocklist rules are applicable on the new IKE SAs that are being negotiated and doesn't affect the existing IKE SAs. At the peer authentication stage, the device applies the blocklist rules.

  • The order of application of the rules is dependent on the sequence in which these rules are listed.

  • Configure the match criteria based on the role (initiator or responder), an ID type (IPv4 or IPv6 address, hostname, distinguished name, email ID, or a key ID) and an ID pattern which is a regular expression to match the IKE ID.

  • You can configure each rule with an ID type. This allows you to configure different IKE IDs for different rules within the same blocklist.

  • Configure an action to either discard or reject the peer connection. Based on the match, the device applies an action. Optionally, you can set the backoff timer with these actions.

  • Refer the blocklist in the IKE policy which is associated to the IKE gateway.

  • Each IKE gateway supports only one type of remote IKE ID type. If you attach a blocklist to a gateway and configure it with rules containing different IKE IDs, the gateway will apply and match only the rules whose IKE ID type is the same as the one configured for the IKE gateway.

  • The tunnel setup rate metrices with blocklists that are attached to the IKE gateways is based on the number of rules configured in the blocklists.

In this section, you'll see how to configure blocklists and associate the blocklist to an IKE policy.

Configuration

  • To create a blocklist with multiple rules:

    • Create a blocklist.

    • Create one or more rules.

    You can create multiple such blocklists and its rules.

  • To configure the match criteria and specify the action:

    • Configure the match criteria for the rule1 in the blocklist blocklist1.

      To configure blocklists using a group of IKE IDs or partial IKE IDs, use the id-pattern value with a suffix or prefix. For example, you can use the value *.example.com, when you need to match hr.example.com, finance.example.com, admin.example.com. In the rule rule1, the device looks for the hostname that matches the pattern peer.*\.example\.net. Here peer.example.net, peer.1.example.net, and peer.uplink.example.net are a few potential matches. In the rule rule2, the device looks for the email address that matches the pattern hr.example.com. Similarly, you can configure another match criteria for the other rules based on different id-type or id-pattern. These patterns use the standard regular expression.

    • Specify the action for a match:

  • To associate a blocklist with an IKE peer:

    • Configure the blocklist blocklist1 in the IKE policy ike_policy1.

Example: Configuring a Device for Peer Certificate Chain Validation

This example shows how to configure a device for certificate chains used to validate peer devices during IKE negotiation.

Requirements

Before you begin, obtain the address of the certificate authority (CA) and the information they require (such as the challenge password) when you submit requests for local certificates.

Overview

This example shows how to configure a local device for certificate chains, enroll CA and local certificates, check the validity of enrolled certificates, and check the revocation status of the peer device.

Topology

This example shows the configuration and operational commands on Host-A, as shown in Figure 9. A dynamic CA profile is automatically created on Host-A to allow Host-A to download the CRL from Sales-CA and check the revocation status of Host-B’s certificate.

Figure 9: Certificate Chain ExampleCertificate Chain Example

The IPsec VPN configuration for Phase 1 and Phase 2 negotiation is shown for Host-A in this example. The peer device (Host-B) must be properly configured so that Phase 1 and Phase 2 options are successfully negotiated and security associations (SAs) are established. See Configuring Remote IKE IDs for Site-to-Site VPNs for examples of configuring peer devices for VPNs.

Configuration

To configure a device for certificate chains:

Configure CA Profiles

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure CA profiles:

  1. Create the CA profile for Root-CA.

  2. Create the CA profile for Eng-CA.

  3. Create the CA profile for Dev-CA.

Results

From configuration mode, confirm your configuration by entering the show security pki command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Enroll Certificates

Step-by-Step Procedure

To enroll certificates:

  1. Enroll the CA certificates.

    Type yes at the prompts to load the CA certificate.

  2. Verify that the CA certificates are enrolled in the device.

  3. Verify the validity of the enrolled CA certificates.

  4. Generate a key pair.

  5. Enroll the local certificate.

  6. Verify that the local certificate is enrolled in the device.

  7. Verify the validity of the enrolled local certificate.

  8. Check the CRL download for configured CA profiles.

Configure IPsec VPN Options

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IPsec VPN options:

  1. Configure Phase 1 options.

  2. Configure Phase 2 options.

Results

From configuration mode, confirm your configuration by entering the show security ike and show security ipsec commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

If certificate validation is successful during IKE negotiation between peer devices, both IKE and IPsec security associations (SAs) are established.

The IKE SA is UP if the certificate is valid. The IKE SA is DOWN and IPSEC SA is formed if the certificate is revoked, only if revocation check is configured on the peer device

Verifying IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

Enter the show security ike security-associations command from operational mode.

Verifying IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

Enter the show security ipsec security-associations command from operational mode.

IKE and IPsec SA Failure for a Revoked Certificate

Checking for Revoked Certificates

Problem

If certificate validation fails during IKE negotiation between peer devices, check to make sure that the peer’s certificate has not been revoked. A dynamic CA profile allows the local device to download the CRL from the peer’s CA and check the revocation status of the peer’s certificate. To enable dynamic CA profiles, the revocation-check crl option must be configured on a parent CA profile.

Solution

To check the revocation status of a peer’s certificate:

  1. Identify the dynamic CA profile that will show the CRL for the peer device by entering the show security pki crl command from operational mode.

    The CA profile dynamic-001 is automatically created on Host-A so that Host-A can download the CRL from Host-B’s CA (Sales-CA) and check the revocation status of the peer’s certificate.

  2. Display CRL information for the dynamic CA profile by entering the show security pki crl ca-profile dynamic-001 detail command from operational mode.

    Enter

    Host-B’s certificate (serial number 10647084) has been revoked.

IKEv2 Fragmentation

Message Fragmentation

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.

For IKEv2 fragmentation to occur, both VPN peers must indicate fragmentation support by including the IKEV2_FRAGMENTATION_SUPPORTED notification payload in the IKE_SA_INIT exchange. If both peers indicate fragmentation support, it is up to the initiator of the message exchange to determine whether or not IKEv2 fragmentation is used.

On SRX Series Firewalls, a maximum of 32 fragments are allowed per IKEv2 message. If the number of IKEv2 message fragments to be sent or received exceeds 32, the fragments are dropped and the tunnel is not established. Retransmission of individual message fragments is not supported

Configuration

On SRX Series Firewalls, IKEv2 fragmentation is enabled by default for IPv4 and IPv6 messages. To disable IKEv2 fragmentation, use the disable statement at the [edit security ike gateway gateway-name fragmentation] hierarchy level. You can also use the size statement to configure the size of the packet at which messages are fragmented; the packet size ranges from 500 to 1300 bytes. If size is not configured, the default packet size is 576 bytes for IPv4 traffic and 1280 bytes for IPv6 traffic. An IKEv2 packet that is larger than the configured packet size is fragmented.

After IKEv2 fragmentation is disabled or enabled or the packet fragment size is changed, the VPN tunnels that are hosted on the IKE gateway are brought down and IKE and IPsec SAs are renegotiated.

Caveats

The following features are not supported with IKEv2 fragmentation:

  • Path MTU Discovery.

  • SNMP.

IKE Policy with a Trusted CA

This example shows how to bind a trusted CA server to an IKE policy of the peer.

Before you begin, you must have a list of all the trusted CAs you want to associate with the IKE policy of the peer.

You can associate an IKE policy to a single trusted CA profile or a trusted CA group. For establishing a secure connection, the IKE gateway uses the IKE policy to limit itself to the configured group of CAs (ca-profiles) while validating the certificate. A certificate issued by any source other than the trusted CA or trusted CA group is not validated. If there is a certificate validation request coming from an IKE policy then the associated CA profile of the IKE policy will validate the certificate. If an IKE policy is not associated with any CA then by default the certificate is validated by any one of the configured CA profiles.

In this example, a CA profile named root-ca is created and a root-ca-identity is associated to the profile.

You can configure a maximum of 20 CA profiles that you want to add to a trusted CA group. You cannot commit your configuration if you configure more than 20 CA profiles in a trusted CA group.

  1. Create a CA profile and associate a CA identifier to the profile.
  2. Define an IKE proposal and the IKE proposal authentication method.
  3. Define the Diffie-Hellman group, authentication algorithm, an encryption algorithm for the IKE proposal.
  4. Configure an IKE policy and associate the policy with the IKE proposal.
  5. Configure a local certificate identifier for the IKE policy.
  6. Define the CA to be used for the IKE policy.

To view the CA profiles and the trusted CA groups configured on your device, run show security pki command.

The show security ike command displays the CA profile group under the IKE policy named ike_policy and the certificate associated with the IKE policy.

Configuring Establish-Tunnel Responder-only in IKE

This topic shows how to configure establish-tunnels responder-only in Internet Key Exchange (IKE). Initiate the tunnels from the remote peer and send the traffic through all the tunnels. Specifies when IKE is activated.

Starting in Junos OS Release 19.1R1, on SRX5000 line, the establish tunnels option supports the responder-only and responder-only-no-rekey values under the [edit security ipsec vpn vpn-name] hierarchy-level.

The responder-only and responder-only-no-rekey options are supported on the SRX5000 line with an SPC3 card only if the junos-ike-package is installed. These options are supported only on a site-to-site VPN. These option are not supported on Auto VPN.

The responder-only and responder-only-no-rekey options does not establish any VPN tunnel from the device, so the VPN tunnel is initiated from the remote peer. When you configure responder-only, an established tunnel rekeys both IKE and IPsec based on the configured IKE and IPsec lifetime values. When you configure responder-only-no-rekey, an established tunnel does not rekey from the device and relies on the remote peer to initiate rekey. If the remote peer does not initiate rekey, then the tunnel teardown occurs after hard-lifetime expires.

Before you begin:

  • Understand how to establish an AutoKey IKE IPsec tunnel. Read IPsec Overview.

To configure establish-tunnel responder-only in IKE:

  1. Configure establish-tunnel responder-only
  2. Confirm your configuration by entering the show security ipsec vpn IPSEC_VPN command.
  3. Configure establish-tunnel responder-only-no-rekey
  4. Confirm your configuration by entering the show security ipsec vpn IPSEC_VPN command.

    In case of multiple VPN objects, the Responder-only mode will take precedence. If any of the VPN in a gateway is configured with responder-only mode, all VPN's in the gateway must be configured with the responder-only mode.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
23.4R1
Support for IKE protection from DDoS attacks is introduced in Junos OS Release 23.4R1.
18.1R1
Starting with Junos OS Release 18.1R1, validation of a configured IKE peer can be done with a specified CA server or group of CA servers.