Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Dynamic Security Associations

Configuring IKE Proposals

Dynamic security associations (SAs) require IKE configuration. With dynamic SAs, you configure IKE first, and then the SA. IKE creates the dynamic SAs and negotiates them for IPsec. 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 services ipsec-vpn ike] hierarchy level:

Note:

In Junos FIPS mode, ECDSA is not supported for the authentication method in Junos OS Release 17.3R1. Starting in Junos OS Release 17.4R1, ECDSA is supported in Junos FIPS mode.

This section includes the following topics:

Configuring the Authentication Algorithm for an IKE Proposal

To configure the authentication algorithm for an IKE proposal, include the authentication-algorithm statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

The authentication algorithm can be one of the following:

  • md5—Produces a 128-bit digest.

  • sha1—Produces a 160-bit digest.

  • sha-256—Produces a 256-bit digest.

    Note:

    For reference information on Secure Hash Algorithms (SHAs), see Internet draft draft-eastlake-sha2-02.txt, Secure Hash Algorithms (SHA and HMAC-SHA) (expires July 2006).

Configuring the Authentication Method for an IKE Proposal

To configure the authentication method for an IKE proposal, include the authentication-method statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

Note:

In IKEv1, the authentication method for SAs is negotiated with the remote peer based on the type of authentication method configured in the IKE proposal. In IKEv2, such a negotiation is not performed with the remote peer. Instead, each IKE peer uses the authentication method that is locally configured for them.

For SAs in IKEv2, the authentication method is the default value as IKEv1 if an authentication method is not configured in the IKE proposal. If you are configuring an authentication method for IKEv2, you must have the same authentication method configured for all proposals referenced in the policy.

The authentication method can be one of the following:

Note:

In Junos FIPS mode, ECDSA is not supported for the authentication method in Junos OS Release 17.3R1. Starting in Junos OS Release 17.4R1, ECDSA is supported in Junos FIPS mode.

  • ecdsa-signatures-256—Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Elliptic Curve Digital Signature Algorithm (ECDSA) for 256-bit moduli.

  • ecdsa-signatures-384—Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Elliptic Curve Digital Signature Algorithm (ECDSA) for 384-bit moduli.

  • pre-shared-keys—A key derived from an out-of-band mechanism; the key authenticates the exchanges.

  • rsa-signatures—Public key algorithm (supports encryption and digital signatures).

Configuring the Diffie-Hellman Group for an IKE Proposal

Diffie-Hellman is a public-key cryptography scheme that allows two parties to establish a shared secret over an insecure communications channel. It is also used within IKE to establish session keys.

To configure the Diffie-Hellman group for an IKE proposal, include the dh-group statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

The group can be one of the following:

  • group1—Specifies that IKE uses the 768-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group2—Specifies that IKE uses the 1024-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group5—Specifies that IKE uses the 1536-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group14—Specifies that IKE uses the 2048-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group19—Specifies that IKE uses the 256-bit random Elliptic Curve Diffie-Hellman Group when performing the new Diffie-Hellman exchange.

  • group20—-Specifies that IKE uses the 384-bit random Elliptic Curve Diffie-Hellman Group when performing the new Diffie-Hellman exchange.

Starting in Junos OS release 17.4R1, group15, group16, and group 24 can also be used:

  • group15—Specifies that IKE use the 3072-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group16—Specifies that IKE use the 4096-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group24—Specifies that IKE use the 2048-bit Diffie-Hellman prime modulus group with 256-bit Prime Order Subgroup when performing the new Diffie-Hellman exchange.

Using a Diffie-Hellman group based on a greater number of bits results a more secure IKE tunnel than using a group based on fewer bits. However, this additional security might require additional processing time.

Configuring the Encryption Algorithm for an IKE Proposal

To configure the encryption algorithm for an IKE proposal, include the encryption-algorithm statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

