Development and General

F5 Friday: What’s Inside an F5?

Lori MacVittie — Fri, 10 Feb 2012 12:00:00 GMT

Is it Linux? Is it third-party? Is it proprietary? Isn’t #vcmp just a #virtualization platform? Just what is inside an F5 BIG-IP that makes it go vroom?

Over the years I’ve seen some pretty wild claims about what, exactly, is “inside” a BIG-IP that makes it go. I’ve read articles that claim it’s Linux, that it’s based on Linux, that it’s voodoo magic. I’ve heard competitors make up information about just about every F5 technology – TMOS, vCMP, iRules – that enables a BIG-IP to do what it does.

There are two sources of the confusion with respect to what’s really inside an F5 BIG-IP. The first stems, I think, from the evolution of the BIG-IP. Once upon a time, BIG-IP was a true appliance – a pure software solution delivered pre-deployed on pretty standard hardware. But it’s been many, many years since that was true, since before v9 was introduced back in 2004. BIG-IP version 9 was the beginning of BIG-IP as not a true appliance, but a purpose-built networking device. Appliances deployed on off the shelf hardware generally leverage existing operating systems to manage operating system and even networking tasks – CPU scheduling, I/O, switching, etc… but BIG-IP does not because with version 9 the internal architecture of BIG-IP was redesigned from the ground up to include a variety of not-so-off-the-shelf components. Switch backplanes aren’t commonly found in your white-box x86 server, after all, and a bladed chassis isn’t something common operating systems handle.

TMOS – the core of the BIG-IP system – is custom built from the ground up. It had to be to support the variety of hardware components included in the system – the FPGAs, the ASICs, the acceleration cards, the switching backplane. It had to be custom built to enable advances in BIG-IP to support the non-disruptive scale of itself when it became available on a chassis-based hardware platform. It had to be custom built so that advances in internal architectures to support virtualization of its compute and network resources, a la vCMP, could come to fruition.

The second source of confusion with respect to the internal architecture of BIG-IP comes from the separation of the operational and traffic management responsibilities. Operational management – administration, configuration, CLI and GUI – resides in its own internal container using off-the-shelf components and software. It’s a box in a box, if you will. It doesn’t make sense for us – or any vendor, really – to recreate the environment necessary to support a web-based GUI or network access (SSH, etc…) for management purposes. That side of BIG-IP starts with a standard Linux core operating system and is tweaked and modified as necessary to support things like TMSH (TMOS Shell).

That’s all it does. Monitoring, management. It generates pretty charts and collects statistics. It’s the interface to the configuration of the BIG-IP. It’s lights out management. This “side” of BIG-IP has nothing to do with the actual flow of traffic through a BIG-IP aside from configuration. At run time, when traffic flows through a BIG-IP, it’s all going through TMOS – through the purpose and very custom built system designed specifically to support application delivery services.

This very purposeful design and development of technology is too often mischaracterized – intentionally or unintentionally – as third-party or just a modified existing kernel/virtualization platform. That’s troubling because it hampers the understanding of just what such technologies do and why they’re so good at doing it.

Take vCMP, which has sometimes been maligned as little more than third-party virtualization. That’s somewhat amusing because vCMP isn’t really virtualization in the sense we think about virtualization today. vCMP is designed to allow the resources for a guest instance to span one or multiple blades. It’s an extension of multi-processing concepts as applied to virtual machines. If we analogized the technology to server virtualization, vCMP would be the ability to assign compute and network resources from server A to a virtual machine running on server B. Cloud computing providers cannot do this (today) and it’s not something that’s associated with today’s cloud computing models; only grid computing comes close, and it still takes a workload-distributed view rather than a resource-distributed view.

vCMP stands for virtual CMP – clustered multi-processing. CMP was the foundational technology introduced in BIG-IP version 9.4 that allowed TMOS to take advantage of multiple multi-core processors by instantiating one TMM (Traffic Management Microkernel) per core, and then aggregating them – regardless of physical location on BIG-IP – to appear as a single pool of resources. This allowed BIG-IP to scale much more effectively. Basically we applied many of the same high-availability and load distribution techniques we use to ensure applications are fast and available to our internal architecture. This allowed us to scale across blades and is the reason adding (or removing) blades in a VIPRION is non-disruptive.

Along comes a demand for multi-tenancy, resulting in virtual CMP. vCMP isn’t the virtual machine, it’s the technology that manages and provisions BIG-IP hardware resources across multiple instances of BIG-IP virtual machines; the vCMP guests, as we generally call them. What we do under the covers is more akin to an application (a vCMP guest) being comprised of multiple virtual machines (cores), with load balancing providing the mechanism by which resources are assigned (vCMP) than it is simple virtualization.

So now you know a lot more about what’s inside a BIG-IP and why we’re able to do things with applications and traffic that no one else in the industry can. Because we aren’t relying on “standard” virtualization or operating systems. We purposefully design and develop the internal technology specifically for the task at hand, with an eye toward how best to provide a platform on which we can continue to develop technologies that are more efficient and adaptable.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,F5 Friday,vCMP,virtualization,BIG-IP,scalability,network,hardware,blog

The Potential Ramifications of Platform-Based Vulnerabilities on Cloud Computing

Lori MacVittie — Wed, 08 Feb 2012 13:26:00 GMT

#infosec #adcfw #cloud Alternate title: How to take out an entire PaaS cloud with one vulnerability

Apache Killer.

Post of Doom.

What do these two vulnerabilities have in common? Right, they’re platform-based vulnerabilities. Meaning they are vulnerabilities peculiar to the web or application server platform upon which applications are deployed. Mitigations for such vulnerabilities generally point to changes in configuration of the platform – limit post size, header value sizes, turn off some value in the associated configuration.

