The value inside a BIG-IP persistence cookie is one topic; how BIG-IP places and manages that cookie is another, and it is governed by the cookie method and the profile settings.

The four methods

BIG-IP can produce the persistence cookie in four ways:

  • Insert is the default and most common. BIG-IP adds its own Set-Cookie to the server's response and reads it back on later requests. The backend does not need to know anything about it.
  • Rewrite has the server send a cookie with a blank value, and BIG-IP fills in the persistence information. This needs cooperation from the application and is rarely used.
  • Passive has BIG-IP read a cookie the server itself sets, without inserting one. The application owns the cookie; BIG-IP only interprets it.
  • Hash keys persistence on a hash of an existing cookie's value, useful when an application cookie already identifies the session.

Insert covers the large majority of deployments because it works without touching the backend.

The settings that matter

A cookie persistence profile also controls the cookie's operational properties. The cookie name can be customized. The expiration decides whether it is a session cookie (gone when the browser closes) or a timed cookie that persists for a set duration. Most importantly for safety, the profile can set the httponly and secure flags: httponly keeps the cookie out of reach of page scripts, and secure stops it being sent over plain HTTP. Together with the encryption option, these are what turn a cookie that would otherwise leak backend details into one that is safe to hand a browser.

Why it is worth setting deliberately

The default insert method with an unencrypted, unflagged cookie is exactly the configuration that exposes pool-member information, as the disclosure and encoding articles describe. The operational settings are the other half of closing that gap: enabling encryption protects the value, and setting httponly and secure protects the cookie in transit and in the browser. Choosing the method and the flags on purpose, rather than accepting the defaults, is what makes cookie persistence both work correctly and stay safe.

Persistence outlives the pool member

A persistence record is a promise to keep sending a client to the same member, and it is stronger than most people : a member marked down does not automatically release the clients pinned to it.

What happens next depends on configuration rather than intuition. The connection may be re-balanced, or it may be refused, and the difference between those two outcomes during an incident is the difference between a degraded service and an outage for a subset of users who cannot understand why everyone else is fine.

Test the failure, not the feature. Persistence working is easy to observe; persistence releasing correctly when a member fails is the behaviour that matters, and it is the one nobody checks until it is load-bearing.

This series, in order

This article opens the series BIG-IP persistence cookies. It covers the four ways the cookie gets there and the profile settings around it; the parts then read the cookie itself, decode its four formats, weigh what it discloses and close the leak.

  1. BIG-IP Persistence Cookies: What They Are and Why They Leak. Why a BIG-IP inserts a BIGipServer cookie, what the value encodes, and why the default form hands out an internal address and port.
  2. The Four BIG-IP Cookie Encodings, Byte by Byte. The four unencrypted encodings, each with a worked decode: reversed address bytes, a byte-swapped port, route domains, IPv6.
  3. What a BIG-IP Cookie Tells an Attacker. A textbook information disclosure: internal addresses, ports, pool size and route domains, and how scanners harvest them.
  4. Closing the Leak: BIG-IP Cookie Encryption. Encrypting the cookie, what the encrypted value looks like, and the hashing and naming options beside it.