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 1 / 2   >   >>
hotellyon
50%
50%
hotellyon,
User Rank: Apprentice
6/16/2014 | 10:47:15 AM
Confusion...
I think a great deal of our confusion comes from the use of SDN as a blanket term for virtualization and software-driven networking, which we know is a bit of a sticky point in various camps these days.
Réservez votre chambre d"hôtel sur Lyon : Hôtel Lyon: Trouvez votre chambre d'hôtel à Lyon au meilleur prix !
AbeG
50%
50%
AbeG,
User Rank: Black Belt
6/14/2014 | 11:47:09 PM
Perhaps, redefining the use of VLAN
This article brings up a some great points -

"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.""

I see this as being cosistent with a pattern that is historically common in IT.  Over the years, IT has experimented with the placement of control over applications, services, and resources at various levels.

For example, a standalone device can have a firewall that controls its security.  It can also be connected to a computer that is either responsible for that security or adds a second layer of security (complexity?).  Further layers of security/complexity can be continually added, especially with the advent of cloud printing as far as this particular example goes.

"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."

 
rubyliu
50%
50%
rubyliu,
User Rank: Apprentice
6/12/2014 | 12:35:51 AM
Re: SDN-Powered
I personally lean towards either FabricPath or L3 for the datacenter, to get to that simple but robust network fabric. Yes, TRILL is the multi-vendor standard, it seems to have potential scaling issues compared to FabricPath (amount of MAC learning by the TRILL fabric switches).

There's a certain irony to the fact that as of maybe 2 years ago we were hearing "flat datacenter, VLANs go everywhere" from vendors, and now with VXLAN, we may be starting to hear "L3 datacenter". Off discussion, if any answer, you can search my facebook page as "Lau Marrine"
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
6/9/2014 | 1:33:08 PM
Re: SDN-Powered
>Sure, you can slap my wrist, but I don't think I'm horribly out of line.

 

Sorry - my bad sense of humor not playing well in text, I suspect. I have an ongoing amusement about Software Defined Anything, and this was supposed to be a playful slap rather than a serious rebuke :-)
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
6/9/2014 | 1:16:03 PM
Re: Firewalls
Today, with BYOD the problem is much worse. Sure, perimeter firewalls are necessary, but at this point it's shocking how much reliance is *still* put on them when even in 1999 it was fairly apparent they had a very limited utility. Defense-in-depth is still a key watchphrase, and I think de-perimeterization of security should be another one.

No arguments about defense in depth; if you choose to expose a port - any port - using a firewall, it doesn't inherently make that port secure as a result; the port/service itself is just as vulnerable as if there were no firewall at all... 

 

I don't think virtual firewalls are necessarily a help either.

In and of themselves, I agree that they aren't any better or worse than a hardware appliance, but the idea of something you can spin up anywhere can at least help change the accepted thinking about where to deploy security devices. But as you say, not the solution in an of itself, for sure.
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
6/9/2014 | 11:45:02 AM
Re: Terminology
Obviously in a 700 word article, some nuances are lost. I did use SDN as a short hand to refer to what is technically "network virtualization", which uses encapsulation protocols such as VXLAN, NVGRE, etc. to create the logical "data plane."

 

Randy, thanks for the clarification and expansion of your points; I really appreciate you taking the time to do so. As somebody who rarely gets to the point in less than a thousand word, I totally understand the challenges of keeping to a word count and still getting a point over as unambiguously as one would like!
Susan Fogarty
50%
50%
Susan Fogarty,
User Rank: Strategist
6/9/2014 | 10:57:51 AM
Re: SDN-Powered
LOL, thank you for the excellent and lucid comments here, gentlemen. It is certainly difficult to debate these points, especially in text, which is many time a very limiting venue for discussing very fine points that might be better visualized.

I think a great deal of our confusion comes from the use of SDN as a blanket term for virtualization and software-driven networking, which we know is a bit of a sticky point in various camps these days.

I must say, we at NWC may borrow this SDN sticker and award it to others as well. It is definitely editor-approved :)

 
rbias570
50%
50%
rbias570,
User Rank: Apprentice
6/9/2014 | 1:07:20 AM
Re: SDN-Powered
Sure, you can slap my wrist, but I don't think I'm horribly out of line.  In fact, I mangled SDN far less than most.  Like cloud, I haven't seen a hard and fast definition of "SDN" that is widely accepted, although certain key concepts are certainly agreed upon.

