IPsec Concepts

This section provides an overview of IPsec concepts.

IPsec provides security to IP flows through the use of authentication and encryption.

IPsec comprises two encapsulation protocols:

Both protocols are defined with two modes of operation:

Secure IP Interfaces

Secure IP interfaces are virtual IP interfaces that you can configure to provide confidentiality and authentication services for the data flowing through such interfaces. The software provides these services using mechanisms created by the suite of IPsec standards established by the IETF.

Secure IP interfaces connect the router to any other endpoint through the routed network and allow much of the same functionality as other IP interfaces. Traffic can reach a secure IP interface via routing or policy routing.

Secure IP interfaces are a logical representation of a secure connection between two security endpoints, one of which is the local system. The remote endpoint can be another security gateway or a host.

RFC 2401 Compliance

RFC 2401 states that a security policy database (SPD) must exist for each physical interface in the router, and an administrator must configure these SPDs to determine which traffic must be IPsec-protected, not IPsec-protected, or denied. The ERX router does not support a systemwide SPD. Instead, the router takes advantage of routing policies that are applied to physical interfaces to describe which traffic to forward to a single IPsec tunnel, which traffic to discard, and so on. The router also applies IPsec selectors to traffic going into or coming out of a secure tunnel so that unwanted traffic is not allowed inside the tunnel. Supported selectors include IP addresses, subnets, and IP address ranges. An implementation that strictly follows RFC 2401 requires a separate IPsec tunnel for each SPD entry.

IPsec Protocol Stack

Figure 12 shows the protocol stack on a client, an IPsec gateway, and a server. In the figure, HTTP and TCP are examples of higher-level protocols involved in the end-to-end communication; other end-to-end communication protocols are also supported. The layers where the data can be encrypted are shown in gray.

Figure 12: IPsec Tunneling Stack

IPsec Tunneling Stack

Figure 13 shows the packet encapsulation for IPsec tunneling.

Figure 13: IPsec Tunneling Packet Encapsulation

IPsec Tunneling Packet Encapsulation

Security Parameters

Secure IP interfaces allow tunneled traffic to be secured in many ways. For that, secure interfaces are associated with security parameters that are enforced for traffic that goes through these interfaces. Table 17 briefly describes all the parameters used for a secure IP interface.

Table 17: Security Parameters Used on Secure IP Interfaces

Security Parameter


Manual or signaled

A secure IP interface, which can be either manual or signaled.

  • You can configure manual interfaces manually on both local and remote security gateways.
  • Signaled interfaces can dynamically set up connections between security gateways using ISAKMP/IKE.

Operational VR

Operational parameters for the secure IP interface, including the virtual router context to which this interface belongs and the network prefix reachable through the interface.

Transport VR

Transport network characteristics for the tunnel, including its virtual router context and source and destination IP addresses.

Perfect forward secrecy (PFS)

A key-generation approach that guarantees that every newly generated session key is not in any way related to the previous keys. PFS ensures that a compromised session key does not compromise previous and subsequent keys.


A limit on time and traffic volume allowed over the interface before an SA needs to be renegotiated.

Inbound and outbound SAs

The actual session-related parameters used by both security gateways to secure the traffic between them. You can manually define the SA for manual secure IP tunnels or the SA can dynamically negotiate for signaled tunnels.

Two sets of SA parameters exist; one for inbound traffic and another for outbound traffic.

Transform set

The set of security parameters, including protocols and algorithms, that is considered adequate to provide a required security level to the traffic flowing through an interface.

Figure 14 shows the relationships of the various security parameters to the IPsec security interface. The following sections discuss each parameter in detail.

Figure 14: IPsec Security Parameters in Relation to the Secure IP Interface

IPsec Security Parameters in Relation
to the Secure IP Interface

Manual Versus Signaled Interfaces

The router supports both manual and signaled interfaces:

Secure IP interface parameters can be required, optional, or not applicable, depending on whether the interface is manual or signaled. Table 18 presents how the other security parameters fit with manual and signaled interfaces.

Table 18: Security Parameters per IPsec Policy Type

Security Parameter



Operational VR



Transport VR



Perfect forward secrecy






Inbound and outbound SAs


Not applicable

Transform set



Operational Virtual Router

The operational VR for a secure IP tunnel is the VR in which a secure IP tunnel exists.

The IP address and mask associated with a secure IP interface exist only within the operational VR under which the interface is declared. The VR defines the network prefix, which is reachable through the logical IP interface.

A secure IP tunnel is always a member of one and only one operational VR. Therefore, the operational VR attributes are mandatory for any secure tunnel. These attributes include:

Transport Virtual Router

The transport VR for a secure IP tunnel is the VR in which both of the secure tunnel endpoints, the source and destination, are routable addresses. Normally, the transport VR is the default ISP routing infrastructure on top of which VPNs are provisioned.