The encryption algorithm can be one of the following:

  • 3des-cbc—Cipher block chaining encryption algorithm with a key size of 24 bytes; its key size is 192 bits long.

  • des-cbc—Cipher block chaining encryption algorithm with a key size of 8 bytes; its key size is 56 bits long.

  • aes-128-cbc—Advanced Encryption Standard (AES) 128-bit encryption algorithm.

  • aes-192-cbc—Advanced Encryption Standard (AES) 192-bit encryption algorithm.

  • aes-256-cbc—Advanced Encryption Standard (AES) 256-bit encryption algorithm.

Note:

For a list of Data Encryption Standard (DES) encryption algorithm weak and semiweak keys, see RFC 2409, The Internet Key Exchange (IKE). The AES encryption algorithms use a software implementation that has much lower throughput, so DES remains the recommended option.

For 3des-cbc, the first 8 bytes should differ from the second 8 bytes, and the second 8 bytes should be the same as the third 8 bytes.

If you configure an authentication proposal but do not include the encryption statement, the result is NULL encryption. Certain applications expect this result. If you configure no specific authentication or encryption values, the Junos OS uses the default values of sha1 for the authentication and 3des-cbc for the encryption.

Configuring the Lifetime for an IKE SA

The lifetime-seconds statement sets the lifetime of an IKE SA. When the IKE SA expires, it is replaced by a new SA (and SPI) or the IPsec connection is terminated.

To configure the lifetime for an IKE SA, include the lifetime-seconds statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level:

By default, the IKE SA lifetime is 3600 seconds. The range is from 180 through 86,400 seconds.

Note:

In IKEv1, the lifetime for SAs is negotiated with the remote peer based on the type of lifetime configured in the IKE proposal. In IKEv2, such a negotiation is not performed with the remote peer. Instead, each IKE peer uses the lifetime that is locally configured for them.

For SAs in IKEv2, the lifetime is either the default value as IKEv1 (if another lifetime is not configured in the IKE proposal) or all IKEv2 proposals in the IKE policy must be configured with the same lifetime value.

Note:

For IKE proposals, there is only one SA lifetime value, specified by the Junos OS. IPsec proposals use a different mechanism.

Example: Configuring an IKE Proposal

Configure an IKE proposal:

See Also

Configuring IKE Policies

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.

Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. You can configure the specific IKE phase to be supported for the negotiation. However, if only IKEv1 is supported, the Junos OS rejects IKEv2 negotiations. Similarly, if only IKEv2 is supported, the Junos OS rejects all IKEv1 negotiations.

The key management process (kmd) daemon determines which version of IKE is used in a negotiation. If kmd is the IKE initiator, it uses IKEv1 by default and retains the configured version for negotiations. If kmd is the IKE responder, it accepts connections from both IKEv1 and IKEv2.

You can create multiple, prioritized proposals at each peer to ensure that at least one proposal matches a remote peer’s proposal.

First, you configure one or more IKE proposals; then you associate these proposals with an IKE policy. You can also prioritize a list of proposals used by IKE in the policy statement by listing the proposals you want to use, from first to last.

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

This section includes the following topics:

Configuring the IKE Phase

Starting with Junos OS Release 11.4, both IKEv1 and IKEv2 are supported by default on all M Series, MX Series, and T Series routers. You can configure the specific IKE phase to be supported for the negotiation. However, if only IKEv1 is supported, the Junos OS rejects IKEv2 negotiations. Similarly, if only IKEv2 is supported, the Junos OS rejects all IKEv1 negotiations.

To configure the IKE phase used, include the version statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

Configuring the Mode for an IKE Policy

IKE policy has two modes: aggressive and main. By default, main mode is enabled. Main mode uses six messages, in three exchanges, to establish the IKE SA. (These three steps are IKE SA negotiation, a Diffie-Hellman exchange, and authentication of the peer.) Main mode also allows a peer to hide its identity.

