| Now that we have completed our discussion of persistence in the Internet, let's take a look at how our favorite company, Foocorp, Inc., would deploy these techniques. When designing a network to support IP-based applications, it is important to understand the criteria of the application; in other words, is user persistence required? Foocorp, Inc. developed an application that requires a user to log in, specify the information they require and then search through the database based on the required criteria. The problem is that they offer a business-to-business service as well as a consumer service. Typically, the business-to-business users are hidden behind a proxy and require different levels of service to that of the consumer. Moreover, the business users may work from home so there is no way of knowing who is who in this scenario. In addition to this, the existing information and service levels cannot be jeopardized by the deployment of SSL for security and authentication. The IT folks at Foocorp, Inc. have decided to use an SSL offload device, as they realize that this provides an increase in performance as well as scalability should this service become popular. They have also selected one that can be deployed outside the data path . Deploying Persistence Let's look at the steps needed for a successful implementation. -
Install the SSL offload appliance(s). These should typically be 100Mbps or gigabit connected. Dependent on available port density, this can be connected to a Layer 2 device. They must, however, only have one path, and that is through the content switch. -
Create a CSR and send the CSR off to a CA for signing. -
On receipt of the certificate, copy it into the device and associate it with the required domain name and IP address. -
If backend encryption is required, ensure that the servers are listening on the correct TCP port and that that service is active. -
Configure redirection policies or filters on the content switch to redirect the SSL connections to the SSL offload appliance. -
If the content switch is not acting as a proxy, redirection policies or filters will need to be created on the content switch to redirect responses back to the SSL offload appliance. If this mechanism were not in place, traffic would be routed directly back to the user either on the wrong TCP source port or with the wrong SIP, which would cause the user to be reset. -
If health checks are being performed from the content switch, ensure that responses reach the switch by inserting an allow policy or filter before the redirection policy or filter used for the return packets. This policy or filter must be specific to the IP address of the Web switch; otherwise , all packets will be allowed and will not hit the redirection policy or filter, thus causing the site to fail. -
Configure the cookie persistence mode required; Temporary, Permanent, or Insert mode on the content switch, remembering to ensure that the cookie name and the size of the cookie are determined. -
If server changes are required to implement cookie persistence, remember to involve the server administrator in order to get the necessary information from them. -
Once these steps are completed, the site should be operational. We can see how this has been achieved by Foocorp in Figure 7-9. Figure 7-9. SSL off load and persistence.  By deploying SSL offload and persistence, Foocorp has been able to achieve the following: -
Increase site response time for online transactions -
Delay the capital outlay for server upgrades to cope with SSL transactions -
Provide true end-to-end application security from any geographical location -
Ensure that users remain connected to the server for the duration of the transaction -
Control client access to and from the site -
Provide end-to-end encryption for key services -
Use Layer 7 information on encrypted sessions By deploying a dedicated appliance to perform process intensive tasks such as SSL, Foocorp has managed to easily and effectively manage their site for future growth.  |