But they also have something else in common – risk. And not just risk in general, but risk to cloud providers whose primary value is in offering not just a virtual server but an entire, pre-integrated and pre-configured application deployment stack. Think LAMP, as an example, and providers like Microsoft (Azure) and VMware (CloudFoundry), more commonly adopting the moniker of PaaS. It’s an operational dream to have a virtual server pre-configured and ready to go with the exact application deployment stack needed and offers a great deal of value in terms of efficiency and overall operational investment, but it is – or should be – a security professional’s nightmare. It’s not unlike the recent recall of Chevy Volts – a defect in the platform needs to be mitigated. The only way to do it, for car owners, is to effectively shut down their ability to drive while a patch is applied. It’s disruptive, it’s expensive (you still have to get to work, after all), and it’s frustrating for the consumer. For the provider, it’s bad PR and negatively impacts the brand. Neither of which is appealing.

A vulnerability in the application stack, in the web or application server, can be operationally devastating to the provider – and potentially disruptive to the consumer whether the vulnerability is exploited or not.

STANDARDIZATION is a DOUBLE-EDGED SWORD

Assume a homogeneous cloud environment offering an application stack based on Microsoft ASP. Assume now an exploit, oh say like Post of Doom, is discovered whose primary mitigation lies in modifying the configuration of each and every instance. Virtualization of any kind provides a solution, of course, but introduces the possibility of disruption in the impact to consumer applications from the configuration change. A primary mitigation for the Post of Doom is to limit the size of data in a POST to under 8MB. Depending on the application, this has to potential to “break” application functionality, particularly those for which uploading big data is a focus. Images, video, documents, etc… These all may be impacted negatively, disrupting applications and angering consumers.

Patching, of course, is preferred, as it eliminates the underlying vulnerability without potentially breaking applications. But patching takes time – time to develop, time to test, time to deploy. The actual delivery of such patches in a PaaS environment is a delicate operation. You can’t just shut the whole cloud down and restart it after the patches are applied to the base images, can you? Do you wait, quiesce the vulnerable images and only force the patched ones when new instances are provisioned? A configuration-based mitigation, too, has these same issues. You can’t just shut down the whole cloud, apply the change, and reboot.

It’s a delicate balance of security versus availability that must struck for the provider, and certainly their position in such cases is one not to be envied. Damned if they do, damned if they don’t.

Then there is the risk of exploitation before any mitigation is applied. If I want to wreak havoc on a PaaS, I may be able to accomplish simply by finding one with the appropriate platform vulnerable to a given exploit, and attack. Cycling through applications deployed in that environment (easily identified at the network layer by the IP ranges assigned to the provider) should result in a wealth of chaos being wrought. The right vulnerability could take out a significant enough portion of the environment to garner attention from the outages caused.

Enterprise organizations that think they are immune from such issues should think again, as even a cloud provider is often not as standardized on a single application platform as an enterprise is, and it is that standardization that is at the root of the potential risk from platform-based vulnerabilities. Standardization, commoditization, these are good things in terms of many financial and operational benefits, but they can also cause operational risk to increase.

MITIGATE in the MIDDLE

There is a better solution, a better strategy, a better operational means of mitigating platform-based risks.

This is where the role of a flexible, broad-spectrum layer of security applies. One that enables security professionals to broadly apply security policies to quickly mitigate potentially disastrous vulnerabilities. Without disrupting a single running instance, an organization can deploy a mitigating solution that detects and prevents the effects of such vulnerabilities. Applying security policies that mitigate such vulnerabilities before they reach the platform is critical to preventing a disaster of epic (and newsworthy) proportions.

Whether stop gap or a permanent solution, by leveraging the application delivery tier of any data center – enterprise or cloud provider – such vulnerabilities can be addressed without imposing harsh penalties on applications and application owners, such as requiring complete shutdown and reboots.

Leveraging such a flexible data center tier insulates the platform from exploitation while insulating customers from the disruption required to mitigate immediately on the platform layer, allowing time to redress through patches or, at least, understand the potential implication to the application from the platform configuration changes required to mitigate the vulnerability.

In today’s data center, time is perhaps the biggest benefit afforded to IT by any solution, and yet the one least likely to be provided. A flexible application delivery tier capable of mitigating threats across the network and application stack without disruption is one of the few solutions available that offers the elusive and very valuable benefit of time. Providers and enterprises alike need to consider their current data center architecture and whether it supports the notion of such a dynamic tier. If not, it’s time to re-evaluate and determine whether a strategic change of direction is necessary to ensure the ability of operations and security teams to address operational risk as quickly and efficiently as possible.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,architecture,availability,cloud computing,virtualization,devops,threat mitigation,application delivery,blog

Desktop VDI May Be Ready for Prime Time but Is the Network?

Lori MacVittie — Mon, 06 Feb 2012 12:20:00 GMT

#VDI #quasar #mobile The proliferation of mobile devices is pushing VDI closer to being “the solution” of the year to resolve the increasing complexity – and costs – associated with consumerization.

Considering the innate differences between just the two most popular mobile operating systems – Android and iOS – gives rise to understanding how costly and complex an infrastructure might need to be to support both. It’s not at all unlike the issues with server virtualization. Management and delivery architectures require different solutions depending on the platform, so despite potentially costly investments to scale, organizations are often staying single-vendor with respect to its virtualization platform strategy.

Organizations had taken that approach – standardized on a single mobile platform – only to discover that employees blatantly ignored such mandates and began using whatever they brought from home. Worse, they expected support when applications didn’t work quite right.

