Lori MacVittie

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

The Ascendancy of the Application Layer Threat

Lori MacVittie — Tue, 17 Jan 2012 13:19:00 GMT

#adcfw #RSAC Attackers have outflanked your security infrastructure

Many are familiar with the name of the legendary Alexander the Great, if not the specific battles in which he fought. And even those familiar with his many victorious conquests are not so familiar with his contributions to his father’s battles in which he certainly honed the tactical and strategic expertise that led to his conquest of the “known” world.

In 339 BC, for example, then Macedonian King Phillip II – the father of Alexander the Great – became engaged in a battle at Chaeronea against the combined forces of ancient Greece. While the details are interesting, they are not really all that germane to technology except for commentary on what may be* Phillips’ tactics during the battle, as suggested by the Macedonian author Polyaenus:

In another 'stratagem', Polyaenus suggests that Philip deliberately prolonged the battle, to take advantage of the rawness of the Athenian troops (his own veterans being more used to fatigue), and delayed his main attack until the Athenians were exhausted.

-- Battle of Chaeronea (338 BC) (Wikipedia)

This tactic should sound familiar, as it akin in strategy to that of application DDoS attacks today.

THE RISE of APPLICATION LAYER ATTACKS

Attacks at the application layer are here to stay – and we should expect more of them. When the first of these attacks was successful, it became a sure bet that we would see more of them along with more variations on the same theme. And we are. More and more organizations are reporting attacks bombarding them not just at the network layer but above it, at the transport and application layers.

Surely best practices for secure coding would resolve this, you may think. But the attacks that are growing to rule the roost are not the SQLi and XSS attacks that are still very prevalent today. The attacks that are growing and feeding upon the resources of data centers and clouds the globe over are more subtle than that; they’re not about injecting malicious code into data to be spread around like a nasty contagion, they’re DDoS attacks. Just like their network-focused DDoS counterparts, the goal is not infection – it’s disruption.

These attacks exploit protocol behavior as well as potentially missed vulnerabilities in application layer protocols as a means to consume as many server resources as possible using the least amount of client resources. The goal is to look legitimate so the security infrastructure doesn’t notice you, and then slowly leech compute resources from servers until they can’t stand – and they topple.

They’re Phillip’s Macedonians; wearing out the web server until it’s too tired to stand.

These attacks aren’t something listed in the OWASP Top Ten (or even on the OWASP list, for that matter). These are not attacks that can be detected by IPS, IDS, or even traditional stateful firewalls. These technologies focus on data and anomalies in data, not behavior and generally not at the application protocol layer.

For example, consider HTTP Fragmentation attacks.

In this attack, a non-spoofed attacker establishes a valid HTTP connection with a web server. The attacker then proceeds to fragment legitimate HTTP packets into tiny fragments, sending each fragment as slow as the server time out allows, holding up the HTTP connection for a long time without raising any alarms. For Apache and many other web servers designed with improper time-out mechanisms, this HTTP session time can be extended to a very long time period. By opening multiple extended session per attacker, the attacker can silently stop a web service with just a handful of resources.

Multiple Methods in a Single Request is another fine example of exhausting a web server’s resources. The attacker creates multiple HTTP requests, not by issuing them one after another during a single session, but by forming a single packet embedded with multiple requests. This allows the attacker to maintain high loads on the victim server with a low attack packet rate. This low rate makes the attacker nearly invisible to NetFlow anomaly detection techniques. Also, if the attacker selects the HTTP method carefully these attacks will bypass deep packet inspection techniques.

There a number of other similar attacks, all variations on the same theme: manipulation of valid behavior to exhaustion of web server resources with the goal of disrupting services. Eventually, servers crash or become so slow they are unable to adequately service legitimate clients – the definition of a successful DDoS attack.

These attacks are not detectable by firewalls and other security infrastructure that only examine packets or even flows for anomalies because no anomaly exists. This is about behavior, about that one person in the bank line who is acting oddly – not enough to alarm most people but just enough to trigger attention from someone trained to detect it. The same is true of security infrastructure. The only component that will detect such subtle improper behavior is one that’s been designed to protect it.

* It was quite a while ago, after all, and sources are somewhat muddied. Whether this account is accurate or not is still debated.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,firewall,application,service delivering,dynamic infrastructure,web application security,DDoS,threat mitigation,blog

