IPSec

In This Chapter
This chapter provides information to configure security parameters. Topics in this chapter
include:

• IPSec Overview
• Best Practices Recommendations
• Configuration Notes
• Configuring IPSec with CLI
• IPSec Command Reference

7705 SAR OS Services Guide 1075

IPSec Overview

IPSec Overview
This section contains the following topics:

• IPSec Implementation
• Applications
• NAT-Traversal for IKEv2 and IPSec
• BFD over IPSec Tunnel
• QoS for IPSec
• Fragmentation and IP MTU
• Support for Private VPRN Service Features
• Routing in Private Services
• IPSec on the 10-port 1GigE/1-port 10GigE X-Adapter Card
• IPSec Sequence Number
• PBR and MFC
• Statistics

1076 7705 SAR OS Services Guide

 IPSec

IPSec Implementation
This section contains the following topics:

• IPSec Overview
• Hardware Support
• IPSec Encryption Features
• SHA2 Support
• IPSec Security Policy, IKE Policy, and IPSec Transform
• Tunnel Group
• Tunnel Interfaces and SAPs
• IPSec Tunnel Configuration

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.

7705 SAR OS Services Guide 1077

IPSec Overview

Figure 99: IPSec Implementation Architecture

Private Private
Tunnel Interface
SAP

7705 SAR

Network Access
MDA MDA
VPRN
Encryption SAP Trusted
Engine Network
Private e.g. Enterprise
Public Tunnel SAP Service Intranet
Untrusted Fabric
Network Public Interface
e.g. Internet

IPSec Tunnel
Public
Service

Physical L3 Network Interface or

interface IES SAP Interface

Legend:
Routed via FIB Lookup
Static route

24019

Hardware Support

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

• 7705 SAR-8 with 8-port Gigabit Ethernet Adapter card, version 3

• 7705 SAR-18 with either:
→ 8-port Gigabit Ethernet Adapter card, version 3, or
→ 10-port 1GigE/1-port 10GigE X-Adapter card, version 2
• 7705 SAR-H
• 7705 SAR-Hc
• 7705 SAR-W
• 7705 SAR-Wx

1078 7705 SAR OS Services Guide

 IPSec

IPSec Encryption Features

IPSec provides a variety of encryption features required to establish bidirectional IPSec

tunnels, including:

Control plane:

• manual keying
• dynamic keying: IKEv2
• authentication: pre-shared-key (PSK)
• perfect forward secrecy (PFS)
• dead peer detection (DPD)
• NAT-traversal (NAT-T)
• security policy

Data plane:

• ESP (with authentication) tunnel mode

• IPSec transform (NULL cannot be used for authentication and encryption at the same
time):
→ authentication algorithm: NULL/MD5/SHA1/SHA256/SHA384/SHA512
→ encryption algorithm: NULL/DES/3DES/AES128/AES192/AES256
• IPSec IKE policy (NULL is not supported):
→ authentication algorithm: MD5/SHA1/SHA256/SHA384/SHA512
→ encryption algorithm: DES/3DES/AES128/AES192/AES256
• DH-Group: 1/2/5/14/15

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

7705 SAR OS Services Guide 1079

IPSec Overview

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:

• AUTH_HMAC_SHA2_256_128
• AUTH_HMAC_SHA2_384_192
• AUTH_HMAC_SHA2_512_256

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

• PRF_HMAC_SHA2_256_128
• PRF_HMAC_SHA2_384_192
• PRF_HMAC_SHA2_512_256

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.

1080 7705 SAR OS Services Guide

 IPSec

Tunnel Interfaces and SAPs

There are two types of tunnel interfaces and associated SAPs:

• public tunnel interface: configured in the public IES service; outgoing tunnel packets
have a source IP address (local gateway address) in this subnet
→ public tunnel SAP: associated with the public tunnel interface
• private tunnel interface: configured in the private VPRN service
→ private tunnel SAP: associated with the private tunnel interface, logically linked
to the public tunnel SAP

Public Tunnel SAPs

An IES service (the delivery service) must have at least one IP interface associated with a
public tunnel SAP to receive and process the following types of packets associated with IPSec
tunnels:

• IPSec ESP (IP protocol 50)

• IKEv2 (UDP)

The public tunnel SAP type has the format tunnel-tunnel-group-

id.public:tag, where tunnel-group-id is always 1. See Configuring IPSec and
IPSec Tunnels in Services for a CLI configuration example.

Private Tunnel SAPs

