Networking

07:00 AM
Randy Bias
Randy Bias
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

SDN & Breaking The VLAN Contract

Software-defined networking disrupts the VLAN approach to network security. We need to embrace change and seize the opportunities SDN offers to improve enterprise security.

There is a big change coming in how we think about enterprise networks. Yes, it’s SDN, but more importantly, it’s a side effect of moving to SDN overlay technology within clouds. Such a move breaks down an implicit contract that has been at work in the enterprise for almost 20 years, what I call “the VLAN contract.”  

The VLAN contract exists between the networking team (or engineer) and the development teams (or developer). The implied contract basically says: “I will give you a network (VLAN) and it will be yours and only yours. It will not be routed nor filtered. The IPs assigned to you will not be used elsewhere. You are free to do as you please within your network, but once traffic leaves it, it is mine and the contract no longer applies.”

In fact, along with a hub-and-spoke security model, the VLAN contract is absolutely fundamental to how enterprises both design and think about networking and security enforcement. Unfortunately, cloud and, in particular, the application of SDN within cloud systems, fundamentally breaks the VLAN contract and introduces the possibility for significant disconnects between network engineering and developers.

As you know, SDN technology virtualizes the network infrastructure, separating the physical underlay from the logical overlay. What you wind up with is less a traditional 802.1Q VLAN and more of what is referred to as a “virtual network” to distinguish it from the hardware-based approach. The effect, however, is the same: You're handing out Layer 2 Ethernet domains to the customer (developer) who expects the legacy VLAN contract to apply.

Unfortunately, because SDN is a software overlay, many of the implicit contract items can be broken. For all you know, your network is actually being routed over a WAN. What will stop the security team from putting a global filter in place, even between virtual servers on the same virtual network, in the face of a wildly propagating worm? Nothing.

There is nothing wrong with the contract being broken. New technology and capabilities will always change the underlying assumptions around the systems we built. The problem is we are backing into this world rather than facing it head-on. Cloud and SDN are going to challenge us around security and networking in unique ways, while also creating unique opportunities.

For example, perimeter firewalls have been worthless almost since they became wildly popular in the late 90s -- the problem being that port-based filtering can only go so far. While there certainly have been notable advances in intelligent, protocol-based filtering, even that can eventually be subverted. It's an arms race. Security needs to be de-perimeterized and moved down closer to the data being protected.

Cloud and SDN provide interesting opportunities to advance the state of the art in security by embracing the change. Distributed, SDN-powered, stateful firewalls could enforce security between servers on the same network, something that was technically possible previously with a bridging firewall, but complex and difficult to maintain. Similarly, on-demand IPS/IDS could be leveraged using SDN. This is literally a whole new area of exploration.

The challenge is we have to run, not walk, away from our old ways of solving network and security problems. We must understand that fundamental underlying assumptions, such as the VLAN contract, are becoming invalid and that the existing hub-and-spoke perimeter security model is well beyond broken. Once we agree that this is the case, we can begin to think creatively about how to solve these problems in new ways using the enabling technologies of cloud combined with SDN.

Randy is the CEO and Founder of Cloudscaling, a leader in enterprise-grade OpenStack-powered products. A long-time expert on infrastructure, he has been working on high availability scale-out systems for decades. He is widely regarded as one of the most original and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
jgherbert
100%
0%
jgherbert,
User Rank: Ninja
6/7/2014 | 1:33:49 PM
SDN-Powered
"Distributed, SDN-powered, stateful firewalls"

 

Sir, may I take this opportunity to slap your wrist for yet another abuse of the abbreviation "SDN". I have joked on a few occasions that I'm just waiting for the product stickers to start appearing claiming that the product inside the box is "SDN Compliant". You have taken this to a new level, so please enjoy the first of a new run of stickers I'm having made up:

SDN Powered!
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
6/7/2014 | 1:15:41 PM
Firewalls
"For example, perimeter firewalls have been worthless almost since they became wildly popular in the late 90s -- the problem being that port-based filtering can only go so far. [...] Security needs to be de-perimeterized and moved down closer to the data being protected."

"Worthless" is an interesting claim and screams of reductio ad absurdum. Talk to Service Providers and they'd likely say that the primary reason for distributing firewalls closer to the protected service is one of scale. Otherwise they'd have firewalls at every ingress/egress point on their network. The reality is that the only way to cope with the traffic (both in terms of session count and bandwidth) is to move any protection towards a specific source and have more protective devices effectively running in parallel. This does suit the concept of virtualizing firewalls and pushing them out wherever necessary, and I do believe that over time the architecture for firewall deployment has definitely shifted. But to call edge firewalls worthless seems like a shock tactic rather than a well-considered evidence-based claim.
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
6/7/2014 | 1:08:56 PM
Terminology
Interesting post. I'm curious to hear a little more from the author, especially given his credentials, on one thing that stood out to me. These two quotes are in adjacent paragraphs:

 