Mobile versus Mobile: An Identity Crisis

Lori MacVittie — Mon, 16 Jan 2012 13:00:00 GMT

#mobileThe expansive options consumers revel in creates an identity crisis for IT that is best resolved via context-aware mobile mediation.

Back in the days of the browser wars, when standards were still largely ignored and the battle for the desktop was highly competitive, developers had to make choices and compromises. They could either write extensive client-side scripts to detect the user’s browser and address the peculiarities of that environment or they could simply ignore them with a disclaimer that “this site (works best when viewed in | was written for) browser X.”

As time went by, developers were able to discontinue this annoying practice as browser features converged and a common, standardized platform emerged upon which all applications were able to be delivered to any popular browser without concern.

Then mobile phones appeared, and the user experience degraded again, this time driven by the relatively feeble processing power of the platform. Small screens aside, the memory and processing power available on a mobile phone was such that – when combined with a constrained networking environment – the delivery of increasingly chunky, graphic heavy, interactive applications to mobile phones was simply a bad idea for both organizations and its visitors.

Developers and web ops returned to the inspection of HTTP headers to determine whether or not a visitor was using a mobile platform, and began writing leaner, more compact interfaces specifically for those platforms.

Enter tablets. Neither desktop nor phone, these admittedly mobile platforms are compact but nearly as powerful as their overweight tethered cousins without sacrificing the mobility of their anorexic form-factor brethren.

COMMON GROUND: MOBILE OPERATING SYSTEM

Tablets are certainly able to take advantage of emerging web application standards such as HTML5 to deliver a full, rich interactive desktop-style experience on a mobile platform, but are rarely offered it. They are by default offered up a mobile experience because of a common element: the operating system. Even if the operating system was masked, still they’ll find out by checking a second, lesser known HTTP header: HTTP_X_WAP_PROFILE. And if not there, then potentially in HTTP_PROFILE.

Unfortunately, this is not necessarily the fault of the developer. There are no standards prescribing what should or should not identity a mobile device, and thus manufacturers are left to their own devices (pun only somewhat intended).

There is no reliable way, today, to identify a mobile device accurately. Developers are left writing complex scripts that strip apart user agents, profile strings and whatever other contextual data they can extract from HTTP headers to determine how best to serve up content.

That often means visitors are served content that is not wholly appropriate for their device. Even if they could, the market is so volatile at this point that it’s a sure bet that a new device will enter soon that requires modification to the application yet again. More code, more string manipulation, more latency in processing.

CONTEXT-AWARE MOBILE MEDIATION

It would be nice if developers could simply receive accurate inbound HTTP headers. Headers that clearly identify the device not only from an operating system perspective, but from a form-factor and network perspective in a standard way. But there are no standards, yet, and may never be. Thus a solution may be found in imposing standards upon inbound requests specifically for developers to better address the disparities in resolution, functionality, and performance between the various mobile device types.

This requires some amount of pre-planning. Design, if you will, or architecture up front. It requires that developers and devops sit down together and determine a standard means of communicating information between infrastructure and the applications it supports. Consider the possibility of two custom HTTP headers, one identifying the network type and one specifying form-factor and device:

HTTP_X_NETWORK = “WIFI | MOBILE | LAN”

HTTP_X_DEVICE = “TABLET | PHONE | DESKTOP”

If developers could rely on these two custom HTTP headers to exist for every inbound request, they could then develop applications based upon these characteristics that were more appropriate for the given device and network over which the device connected. Implementation requires only minimal inspection and insertion on a context-aware mediating device such as a network-side scripting capable application delivery controller.

Because the application delivery controller is topologically positioned in a strategic point of control, it has visibility into the network, client, and server-side environments. This gives it the ability to better interpret and execute policies that govern the delivery of applications to optimize performance and assure availability, but it also provides the ability to extract and share pertinent data with applications and other infrastructure. This data can be shared in a number of ways, including modification of the payload, of the headers, insertion of new headers, removal of old headers, etc…

The flexibility inherent in network-side scripting solutions, particularly those capable of side-band connectivity, allows devops and developers to design and develop a solution that works for them – in their environment.

The advantage to such a solution lies not only in more accurate, actionable data to share with applications, but in its ability to easily be modified without negatively impacting the application. A second advantage is the ability of developers to also take into consideration the network characteristics of the mobile device, data generally not available or, if available, generally inaccurate. A mobile device today may be accessing an application via WiFi or a mobile network, and that piece of information is quite pertinent as the performance and capabilities of each network are quite different and have a significant impact on the end-user experience from a delivery perspective.

