Tuesday, March 24, 2009

Need for Third party certification

Are there any third party certifications for the load balancers/ADCs?

I came across Tolly group which conducts tests when the vendor
equests them. That too, Tolly group just concentrates on a given set
of tests and will not cover entire box and features wide. And there is
Gartner group classifying the lbs into magic quadrants based on the
feature set but does not depend on the test results.

The LB market lacks a genuine third party certification like NSS for
Intrusion prevention systems.

LBs are now ADCs, with lot of more complex jobs to do. These days,
ADCs are pitched against application firewalls and protocol anomoly
detection systems. These products (application firewall and IDP)
always go for third party certification. These certifications gives
confidence to the customer that these products are effective against
zero day attacks, known vulnerabilities or exploits. Since, ADC are
also entering that segment, they need third party certifications.
These ADCs are front ending the servers and these devices
themselves should not be vulnerable to attacks. These third party
will also certify how hardend is the ADC OS and its
proxy/applications.

I suggest either the vendors go with groups like NSS Labs or ask
Tolly group to come out with complete set of test cases for ADCs.

The third party certifications will help the customers to choose
the best ADC based on the performance and test results rather
than carried away with the feature rich marketing terminology.

Monday, March 23, 2009

Implementation suggestion for LBs to use in Virtual Data Center (VDC)

Virtual Data Center (VDC) uses virtualization technologies in the
data centers. Virtualization platforms like Xen, vmware, HyperV
from Microsoft are used in the VDCs. With increasing number of
subscribers, and many relying on the cloud data centers, there
will be IP address exhaustion for internal servers allocation.

Fortunately, the VDCs with the help of virtualization platforms
can have overlapping IP addresses. The subscribers are given
freedom to choose their own set of IP addresses. In such
setups, the network devices should be programmed such a way
that they identify the server not just by IP address ,its based
on subscriber id too.

Lets take an example. The data center has two subscribers.
There is a load balancer before the real servers. Subscriber A
has VIP1 and the subscriber B has VIP2. But they chose to
have real servers in 10.x.x.x network and chose same IPs
for their real servers.


-------------10.1.1.1(Real 1)
-------------10.1.1.2(Real 2)
VIP1 ------------10.1.1.3(Real 3)

VIP2-------------10.1.1.1(Real 4)
_________10.1.1.2(Real 5
_________10.1.1.3(Real 6)


In the above setup, the load balancer has to distinguish
between real servers based on the subscriber. Traffic
coming to VIP1 must be load balanced between real 1,
real 2 and real 3. While the traffic to VIP2 must be sent
among real 4, real 5 and real 6.

In order to achieve the above setup, the load balancers
must have intelligence to classify the traffic between
subscribers. This can be achieved by allocating a different
vlan id per subscriber. Subscriber A will be allocated a
vlan-a and the other subscriber B should be given a different
vlan, vlan-b. The load balancer after taking a lb decission ,will
tag the packets with respective vlanid. Thus, the packet will
make to its destination.



/--------10.1.1.1(Real 1)
/---------10.1.1.2(Real 2) --vlan a
VIP1 ----------10.1.1.3(Real 3)

VIP2-------------10.1.1.1(Real 4)
\_______10.1.1.2(Real 5) --vlan b
\______10.1.1.3(Real 6)

- Should have different VLANs per subscriber. VLAN will be the
identification parameter for the subscribers.
- LB should be able to take same IP for different real servers and
associate with vlanid
- A different routing table per subscriber. The routing table should
consider vlanid for the route lookups or maintain a different
routing table per subscriber.


The load balancers should implement the above mentioned to
tune to the Virtual Data center and solve future problems.

Wednesday, March 11, 2009

Future talk - What ADCs need to replace IDP?

Few weeks back there was a question in load balancing mailing list.
"What is the difference between ADC and Load balancer?" I would say
the ADCs are next generation Load Balancers. ADCs are capable of
doing more jobs than just Server Load Balancing. The present generation
of ADCs are implementing
a) Application compression and optimization
b) Application validation by protocol anomaly detection
c) Improving network utilization by TCP connection pooling
d) XML parsing and validation

