Cookie-Based Persistence

Another more accurate mechanism to use is something that is unique to the user and is always used during communications between the client and server. Cookies are the mechanism used to achieve this. To understand this concept, let's first find out what cookies are and how browsers make use of them.

Cookies

A cookie is just another HTTP header. Every browser has the ability to use this information. It is stored in memory while the browser is operational and then can be copied to the hard drive of the user's device for later use. Cookies are text strings that consist of specific information set by the device issuing the cookie. They will have a name or ID and each will have a value. It is this value that is unique to each TCP session and can be used to differentiate between users. In addition, cookies will also have a date, time, and an expiration date. Cookies can also be embedded within the URI string and can be inspected by content-aware switches. The following is an example of a cookie stored on the hard drive of a PC:

 PREFID=0b8a58957b6eb7d0:TB=1:TM=1012536298:LM=1012536298:S=7tVGQN2iyDM Foocorp.com/1536261887833632111634322235948829469397* 

To further demonstrate the cookie location and value, Figure 7-4 is a trace of the HTTP header using the preceding cookie. The name (PREF ID) is typically used by the content switch to search on, and it is the associated value to the name that is used to create persistence.

Figure 7-4 Packet trace showing HTTP header with cookie information.

 Hypertext Transfer Protocol GET /search?client=navclient-auto&ch=51554150042&freshness_check=3Mpsk9VuX HTTP/1.1\r\n Accept: */*\r\n Accept-Encoding: gzip, deflate\r\n User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n Host: www.foocorp.com\r\n Connection: Keep-Alive\r\n Cookie: PREF=ID=656210d555a653:TB=1:TM=2029086665:LM=2029086665:S=qIL-CZYmB_o\r\n \r\n 

There are typically two types of cookiespermanent, and temporary. A permanent cookie has an expiration date and is used each time that particular site is visited. This cookie is stored on the local machine. A temporary cookie is used only for the duration of the session; in other words, only while the browser is open . Once shut down, that cookie is no longer valid and is deleted. Temporary cookies do not have an expiration date in order to differentiate themselves from permanent cookies.

Using cookies for persistence is an extremely compelling argument, as each session can be seen as unique regardless of the source IP address. We are now making decisions based on content and not just Layer 3 and /or Layer 4 information. However, one of the requirements when using cookies is to ensure that the server issues cookies back to the user or requests a cookie from a user on initial connection. This process will require liaison with the application development team and will normally require changes to the server setup. In some instances, this is not possible or practical. To overcome this, content switches are able to insert and strip out cookies on sessions to and from the user without the server being aware of this. This allows the network administrator to control the environment and not rely on server software changes to aid in the quest for cookie persistence. One key element here is that the browser needs to be set to accept cookies. This can be turned off on browsers and is an individual choice, dependent on your security required. If a browser does not accept cookies, the best mechanism for persistence is to use IP address hashing.

Before we go any further, let's look at the steps involved for cookie persistence when a client connects to the VIP. This is a typical setup and would be used even if a content switch were not installed to provide load balancing.

1. The user and server set up a TCP three-way handshake via the content switch VIP.

2. The user sends an HTTP GET to the VIP.

3. The content switch examines the request, confirms that there is no session information pertaining to this session, and selects a server based on the load balancing metric set for that group .

4. The server responds to the request and inserts the cookie in the return packet.

5. The content switch examines the cookie and inserts the session into the session table, including the server that responded. If cookies are to be inserted or rewritten by this switch, this would occur at this point as well.

6. All subsequent sessions with that cookie value will be sent to the same server, thus maintaining persistence.

A point to remember is that delayed binding, also known as TCP splicing, will be enabled when a content switch is used, because the switch needs to determine what content is being requested before sending a user to the selected server. Delayed binding is discussed in more detail in Chapter 6, Content-Aware Server Load Balancing .

Cookie Types

In most content switches, there are three types of cookies used for persistence:

• Temporary mode

• Permanent mode

• Insert mode

Let's first look at Temporary mode, where a temporary cookie is used only for the duration of the session and expires on shutdown of the browser. These cookies are not stored locally on the user machine and are issued each time a user attaches to a server. Therefore, each cookie value could be different on each visit to the site. This requires that the server be set up to issue cookies on request. Once the cookie has been issued, the content switch checks for the cookie ID and ensures that subsequent cookies are sent to the selected server.

Permanent mode allows cookies to be stored on the user machine. The duration for which they are stored is dependent on the cookie expiration date. Expiration dates are set by the server administrator for the servers that issue cookies. The date can be any length from a few hours to many years . This is beneficial when using applications or services in which the users will need to take one of the following actions:

• Renegotiate their connectivity

• Resubmit certain information

• Provide further payment to continue enjoying access

Insert mode is unique to content switches and can be implemented by the network administrator without input from the server administrators. The reason for this is that the cookie is inserted when the session leaves the switch back to the user and is stripped out on the subsequent return. The server never sees this cookie and as far as it is concerned , the cookie never existed. Obviously, Insert mode places additional overhead on content switches, as they need to inspect every packet and manipulate it on ingress and egress. Insert mode supports both temporary and permanent cookies.

Cookies in Action

Using cookies is an extremely powerful approach that allows for a more granular view of content switching. Cookies can be used to single-handedly allow the administrator to determine different levels of access, performance, and status based on user cookie values. This gives the administrator the ability to create different services and revenue streams using cookies. Figure 7-5 demonstrates the ability to assign different class or service levels to each user. The level of service purchased (or granted) can be associated to cookie values; in this case, bronze, silver, and gold cookies are used, with bronze being the basic service and gold the premium. Dependent on the value of the cookie issued during login, the user is granted access rights and privileges commensurate with the level of service purchased.

Figure 7-5. Cookies enable us to differentiate services to specific servers based on the uniqueness of the cookie. It is the cookie that is unique to each user.

However, when using cookies as a persistence mechanism we need to be able to detect the cookie within the HTTP header or within the URL. This is done by parsing the packet and looking, from the HTTP header onward, for the cookie value. Parsing is explained in more detail in Chapter 6. This works great for HTTP applications, but we break the model when using HTTPS. The reason for this is that with HTTPS, the data portion is encrypted and the cookie ID that we use to associate the value is no longer visible. Figure 7-6 shows why this occurs.

Figure 7-6. Using cookies with SSL brings its own challenges, as SSL has encrypted the very thing we want to inspect.

Obviously, persistence is no longer possible so we are left with two options: IP address hashing or SSL Session ID. We have seen the drawback of using hashing with mega proxies, so SSL Session ID is an alternative.