IPSec Concepts
This section provides an overview of IPSec concepts.
IPSec provides security to IP flows through the use of authentication and encryption.
- Authentication verifies that data is not altered during transmission and ensures that users are communicating with the individual or organization that they believe they are communicating with.
- Encryption makes data confidential by making it unreadable to everyone except the sender and intended recipient.
IPSec comprises two encapsulation protocols:
- Encapsulating Security Payload (ESP) provides confidentiality and authentication functions to every data packet.
- Authentication header (AH) provides authentication to every data packet.
Both protocols are defined with two modes of operation:
- Tunnel mode completely encapsulates the original packet within another IP header.
- Transport mode keeps the original header and does not add the extra IP header.
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.
- A secure tunnel is a layer 2 entity. It is a point-to-point connection that is mapped on top of other IP interfaces. Secure tunnels carry only IP traffic.
- A secure IP interface is a layer 3 entity; that is, an IP interface mapped on top of a secure tunnel that inherits all security associated with it.
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 13 shows the packet encapsulation for IPSec tunneling.
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 10 briefly describes all the parameters used for a secure IP interface.
Figure 14 shows the relationships of the various security parameters to the IPSec security interface. The following sections discuss each parameter in detail.
Manual Versus Signaled Interfaces
The router supports both manual and signaled interfaces:
- Manual interfaces use a preconfigured set of SA parameters to secure traffic flowing through a secure IP interface. If SA parameters do not use a preconfigured, manual secure interface, the interface drops all traffic it receives. The router keeps statistics for dropped traffic. Both peer security gateways must contain a manually provisioned manual secure IP tunnel.
- Signaled interfaces negotiate an SA on demand with the remote security gateway. The remote security gateway must also support SA negotiation; otherwise the gateway drops traffic. Again, the router keeps statistics for dropped traffic.
The router supports SA negotiation within an IKE SA by means of the ISAKMP and IKE protocols. Only one IKE SA is maintained between a set of local and remote IKE endpoints. That means that if an IKE SA already exists between the two endpoints, it is reused.
Secure IP interface parameters can be required, optional, or not applicable, depending on whether the interface is manual or signaled. Table 11 presents how the other security parameters fit with manual and signaled interfaces.
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 tunnel source IP address must be one of the local IP addresses configured on the router.
- The tunnel destination address must be a routable IP address within the transport VR routing tables.
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 virtual router name—Name of the transport virtual router. If not explicitly configured, the operational VR is assumed.
- Tunnel source endpoint—IP address or FQDN used as the tunnel source endpoint on this end of the tunnel. In the case of signaled tunnels, the router monitors and transmits on port 500 of this address for IKE negotiations. The tunnel source endpoint must be a configured IP address or FQDN on the transport VR, or the router indicates an error. See Transport VR Definitions with an FQDN for information about using an FQDN rather than an IP address.
- Tunnel destination endpoint—IP address or FQDN associated with the termination or initiation point of the secure IP tunnel. This address must be routable within the context of the transport VR. Each secure IP tunnel can have a different remote IP address.
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:
branch245.customer77.isp.net
user4919@branch245.customer77.isp.net
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:
- Group 1—A 768-bit Diffie-Hellmann prime modulus group
- Group 2—A 1024-bit Diffie-Hellmann prime modulus group
- Group 5—A 1536-bit Diffie-Hellmann prime modulus group
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.
Lifetime
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:
- To avoid delays in the data flow, a new user SA is actually renegotiated before the expiration. If the SA expires in the middle of processing a packet, the router finishes processing that packet.
- The actual user SA lifetime may not equal the value configured in the router.
- There are both global and tunnel-specific lifetime parameters. If there is no tunnel-specific lifetime configured, the router uses the global lifetime. The global lifetime parameters have the following default settings:
- Lifetime parameters are valid only for user SAs established via IKE. Manually configured user SAs ignore this parameter.
You can set a lifetime for all SAs on a specific tunnel, and you can set a global lifetime.
- To set the tunnel lifetime, use the tunnel lifetime command.
- To set the global (default) lifetime, use the ipsec lifetime command.
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:
- For manual secure IP interfaces, the system administrator sets SA parameters. Manually setting SA parameters allows provisioning of IP security to destinations that do not support SA negotiation via IKE.
- For signaled secure IP interfaces, the two security gateway peers negotiate SA parameters; the system administrator is not allowed to set any of the parameters. In fact, for some of these parameters, such as session keys, the system administrator is not even granted read access.
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:
- SPI—The SPI is a unique identifier that is applied to the SA when securing a flow. An SPI is unique for a given destination IP address and protocol tuple. The destination IP address is either the remote secure IP interface endpoint for the outbound direction or the local secure IP interface endpoint for the inbound direction.
- Encapsulation—The encapsulation options include both an encapsulating protocol and an encapsulating mode. The protocol can be either ESP or AH. The mode is tunnel mode.
- Transforms—The allowed transforms for given SA parameters depend on the encapsulation protocol. See Transform Sets for more information.
- Keys—The session key is used for the respective SA transform. The key length depends on the SA transform to which it applies, and is as follows:
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 12.
- AH provides authentication.
- ESP provides data confidentiality and antireplay functions. ESP can also provide data authentication; although, in this implementation, ESP does not cover the outer IP header.
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 Chapter 13, Securing L2TP and IP Tunnels with IPSec for a description of L2TP transport mode.
Supported Transforms
Table 12 describes the supported transforms.
Table 13 lists the security functions achieved with the supported transforms, and provides a view of which combinations can be used, depending on security requirements.
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.
- During negotiation as an initiator of the user SA, the router uses transform number one first. If the remote system does not agree on the transform, the router then tries number two, and so on. If both end systems do not agree on a transform, the user SA fails and the secure IP tunnel is not established.
- During negotiation as a responder, the router compares the proposed transform from the remote end against each transform in the transform set. If there is no match, the router provides a negative answer to the remote end, which can either try another transform or give up. If no match is found, the secure IP tunnel is not established.
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:
- DES and 3DES encryption algorithms
- The HMAC-SHA and HMAC-MD5 authentication algorithms
- ESP security options on a per-tunnel (per-SA) basis
- Tunnel mode
AH Processing
The router supports AH encapsulation as defined in RFC 2402. Specifically, the router supports:
- HMAC-SHA and HMAC-MD5 authentication algorithms
- AH authentication options on a per-tunnel (per-SA) basis
- Tunnel mode
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:
- Tears down the IPSec connection and displays the interface's state as down in output for the show ipsec tunnel detail command
- Clears all SAs that were established between the two endpoints
- Stops forwarding packets to the unavailable destination
- Generates SNMP traps
- Allows routing protocols running on the IP interfaces on top of the failed IPSec tunnel to switch to alternate paths
- (Optional) Redirects traffic to an alternate tunnel destination
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.
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.