Internet Protocol Security (IPSec) is a set of standards applicable to IPv4 and IPv6 networks that provide end-to-end security. It is based on three elements:
Authentication Headers (AH) providing connectionless data integrity and data origin authentication for IP datagrams and provides protection against replay attacks.
Encapsulating Security Payloads (ESP) provides confidentiality, connectionless data integrity, data origin authentication, an anti-replay service (a form of partial sequence integrity), and limited traffic-flow confidentiality.
Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange
These can be used to either protect IP directly or in a ‘tunnelled’ mode. Tunnelled mode is most like the virtual private network widely used by enterprises in the global Internet.
By the year 2000, Virtual Private Network (VPN) network technologies were using IPSec. Multiprotocol Label Switching (MPLS) and Layer Two Tunnelling Protocol (L2TP) were also gaining popularity in the networking world. Researchers interested in these technologies performed some interoperability testing, and there was some deployment by vendors of these technologies. However, these vendors found IPSec interoperability too difficult or even impossible to evaluate operationally because IPSec protocol procedures are complex and ill-defined in the RFC.
Because IPSec traffic is encrypted, uncovering higher protocol behaviour is deliberately obscured making troubleshooting difficult.
Additionally, key management specifications in IPsec have two lifetimes for Security Associations (SAs), as seen in 1998’s RFC 2408. So, maintenance of the SA requires great care in ‘re-key’ timing.
Due to these issues, IPSec had interoperability, performance, debug, and scalability issues, placing significant barriers to deployment in the real world. But it was simplified with the Internet Key Exchange (IKEv2) protocol. IKEv2 has undergone significant standardization work since its inception in 2005 and is now documented in 2014’s RFC 7296, with subsequent work in 2021’s RFC 8983 on controller-based solutions, and merchant silicon implementations.
MPLS-based Layer 3 VPN services started (in Japan) in 1999 and were based on a model defined in RFC 2547. However, this was an informational RFC, so the relevant IETF Working Group started work on ‘2547bis’ draft, with a goal to promote it to the Internet standards track. This led directly to two distinct efforts:
- draft-ietf-l3vpn-ipsec-2547bis — for IPSec ‘l3’ VPN implemented in MPLS
- draft-ietf-l3vpn-ipsec-2547 — which went through five drafts and terminated in 2006
The first draft, draft-ietf-l3vpn-ipsec-2547bis, reached consensus and was published as RFC 4364. There is now a documented MPLS IPSec l3 VPN model that uses BGP to inform routing and MPLS with IPSec to implement the VPN.
The second draft, draft-ietf-l3vpn-ipsec-2547, proposed to use IPSec between Provider Edge (PE) instances as an option to solve the problem of confidentiality of VPN services used with MPLS. It addressed services that can ensure security beyond Layer 2 services such as ATM/HDLC.
There were two strong proposals that aligned with the two lead vendors in this space:
The IETF sought consensus on one standard protocol but failed to reach it and this problem space could not be standardized.
Currently, there is no standard VPN encrypted technology deployed Internet-wide by service providers like this. This is a pity because at enterprise network ‘site’ scale, auto-discovery VPN technology would be useful. It could reduce the scalability requirement and operational cost for a new branch network deployment by multi-site enterprises.
For example, in the past, a bank’s financial network was typically deployed using hardware encryption devices across a carrier-leased service like a T1 line. The telco provider could not see any part of the higher communication, and debugging by either party (bank or carrier) was complex and expensive.
In today’s financial networks, the use of public Internet services and wide-area Ethernet carried over MPLS or other layered services on IP are now recognized as part of the financial infrastructure, and various encryption protocols are in use, such as:
- SSL/TLS protected Internet protocol (across various standards and variants of the protocols)
- IPSec/proprietary ethernet encryption switching devices
There are several encryption/security related considerations in today’s financial networks. Some of them are:
- The performance of IPSec routers
- Multi-vendor interoperability of IPSec routing
- Encryption on Ethernet switches (for a multi-site Ethernet-switched network)
- The encryption method inside cloud data centres (how to provide encryption on high-scale networking and service in the cloud)
- The use of Mac Security IEEE802.1AE (MACSec), defined in 2006 and refined in 2011 and 2013:
- Whole-of-data encryption defined in MACSec and additional Security TAG and ICV (Message Authentication Codes)
- MACSec deployment is increasing for high bandwidth security requirements
Clearly, there are several dimensions to the problem of IP connectivity in enterprise and financial network contexts, where security and privacy is at a premium. Let’s look at the future of IPSec, and encryption technology in this context.
IKEv2, as defined in RFC 7296, would simplify deployment, and has a clear message/protocol sequence. IPSec multi-vendor interoperability would be improved significantly by wide-scale IKEv2 adoption by vendors and providers.
There are now robust and reliable open source IPsec-based VPN implementations such as the StrongSwan system. StrongSwan provides interoperability information and a documented test suite.
Virtual Extensible LAN (VXLAN) is now a common encapsulation protocol, and Ethernet VPN (EVPN) uses the VXLAN control plane across multi-vendor networks. Secure EVPN is a proposal for EVPN/VXLAN as secure VPN technology, explored in the BESS IETF Working Group. It uses a controller (RR) to exchange IPSec SAs without direct IKEv2 peering.
The vast majority of encapsulation for Network Virtualization Overlay (NVO) networks in deployment are based on UDP, and the IPSec Encapsulating Security Payload (ESP) can encrypt these UDP-based packets. Therefore, NVO networks are a good fit for an IPSec deployment.
Looking at the hardware side of things, Broadcom has released and documented, the Jericho2C+ chipset. Jericho is a useful chipset for a storage or Hadoop style network, deployed by a service provider’s routing and switching network because it supports Virtual Output Queuing (VoQ) and deep buffer models. This improves performance and reduces latency across the routing and switching functions. The Jericho2C+ is the latest in the series and uses 7nm semiconductor technology for lower power usage and faster switching speeds. It supports IPSec/MACSec directly, providing IPSec/MACSec at ‘wire rate’ for Ethernet switching, up to 14.4Tbps.
The future of IPSec
What about the future of IPSec? Most of the software systems in deployment worldwide already support IKEv2 forms of IPSec, so we now have good, reliable, testable, and interoperable open-source implementations that have proven interoperability with multiple vendors. Routing software has started to support controller-based Secure EVPN. Merchant silicon supports MACSec/IPSec and MACSec has already been deployed by DCI and some other data centre operators. Controller-based IPSec could be applicable not only for service provider networks, but also enterprise networks for rapid deployment of new satellite locations, using IPSec standardized models of auto-discovery VPN rather than vendor-specific Auto Discovery VPN solutions.
From this evidence, a robust and secure VPN tunnel can now be deployed widely into a multi-vendor network at scale. It can offer high-assurance and high-quality secured communications to the enterprise sector, in a standards-respecting manner.
Shishio Tsuchiya is a Senior Systems Engineer at Arista Networks. He has been a network engineer since 1997.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
While MACSec is a good solution for LAN, its security properties and its functionality are underwhelming for WAN use. State-of-the-art solutions provide confidentiality, integrity and availability for the data plane and the control plane. MACsec doesn’t. MACsec only protects one of the three EtherTypes that enter and live the interface.
There are also alternatives to IPsec for IP encryption, such as WireGuard-based solutions and proprietary/de-facto standards using group key encryption. With WIreGuard there are no interoperability issues as it is cryptographically opinionated.