Our latest version of LineRate (v2.5.0) has landed with a bunch of new features. I led the charge in the development of "SSL Session ID Persistence". The purpose is to direct SSL or TLS user flows with the same Session ID to the same application server to:

• Reducing load on application server infrastructure
• Reduce the number of round trip communications needed

Let's dive into the technical details behind SSL Session IDs, session cache behavior, how to configure and use this feature, and why to use it.

---

Using Session IDs

Every successful SSL connection has an ID. The first time a new client connects to an SSL server the server generates a session identifier and sends it back to the client as part of the session negotiation. From this point on the client can establish new connections and send the session identifier in the CLIENT HELLO message. The server will re-establish the session using the previously negotiated settings, provided the server has remembered it in the cache. Otherwise it generates a new one.

Generating a new session identifier also requires generating new keys. These keys are costly to generate and get costlier with the larger keys being used today. Avoiding this excess computation by reusing the session identifier is one way to reduce load on the server. Reuse has the added benefit of eliminating a few round-trip communications required to establish the new session parameters.

---

Session Cache Behavior

OpenSSL provides session caching by default. It can be configured by the server to use the library's internal caching or an external cache. Other SSL/TLS implementations also provide caching.

The cache is only populated on the endpoint which terminates the SSL connection, which can be the proxy or the backend server. This is an important note. When the proxy (LineRate) is configured to terminate the SSL connection the session cache is on the proxy, not the backend server. This feature is really applicable to situations in which the traffic is encrypted from the client all the way to the server and is never terminated or decrypted by intermediate entities. On LineRate this means that the Virtual IP is configured in TCP mode (L4) and does not have an SSL Profile attached. Other configurations will reduce load on the proxy, but not the backend as desired. Let's look more closely at this configuration:

virtual-ip <VIP_NAME>
 ip address <VIP_IP_ADDR>:443
 service tcp
 admin-status online
real-server <RS_NAME1>
 ip address <BACKEND_SERVER_IP1>:443
 service tcp
 admin-status online
real-server <RS_NAME2>
 ip address <BACKEND_SERVER_IP2>:443
 service tcp
 admin-status online
virtual-server vs
 service tcp
 attach virtual-ip <VIP_NAME> default
 attach real-server <RS_NAME1>
 attach real-server <RS_NAME2>

Notice the following:

• Virtual IP does not terminate SSL (no SSL Profile attached)
• Real Servers do not initiate an SSL connection to the backend servers (no SSL Profile attached)
• The ports are the default SSL port on the VIP and the Reals
• The service is set to TCP so no HTTP termination is being done

The system with this configuration will load-balance incoming connections to the 2 configured Real Servers. However, there is a problem. Let's say a client establishes a connection it gets load-balanced to a Real Server and receives the session identifier from that server. When the client comes back later and attempts to re-establish a connection using the same session identifier it might get load-balanced to the other server. That server has no knowledge of the session identifier and must generate a new one and perform all of the new session negotiations. Bring on "Session ID Persistence"!

---

Configure Session ID Persistence

All that needs to be done is extend the configuration above by adding the persistence setting to the Virtual Server. User documentation is available at docs.lineratesystems.com.

virtual-ip <VIP_NAME>
 ip address <VIP_IP_ADDR>:443
 service tcp
 admin-status online
real-server <RS_NAME1>
 ip address <BACKEND_SERVER_IP1>:443
 service tcp
 admin-status online
real-server <RS_NAME2>
 ip address <BACKEND_SERVER_IP2>:443
 service tcp
 admin-status online
virtual-server vs
 service tcp
  persist ssl-session-id
 attach virtual-ip <VIP_NAME> default
 attach real-server <RS_NAME1>
 attach real-server <RS_NAME2>

The Virtual Server will then perform inspection of CLIENT HELLO messages in new connections before making a load-balancing decision. When the CLIENT HELLO includes a session identifier the load-balancing algorithm is pre-empted by using the cached value, if one exists. The data being returned in the new connection by the server is inspected for a SERVER HELLO and the cache is populated with the actual session indentifier being used and the server name so that it can be looked up next time.

---

Configuration Gotchas

At this time, there are 4 conceptual configuration models. This feature only really applies to one when considering the proxy (LineRate) terminated protocols. They are:

1. HTTP Virtual IP (TCP+HTTP termination)
2. HTTP Virtual IP with attached SSL Profile (TCP+SSL+HTTP termination)
3. TCP Virtual IP (TCP termination)
4. TCP Virtual IP with attached SSL Profile (TCP+SSL termination)

Explanations

#1 N/A: No SSL session identifiers exist, so it is obviously not important here.

#2 OFFLOAD: SSL termination exists, but it is terminated by LineRate. The persistence to the Real Server will work, but the server offload of the SSL overhead is not achieved. This is not the intended usecase, but persistence will work.

#3 GOAL: SSL termination may exist, and is terminated by the server. To LineRate the application layer traffic is unterminated. This configuration represents the best possible server offload and is the goal of the feature.

#4 OFFLOAD: SSL termination exists, but it is terminated by LineRate. The persistence to the Real Server will work, but the server offload of the SSL overhead is not achieved. This is not the intended usecase, but persistence will work.

Note: "OFFLOAD" cases #2 and #4 are great use-cases for LineRate because of its outstanding SSL performance, but those are not the goal of this specific feature.

---

See my article on the actual performance results over here.

---