The goal of CORD (Central Office Re-architected as a Datacenter) is to bring the efficiencies and economies of the virtualized data center to the service provider edge. Security, of course, is central to the initiative.
ONF/Open Networking Lab CTO Larry Peterson, in the first part of a Q&A with Telco Transformation, says that doing this involves an end user access dimension not required in the data center. Security, of course, is central to this. Peterson is also CORD's chief architect. After starting out as a use case for ONOS, CORD was put into open source last year with the Linux Foundation. (See CORD Becomes New Open Source Project.)
Telco Transformation: What is the conceptual approach to security in CORD?
Larry Peterson: I think the fundamental approach is to try to adopt the practices that Google and Amazon have adopted for their clouds. CORD is about making the access network of the network operators -- the telcos and cablecos -- as much like a cloud as possible.
The cloud differs only in that it also offers access to the service, which typically the commodity clouds don't. It's probably smaller, not warehouse size, and at the very edge of the network. But, in terms of security, the model is almost entirely "Let's do this the same way Amazon would have secured applications in EC2 (elastic compute cloud)."
TT: What are the building blocks of the approach used by the Amazons of the world and by CORD? What characterizes that security?
LP: I think leveraging SDN is the critical aspect, rather than depending on human operators to by hand-configure subnets, switches and routers. You automatically spin up virtualized private networks. They are virtualized private networks that use SDN capabilities to program the switches' programmatically to enforce the isolation that keeps user A from interfering with or invading the privacy of user B.
TT: Is the actual security that keeps those people from bumping into each other different in SDN? Or is it just that in an SDN network it's automated whereas in a legacy network it's done by human beings?
LP: Conceptually they're very similar. The details in the actual packets that get sent around will vary. But conceptually you're asking SDN to set up a private network between a subset of entities that need to cooperate to get some work done. You could have programmed a subnet by an appropriate Cisco command line interface, for instance.
TT: Where does NFV fit into this?
LP: NFVs are the functions that are being stitched together securely using SDN. So one of the places where the cloud is different than the telco is this notion of NFVs as something special. So you might go into Amazon's cloud and find a database, a storage system, SDN services and so on.
So the question is: What are the services that the telcos would have at the edge of the network in something like CORD? They might very well be exactly like those scalable services in Amazon's cloud, but they also then have NFVs. These are functions you would not have found in Amazon's cloud because Amazon didn't have to worry about access. But at the edge you do have to also provide access. That was a very long-winded way of saying the things that you are securing are in fact the NFVs.
TT: At the end of the day, could this be a more secure environment than a manual non-virtualized environment?
LP: Absolutely. I think that is part of the value proposition.
TT: How does security evolve in CORD?
LP: I would say that the fundamental thing that is happening in CORD that is a little bit unique is the notion that we have a declarative model for every aspect of the system -- at least that's the goal -- and we can apply policies to that abstract layer of modeling.
I think of CORD as having certainly all the appropriate physical resources like switches and servers and so on, but of course it's also running a set of virtual machine images, microservices running in containers and programs to program the switches. All of that software is written by many different people. It uses different programming languages. It's managed in many different ways. It's a very ad hoc process to apply global security policies to something like that. What CORD has done is put a layer on top of all of that software that allows you to define what behavior you expect from those subsystems in a very uniform way.
That's the model. It's independent of how the software is actually implemented, whether it's ultimately executing instructions on an x86 architecture or executing instructions on a Broadcom chip and a switch. These are details way down below. They all look alike from a modeling point of view. Then you can apply policies to those models.
TT: You told them what it has to look like once it gets to that higher level in order to be there?
LP: Yes. Implementation choices you've made as a developer are all your business. We ask that you express the behavior of your system with this declarative model and then that gives the operator a target to go write policies to.
TT: What are some of the earmarks of what this must look like?
LP: These subsystems that are providing the scalable services and so on need to be configured so that when they come up for the first time there are parameters set on their behavior. So that's kind of a configuration time. It's service wide. That includes who they may talk to, what other services they may depend on.
As users start to use the service they may want to control of individual sessions. We think in terms of a configuration time on service-wide basis and control on a per-user per-subscriber basis.
TT: Could you give me an example of that?
LP: At configuration time I might want to have an OLT device as an access point for a fiber from the home service that can support 10,000 customers. Some parameters are set. It could be to give no customer more than 10 megabits a second or a gigabit or whatever. So these are system-wide parameters. Then at run time any given user, when they connect from home, may be willing to pay for a megabit, they may be willing to pay for 5 megabits. They may want parental controls turned on for their kid's iPad or they want to turn it off. Those are all per-subscriber controls. So these declarative models define what those parameters are. What can be configured? What can and cannot be controlled?
— Carl Weinschenk, Contributing Writer, Telco Transformation