Cloud
is great at many things. At other things, not so much.
Understanding the limitations of cloud will better enable a successful
migration strategy. One of the truisms of technology is that takes a few years
of adoption before folks really start figuring out what it excels at – and
conversely what it doesn't. That's generally because early adoption is focused
on lab-style experimentation that rarely extends beyond basic needs.
It's
when adoption reaches critical mass and folks start trying to use the
technology to implement more advanced architectures that the "gotchas"
start to be discovered.
Cloud
is no exception.
A
few of the things we've learned over the past years of adoption is that cloud
is always on, it's simple to manage, and it makes applications and
infrastructure services easy to scale. Some of the things we're learning now is that cloud isn't so great at supporting application
mobility, monitoring of deployed services and at providing advanced networking
capabilities.
The
reason that last part is so important is that a variety of enterprise-class
capabilities we've come to rely upon are ultimately enabled by some of the
advanced networking techniques cloud simply does not support. Take gratuitous
ARP, for example. Most cloud providers do not allow or support this feature
which ultimately means an inability to take advantage of higher-level functions
traditionally taken for granted in the enterprise – like failover.
GRATUITOUS
ARP and ITS IMPLICATIONS
For
those unfamiliar with gratuitous ARP let's get you familiar with it quickly. A
gratuitous ARP is an unsolicited ARP request made by a network element (host,
switch, device, etc…) to resolve its own IP address. The source and destination
IP address are identical to the source IP address assigned to the network
element. The destination MAC is a broadcast address. Gratuitous ARP is used for
a variety of reasons. For example, if there is an ARP reply to the request, it
means there exists an IP conflict. When a system first
boots up, it will often send a gratuitous ARP to indicate it is "up"
and available. And finally, it is used as the basis for load balancing
failover.
Most
cloud environments do not allow broadcast traffic of this nature. After all,
it's practically guaranteed that you are sharing a network segment with other
tenants, and thus broadcasting traffic could certainly disrupt other tenant's
traffic. Additionally, as security minded folks will be eager to remind us, it
is fairly well-established that the default for accepting gratuitous ARPs on
the network should be "don't do it".
The
astute observer will realize the reason for this; there is no security, no
ability to verify, no authentication, nothing. A network element configured to
accept gratuitous ARPs does so at the risk of being tricked into trusting,
explicitly, every gratuitous ARP – even those that may be attempting to fool
the network into believing it is a device it is not supposed to be.
That,
in essence, is ARP poisoning, and it's one of the security risks associated
with the use of gratuitous ARP. Granted, someone needs to be physically on the
network to pull this off, but in a cloud environment that's not nearly as
difficult as it might be on a locked down corporate network. Gratuitous ARP can
further be used to execute denial of service, man in the middle and MAC
flooding attacks. None of which have particularly pleasant outcomes, especially
in a cloud environment where such attacks would be against shared
infrastructure, potentially impacting many tenants.
Thus
cloud providers are understandably leery about allowing network elements to
willy-nilly announce their own IP addresses. That said,
most enterprise-class network elements have implemented protections against
these attacks precisely because of the reliance on gratuitous ARP for various
infrastructure services. Most of these protections use a technique that will
tentatively accept a gratuitous ARP, but not enter it in its ARP cache unless
it has a valid IP-to-MAC mapping, as defined by the device configuration.
Validation can take the form of matching against DHCP-assigned addresses or
existence in a trusted database.
Obviously
these techniques would put an undue burden on a cloud provider's network given
that any IP address on a network segment might be assigned to a very large set of
MAC addresses. Simply put, gratuitous ARP is not cloud-friendly, and thus it is
you will be hard pressed to find a cloud provider that supports it.
What
does that mean?
That
means, ultimately, that failover mechanisms in the cloud cannot be based on traditional
techniques unless a means to replicate gratuitous ARP functionality without its
negative implications can be designed.
Which
means, unfortunately, that traditional failover architectures – even using
enterprise-class load balancers in cloud environments – cannot really be
implemented today? What that means for IT preparing to migrate business
critical applications and services to cloud environments is a careful review of
their requirements and of the cloud environment's capabilities to determine whether
availability and uptime goals can – or cannot – be met using a combination of
cloud and traditional load balancing services.
For
further information visit: http://cloudcomputing.sys-con.com/node/2469233
No comments:
Post a Comment