Behavioral and Performance Characteristics of IPsec/IKE in Large-Scale VPNs Okhee Kim...

Behavioral and Behavioral and Performance Performance

Characteristics of IPsec/IKE Characteristics of IPsec/IKE inin

Large-Scale VPNsLarge-Scale VPNsOkhee Kim ([email protected])

Doug Montgomery ([email protected])Advanced Network Technologies Division

Information Technology LaboratoryNational Institute of Standards and Technology

Gaithersburg, MD 20899

Dec. 12, 2003 NIST/ITL/ANTD 2

OutlineOutline

Introduction NIST IPsec/IKE Simulation Tool (NIIST) Experiment Design Simulation results: Analysis and

observations IPsec/IKE Overview (If needed)


IntroductionIntroduction Cryptographic network security is essential for

providing secure communication over an insecure public network such as the Internet.

IPsec has become one of the most widely used means for building secure Virtual Private Networks (VPNs).

Currently, most IPsec VPNs are statically configured and of moderate scale.

We investigate the relative performance and dynamic behavior of IPsec VPN in large-scale environments with dynamic key management system (IKEv1).


NIST IPsec/IKE Simulation NIST IPsec/IKE Simulation ToolTool

NIIST- Provides detailed, packet level models of IPsec/IKE protocols based on the Scalable Simulation Framework (SSF/SSFNet).

Provides the tools that easily build large scale VPN models, using SOS (Scripts for Organizing ‘Speriments).

Models the behavior of security protocols and impact of cryptographic processing overhead on performance.

Designed to study the performance / behavior impact of IPsec/IKE, not to evaluate security properties.


NIIST (cont’d)NIIST (cont’d)

Provides the ability to parameterize IPsec VPN models:

Security policies IPsec/IKE parameters Performance of cryptographic algorithms Operational processing options: e.g., re-keying

techniques, packet handling options. Provides instrumentation that can be used to

evaluate the relative performance of IPsec/IKE and its effect on the performance of end-to-end applications.


Experiment DesignExperiment Design

Experiment Topology Workload models Experiment security parameters Performance measures


Experiment TopologyExperiment Topology A network configuration of N sites in

a full mesh VPN topology Each site consists of a single SG

and M hosts We consider 3 different

client/server topologies AsymmNet – all hosts at site are

either clients or severs AsymmHost – ½ hosts at each

site are clients, the other ½ servers

FullSymm – every host is both client and server

Two types of tunnel granularities: Per-site creates a single IPsec SA

for all the hosts behind a given SG;

Per-host creates an unique IPsec SA, at the SG, for each communicating host pair.


Workload modelsWorkload models VPN Client/Server Application: file transfer (FTP) An FTP client sends a request to a randomly

chosen server to transfer fixed size (1KB or 1MB) data.

The FTP client, then, sleeps a random time seconds (an exponential distribution with mean of 10 secs) before sending the next request.

Simulation time: 28800 seconds (8 hours) Packet size: 1000bytes


Experiment ParametersExperiment Parameters Life time:

IKE: 2400 seconds IPsec: 800 seconds

The initial SA establishment The SA initiator starts the phase 1 negotiation

followed by phase 2. The re-keying SA negotiation

Either initiator or responder can initiate the re-keying negotiation, if required by the local security policy.

For IPsec re-keying, only outbound SAs are allowed to re-key.

IKE and IPsec use the same cryptographic algorithms if required.


Experiment ParametersExperiment Parameters

Perfect forward secrecy (PFS) for phase 2 is used. The IKE authentication mode: pre-shared secret key Default action = DROP when no active SAs are

available: The relative performance of cryptographic

algorithms: 3DES_CBC: 1481KB/s HMAC_SHA1: 15384KB/s AES_CBC: 12500KB/s DH group 2 delay: 0.1 sec.


Workloads: Application, IPsec and Workloads: Application, IPsec and IKEIKE

Traffic load (TCP sessions and IKE/IPsec SAs) generated from each Traffic load (TCP sessions and IKE/IPsec SAs) generated from each network configuration and workload models using network configuration and workload models using ESP(AES_CBC+HMAC_SHA1)ESP(AES_CBC+HMAC_SHA1)