"SDN technology virtualizes the network infrastructure, separating the physical underlay from the logical overlay."

"Unfortunately, because SDN is a software overlay, [...]"

 

Could you clarify those again for me please? In one you say that SDN is a software overlay, but in the other you imply that SDN in fact is both the physical infrastructure as well as a logical overlay. But when we talk about 'overlays' we're normally referring to encapsulation technologies like VXLAN or NVGRE; but SDN goes way beyond that. The article reads to me (especially in the context of the inclusion of WAN within those virtual networks) as being focused on encapsulated overlays controlled by endpoints, rather than necessarily the broader concept and capabilities of Software Defined Networking. Maybe the problem is that SDN is such a vague term it isn't helping here. I look forward to the clarification, thank you!
aditshar1
50%
50%
aditshar1,
User Rank: Apprentice
6/6/2014 | 5:46:02 AM
Re: Breeding Complexity
Is it you would like to make some what equal to MPLS environment here, keeping same IP with diffrentiated RD values.
Lorna Garey
100%
0%
Lorna Garey,
User Rank: Ninja
6/5/2014 | 12:56:35 PM
Oh, the irony
If you think about this at a high level, the irony of software eating the network (if not the world) messing with how dev teams have done business is going to give some admins serious schadenfreude. 
rbias570
50%
50%
rbias570,
User Rank: Apprentice
6/4/2014 | 10:14:16 PM
Re: Breeding Complexity
I think there are a number of ways to solve these issues.  I'm not sure that spinning up VMs always makes sense.  Firewall capabilities, for example, might be better handled as distributed capabilities running directly on the hypervisor, but with different rules per VRF, where a VRF maps to a particular customer, VM, or virtual network segment.

OTOH, real time analytics tools, for example, snooping/sniffing might be handled best as on demand VMs that are inserted into the data path.  IPS might be better off handled in a distributed fashion like firewalls above.

I concur that moving to a world of VM sprawl makes things more difficult and I'm certainly not advocating that approach.  I believe there are alternatives and this is a place where security and networking vendors can make hay.
pkerpan606
100%
0%
pkerpan606,
User Rank: Apprentice
6/4/2014 | 2:53:36 PM
Tear it all apart, put it back together again.
The way we think about it at CohesiveFT is that the bulk transport belongs to the network team, the physical/location-based VLAN belongs to the network team, but the logical VLAN (created out of NFV in our case) belongs to the application team. 

Your device identity used to be the MAC address, we all depended on it, and it anchored you to a location (some VMware vmotion stuff aside).  In the public cloud or virtual infrastructures you can't depend on the MAC address - they are made willy nilly by the virtual infrastructure. 

In overlay VLANs we make an address' cryptographic identity its MAC.  Move the crypto identity - you have moved the address - in many meaningful ways you have moved part of the app.  This allows an easy separation of location from network identity which creates interesting forms of flexibility.   It does though require that firewall rules live "in the mesh" or in the overlay and are distributed throughout the nodes controlling the overlay.  If you get the distributed ruleset right - then the overlay is even more cool, you can secure nodes of your application from each other regardless of what location the device runs in. 

 
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Strategist
6/4/2014 | 2:10:25 PM
Breeding Complexity
I like the notion of a VLAN contract and how that might change. I wanted to follow up on firewalls and IDS/IPS in an SDN world.

I can see how from a deployment perspective it will be a lot easier to spin up virtual instances of firewalls, IDS, etc wherever you need it. That's great, but I haven't heard anything about how to handle the operational burden this might entail. You might not have to rack a physical appliance, but you still have to configure it, make sure it meets policy, and then manage those configs (and handle all change requests as well).

Do you see this becoming a problem?
<<   <   Page 2 / 2
Cartoon
Hot Topics
7
VMware NSX Banks On Security
Marcia Savage, Managing Editor, Network Computing,  8/28/2014
5
How To Survive In Networking
Susan Fogarty, Editor in Chief,  8/28/2014
4
Real-World SDN, Lesson 2: Conquer The Enemy Within
Symon Perriman, Senior Technical Evangelist, Microsoft,  8/25/2014
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Slideshows
Twitter Feed