Thus IT is stuck trying to figure out how to efficiently deliver, secure, and manage applications to multiple operating systems right now. Not tomorrow, not next week. Today.

VDI is thus rearing its head as a viable solution; one that promises consistency regardless of platform, without worry about Bob wanting to access corporate resources via his Internet-enabled HDTV. For the most part, experts and implementers deem VDI ready to meet the challenge. But what they haven’t asked, nor considered, is whether the network is ready for VDI.

Desktop Virtualization Ready for Prime Time

The appeal of VDI remains the same: it improves flexibility, simplifies administration and boosts security. What has changed are ongoing price drops and a growing need to seamlessly manage an IT infrastructure that includes desktops running Windows, Mac laptops using Apple OS X and mobiles devices using iOS and Android. In many cases, VDI streamlines data exchange and accessibility in an increasingly bring-your-own device (BYOD) IT world.

VDI OFFLOADS the PROBLEMS to the INFRASTRUCTURE

Interestingly enough, the problems with delivering applications to multi-endpoint environments do not actually disappear with the introduction of VDI. Oh, the problem of supporting every device under the sun is neatly resolved, but other problems quickly arise, and these are not necessarily easy problems to solve.

Roaming

The issue with roaming isn’t just that of a device roaming across service boundaries or WiFi networks, it’s roaming geographically. VDI deployments carry with them some strict and often constraining infrastructure requirements that are not easily overcome without the assistance of infrastructure. Typical network environments are ill-prepared to deal with not just the basic constraints but the resolution to those constraints. They lack the flexibility of an application delivery tier to mediate between roaming users and virtual desktop infrastructure.

A user that roams between two completely different network types may in fact appear to be two different network users from an IP perspective. While we know we must one day eliminate our dependency on IP addressees, today it remains a factor that must be addressed. Users who suddenly move from one network to another may cause undue stress along the entire infrastructure – but especially on VDI servers that maintain their understanding of users based on connections, which base their identification on IP addresses. A mediating connectivity layer such as an application delivery tier eliminates not the dependency, but the impact on the actual VDI servers and applications by becoming the endpoint and handling the possible volatility in device identification on behalf of the services, mitigating the impact by absorbing and managing it itself.
Network Impact on Performance

What, exactly, is the network over which the mobile device is connecting? Is it WiFi? Is it the mobile network? The network over which a device is connecting has a significant impact on performance, particularly from the perspective of the end-user. It isn’t so much a question of whether or not the network is fat enough, it’s whether or not the external (read: out of IT control) network is fat enough, or fast enough.

Latency is the biggest concern among networking pros considering a VDI deployment, according to an informal survey of 1,197 VMworld 2010 attendees conducted by storage vendor Xiotech and WAN optimization vendor Silver Peak. The vendors say 62% of respondents named latency as their top VDI network consideration.
A minority named other WAN-related issues as concerns, such as the ability to shape or prioritize traffic (7%) and bandwidth (6%).

-- VDI over the WAN: How latency affects virtual desktop performance

While WAN Optimization and similar technologies can certainly address issues when a WAN is involved, it won’t necessarily be of assistance when mobile devices experience issues over WiFi or mobile networks or any configuration in which there is no control over both endpoints. Yet the same network problems will plague these devices, and likely with more frequency than remote desktops over IT controlled WAN channels.
Scale of Dependent and Primary Services

Likely the most overlooked of all is the scalability of dependent network services. Simple things like NAT, like application access control, like network security infrastructure that must deal with the possibility that users will be logged in from several places at the same time, trying to access different resources. It’s the scalability of network security devices that suddenly must contend with connections coming from a wide variety of networks and locations, and must decide – quickly – which of those connections will be allowed, and which should – and must – be denied.

It’s also about the ability of applications themselves to scale when faced with suddenly very different network profiles that significantly impact the capacity and load on existing services. Applications that have performed well with capacity X suddenly perform poorly even though concurrent user counts have not changed. This is because the network characteristics may have changed in such a way as to change the way in which the applications are served. Users connecting over the LAN are able to receive content quickly and thus reduce the overall burden on server infrastructure by clearing queues and releasing connections that can be used by other users. Users connecting over mobile networks are not able to receive content as quickly and thus increase the burden on server infrastructure by receiving content more slowing and taking more time to complete a session. This reduces the capacity of server infrastructure and may require additional scaling to ensure consistent, acceptable performance levels across all device types and users.

Thus, while VDI may be ready for prime-time, and is certainly a valid solution to the problem of consumerization with respect to mobile device proliferation in the enterprise, the network may not be ready for VDI – regardless of endpoint form factor.

VDI, like server virtualization and cloud computing , will necessarily change the way in which we architect and ultimately view the network because of the very characteristics that make these technologies appealing – abstraction, elasticity, dynamism. These characteristics make it more difficult to deliver applications and services like VDI because of the volatility and diversity they introduce into the data center and impose on the network.

New architectural and technological solutions will be required in the network to manage such issues as they arise.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,mobile,VDI,virtualization,scalability,performance,network,optimization,blog

F5 Friday: New Services from F5 Ease Migration and Upgrades

Lori MacVittie — Fri, 03 Feb 2012 13:14:00 GMT

I get by with a little help from my friends…

While cloud and virtualization primarily focus on improving the provisioning process, there is a lot more to managing a data center and its critical components than just deployment. There’s upgrades – both software and hardware – and migration to new solutions as well as tweaking knobs and buttons to optimize and troubleshoot issues. While public cloud computing may alleviate much of the pain associated with forward movement, private and hybrid environments as well as traditional data center models must face the reality of dealing with these admittedly often tedious tasks.