1KB 1MB 1KB 1MB 1KB 1MB 1KB 1MB 1KB 1MB 1KB 1MBAppl: # of sessions 70228 51482 70333 51452 84572 62078 84833 61622 140771 103793 137900 101382IKE: Initial requests 25 25 25 25 45 45 45 45 45 45 45 46 Rekey requests 389 388 389 388 700 699 699 701 702 701 702 700IPsec: Initial requests 25 25 625 625 47 48 540 540 46 46 1125 1126 Rekey requests 1214 1215 30048 29933 2283 2345 26147 26097 2237 2288 54402 57238 No SA pkts 26 26 625 625 49 48 540 540 48 48 1131 1126

per-site per-hostasymmnet asymmhost fullsymm

per-site per-host per-site per-host


Performance measuresPerformance measures

IPsec/IKE metrics at the SGs: The number of both initial and re-keyed SAs created. The number of IP packets discarded due to no valid SAs. SA establishment latency: a measure of time taken to

establish an SA by the initiator. IKE SA latency: the time taken from sending the first IKE

message and to receiving the last (6th) message (requiring 3 round trips).

IPsec SA latency (for an outgoing SA): the time taken from the initial IPsec SA request to receiving the corresponding message from IKE to set-up the SA to the SADB.

IPsec SA latency may include phase 1 set-up time if no IKE SA is available.

When a corresponding IKE SA is available, IPsec SA set-up requires 2 round trips.


Performance measures Performance measures (cont’d)(cont’d)

At the application layer / host: session throughput; session latency; the number of sessions that succeeded; and the total number of TCP retransmissions.

We examined the metrics above to analyze and characterize the relative performance of IPsec/IKE and its effect on end-to-end applications such as FTP/TCP.


Simulation results:Simulation results:

Analysis and Characterization We only discuss the results from a

fullsymm network configuration for this presentation.

Our study focuses on the: Impact of security policies Impact of IPsec/IKE implementation options Impact of dynamic SA establishment


Impact of Security Impact of Security PolicyPolicy

What is the impact of security policy granularity on the overall performance of VPN applications?

The security policy specifies what security services are required to specific IP flows: apply, bypass, or drop (reject).

If the flow requires secure communication, the policy specifies: The type of security services (e.g., authentication and/or encryption); Specific cryptographic algorithms (e.g., AES, HMAC_SHA1); and Traffic selector (SA granularity) (e.g., per-host vs. per-site).

Effects of the following policy decisions are examined: SA granularity (per-site vs. per-host) Security services.


Effect of SA GranularityEffect of SA GranularityAnalysis and Observations: Per-site performance is

significantly higher than that of per-host.

# of IPsec SAs created in fullsymm: Per-host: 55,500; per-site: 2,300. Per-host results in more noSA packet drops (1131 vs. 48) and increased wait time for traffic.

The impact of the key management delay and consequently more packet drops is more significant than that of the choice of security services, in this experiment (small file size/short session).

IPsec services: 1=bypass;2=AH(hmac_sha1);3=ESP(3des+hmac_sha1);4=ESP(aes+hmac_sha1); 5=ESP(aes+null); file size of 1KB.


Effect of Security Effect of Security ServicesServices

Analysis and Observations: Shows the impact of the relative

performance of the cryptographic algorithms on the overall performance of the application.

As expected, IPsec services #3 (i.g., ESP(3des+h_sha1) is worst among selected algorithms.

Per-site results in improved overall performance as high as 10%.

