RE: [load balancing] SSL Session ID Load Balancing

From: Cabral, Ken (kcabralIZZATCalence.com)
Date: Tue Feb 05 2002 - 15:28:31 EST

  • Next message: Stephane Litkowski: "Re: [load balancing] CSS hangs after 16Mb of traffic into GE port for transparent proxies"

    The combination of load balancing and statefull, secure applications creates
    an issue which typically requires additional capitol to fix. Here are some
    options for you to consider.

    1) Create a hot stand-by configuration where 1 server handles all of the
    traffic until it has an issue. Then the back up server will service all of
    the traffic.

    You will be sacrificing scalability and it may cost you to upgrade the
    server to be able to handle the load, but it may be a good short-term
    solution.

    2) Get the application team to push their state information to a shared,
    back-end database.

    This is probably the most expensive solution for existing applications to
    migrate to.

    3) Invest in an SSL Acceleration device.

    You can load balance the SSL accelerators via port 443
    Note: 1) Configure the load balancer to perform the TCP hand shake with the
    client.
            2) Configure SSL ID persistence on the SSL accelerators so that you
    can minimize the performance hit to the browser.

    Once the traffic is decrypted you can make the persistence decision based on
    cookie, etc.
    Please note that the load balancer with have to make 2 load balancing
    decisions for each request.

    I hope this helps.

    Ken C

    -----Original Message-----
    From: Tim Maestas [mailto:lbIZZATdnsconsultants.com]
    Sent: Tuesday, February 05, 2002 9:42 AM
    To: lb-lIZZATvegan.net
    Subject: Re: [load balancing] SSL Session ID Load Balancing

            Yes that sounds correct. SSL Session ID is pretty
            useless these days for maintaining persistence. If
            you are terminating SSL on your load balancers, doing
            cookie based persistence is probably your best bet.
            If you are not terminating on the load balancer and
            are encrypted all the way through, you are pretty
            much stuck with source ip based persistence, which
            basically sucks if you have lots of clients coming
            through proxies.

    -Tim

    On Tue, 5 Feb 2002, Allan Liska wrote:

    >
    > Hi all,
    >
    >
    > I am trying to develop a definitive policy for SSL Session-ID based load
    > balancing, and I am wondering if you all can help, because there seems to
    > be a lot of confusion.
    >
    > This is my understanding of how the process works, and the problem with
    > the Microsoft bug, if I am missing anything, please let me know:
    >
    > 1. A client initiates a session with a server.
    > 2. The client and the server share the following information:
    > Protocol Version
    > Session ID -- Generated by the Client
    > Cipher Suite
    > Compression Method
    > ClientHello.random
    > ServerHello.random
    > 3. After the hello session has completed, the server sends its certificate

    > to the client.
    > 4. In subsequent transactions, the server will use the SSL Session ID to
    > track session information with the client.
    >
    > In the case of the browsers listed here:
    >
    > http://support.microsoft.com/default.aspx?scid=kb;en-us;Q265369
    >
    > The SSL session ID is regenerated every 2 minutes, which creates a new
    > session. Making it possible for a client to lose persistency if the site
    > is being load balanced.
    >
    >
    >
    > Does all of this sound correct?
    >
    >
    > Thanks!
    >
    >
    > allan
    >
    >

    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com
    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com



    This archive was generated by hypermail 2b30 : Tue Feb 05 2002 - 15:37:45 EST