The IPsec Service module (ISM) is a security gateway and, as such, is one of the endpoints for secure tunnels. The tunnel endpoints are the tunnel source and the tunnel destination IP addresses. For IKE signaled IPsec tunnels, you can use the fully qualified domain name (FQDN) instead of the IP address to identify the tunnel endpoints. You typically use this feature to identify the tunnel destination endpoint in DSL and broadband environments. See Transport VR Definitions with an FQDN in this section.

The transport VR information is required, although its explicit configuration is not. If omitted, the transport VR is assumed to be the same as the operational VR. However, the tunnel source and destination are mandatory elements.

Transport VR Definition

The transport VR definition includes:

Transport VR Definitions with an FQDN

For signaled IPsec tunnels, you can use an FQDN instead of the IP address to specify tunnel endpoints. You typically use this feature to identify the tunnel destination in broadband and DSL environments in which the destination does not have a fixed IP address. The remote device uses the FQDN to establish and authenticate the IPsec connection, and then uses the actual IP address for rekeying and filtering operations.

The ERX router FQDN feature supports both preshared keys and digital certificates. If it uses preshared keys, the router must use IKE aggressive mode to support FQDNs.

An identity string can include an optional user@ specification that precedes the FQDN. The entire string can be a maximum of 80 characters. For example, both of the following are supported:


With preshared key authentication, and when using the user@fqdn format, the router searches for the key based on the entire identity string. If the router cannot find that string, the router strips off the user@ part and performs a second search based on the FQDN part of the string.

With digital certificates, the two sides of the tunnel must use the same identity format, with or without the user@ specification; no stripping operation and no second search occurs.

Note: The E Series router does not support FQDN-to-IP address resolution by DNS.

Perfect Forward Secrecy

PFS is an optional feature that causes every newly refreshed key to be completely unrelated to the previous key. PFS provides added security, but requires extra processing for a new Diffie-Hellmann key exchange on every key refresh.

If PFS is enabled, the router mandates PFS during SA negotiation. The remote security gateway must accept PFS to successfully negotiate the SA. However, if PFS is disabled, PFS might still be negotiated if the remote security gateway requests PFS.

PFS supports three Diffie-Hellmann prime modulus groups:

SA negotiation favors the highest request. For example, if group 2 is requested locally, the remote security gateway must support group 2 for the SA negotiation to be successful. If group 1 is requested locally, either groups 1 or 2 can be accepted, depending on requests from the remote security gateway.


You can set a lifetime for user SAs and IKE SAs. For information about setting the IKE SA lifetime, see Lifetime .

For signaled IPsec interfaces, both the inbound and outbound SA must be assigned a lifetime. The lifetime parameter controls the duration for which the SA is valid. When a user SA is established, both a timer and a traffic volume counter are set. When either counter reaches the limit specified by the SA lifetime, a new SA is negotiated and the expired SA is deleted. The renegotiations refresh several SA parameters, including keys.

Note the following about how the lifetime parameters work:

You can set a lifetime for all SAs on a specific tunnel, and you can set a global lifetime.

Inbound and Outbound SAs

SA parameters are the actual session parameters used to secure a specific data flow associated with a specific secure IP interface. How SA parameters are set depends on how the IP interfaces are secured:

Similarly to IPsec SAs, SA parameters are unidirectional. Therefore, for a two-way data flow, two SAs need to be established—one for inbound traffic and another for outbound traffic. For each direction, SA parameters must be set for each transform associated with a secure IP interface. Therefore, two sets of SA parameters exist for each secure IP interface, one being the inbound SA parameters and the other the outbound SA parameters.

The following parameters form each set of SA parameters:

Transform Sets

Transform sets are composed of security parameters that provide a required security level to a particular data flow. Transform sets are used during user SA negotiation to find common agreement between the local and the remote security gateway on how to protect that specific data flow.

A transform set includes encapsulation protocols and transforms; for example, encryption/decryption/authentication algorithms. These parameters are grouped to specify the acceptable protection for a given data flow. Many transform sets are supported, since different traffic requires distinct security levels.

A secure IP tunnel is associated with one transform set. Multiple secure IP tunnels can refer to the same transform set.

Changing existing transform sets affects only future user SA negotiations. User SAs that are already established remain valid and do not use the changed transform set until they are renegotiated.

For manually configured secure IP tunnels, the associated transform set must contain a single transform option.

Encapsulation Protocols

Both the AH and ESP protocols are supported. See supported transforms in Table 19.

Encapsulation Modes

IPsec supports two encapsulation modes—tunnel mode and transport mode. Tunnel mode creates a second IP header in the packet and uses both the local and remote security gateway addresses as source and destination IP addresses. Also, tunnel mode allows an IP interface to be created and stacked right above it.

