I attended SC World Congress in New York this week and a keynote from Cisco caught my attention: Securing the Cloud: Building the Borderless Network. I became fixated on the words used over and over by Joel McFarland. Borderless this, borderless that, borderless everything. This campaign started to bother me as this was a security conference and a network company was pushing the idea of less borders. It seemed off, wrong, and incomplete to me.

Little Bit of History

I am going to quickly cover some of the history of the Internet and how it grew borders, but please skip to the highlight of the article if you are familiar with this already: Borderless Networks, What?

ARPANET (‘69-’91)

In the beginning, there was ARPANET which was the pioneer in packet switching networks and gave providers the choice of which method and hardware for communication it would use. However, the base protocol used for devices to communicate in ARPANET was NCP. The NCP protocol could best be described as a network device driver and less as a network transport stack. It did not have any method for end-to-end error handling which was seen as a problem, but nothing was done about this until 1983.

In 1983, TCP/IP replaced NCP as the protocol for transport and ARPANET became a part of what was to become the Internet. TCP/IP was a huge improvement over NCP in that it accounted for problems on the network and allowed the network not to come to a grinding halt when packets were lost. It also achieved the concept of end-to-end connectivity between each host. This meant that as long as two hosts were on the Internet they could reach each other by utilizing standard TCP/IP. This standard framework also lead to the growth of many different applications as there was no longer any need to make changes to the network to add new applications/protocols.

First Borders (‘91-’94)

All the building blocks were in place and what formed was a large group of interconnected networks to share and exchange data. Then the first virus and worm hit in 1983 and 1988 respectively. The morris worm gained a fair amount of media attention and in fact prompted the establishment of CERT. Even in this embryonic stage the vitality of the information being shared caused many researchers to begin placing limitations on the end-to-end connectivity of their hosts. Thus began the ‘Us’ and ‘Them’ status of the Internet.

‘Us’ and ‘Them’ started out simple with a move to keep networks segregated-or put another way, adding a border between the networks. At first, the borders were nothing more than routers that limited the effects from network A from spilling over into network B. They were effective, but in 1991 DEC released the first modern Firewall: SEAL. This marked the first real security border on the Internet, where all packets were inspected and compared to a set of policy rules before being passed on. These first security borders were instrumental in providing the trust and assurance in the network that companies and researchers required, speeding the growth of the Internet. While intrusion was still possible, the bar of entry was raised beyond causal attacks and probes.

Figure 1: Us vs. Them

In 1992, the dominant addressing of hosts was IPv4, where each host is a assigned a 32-bit address. This assignment limited the total number of addressable hosts to 4,294,967,296, but, due to reservations and subnetting, this could never be fully utilized. At this time, it was recognized that IPv4 limitations would be become a problem in the future, beginning the process of creating a new IP protocol with a much higher number of addressable hosts. IPv6 was born in 1994, based on a 128-bit address for each host. This would effectively allow every man, woman, and child on Earth to be assigned an address many times over. As a part of the formation of IPv6, security between networks was also taken into account and IPSec was created as a requirement of the IPv6 protocol.

IPv6’s creation gave the Internet a secure method of communications between networks via IPSEC and nearly unlimited address space, but IPv6 did not get off the ground quickly. This was mostly due to the fact that all devices and operating systems would need to be upgraded to handle the new protocol, and there was little to no pressure from the market to push things forward. IPSec on the other hand did take off, as it quickly became the standard method for interconnecting trusted networks over an untrusted medium (such as the Internet).

At the same time that IPv6 and IPSec were being developed, another group of people began working on an alternate method for dealing with the lack of addressable space in IPv4. Network Address Translation (NAT) was published in RFC1631 in 1994 as a short term solution, while the larger problems were being addressed. NAT became very successful quickly as it allows a very large number of hosts to access the larger Internet while using very few publicly addressable IP addresses. As with most things, NAT came with some trade-offs. One of the big ones was that hosts no longer had complete end-to-end connectivity. Thus, another border on the network was created; in practice firewalls became the dominate NAT devices. Nonetheless, the NAT border would create problems for applications developers for years to come.

Present (‘09)