It’s a foregone conclusion that new technology and devices like mobile, tablets, unified application delivery and cloud computing as well as an evolving threat spectrum put pressure on IT to maintain a healthy and modern set of services to ensure availability, performance, and security. As pressures increase on infrastructure services, vendors respond with new and or updated solutions to help IT combat the growing complexity of data center architectures.

But sometimes, IT needs a little help from its friends to get there, and that’s where professional service organizations enter into the picture.

One of F5’s top priorities is a world-class service organization. From implementation and ongoing support to migration and upgrades, our professional services organization continues to evaluate the technology landscape and address the most pressing issues facing IT through new offerings designed to ease those pain points introduced by a need to upgrade or migrate to new platforms.

New Services Offerings from F5

F5 is introducing three new services offerings that address many of these issues. Each assessment covers four phases: planning, analysis, a detailed report, and review with recommendations.

BIG-IP Local Traffic Manager (LTM) Upgrade Assessment

Understand Your Infrastructure’s Readiness for Change

The flexible infrastructures made possible by BIG-IP LTM can drive efficiencies, support business growth, and optimize new capabilities that become available as the infrastructure devices evolve. Nonetheless, version upgrades require planning and analytical validation that new functionality will align with the organization’s infrastructure vision.

The BIG-IP LTM configuration is assessed in four broad categories:

Platform, including current TMOS release level, device health, network configuration, and system monitoring and management

Availability, including HA configuration, active/standby preferences, network redundancy, connection mirroring, and persistence settings

Performance, including optimized service profiles, CPU throughput, simple F5 iRules scripting, virtual server types, and health monitors

Security, including secure socket layer (SSL) cipher strengths, port lockdown settings, and administrative access configurations

Firepass to BIG-IP Access Policy Manager (APM) Migration Assessment

Migrate to BIG-IP APM for Faster, Flexible Access

The rapid proliferation of mobile devices, an increasingly dispersed workforce, and the need to secure and optimize content delivery combine to make high-performance, high-concurrency remote access solutions crucial to organizations. Migrating now from a FirePass device to BIG-IP APM ensures your applications remain fast, secure, and available. BIG-IP APM provides a flexible, high-performance access and security solution within an agile infrastructure that will position your organization to effectively support today’s mobile workforce.

The F5 Professional Services consultant reviews your current FirePass configuration and conducts a high-level design discussion to understand the target architecture requirements for meeting your organization’s remote access needs. The configuration review includes analysis of web services, landing URIs, authentication method, certificates, master and resource groups, and network, portal, and application access.

Proactive Assessment

Assess Your F5 Infrastructure Agility

An F5 Proactive Assessment Service audits your F5® BIG-IP® products to ensure optimal configuration. Specifically, the Proactive Assessment Service reviews your current environment to uncover potential issues or areas for improvement and makes recommendations that help optimize F5 technologies. The result is an action plan designed to boost your BIG-IP platform performance, strengthen security, and increase availability.

Network configuration is assessed with a comprehensive review of infrastructure characteristics in five categories:

Operating system, including hotfix level and consistency within products and across BIG-IP device high-availability (HA) pairs

Architecture, including virtual servers, pools, network address translation, and address resolution protocol (ARP) settings

Security, including password policy, authentication methods, and network forwarding

Availability, including fail-over, mirroring, HA configuration, health monitors, and backup policies

Performance, including CPU performance graphs, memory consumption, and throughput

Another great self-service resource can be found in iHealth, which enables you to verify the proper operation of your BIG-IP system and ensure your hardware and software function at peak efficiency. New to iHealth is a comparison feature that can assist with assessments as well as troubleshooting. iHealth requires registration, but is a free service from F5 designed to ease the support process as well as providing organizations with the means to self-support when desired.

Additional Resources:

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,professional Services,BIG-IP,LTM,APM,iRules,iHealth,blog

The Cloud API is Pseudo-Consolidation of Infrastructure

Lori MacVittie — Wed, 01 Feb 2012 13:00:00 GMT

It’s about operational efficiency and consistency, emulated in the cloud by an API to create the appearance of a converged platform

In most cases, the use of the term “consolidation” implies the aggregation (and subsequently elimination) of like devices. Application delivery consolidation, for example, is used to describe a process of scaling up infrastructure that often occurs during upgrade cycles. Many little boxes are exchanged for a few larger ones as a means to simplify the architecture and reduce the overall costs (hard and soft) associated with delivering applications. Consolidation.

But cloud has opened (or should have opened) our eyes to a type of consolidation in which like services are aggregated; a consolidation strategy in which we layer a thin veneer over a set of adjacent functionalities in order to provide a scalable and ultimately operationally consistent experience: an API. A cloud API consolidates infrastructure from an operational perspective. It is the bringing together of adjacent functionalities into a single “entity.” Through a single API, many infrastructure functions and services can be controlled – provisioning, monitoring, security, and load balancing (one part of application delivery) are all available through the same API. Certainly the organization of an API’s documentation segments services into similar containers of functionality, but if you’ve looked at a cloud API you’ll note that it’s all the same API; only the organization of the documentation makes it appear otherwise.

This service-oriented approach allows for many of the same benefits as consolidation, without actually physically consolidating the infrastructure. Operational consistency is one of the biggest benefits.

OPERATIONAL CONSISTENCY

The ability to consistently manage and monitor infrastructure through the same interface – whether API or GUI or script – is an important factor in data center efficiency. One of the reasons enterprises demand overarching data center-level monitoring and management systems like HP OpenView and CA and IBM Tivoli is consistency and an aggregated view of the entire data center.

