Introducing IPSec – Network Layer Packet Security
With the explosive growth of the Internet, more and more enterprises are looking towards building their network infrastructure across the Internet without having to spend a lot on private leased lines. However, more and more "evil ways" of breaking into the network to gather sensitive information are also evolving. Thus, security on the Internet has been a main concern for each enterprise. IPSec provides the necessary infrastructure to extend an enterprise's private network across the Internet to reach out to customers and business partners with the help of a "virtual private network (VPN)".
There are three basic flavors of IPSec VPNs, each with an associated set of business requirements (Fig. 1):
Remote-Access VPNs: These let individual users connect to a corporate network. The user's laptop usually contains a VPN client that creates a secure tunnel to the security gateway at the corporate headquarters. Another flavor of this application is offered via creating an L2TP/PPTP session that is protected through IPSec.
Intranet VPNs: This type connects branch offices to the corporate headquarters, thus creating a transparent Intranet.
Extranet VPNs: These let companies connect with their business partners (for example, suppliers, customers, and joint ventures).
Figure 1 - IPsec VPN Applications
IPSec Modes of Operation
IPSec provides two different modes to exchange protected data across the different kinds of VPNs:
1. Transport Mode: This mode is applicable only for host-to-host security. Here protection extends to the payload of IP data. The IP addresses of the hosts must be public IP addresses.
2. Tunnel Mode: This mode is used to provide data security between two networks. It provides protection for the entire IP packet and is sent by adding an outer IP header corresponding to the two tunnel end-points. The unprotected packets generated by hosts travel through the protected "tunnel" created by the gateways on both ends. The outer IP header in Figure 2 corresponds to these gateways. Both intranet and extranet VPNs are enabled through this mode. Since tunnel mode hides the original IP header, it facilitates security of the networks with private IP address space.
Figure 2: IPsec modes of operation—tunnel and transport
Figure 3 describes the overall IPSec architecture:
Figure 3: IPsec architecture
The "Policy Manager" module is the interface between the user adding a security policy and the SPD. The "IKE Daemon" module does the automatic SA negotiation between two IPSec peers. The "Certificate Manager" verifies and enrolls certificates for authentication purposes.
In short, a typical packet flow inside this architecture proceeds as follows:
A packet is received through the receive queue and passed to the IPSec packet processing module.
The IPSec packet processing module extracts the "selector" from the packet and looks up the SPD for a policy. If the policy is "discard", the packet is discarded. If the policy is "pass through", the forwarding engine forwards the packet normally.
If the policy is "IPSec", the SPD entry should point to an SA in SAD. The module then fetches the corresponding SAD entry and checks for validity. If the SA state is expired, the IKE daemon starts another SA negotiation.
The transform depicted in the SA is performed on the packet with the help of the "cryptography" module.
The transformed packet is sent to the "transmit queue" for transmission.
IPSec standards have defined a key negotiation protocol, IKE, and two protocols to exchange data, ESP and AH. ESP is most commonly used.
Encapsulating Security Payload (ESP)
ESP provides data confidentiality, data integrity, and replay protection for the IP payload. It uses a symmetric key algorithm (like 3DES-CBC or AES-CBC) to encrypt the payload and a secure hash algorithm (such as SHA1 or SHA2) that takes an authentication key as input to compute the integrity check value (ICV) over the payload. The ICV is then appended to the packet. The receiver decrypts the payload and re-computes the ICV on the received packet and checks for equality. Any modifications that occurred to the packet payload during transmission can be discovered, as the ICVs will not match. Unlike AH (below), the IP header itself is not protected against data-integrity attacks. Figure 4a illustrates the ESP header.
Authentication Header (AH)
AH provides data integrity and replay protection for the whole IP datagram and is an effective measure against IP-spoofing and session-hijacking attacks. AH, like ESP, uses a secure hash algorithm to compute the ICV over the IP header plus payload. The ICV is included as part of the AH header. The AH protocol specifies a set of mutable IP header fields (TOS, Fragment offset and flags, TTL, Checksum) that should be excluded from the ICV computation. Figure 4b illustrates the AH header.
Figure 4: IPsec (a) ESP format and (b) AH format
Internet Key Exchange (IKE)
IKE defines the mechanism to establish SAs required to secure the packets between the two IPSec peers. The main components of an SA are the transform details (the algorithm and the key) that will be used to protect data. IKE defines an automatic and secure way of negotiating these details between the two peers. The protocol operates in two phases:
Phase I (Authentication Phase)
When two peers over the Internet wish to communicate, it is assumed that no secure channel exists. Therefore, the objective of "phase I" is to establish a secure channel, authenticate the negotiating parties, and generate shared keys to protect IKE protocol messages.
Phase II (Key Exchange)
Phase II, also called as the "Quick Mode," is used to establish the IPSec SA and to generate new keying material.
IPsec Packet Processing
Figure 5 describes IPSec operation on the security device for inbound and outbound packets.
Inbound Packet Processing
Inbound packets are the protected packets that arrive at the security gateway, typically coming from the public network to the private network. These packets have to be decrypted, authenticated, and forwarded to the private network.
Outbound Packet Processing
Outbound packets arrive from the private network and are destined to another private network across the Internet. These packets need to be protected.
Figure 5: IPsec Packet Processing Data Flow (User Space SW implementation)
Engineering A High-Performance Security Gateway
Encryption and authentication are extremely compute-intensive functions. A security gateway that must perform at wire speed with 64-byte packets cannot rely on a software-only implementation. Specialized SoC functions that perform the cryptographic computations, including encryption and authentication, are called crypto accelerators. These devices are necessary to scale to higher throughput rates. There are different types of crypto accelerators available in the market. At this point of time, these crypto accelerators seem to fall into three general categories:
Processors with Basic Algorithm Support
These processors perform basic symmetric-key operations such as 3DES, AES, and others and hash operations such as SHA1, SHA2, and others.
These take in a packet along with an SA and do the complete packet processing (for example, the addition of the ESP or AH header, as required) in addition to supporting the prior functionality.
Inline Security Coprocessors
These processors can handle SA lookup and packet handling, as well as SPD verification.
Introducing Inside Secure’s EIP-197 Packet Engine Family
The PacketEngine-IP-197 (EIP-197) security packet engine is comprised of an in-line streaming interface, a look-aside bus interface, an IPsec classifier, a packet transform engine and an optional post decryption processor.
This packet engine is used as a bus master in the data plane of the system and processes packets with very little CPU intervention. It supports an AXI streaming interface, an AMBA SoC bus interface and can be delivered in different configurations to support multiple performance grades from 5 to 80+ Gbps, achievable even on a single SA (one half of a single tunnel) - or as many SA’s/tunnels as needed (limited only by available memory connected to the SoC).
The EIP-197 is designed for systems requiring security protocol processing at extreme speeds, where CPU (farms) cannot handle the cryptographic workload due to performance or power limitations. The packet engine handles the security (protocol) operations and reduces power in high-end servers, communication and network processors for: network processors used in switch applications; data center processing and cloud computing; communication and high-end security gateways.
The EIP-197 packet engine is highly configurable. Therefore, implementations are available for low power, low cost (area) and low bandwidth applications, using a limited set of algorithms, as well as for extreme high-bandwidth server implementations, capable of handling large system latencies and supporting all common algorithms.
The EIP-197 is silicon proven. Its flexible layered design is fast and easy to integrate into SoC designs, and it supports the complete range of configurations required for an efficient IPsec implementation. It is accompanied by a driver development kit and supported by a world-class technical support team at Inside Secure.
The EIP-197 provides extensive protocol offload support not only for IPsec, but also for DTLS, SRTP, SSL/TLS and MACsec, as well as efficient offloading of a wide range of basic cryptographic operations, including single-pass encrypted authentication and optional support for 3GPP wireless algorithms.
The EIP-197 parses the IPsec-ESP header to look-up a flow, it fetches the flow and corresponding transform record based on the lookup result, updates flow and transform statistics and supports IPv4 and IPv6 architectures.
Complete IPsec transformation (IPv4 and IPv6):
Full IPsec packet ESP transforms according to latest RFCs (2403, 2404, 2405, 2410, 3566, 3602, 3686, 4106, 4301, 4303, 4308, 4309, 4543, 4835, 4868, 4869, 6054, 6071 and 6379)
IPsec ESP tunnel & transport mode
Autonomous IPsec ESP packet classification and security association selection (both inbound and outbound)
Insert ESP header for outbound packets, strip and verify ESP header for inbound packets
Full sequence number processing, including ESN and full anti-replay check with various mask sizes
Calculate and insert integrity check value for outbound packets, strip and verify for inbound packets
Append (outbound) / strip and verify (inbound) padding up to 255 bytes
Leveraging Multi-CPU and Trusted Execution Environment (TEE) Architectures:
The EIP-197 supports multi-core and virtual machine architectures as well as a SA/key separation for TEE environments with Normal and Secure worlds. All required arbitration is fully handled in hardware.
Protocol Processing Software Toolkits
The EIP-197 is provided together with an efficient Driver Development Kit which enables a seamless integration with Inside Secure’s QuickSec SW Stack.
Measuring Security Performance:
When comparing security performance and power consumption between HW and SW architectures, the EIP-197 Packet Engine may save in excess of 90% of the total power consumption required by a pure software solution, in addition to the obvious performance benefit of a hardware solution: