Even so, an ongoing concern has been whether our technology infrastructure is ready for IPv6. Rainer Enders, CTO of NCP engineering, posed this very question last year in the column “We Need Infrastructure Before IPv6 Becomes a Real Problem” on CTOEdge. Drawing upon his personal experience, Enders illustrated the stark technical reality facing IPv6 implementation:

I live in Walnut Creek, a community less than 30 miles from San Francisco — arguably, the epicenter of technology and innovation in the world. And yet, my community isn’t yet equipped to handle IPv6 or high-speed Internet protocols. If we — just a stone’s throw from Silicon Valley — can’t transition easily to technological innovations, how can we expect anything more from the rest of the country? 

Now, in an encouraging next step, the Internet Society has announced that “Major Internet service providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012,” reports ZDNet’s Steven J. Vaughan-Nichols.

He adds:

In a statement, the Internet Society’s CTO, Leslie Daigle, said, “The fact that leading companies across several industries are making significant commitments to participate in World IPv6 Launch is yet another indication that IPv6 is no longer a lab experiment; it’s here and is an important next step in the Internet’s evolution. And, as there are more IPv6 services, it becomes increasingly important for companies to accelerate their own deployment plans.”

What this means, exactly, according to the Internet Society is that ISPs participating in World IPv6 Launch will enable IPv6 for enough users so that at least 1% of their wireline residential subscribers who visit participating websites will do so using IPv6 by 6 June 2012. These ISPs have committed that IPv6 will be available automatically as the normal course of business for a significant portion of their subscribers.”

VPN Haus: What impact will the Android 4.0 “Ice Cream Sandwich” have on the device’s core VPN functionality?

Tim Felser: VPN functionality in “Ice Cream Sandwich” was extended to support native IPsec connections, using XAUTH for user authentication. With this new option, it is possible to connect to IPsec gateways without any problems.
By using this API, it is also possible for you to implement your own VPN features. However, it remains to be seen if the device manufacturers integrate this API into their devices.

VPN Haus: Until version 4.0, no integrated IPsec VPN client was available on Android. What

technical challenges were possibly precluding this functionality?

Felser: There were no technical reasons why prior Android versions did not have native IPsec functionality. In versions before and including 4.0, Android’s IPsec functionality is provided by the IPsec-Tools, namely the raccoon service responsible for Internet Key Exchange (IKE) negotiation.

VPN Haus: Can you tell me about the tests that NCP conducted in which an Android 2.2’s integrated VPN client—based on PPTP or L2TP—was used in lieu of “real IPsec”? What are the key lessons learned for the enterprise?

Felser: In Android 2.x and 3.x, the integrated VPN functionality was limited to the following modes: PPTP, L2TP and L2TP over IPsec. These protocols are used to connect to Microsoft Server systems. We just concentrated on L2TP over IPsec because NCP’s software is capable of processing these protocols. The connection works as follows: first, an IPsec connection is established; this one is used for encryption. A plain IPsec connection is not good at authenticating a single user, so that’s the job of L2TP. So after the IPsec tunnel is established, the user is authenticated via a L2TP negotiation. A design flaw in Android leads to a security hole: L2TP and IPsec are not closely linked, so L2TP negotiation simply starts two seconds after IPsec was triggered, independent of a successful result of the IPsec negotiation. This may lead to plain unencrypted L2TP packets visible in the Internet. Fortunately, authentication is done via PAP or CHAP, so no plain text passwords are transmitted, just the hash values hash.

Result: We adapted our VPN gateway in order to establish this connection. However, this wasn’t a huge effort on our part, since we already supported both protocols beforehand.

Beyond the recent consumer-oriented, high profile hacks to celebrity address books, the danger to enterprises is being laid bare in a more subtle manner. In May 2011, Juniper Networks published a study that found risks to mobile phone security at an all time high, and cited a 400% rise in malware against the Android, for example. In 2008, critical mobile SSL VPN vulnerabilities were discovered by Christophe Vandeplas, as a laboratory example of the man-in- the-middle (MITM) exploit.

In mid-March 2011, after Comodo issued nine fraudulent certificates affecting several domains, Microsoft issued updates for its PC platforms to fix the vulnerabilities, but the company’s patch for Windows Phone 7 was  not immediately available. More details surrounding this attack were outlined in Myth 1. But clearly, the priority is not currently on the mobile platform, creating an undeniable threat.

By Nicholas Greene