Aggressive mode also establishes an authenticated IKE SA and keys. However, aggressive mode uses half the number of messages, has less negotiation power, and does not provide identity protection. The peer can use the aggressive or main mode to start IKE negotiation; the remote peer accepts the mode sent by the peer.

Note:

The mode configuration is required only if the version option is set to 1.

To configure the mode for an IKE policy, include the mode statement and specify aggressive or main at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

Configuring the Proposals in an IKE Policy

The IKE policy includes a list of one or more proposals associated with an IKE policy.

To configure the proposals in an IKE policy, include the proposals statement and specify one or more proposal names at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

Configuring the Preshared Key for an IKE Policy

When you include the authentication-method pre-shared-keys statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level, IKE policy preshared keys authenticate peers. You must manually configure a preshared key, which must match that of its peer. The preshared key can be an ASCII text (alphanumeric) key or a hexadecimal key.

To configure the preshared key in an IKE policy, include the pre-shared-key statement and a key at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

The key can be one of the following:

  • ascii-text—ASCII text key. With the des-cbc option, the key contains 8 ASCII characters. With the 3des-cbc option, the key contains 24 ASCII characters.

  • hexadecimal—Hexadecimal key. With the des-cbc option, the key contains 16 hexadecimal characters. With the 3des-cbc option, the key contains 48 hexadecimal characters.

Configuring the Local Certificate for an IKE Policy

When you include the authentication-method rsa-signatures statement at the [edit services ipsec-vpn ike proposal proposal-name] hierarchy level, public key infrastructure (PKI) digital certificates authenticate peers. You must identify a local certificate that is sent to the peer during the IKE authentication phase.

To configure the local certificate for an IKE policy, include the local-certificate statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

The local-certificate statement specifies the identifier used to obtain the end entity’s certificate from the certification authority. Configuring it in an IKE policy allows you the flexibility of using a separate certificate with each remote peer if that is needed. You must also specify the identity of the certification authority by configuring the ca-profile statement at the [edit security pki] hierarchy level.

You can use the configured profiles to establish a set of trusted certification authorities for use with a particular service set. This enables you to configure separate service sets for individual clients to whom you are providing IP services; the distinct service sets provide logical separation of one set of IKE sessions from another, using different local gateway addresses, or virtualization. To configure the set of trusted certification authorities, include the trusted-ca statement at the [edit services service-set service-set-name ipsec-vpn-options] hierarchy level:

See the following to configure a certificate revocation list:

Configuring a Certificate Revocation List

A certificate revocation list (CRL) contains a list of digital certificates that have been cancelled before their expiration date. When a participating peer uses a digital certificate, it checks the certificate signature and validity. It also acquires the most recently issued CRL and checks that the certificate serial number is not on that CRL.

Note:

By default, certificate revocation list verification is enabled. You can disable CRL verification by including the disable statement at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level.

By default, if the router either cannot access the Lightweight Directory Access Protocol (LDAP) URL or retrieve a valid certificate revocation list, certificate verification fails and the IPsec tunnel is not established. To override this behavior and permit the authentication of the IPsec peer when the CRL is not downloaded, include the disable on-download-failure statement at the [edit security pki ca-profile ca-profile-name revocation-check crl] hierarchy level.

To use the CA certificate revocation list, you include statements at the [edit security pki ca-profile ca-profile-name revocation-check] hierarchy level. For details, see the Junos OS System Basics Configuration Guide.

Configuring the Description for an IKE Policy