In 2009, the way Internet runs is really not very different from 1994; IPv6 is just now getting underway, NAT is used everywhere, and IPSEC still secures networks over an untrusted medium. What has changed in a big way is the applications and uses of the Internet. Telephone calls commonly use the Internet for transport, on demand video is a huge source of traffic, social media networks garner huge numbers of users, online shopping is an important revenue stream for companies, and most recently more and more services are being hosted elastically on demand via the Internet.

Borderless Networks. What?

Now let’s get back to Borderless Networks…

Cisco envisions a global network where you can go any place and access any data you could need at anytime. John Chambers detailed the approach on a video at Cisco.com:

Cisco also has a Virtual event on Oct 20th for Borderless Networks, and have been encouraging people to register via twitter and emails for the last two weeks.

I first learned of the Borderless Networks push during the SC World Congress. I was there to get a preview of Borderless Networks as presented by Joel McFarland. The session description sounded interesting and as it was a keynote there was nothing else to pull on my time.

Two co-workers and I attended the session, but being a little late we had to make our way to the very front of the room to find seats. Up front we were able to hear and see everything in great detail, but in hindsight this might have not been the best place for us. There was no way Joel could have missed the looks of skepticism on all three of our faces.

Joel pushed the Cisco idea of Borderless Networks in many different ways, but pointed to the iPhone as the game changer, the beginning of things to come. Then iPhone and salesforce.com became his prime example of how the mobile sales team are almost completely disconnected from the enterprise network. They access leads, manage contacts, input orders, and exchange notes and information all without even logging into the corporate network. At this point, I looked to my co-workers with a questioning expression and whispered the rhetorical question “No corporate login?“.

The example Joel used is common for a sales workforce, and is actively encouraged in many environments, but this was just something that I have always felt was wrong. In many companies, sales leads are valuable information and something that competitors and even other sales people would actively try to gain access to. When all access to this information is controlled by an external party you are no longer able to apply your own controls. In fact, you are beholden to the policies and procedures of the provider. Joel was one step ahead of me on this. He pointed out the problems that were playing through my head and countered that salesforce.com can be made to use a corporation’s internal authentication methods (Active Directory, RSA Token, etc.). As such, your internal policies for access and removal of access are once again in your control. I conceded. Joel is correct that salesforce.com can be brought into line with one’s internal security policy, but he does not address the issue of the remote device-the iPhone itself.

Borderless

Let me come back to the iPhone in a bit, I want to point out another slide that came up during this iPhone praise. In Figure 2 I have created a combined version of the two slides Joel was showing to demonstrate the future of networking (I have recreated them from memory, but its close enough for this post).

Figure 2: Before & After

In Figure 2, we have the before and after sections. According to Joel, currently the before example is a good summary of how most enterprises networks allow access into and between their networks. This Joel and I agree on.

As seen in the before section, you have a defined entry point into the network from outside, where all external resources gain access. This is your border between “us” and “them“. In the examples, both the remote home desktop and iPhone access the network and are allowed across past the border only if proper authentication and authorization have take place. Once completed, the remote device is granted access to the resources that are allowed for it to function as an effective job tool: access to to internet via internal proxy, access of files in the London office, or logging into the salesforce.com website. The key thing is that all access flows through this single point of entry.

By restricting access for remote devices to a single point, we are able to overcome some technical shortcomings and greatly reduce the vectors of attack for the network. NAT is required due to the limited number of publicly addressable addresses. Thus end-to-end connectivity is not an option for the remote devices. The use of IPSec for transport and assigning a RFC1918 address to the remote device end of the IPSec tunnel allows one to overcome the NAT limitations. This gives you remote device end-to-end connectivity within the enterprise network. By using this method the network administrators are able to capture and monitor at a single point all access into and out of the network. NAC, IPS/IDS, and other methods of monitoring are commonly deployed here.

With the after diagram of Figure 2, we see the future as Cisco/Joel see it. This is where all resources are able to access all other resources; also known as complete end-to-end connectivity. Joel did not say how this was to be achieved, but given the network diagram it’s not hard to surmise that Cisco is planning a big push for IPv6. IPv6 will allow for this type of network, and will bring down the NAT boundary. With it the technical limitation of too few addresses for end-to-end connectivity on the Internet is eliminated and things can get a lot more complex as we see in the after section of the diagram.