Yet this data is not available by default to developers and it cannot reliably be inferred from device type. By leveraging a context-aware mediating solution, however, it becomes possible to share this data with developers such that they are able to take that information into consideration when putting together a response to a given request.

While not a panacea, such a solution certainly provides a more consistent and overall accurate environment in which to deliver applications to the increasingly broad and diverse spectrum of mobile devices.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,mobile,HTML5,tablet,context-aware,performance,architecture,network-side scripting,iRules,strategic point of control,blog

F5 Friday: Why SSL VPN Still Matters

Lori MacVittie — Fri, 13 Jan 2012 12:55:00 GMT

#mobile #vdi #infosec Scale and flexibility make SSL VPN an important part of any corporate remote access strategy

You might have noticed a couple of news items from F5 this week that appeared related. If you noticed you were right, they are.

First, we were very excited to announce recognition of our hard work on our SSL VPN solutions: F5 Positioned in Leaders Quadrant of SSL VPN Magic Quadrant. Second, we were even more excited to announce adding industry-leading support for Android’s 4.x OS, enhancing its SSL VPN capabilities.

Why would be excited about that? Because mobile devices and virtualization (desktop, a la VDI, and server, a la cloud) continue to drive the need for secure remote access at a scale never before experienced by most IT organizations. While web monsters and primarily web-focused organizations have long understand the critical nature of scalability to their business, IT shops for whom a web presence was only somewhat important have not necessarily invested in the infrastructure or architecture necessary to truly scale to meet the increasing demand. It is increasingly the case that IT orgs of all shapes, sizes, and concerns must look to the scalability of its infrastructure to ensure its ability to service users inside and outside the data center via an often times dizzying array of clients and technologies.

SSL VPNs arose from similar needs many years ago, out of the overwhelming complexity associated with IPSEC and the inability to support every end-user from every platform available. An SSL VPN generally provides two things: secure remote access via a web-top portal and network-level access via an SSL secured tunnel between the client and the corporate network.

By providing both modes of access via an established, ubiquitous protocol (SSL), such solutions are better able to provide end users with access to resources regardless of platform. By deploying such a solution on a proven, highly scalable platform (BIG-IP), such solutions are better able to provide IT with the means to scale not only the solution but its requisite infrastructure services.

Enhanced Mobile Support

BIG-IP^® Edge Client^™ is the industry’s first SSL VPN solution that provides comprehensive security and mobile access for all devices running Android 4.x (codenamed Ice Cream Sandwich). It’s free, and you can get it anytime you like. Right now, if you want – go ahead. Grab it, I’ll wait.

Oh, you aren’t running Ice Cream Sandwich yet? If you’ve got a “rooted” device, we’ve got your back there, too, with our BIG-IP Edge Client for “rooted” devices.

Additionally, F5 is introducing enhanced support for its BIG-IP Edge Portal™, which provides managed application access to enterprise web applications such as SharePoint, wikis, and Intranet sites. This is that web top access mentioned earlier – a secure means of providing access to resources from any device without giving away the keys to the kingdom via the more open corporate network access route.

And ultimately, this two-pronged approach to secure remote access afforded by SSL VPN solutions like BIG-IP Edge Gateway will continue to be important to corporate remote access strategies precisely because of the need to differentiate levels of service and access based on location, device, and user – something only a context-aware solution can provide.

This is why validation of external sources of our work in the SSL VPN arena is exciting – because SSL VPN continues to be a significantly more flexible option to traditional IPSEC VPN connectivity and with the continued growth of mobile devices and demand for technology like VDI, it will certainly only continue to expand its applicability in the enterprise as scale and flexibility become more and more necessary to meet the diverse, distributed demand of clients.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,mobile,vdi,ssl,ssl vpn,secure remote access,Android,Ice Cream Sandwich,BIG-IP,IPSEC,VPN,blog

Mature Security Organizations Align Security with Service Delivery

Lori MacVittie — Thu, 12 Jan 2012 13:33:00 GMT

#adcfw #RSAC Traditional strategy segregates delivery from security. Traditional strategy is doing it wrong…

