IPSec Overview

IPSec is a structure of open standards to ensure private, secure communications over Internet Protocol (IP) networks by using cryptographic security services.

For IPSec, the 7705 SAR supports VPRN for the private side of the tunnel and IES for the public side of the tunnel. A public service instance (IES) connects to the public network and a private service instance (VPRN) connects to the private network, which originates the traffic that is to be encrypted (see Figure 99).

In Figure 99, all ingress customer traffic from the trusted network is aggregated into the private VPRN service, where a VPRN static route directs the traffic into the encryption engine. The encryption engine encrypts the customer traffic using configurable encryption and authentication protocols, and adds the IPSec tunnel outer IP header. The source IP address of the outer IP header is the local security gateway address, and the destination IP address is the peer security gateway address.

The encrypted IPSec packet exits the node via an IES or router interface that is configured on an encryption-capable adapter card; it gets routed to its destination via a standard FIB lookup.

On ingress from an untrusted network, all arriving IPSec traffic is routed to the appropriate security gateway as configured on the VPRN service. The incoming IPSec traffic is processed and checked against the tunnel security configuration.

If the traffic passes all security checks, it is decrypted and the customer traffic is routed through the associated VPRN. Any traffic that does not match the tunnel security configuration is dropped.

Figure 99:  IPSec Implementation Architecture 

Hardware Support

The 7705 SAR supports IPSec on the following nodes and adapter cards:

IPSec Encryption Features

IPSec provides a variety of encryption features required to establish bidirectional IPSec tunnels, including:

Control plane:

Data plane:

Note: The 7705 SAR uses a configured authentication algorithm in an IKE policy for the pseudorandom function (PRF).

SHA2 Support

The 7705 SAR supports RFC 4868. For data origin authentication and integrity verification functions in the IKEv2 and Encapsulating Security Payload (ESP) protocols, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

For pseudorandom functions (PRF) with IKEv2, the 7705 SAR supports the following HMAC-SHA-256+ algorithms:

IPSec Security Policy, IKE Policy, and IPSec Transform

An IPSec security policy defines the type of traffic allowed to pass in or out of an IPSec tunnel. The policy does this through the configuration of local and remote IP address pairs. The behavior of an IPSec security policy is similar to IP filtering. IPSec security policies are created for a VPRN service context and applied to an IPSec tunnel in that service.

An IKE policy defines how the 7705 SAR encrypts and authenticates an IPSec tunnel that uses that policy. Its configuration includes specifics on Diffie-Hellman key derivation algorithms, encryption and authentication protocols to be used for establishing phase 1 and phase 2 security associations, and so on.

An IPSec transform defines the algorithms used for IPSec SA. The transform configuration dictates the algorithms that customer traffic uses for encryption and authentication.

Tunnel Group

A tunnel group is a collection of IPSec tunnels. The 7705 SAR supports one tunnel group that always uses tunnel ID 1.

An IPSec tunnel belongs to only one tunnel group. The show>isa>tunnel-group command allows the operator to view information about the configured tunnel group.

Tunnel Interfaces and SAPs

There are two types of tunnel interfaces and associated SAPs:

IPSec Tunnel Configuration

To bind an IPSec tunnel to a private tunnel SAP, the ipsec-tunnel command is configured under the SAP context, where the ipsec-tunnel context provides access to the following parameters:

The local gateway address must belong to the same subnet as the delivery-service (IES) public tunnel interface address. The local gateway address and peer gateway address are the source and destination addresses for the outgoing IPSec traffic.

A private tunnel SAP can have only one IPSec tunnel.

Metrocell Deployment

As shown in Figure 100, in a typical metrocell deployment, the cell site network is divided into two separate segments: the private domain and the public domain. An IPSec tunnel generated from the 7705 SAR-H is used to backhaul the management and OAM traffic of the private network, including the management traffic of the switches and the 7705 SAR-H itself. All OAM traffic is aggregated within a VPRN service and uses the IPSec tunnel as the uplink tunnel to the 7750 SR gateway.

Figure 100:  Typical Metrocell Deployment 

Small Business Deployment

In a small business deployment, the network is usually designed with a hub and spoke topology. The spoke sites connect to the hub through a leased line or a public non-secure domain. IPSec provides the security and encryption needed to connect the spoke sites to the centralized office (hub). The hub and spoke topology in a small business deployment is favorable because of the security that the hub side can provide to the entire network. IPS/IDS and anti-virus appliances can be deployed to the hub site, which examines arriving traffic from the spoke sites. SPAM and viruses can be filtered out on the hub site by these appliances. If additional spoke-to-spoke connectivity is required, then additional IPSec tunnels can be established. See Figure 101.

Figure 101:  Typical Small Business Deployment 

Network and Access Ingress QoS (Decryption QoS)

