NETWORKING

  • 06/04/2014
    7:00 AM
    Randy Bias
  • Randy Bias
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    +
    Vote up!
    -
    Vote down!

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.