The private (VPRN) service must have an IP interface to an IPSec tunnel in order to forward
IP packets into the tunnel, causing them to be encapsulated according to the tunnel
configuration, and to receive IP packets from the tunnel after the encapsulation has been
removed (and decrypted). That IP interface is associated with a private tunnel SAP.

The private tunnel SAP has the format tunnel-tunnel-group-id.private:tag,

where tunnel-group-id is always 1. The tunnel keyword must be used when creating the
private tunnel interface. See Configuring IPSec and IPSec Tunnels in Services for a CLI
configuration example.

7705 SAR OS Services Guide 1081

IPSec Overview

IP Interface Configuration

The IP MTU of a private tunnel SAP interface can be configured. This sets the maximum
payload IP packet size (including IP header) that can be sent into the tunnel and applies to the
packet size before the tunnel encapsulation is added. When an IPv4 payload packet that needs
to be forwarded to the tunnel is larger than M bytes, one of the following behaviors occurs.

• If the DF bit is clear (not set), the payload packet is fragmented to the MTU size prior
to tunnel encapsulation.
• If the DF bit is set, the payload packet is discarded and (if allowed by the ICMP
setting of the sending interface) an ICMP type 3/code 4 is returned to the sender (with
the MTU of the private tunnel SAP interface in the payload).

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:
security-policy 1
local-gateway-address 80.22.22.2 peer 80.11.11.2 delivery-service 21
dynamic-keying
ike-policy 1
pre-shared-key "alcatel"
transform 1

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.

Applications
Two mobile backhaul applications are described in this section:

• Metrocell Deployment: a solution for providers who are looking for security in the
transmission medium to manage remote private networks in a metrocell deployment.
IPSec is used as an encrypted uplink for OAM and mobile traffic to connect the
remote network to the MTSO. The 7705 SAR-initiated IPSec tunnels can provide a
secure means for managing the 7705 SAR and any private network behind the
7705 SAR, while NAT can provide scalability of IPSec tunnels over a single public
IP address.

1082 7705 SAR OS Services Guide

 IPSec

• Small Business Deployment: the use of LTE and IP NodeBs, as an alternative to

PWs, to provide a better match for an operator’s choice of transport network (that is,
IPSec over public network compared to MPLS/PWs over a private network)

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

Private Domain Public Domain Private Domain

192.168.2.x/24 192.168.1.x/24

Metro Cells with

IPSec & NAT-T 1/1/1 1/1/1
Enabled 68.193.0.1 68.193.0.2

7705 SAR-H with 7750 SAR

IPSec & NAT-T Gw
Enabled
Physical L3
Interface
Switch VPRN IPSec tunnel VPRN

5620 SAM
1/1/1 1/1/1
68.193.0.1 68.193.0.1
24013

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.

7705 SAR OS Services Guide 1083

IPSec Overview

Figure 101: Typical Small Business Deployment

Private Domain Public Domain Private Domain

192.168.2.x/24 192.168.1.x/24

68.193.0.1 68.193.0.2
7705 SAR
Management 7750 SAR
Traffic Physical L3
Laptops Switches Interface
IPSec tunnel VPRN
VPRN

Servers
IPSec tunnel VPRN
1/1/1
68.193.1.1 68.193.0.1

68.193.1.2

24014

NAT-Traversal for IKEv2 and IPSec

The 7705 SAR supports NAT-T (Network Address Translation-Traversal) for IKEv2, as
described in section 2.23 of RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2).
NAT-T is functionality belonging to IPSec and IKEv2. It is not functionality belonging to the
NAT device.

In a private network where the entire network is hidden behind a single public IP address,
NAT-T for IPSec is used to support the fan-out of multiple IPSec tunnels in the private
network.

IPSec is an IP protocol and as such does not use ports. Figure 102 illustrates how the UDP
header is injected into the packet as well as the many-to-one to one-to-many mappings. NAT
relies on port mapping, so in order to allow traversal of a NAT device, NAT-T adds a UDP
header with port 4500 to the IPSec traffic when the NAT device is detected. The UDP header
is added to the IPSec packet above the ESP header and IKEv2 already uses UDP port 500.
This UDP header can be used by the NAT device to uniquely map each IPSec tunnel and
assign a different source port to each individual tunnel. That is, many IP addresses using UDP
4500 lead to a NAT mapping where a single public IP address uses many UDP ports.

1084 7705 SAR OS Services Guide

 IPSec

In Figure 102, the 7750 SR performs the following functions:

• tracks the different metrocell IKEv2 port-to-session mappings

• tracks the different metrocell IPSec port-to-tunnel mappings
• transmits traffic to each metrocell on the appropriate UDP port

Figure 102: UDP Header Injected by a NAT-T-enabled IPSec Tunnel

