Solved: ACE 3.0(0) SW / LB with SSL Session-ID

Yury Shefer · ‎09-15-2008

Hello!

I want to use "SSL Session-ID" sticky method in load-balancing, but can't find any info about it in 3.0(0)A1(2) sw configuration guides. Where i can find info about it? Or this method is supported only in old A2(1.0) release?

Thanks.

Gilles Dufour · ‎09-15-2008

SSL Session ID Sticky to ensure Client Persistence

1. Demonstrate the ability to provide stickiness using SSL

Session ID. To do this you will need to the Generic Protocol Parsing

framework on ACE. With the right regular expression you will be successful!!

2. Before you begin to configure the SSL Sticky group, be sure that

you have allocated resources to the sticky group. Note this done in the

Admin context.

resource-class cart

limit-resource all minimum 0.00 maximum unlimited

limit-resource sticky minimum 1.00 maximum equal-to-min

context Lab-Cart-11

allocate-interface vlan 211

allocate-interface vlan 411

member cart

3. Create an SSL-v3 sticky group and associate the serverfarm. Good

idea to configure a sticky timeout value. This specifies the period of time

that the ACE keeps the sticky information in the sticky table. Note the ACE

resets the timer each time ACE opens connections matching that entry. Also

configure the Layer 4 sticky parameters for 32 bytes session ID.

sticky layer4-payload ssl-v3

timeout 600

serverfarm HTTPS-FARM

response sticky

layer4-payload offset 43 length 32 begin-pattern "\x20"

When a new session is established between client and server, the server

generates a session id. The session id is an arbitrary sequence of bytes.

The length of the session id is 16 bytes for SSLv2 sessions and between 1

and 32 bytes for SSLv3/TLSv1. The session id is not security critical but

must be unique for the server. Additionally, the session id is transmitted

in the clear when reusing the session so it must not contain sensitive

information.

4. Create a class-map to match the layer 4 payload.

class-map type generic match-any SSL-v3-32

2 match layer4-payload regex "\x16\x03\x00..\x01.*"

3 match layer4-payload regex "\x16\x03\x01..\x01.*"

5. Create a new generic load balance policy map and assoiciate the

sticky-serverfarm understand the class.

policy-map type loadbalance generic first-match SSL-v3-Sticky

class SSL-v3-32

sticky-serverfarm ssl-v3

6. Change to the client-vips policy map to represent the new

SSL-v3-Sticky policy you just created

policy-map multi-match client-vips

class VIP-HTTPS

loadbalance vip inservice

loadbalance policy SSL-v3-Sticky

loadbalance vip icmp-reply active

7. Verify the VIP is accessible by trying to hit the VIP.

8. View the connection using the show cons command.

Pod1-ACE/Lab-Cart-11# show conn

total current connections : 1

conn-id np dir proto vlan source destination

state

----------+--+---+-----+----+---------------------+---------------------+---

---+

10 1 in TCP 211 209.165.201.11:1115 172.16.11.190:443

ESTAB

-- - - -- -- -- -- --

9. Interesting I can see that the first connection has been setup. Why

is ACE not load balancing the connection to the server?

10. Great I need to configure a L7 parameter map with a max parse-length

parameter-map type generic SSL-v3

set max-parse-length 70

11. Associate the parameter map to the client-vips policy map

policy-map multi-match client-vips

class VIP-HTTPS

loadbalance vip inservice

loadbalance policy SSL-v3-Sticky

loadbalance vip icmp-reply active

appl-parameter generic advanced-options SSL-v3

12. Verify the VIP is now accessible by trying to hit the VIP.

View solution in original post

Gilles Dufour · ‎09-15-2008

SSL Session ID Sticky to ensure Client Persistence

1. Demonstrate the ability to provide stickiness using SSL

Session ID. To do this you will need to the Generic Protocol Parsing

framework on ACE. With the right regular expression you will be successful!!

2. Before you begin to configure the SSL Sticky group, be sure that

you have allocated resources to the sticky group. Note this done in the

Admin context.

resource-class cart

limit-resource all minimum 0.00 maximum unlimited

limit-resource sticky minimum 1.00 maximum equal-to-min

context Lab-Cart-11

allocate-interface vlan 211

allocate-interface vlan 411

member cart

3. Create an SSL-v3 sticky group and associate the serverfarm. Good

idea to configure a sticky timeout value. This specifies the period of time

that the ACE keeps the sticky information in the sticky table. Note the ACE

resets the timer each time ACE opens connections matching that entry. Also

configure the Layer 4 sticky parameters for 32 bytes session ID.

sticky layer4-payload ssl-v3

timeout 600

serverfarm HTTPS-FARM

response sticky

layer4-payload offset 43 length 32 begin-pattern "\x20"

