Cisco UK & Ireland Blog / Security / Deep dive: A VPN journey …

** Note from the editor, a small disclaimer! This blog is wee bit technical… **

IPsec VPN

Internet Protocol Security (IPsec) VPNs are widely used to protect traffic over insecure networks. One example could be enabling secure connectivity from an on-premises location to the cloud. Data is sent through the IPsec VPN, with the VPN providing confidentiality and integrity protection.

In the case of technologies such as Dynamic Multipoint VPN (DMVPN) and FlexVPN, simple configurations can be deployed on Cisco routers, which dynamically create VPN tunnels as and when required. This flexibility removes the need to create many static point-to-point tunnels between all VPN devices, allowing solutions to efficiently scale.

Making the magic happen

In fact, IPsec VPNs aren’t created by magic. The Internet Key Exchange version 2 (IKEv2) is a protocol used to securely authenticate peers and setup the IPsec VPN. In other words, it sets up a security association. IKEv2 is an open standard protocol used by almost all networking vendors; for the more technically savvy among our readership, IKE is the control-plane.

The IKEv2 exchange process

When an IKEv2 device begins the IKEv2 exchange it sends a list of types and cryptographic algorithms to the peer, this list is called the proposal. The peer must select one cipher for each type:

• Encryption,
• Integrity,
• PRF

Protecting the exchange

Meanwhile, Diffie-Hellman (DH) is an algorithm used by IKE to negotiate a shared secret between parties, which is then used to protect the IKEv2 and IPsec exchanges. The whole security of the IKEv2 exchange relies on DH, so if someone can break DH, they can break IKE and the subsequent IPsec data plane traffic.

Cisco introduced the IKEv2 protocol into routers in 2011. Back in the heady days of 2011, the cryptographic strength of the default ciphers used by IKEv2 on Cisco IOS were deemed good enough for the majority of applications.

The following figure illustrates the legacy IKEv2 proposal, with the preferred ciphers being listed higher to lower:

Fast forward to 2018

Today of course, the use of ciphers such as MD5 and SHA-1 is no longer recommended. Click here for more information.

It’s no longer acceptable to include these ciphers in Cisco technologies and as such, starting in IOS-XE 16.8.1 we have removed any insecure ciphers from the default IKEv2 proposal as part of CSCuy44786.

The new proposal looks like this:

We have dropped any of the non-quantum resistant encryption, integrity and PRF ciphers and removed DH Group2 from the default IKEv2 proposal due to security concerns and instead made the preferred group, Group19. Group19 is a lightweight elliptic curve group, being both efficient and secure.

Note: DH is not considered quantum safe, but at the time of writing there is not a standardised quantum resistant IKEv2 exchange, although we’ve been active in creating the following draft RFCs.

https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2-01

https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-02

The following diagram (courtesy of TAC legend, Nitin Dhingra), illustrates the time taken to establish IKEv2 SA’s on a ISR 4351 using the new proposal. It’s apparent that Group19 is the most lightweight. For large-scale mesh networks using DMVPN or FlexVPN, or for large remote access networks convergence time can be critical.

Why does this matter?

I have the pleasure of seeing hundreds of customer VPNs, many of which use the built-in default IKEv2 proposal. As we have made changes to the default proposal, deployments using the default proposal will seamlessly now negotiate stronger cryptographic ciphers. Group19 will be negotiated. For backwards compatibility Group5 is included, but less preferred, so will only be used if it is the lowest common denominator.

It was a common occurrence for customers who had their VPN architecture penetration tested, to receive concerns regarding the security of  MD5 or SHA-1 ciphers. With the new default proposal, this will no longer be the case.

One reason we choose Group19 is that it’s in the Suite-B and NCSC list of ciphers. We also have included Group14 and Group21, which are both deemed acceptable today.

• Suite-b https://tools.ietf.org/html/rfc6379
• NCSC https://www.ncsc.gov.uk/guidance/using-ipsec-protect-data

What’s next?

Now we have updated the IKEv2 proposal, we will update the ciphers used for the IPsec dataplane. In the meantime, if you are lucky enough to be attending CiscoLive in Florida next month, we encourage you to attend the following sessions;

• Advanced IKEv2 Protocol [BRKSEC-3001]
• Cryptographic Protocols and Algorithms – a review [BRKSEC-3005]
• Designing Remote-Access and Site-to-Site IPSec networks with FlexVPN [BRKSEC-2881]
• IOS FlexVPN Remote Access, IoT and Site-to-Site advanced Crypto VPN Designs [BRKSEC-3054]

A number of us within Cisco’s VPN core team have been working on making this functionality available for some time now,  something which would not have been possible without other members of the VPN core team; Amjad, Fred, Nitin, Olivier, Piotr, Sarat, Srinivasu, Tapesh, Wen and many others.

Find out more about our security solutions at cisco.co.uk/security

Authors

Graham Bartlett

Senior Technical Leader

UKI