IPSec traffic arriving on network ingress is classified based on network policy and network queue policy when the uplink interface is a network interface (refer to the 7705 SAR OS Quality of Service Guide). This classification is done based on the DSCP marking of the IPSec outer IP header.

The IPSec (encrypted) traffic destined for the secure gateway (SeGW) of the 7705 SAR is mapped to two queues (expedited and best effort) of the decryption engine on the ingress adapter card. This means that encrypted traffic is mapped to the decryption queue.

The encrypted traffic is mapped to one of these two queues based on the queue-type of its mapped network ingress queue, as determined by the result of the network ingress classification. For example, at network ingress, the QoS network policy determines a forwarding class (FC) for the packet. Then, the network-ingress queue policy maps the FC to a queue. The configured queue-type of network-ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card (where the uplink interface resides).

The uplink interface for the SeGW can be configured as a network interface or as an access IES interface. For an access IES interface, the decryption-queue mapping is based on the queue-type of the access ingress queue of the IES interface SAP. For example, at IES ingress, the SAP ingress policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of this SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the ingress adapter card where the IES interface SAP resides.

The decrypted customer traffic with removed IPSec tunnel header is queued on network and access ingress queues (the uplink interface can be a network interface or an IES interface) based on the network and access ingress policy, and the DSCP bits of the IPSec outer IP header are used for the classification.

Network and Access Egress QoS (Encryption QoS)

Customer packets arriving on access ingress in the VPRN are classified based on the SAP ingress policy (refer to the 7705 SAR OS Quality of Service Guide).

Customer packets arriving in the VPRN that are destined for the IPSec tunnel are enqueued before the encryption engine on the egress adapter card. There are three queues servicing the encryption engine on the egress adapter card (expedited, best effort, and CTL).

All CSM traffic over IPSec (BFD, ping, and so on) is queued in the CTL queue, while data (customer) traffic is mapped to the expedited or best-effort queue.

The customer traffic to the two data queues is mapped based on the queue-type of the ingress SAP queue. For example, at access VPRN SAP ingress, the ingress SAP policy determines a forwarding class (FC) for the packet. The FC is mapped to a SAP ingress queue. The queue-type of the SAP ingress queue (expedited, best-effort, or auto-expedite) is used to choose the queue for the decryption engine on the egress adapter card (where the uplink interface resides).

Note: If DSCP egress re-marking is configured on the network interface or access interface (uplink interface), DSCP bits are re-marked on the IPSec outer IP header.

Fragmentation Configuration

By default, the 7705 SAR sets the DF bit on the IPSec tunnel IP header.

There are some configurations where the customer IP header DF bit needs to be copied into the IPSec tunnel IP header. The copy-df-bit command under the config>service>vprn>if>sap>ipsec-tunnel context enables copying the customer clear text IP header DF bit into IPSec tunnel IP header.

The clear-df-bit command , also under the ipsec-tunnel context, clears the customer clear text IP header DF bit (if it is set). This allows the customer packet to be fragmented into the IPSec tunnel even if the customer packet has the DF bit set. However, the fragmented customer clear text packet is not be reassembled at the far end of IPSec tunnel.

Reassembly

The 7705 SAR does not support reassembly of fragmented IPSec packets.

PBR

PBR configuration can be applied in two places for an IPSec service.

The first place is for VPRN and applies to all incoming access traffic into a private VPRN. In this case, PBR can be used to direct the customer traffic into uplink IPSec tunnels by means of ACL matching criteria. The filtering action of forwarding to an indirect next hop can be used to direct customer traffic into the appropriate IPSec tunnel. Note that the security policy works only on the original (customer packet) IP header; that is, the PBR next hop is not used in making the security policy decision.

The second place is for IPSec traffic entering the 7705 SAR from the public domain. A PBR filter can be placed on the network interface or the IES interface to direct the IPSec packet based on the matching/forwarding criteria. In this case, IPSec packets are processed by the PBR filter in the same way as any other IP packet.

For more information on PBR, refer to the “Policy-Based Routing” section in the 7705 SAR OS Router Configuration Guide.

Note: All routing decisions are made based on the PBR configuration; therefore, it is possible that even if the packet is destined for the local node security gateway (SeGW), the PBR filter might redirect the packet to another interface. Alternatively, for IPSec packets that are not destined for the local node SeGW, PBR can force the packets into the local node SeGW. In this case, the encapsulating security payload (ESP) index of the IPSec packet will not match the SeGW ESP configuration and the packet will be dropped. Thus, it is the responsibility of the network administrator to ensure that the PBR configuration is correct and meets the network needs.

MFC

Multi-field classification (MFC) is supported on the private IPSec service (VPRN). MFC functions in the same manner as the VPRN configuration of traditional services.

For more information on MFC, refer to the “Multi-field Classification” section in the 7705 SAR OS Router Configuration Guide.