Private Domain Public Domain Private Domain

192.168.2.x/24 192.168.1.x/24

1/1/1 1/1/1
68.193.0.1 68.193.0.2

7705 SAR
Switch Management 7750 SAR
Management IP Traffic
Physical L3
192.168.2.2/24 Interface
VPRN IPSec tunnel VPRN

5620 SAM

90.0.0.2 90.0.0.2
UDP Header
68.193.0.1 injected by NAT-T 68.193.0.1
UDP UDP
ESP ESP
192.168.1.3 192.168.1.3 192.168.1.3 192.168.1.3
192.168.2.2 192.168.2.2 192.168.2.2 192.168.2.2
Payload Payload Payload Payload
Traffic Flow

500/udp - Internet Key Exchange (IKE)

4500/udp NAT Traversal

IKE Establishment

srcIP 192.168.2.2, UDPsrcPort 500 srcIP 68.193.0.1, UDPsrcPort 5000

dstIP 192.168.2.2, UDPdstPort 500 dstIP 68.193.0.1, UDPdstPort 5000

IPSec with NAT-T Establishment

srcIP 192.168.2.2, UDPsrcPort 4500 srcIP 68.193.0.1, UDPsrcPort 6000

dstIP 192.168.2.2, UDPdstPort 4500 dstIP 68.193.0.1, UDPdstPort 6000
24016

7705 SAR OS Services Guide 1085

IPSec Overview

BFD over IPSec Tunnel

To configure BFD for an IPSec tunnel, do the following:

• configure BFD on a loopback interface in the private VPRN

• configure at least two IPSec tunnels:
→ one tunnel is a BFD-designate tunnel over which BFD packets are exchanged;
this BFD-designate tunnel does not go down when BFD goes down
→ the other tunnels are tunnels that use the BFD-designate tunnel’s BFD session;
these tunnels go down when BFD goes down
• configure a static route in the private VPRN, where the static route points to the
destination node’s private-side loopback interface, using the BFD-designate tunnel
as the next hop
• configure BFD under the BFD-designate tunnel using the loopback interface and
point to the far-end loopback address
• configure BFD under the protected tunnels also using the loopback interface (same
configuration as under the BFD-designate tunnel)

QoS for IPSec

This section contains information on the following topics:

• Network and Access Ingress QoS (Decryption QoS)

• Network and Access Egress QoS (Encryption QoS)

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.

1086 7705 SAR OS Services Guide

 IPSec

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.

7705 SAR OS Services Guide 1087

IPSec Overview

Fragmentation and IP MTU

On the 7705 SAR, unencrypted IP packets arriving on a VPRN access interface and destined
for an IPSec uplink will be fragmented if the incoming packet is larger than:

• the VPRN private interface MTU

• the IPSec tunnel MTU
• the difference between the uplink MTU and the IPSec overhead (uplink interface
MTU minus IPSec overhead), where the IPSec overhead values are calculated as
follows:
→ IPSec overhead if NAT-T is enabled
IPSec overhead = outer IPSec (20) + UDP (8) + ESP (24) + trailer (16) +
ICV (32)
= 100 bytes
→ IPSec overhead if NAT-T is disabled (no nat-t)
IPSec overhead = outer IP (20) + ESP (24) +trailer (16) + ICV (32)
= 92 bytes

For example, if a private tunnel interface has its IP MTU set to 1000 bytes, then a packet
larger than 1000 bytes will be fragmented. As another example, if an uplink interface has its
IP MTU set to 1000 bytes, then a packet that is larger than 1000 – IPSec overhead will be
fragmented. Both these examples assume that the DF bit is not set or the clear-df-bit
command is enabled.

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.

1088 7705 SAR OS Services Guide

 IPSec

Reassembly

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

Support for Private VPRN Service Features

Private VPRN access features are only supported on non-IPSec interfaces. That is, they are
only supported for Layer 3 interfaces that are not configured with a private IPSec tunnel.

Some of these features include r-VPLS, VRRP, ECMP, and LAG. See VPRN Services for
information on these features.

Routing in Private Services

For static LAN-to-LAN tunnels, the static route with the IPSec tunnel as the next-hop could
be exported to a routing protocol by a route policy. The protocol type remains static.

IPSec on the 10-port 1GigE/1-port 10GigE X-Adapter Card

The 10-port 1GigE/1-port 10GigE X-Adapter card has two encryption engines that share the
encryption/decryption load. Therefore, the 10-port 1GigE/1-port 10GigE X-Adapter card has
the potential for double the encryption/decryption throughput when compared with other
adapter cards and nodes with a single encryption engine (the 8-port Gigabit Ethernet Adapter
card, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-W, and 7705 SAR-Wx).