It is no different in the consumer world, where the consistency of the same interface greatly enhances the ability of the consumer to take advantage of underlying services. Convenience, too, plays a role here, as a single device (or API) is ultimately more manageable than the requirement to use several devices to accomplish the same thing. Back in the day I carried a Blackberry, a mobile phone, and a PDA – each had a specific function and there was very little overlap between the two. Today, a single “smart”phone provides the functions of all three – and then some. The consistency of a single interface, a single foundation, is paramount to the success of such consumer devices. It is the platform, whether consumers realize it or not, that enables their highly integrated and operationally consistent experience.

The same is true in the cloud, and ultimately in the data center. Cloud (pseudo) consolidates infrastructure the only way it can – through an API that ultimately becomes the platform analogous to an iPhone or Android-based device.

Cloud does not eliminate infrastructure, it merely abstracts it into a consolidated API such that the costs to manage it are greatly reduced due to the multi-tenant nature of the platform. Infrastructure is still managed, it’s just managed through an API that simplifies and unifies the processes to provide a more consistent approach that is beneficial to the organization in terms of hard (hardware, software) and soft (time, administration) costs.

The cloud and its requisite API provide the consolidation of infrastructure necessary to achieve greater cost savings and higher levels of consistency, both of which are necessary to scale operations in a way that makes IT able to meet the growing demand on its limited resources.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,cloud,cloud computing,API,architecture,mobile,operational consistency,blog

Performance in the Cloud: Business Jitter is Bad

Lori MacVittie — Mon, 30 Jan 2012 12:46:00 GMT

#fasterapp #ccevent While web applications aren’t sensitive to jitter, business processes are.

One of the benefits of web applications is that they are generally transported via TCP, which is a connection-oriented protocol designed to assure delivery. TCP has a variety of native mechanisms through which delivery issues can be addressed – from window sizes to selective acks to idle time specification to ramp up parameters. All these technical knobs and buttons serve as a way for operators and administrators to tweak the protocol, often at run time, to ensure the exchange of requests and responses upon which web applications rely. This is unlike UDP, which is more of a “fire and forget” protocol in which the server doesn’t really care if you receive the data or not.

Now, voice and streaming video and audio over the web has always leveraged UDP and thus it has always been highly sensitive to jitter. Jitter is, without getting into layer one (physical) jargon, an undesirable delay in the otherwise consistent delivery of packets. It causes the delay of and sometimes outright loss of packets that are experienced by users as pauses, skips, or jumps in multi-media content.

While the same root causes of delay – network congestion, routing changes, time out intervals – have an impact on TCP, it generally only delays the communication and other than an uncomfortable wait for the user, does not negatively impact the content itself. The content is eventually delivered because TCP guarantees that, UDP does not.

However, this does not mean that there are no negative impacts (other than trying the patience of users) from the performance issues that may plague web applications and particularly those that are more and more often out there, in the nebulous “cloud”. Delays are effectively business jitter and have a real impact on the ability of the business to perform its critical functions – and that includes generating revenue.

BUSINESS JITTER and the CLOUD

David Linthicum summed up the issue with performance of cloud-based applications well and actually used the terminology “jitter” to describe the unpredictable pattern of delay:

Are cloud services slow? Or fast? Both, it turns out -- and that reality could cause unexpected problems if you rely on public clouds for part of your IT services and infrastructure.

When I log performance on cloud-based processes -- some that are I/O intensive, some that are not -- I get results that vary randomly throughout the day. In fact, they appear to have the pattern of a very jittery process. Clearly, the program or system is struggling to obtain virtual resources that, in turn, struggle to obtain physical resources. Also, I suspect this "jitter" is not at all random, but based on the number of other processes or users sharing the same resources at that time.

-- David Linthicum, “Face the facts: Cloud performance isn't always stable”

But what the multitude of articles coming out over the past year or so with respect to performance of cloud services has largely ignored is the very real and often measurable impact on business processes. That jitter that occurs at the protocol and application layers trickles up to become jitter in the business process; a process that may be critical to servicing customers (and thus impacts satisfaction and brand) as well as on the bottom line. Unhappy customers forced to wait for “slow computers”, as it is so often called by the technically less adept customer service representatives employed by many organizations, may take to the social media airwaves to express displeasure, or cancel an order, or simply refuse to do business in the future with the organization based on delays experienced because of unpredictable cloud performance.

Business jitter can also manifest as decreased business productivity measures, which it turns out can be measured mathematically if you put your mind to it.

Understanding the variability of cloud performance is important for two reasons:

You need to understand the impact on the business and quantify it before embarking on any cloud initiative so it can be factored in to the overall cost-benefit analysis. It may be that the cost savings from public cloud are much greater than the potential loss of revenue and/or productivity, and thus the benefits of a cloud-based solution outweigh the risks.
Understanding the variability and from where it comes will have an impact and help guide you to choosing not only the right provider, but the right solutions that may be able to normalize or mitigate the variability. If the primary source of business jitter is your WAN, for example, then it may be that choosing a provider that supports your ability to deploy WAN optimization solutions would be an appropriate strategy. Similarly, if the variability in performance stems from capacity issues, then choosing a provider that allows greater latitude in load balancing algorithms or the deployment of a virtual (soft) ADC would likely be the best strategy.

It seems clear from testing and empirical (as well as anecdotal) evidence that cloud performance is highly variable and, as David puts it, unstable. This should not necessarily be seen as a deterrent to adopting cloud services – unless your business is so highly sensitive to latency that even milliseconds can be financially damaging – but rather it should be a reality that factors into your decision making process with respect to your choice of provider and the architecture of the solution you’ll be deploying (or subscribing to, in the case of SaaS) in the cloud.

Knowing is half the battle to leveraging cloud successfully. The other half is strategy and architecture.

