SSL Capacity Planning

Microsoft Internet Security and Acceleration (ISA) Server 2004, using Secure Socket Layer (SSL), enhances secure publication of a variety of Web content. ISA Server 2004, together with SSL, enables private access to published Web sites and, for corporate users, more secure access to various internal network resources, such as e-mail, shared Web sites, terminal services, and more. Using the information in this article, you can make sure that your organization’s implementation of ISA Server 2004 has enough capacity to support SSL and SSL-published applications.

Executive Summary

Understanding SSL Performance

SSL Bridging

Determining SSL Capacity

Executive Summary

Generally, the available network bandwidth, and especially the bandwidth of the Internet link, can be secured to an acceptable degree by ISA Server with SSL enabled, running on typical hardware. The following table shows the amount of throughput supported by an ISA Server running on 2.4 gigahertz (GHz) Intel® Pentium 4 processors for various SSL applications.

Table 1   Megabits per second supported by typical hardware, and SSL configuration for various SSL applications

Understanding SSL Performance

SSL is a TCP protocol that uses port 443. SSL is also known as Secure HTTP (HTTPS), because it defines secure wrapping, authentication, and encryption for HTTP content.

From a performance perspective, SSL encryption and decryption create an additional processing layer, beyond regular HTTP processing. This layer includes the following two major CPU intensive phases:

• SSL handshake   After establishing a TCP connection, SSL creates a security context between endpoints using Public Key Interchange (PKI). This is known as an SSL handshake. In terms of aggregate network traffic, an SSL handshake consumes processing power that is proportional to connection rate (measured in connections per second).
• **Encryption   **After a security context is established, an endpoint uses it to encrypt or decrypt HTTP content, using symmetric encryption. This processing is performed on each byte of HTTP data. Therefore, it consumes processor cycles proportional to aggregate network throughput (measured in megabits per second).

The ratio between aggregate throughput and connection rate determines the average number of bits that are processed for every connection. This ratio is defined as "bits per connection," and in practice, every application has a characteristic value for this ratio.

Here are some examples:

Outlook Web Access

When a Web client connects to an Outlook Web Access Exchange Server front-end server, it loads the Outlook Web page that contains the user-interface icons and headers of messages currently in the mailbox. Subsequently, any operation that the user performs (such as Open, Send, or Move to Folder) generates a new HTTP connection that transfers an average of 10 to 20 kilobytes (KB). When accumulating the behavior of Outlook Web Access over many users, the Web client typically creates a relatively low bits per connection value (such as, 100 kilobits per connection).

RPC over HTTP with Outlook 2003 Cached Exchange Mode

RPC over HTTP is a feature of Microsoft® Exchange Server 2003 that enables Outlook 2003 clients to access an Exchange server in the internal corporate network from the Internet. When connecting to Exchange Server, an Outlook 2003 client working in Cached Exchange Mode typically starts with a synchronization of mailbox content with a local cache file. After the synchronization is complete, intermittent connections occur, in which new messages are transferred. For a heavy knowledge worker profile user, the synchronization operation transfers many bytes of data over a small number of connections, so the overall characteristic bits per connection value is rather high (such as, 500 kilobits per connection).

Web Site

There are many ways to design and implement a Web site. Therefore, Web sites do not have a typical bits per connection value. However, after a Web site is serving requests, you can measure the aggregate bits per connection. In practice, Web sites have medium value bits per connection (anywhere between 100 and 500 kilobits per connection).

SSL Bridging

When you deploy ISA Server with Secure Web Publishing, secure Web clients on the external network can connect to the SSL port. SSL bridging is a feature of ISA Server, which enables you to specify how ISA Server communicates with the back-end Web server that is published. This feature lets you choose between the following two types of bridging:

• SSL to SSL bridging   In this type of bridging, ISA Server accesses the back-end server with SSL. ISA Server performs separate SSL handshakes with the back-end server and must use encryption for every packet that it receives from or sends to the back-end server.
• SSL to HTTP bridging   In this type of bridging, ISA Server accesses the back-end server in clear, unencrypted HTTP.

SSL to SSL bridging strengthens the security on the internal network, but adds the processing cost of double encryption to every packet that is transferred between ISA Server and the back-end server. SSL to SSL bridging costs about 20 to 30 percent more than SSL to HTTP bridging.

