Forum Discussion

Alan_Evans_1020's avatar
Icon for Nimbostratus rankNimbostratus
Sep 28, 2011

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




- Does not require persistence sync between units in HA pair




- 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




- 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




- 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




- Same as 2




- 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 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?







1 Reply

  • Hmmmm. Gotta love the shared hosting model. Adds that fun twist to everything. Personally, I'd say you've got it right with the first option. Cookie encryption should not add to much overhead to the transaction, since it's a simple encrypt, and as you said, built in natively.



    The other options are creative, fun, and ... have those cons + associated risks when it comes time to upgrade the devices (migrating irules usually works just fine, but once in a while, a command gets depricated, and you end up having to pull some rewrite magic)