INTERNET PROTOCOL SECURITY (IPSEC) GUIDE.

Transcription

1 INTERNET PROTOCOL SECURITY (IPSEC) GUIDE

2 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

3 VPN APPLICATIONS There 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. ranet VPNs: These let companies connect with their business partners (for example, suppliers, customers, and joint ventures). 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 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 TRANSPORT MODE IP HDR HDR Trailer Auth Encrypted Authenticated TUNNEL MODE NEW IP HDR HDR IP HDR Authenticated Encrypted Trailer Auth Figure 1 - IPSec VPN Applications Figure 2 - IPSec modes of operation tunnel and transport 03

4 IPSEC ARCHITECTURE Figure 3 describes the overall 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 Certificate Manager SPD SAD Incoming Packet Receive Queue IPSecPacketProcessingModule Transmit Queue Outgoing Packet CryptographyModule Figure 3 - IPSec architecture 04

5 IPSEC PROTOCOLS IPSec standards have defined a key negotiation protocol, IKE, and two protocols to exchange data, and AH. is most commonly used. Original Packet IP TCP Encapsulating Security Payload () 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 header. New IP IP TUNNEL MODE TRANSPORT MODE IP TCP Encrypted Authenticated TCP Encrypted Authenticated Trailer Trailer Figure 4a - IPSec Transport and Tunnel formats Auth Auth 05

6 Authentication (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, 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. Original Packet IP TCP 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. IP TRANSPORT MODE Authent. TCP 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. Authenticated (except for mutable fields) TUNNEL MODE New IP Authent. IP TCP Authenticated (except for mutable fields in new IP ) Figure 4b - IPSec AH Transport and Tunnel formats 06

7 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. Engineering A High-Performance Security Gateway Encryption and authentication are extremely computeintensive functions. A security gateway that must perform at wire speed with 64-byte packets cannot rely on a softwareonly 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 or AH header, as required) in addition to supporting the prior functionality. Figure 5 - IPSec Packet Processing Flow (User Space SW implementation) Inline Security Coprocessors - Handles SA lookup and packet handling, as well as SPD verification. 07

8 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

9 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 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

10 IPSec classification The EIP-197 parses the IPSec- 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. 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. Complete IPSec transformation (IPv4 and IPv6) Full IPSec packet 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 tunnel & transport mode Autonomous IPSec packet classification and security association selection (both inbound and outbound) Application 2 Application 1 Application 3 CPU1 CPU2 descriptor ring 1 descriptor ring 2 descriptor ring 3 MEMORY SA database packet and tokens Insert header for outbound packets, strip and verify header for inbound packets SYSTEM BUS Full sequence number processing, including ESN and full antireplay 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 Ethernet Interface ringctrl 1 ringctrl 3 ringctrl 2 AIC1 Processing engine EIP-(1)97 PACKET ENGINE AIC2 Figure 7 - Leveraging Multi-CPU and TEE Architectures 10

11 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 (Figure 8). HIGHER POWER 100% Energy/Power consumption Lower is better LOWER POWER 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 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) Figure 8 - Security performance measures 11

12 For further details on all of Inside s security solutions, visit 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 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