And I haven't even addressed the information security controls that should be in place. I am just talking about protecting the platform and protocols.
You can do what I described today by putting the parts together. It's not that difficult. But in the borderless world that Cisco envisions (and I tend to agree it is going to happen) is going to be much more dynamic. You won't be setting that stuff up manually. You won't be able to do so quickly enough. It's going to be automated. That is where you either need an all Cisco network (or it's partners) or a set of standards that aren't close to being developed. By the way, this vision applies to any vendor, not just Cisco. I'd put Juniper's security vision in the same boat.
It comes down to integration between disparate systems and that is the disconnect. It's hard enough to get vendors to sit down and agree on basic connectivity standards. I see a riff over TRILL and 802.1aq for multi-path support in networking. Cisco favors FabricPathand TRILL. Other vendors are lining up with 802.1aq. Comparatively speaking, multi-pathing is child's play compared to the integration required to protect the borderless network and then prove that the borderless network is in fact, secured. It's not just adding some ACLs to a firewall and creating a VPN. It's identifying what routers and firewalls need the ACL, and which ACLs to apply. Creating the userIDs and VPNs. Setting up the IDS/IPS monitoring and policies. Setting up other monitoring and logging policies. And then ensuring those policies are applied to your switches, routers, firewalls, IDS/IPS's, VPN system, log management, hypervisor, virtual machine, directory store and key manager. And then documenting that what you think you have in place is in fact in place. Do you have all those functions from one vendor?
Probably not. More likely, you have products from multiple vendors that have some form of API available and perhaps a few vendors may have actually done some integration, but I will bet it is pretty limited. And that's for a single vendor and/or partner. So here is my point: IT needs standards that define the protocols and message formats for communicating and automating those functions need to be developed and deployed. Those standards need to be robust and well defined so that they are predictable, interoperable and unencumbered by patents and other intellectual property claims. I am suggesting the scale of standards development work is on par with the standards work defining the Internet Protocol and all the enhancements and improvements. I think herding squirrels would be easier (and perhaps more fun).
Here's what's going to happen: Cisco or Juniper, the only two vendors I think have the scale of vision today, will be driving a lot of the standards work. I put my money on Cisco just because of the breadth and depth of their product lines and their footprint in the standards bodies and the market, but I wouldn't dismiss Juniper. They are going to push the direction of the standards because they will be working on them internally and they will want other vendors to come play in their sandbox. They will eventually start the standards work in the IEEE and IETF bodies with a ready made set of documents like they are doing with their Overlay Transport Virtualization protocols that other vendors, even competitors, can use. In the mean time, Cisco will be out in front with their own protocols with the plan to offer the ratified standards when they are ready, just like Flexfabric and TRILL.
