Industry Solutions and Trends
Technology is more than just networking and Juniper experts share their views on all the trends affecting IT
Packetdiscards

SDN and why security should be part of its DNA, not an afterthought or overlay.

by Packetdiscards ‎08-16-2012 03:04 AM - edited ‎08-16-2012 03:09 AM

As an attendee at a recent conference on Software Defined Networking (SDN), it was quite telling that many of the presenters opened their discussion with their interpretation of a definition for SDN. Given some of the hype and recent industry activity (such as VMWare’s acquisition of Nicira), it is easy to forget that this is still very much a rapidly evolving area of development in the IT industry. Even some notable presenters such as Bruce Davie (VMware/Nicira) made light of this fact in describing the SDN “bubble” in that whilst everyone is talking about “it", what "it" actually is has not yet quite been agreed upon.

 

I suspect I am not alone as a relative newcomer in trying to figure out what the actual practical use-cases for SDN actually are (worth seeing Pradeep Sindhu’s discussion of the topic on YouTube). For me, it is identifying the application of the benefits that this new technology brings to real-world deployments that is most important to understand - Google appear to have been able to figure this out, but how does this translate for the rest of us?

 

 

One thing that SDN has brought to the fore is that there is a need for the ability to couple a software abstraction layer (the bit that provides the application to provide the service) with the underlying infrastructure (e.g. the blue/grey/green boxes that move the bits and bytes from A->B). Indeed the ability for a user application to create state in the network via a control tier is something that has quantifiable value - for instance, in a consumer environment, the ability to add new services to their existing offering on-demand via a web-portal, is something that improves ARPU for the service provider and potentially reduces subscriber churn etc. However, we have been able to do this for some time now, and long before the whole SDN hype cycle started.

 

So, what is it that seems so special about SDN - and why now? One perspective is that it is the creation of dynamic (real-time) state in the network that appears to be the attractive quality that we see in this technology - or in fancy terminology is ephemeral state. Another point of view is the ability to create overlay network domains that can be abstracted from the underlying infrastructure helping cloud providers scale their platform. Indeed, given the capabilities that SDN could bring, there are some use cases within the data centre environment that definitely could benefit from SDN and more specifically OpenFlow.

 

We have had protocols such as NetConf, which have been around for some time now and indeed what some are describing as SDN, the likes of standards bodies such as the IPSphere forum have tried before to at least partially address. Furthermore, there are many cloud service providers today that have Infrastructure as a Service (IaaS) platforms deployed that pre-existed the recent SDN hype. One characteristic of both of these however, is the way in which we create network state based on the definition of a configuration, and it is the application of that configuration that creates this state information (e.g. provisioning of a VLAN or an ACL in a switch or router isn’t dynamic, but instead is generated through configuration of a network element). Whilst achieving the desired aim, this typically involves a significant overhead and therefore time to create this state. Indeed, this becomes a barrier to the type of dynamic environment where we may need state to be created in near-real-time or on demand (such as during a vMotion event or live migration of a virtualised workload).

 

Of course there are ways to simplify the configuration aspect and this might be made even more accessible through standard API’s etc, however without dynamic state, these are still constrained. Now contrast this with a routing protocol where the protocol is applied through configuration, but the state is created through dynamic propagation of routing information. This provides a means to carry lots of state, respond quickly to changes and is proven to scale massively.

 

What OpenFlow seems to bring is the ability to get the best of both worlds - application driven, flexible control of the underlying infrastructure with the fast, dynamic properties that we associate with forwarding-state creation coupled with a centralised model for distribution of this information. Whilst the debate remains lively and shows promise of moving the industry towards standardisation of the protocols to solve this problem for the networking function, this however is only part of the problem.

 

Getting us to where it begins to solve real challenges such as dynamic workload mobility etc, it is interesting to note that security needs often don’t feature in the discussion.

 

When we talk about the data centre it is often synonymous with the cloud. More specifically, for our service provider customers, this means dealing with the challenge of multiple tenants sharing the same infrastructure within a common facility. Furthermore, whilst industry analysis may vary, in general security concerns tend to come in as one of the top inhibitors towards cloud adoption so it is an issue we need to address.

 

Indeed if we look at the OpenFlow spec, one may be forgiven to think that our 5-tuple is sufficient (ref table 3 on p.8: there are 15 match fields in total, but in a DC environment, the ACL is still likely to be based on the 5-tuple). However, for some time now we have seen the benefits for of additional match conditions such as the zone construct for partitioning of security domains to provide multi-tenancy on physical infrastructure (indeed other vendors have adopted similar concepts into their platforms).  

 

Of course, the issues don’t stop with just simple ACL creation. Today we see advanced application-layer firewalls with complex policies that need to extend from the hypervisor and be VM aware, to service per-application/per-user controls. Therefore, whilst it is good that OpenFlow does have the extensibility to potentially support these in future, it is useful to note what can be accomplished using the standards as they are today.

 

From a Juniper perspective, there is already an elegant solution to providing programmable multi-tenant environments within the data centre in the form of Virtual Gateway (vGW).  Of course, there are solutions from other vendors that also aim to address the same problem domain, however the reality is that today there are no standards-based solutions today to address the problem that solutions such as these hope to solve - something that SDN and specifically OpenFlow is positioned to address at the networking layer.

 

Whilst it is early days for this technology and we are taking the steps forward to realising the value of SDN, maybe there is an opportunity to also incorporate support for upper-layer functions, and specifically some form of additional security policy in the future - therefore making security part of the SDN DNA and not an afterthought or overlay.

Post a Comment
Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Labels
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.