posted on Thursday, March 04, 2010 3:54 AM
The advent of virtualization brought about awareness of the need to decouple applications from IP addresses. The same holds true on the client side – perhaps even more so than in the data center.
I could quote The Prisoner, but that would be so cliché, wouldn’t it? Instead, let me ask a question: just which IP address am I? Am I the one associated with the gateway that proxies for my mobile phone web access? Or am I the one that’s currently assigned to my laptop – the one that will change tomorrow because today I am in California and tomorrow I’ll be home? Or am I the one assigned to me when I’m connected via an SSL VPN to corporate headquarters?
If you’re tying identity to IP addresses then you’d better be a psychiatrist in addition to your day job because most users have multiple IP address disorder.
IP addresses are often utilized as part of an identification process. After all, a web application needs some way to identify a user that’s not supplied by the user. There’s a level of trust inherent in the IP address that doesn’t exist with my name or any other user-supplied piece of data because, well, it’s user supplied. An IP address is assigned or handed-out dynamically by what is an unemotional, uninvolved technical process that does not generally attempt to deceive, dissemble, or trick anyone with the data. An IP address is simply a number.
But given the increasingly dynamic nature of data centers, of cloud computing, and of users accessing web-based services via multiple devices – sometimes at the same time – it seems a bad idea to base any part of identification on an IP address that could, after all, change in five minutes. IP addresses are no longer guaranteed in the data center, that’s the premise of much of the work around IF-MAP and dynamic connectivity and Infrastructure 2.0, so why do we assume it would be so on the client side? Ridonculous!
The decoupling of IP address from identity seems a foregone conclusion. It’s simply not useful anymore. Add to this the fact that IP address depletion truly is a serious problem – the NRO announced recently that less than 10% of all public IPv4 addresses are still available – and it seems an appropriate time to decouple application and infrastructure from relying on client IP addresses as a form of identification.
BUT WHAT ELSE IS THERE?
Cookies. Unique names. Device types. Browser. Tokens. Any combination thereof. In other words, user context. It’s not that we need to stop using IP addresses altogether, but we do need to stop using them as an authoritative source on their own. They are still, certainly, part of the equation but it’s not an idempotent one and especially when used for
security purposes it should be just one more piece of information used to make the determination to deny, allow, or grade access to application and network resources.
Developers are probably thinking “Hey, we use usernames and stuff, we don’t rely upon IP addresses anyway.” And that’s true. When I say “we” I mean primarily infrastructure, the underlying network and application delivery network solutions that provide security and acceleration and delivery functions necessary to ensure the fast, secure delivery of that application. It is the infrastructure that relies heavily on IP addresses and as virtualization becomes even more pervasive and ubiquitous across the data center, infiltrating every layer of the stack, it will become increasingly difficult to not only manage but rely upon IP address as a foundational identifier for user or application-specific policy enforcement.
Infrastructure simply has to evolve to operate on a more session or request-oriented boundary, taking advantage of the context in which requests are made, in order to properly apply the policies that will ensure security for user and organization alike. Solutions will need to become more application-aware, network-aware, and user-aware and in the event they simply can’t access certain variables necessary then it will be a requirement to collaborate with those solutions that do have that information, or use solutions that are already context-aware and have an underlying unified framework through which such information is leveraged.
Strategic points of control will continue to emerge within the data center; points at which context-aware solutions will be a requirement in order to take advantage of the necessary information from the network to the application layer to make critical decisions regarding access control to network and application resources. This is particularly true in cloud computing environments in which shared resources means shared risk, and IP address assignment is highly volatile.
Technorati Tags:
MacVittie,
F5,
context-aware,
infrastructure,
IP,
security,
application security,
access control,
virtualization,
network,
application delivery,
unified application delivery and data services