Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Configuring Security Associations

To use IPsec services, you create a security association (SA) between hosts. An SA is a simplex connection that enables two hosts to communicate with each other securely using IPsec.

Note:

Both OSPFv2 and OSPFv3 support IPsec authentication. However, dynamic or tunnel mode IPsec SAs are not supported for OSPFv3. If you add SAs into OSPFv3 by including the ipsec-sa statement at the [edit protocols ospf3 area area-number interface interface-name] hierarchy level, your configuration commit fails. For more information about OSPF authentication and other OSPF properties, see the Junos OS Routing Protocols Library.

You can configure two types of SAs:

  • Manual—Requires no negotiation; all values, including the keys, are static and specified in the configuration. As a result, each peer must have the same configured options for communication to take place.

  • Dynamic—Specifies proposals to be negotiated with the tunnel peer. The keys are generated as part of the negotiation and therefore do not need to be specified in the configuration. The dynamic SA includes one or more proposal statements that prioritizes a list of protocols and algorithms to be negotiated with the peer.

This section includes the following topics:

Configuring Manual Security Associations

Manual SAs require no negotiation; all values, including the keys, are static and specified in the configuration. As a result, each peer must have the same configured options for communication to take place. Manual SAs are best suited for small, static networks where the distribution, maintenance, and tracking of keys are not difficult.

To configure a manual IPsec security association, include the following statements at the [edit services ipsec-vpn rule rule-name term term-name then manual] hierarchy level:

To configure manual SA statements, do the following:

Configuring the Direction for IPsec Processing

The direction statement specifies inbound or outbound IPsec processing. If you want to define different algorithms, keys, or security parameter index (SPI) values for each direction, you configure the inbound and outbound options. If you want the same attributes in both directions, use the bidirectional option.

To configure the direction of IPsec processing, include the direction statement at the [edit services ipsec-vpn rule rule-name term term-name then manual] hierarchy level:

The following two examples illustrate this:

  • Example: Using Different Configuration for the Inbound and Outbound Directions

    Define different algorithms, keys, and security parameter index values for each direction:

  • Example: Using the Same Configuration for the Inbound and Outbound Directions

    Define one set of algorithms, keys, and security parameter index values that is valid in both directions:

Configuring the Protocol for a Manual IPsec SA

IPsec uses two protocols to protect IP traffic: Encapsulating Security Payload (ESP) and authentication header (AH). The AH protocol is used for strong authentication. A third option, bundle, uses AH authentication and ESP encryption; it does not use ESP authentication because AH provides stronger authentication of IP packets.

To configure the IPsec protocol, include the protocol statement and specify the ah, esp, or bundle option at the [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy level:

Configuring the Security Parameter Index

An SPI is an arbitrary value that uniquely identifies which SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt packets.

Note:

Each manual SA must have a unique SPI and protocol combination. Use the auxiliary SPI when you configure the protocol statement to use the bundle option.

To configure the SPI, include the spi statement and specify a value (from 256 through 16,639) at the [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy level:

Configuring the Auxiliary Security Parameter Index

Use the auxiliary SPI when you configure the protocol statement to use the bundle option.

Note:

Each manual SA must have a unique SPI and protocol combination.

To configure the auxiliary SPI, include the auxiliary-spi statement and specify a value (from 256 through 16,639) at the [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy level:

Configuring Authentication for a Manual IPsec SA

To configure an authentication algorithm, include the authentication statement and specify an authentication algorithm and a key at the [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy level:

The algorithm can be one of the following:

  • hmac-md5-96—Hash algorithm that authenticates packet data. It produces a 128-bit authenticator value and a 96-bit digest.

  • hmac-sha1-96—Hash algorithm that authenticates packet data. It produces a 160-bit authenticator value and a 96-bit digest.

  • hmac-sha-256-128—Hash algorithm that authenticates packet data. It produces a 256-bit authenticator value 256-bit digest, truncated to 128 bits.

The key can be one of the following:

  • ascii-text—ASCII text key. With the hmac-md5-96 option, the key contains 16 ASCII characters. With the hmac-sha1-96 option, the key contains 20 ASCII characters.

  • hexadecimal—Hexadecimal key. With the hmac-md5-96 option, the key contains 32 hexadecimal characters. With the hmac-sha1-96 option, the key contains 40 hexadecimal characters.

Configuring Encryption for a Manual IPsec SA

To configure IPsec encryption, include the encryption statement and specify an algorithm and key at the [edit services ipsec-vpn rule rule-name term term-name then manual direction direction] hierarchy level:

The algorithm can be one of the following:

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

  • 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:

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 reference information on AES encryption, see RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec.

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.

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.

    Note:

    You cannot configure encryption when you use the AH protocol.

Configuring Dynamic Security Associations

You configure dynamic SAs with a set of proposals that are negotiated by the security gateways. The keys are generated as part of the negotiation and therefore do not need to be specified in the configuration. The dynamic SA includes one or more proposals, which allow you to prioritize a list of protocols and algorithms to be negotiated with the peer.

To enable a dynamic SA, follow these steps:

  1. Configure Internet Key Exchange (IKE) proposals and IKE policies associated with these proposals.

  2. Configure IPsec proposals and an IPsec policy associated with these proposals.

  3. Associate an SA with an IPsec policy by configuring the dynamic statement.

To configure a dynamic SA, include the dynamic statement and specify an IPsec policy name at the [edit services ipsec-vpn rule rule-name term term-name then] hierarchy level. The ike-policy statement is optional unless you use the preshared key authentication method.

Note:

If you want to establish a dynamic SA, the attributes in at least one configured IPsec and IKE proposal must match those of its peer.

Clearing Security Associations

You can set up the router software to clear IKE or IPsec SAs automatically when the corresponding services PIC restarts or is taken offline. To configure this property, include the clear-ike-sas-on-pic-restart or clear-ipsec-sas-on-pic-restart statement at the [edit services ipsec-vpn] hierarchy level:

After you add this statement to the configuration, all the IKE or IPsec SAs corresponding to the tunnels in the PIC will be cleared when the PIC restarts or goes offline.

Starting in Junos OS Release 17.2R1, you can enable the cleanup of IKE triggers and IKE and IPsec SAs when an IPsec tunnel’s local gateway IP address goes down or the MS-MIC or MS-MPC being used in the tunnel’s service set goes down. This reduces dropped traffic and unnecessary IKE triggers. To enable this feature, include the gw-interface statement at the [edit services service set service-set-name ipsec-vpn-options local-gateway address] hierarchy level. If the local gateway IP address for an IPsec tunnel’s service set goes down or the MS-MIC or MS-MPC that is being used in the service set goes down, the service set no longer sends IKE triggers.

In addition, when the local gateway IP address goes down, the IKE and IPsec SAs are cleared for next-hop service sets, and go to the Not Installed state for interface-style service sets. The SAs that have the Not Installed state are deleted when the local gateway IP address comes back up. If the local gateway IP address that goes down for a next-hop service set is for the responder peer, then you need to clear the IKE and IPsec SAs on the initiator peer so that the IPsec tunnel comes back up once the local gateway IP address comes back up. You can either manually clear the IKE and IPsec SAs on the initiator peer or enable dead peer detection on the initiator peer.

Related Documentation

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.2R1
Starting in Junos OS Release 17.2R1, you can enable the cleanup of IKE triggers and IKE and IPsec SAs when an IPsec tunnel’s local gateway IP address goes down or the MS-MIC or MS-MPC being used in the tunnel’s service set goes down.