I’ll be at CloudConnect 2012 and we’ll discuss the subject of cloud and performance a whole lot more at the show!

Sessions

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,jitter,cloud,performance,latency,WAN optimization,application delivery,cloud computing,blog

F5 Friday: Goodbye Defense in Depth. Hello Defense in Breadth.

Lori MacVittie — Fri, 27 Jan 2012 12:45:00 GMT

#adcfw #infosec F5 is changing the game on security by unifying it at the application and service delivery layer.

Over the past few years we’ve seen firewalls fail repeatedly. We’ve seen business disrupted, security thwarted, and reputations damaged by the failure of the very devices meant to prevent such catastrophes from happening. These failures have been caused by a change in tactics from invaders who seek no longer to find away through or over the walls, but who simply batter it down instead. A combination of traditional attacks – network-layer – and modern attacks – application-layer – have become a force to be reckoned with; one that traditional stateful firewalls are often not equipped to handle. Encrypted traffic flowing into and out of the data center often bypasses security solutions entirely, leaving another potential source of a breach unaddressed. And performance is being impeded by the increasing number of devices that must “crack the packet” as it were and examine it, often times duplicating functionality with varying degrees of success. This is problematic because the resolution to this issue can be as disconcerting as the problem itself: disable security. Seriously. Security functions have been disabled, intentionally, in the name of performance.

IT security personnel within large corporations are shutting off critical functionality in security applications to meet network performance demands for business applications.

SURVEY: SECURITY SACRIFICED FOR NETWORK PERFORMANCE

What the company [NSS Labs] found would likely startle any existing or potential customers: three of the six firewalls failed to stay operational when subjected to stability tests, five out of six didn't handle what is known as the "Sneak ACK attack," that would enable attackers to side-step the firewall itself. Finally, according to NSS Labs, the performance claims presented in the vendor datasheets "are generally grossly overstated."

Independent lab tests find firewalls fall down on the job

Add in the complexity from the sheer number of devices required to implement all the different layers of security needed, which increases costs while impairing performance, and you’ve got a broken model in need of repair. This is a failure of the defense in depth strategy; the layered, multi-device (silo) approach to operational security. Most importantly, it’s one that’s failing to withstand attacks.

What we need is defense in breadth – the height of the stack –to assure availability and security using a more intelligent, unified security strategy.

DEFENSE in BREADTH

While it’s really not as catchy as “defense in the depth” the concept behind the admittedly awkward sounding phrase is sound: to assure availability and security simultaneously requires a strong security strategy from the bottom to the top of the networking stack, i.e. the application layer. The ability of the F5 BIG-IP platform to provide security up and down the stack has existed for many years, and its capabilities to detect, prevent, and withstand concerted attacks has been appreciated by its customers (quietly) for some time. While basic firewalling functions have been a part of BIG-IP for years, there are certain capabilities required of a firewall – specifically an ICSA certified firewall – that it didn’t have. So we decided to do something about that.

The result is the ICSA certification of the BIG-IP platform as a network firewall. Combined with its existing

ICSA certification for web application firewall (BIG-IP Application Security Manager) and SSL-TLS VPN 3.0 (BIG-IP Edge Gateway), the BIG-IP platform now supports a full-spectrum security solution in a single, unified system. What is unique about F5’s approach is that the security capabilities noted above can be deployed on BIG-IP Application Delivery Controllers (ADCs)—best known for providing industry-leading intelligent traffic management and optimization capabilities. This firewall solution is part of F5’s comprehensive security architecture that enables customers to apply a unified security strategy. For the first time in the industry, organizations can secure their networks, data, protocols, applications, and users on a single, flexible, and extensible platform: BIG-IP.

Combining network-firewall services with the ability to plug the hole in modern security implementations (the application layer) with a platform-based solution provides the opportunity to consolidate security services and leverage a shared infrastructure platform resulting in a more comprehensive, strategic deployment that is not only more secure, but more cost effective.

Resources:

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: MacVittie,F5,F5 Friday,firewall,ICSA,security,BIG-IP,network,application security,DDoS,threat mitigation,blog

The Mobile Chimera

Lori MacVittie — Wed, 25 Jan 2012 11:56:00 GMT

#mobile #vdi #IPv6 In the case of technology – as with mythology - the whole is often greater (and more challenging) than the sum of its parts.

The chimera is a mythological beast of scary proportions. Not only is it fairly large, but it’s also got three, independent heads – traditionally a lion, a goat, and a snake. Some variations on this theme exist, but the basic principle remains: it’s a three-headed, angry beast that should not be taken lightly should one encounter it in the hallway.

Individually, one might have a strategy to meet the challenge of a lion or a goat head on. But when they converge into one very angry and dangerous beast, the strategies and tactics employed to best any one of them will almost certainly not work to address all three of them simultaneously.

The world of mobility is rapidly approaching its own technological chimera, one comprised of three individual technology trends. While successful stratagem and tactics exist which address each one individually, when taken together they form a new challenge requiring a new strategic approach.

THE MOBILE CHIMERA

Three technology trends - VDI, mobile, and IPv6 - are rapidly converging upon the enterprise. Each is driven in part by the other, and each requires in part functionality and support of another. Addressing the challenges accompanying this trifecta requires a serious evaluation of the enterprise infrastructure with an eye toward performance, scalability, and flexibility, less it be overwhelmed by demand originating both internally and externally.

Mobile

The myriad articles, blogs, and editorial orations on mobile device growth have to date focused on the need for organizations to step up and accept the need for device-ready enterprise applications. This focus has thus far ignored the reality of the diversity of the device client base, the ramifications of which those with long careers in IT will painfully recall from the client-server era. Thus it is no surprise that interest in and adoption of technology such as VDI is on the rise, as virtualization serves as a popular solution to the problem of delivering applications to a highly-diverse set of clients.

