Internet Protocol Security (Ipsec) Guide

INTERNET PROTOCOL SECURITY (IPSEC) GUIDE

www.insidesecure.com 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)».

| 02 VPN APPLICATIONS IPSEC MODES OF OPERATION There are three basic flavors of IPSec VPNs, each with an IPSec provides two different modes to exchange protected associated set of business requirements (Figure 1): data across the different kinds of VPNs:

• Remote-Access VPNs: These let individual users connect to 1. Transport Mode: This mode is applicable only for host-to-host a corporate network. The user’s laptop usually contains a VPN security. Here protection extends to the payload of IP data. client that creates a secure tunnel to the security gateway at The IP addresses of the hosts must be public IP addresses. the corporate headquarters. Another flavor of this application is offered via creating an L2TP/PPTP session that is protected 2. Tunnel Mode: This mode is used to provide data security through IPSec. between two networks. It provides protection for the entire IP packet and is sent by adding an outer IP header corresponding to • Intranet VPNs: This type connects branch offices to the the two tunnel endpoints. The unprotected packets generated corporate headquarters, thus creating a transparent Intranet. by hosts travel through the protected «tunnel» created by the gateways on both ends. The outer IP header in Figure 2 • Extranet VPNs: These let companies connect with their corresponds to these gateways. Both intranet and extranet business partners (for example, suppliers, customers, and joint VPNs are enabled through this mode. Since tunnel mode hides ventures). the original IP header, it facilitates security of the networks with private IP address space.

IP HDR Data

TRANSPORT MODE

ESP ESP IP HDR ESP HDR Data Trailer Auth

Encrypted Authenticated

TUNNEL MODE

ESP ESP NEW IP HDR ESP HDR IP HDR Data Trailer Auth

Encrypted Authenticated

Figure 1 - IPSec VPN Applications Figure 2 - IPSec modes of operation—tunnel and transport

03 | IPSEC ARCHITECTURE Figure 3 describes the overall IPSec architecture: «pass through», the forwarding engine forwards the packet normally. The «Policy Manager» module is the interface between the user adding a security policy and the SPD. The «IKE Daemon» module • If the policy is «IPSec», the SPD entry should point to an SA does the automatic SA negotiation between two IPSec peers. in SAD. The module then fetches the corresponding SAD The «Certificate Manager» verifies and enrolls certificates for entry and checks for validity. If the SA state is expired, the authentication purposes. In short, a typical packet flow inside IKE daemon starts another SA negotiation. this architecture proceeds as follows: • The transform depicted in the SA is performed on the packet • A packet is received through the receive queue and passed with the help of the «cryptography» module. to the IPSec packet processing module. • The transformed packet is sent to the «transmit queue» for • The IPSec packet processing module extracts the «selector» transmission. from the packet and looks up the SPD for a policy. If the policy is «discard», the packet is discarded. If the policy is

Policy Certificate IKE Daemon Manager Manager

SPD SAD

Receive Transmit Queue Queue IPSecPacketProcessingModule Incoming Outgoing Packet Packet

CryptographyModule

Figure 3 - IPSec architecture

| 04 IPSEC PROTOCOLS IPSec standards have defined a key negotiation protocol, IKE, and two protocols to exchange data, ESP and AH. ESP is most Original IP Ext commonly used. Packet Header Hdrs TCP Data

Encapsulating Security Payload (ESP) TRANSPORT MODE ESP provides data confidentiality, data integrity, and replay IP Ext ESP ESP protection for the IP payload. It uses a symmetric key algorithm Header Hdrs ESP Header TCP Data Trailer Auth (like 3DES-CBC or AES-CBC) to encrypt the payload and a Encrypted secure hash algorithm (such as SHA1 or SHA2) that takes an Authenticated authentication key as input to compute the integrity check value (ICV) over the payload. The ICV is then appended to the TUNNEL MODE New IP Ext IP Ext ESP ESP packet. The receiver decrypts the payload and re-computes Header Hdrs ESP Header Header Hdrs TCP Data Trailer Auth the ICV on the received packet and checks for equality. Encrypted Authenticated 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. Figure 4a - IPSec ESP Transport and Tunnel formats

05 | Authentication Header (AH) Internet Key Exchange (IKE) AH provides data integrity and replay protection for the whole IKE defines the mechanism to establish SAs required to IP datagram and is an effective measure against IP-spoofing secure the packets between the two IPSec peers. The main and session-hijacking attacks. AH, like ESP, uses a secure hash components of an SA are the transform details (the algorithm algorithm to compute the ICV over the IP header plus payload. and the key) that will be used to protect data. IKE defines an The ICV is included as part of the AH header. The AH protocol automatic and secure way of negotiating these details between specifies a set of mutable IP header fields (TOS, Fragment the two peers. The protocol operates in two phases: offset and flags, TTL, Checksum) that should be excluded from the ICV computation. Figure 4b illustrates the AH header. 1. 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 Original IP Ext Packet Header Hdrs TCP Data protocol messages.

TRANSPORT MODE 2. Phase II (Key Exchange) Phase II, also called as the «Quick Mode,» is used to establish IP Ext Authent. Header Hdrs Header TCP Data the IPSec SA and to generate new keying material.

