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
Threaded  |  Newest First  |  Oldest First
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?
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.
aditshar1
50%
50%
aditshar1,
User Rank: Ninja
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.
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. 

 
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. 
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!
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.
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!
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.
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.
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
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!
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.
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 :)

 
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 :-)
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"
AbeG
50%
50%
AbeG,
User Rank: Ninja
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."

 
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 !
Slideshows
Cartoon
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
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
Twitter Feed