But virtualization, as popular a solution as it may be, is not a panacea. Security and control over corporate resources and applications is a growing necessity today because of the ease with which users can take advantage of mobile technology to access them.

Access control does not entirely solve the challenges of a diverse mobile client audience, as attackers turn their attention on mobile platforms as a means to gain access to resources and data previously beyond their reach. The need for endpoint security inspection continues to grow as the threat posed by mobile devices continues to rear its ugly head.

VDI

It was inevitable that the growth of mobile device usage in the enterprise continued to grow that so, too, would the solution of VDI grow as the most efficient way to deliver applications without requiring mobile platform-specific versions. The desire by business owners and security practitioners to keep data securely within the data center "walls", too, is a factor in the rising desire to deploy VDI. VDI enables organizations to deliver applications remotely while maintaining control over data inside the data center, preserving enforcement of corporate security policies and minimizing risk.

But VDI deployments are not trivial, regardless of the virtualization platform chosen. Each virtualization solution has its challenges and most of those challenges revolve around the infrastructure necessary to support such an initiative. Scalability and flexibility are important facets of VDI delivery infrastructure, and performance cannot be overlooked if such deployments are to be considered successful.

IPv6

Who could forget that the Internet is being pressured to move to IPv6 sooner rather than later, in part because of the growth of mobile clients? The strain placed on service providers to maintain IPv4 support as a means to not "break the Internet" can only be borne so long before IPv6 becomes, as has been predicted, the Y2K for the network.

The ability to deliver applications via VDI to mobile devices will soon require support for IPv6, but will not obviate the need to support IPv4 just yet. A dual stack approach will be required during the transition period, putting delivery infrastructure again front and center in the battle to deploy and support applications for mobile devices.

With all accounts numbering mobile devices in the four billion range across multiple platforms and effectively 0 IPv4 addresses left to assign to those devices, it should be no surprise that as these three technology trends collide the result will be the need for a new mobility strategy.

This is why solutions are strategic and technology is tactical. There exist individual products that easily solve each of these problems individually, but very few solutions that address the combined juggernaut that is the three combined. It is necessary to coordinate and architect a solution that can solve all three challenges simultaneously as a means to combat complexity and its associated best friend forever, operational risk.

A flexible and scalable delivery strategy will be necessary to ensure performance and security without sacrificing operational efficiency.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,mobile,vdi,ipv6,application delivery,strategy,performance,security,availability,architecture,quasar,blog

The API is the Center of the Application (Integration) Universe

Lori MacVittie — Mon, 23 Jan 2012 12:42:00 GMT

#mobile #fasterapp #ccevent Today, at least. Tomorrow, who knows?

Some have tried to distinguish between “mobile cloud” and “cloud” by claiming the former is the use of the web browser on a mobile device to access services while the latter uses device-native applications. Like all things cloud, the marketing fluff is purposefully obfuscating and sweeping under the rug the technology required to make things work for consumers, whether those consumers be your kids or IT professionals. Infrastructure is not eliminated when organizations take to the cloud nor do the constraints of web-based protocols and methodologies become irrelevant when Bob uses a service to store photos of his kid’s piano recital on Flickr.

The applications and web browsers on a mobile device are using the same technology, the same protocols, suffering under the same constraints as the rest of us in wireline land. If developers are as smart as they are lazy (and I say that as a compliment because it is the laziness of developers that more often than not leads to innovation) they have already moved to an API-centric model in which web site and device native-app interfaces both leverage the same APIs.

This isn’t just a social integration phenomenon – it isn’t just about Twitter and Facebook and Google. API usage and demand is growing, and it is not expected to stop any time soon. Given the option, developers asked about desire to connect to services (assuming service = API) the overwhelming response was developers would like to connect to “everything, if it were easy.” (API Integration Pain Survey Results)

The API is rapidly becoming (if it isn’t already) the center of the application (integration) universe. This unfortunately has the potential to cause confusion and chaos in the data center. When a single API is consumed by multiple clients – mobile, remote, applications, partners, etc.. – solutions unique to each quickly seem to make their way into the code to deal with “exceptions” and “peculiarities” inherent to the client platform.

That’s inefficient and, when one considers the growing number of platforms and form-factors associated with mobile communications alone, it is not scalable from a people and process perspective.

But reality is that these exceptions and peculiarities – often times caused by a lack of feature parity across form-factors and platforms – must be addressed somewhere, and that somewhere is unfortunately almost unilaterally determined to be the application. Do we need to treat mobile devices differently? In terms of performance and delivery concerns, yes. But that’s where we leverage the application delivery tier to differentiate by device to ensure delivery. That’s the beauty of an abstracted, service-enabled data center – there’s an intelligent and agile layer of application delivery services that mediates between clients (regardless of their form factor) and services to ensure that delivery needs (security, performance, and availability) are met in part by addressing the unique characteristics and reality of access via mobile devices.

ABSTRACT and ISOLATE

This is exactly the type of problem application delivery is designed to address. Multiple clients, multiple networks, all accessing the same application service or API but requiring specific authentication, security, and delivery characteristics to ensure that operational risk is mitigated in the most efficient manner possible.

This includes the ability to throttle services based on user and client, a common approach used by mega-sites such as Twitter. This includes the ability to provide single sign-on capabilities to all clients, regardless of platform, form-factor and support for enterprise-grade authentication integration to the same API or application service. This includes leveraging the appropriate security policies to ensure inbound and outbound security of data regardless of client, such that corporate data is not infected and spread to other consumers.

