A History of iPass' Core Security Infrastructure—Part 1

In some sports, the strength of a team's defense often directly relates to the success of the team as a whole. For iPass, the success of the company and its ability to move forward and continually expand its services, would not be possible had it not been built upon a stable and reliable security infrastructure. As in many things in life, what you'll find is that simply sticking with the fundamentals is key to a winning strategy.

Vice President of Network Operations Security & QA, Peter Albert, provides some initial insight into the history and design philosophy of the Transaction Centres which represent the core of iPass' authentication fabric.

From the Beginning:
Early on, we decided to abandon the concept of the five 9's associated with "high availability" in favor of a design that strove to be "always available." Of course, most professionals in the industry would say that such an absolute as "always available" is not achievable. Maybe they are right. But that doesn't mean it shouldn't be a design goal.

So, setting out to design and implement an always available service infrastructure, we had to invent a few axioms from which to base the design:

1. No SPOFs (Single Points of Failure)
2. Corollary: The Rule of Three

The Rule of Three says that a deployment of systems should be done in groups of three, rather than two. If two systems are deployed, and one of them fails or is taken down for any reason, the resulting condition would be a single system running, which violates the first law above (No SPOFs).

So we deploy in groups of three which allow for a single system to either be taken down, or fail, and the resulting condition is still two operational systems—the first law above is fulfilled.

At first, this may sound gluttonous and wasteful, and it would be were the systems extremely expensive and not all being actively utilized. But in our case, we found a way to implement the Rule of Three with reasonably-priced equipment. And by enhancing the logic of our application layer, coupled with the introduction of load balancing logic in the fabric, we managed to leverage all of our Transaction Servers, hence, no waste.

You can find this Rule of Three applied in numerous ways throughout our service infrastructure.

Having created the axioms, the next task was to create some logic in order to determine where to deploy the Transaction Centres globally. Based on the Rule of Three, we divided the globe into three logical geographies: The Americas, EMEA and Asia Pacific. Again, based on the Rule of Three, we then looked within each geography to identify the three optimum cities to host the Transaction Centres.

There were several criteria used to make this selection:

• The City must be a major Internet hub
• The City must be within our Top 20 roaming destinations for our customers
• The City must be within our Top 20 source locations, from a customer perspective

Working with Business Operations to facilitate the data-mining exercise, we ultimately selected the following locations:

Geography 1: Americas
Cities: Santa Clara, Atlanta, New York City.

Geography 2: EMEA
Cities: London, Amsterdam, Frankfurt

Geography 3: Asia Pacific
Cities: Tokyo, Hong Kong, Sydney

Having selected the cities, the next task was to devise a set of criteria with which to choose a collocation vendor. Working with consultants, we created a rather extensive, detailed and stringent collocation provider criteria checklist. Many collocation suppliers we toured failed to meet all of the requirements and consequently were not selected. The checklist so devised actually went through a considerable lifecycle of its own.

Concurrent with the work being done on the geography and location selections, a concerted effort was conducted by our Architecture and Engineering departments to stabilize the existing Transaction Server application.

Though functionally operational, there were certain conditions which caused temporary conditions to occur, sometimes requiring manual intervention from a System Administrator. In order to achieve "always available," a rock solid application requiring no intervention was critical.

Many iterations of our core proprietary software were produced until the April 2000 timeframe—At that time, the protocol was finally redesigned, and a stable release was produced.

Tune in for more...
Gain additional insight into the inner workings of iPass through Peter Albert's next iPass Perspective feature as he'll delve into what's at the core of these triple-power Transaction Centres and more inside details.