TLS Caching Explained on BIG-IP

1. Preliminary Information

In one of my discussions with a couple of community members, we discussed the use of TLS caching as a powerful way to improve performance, TLS-wise. With the increase of Internet traffic globally due to COVID-19, this is an important concept to grasp.

This is the topology I used to perform the tests:

Both client and server SSL profiles have cache-size set to 1:

If you just want to know how TLS Caching works, move straight to Lab Test Results section.

2. What we need to know upfront

First off we should learn that there is a global db variable for tmm's cache size with min and max values:

TMM is BIG-IP's forwarding plane daemon.

The other things we should be aware of:

tmm.ssl.cache is the global value enforced per TMM, not split among all tmms.
cache-size is a local value per virtual server
Setting SSL Profile's Cache Size option (cache-size in tmsh) to zero (0) disables SSL session caching
SSL Profile's Cache Size is also enforced per TMM
When either Cache Size or the value of tmm.ssl.cache limit is reached on a given tmm (whichever is reached first), oldest entry is removed (evicted) from SSL cache to give room to new entry (reference: https://support.f5.com/csp/article/K6767).
tmm.ssl.cache is configurable from 11.5.0+ (reference: https://support.f5.com/csp/article/K16303).

3 Lab Test Results

For Client SSL profile, BIG-IP uses Session ID or Session Ticket to look up TLS session entries in local SSL cache.
If Session ID or Session Ticket is changed, it is a cache miss.
For Server SSL profile, BIG-IP uses back end server's IP address and destination port for the lookup in order to find corresponding Session ID or Session Ticket to be presented to back-end server so session can be resumed.

Note: To learn about the difference between Session ID and Session Ticket, please refer to this article here.

4. Client SSL behaviour

In the beginning cache is clear:

I then send first request making sure I save session information locally:

New TLS Cached Session

We then see first cache entry populated with 1 lookup but no hits yet since this is new cache entry:

TLS Cache Hit

Next, I send 2nd request reusing the same SSL session using OpenSSL:

And fair enough we see our first cache hit (note that lookup also increases):

TLS Cache Overflow

I'm now going to create a new TLS session with no session reuse:

And now we see first overflow because it is a cache miss and as the max cache size is set to 1.

The new cache entry overwrites oldest cache entry:

Now let's move on to Server SSL profile.

5. Server SSL behaviour

New TLS Cached Session

Sent first request:

The usual entry added to cache and 1 lookup:

TLS Cache Hit

Sent 2nd request intentionally using curl again (not reusing previous TLS session information):

But we still see a cache hit!

The reason is because on Server SSL side BIG-IP no longer uses Session ID/Session Ticket information to to retrieve cached entry. Remember, on Server SSL side, BIG-IP is the client!

Instead, BIG-IP uses destination server and port to retrieve previously stored session ID/Session ticket and send it over to back-end server in Client Hello message in order to resume session.

That's why we had a cache hit here!

TLS Cache Overflow

For this particular overflow test, I've added a 2nd pool member to our pool (172.16.199.32) because Server SSL profile uses destination IP and port to retrieve cached TLS session, which wouldn't change if we use the same pool member, would it?