On the after diagram you see end-to-end connectivity to each resource both inside the network and outside. We have an iPhone going directly to salesforce.com, directly accessing a file in the London office, and able to access all the data that it could ever need. What about limiting access to resources? How do you make sure that a remote home desktop does not start copying all of the data from the London office, NYC office, and salesforce.com to a remote site? What if the desktop is infected with malware? How do you log the activity of the remote device access? All the questions become much harder when you have completed end-to-end connectivity, and historically we have learned it becomes an even larger problem when there are remote devices involved.

All the questions I have asked about the security of the after sections can be answered with products already on the market and in fact are recommended for use in both networks. The problem becomes the scale that is needed to protect and defend a network that has complete end-to-end connectivity. Once again, going back to the after diagram, only taking into account remote device access, the number of policies that needs to be maintained, protected, and monitored goes from 1 to 4. Now a growth of 400% is big, but almost manageable. If you start to think about a small enterprise with 20 offices, 2 datacenters, and 200 remote users, the problem of scale is instantly untenable.

IPv6 will solve a lot of problems for networks as the need for NAT will go away and devices will be able to directly address each other across networks and boundaries, but as with just about everything there are side effects. Keeping control of access into and out your network is the first line of defense and with IPv6 this becomes a policy and enforcement issue even if it is no longer a technical requirement.

The iPhone, Key to the Borderless Network

Joel said he likes his iPhone and from the huge number of videos from Cisco featuring an iPhone it’s safe to assume Cisco does too. During the keynote Joel pointed out the iPhone a few times in a number examples and in general with heavy praise. Joel and I agree the iPhone is an amazing device, an important step forward in mobile computing. After this Joel and I begin to disagree, namely around one key point: “The iPhone is a game changer.” I think that statement needs to add “for the consumer market“.

Figure 3: The iPhone

iPhones are enabling users to use the Internet from almost anyplace; it’s one of the most popular cameras on flickr, has a huge list of applications, and, for some people, a complete replacement for the traditional computer. While its strong points work well in the consumer market, in the enterprise markets it’s a very different beast. In fact the strongest points for the iPhone in the consumer market are security concerns for the enterprise. Application controls are limited, centralized control is even more limited, and encryption of the data residing on the devices is a problem on the most fully featured phone to date.

Devices like the iPhone should be thought of less as a phone and more as a laptop. With that comes all the same protections and controls that we use to mitigate risk on an enterprise laptop. Here is a quick list of what I expect from a laptop and by extension from an iPhone for it to become a viable remote access device in the enterprise environment:

• Virus and Malware software with centralized reporting
• Secure communications for the device; both internal resources and the ability to define policies
• Strong Data Encryption on the device
• Ability to do remote kill of device
• Application installation and run controls
• Web Filter/Proxy controls
• Access controls, password complexity settings and password failure data destruction

Some of the areas listed are available on the iPhone, but none of them are near complete and ready for everyday use in an enterprise. Research In Motion (RIM) dominates the enterprise market for the reasons I have listed here. RIM via the BlackBerry Enterprise Server (BES) gives the enterprise complete control of every device that connects via a centralized management station. BES also does network traffic correctly in that all devices came back to the BES at a single point of entry into the enterprise. This allows an enterprise to place additional control directly attached to the BES and not with multiple devices all over the network. RIM’s BES product represents the minimum level of security that should be expected for remote access of phone like devices. I would go so far as to say it should be the starting standard for how remote access devices should behave.

The iPhone might be the start of things to come, but in no way is it even close to ready for the enterprise market.

Why?

Cisco’s push with Borderless Networks is either something that they haven’t completely vetted from a security perspective or the security strategy isn’t completely explained in the marketing. The huge increase in the number of points needing protection, the corresponding increase in the policy and management, and management data flow and access controls are areas that need addressing. These are problems we still having troubles controlling with our current network deployments. Unless Cisco has a magic bullet coming out of their research and development departments, I don’t see how this move to Borderless Networks is even possible.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action