While one person's hobby might be scaling Mount Everest, efficiently scaling a datacenter while accommodating dramatic spikes in secure Internet traffic is another person’s job. In both cases, these tasks can present daunting challenges, but if successfully overcome, they also provide an immense sense of relief once accomplished.
Scaling and security aren’t just buzzwords -- they’re serious challenges for technology professionals responsible for deploying the next generations of the world’s networks.
If all types of network traffic presented equivalent difficulty, scaling could be efficiently addressed with the simple addition of more servers and routers. But what happens when some portion of the network traffic does not scale proportionally? The answer: Significant costs and power can be spent on a solution that might not be very efficient.
Coincident with the all of the talk about security, secure network traffic is truly growing. It could be driven by the fact that cybercrime is a double-digit growth industry, or the fact that corporate hacking continues to appear in news headlines.
While online retail and banking may be obvious examples, the fact that many of the largest companies in the world use or require secure traffic makes it clear that security is not just the concern of financial firms. The BYOD (bring your own device) revolution needs secure connectivity from non-enterprise devices into the enterprise, requiring smarter networks, which now must identify users, instead of just routing and sending data. Finally, the ongoing migration of IT to the cloud means that more users need to securely access their data and applications remotely.
With secure Internet traffic becoming ubiquitous -- regardless of its source -- next-generation Internet infrastructure must be able to scale with efficiency.
Back to basics: SSL and HTTPs
Many of us are familiar with the padlock icon that appears in our browser window when we are surfing the web. That lock appears when an HTTP session is secure. This type of session uses SSL encryption to establish a secure tunnel between the client and the server. Unbeknownst to the user, his PC has requested a secure connection with a server hosting the current page, and in return, the server sends a certificate with a public key. The client then uses the public key to encrypt a secret that’s sent to the server, so it can sign and verify that the sent secret originated from the certificate’s public key. At this point, a set of keys is mutually created and a secure tunnel is established.
All of these processes must take place instantaneously. For most, these processes are the mundane machinations of the Internet, thankfully kept out of sight of the user. But when you consider that the very existence of global commerce moving forward depends on these processes, it gets interesting pretty fast.
Computation associated with the public key math is special; special in a good way because it provides a standardized way to exchange a secret (essentially the secret is the code used to create keys to encrypt data each way). It’s also special in a bad way, in that the math is designed to be very difficult to break and can be extremely complex to compute. Public key math typically relies on modular arithmetic involving large prime numbers, which are typically 1,024-bit, 2,048-bit, or higher.
The computation of this math may slow down a personal PC at home for only an instant. But in the datacenter where public key transactions are aggregated, the challenge becomes apparent. Relying only on software to crunch these numbers quickly saturates the compute resources of a server. Scaling via the software approach can work, but requires load balancers and additional servers, translating to more cost, more heat, and overall inefficiency.