Everyone, I’m sure, has had the experience of calling customer service. First you get the automated system, which often asks for your account number. You know, to direct you to the right place and “serve you better.” Everyone has also likely been exasperated when the first question asked by a customer service representative upon being connected to a real live person is … “May I have your account number, please?”

It’s frustrating and, for everyone involved, it’s cumbersome.

That’s exactly the process that occurs in most data centers today as application requests are received by the firewall and then passed on to the service delivery layer.

Traditional data center design segregates security from service delivery. There’s an entire complement of security-related components that reside at the perimeter of the network, designed to evaluate incoming traffic for a wide variety of potential security risks – DDoS, unauthorized access, malicious packets, etc… But that evaluation is limited to the network layers of the stack. It’s focused on packets and connections and protocols, and fails to take into consideration the broader contextual information that is carried along by every request. It’s asking for an account number but failing to leverage it and share it in a way that effectively applies and enforces corporate security policies.

It’s cumbersome.

Reality is that many of the functions executed by firewalls are duplicated in the application delivery tier by service delivery systems. What’s more frustrating is that many of those functions are executed more thoroughly and to better effect (i.e. they mitigate risk more effectively) at the application delivery layer.

What should be frustrating to those concerned with IT budgets and operational efficiency is that this disconnected security strategy is more expensive to acquire, deploy, and maintain. Using shared infrastructure is the hallmark of a mature security organization; it’s a sign of moving toward a more strategic security strategy that’s not only more technically adept but is financially sound.

SHARED INFRASTRUCTURE

We most often hear the term “shared infrastructure” with respect to cloud computing and its benefits. The sharing of infrastructure across organizations in a public cloud computing environment nets operational savings not only from alleviating the need to manage the infrastructure from the fact that the capital costs are shared across hundreds if not thousands of customers.

Inside the data center private cloud computing models are rising to the top of the “must have” list for IT for similar reasons. In the data center, however, there are additional technical and security benefits that should not be overlooked. Aligning corporate security strategy with the organizations’ service delivery strategy by leveraging shared infrastructure provides a more comprehensive, strategic deployment that is not only more secure, but more cost effective.

Service delivery solutions already provide a wide variety of threat mitigation services that can leveraged to mitigate the performance degradation associated with a disjointed security infrastructure, the kind that leads 9 of 10 organizations to sacrifice that security in favor of performance. By leveraging shared infrastructure to perform both service delivery acceleration as well as security, neither performance nor security need be sacrificed because it essentially aligns with the mantra of the past decade with regards to performance and security: crack the packet only once.

In other words, don’t ask the customer for their account number twice. It’s cumbersome, frustrating, and an inefficient means of delivering any kind of service.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,security,firewall,strategy,service delivering,dynamic infrastructure,web application security,DDoS,threat mitigation,blog

Enterprise Apps are Not Written for Speed

Lori MacVittie — Wed, 11 Jan 2012 12:20:00 GMT

#fasterapp #cceventThey’re written for readability, for integration, for business function, and for long-term maintenance…

When I was first entering IT I had the good (or bad, depending on how you look at it) fortune to be involved in some of the first Internet-facing projects at a global transportation organization. We made mistakes and learned lessons and eventually got down to the business of architecting a framework that would span the entire IT portfolio.

One of the lessons I learned early on was that maintainability always won over performance, especially at the code level. Oh, some basic tenets of optimization in the code could be followed – choosing between while, for, and do..until conditionals based on performance-related concerns – but for the most part, many of the tricks used to improve performance were verboten, and some based solely on factors like readability. The introduction of local scope for an if…then…else statement, for example, was required for readability, even though in terms of performance this introduces many unnecessary clock ticks that under load can have a negative impact on overall capacity and response time. Microseconds of delays adds up to seconds of delays, after all.

But coding standards in the enterprise lean heavily toward the reality that (1) code lives for a long time and (2) someone other than the original developer will likely be maintaining it. This means readability is paramount to ensuring the long-term success of any development project.

Thus, performance suffers and “rewriting the application” is not an option. It’s costly and the changes necessary would likely conflict with the overriding need to ensure long-term maintainability.

Even modern web-focused organizations like Twitter and Facebook have run into performance issues based on architectural decisions made early in the lifecycle. Many no doubt recall the often very technical discussions regarding Twitter’s design and interaction with its database as a source of performance woes, with hundreds of experts offering advice and criticism.

