 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 Wikipedia 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:
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:
There are several encryption/security related considerations in today’s financial networks. Some of them are:
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 IPSecWhat 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. |
What framework of open standards that provides confidentiality data integrity authentication and anti-replay protection?
Postagens relacionadas
direito autoral © 2024 cemle Inc.