I don't mind you taking me to task on misusing the term; however, I don't think I really did nor did you really point out something horribly inaccurate.  As to the phrase I used, "Distributed, SDN-powered, stateful firewalls", what I was referring to was that a network virtualization system coupled with dynamic programmable network configuration, leads to the ability to use techniques like service chaining to wire virtual stateful firewalls into the cloud fabric in a way that was previously quite difficult.  Hence the SDN-powered.  It's a short hand, but not one that is grossly out of line.

Regardless, I'm grateful for your comments and the opportunity to further clarify this article.
rbias570
50%
50%
rbias570,
User Rank: Apprentice
6/9/2014 | 12:58:51 AM
Re: Firewalls
Calling them "worthless" is possibly an overstatement and certainly designed to grab the reader's attention. I would argue the former and I would say that the latter is within my purview for making the article worth reading.

As far as perimeter firewalls being worthless...

In the late 90s I was the director of engineering for Checkpoint's #1 reseller on the west coast. We received numerous awards from Checkpoint. At it's height we were installing a pair of HA perimeter firewalls twice a week and then managing those firewalls under a managed service agreement. We managed several hundred firewalls month to month. I was the principle architect and creator of this product and service.

In my experience, most of the firewalls that I put in could be relatively easily subverted because the firewall rules did very simple port-based filtering. An attacker could breach a system via this port and then use the "pinholes" (e.g. port 80, 443, or UDP on 53) to expand access. This approach to restricting port access to a set of pinholes is as useful as a deadlock on the front door of your home. It will keep the casual intruder from entering, but for anyone serious, it's little more than a diversion at best. Given the level of state sponsorship in today's world, perimeter firewalls are "worthless" in my opinion.

Sure, you need them because they provide the basic front door lock, but for the majority of cases that are most important they may in fact provide a false sense of security, which is dangerous. Perhaps worse, is that the perimeter is really difficult to define and therefor hard to truly secure. One might even go so far as to claim the perimeter doesn't exist.

I talked about this as far back as 2003 in my first attempt at blogging that was security focused:

https://web.archive.org/web/20040820064714/http://www.randybias.com/archives/000021.html

Today, with BYOD the problem is much worse. Sure, perimeter firewalls are necessary, but at this point it's shocking how much reliance is *still* put on them when even in 1999 it was fairly apparent they had a very limited utility. Defense-in-depth is still a key watchphrase, and I think de-perimeterization of security should be another one. I don't think virtual firewalls are necessarily a help either.
rbias570
50%
50%
rbias570,
User Rank: Apprentice
6/9/2014 | 12:37:18 AM
Re: Terminology
Your observations are valid and reasonable. I appreciate you bringing to the attention of the audience that SDN is a complex subject. Obviously in a 700 word article, some nuances are lost. I did use SDN as a short hand to refer to what is technically "network virtualization", which uses encapsulation protocols such as VXLAN, NVGRE, etc. to create the logical "data plane."

SDN, like cloud, can be a messy place with people with a lot of positions, but I think the generally accepted definition of SDN is that it has two parts: network programmability and network virtualization. Essentially the control plane and the data plane, which are becoming functionally separate. SDN includes both items and to some degree it can be confusing the way I equated it to the network virtualization component only. In terms of equating SDN to the physical underlay, that was not my intention. The verbiage could have been better, but the intent of the specific sentence you called out was to say that network virtualization, a subcomponent of an entire SDN solution, is the mechanism by which we create a logical overlay that can be separated from the physical underlay via the virtualization (encapsulation) of your choice.
Page 1 / 2   >   >>
Hot Topics
7
Understanding IPv6: Link-Local 'Magic'
Denise Fishburne, Cisco Champion,  7/24/2014
6
Guide: The Open Compute Project and Your Data Center
James M. Connolly, Editor in Chief, The Enterprise Cloud Site,  7/21/2014
4
Network Security: An Oxymoron In The Cloud Era?
Rajat Bhargava, Co-Founder & CEO, JumpCloud,  7/22/2014
White Papers
Register for Network Computing Newsletters
Cartoon
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