Applications are not often designed with performance in mind. They are architected and designed to perform specific functions and tasks, usually business-related, and they are developed with long-term maintenance in mind.

This leads to the problem of performance, which can rarely be addressed by the developers due to the constraints placed upon them, not least of which may be an active and very vocal user base.

APPLICATION DELIVERY PUTS the FAST back in APPLICATIONS

This is a core reason the realm of application delivery exists: to compensate for issues within the application that cannot – for whatever reason – be addressed through modification of the application itself. Application acceleration, WAN optimization, and load balancing services combine to form a powerful tier of application delivery services within the data center through which performance-related issues can be addressed. This tier allows load balancing services, for example, to be leveraged as a means to scale out an application, which effectively results in similar (and often greater) performance gains as simply scaling up to redress inherent performance constraints within the application.

Application acceleration techniques improve the delivery of application-related content and objects through caching, compression, transformation, and concatenation. And WAN optimization services address bandwidth constraints that may inhibit delivery of the application, especially those heavy on the data and content side. While certainly developers could modify applications to rearrange content or reduce the size of data being delivered, it is rarely practical or cost-effective to do so. Similarly, it is not cost-effective or practical to ask developers to modify applications to remove processing bottlenecks that may result in unreadable code.

Enterprise applications are not written for speed, but that is exactly what is demanded of them by their users. Both needs must be met, and the introduction of an application delivery tier into the architecture can serve to provide the balance between performance and maintenance by applying acceleration services dynamically. In this way applications need not be modified, but performance and scale is greatly improved.

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,performance,application delivery,application acceleration,caching,compression,transformation,WAN Optimization,load balancing,FEO,WPO,blog

The Epic Failure of Stand-Alone WAN Optimization

Lori MacVittie — Mon, 09 Jan 2012 13:03:00 GMT

#fasterapp #ccevent WAN optimization is not and cannot be separated from application delivery

Yes, yes I did say that. There's a reason for that, and after more than a decade of watching the markets that tangentially revolve around making applications faster I'm here to tell you it's a failure of monumental proportions.

The very term WAN Optimization has always stuck in my craw (whatever and wherever that may be). That's because optimizing the WAN implies that you're making the WAN faster. The problem is that a WAN is either a dedicated link between two locations (old skool) or a connection to a remote site across the Internet (new skool). In the case of the former there really isn't a whole lot you can do to that network to make it faster. In the case of the latter there really isn't anything you can do to influence the networking components out there, on the Internet (or "in the cloud" as some are wont to call it these days) to make it faster.

In the data center, optimizing the network has real meaning. It's about modifying routing and switching, moving segments and changing VLANs. It's about fatter connections and changing the way in which network traffic flows through the pipes.

But when it comes to the WAN, you've got very little to tweak.

This is the reason that when folks said WAN Optimization what they really meant was "we squish data down so there's fewer packets and thus, it traverses the network faster.”

Wonderbar.

APPLICATIONS are not NETWORKS

What IT and business stakeholders really want - what they care about and what they're basing key performance indicators on, however - is faster applications. And if you focus on optimizing the network, well, that's not really the right approach. The right approach is to focus on the application, with its unique transport and application layer behaviors and what those imply in terms of performance. Then you focus on resolving any issues that arise because of that behavior. Then, if you still need to, you can apply traditional techniques like compression and deduplication and reduce the size to make the results of your initial efforts even better.

But if you aren't focusing on those initial efforts, you're doing it wrong. If you profile an application and find out performance degradations are caused by excessive load on the server, optimizing the WAN is not going to really help. Reducing the load on the server, however, will. While it is certainly the case that improving transfer speeds over the WAN can ensure that some of the load is alleviated by clearing out server queues faster, it won't solve the entire problem because some of the degradation is caused by excessive context switching and simple fact that is compute time sharing between threads and processes on a server. Optimizing the WAN isn't really going to address that, but reducing the number of those threads and processes required will.

See, application delivery is about the big picture - and the focal point of that picture is the application. WAN Optimization has a role to play in that picture, but it's a supporting role, just like network optimization and web acceleration. WAN optimization is not and cannot be separated from application delivery. It simply isn't a stand-alone technology - or at least not one that really enables organizations to realize real benefits with respect to performance and availability of applications. It's a piece of the larger picture that is application delivery.

