Using IPsec to protect data | National Cyber Security Centre

Using IPsec to protect data | National Cyber Security Centre
Guidance
Download & print article PDF
Download & print article PDF
Using IPsec to protect data
Guidance for organisations wishing to deploy products that use IPsec.
On this page
About this guidance
Deploying and using IPsec securely
Cryptographic profiles
This guidance provides recommendations for the selection and configuration of equipment that uses IPsec. It also describes how a network encryption service using IPsec should be designed, operated and maintained to provide a level of security appropriate for protecting personal, enterprise and OFFICIAL-tier government information. The recommendations in this guidance address both security and usability.
About this guidance
This guidance is for the protection of data in transit within a single organisation, or within a group of organisations, across bearer networks such as the internet or a commercial WAN circuit. Other scenarios may benefit from some aspects of this guidance, such as the protection of information flows on dedicated links between organisations and cloud service providers, or in the inter-data centre connections in such providers' networks.
This guidance is aimed at system administrators who are responsible for configuration of network cryptographic devices and/or software. It defines two profiles for use with IPsec:
the
Recommended Profile
is based upon modern cryptographic algorithms and protocols
the
Legacy Profile
is to be used by only legacy devices for which transition to platforms supporting IKEv2 has not yet been possible
These profiles were last updated in 2022. There are no changes to the particulars of the profiles in this update to the guidance.
Note
This guidance (and IPsec itself) makes
no
assumptions about the underlying security or resilience of the bearer network. Therefore, any bearer network can be used without affecting the confidentiality or integrity protection provided by the IPsec VPN.
Deploying and using IPsec securely
IPsec helps protect the confidentiality and integrity of your information as it travels across less-trusted networks. Network-based encryption is implemented using the IPsec protocols to establish virtual private networks (VPNs). This can be performed by a software client, by a dedicated hardware appliance (a VPN gateway), or as additional functionality in other networking infrastructure equipment (such as a router).
IPsec VPNs may be dedicated to a single purpose (such as two gateways which connect data centres together). Alternatively, a single gateway may be used by multiple clients as required (for example, for remote working connections).
Device principles
Establishing trustworthy encrypted network links is not just about technology. It is also important that the management of these networks links is carried out by skilled individuals, performing their assigned management activities in a competent and trusted fashion, within a management system that protects the overall integrity of the system.
Devices which implement cryptographic protection of information using IPsec should:
be deployed and managed
by a competent authority in a manner that does not undermine the protection they provide, from a suitable management platform
be configured to provide effective
cryptographic protection
not
be used beyond end of life, and be
disposed of securely
generate and
protect private keys
in an appropriate manner
be patched promptly upon release of updated software or firmware (implementation issues can introduce vulnerabilities that can be exploited if devices are left unpatched)
use
certificates
as a means of identifying and trusting other devices using a suitable PKI, possibly an
in-house PKI
(by exception
Pre-Shared Keys (PSKs)
may be used for authentication where certificates are not supported by both peers)
Additional guidance for the use of VPNs is available in the
NCSC's Device Security Guidance
Pre-Shared Keys (PSKs)
We strongly recommend using certificates for authenticating devices. The NCSC does
not
encourage using PSKs, nor any other approaches for establishing shared authentication keys across multiple devices. However, we recognise that PSKs are widely used in site-to-site VPNs, and in some situations, may be the only available option for authentication. In this case, we recommend that PSKs are:
generated in a cryptographically secure manner, and have at least 128 bits of entropy
unique to a group of devices that need to authenticate each other, and not shared across different groups
handled securely and only by authorised personnel (from the point of creation, through distribution, to eventual destruction) to prevent compromise
changed if you suspect they are compromised
Network design principles
Keeping the network design simple is one of the most effective ways to ensure the network provides the expected security and performance. With this in mind:
Avoid the need for too much security functionality in any single product or network feature, as a failure in one will likely compromise all.
VPN gateways should ideally have three interfaces; a LAN-side interface, a WAN-side interface with IPsec-encrypted data, and a management interface.
The management interface should be connected to a dedicated management LAN (or secure dedicated management WAN with suitable encryption). Traffic on the management interface should be suitably encrypted, with strong authentication, authorisation, and auditing of management activity.
Management functionality of the device should
not
be directly accessible on the WAN interface. We recommend using privileged access workstations for carrying out system management functions; they should follow NCSC’s
PAWs principles
VPN gateways and the traffic they handle should be monitored to identify unexpected traffic patterns which may point to misconfiguration or compromise.
Some network designs may have increased complexity due to features such as:
use of multiple LAN or WAN interfaces
application of traffic routing rules that cause some traffic to pass in-clear depending on traffic characteristics
Care should be taken when increasing the complexity of a network, as adding additional complexity to the network design increases the risk that traffic will be mis-routed, or that devices will be configured incorrectly, allowing an attacker access to them (and the data they protect).
More information on secure network design is available in the
Secure design principles
and
Security architecture anti-patterns
. More information on management networks and management traffic protection can be found within the
Acquiring, managing, and disposing of network devices
guidance.
Cryptographic profiles
As a default policy, VPN gateways and clients should be configured:
to offer and accept only the
Recommended Profile
to
not
allow negotiation of alternative cipher suites (unless explicitly permitted by an administrator)
The
Legacy Profile
is no longer suitable for the protection of information that attracts the OFFICIAL security classification in government and public sector networks. Such information should be protected using the Recommended Profile. It is included here solely to support the development of any remaining plans for transition to the Recommended Profile.
Post-quantum cryptography in IPsec
There is a threat to the cryptography securing IPsec from a cryptographically relevant quantum computer. The primary mitigation to this risk will be to migrate to post-quantum cryptography (PQC).
The standardisation of PQC within IPsec is well underway within the Internet Engineering Taskforce (IETF). We will update this guidance in due course to include IPsec PQC profile(s) when implementations of those final standards are widespread.
Certificate algorithms and key sizes
For most IPsec-based networks, VPN gateways and clients will need to use certificates based on a central trust infrastructure to successfully identify themselves to other VPN devices. Both the Recommended and Legacy Profiles use X.509 certificates to authenticate peers. This is achieved using either the ECDSA or RSA digital signature algorithm.
The parameters for each algorithm, for root CAs, sub-CAs, and end entity devices are:
ECDSA with SHA256 digests on NIST P-256 curve
RSA with 2048-bit modulus and SHA256 digests
For RSA signature algorithms, both RSASSA-PSS and RSASSA-PKCS1-v1_5 are acceptable, with RSASSA-PKCS1-v1_5 being more generally supported (RFC 7427, RFC 8017).
Both ECDSA and RSA, with the above parameters, are expected to provide a suitable level of protection for OFFICIAL information until at least 31
st
December 2027.
The NCSC has guidance on how to
Design and build a privately hosted Public Key Infrastructure
Recommended Profile
For configuring IKE, the Recommended Profile uses the following parameters:
Parameter
Selection
RFCs
IKE Version
IKEv2
RFC7296
Encryption Algorithm
AES with 128-bit key using GCM with 16-octet (128-bit) tags
RFC5282
Pseudo-Random Function
HMAC-SHA-256
RFC4868
Diffie-Hellman Group
256-bit random ECP Group 19 or 2048-bit MODP Group 14
RFC5903, RFC3526
Authentication Method
X.509 certificates using ECDSA or RSA
RFC4945, RFC4754, RFC4055
For configuring Encapsulating Security Payload (ESP), the Recommended Profile uses the following parameters:
Parameter
Selection
RFCs
Encryption Algorithm
AES with 128-bit key using GCM with 16-octet (128-bit) tags
RFC4106
For configuring key lifetimes, the Recommended Profile uses the following lifetimes:
Key Type
Lifetime
IKE SA
86,400 seconds (1 day)
Child SA
28,800 seconds (8 hours)
The Recommended Profile is expected to provide a suitable level of protection for OFFICIAL information until at least 31
st
December 2027.
Legacy Profile
With the development of IKEv2, there have been no updates to IKEv1 for over a decade which means that IKEv1 does not support current cipher suites. Implementations also run the risk of using unmaintained code bases, meaning that any security vulnerabilities are unlikely to be patched. IKEv1 has been formally deprecated by the IETF (RFC 9395) and moved to Historic status, so
the NCSC strongly advises that IKEv1, and this legacy profile, should no longer be used.
A time-bounded migration plan should be put in place for any government systems still using the deprecated IKEv1 to move to IKEv2. Where this is not possible, system owners should approach the NCSC for advice.
The following legacy profile is defined only for use cases where IKEv1 cannot yet be disabled. It consists of an RFC 2409-compliant implementation of IPsec with IKEv1 using 'Main Mode', without custom extensions, using Extended Sequence Numbers (RFC4304), Encapsulating Security Payload (ESP) (RFC4303), and the algorithms given in the tables below.
For configuring IKE, the Legacy Profile uses the following parameters:
Parameter
Selection
RFCs
IKE Version
IKEv1
RFC2409
Mode
Main Mode
RFC2409
Encryption Algorithm
AES with 128-bit key using CBC
RFC3602
Hash Algorithm
SHA2-256
RFC4868
Diffie-Hellman Group
256-bit random ECP Group 19 or 2048-bit MODP Group 14
RFC5903, RFC3526
IKE Authentication Method
X.509 certificates using ECDSA or RSA
RFC4945, RFC4754, RFC4055
Note
The use of Main Mode is mandatory. No other mode is acceptable.
For configuring Encapsulating Security Payload (ESP), the Legacy Profile uses the following parameters:
Parameter
Selection
RFCs
Encryption Algorithm
AES with 128-bit key using CBC
RFC3602
Integrity Algorithm
HMAC-SHA-256-128
RFC4868
Some currently fielded devices are unable to use HMAC-SHA-256-128 for the ESP integrity algorithm. In accordance with wider recommendations on the use of SHA-1, you can continue to use HMAC-SHA-1-96 as the ESP integrity algorithm at this time. SHA-1 must not be used for any other purpose within IPsec.
For configuring key lifetimes, the Legacy Profile uses the following lifetimes:
Key Type
Lifetime
Phase 1
86,400 seconds (1 day)
Phase 2
28,800 seconds (8 hours)
It is acceptable to replace any element of the Legacy Profile with the corresponding element from the Recommended Profile.
You should no longer rely on the Legacy Profile to provide a suitable level of protection for OFFICIAL information.
Security considerations for key exchanges
Some IPsec equipment may re-use ephemeral Diffie-Hellman private keys with multiple IKE SAs. If such equipment can be configured to do so, we recommend that ephemeral Diffie-Hellman private keys are only ever used by a single IKE SA.
Share and print this article
Download & print article PDF
Download & print article PDF
Share
Share on
Share on
Share on
Published
Publish date
23 September 2016
Reviewed
10 December 2025
Version
2.1
Written for
Written for
Small & medium sized organisations
Large organisations
Public sector
Cyber security professionals
Was this article helpful?
Yes
the article was helpful
No
the article was not helpful
Share
Share on
Share on
Share on
Also see
Report
Publish date
19 Apr 2023
The threat from commercial cyber proliferation
Report informing readers about the threat to UK industry and society from commercial cyber tools and services.
Report
Publish date
4 May 2022
Threat report on application stores
This report outlines the risks associated with the use of official and third party app stores.
News
Publish date
28 Jul 2021
UK and allies publish advice to fix global cyber vulnerabilities
A joint advisory from international allies has offered advice for the most publicly known software vulnerabilities.