Current IPsec Recommended Settings

I’ve stumbled upon this IETF RFC and it says to use DH group 14 as best practice right now (in 2017 when the RFC was published) and to avoid a bunch including 2, 5 and some of the 20s.

I can’t see a more recent version of this RFC so I’m wondering if this is still accurate 3.5 years later and where people look to see what the current best practice is?

Read this:

Then, read this:

https://tools.cisco.com/security/center/resources/next_generation_cryptography

safe wrench zephyr reminiscent angle correct impossible fade pie dime

This post was mass deleted and anonymized with Redact

We follow NCSC Guidence on IPsec, Most of ours are using prime settings, but there the odd device that can’t support it thus foundation is there for this purpose.

https://www.ncsc.gov.uk/guidance/using-ipsec-protect-data

Profile Details Foundation 2048-bit RSA and SHA-256 PRIME ECDSA-256 and SHA-256

PRIME profile for IPsec

The recommended IPsec cipher suite profile for protecting information is called PRIME. A non-authoritative summary is provided in the table below:

IKEv2 Selection Encryption AES-128 in GCM-128 (and optionally CBC) Pseudo-random function HMAC-SHA256 Diffie-Hellman Group 256bit random ECP (RFC5903) Group 19 Authentication ECDSA-256 with SHA256 on P-256 curve ESP Selection Encryption AES-128 in GCM-128

Authoritative reference: CESG Technical Specifications No. 403 - PRIME Framework - Suite B.128 Module. Issue 1.2.2 November 2012.

Foundation profile for IPsec

This profile consists of an RFC-compliant implementation of IPsec with IKEv1 (RFC2408 and RFC2409 apply), without custom extensions, using Extended Sequence Numbers (RFC4304), Encapsulating Security Payload (ESP - RFC4303), and the algorithms given in the tables below:

IKEv1 Selection Encryption AES with 128-bit keys in CBC mode (RFC3602) Pseudo-Random Function HMAC-SHA-256 (RFC4868) Diffie-Hellman Group Group 14 (2048-bit MODP Group) (RFC3526) Authentication X.509 certificates with RSA signatures (2048 bits) and SHA-256 (RFC4945 and RFC4055) ESP Selection Encryption AES with 128-bit keys in CBC mode (RFC3602)

In the real world you can’t always use what you would like, very dependant on both sides of the VPN’s hardware and each companies security policy. Usually thrashed out with a bit of back and forth of the VPN requirements spreadsheet. My most recent 3rd party VPN, I requested 14, ended up using 2.

Best: aesgcm256 with group 21
Acceptable: aes256 with group 14
PFS enabled
All settings are ikev2

This is what the government recommends these days for commercial encryption which is usually what I use as a baseline albeit after looking to ensure there are no known issues w/ ciphers or implementations.

"Advanced Encryption Standard with 256 bit keys

Above is from the wikipedia but seems to align to the RFC from a cursory glance.

https://en.wikipedia.org/wiki/Commercial_National_Security_Algorithm_Suite

https://tools.ietf.org/html/rfc8603

This superseded the Suite-b protocols they previously had outlined in the rfc below

https://tools.ietf.org/html/rfc8423

Has anyone seen an ipsec connection getting cracked?

quick take away from https://tools.cisco.com/security/center/resources/next_generation_cryptography

Appendix A: Minimum Cryptography Recommendations

The following table lists recommended cryptographic algorithms that satisfy minimum security requirements for technology as of October 2020.

Table 3. Recommended Minimum Security Algorithms

Operation	Recommended Minimum Security Algorithms
Encryption	AES-128-GCM mode
Authentication	RSA-3072, DSA-3072
Integrity	SHA-256
Key exchange	DH Group 15 (3072-bit)

First Published: April 2012

Last Updated: October 2020

edit: Relevant XKCD

Ahh the well documented “rubber hose” or “phonebook” attack. very effective

In one of my previous roles, I was trying to do the same thing. What was scary is some of the tunnels still used md5 as well.

Same problem though, getting time for me as well as getting someone on the other end of the tunnel to take it seriously was a huge PITA. Really wish people would take this more seriously.

As far as I’m concerned, doing 3des/md5 might as well be using gre tunnels at that point.

How the hell can you have an IPSec tunnel using 3DES in 2021. Some backwater ISP?

Has anyone seen an ipsec connection getting cracked?

I respect the whim of a “ShowerThought” question.

But “I have never personally experienced that phenomenon…” would be a terrible foundation for a data security policy, don’t you think?

Also, consider the sophistication required just to capture the packets to start brute-forcing them.

Odds are fair you’d never know this was happening.

enable aggressive mode

complete fretful afterthought continue pen childlike teeny saw combative icky

This post was mass deleted and anonymized with Redact

Correct, its way easier to send Phishing Mails etc and get access to the network this way.
Also ipsec tunnel most likely will transfer encrypted data anyway :joy:

I prefer passive aggressive mode