A flexible, scalable application delivery tier addresses the problem of a single API being utilized by a variety of clients in a way that precludes the need to codify specific functionality on a per-platform or form-factor basis in the application logic itself, making the API simpler and easier to maintain as well as test and upgrade. It makes APIs and application services more scalable in terms of people and processes, which in turn makes the development and deployment process more efficient and able to focus on new services rather than constantly modifying and updating existing ones.

Service-oriented architecture may have begun in the application demesne as a means to abstract and isolate services such that they could more easily be integrated, maintained, and changed without disruption, but the concept is applicable to the data center as a whole. By leveraging SOA concepts at the data center architecture level, the entire technological landscape of the business can be transformed into one that is ultimately more adaptable, more scalable, and more secure.

I’ll be at CloudConnect 2012 and we’ll discuss the subject of cloud and performance a whole lot more at the show!

Sessions

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,application delivery,data center,architecture,mobile,API,SOA,security,performance,availability,blog

The Fundamental Problem with Traditional Inbound Protection

Lori MacVittie — Fri, 20 Jan 2012 13:11:00 GMT

#adcfw #RSAC #infosec The focus on bandwidth and traffic continue to distract from the real problems with traditional inbound protections …

The past year brought us many stories focusing on successful attacks on organizations for a wide variety of reasons. Why an organization was targeted was not nearly as important as the result: failure to prevent an outage. While the volume of traffic often seen by these organizations was in itself impressive, it was not the always the volume of traffic that led to the outage, but rather what that traffic was designed to do: consume resources.

It’s a story we’ve heard before, particularly with respect to web and application servers. We know that over-consumption of resources impairs performance and, ultimately, causes outages. But what was perhaps new to many last year was that it wasn’t just servers that were falling to an overwhelming number of connections, it was the very protections put in place to detect and prevent such attacks – stateful firewalls.

Firewalls are the most traditional of inbound protection for data centers. Initially designed to simply prevent unauthorized access via specific ports, they have evolved to a level that includes the ability to perform limited packet inspection and make decisions based on the data within them. While this has been helpful in preventing a growing variety of attacks, they have remained unable to move laterally across protocols and understand expected and acceptable behavior within the context of a request, which results in a failure to recognize an attack. This is because modern application layer attacks look and smell to traditional inbound protection devices like legitimate requests. They are simply unable to parse behavior in its appropriate context and make the determination that the intention behind the request is malicious.

A recent InfoWorld article presented a five-point list regarding how to deny DDoS attacks. The author and his referenced expert Neal Quinn, VP of operations at Prolexic, accurately identify the root cause of the inability of traditional inbound protection to thoroughly mitigate DDoS attacks:

But the most difficult challenge has been DDoS attackers' increasing sophistication as they've moved from targeting Layers 3 and 4 (routing and transport) to Layer 7 (the application layer). They've learned, for example, how to determine which elements comprise a victim's most popular Web page, honing in on which ones take the most time to load and have the least amount of redundancy.

"Attackers are now spending a much longer period of time researching their targets and the applications they are running, trying to figure out where they can cause the most pain with a particular application," Quinn said. "For example, they may do reconnaissance to figure out what URL post will cause the most resource-consuming Web page refresh."

-- How to deny DDoS attacks

Unfortunately the five-point list describing the strategy and tactics to “deny DDOS attacks” completely ignores this difficult challenge, offering no advice on how to mitigate “the most difficult challenge".” While the advice to ensure enough compute resources tangentially touches upon the answer, the list is a traditional response that does not address the rising Layer 7 challenge.

CONNECTIONS not THROUGHPUT

To understand how to mitigate the rising layer 7 security challenge one must first understand the two core reasons traditional inbound security solutions are unlikely to mitigate these attacks. First is a failure to recognize an application layer attack for what it is. This failure cascades into the second reason traditional inbound security solutions fail: connection capacity.

Not bandwidth, connections. A million TCP connections can easily topple most modern firewalls today and yet the bandwidth involved could be miniscule compared to the gigabits of capacity many organizations have at their disposal. It isn’t about bandwidth anymore, it’s about connections. This is why the advice to ramp up compute processing power and memory is partially on target – because memory is imperative in maintaining massive session (connection) tables on infrastructure as traffic flows to and from targeted services.

Because traditional inbound protection devices are unable to recognize the malicious intent of these legitimate-appearing requests, they must maintain the connection. When combined with the need to maintain connections for all legitimate traffic, these malicious requests can quickly push a traditional device beyond its meager connection limitations. When that occurs, the results are disastrous. Performance, of course, suffers unacceptable degradation. One can only hope that is the only impact, for far more often the device simply fails, completely disrupting all services.

To complete the aforementioned list of “how to deny a DDoS attack”, it is necessary to implement a security solution at the perimeter of the network that is both able to detect and thus deny malicious requests and which has the connection capacity necessary to withstand the combined volume of legitimate and malicious requests. This solution must reside at the edge of the network, lest a less capable device be overwhelmed. This is because when it comes to perimeter security, the default is a serial strategy – nothing gets past a failed security device. If that security device is at the edge of the network, as is the case with traditional inbound security solutions like stateful firewalls, then all services residing topologically behind that device will fail should the firewall fall.

This is by design. One does not want unfettered access to services and applications. No perimeter protection, no access. It’s a sound strategy, but one that needs to employ a perimeter device capable of withstanding even the most diverse of attacks.

Traditional inbound security is too constrained in terms of connection capacity to maintain its position on the front lines. A more capable, intelligent security solution is required – one able to provide traditional inbound security protections as well as recognizing the malicious intent of more modern, application layer attacks.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,firewall,security,application security,blog