In this section, we show simple experiments using a simple dumbbell topology. For a full mesh VPN experiments, refer Publications Section.
A dumbbell topology used in the experiments (shown diagram below) consists of a pair of security gateways (SG1 and SG2) and one or more hosts behind each gateway (connected with a LAN). Each gateway provides secure VPN services (using IPsec) for the local hosts and acts as the SA initiator or the SA responder.
The tunnel granularity represents how a security system controls data traffic flows. IPsec allows the user to control the granularity of SAs depending on the local security policy, such as port-based, protocol-based, host-based or site-based tunnels. We used two types of granularities for the experiment: per-site creates a single SA for all the hosts behind the gateway and per-host creates an SA for each host.
As described in the Publications Section, NIIST also provides a tool that can easily build large-scale VPNs in a full mesh topology. The tool is based on SOS: Scripts for Organizing 'Speriments. The user can create a network configuration of N sites, each of which consists of a single SG and M hosts behind it. Three network configurations can be modeled:
In all cases, connections are made between SGs that contain clients and servers. Thus, each network that contains clients is connected to every other network that contains servers whenever TCP requests are generated from the local hosts, under various network configurations.
Traffic Models
At the start of the simulation, a TCP client of each TCP session connects to a randomly chosen server and sends a file transfer request to transmit fixed-size data for the duration of the experiment. A security gateway initiates the SA negotiation for both IKE and IPSec as ``needed'' basis. In other words, all initial SA negotiations are triggered by user traffic.
A TCP-based application continuously generates fixed-size traffic for each session for the duration of the experiment. The TCP clients wait for either a random time (an exponential distribution with mean of 10 seconds) to send the next request after completion of the session, depending on the specific experiment to create a desired environment.
We explore a set of performance metrics such as the number and type of SAs created (e.g., IKE SA/IPsec SA and initial SA/re-keyed SA), SA establishment latency, and the number of IP packets discarded, due to no SAs available, in the IPSec module. These measurements can be evaluated at various layers, depending upon the purpose of experiments: application level, IKE level, IPSec level.
SA establishment latency is a measure of the logical time taken to establish an SA by the initiator. IKE SA latency is measured for the time taken from sending the first IKE message and to receiving the last message (requiring 3 round trips). IPSec SA latency (for an outbound SA) is measured for the time taken from sending a SA request (by IPSec module) and to receiving the corresponding SADB message from the IKE module. IPsec SA latency may include IKE set-up time if no IKE SA is established. When a corresponding IKE SA is available, IPsec SA set-up requires 2 round trips, including a Delete message or user traffic with the new SA, as a default mode.
Packet statistics represent counts of various packet types processed at the IPSec module such as protected/unprotected/bypassed/error packets. The IP packets are counted for both inbound and outbound independently within a security gateway so the same packet can be counted more than once as inbound and outbound.
For the application layer, the following statistics were gathered: the number of FTP sessions which succeeded, session throughput, session latency, and total number of TCP retransmissions.
Experiment Background
All experiments are conducted in Tunnel Mode and use a time-based policy. For the initial SA establishment, the initiator starts the Phase 1 negotiation followed by Phase 2. Any security gateway can initiate the re-keying negotiation, if required by the local security policy. For the phase 2 re-keying, only outbound SAs are allowed to re-key. Before sending a SA re-keying request to key management, the kernel checks to see whether there already exists the new SA with the same policy criteria as the original SA. As for Phase 1 re-keying, the key management also checks to see whether there already exists a qualified IKE SA for the old SA.
Generally, a security gateway is assumed to be an edge router connected to Internet with bandwidth of 1.5 Mbps (for an IPSec-enabled external interfaces) and to the local hosts with a LAN 100 Mbps (for an internal interface with no IPSec). The packet size is assumed to be constant 1000 bytes and one-way link delay as 50ms. The initial action to be taken by the system when no SA is available is to drop packets.
The identity used for IKE and IPSec is a single IPV4 address and no network interface delay is assumed. The default authentication mode is a pre-shared secret key for IKEv1.
The security attribute values and the experiment-specific parameter values can affect the overall performance and dynamics of security protocol operations. Depending on the experiments, the values of one or more parameters are changed to see what affect those parameters and their values play on performance. Unless otherwise stated, the following default values are used:
Variable Default Value
Sequence number space 32-bit anti-replay window
Encryption algorithm THREE_DES_CBC
Authentication algo.(IKE/IPsec) HMAC_SHA1
Lifetime (IKE) 1000 seconds
Lifetime (IPSec) 400 seconds
Simulation duration 172800 seconds (48 hours)
link delay 50 ms
network interface delay 0
bandwidth (between gateways) 1.5Mb/s
bandwidth (gateway and host) 100Mb/s
Threshold (initiator) 85%
Threshold (responder) 90%
Initial action with no SA DROP
The cryptographic performance figures used for these experiments were measured using an IPSec reference prototype Cerberus developed by NIST. The specific figures are shown below.
Algorithms Block Size Key Size Encryption Decryption THREE_DES_CBC 8 24 811K 810K HMAC_SHA1 64 20 7174K 7313K HMAC_MD5 64 16 15651K 16228K DH group 2 0.1 second
A set of experiments are discussed to demonstrate behavioral and performance characteristics of interacting suite of security protocols. All experiments are conducted on a Linux server featuring two 1-GHz processors and 1 GB of memory.