1. Behavioral and Performance Characteristics of IPsec/IKE in Large-Scale VPNs Okhee Kim (okim@nist.gov) Doug Montgomery (dougm@nist.gov) Advanced Network Technologies Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899

2. Dec. 12, 2003 NIST/ITL/ANTD 2 Outline Introduction NIST IPsec/IKE Simulation Tool (NIIST) Experiment Design Simulation results: Analysis and observations IPsec/IKE Overview (If needed)

3. Dec. 12, 2003 NIST/ITL/ANTD 3 Introduction 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).

4. Dec. 12, 2003 NIST/ITL/ANTD 4 NIST IPsec/IKE Simulation Tool 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.

5. Dec. 12, 2003 NIST/ITL/ANTD 5 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.

6. Dec. 12, 2003 NIST/ITL/ANTD 6 Experiment Design Experiment Topology Workload models Experiment security parameters Performance measures

7. Dec. 12, 2003 NIST/ITL/ANTD 7 Experiment 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.

8. Dec. 12, 2003 NIST/ITL/ANTD 8 Workload 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

9. Dec. 12, 2003 NIST/ITL/ANTD 9 Experiment 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.

10. Dec. 12, 2003 NIST/ITL/ANTD 10 Experiment 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.

11. Dec. 12, 2003 NIST/ITL/ANTD 11 Workloads: Application, IPsec and IKE Traffic load (TCP sessions and IKE/IPsec SAs) generated from each network configuration and workload models using ESP(AES_CBC+HMAC_SHA1)

12. Dec. 12, 2003 NIST/ITL/ANTD 12 Performance 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 (6 th ) 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.

13. Dec. 12, 2003 NIST/ITL/ANTD 13 Performance measures (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.

14. Dec. 12, 2003 NIST/ITL/ANTD 14 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

15. Dec. 12, 2003 NIST/ITL/ANTD 15 Impact of Security Policy 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.

16. Dec. 12, 2003 NIST/ITL/ANTD 16 Effect of SA Granularity Analysis 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.

17. Dec. 12, 2003 NIST/ITL/ANTD 17 Effect of Security Services 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.

18. Dec. 12, 2003 NIST/ITL/ANTD 18 Effect of Security Services (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.

19. Dec. 12, 2003 NIST/ITL/ANTD 19 Impact of Implementation Options We examine two implementation details of IPsec/IKE that can impact on the overall VPN performance. Various re-keying techniques IPsec packet handling options

20. Dec. 12, 2003 NIST/ITL/ANTD 20 Various 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.

21. Dec. 12, 2003 NIST/ITL/ANTD 21 Impact 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 3 rd message has been sent out. The responder continues to transmit data with the old SA until the 3 rd 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.

22. Dec. 12, 2003 NIST/ITL/ANTD 22 IPsec Handling Options for TCP SYN Packets 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.

23. Dec. 12, 2003 NIST/ITL/ANTD 23 Impact of Dynamic SA Establishment 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.

24. Dec. 12, 2003 NIST/ITL/ANTD 24 Impact of Dynamic SA Establishment 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.

25. Dec. 12, 2003 NIST/ITL/ANTD 25 For more information www.antd.nist.gov/niist/

26. IPsec/IKE Overview

27. Dec. 12, 2003 NIST/ITL/ANTD 27 IP Security Protocols (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

28. Dec. 12, 2003 NIST/ITL/ANTD 28 IPsec 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.

29. Dec. 12, 2003 NIST/ITL/ANTD 29 IPsec 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)

30. Dec. 12, 2003 NIST/ITL/ANTD 30 Encapsulation modes Transport mode Tunnel mode

31. Dec. 12, 2003 NIST/ITL/ANTD 31 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

32. Dec. 12, 2003 NIST/ITL/ANTD 32 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

33. Dec. 12, 2003 NIST/ITL/ANTD 33 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

34. Dec. 12, 2003 NIST/ITL/ANTD 34 IPsec/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.

35. Dec. 12, 2003 NIST/ITL/ANTD 35 Experiment 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

36. Dec. 12, 2003 NIST/ITL/ANTD 36 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.

37. Dec. 12, 2003 NIST/ITL/ANTD 37 Asymmetric 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.

38. Dec. 12, 2003 NIST/ITL/ANTD 38 Asymmetric Hosts (asymmhost) A configuration where: Half the hosts in each net are clients; The other half of the hosts are servers.

39. Dec. 12, 2003 NIST/ITL/ANTD 39 Fully Symmetric (fullsymm) A configuration where Each host in each net acts as both a client and a server.