Microsoft does have its own mobile solution, which integrates swimmingly with DirectAccess. Trouble is, in the world of enterprise…the Windows 7 Phone is a small fry- holding only around 6% of the market. The top dogs are: Android, Apple and Research In Motion, and Android. Yet DirectAccess doesn’t offer support for any of them.

With this in mind, the lack of support for non-Windows mobile devices seems a rather obvious crack in DA’s armor. This, perhaps more than anything else, is what marks DirectAccess as unfeasible when compared to a standard VPN setup. It’s simply foolish to assume that every single employee will be using the same mobile device, and even more-so to think that said device will run Windows.

While a traditional solution might be a little more complex than DirectAccess, it’s also considerably more flexible in its implementation. Take NCP Engineering’s suite of solutions, for example- users can connect from virtually any device, regardless of operating system. What’s more, their Secure Entry Client supports both IPv4 and IPv6.

It’s also worth considering the idea that, as IPv6 becomes more prevalent, traditional VPNs themselves might evolve to adapt to the new features. The reason many of our remote computing solutions have the potential to cause such headaches for IT lies in IPv4’s own disadvantages and failings. Since it’s currently the dominant protocol suite, it needs to be accommodated- regardless of how painful that accommodation might be for the end user.

There’s a fairly distinct possibility that, by the time IPv6 is common enough for DirectAccess to be a completely viable remote networking solution, other VPN providers may well have produced something similar. If Microsoft hasn’t expanded DA’s compatibility by then, it could well be those providers who put a nail in DirectAccess’s coffin- and not the other way around.

It’s been called “The Death of VPN.” It’s been placed on a pedestal as one of the best available solutions to our VPN woes. But, on taking a step back, does DirectAccess  actually deliver on its promise?

Two months ago, VPN Haus ran a story asking just that. What that article found was telling- more and more, experts are saying no. While it’s certainly flexible, powerful, and packaged with a plethora of encryption and authentication options, DirectAccess decisively lacks the comprehensive features to be an all-in-one solution. Aside from only running on Windows 7, this “flexible alternative” is, ironically, more than a little inflexible when it comes to implementation, with a list of requirements a mile long, including mandatory IPv6 implementation.

Proponents of DirectAccess might postulate that it’s possible to circumvent the “mandatory IPV6 rule” by installing Microsoft’s Forefront Unified Access Gateway over DirectAccess to handle VPN requirements- installing most of the required infrastructure for DirectAccess in the process, as well as NAT64 and DNS64.

Of course, this brings to the table a whole new gallery of issues, mostly related to flexibility and client management.

If you decide to install UAG so that you can use DirectAccess over IPv4, The built in firewall will be disabled  and the Microsoft Forefront Trust Management Gateway will install. This offers full support for IPv4 — but no support for IPv6.  Not only that, NAT64 offers no support for reverse NAT mapping- so client management becomes a considerable challenge.

On the other hand, if you install DirectAccess into Windows Server 2008, the built-in firewall will be able to support IPv6. Unfortunately, this comes with a rather crippling caveat –  the firewall will only enable inbound or outbound rules.  In other words, you won’t be able to get any IPv6 traffic past the server.

Either way, there’s the potential to cripple- or at least considerably hobble- your network in some way. This is particularly true if you’re using a non-Microsoft firewall for security. If you are, well…good luck implementing DirectAccess. You’ll need it.

The fact that DirectAccess absolutely requires Windows 7 and Windows Server 2008 R2 with PKI access is extremely problematic for any non-Microsoft devices- and that includes mobile devices. Consider that for a moment- if you’re using a tablet or smartphone, you’re going to have a very, very difficult time connecting via DirectAccess. Even Microsoft’s own mobile offerings are, at the current juncture, incompatible.  This is a huge hurdle, especially in age when many are trumpeting mobile as the future of enterprise.  DirectAccess, meet the Bring Your Own Device craze. You two aren’t going to get along.

Skype uses SSL and Advanced Encryption Standard (AES) hashed with the RSA security algorithm for its public key cryptography. The details of how this combination is dismantled as a security model are explained in Myth 3 and Myth 6 in our series on debunking SSL myths. Suffice it to say that Skype is not nearly as secure as people think. As we saw in Myth 5, the public key cryptography is susceptible to the infamous MITM attack. As a result of these revelations, Skype and Facebook users need to be very concerned about what they disclose in their personal and business conversations.

The net effect of attacks against the trust model for mobile certificates and use of Skype should leave CIOs and network security architects uneasy about SSL and using it to secure mobile devices and Skype within their network ecosystems. Employees are using them, and policies restricting mobile devices and Skype use are no longer effective or logical.

What do you think? Is Skype a secure communication channel for the enterprise?