To specify an optional text description for an IKE policy, include the description statement at the [edit services ipsec-vpn ike policy policy-name hierarchy level:

Configuring Local and Remote IDs for IKE Phase 1 Negotiation

You can optionally specify local identifiers for use in IKE phase 1 negotiation. If the local-id statement is omitted, the local gateway address is used.

Starting with Junos OS Release 19.1R1, you can configure one of the local id type as distinguished name and you can configure one of the remote id type as distinguished name. The distinguished name field can be a container with container string values or wildcard with wildcard string values.

A distinguished name is a name used with digital certificates to uniquely identify a user. For example a distinguished name can be:

  • CN=user

  • DC=example

  • DC=com

For the container string, the order of the fields and their values must exactly match the distinguished name in the peer’s digital certificate. Example: container ["C=US, ST=CA, L=Sunnyvale, O=Juniper, CN=local_neg, CN=test@juniper.net, OU=QA" "cn=admin, ou=eng, o=example, dc=net" ];

For the wildcard string, the configured field and value must match the distinguished name in the peer’s digital certificate but the order of the fields in the DN does not matter. Example: wildcard [ "L=Sunnyvale, O=Juniper" "C=US, ST=CA" ];

To specify one or more local IDs, include the local-id statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

You can also specify remote gateway identifiers for which the IKE policy is used. The remote gateway address in which this policy is defined is added by default.

To specify one or more remote IDs, include the remote-id statement at the [edit services ipsec-vpn ike policy policy-name] hierarchy level:

The any-remote-id option allows any remote address to connect. This option is supported only in dynamic endpoints configurations and cannot be configured along with specific values.

Enabling Invalid SPI Recovery

When peers in a security association (SA) become unsynchronized, packets with invalid security parameter index (SPI) values can be sent out, and the receiving peer drops these packets. For example, this could occur when one of the peers reboots. Starting in Junos OS Release 14.2, you can enable the device to recover when packets with invalid SPIs are received by resynchronizing the SAs.

To enable recovery from invalid SPI values, include the respond-bad-spi statement at the [edit services ipsec-vpn ike policy] policy-name hierarchy level:

Example: Configuring an IKE Policy

Define two IKE policies: policy 10.1.1.2 and policy 10.1.1.1. Each policy is associated with proposal-1 and proposal-2. The following configuration uses only IKEv1 for negotiation.

Note:

Updates to the current IKE proposal and policy configuration are not applied to the current IKE SA; updates are applied to new IKE SAs.

If you want the new updates to take immediate effect, you must clear the existing IKE security associations so that they will be reestablished with the changed configuration. For information about how to clear the current IKE security association, see clear services ipsec-vpn ike security-associations.

See Also

Configuring IPsec Proposals

An IPsec proposal lists protocols and algorithms (security services) to be negotiated with the remote IPsec peer.

To configure an IPsec proposal, include the proposal statement and specify an IPsec proposal name at the [edit services ipsec-vpn ipsec] hierarchy level:

This section discusses the following topics:

Configuring the Authentication Algorithm for an IPsec Proposal

To configure the authentication algorithm for an IPsec proposal, include the authentication-algorithm statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

The authentication algorithm can be one of the following:

  • hmac-md5-96—Hash algorithm that authenticates packet data. It produces a 128-bit digest. Only 96 bits are used for authentication.

  • hmac-sha1-96—Hash algorithm that authenticates packet data. It produces a 160-bit digest. Only 96 bits are used for authentication.

  • hmac-sha-256-128—Hash algorithm that authenticates packet data. Produces a 256-bit authenticator value.

Note:

Keep the following points in mind when you configure the authentication algorithm in an IPsec proposal:

  • When both ends of an IPsec VPN tunnel contain the same IKE proposal but different IPsec proposals, an error occurs and the tunnel is not established in this scenario. For example, if one end of the tunnel contains router 1 configured with the authentication algorithm as hmac-sha- 256-128 and the other end of the tunnel contains router 2 configured with the authentication algorithm as hmac-md5-96, the VPN tunnel is not established.

  • When both ends of an IPsec VPN tunnel contain the same IKE proposal but different IPsec proposals, and when one end of the tunnel contains two IPsec proposals to check whether a less secure algorithm is selected or not, an error occurs and the tunnel is not established. For example, if you configure two authentication algorithms for an IPsec proposal as hmac-sha-256-128 and hmac-md5-96 on one end of the tunnel, router 1, and if you configure the algorithm for an IPsec proposal as hmac-md5-96 on the other end of the tunnel, router 2, the tunnel is not established and the number of proposals mismatch.

  • When you configure two IPsec proposals at both ends of a tunnel, such as the authentication-algorithm hmac-sha-256-128 and authentication- algorithm hmac-md5-96 statements at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level on one of the tunnel, router 1 (with the algorithms in two successive statements to specify the order), and the authentication-algorithm hmac-md5-96 and authentication- algorithm hmac-sha-256-128 statements at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level on one of the tunnel, router 2 (with the algorithms in two successive statements to specify the order, which is the reverse order of router 1), the tunnel is established in this combination as expected because the number of proposals is the same on both ends and they contain the same set of algorithms. However, the authentication algorithm selected is hmac-md5-96 and not the stronger algorithm of hmac-sha-256-128. This method of selection of the algorithm occurs because the first matching proposal is selected. Also, for a default proposal, regardless of whether the router supports the Advanced Encryption Standard (AES) encryption algorithm, the 3des-cbc algorithm is chosen and not the aes-cfb algorithm, which is because of the first algorithm in the default proposal being selected. In the sample scenario described here, on router 2, if you reverse the order of the algorithm configuration in the proposal so that it is the same order as the one specified on router 1, hmac-sha-256-128 is selected as the authentication method.

  • You must be aware of the order of proposals in an IPsec policy at the time of configuration if you want the matching of proposals to happen in a certain order of preference, such as the strongest algorithm to be considered first when a match is made when both policies from the two peers have a proposal.

Configuring the Description for an IPsec Proposal

To specify an optional text description for an IPsec proposal, include the description statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

Configuring the Encryption Algorithm for an IPsec Proposal

To configure encryption algorithm for an IPsec proposal, include the encryption-algorithm statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

The encryption algorithm can be one of the following:

  • 3des-cbc—Encryption algorithm that has a block size of 24 bytes; its key size is 192 bits long.

  • aes-128-cbc—Advanced Encryption Standard (AES) 128-bit encryption algorithm.

  • aes-192-cbc—Advanced Encryption Standard (AES) 192-bit encryption algorithm.

  • aes-256-cbc—Advanced Encryption Standard (AES) 256-bit encryption algorithm.

Note:

In Junos FIPS mode, AES-GCM is not supported in Junos OS Release 17.3R1. Starting in Junos OS Release 17.4R1, AES-GCM is supported in Junos FIPS mode.

  • aes-128-gcm—Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 128-bit encryption algorithm with a 16 octet integrity check value (ICV).

  • aes-192-gcm—Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 192-bit encryption algorithm with a 16 octet integrity check value ICV.

  • aes-256-gcm—Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 256-bit encryption algorithm with a 16 octet integrity check value ICV.

  • des-cbc—Encryption algorithm that has a block size of 8 bytes; its key size is 48 bits long.

Note:

For a list of Data Encryption Standard (DES) encryption algorithm weak and semiweak keys, see RFC 2409, The Internet Key Exchange (IKE). The AES encryption algorithms use a software implementation that has much lower throughput, so DES remains the recommended option.

For 3des-cbc, the first 8 bytes should differ from the second 8 bytes, and the second 8 bytes should be the same as the third 8 bytes.

If you do not configure specific authentication or encryption settings, Junos OS uses the default values of sha1 for the authentication and 3des-cbc for the encryption. For NULL encryption to be effective, you must always specify the Encapsulating Security Payload (ESP) protocol for the NULL encryption algorithm by including the protocol esp statement at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level, regardless of other system configurations.

Configuring the Lifetime for an IPsec SA

When a dynamic IPsec SA is created, two types of lifetimes are used: hard and soft. The hard lifetime specifies the lifetime of the SA. The soft lifetime, which is derived from the hard lifetime, informs the IPsec key management system that the SA is about to expire. This allows the key management system to negotiate a new SA before the hard lifetime expires.

Note:

In IKEv1, the lifetime for SAs is negotiated with the remote peer based on the type of lifetime configured in the IPsec proposal. In IKEv2, such a negotiation is not performed with the remote peer. Instead, each IKE peer uses the lifetime that is locally configured for them.

For SAs in IKEv2, the lifetime is either the default value as IKEv1 (if another lifetime is not configured in the IPsec proposal) or all IKEv2 proposals in the IPsec policy must be configured with the same lifetime value.

To configure the hard lifetime value, include the lifetime-seconds statement and specify the number of seconds at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

The default lifetime is 28,800 seconds. The range is from 180 through 86,400 seconds.

To calculate soft lifetime, lifetime-diff is calculated initially. Then based on whether the peer is the initiator or responder, soft lifetime is calculated.

The lifetime-diff calculation is performed as below:

  • If (3*hard-lifetime)/10 is GREATER than 850 seconds, then lifetime-diff = 850 seconds + jitter between 0 to 850 seconds.

    Note:

    Jitter value increments from 0 to 850 on every IPsec SA install and will reset to 0.

  • If (3*hard-lifetime)/10 is GREATER than 600 seconds and LESS than 850, then lifetime-diff = 600 seconds + random jitter between 0 to 45 seconds.

  • If (3*hard-lifetime)/10 is GREATER than 90 seconds and LESS than 600, then lifetime-diff = 90 seconds + random jitter between 0 to 45 seconds.

  • If (3*hard-lifetime)/10 is LESS than 90 seconds, then lifetime-diff = 90 seconds + random jitter between 0 to 10 seconds.

Based on the lifetime-diff, the soft lifetime is calculated as below:

  • If lifetime-diff is GREATER than hard-lifetime, soft lifetime = (9*hard-lifetime)/10

  • Initiator soft lifetime = hard-lifetime - lifetime-diff

  • Responder soft lifetime = hard-lifetime - lifetime-diff + 45 seconds

Note:

Initiator soft lifetime will be always less than responder soft lifetime. It is to ensure that initiator soft lifetime will expire first so that it can initiate rekey process.

For example, if hard lifetime is configured as 3600 seconds for IPSec SA's:

  • Max soft lifetime of initiator is : 3600 - 850 (jitter equals 0) = 2750 seconds

  • Min soft lifetime of initiator is : 3600 - 850 - 850 (jitter equals 850) = 1900 seconds

  • Max soft lifetime of responder is : 3600 - 850 (jitter equals 0) + 45 = 2795 seconds

  • Min soft lifetime of responder is : 3600 - 850 - 850 (jitter equals 850) + 45 = 1945 seconds

Configuring the Protocol for a Dynamic SA

The protocol statement sets the protocol for a dynamic SA. IPsec uses two protocols to protect IP traffic: ESP and AH. The ESP protocol can support authentication, encryption, or both. The AH protocol is used for strong authentication. AH also authenticates the IP packet. The bundle option uses AH authentication and ESP encryption; it does not use ESP authentication because AH provides stronger authentication of IP packets.

To configure the protocol for a dynamic SA, include the protocol statement and specify the ah, esp, or bundle option at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level:

See Also

Configuring IPsec Policies

An IPsec policy defines a combination of security parameters (IPsec proposals) used during IPsec negotiation. It defines Perfect Forward Secrecy (PFS) and the proposals needed for the connection. During the IPsec negotiation, IPsec looks for a proposal 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.

You can create multiple, prioritized IPsec proposals at each peer to ensure that at least one proposal matches a remote peer’s proposal.

First, you configure one or more IPsec proposals; then you associate these proposals with an IPsec policy. You can prioritize a list of proposals used by IPsec in the policy statement by listing the proposals you want to use, from first to last.

To configure an IPsec policy, include the policy statement, and specify the policy name and one or more proposals to associate with the policy, at the [edit services ipsec-vpn ipsec] hierarchy level:

This section includes the following topics related to configuring an IPsec policy:

Configuring the Description for an IPsec Policy

To specify an optional text description for an IPsec policy, include the description statement at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy level:

Configuring Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) provides additional security by means of a Diffie-Hellman shared secret value. With PFS, if one key is compromised, previous and subsequent keys are secure because they are not derived from previous keys. This statement is optional.

