Build an IPsec profile before negotiating each tunnel by exception

An IPsec tunnel that comes up once is not yet an operational standard. The harder failures often arrive at rekey, certificate rollover, peer failover, path-MTU change, or an emergency rebuild when undocumented exceptions must be rediscovered.

Source fact:

NIST Special Publication 800-77 Revision 1 provides guidance on IPsec virtual private networks. It describes the IPsec framework and Internet Key Exchange, the security services they can provide, and practical considerations for implementing IPsec-based VPNs. The publication also discusses alternatives and the need to select designs and controls that match an organization’s environment and risk.

IPsec can protect network-layer traffic between configured endpoints through authentication, integrity, and confidentiality services selected by policy. IKE establishes and manages the security associations used by the tunnel. The publication is guidance rather than a statement that any named algorithm, product default, or configuration remains appropriate indefinitely.

Boundary

A secure cryptographic profile does not make either endpoint, routing table, or application trustworthy. Interoperability depends on exact platform support and identity configuration. NAT, fragmentation, MTU, asymmetric routing, overlapping addresses, policy selectors, certificate revocation access, and high-availability behavior can affect service without appearing as a basic IKE failure. Requirements imposed by contracts or regulated environments need separate review.

Applicability questions

• Which tunnel types and peer classes need distinct profiles, such as managed branch, partner, cloud, or remote access?
• How are peers authenticated, and how are keys or certificates issued, stored, rotated, and revoked?
• Which cryptographic choices are supported on both sides and approved under current organizational policy?
• What traffic selectors, routes, MTU handling, logging, and high-availability dependencies apply?
• Who owns partner coordination during rekey or an incident?

DSE recommendation:

Create a small set of versioned profiles covering IKE version, authentication, approved algorithm suites, lifetimes, rekey behavior, identity matching, dead-peer detection, logging, and traffic selectors. Validate each profile against current organizational cryptographic policy and the exact products involved. Record every deviation with a business owner, technical rationale, risk decision, and expiration or migration date.

Test initial establishment and steady traffic, then force child and IKE rekeys, peer restart, certificate renewal, path failover, packet loss, MTU constraints, and restoration from backed-up configuration. Confirm the monitoring differentiates negotiation, authentication, selector, and routing failures. Protect secrets and private keys from ordinary configuration exports, and document an emergency rebuild that does not rely on the failed tunnel.

Verification and evidence

Keep the approved profile, platform matrix, sanitized configurations, identity and certificate lifecycle records, exception register, negotiated-parameter output, traffic tests, and failure/recovery timestamps. Evidence should show that both directions carry only intended networks and that rekey does not create an unacceptable interruption. Periodically compare deployed tunnels with the standard and review exceptions before renewals or platform upgrades.

Official references

• NIST SP 800-77 Rev. 1