Authenticated (except for mutable fields)

TUNNEL MODE

New IP Ext Authent. IP Ext Header Hdrs Header Header Hdrs TCP Data

Authenticated (except for mutable fields in new IP Header)

Figure 4b - IPSec AH Transport and Tunnel formats

| 06 IPSEC PACKET PROCESSING Outbound Packet Processing Figure 5 describes IPSec operation on the security device for Outbound packets arrive from the private network and are inbound and outbound packets. destined to another private network across the Internet. These packets need to be protected.

Inbound Packet Processing Engineering A High-Performance Security Gateway Inbound packets are the protected packets that arrive at the security gateway, typically coming from the public network Encryption and authentication are extremely compute- to the private network. These packets have to be decrypted, intensive functions. A security gateway that must perform at authenticated, and forwarded to the private network. 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.

• Packet Processors - 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 - Handles SA lookup and packet handling, as well as SPD verification. Figure 5 - IPSec Packet Processing Data Flow (User Space SW implementation)

07 | 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).

| 08 This packet engine is used as a bus master in the data plane handle the cryptographic workload due to performance or of the system and processes packets with very little CPU power limitations. The packet engine handles the security intervention. It supports an AXI streaming interface, an (protocol) operations and reduces power in high-end servers, AMBA SoC bus interface and can be delivered in different communication and network processors for: network processors configurations to support multiple performance grades from used in switch applications; data center processing and cloud 5 to 80+ Gbps, achievable even on a single SA (one half of a computing; communication and high-end security gateways. single tunnel) - or as many SA’s/tunnels as needed (limited only by available memory connected to the SoC). The EIP-197 packet engine is highly configurable. Therefore, implementations are available for low power, low cost (area) and The EIP-197 is designed for systems requiring security protocol low bandwidth applications, using a limited set of algorithms, processing at extreme speeds, where CPU (farms) cannot as well as for extreme high-bandwidth server implementations, capable of handling large system latencies and supporting all common algorithms.

Key benefits 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.

Figure 6 - EIP-197 Security Packet Engine with Classifier, In-Line, >5Gbps

09 | IPSec classification Leveraging Multi-CPU and Trusted Execution Environment The EIP-197 parses the IPSec-ESP header to look-up a flow, it (TEE) Architectures fetches the flow and corresponding transform record based The EIP-197 supports multi-core and virtual machine on the lookup result, updates flow and transform statistics and architectures as well as a SA/key separation for TEE supports IPv4 and IPv6 architectures. environments with Normal and Secure worlds. All required arbitration is fully handled in hardware.

Complete IPSec transformation (IPv4 and IPv6)

• Full IPSec packet ESP transforms according to latest RFCs MEMORY (2403, 2404, 2405, 2410, 3566, 3602, 3686, 4106, 4301, 4303, Application 2 descriptor 4308, 4309, 4543, 4835, 4868, 4869, 6054, 6071 and 6379) ring 1 Application 1 Application 3 SA descriptor packet and • IPSec ESP tunnel & transport mode data- ring 2 tokens base CPU1 CPU2 descriptor • Autonomous IPSec ESP packet classification and security ring 3 association selection (both inbound and outbound)

• Insert ESP header for outbound packets, strip and verify ESP header for inbound packets SYSTEM BUS

• Full sequence number processing, including ESN and full anti- replay check with various mask sizes Ethernet ring- ring- ring- AIC1 AIC2 • Calculate and insert integrity check value for outbound Interface ctrl 1 ctrl 3 ctrl 2 packets, strip and verify for inbound packets Processing engine • Append (outbound) / strip and verify (inbound) padding up to 255 bytes EIP-(1)97 PACKET ENGINE

Figure 7 - Leveraging Multi-CPU and TEE Architectures

| 10 Protocol Processing Software Toolkits Measuring Security Performance The EIP-197 is provided together with an efficient Driver When comparing security performance and power consumption Development Kit which enables a seamless integration with between HW and SW architectures, the EIP-197 Packet Engine may Inside Secure’s QuickSec SW Stack. 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 (Figure 8).

HIGHER POWER 100% 90% 80% Energy/Power ARMv7 32 bit consumption 70% ARMv8 64 bit 60% Packet Engine 50%

Lower is 40% better 30% 20% 10% HW Offloading LOWER POWER 0% Benefit

AES / SHA-1 / DES / ARC4 / IPSec transform IPSec transform SSL SHA256 MD5 / HMAC (AES / SHA-1) (other crypto) (ARC4 / MD5)

Figure 8 - Security performance measures

11 | For further details on all of Inside’s security solutions, visit www.insidesecure.com

Information in this document is not intended to be legally binding. Inside Secure products are sold subject to Inside Secure Terms & Conditions of Sale or the provisions of any agreements entered into and executed by Inside Secure and the customer. © Inside Secure 2017. All Rights Reserved. Inside Secure,® Inside Secure logo and combinations thereof, and others are registered ® trademarks or tradenames of Inside Secure or its subsidiaries. Other terms and product names may be trademarks of others. The products described herein may be protected by one or more of the patents and/or patent applications listed in related datasheets, such document being available on request under specific conditions. Additional patents or patent applications may also apply depending on geographic regions. infostrates