For some applications – and uses – WAN optimization will provide the biggest gains in performance. Transferring large data sets such as those related to backups and DR efforts, or virtual machines in long-distance migration efforts, need the assistance of WAN optimization solutions. For others, however, such technology does very little to improve performance. That’s why application delivery focuses on the whole, on the big picture – the application and the context in which it is accessed. Without a holistic approach to application delivery you may be making one piece of the puzzle better – or you may be just spinning your technological wheels.

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,MacVittie,cloud,WAN optimization,acceleration,performance,application delivery,network,blog

F5 Friday: Creating a DNS Blackhole. On Purpose

Lori MacVittie — Fri, 06 Jan 2012 12:32:00 GMT

#infosec #DNS #v11 DNS is like your mom, remember? Sometimes she knows better.

Generally speaking, blackhole routing is a problem, not a solution. A route to nowhere is not exactly a good thing, after all. But in some cases it’s an approved and even recommended solution, usually implemented as a means to filter out bad packets at the routing level that might be malformed or are otherwise dangerous to pass around inside the data center.

This technique is also used at the DNS layer as a means to prevent responding to queries with known infected or otherwise malicious sites. Generally speaking, DNS does nothing more than act like a phone book; you ask for an address, it gives it to you. That may have been acceptable through the last decade, but it is increasingly undesirable as it often unwittingly serves as part of the distribution network for malware and other malicious intent.

In networking, black holes refer to places in the network where incoming traffic is silently discarded (or "dropped"), without informing the source that the data did not reach its intended recipient.

When examining the topology of the network, the black holes themselves are invisible, and can only be detected by monitoring the lost traffic; hence the name.