Transport mode does not add a second IP header and does not allow an IP interface to be created and stacked right above it. Instead, transport mode allows other tunneling applications, such as an L2TP tunnel, to be created and stacked on top of an IPsec transport mode connection. See Securing L2TP and IP Tunnels with IPsec for a description of L2TP transport mode.

Supported Transforms

Table 19 describes the supported transforms.

Table 19: Supported Transforms




IPsec performs AH protocol encapsulation using the MD5 hash function with HMAC message authentication.


IPsec performs AH protocol encapsulation using the SHA-1 hash function with HMAC message authentication. SHA-1 is considered stronger than MD5.


IPsec performs ESP protocol encapsulation using the MD5 hash function with HMAC message authentication.


IPsec performs ESP protocol encapsulation using the SHA-1 hash function with HMAC message authentication. SHA-1 is considered stronger than MD5.


IPsec performs ESP protocol encapsulation using the DES encryption algorithm. DES uses a 56-bit symmetric key and is considered a weak (breakable) encryption algorithm.


IPsec performs ESP protocol encapsulation using the 3DES encryption algorithm. 3DES uses a 168-bit symmetric encryption key and is widely accepted as a strong encryption algorithm. Export control issues apply to products that ship from the USA with 3DES.


Combination of ESP-MD5 and ESP-DES transforms.


Combination of ESP-SHA and ESP-DES transforms.


Combination of ESP-MD5 and ESP-3DES transforms.


Combination of ESP-SHA and ESP-3DES transforms.

Table 20 lists the security functions achieved with the supported transforms, and provides a view of which combinations can be used, depending on security requirements.

Table 20: Supported Security Transform Combinations

Security Type

Supported Transform Combinations

Data authentication only





Data confidentiality only



Data authentication and confidentiality





The ISM does not support both the ESP and AH encapsulation modes concurrently on the same secure tunnel.

Negotiating Transforms

Inside a transform set, IPsec transforms are numbered in a priority sequence.

Other Security Features

The following sections briefly describe other supported security features for the ERX routers. These features include the following:

This section also provides a pointer to the IPsec system maximums.

IP Security Policies

The ERX router does not support a systemwide SPD. Instead, the router takes advantage of routing to forward traffic to and from a secure tunnel. The router still applies IPsec selectors to traffic going into or coming out of a secure tunnel so that unwanted traffic is not allowed inside the tunnel. Supported selectors include IP addresses, subnets, and IP address ranges.

ESP Processing

The router supports both the encryption and authentication functions of ESP encapsulation as defined in RFC 2406. Specifically, the router supports:

AH Processing

The router supports AH encapsulation as defined in RFC 2402. Specifically, the router supports:

IPsec Maximums Supported

See JunosE Release Notes, Appendix A, System Maximums corresponding to your software release for information about maximum values.

DPD and IPsec Tunnel Failover

Dead peer detection (DPD) is a keepalive mechanism that enables the E Series router to detect when the connection between the router and a remote IPsec peer has been lost. DPD enables the router to reclaim resources and to optionally redirect traffic to an alternate failover destination. If DPD is not enabled, the traffic continues to be sent to the unavailable destination.

When a disconnected state is detected between the E Series router and an IPsec peer, the router:

Unlike other keepalive and heartbeat schemes, which require that peers frequently exchange Hello packets with each other at regular predetermined intervals, DPD uses two techniques to verify connectivity on an as-needed basis. In the first method, the router sends DPD inquiries to the remote peer when traffic has been sent to the peer in the last 30 seconds but no traffic has been received from the peer in the last 60 seconds. In the second method, DPD uses an idle timer. If there has been no traffic between the router and the peer for 2.5 minutes, DPD sends an inquiry to the remote end to verify that the peer is still reachable.

Note: Not all IPsec connections need to verify connectivity between peers. For example, the ERX router does not use DPD to check secure remote access connections based on L2TP over IPsec, which have their own keepalive mechanism. However, the router does reply to a request from a remote peer in this type of connection.

Tunnel Failover

The ERX router provides a failover mechanism for IPsec tunnels that works in concert with both DPD and with IKE SA negotiation. The tunnel failover feature provides an alternate tunnel destination when DPD detects that the current destination is unreachable or when IKE SA set up is unsuccessful. During failover, the IPsec tunnel switches to the alternate destination and establishes IPsec SAs with the new peer. To configure tunnel failover, you specify the tunnel destination backup endpoint.

Tunnel failover is a two-way process. If the router detects that the remote peer is unreachable, it switches to sending traffic to the backup destination. Likewise, if the router is sending traffic to the backup destination when the connection is terminated, the router switches to sending the traffic to the original remote peer.

Note: Even without tunnel failover configured, DPD still provides many benefits, such as indicating that the destination interface is down, ensuring that the router stops sending packets to the unreachable destination, and generating SNMP traps.