INTERNET PROTOCOL SECURITY (IPSEC) GUIDE

www.insidesecure.com

INTRODUCING IPSEC– NETWORK LAYER PACKET SECURITYWith 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

03 |

VPN APPLICATIONSThere are three basic flavors of IPSec VPNs, each with an associated set of business requirements (Figure 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 OPERATIONIPSec 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 endpoints. 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.

IP HDR Data

ESPTrailer

ESPAuthIP HDR ESP HDR

TRANSPORT MODE

Data

Encrypted

Authenticated

TUNNEL MODEESP

TrailerESPAuthIP HDRNEW IP HDR ESP HDR Data

Encrypted

Authenticated

Figure 2 - IPSec modes of operation—tunnel and transport

IPSEC ARCHITECTURE 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.

Policy Manager IKE Daemon

IPSecPacketProcessingModule

SADSPD

Certificate Manager

Receive Queue

Incoming Packet

Outgoing Packet

Transmit Queue

CryptographyModule

| 04

IPSEC PROTOCOLSIPSec 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. Figure 4a - IPSec ESP Transport and Tunnel formats

TCPExt Hdrs

IP Header

Original Packet Data

TCP ESPTrailer

ESPAuth

Ext Hdrs

IP Header

TRANSPORT MODE

Data

Encrypted

Authenticated

ESP Header

TCP ESPTrailer

ESPAuth

Ext Hdrs

Ext Hdrs

New IP Header

IP Header Data

Encrypted

Authenticated

ESP Header

TUNNEL MODE

05 |

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:

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 protocol messages.

2. 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.

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 4b - IPSec AH Transport and Tunnel formats

TCPExt Hdrs

IP Header

Original Packet

TRANSPORT MODE

Data

Authenticated (except for mutable fields)

TCPExt Hdrs

IP Header DataAuthent.

Header

TUNNEL MODE

DataTCPExt Hdrs

Ext Hdrs

New IP Header

IP Header

Authent. Header

Authenticated (except for mutable fields in new IP Header)

| 06

IPSEC PACKET PROCESSINGFigure 5 describes IPSec operation on the security device for inbound and outbound packets. Inbound Packet ProcessingInbound 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 ProcessingOutbound packets arrive from the private network and are destined to another private network across the Internet. These packets need to be protected.

Engineering A High-Performance Security GatewayEncryption 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.

• 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.

07 |

Figure 5 - IPSec Packet Processing Data Flow (User Space SW implementation)

| 08

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

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

09 |

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

Leveraging Multi-CPU and Trusted Execution Environment (TEE) ArchitecturesThe 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.

IPSec classificationThe 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

| 10

Application 1 Application 3

Application 2

CPU1

Ethernet Interface

CPU2

descriptor ring 1

descriptor ring 2

descriptor ring 3

SA data- base

packet and tokens

MEMORY

SYSTEM BUS

ring- ctrl 1

ring- ctrl 3

ring- ctrl 2 AIC1

Processing engine

EIP-(1)97 PACKET ENGINE

AIC2

Figure 7 - Leveraging Multi-CPU and TEE Architectures

Protocol Processing Software ToolkitsThe 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 PerformanceWhen 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 (Figure 8).

11 |

Figure 8 - Security performance measures

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%HIGHER POWER

Energy/Power consumption

Lower is better

LOWER POWER

ARMv7 32 bit

ARMv8 64 bit

Packet Engine

HW Offloading Benefit

AES / SHA-1 / SHA256

DES / ARC4 / MD5 / HMAC

IPSec transform (AES / SHA-1)

IPSec transform (other crypto)

SSL (ARC4 / MD5)

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.

For further details on all of Inside’s security solutions,

visit www.insidesecure.com

info

stra

tes