IPsec services: 1=bypass; 2=AH(h_sha1); 3=ESP(3des+h_sha1); 4=ESP(aes+h_sha1; 5=ESP(aes+null); File size of 1MB.


Effect of Security Services Effect of Security Services (cont’d)(cont’d)

Analysis and Observations (cont’d): based on table below: Security services do not greatly impact on key management performance. SA latency performance is also impacted by the SA granularity (per-site vs. per-host). IPsec Init SA delay (requiring 2 round-trips) is higher than that of IKE (requiring 3

round-trips) for per-site, but is lower for per-host. IPsec Init SA delay for per-site includes the time for the Phase 1 set-up since no corresponding IKE SAs are available.

Per-host results in much better IKE performance since a single IKE SA between a pair of SGs can be used to negotiate multiple phase 2 SAs and the cost of the initial IKE SA establishment is amortized across numerous IPsec SAs.

per-site per-host per-site per-host per-site per-host per-site per-hostIKE: Init SA delay (s) 0.538 0.572 0.567 0.571 0.537 0.574 0.538 0.565 Rekey SA delay(s) 0.505 0.522 0.539 0.58 0.506 0.522 0.505 0.52IPsec: Init SA delay (s) 0.847 0.331 0.894 0.344 0.842 0.331 0.85 0.331 Rekey SA delay(s) 0.403 0.461 0.428 0.452 0.403 0.459 0.402 0.46

AH (hmac_sha1) ESP (3des+h_sha1) ESP (aes+h_sha1) ESP (aes+null)


Impact of Implementation Impact of Implementation OptionsOptions

We examine two implementation details of IPsec/IKE that can impact on the overall VPN performance. Various re-keying techniques IPsec packet handling options


Various re-keying strategiesVarious re-keying strategies

The performance trade-offs inherent in implementing 4 re-keying techniques:

DeleteMsg: set-up when a Delete message for the old SA is received;

Fixed delay: set-up when either receiving inbound traffic with the new SA or, in the absence of incoming traffic, after a fixed amount of time (e.g., 30s) has elapsed;

Twice measured RTT: set-up after either receiving inbound traffic using the new SA or after twice the measured round trip time has elapsed; and

immediateUSE: set-up immediately for use.


Impact of Re-keying TechniquesImpact of Re-keying Techniques

Analysis and Observations: immediateUse shows the worst overall performance.

The re-key SA initiator sets-up the new SA (and deletes the old) as soon as the Quick Mode 3rd message has been sent out. The responder continues to transmit data with the old SA until the 3rd message is received.

The application performance for immediateUse is not greatly impacted due to the use of fast retransmission. The amount of time to wait for SA transfer can impact the performance of key management and application. Inconsistent choices among re-keying options among peer SGs can be one of causes that results in potential

synchronization and interoperability problems.

DeleteMsgFixed Delay RTTD2 ImmedUseApplication: # of sess(1MB/se) 101382 99929 101419 101608 Avg. Thrput (kbps) 1904.955 1900.938 1904.564 1896.463 Avg sess. Delay(s) 4.2 4.208 4.2 4.218 # of retransmission 1126 1130 1145 2036IPsec: Rekeying req's 57238 56297 57296 57249 Rekeying SA del(s) 0.459 27.755 0.918 0.309 Pkts dropped(noSA) 1126 1129 1145 19839


IPsec Handling Options IPsec Handling Options for TCP SYN Packetsfor TCP SYN Packets

1800

1850

1900

1950

2000

2050

2100

Per-Host Per-Site

SA Granularity

Thro

ughp

ut (kb

ps)

DROP

KEEP

Analysis and Observations: The IPsec specification specifies that

received IP packets are to be dropped when no valid SAs available.

The graph shows that the application performance can be significantly improved by keeping the first packet for a TCP connection (i.e., a SYN packet) at the gateway and transmitting it to the peer SG as soon as the IPsec SA negotiation is complete.

The performance of application latency also shows the identical characteristics as that of throughput. In case of latency, the performance improvement is as much as the initial TCP retransmission timeout.


Impact of Dynamic SA Impact of Dynamic SA EstablishmentEstablishment

Three scenarios are examined: Dynamic p1+p2: dynamically created IKE SA

followed by IPsec SAs; Dynamic p2: Statically created IKE SA and

dynamically created IPsec SAs; Static p1+p2: manually pre-installed IKE SA and

IPsec SAs.


Impact of Dynamic SA Impact of Dynamic SA EstablishmentEstablishment

Analysis and Observations: Application latency increases when

SYN packets are dropped at SGs, as much as the TCP initial retransmission timeout.

The performance of the drop policy is identical for both dynamicp1+p2 and dynamic p2 because the retransmission timeout is longer than the IKE latency for both phase 1 and phase 2.

The application performance, latency in this case, is not greatly impacted by dynamic SA establishment under the keep implementation policy at SGs.

The overall performance of TCP based applications, in this experiment, is significantly impacted by the packet handling implementation options than dynamic SA establishment.

0

2

4

6

8

10

12

14

Dynamic P1+P2 Dynamic P2 Static P1+P2

Laten

cy (s

)

DROP

KEEP


For more informationFor more information

www.antd.nist.gov/niist/

IPsec/IKE OverviewIPsec/IKE Overview


IP Security Protocols IP Security Protocols (IPsec)(IPsec)

Provides cryptographic network security at the network layer:

Confidentiality Data origin authentication Data integrity Anti-replay

Transparently protects data at the IP level.

Applications: Secure VPNs between sites

(as shown at right) Secure remote access (site-

to-end) End-to-end communication


IPsec VPNsIPsec VPNs

Configuration: Security policy: static configuration. The

design of dynamic security policy management is currently being underway by IETF.

Key exchange and management: Manual configuration: does not scale well. Dynamic management (IKE): complex in

large-scale networks.


IPsec ComponentsIPsec Components IP security management

protocols: ESP and AH. Security policy (SPD)

specifies what services are to be offered to specific IP traffic: protection, bypass, or drop.

Security association database (SAD) contains security parameters associated with current active SAs.

Key exchange and management (IKE)


Encapsulation modesEncapsulation modes

Transport mode Tunnel mode


Traffic selector (TS)Traffic selector (TS)

Is used to map traffic to a policy (an SA): Source and destination IP address Source and destination ports TP protocols

Defines the SA granularity: Fine granularity SAs Coarse granularity SAs


Internet Key Exchange (IKE)Internet Key Exchange (IKE)

Automated cryptographic key exchange and management Phase 1:

Establish a secure authenticated channel to protect IKE exchanges.

Diffie-Hellman (D-H) exchange for public key. Peer authentication: either shared secret or public keys. Bi-directional. A single phase 1 SA can be used to create multiple phase

2 SAs. 2 possible modes:

Main mode: requires 3 round-trips (6 messages) Aggressive mode: 3 messages


IKE (cont’d)IKE (cont’d) Phase 2:

Quick mode: 3 messages (requiring 2 round-trips).

Used to negotiate SA for other protocols such as IPsec (e.g., ESP and AH).

Generate 2 SAs (one in each direction) Can initiate a new D-H for new keying

material (with Perfect Forward Secrecy). Informational exchange


IPsec/IKE Re-keyingIPsec/IKE Re-keying In general, the new SA is established before the

existing one expires, if needed. Either party can initiate re-keying negotiation. Threshold can be used to trigger the negotiation

of re-keying. Issues with regard to re-keying:

No standardization on the re-keying procedures. Different IPsec implementations use different

techniques with regard to when to set-up the re-keyed SA over the old.

Potential synchronization/interoperability problem.


Experiment TopologyExperiment Topology A network configuration of N

sites in a full mesh topology Each site consists of a

single SG and M hosts LAN: 100Mbps WAN link: 1.5Mbps Propagation delay: 50ms N = 10 sites; M in each site= 5 hosts


Experiment Topology (cont’d)Experiment Topology (cont’d)

To vary the workload presented to the VPN and IPsec/IKE modules, three models are configured: Asymmetric nets (asymmnet) Asymmetric hosts (asymmhost) Fully symmetric (fullsymm)

Two types of tunnel granularities: Per-site creates a single IPsec SA for all the

hosts behind a given SG; Per-host creates an unique IPsec SA, at the

SG, for each communicating host pair.


Asymmetric NetworksAsymmetric Networks

(asymmnet) A configuration where:

Half the network contain only hosts that are clients;

The other half of the networks contain only hosts that are servers.


Asymmetric HostsAsymmetric Hosts

(asymmhost) A configuration where: Half the hosts

in each net are clients;

The other half of the hosts are servers.


Fully Symmetric (Fully Symmetric (fullsymmfullsymm))

A configuration where Each host in

each net acts as both a client and a server.

Date post:	03-Jan-2016
Category:	Documents
Upload:	mark-mckinney
View:	214 times
Download:	0 times

Behavioral and Performance Characteristics of IPsec/IKE in Large-Scale VPNs Okhee Kim...

Documents