Some implementations went beyond and started application data
modification based on user inputs. In summary, the ADC products
are doing sort of doing application protection like Intrusion
Detection and Prevention devices
(IDP).

With all these features, ADCs became multi functional.
And, the market and experts too feels that its end of load balancing
and emerging ADC market.


First generation of load balancers were not using TCP stack.
They were not vulnerable to TCP/IP exploits and fortunately,
that way they gained huge performance with no stack and in some
cases Operating system overheads. The current generation load balancers
called ADC are running application proxies. The ADCs required
a network stack and as well as application intelligence to does the
application processing, compression, validation etc., All these
features now opened up many vulnerabilities. All the cross site
scripting (XSS), TCP vulnerabilties etc., now started appearing in
ADC products.
Check out the BigIP and Netscaler vulnerabilities. ADCs should
be written following secure coding standards and not leave any scope
for buffer overflow and other stack exploits and evolve further.

ADC does have protocol anomaly detection. But, its not as classic
as IDP devices. ADC do have the potential to replace the IDP provided
they implement the following to evolve into next league
a) Statistical anomaly detection
b) Protocol anomaly detection algos
c) Signature based detection
d) Automatic Live updates for the signatures and software updates
e) Useful reporting to detect zero day attacks

Most of the ADCs in the market do have protocol anomaly. That is not
sufficient but should also have live signature updates to stop newly
found application exploits before the admins patch up the server
applications. Currently, admins still depend up on the IDP to prevent
from exploits even with ADCs having application firewalls and protocol
anomaly detection. There is not much time we would see ADCs competing
with IDP devices..

Application Delivery Controller and cloud integration

My colleagues ask me this question "what is needed to integrate
application delivery controllers in cloud computing data centers?"
I happen to read about a switch vendor claiming cloud computing ready
layer2 switches. After going through their website, I felt there
is nothing special they do when compared to their competitors but
market it with eye catching cloud computing terms.

Coming to the load balancer market, vendors show up to the customers
that application intelligence, optimization, providing complex
configuration tools are needed for cloud computing. There are some
specialized devices to do those jobs. Let the application delivery
controller not mess up with applications by talking its language.


In my opinion, any network vendors claiming cloud ready should
have the following.


Scalability: Generally, load balancers have up to 1024 real servers.
That is not enough to position a load balancer in cloud data centers.
There will be several thousand of servers running. The load balancer
must be scalable to several thousand of real servers, virtual servers,
IP interfaces etc.,
The load balancer must not be a bottle neck to the cloud performance.
For example, the load balancer should be able to do health checks for
thousands of servers with out its CPU going 100%
It should be able to support a huge routing table and session table to
support huge traffic that is expected in cloud data centers.


Ease of configuration: The load balancers must support a simple XML
interface to allow external management applications configure the
load balancer settings. For example, many LB vendors came up with
applications to work with vmware's virtual Center(VC). Those tiny
applications work with VC and adds new servers to server farm when
there is huge traffic. Cloud data centers does not just have load
balancers and servers. It comprises of many network devices and
all these network devices are to be managed in a simple way.
Instead of independently making a decision to add new server to
server farm, load balancers must provide a simple XML interface
for more capable external applications that can understand and talk
to much more network devices. Load balancers must evolve to be
virtualization vendor independent.


Virtualized CLI and reports: The CLI must be remotely administered
and integrated with cloud computing management tool of choice. CLI
should be virtualised and subscriber of cloud data centers can see
only their settings as if a dedicated box for them. The reports
generated must be customized per subscriber. That gives easiness
for the administrators to manage it easily. For example, the admin
may would like to decommission it after a specific job is completed.
If the reports are customized then it enables the admins to calculate
the cost involved per subscriber based on the usage of the services,
bandwidth consumed etc.,

Above explained are few things that are mandatory for the load balancers
to immediate deploy them in cloud computing data centers.