Manual Ipsec Security Associations; Perfect Forward Secrecy - Cisco IOS XR Configuration Manual

Implementing IPSec Network Security on Cisco IOS XR Software
Assuming that the particular crypto profile entry does not have lifetime values configured, when the
router requests new SAs it specifies its global lifetime values in the request to the peer; it uses this value
as the lifetime of the new SAs. When the router receives a negotiation request from the peer, it uses the
smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the
lifetime of the new SAs.
The SA (and corresponding keys) expire according to whichever comes sooner, either after the number
of seconds has passed (specified by the seconds keyword) or amount of traffic in kilobytes is passed
(specified by the kilobytes keyword).
A new SA is negotiated before the lifetime threshold of the existing SA is reached, to ensure that a new
SA is ready for use when the old one expires. The new SA is negotiated approximately 30 seconds before
the seconds lifetime expires or when the volume of traffic through the tunnel reaches 300 kilobytes less
than the kilobytes lifetime (whichever comes first).
If no traffic has passed through the tunnel during the entire life of the SA, a new SA is not negotiated
when the lifetime expires. Instead, a new SA is negotiated only when IPSec sees another packet that
should be protected.

Manual IPSec Security Associations

The use of manual security associations is a result of a prior arrangement between the users of the local
router and the IPSec peer. The two parties can begin with manual security associations, but must move
to using security associations established through IKE, or the remote party's system cannot support IKE.
If IKE is not used to establish security associations, there is no negotiation of security associations, so
the configuration information in both systems must be the same for traffic to be processed successfully
by IPSec.
The local router can simultaneously support manual and IKE-established security associations, even
within a single crypto profile entry. There is very little reason to disable IKE on the local router (unless
the router supports only manual security associations, which is unlikely).

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) ensures that a given key of an IPSec security association is not derived
from any other secret, such as some other keys. In other words, if someone broke a key, PFS ensures that
the attacker is not able to derive any other key. If PFS is not enabled, someone can hypothetically break
the IKE SA secret key, copy all the IPSec-protected data, and use knowledge of the IKE SA secret to
compromise the IPSec SAs set up by this IKE SA. With PFS, breaking IKE does not give an attacker
immediate access to IPSec. The attacker needs to break each IPSec SA individually.
During negotiation, the set pfs command causes IPSec to request PFS when requesting new security
associations for the crypto profile entry. If the set pfs command statement does not specify a group, the
default (group1) is sent. If the peer initiates the negotiation and the local configuration specifies PFS,
the remote peer must perform a PFS exchange or the negotiation fails. If the local configuration does not
specify a group, a default of group1 is assumed, and an offer of either group1, group2, or group5 is
accepted. If the local configuration specifies group2 or group5, the group must be part of the offer from
the peer or the negotiation fails. If the local configuration does not specify PFS, the configuration accepts
any offer of PFS from the peer.
Information About Implementing IPSec Networks
Cisco IOS XR System Security Configuration Guide
SC-97