Cookie persistence with encryption or Cookie Hash or iRule with Universal

I see three ways to get past this problem but I am wondering which will be most reusable. My company is a managed hosting provider and we have hundreds of HTTP/HTTPS virtual services on our F5s and do not want to have to make custom HTTP/Cookie profiles for each VS or customer.

 

 

1. Cookie Insert with static name + HTTP profile doing cookie encryption

 

Pros:

 

- Does not require persistence sync between units in HA pair

 

Cons:

 

- Extra CPU work for encryption (one article suggests that HTTP profile w/ cookie encryption is more efficient than HTTP::cookie encrypt)

 

2. Cookie Hash using something like JSESSIONID or PHPSESSIONID

 

Pros:

 

- Its passive, doesn't expose any additional information to client

 

- Side effect of letting the server determine when persistence is necessary by choosing when to send session cookie

 

- Could easily deploy consistently across many VS

 

Cons:

 

- Requires persistence synchronization between HA units to survive failover

 

- Does not work if VS has webserver serving PHP and Java

 

- iRules are executed on general CPU and are an interpreted language

 

3. iRule to hash JSESSIONID and/or PHPSESSIONID with Universal Persistence

 

Pros:

 

- Same as 2

 

Cons:

 

- Same as 2 with exception of allowing hashing of PHPSESSIONID and JSESSIONID in one request

 

 

Because we run multiple customers on shared F5 hardware we are very careful about protecting the general CPU on our devices. All three of these options *should* be pretty reasonable on CPU usage but items 2 and 3 could be a bit higher than 1 since its presumably implemented in TMM in native code instead of iRule.

 

 

See http://devcentral.f5.com/wiki/iRules.HTTP__cookie.ashx for the note about HTTP profile cookie encryption vs HTTP::cookie encrypt.

 

 

Can anyone see any other pros/cons or for that matter options that I have missed?

 

 

Regards,

 

-Alan