When a new session is established between client and server, the server

generates a session id. The session id is an arbitrary sequence of bytes.

The length of the session id is 16 bytes for SSLv2 sessions and between 1

and 32 bytes for SSLv3/TLSv1. The session id is not security critical but

must be unique for the server. Additionally, the session id is transmitted

in the clear when reusing the session so it must not contain sensitive

information.

4. Create a class-map to match the layer 4 payload.

class-map type generic match-any SSL-v3-32

2 match layer4-payload regex "\x16\x03\x00..\x01.*"

3 match layer4-payload regex "\x16\x03\x01..\x01.*"

5. Create a new generic load balance policy map and assoiciate the

sticky-serverfarm understand the class.

policy-map type loadbalance generic first-match SSL-v3-Sticky

class SSL-v3-32

sticky-serverfarm ssl-v3

6. Change to the client-vips policy map to represent the new

SSL-v3-Sticky policy you just created

policy-map multi-match client-vips

class VIP-HTTPS

loadbalance vip inservice

loadbalance policy SSL-v3-Sticky

loadbalance vip icmp-reply active

7. Verify the VIP is accessible by trying to hit the VIP.

8. View the connection using the show cons command.

Pod1-ACE/Lab-Cart-11# show conn

total current connections : 1

conn-id np dir proto vlan source destination

state

----------+--+---+-----+----+---------------------+---------------------+---

---+

10 1 in TCP 211 209.165.201.11:1115 172.16.11.190:443

ESTAB

-- - - -- -- -- -- --

9. Interesting I can see that the first connection has been setup. Why

is ACE not load balancing the connection to the server?

10. Great I need to configure a L7 parameter map with a max parse-length

parameter-map type generic SSL-v3

set max-parse-length 70

11. Associate the parameter map to the client-vips policy map

policy-map multi-match client-vips

class VIP-HTTPS

loadbalance vip inservice

loadbalance policy SSL-v3-Sticky

loadbalance vip icmp-reply active

appl-parameter generic advanced-options SSL-v3

12. Verify the VIP is now accessible by trying to hit the VIP.

RAMAN AZIZIAN · ‎03-15-2010

Hello,

Could you kindly breakdown the below command(s) and what is it looking for?Is that a pattern within the SSL session ID for V3 and TLSV1?

class-map type generic match-any SSL-v3-32

2 match layer4-payload regex "\x16\x03\x00..\x01.*"

3 match layer4-payload regex "\x16\x03\x01..\x01.*"

Thanks,

raman

ppalmerjr · ‎07-25-2010

Did you ever get the answer to the breakdown of the string in the generic class map? I'm having issues understand those.

Thanks

ppalmerjr · ‎07-29-2010

Anyone?

Thanks in advance!

Gilles Dufour · ‎07-30-2010

2 match layer4-payload regex "\x16\x03\x00..\x01.*"

This means match the following bytes 0x16 0x03 0x00 ANY ANY 0x01

3 match layer4-payload regex "\x16\x03\x01..\x01.*"

This means match the following bytes 0x16 0x03 0x01 ANY ANY 0x01

The 0x16 indicates this is a handshake packet. 0x0301 indicates this TLSv1.0 and 0x0300 indicates SSL v3

Hope this helps.

Gilles.

yves.haemmerli · ‎09-29-2010

Hi Gilles,

I come back on this thread as I have a fundamental question/comment in regard to stickyness using the SSL Session-ID. I don't understand how it can work actually...

Background :

As far as I understand, when a client wants to establish an SSL session with a server, it sends a first Client Hello, in which the session-ID length is set to zero. Then, the server sends a Server Hello with the session-ID set to a 32 byte value for SSLv3. Then, after the handshake is completed, the client and the server communicate via the established TCP session on port 443. As far as I also known it can be that the SSL handshake is renegotiated every two minutes, hence creating another Session-ID as well.

My concern is to be analyzed in 3 scenarios :

Case 1 : The ACE does not terminate the SSL session and the SSL session is permanent between the client and the server

In this case, the ACE has to select a real server at TCP session establishment time. Then, as long as the TCP session is established, all packets are directed to the selected server. So, if the SSL session is permanent, there is no stickyness requirement I think ?

Case 2 : The ACE does not terminate the SSL session and the SSL session is NOT permanent between the client and the server

In this situation, the ACE cannot stick the client to a real server because he has to select a server at TCP session establishment time. So, where is stickiness with session-ID useful here ?

Case 3 : The ACE terminates the SSL session

In this case, the session-ID is only valid between the client and the ACE itself. Then, it cannot be used for stickiness with the real servers.

I am maybe wrong, could you give me your comments ont that question ?

Thank you in advance,

Yves