To configure PFS, include the perfect-forward-secrecy statement and specify a Diffie-Hellman group at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy level:

The key can be one of the following:

  • group1—Specifies that IKE use the 768-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group2—Specifies that IKE use the 1024-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group5—Specifies that IKE use the 1536-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group14—Specifies that IKE use the 2048-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

Starting in Junos OS release 17.4R1, group15, group16, and group 24 can also be used for the key:

  • group15—Specifies that IKE use the 3072-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group16—Specifies that IKE use the 4096-bit Diffie-Hellman prime modulus group when performing the new Diffie-Hellman exchange.

  • group24—Specifies that IKE use the 2048-bit Diffie-Hellman prime modulus group with 256-bit Prime Order Subgroup when performing the new Diffie-Hellman exchange.

The higher numbered groups provide more security than the lowered numbered groups, but require more processing time.

Configuring the Proposals in an IPsec Policy

The IPsec policy includes a list of one or more proposals associated with an IPsec policy.

To configure the proposals in an IPsec policy, include the proposals statement and specify one or more proposal names at the [edit services ipsec-vpn ipsec policy policy-name] hierarchy level:

IPsec Policy for Dynamic Endpoints

An IPsec policy for dynamic endpoints defines a combination of security parameters (IPsec proposals) used during IPsec negotiation between dynamic peer security gateways, in which the remote ends of tunnels do not have a statically assigned IP address. During the IPsec negotiation, the IPsec policy looks for an IPsec proposal 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 the 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.