Determining SSL Capacity

To determine what size ISA server you must have to support peak network traffic loads, you must first measure the typical kilobits per connection of your network traffic and then measure the total aggregate traffic. Use the following procedure to make these determinations:  

1. Use the system performance monitor tool to monitor the network traffic of each application server for the peak two hours of server activity. Collect the following counters:
   \Network Interface\Bytes Total/sec   This is the counter of the interface that is published by ISA Server. Use the average value as the average throughput with the duration. This value is also used to calculate the total aggregate traffic.
   \TCPv4\Connections Active   The value of this counter is the total number of connections created during the monitoring session. To determine the average connections per second within this duration, you divide the difference between maximal and minimal values by the total duration. Calculate the number of kilobits per connection as: kilobits per connection = (bytes total per second * 8 per 1000) per (connections per second).

2. Determine the total average kilobits per connection as the weighed average of the kilobits per connection of each application server. The weight for each server is the throughput of that server divided by the total throughput of all servers.

3. Determine the total aggregate traffic by adding the traffic measured on each server.

4. Use the following table to determine the number of megacycles that are required for every megabit of SSL traffic that ISA Server processes, according to the kilobits per connection measured in Step 2.
   Megacycles per megabit for various kilobits per connection

   Kilobits per Connection	100 (Outlook Web Access)	200(Web)	500(RPC over HTTP)
   1 processor, SSL to HTTP	91	77	69
   1 processor, SSL to SSL	120	96	83
   2 processors, SSL to HTTP	128	104	91
   2 processors, SSL to SSL	142	120	104

   Note

   Because of the wide variety of ISA Server configurations, usage scenarios and hardware platforms, the numbers just cited are for estimation purposes only. For deployments with Internet link bandwidth larger than 10 megabits per second, we recommend pilot testing to verify these estimates. For more information about ISA Server performance and capacity planning, see ISA Server 2004 Performance Best Practices at https://go.microsoft.com/fwlink/?LinkID=24514.

5. To determine the processor speed that is required to support the total aggregate traffic, multiply the megacycles per megabit, from the table in Step 4, by the total throughput, as measured in Step 3.

For example, suppose that the kilobits per connection calculated in Step 2 is 200, the total aggregate throughput is 15 megabits, and you require ISA Server to perform SSL to SSL bridging. From the table above, a single processor requires 96 megacycles per megabit or 96 * 15 = 1440 megacycles for 15 megabits per second. A single Intel Pentium 4 processor running at 2.4 GHz is sufficient for this load and is used at 1440 / 2400 = 60% at peak throughput. A dual processor computer with two Intel 2.4 GHz Pentium 4 processors requires 120 megacycles per megabit or 120 * 15 = 1800 megacycles for 15 megabits per second and is used at 1800 / (2 * 2400) = 38% at peak throughput.      

The following table shows the amount of traffic that a 2.4 GHz processor can process at maximum recommended usage (80%):

Table 2   Megabits per second at 80% CPU usage for various kilobits per connection

Table 2 is specifically for deployments in which ISA Server is used only for SSL traffic. If you plan to deploy ISA Server for both SSL and regular, unencrypted HTTP traffic, you can estimate the processing power you require by calculating a weighted average of megacycles according to the amount of traffic for each scenario multiplied by the megacycles per megabit shown in the following table:

Table 3   Megacycles per megabit for unencrypted Web Proxy scenarios

For example, suppose that you want to deploy ISA Server in an edge firewall scenario in which 40% of the 20 megabit per second peak traffic is transparent proxy, 35% is forward proxy, and 25% is SSL to SSL with 200 kilobits per connection. The total amount of megacycles required for ISA Server to process this traffic on a single processor computer is:

megacycles = 20 megabits per second * (74 * 40% + 37 * 35% + 96 * 25%) = 1331

A 2.4 GHz Intel Pentium 4 processor is sufficient to process this load and is used at 1331 / 2400 = 55% at peak throughput. A dual processor computer requires 20 * (86 * 40% + 43 * 35% + 120 * 25%) = 1589 megacycles, which uses 1589 / (2400 * 2) = 33% of two 2.4 GHz Intel Pentium 4 processors at peak throughput.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, places, or events is intended or should be inferred.