To utilize the potential of the 10-port 1GigE/1-port 10GigE X-Adapter card, the IPSec
security associations (SAs) are load-balanced between the two engines based on a
round-robin algorithm. When there is an SA download to the 10-port 1GigE/1-port 10GigE
X-Adapter card, the upper-layer software load-balances the SA on the two engines.

7705 SAR OS Services Guide 1089

IPSec Overview

IPSec Sequence Number

The IPSec sequence number is used to prevent replay attacks. A replay attack is a network
attack in which valid data transmission is repeated or delayed for fraudulent purposes. The
7705 SAR supports a 32-bit sequence number, where the transmission of each packet
increments the sequence number. If there is a sequence number rollover, the 7705 SAR
performs the rollover by resignaling the phase-2 IKE negotiation.

PBR and MFC

Both PBR (policy-based routing) and MFC (multi-field classification) are part of the ingress
ACL (access control list) configuration on the 7705 SAR. Hence, both PBR and MFC are
supported by IPSec on the 7705 SAR, as discussed below:

• PBR
• MFC

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.

1090 7705 SAR OS Services Guide

 IPSec

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.

Statistics
All statistics for security association and tunnel statistics on the 7705 SAR are retrieved from
the datapath on demand. When the user requests the statistics for a tunnel, the statistics are
retrieved directly from the datapath; the retrieved statistics are not cached on the 7705 SAR.
This means that on redundant platforms (that is, on the 7705 SAR-8 or 7705 SAR-18),
statistics will not synchronize over to the inactive CSM, and at the time of a CSM switchover,
all statistics will be lost. Also, in the case of statistics rollover in the datapath, the newly
retrieved statistics will start from 0 (zero) again.

7705 SAR OS Services Guide 1091

Best Practices Recommendations

Best Practices Recommendations

This section provides best practices recommendations.

IPSec Best Practices

To avoid high CPU loads and some complex cases, the following are suggestions to configure
the IKEv2 lifetime.

• Both the IKE_SA and CHILD_SA lifetime on one side should be approximately 2 or
3 times larger than the other side.
• With the previous rule, the lifetime of the side with the smaller lifetime should NOT
be too small:
→ IKE_SA: greater than or equal to 86 400 s
→ CHILD_SA: greater than or equal to 3600 s
• With the first rule, on the side with the smaller lifetime, the IKE_SA lifetime should
be at least 3 times larger than the CHILD_SA lifetime.

The IKE protocol is the control plane of IPSec; thus, the IKE packet should be treated as high
QoS priority in the end-to-end path of public service.

• On a public interface, a SAP-ingress QoS policy should be configured to ensure that

the IKE packet gets high QoS priority.

1092 7705 SAR OS Services Guide

 IPSec

Configuration Notes
This section describes operational conditions and IPSec configuration caveats.

• A tunnel group that is in use cannot be deleted. Changes are allowed only when the
tunnel group is in a shutdown state.
• A change to the IPSec transform policy is allowed at any time. The change will not
impact tunnels that have been established until they are renegotiated. If the change is
required immediately, the tunnel must be cleared (reset) for force renegotiation.
• A change to the IKE policy is allowed at any time. The change will not impact tunnels
that have been established until they are renegotiated. If the change is required
immediately, the tunnel must be cleared (reset) for force renegotiation.
• An IPSec tunnel must be shut down before the transform policy can be modified.
• The public interface address can be changed at any time (current behavior). If
changed, tunnels that were configured to use it will require a configuration change.
If the subnet has been changed, the tunnels will be in an operationally down state
until their configuration is corrected. The public service cannot be deleted while
tunnels are configured to use it. A public service is the IES service that holds an
interface with a public tunnel SAP that connects the node to the public network. A
private service connects to the private protected service.
• The 7705 SAR supports only one tunnel group (tunnel-group 1).
• A change to the security policy is not allowed while a tunnel is active and using the
policy.
• The tunnel local gateway address, peer address, or delivery router parameters cannot
be changed while the tunnel is operationally up (shutdown makes the tunnel both
administratively down and operationally down).
• A tunnel security policy cannot be changed while the tunnel is operationally up. An
IPSec transform policy or IKE policy assignment to a tunnel requires the tunnel to be
shut down.

Reference Sources
For information on supported IEEE standards, IETF drafts and standards as well as standard
and proprietary MIBs, refer to Standards and Protocol Support.

7705 SAR OS Services Guide 1093

Configuration Notes

1094 7705 SAR OS Services Guide