If no policy is set, any policy proposed by the dynamic peer is accepted.

Example: Configuring an IPsec Policy

Define an IPsec policy, dynamic policy-1, that is associated with two proposals (dynamic-1 and dynamic-2):

Note:

Updates to the current IPsec proposal and policy configuration are not applied to the current IPsec SA; updates are applied to new IPsec SAs.

If you want the new updates to take immediate effect, you must clear the existing IPsec security associations so that they will be reestablished with the changed configuration. For information about how to clear the current IPsec security association, see the Junos OS System Basics and Services Command Reference.

See Also

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
17.4R1
Starting in Junos OS Release 17.4R1, ECDSA is supported in Junos FIPS mode.
17.4R1
Starting in Junos OS Release 17.4R1, ECDSA is supported in Junos FIPS mode.
17.4R1
Starting in Junos OS release 17.4R1, group15, group16, and group 24 can also be used
17.4R1
Starting in Junos OS Release 17.4R1, AES-GCM is supported in Junos FIPS mode.
17.4R1
Starting in Junos OS release 17.4R1, group15, group16, and group 24 can also be used for the key
17.3R1
Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Elliptic Curve Digital Signature Algorithm (ECDSA) for 256-bit moduli.
17.3R1
Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Elliptic Curve Digital Signature Algorithm (ECDSA) for 384-bit moduli.
17.3R1
Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 128-bit encryption algorithm with a 16 octet integrity check value (ICV).
17.3R1
Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 192-bit encryption algorithm with a 16 octet integrity check value ICV.
17.3R1
Starting In Junos OS Release 17.3R1 for MS-MPCs and MS-MICs, Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) 256-bit encryption algorithm with a 16 octet integrity check value ICV.
14.2
Starting in Junos OS Release 14.2, you can enable the device to recover when packets with invalid SPIs are received by resynchronizing the SAs.