(http://en.wikipedia.org/wiki/Black_hole_(networking))

What we’d like to do is prevent DNS servers from returning addresses for sites which we know – or are at least pretty darn sure – are infected. While we can’t provide such safeguards for everyone (unless you’re the authoritative server for such sites) we can at least better protect the corporate network and users from such sites by ensuring such queries are not answered with the infected addresses.

Such a solution requires the implementation of a DNS blackhole – a filtering of queries at the DNS level. This can be done using F5 iRules to inspect queries against a list of known bad sites and returning an internal address for those that match. What’s cool about using iRules to perform this function is the ability to leverage external lookups to perform the inspection. Sideband connections were introduced in BIG-IP v11 and these connections allow external, i.e. off device, lookups for solutions like this. Such a solution is similar to the way in which you’d want to look up the IP address and/or domain of the sender during an e-mail exchange, to validate the sender is not on the “bad spammer” lists maintained by a variety of organizations and offered as a service.

Jason Rahm recently detailed this solution as architected by Hugh O’Donnel, complete with iRules, in a DevCentral Tech Tip. You can find a more comprehensive description of the solution as well as the iRules to implement in the tech tip.

v11.1: DNS Blackhole with iRules

Happy (DNS) Routing!

Connect with Lori:	Connect with F5:

Related blogs & articles:

Technorati Tags: F5,F5 Friday,MacVittie,DNS,routing,blackhole,network,iRules,architecture,security,context-aware,blog

The Three Axioms of Application Delivery

Lori MacVittie — Wed, 04 Jan 2012 12:04:00 GMT

#fasterapp If you know these three axioms, then you’ll know application delivery when you see it.

Like most technology jargon, there are certain terms and phrases that end up mangled, conflated, and generally misapplied as they gain traction in the wider market. Cloud is merely the latest incarnation of this phenomenon, and there will be others in the future. Guaranteed.

Of late the term “application delivery” has been creeping up into the vernacular. That could be because cloud has pushed it to the fore, necessarily. Cloud purports to eliminate the “concern” of infrastructure and allows IT to focus on … you guessed it, the application. Which in turn means the delivery of applications is becoming more and more pervasive in the strategic vocabulary of the market.

But like cloud and its predecessors, the term application delivery is somewhat vague and without definition. I am not going to define it, in case you were wondering, because quite frankly I’ve watched its expansion and transformation over the past decade and understand that application delivery is not static. As new technology and deployment models arise, new techniques and architectures must also arise to meet the challenges that naturally arise along with those applications.

But how, then, do you know what is and is not application delivery? If it can morph and grow and transform with time and technology, then anything can be considered application delivery, right?

Not entirely. Application delivery, after all, is about an end-to-end process. It’s about a request that is sent to an application and subsequently fulfilled and returned to the originator of the request. Depending on the application this process may be simple or exceedingly complex, requiring authentication, logging, verification, interaction of multiple services and, one hopes, a wealth of security services ensuring that what is delivered is what was intended and desired, and is not carrying along something malicious.

A definition comprising these concepts would be either be far too broad so as to be meaningless, or so narrow that it left no room to adapt to future technologies. Neither is acceptable, in my opinion. A much better way to understand what is (and conversely what is not) application delivery is to learn three simple axioms that define the core concepts upon which application delivery is based.

APPLICATION-CENTRIC

“Applications are not servers, hypervisors, or operating systems.”

Applications are not servers. They are not the physical or virtual server upon which they are deployed and from where they draw core resources. They are not the web and application servers on which they rely for application-layer protocol support. They are not the network stack from which they derive their IP address or TCP connection characteristics. They are uniquely separate entities that must be managed individually.

The concrete example of this axiom in action is health-monitoring of applications. Too many times we see load balancing services configured with health-checking options that are focused on IP or TCP or HTTP parameters. Ping checks, TCP half-open checks, HTTP status checks. None of these options are relevant to whether or not the application is available and executing correctly. A ping check assures us the network is operating and the OS is responding. A TCP half-open check tells us network stack is operating properly. An HTTP status check tells us the web or application server is running and accepting requests. But none of these even touches on whether or not the application is executing and responding correctly.

Similarly, applications are not ports, and security services must be able to secure the application, not merely its operating environment. Applications are not – or should not – be defined by their network characteristics, and neither should they be secured based on these parameters.

Applications are not servers, hypervisors, or operating systems. They are individual entities that must be managed individually, from a performance, availability, and security perspective.

MITIGATE OPERATIONAL RISK

“Availability, performance, and security are not separate operational challenges.”

In most IT organizations the people responsible for security are not responsible for performance or availability, and vice-versa. While devops tries to bridge the gap between applications and operations-focused professionals, we may need to intervene first and unify operations. These three operational concerns are intertwined, they are interrelated, they are paternal triplets. A DDoS attack is security, but it has – or likely will have – a profound impact on both performance and availability. Availability has an impact on performance, both positive and negative. And too often performance concerns result in the avoidance of security that can ultimately return to bite availability in the derriere.

Application delivery recognizes that all three components of operational risk are inseparable, and they must be viewed as a holistic concern. Each challenge should be addressed with the others in mind, and with the understanding that changes in one will impact the others.

OPERATE WITHIN CONTEXT

“Application delivery decisions cannot be made efficiently or effectively in a vacuum.”

Finally, application delivery recognizes that decisions regarding application performance, security, and availability cannot be made within a vacuum. What may improve performance for a mobile client accessing an application over the Internet may actually impair performance for a mobile client accessing the application over the internal data center network. What is appropriate authentication methods for a remote PC desktop are unlikely to be applicable to the same user requesting access over a smartphone. The various components of context provide the means by which the appropriate policies are enforced and applied at the right time to the right client for the right application.

It is context that provides the unique set of parameters that enfolds any given request. We cannot base decisions solely on user, because user may migrate during the day from one client device to another, and one location to another. We cannot base decisions solely on device, because network conditions and type may change as the user roams from home to the office and out to lunch, moving seamlessly between mobile carrier network and WiFi. We cannot base decisions solely on application, because the means and location of the client may change its behavior and impact delivery in a negative way.

When you put these axioms into action, the result is application delivery. A comprehensive, holistic and highly strategic approach to delivering applications. It is impossible to say application delivery is these five products delivered as a solution because whether or not those products actually comprise an application delivery network depends on whether or not they are able to deliver on the promise of these three axioms of application delivery.

Connect with Lori: Connect with F5:

Related blogs & articles:

The Pythagorean Theorem of Operational Risk

DevOps. It’s in the Culture, Not Tech.

Ecosystems are Always in Flux

The Impossibility of CAP and Cloud

Who In The World Are You?

Operational Risk Comprises More Than Just Security

At the Intersection of Cloud and Control…

IT Services: Creating Commodities out of Complexity

What is a Strategic Point of Control Anyway?

Technorati Tags: F5,MacVittie,application delivery,application delivery axioms,performance,security,availability,operational risk,architecture,platform,context-aware,blog