SDN for Dummies – Part Drei

The fun is about to begin. Let’s look at a definition of SDN and some of the major components that make it unique.

Dreez Definition: Software Defined Networking (SDN): The ability to co-manage both the network and security components of a Cloud Infrastructure from a single centralized management platform through the use of automation (software scripting / orchestration).

I know…pretty deep….Let’s go through it one step at a time:

  1. Co-Manage both network and security of a Cloud infrastructure from a single centralized management Platform SDN is a layer of software that gives its transparency. SDN allows virtual guests to float between physical platforms with neither the guest nor the end user knowing what physical platform it is on. SDN will merge network management with security management. You see that a bit now in vCenter Security Manager. vcenter security manager So imagine in the future if you click on ‘Security’ and an MDS/Security Management Station pops up and all the VMware objects exist in that view.
  2. Through the use of software scripting (orchestration)EVERY!!! SDN platform has APIs that enable scripting tools to do whatever you can do in the GUI. If there is an SDN that does not, then it is NOT SDN. What does this mean. Massive unemployment for most of you reading this.Think of what happens now if you have to move a subnet from Chicago to New York. The routing geeks have to touch several routers and switches one at a time. The firewall people have to redo their routing and rulesets on two firewalls. The Load Balancing people have work magic.In the future with SDN this subnet move will occur with scripts. One person will write and execute a script making this whole move happen transparently.

Security  and Network Tags

So what is the mechanism that keeps keeps the security world organized? The glue is called Security and Network Tags. Each virtual guest has a tags that contains security and network information such as policy, encryption keys, IP information. When you ‘orchestrate’ your virtual world and create policy and encryption keys for the guests, the information gets stuck into these tags. vmtags Now notice it doesn’t matter where these virtual guests are running…no one knows except VMware and the administrator. These tags are what I call the operation context of a virtual guest. They allow the guests to float between physical platforms and maintain their current state and environment.

VMware Security Groups

Now for the best part with regards to security. This next image is so innocuous but yet is the heart of SDN that will ravage networking as we know it and could be CheckPoint’s/Tufin’s strength if they could swing it politically. This will make most of you reading this unemployed boat anchors, Cisco routing geeks bankrupt, network gear makers bankrupt….I think you get the picture.

securitygroup

[ crickets….]

So in VMware you can gather hosts into security groups based on characteristics of the hosts – and not just IPv4 addresses. Not really a big deal, you can do that on almost any management platform. But in a virtual orchestrated world grouping is the glue that keeps the management station from self destructing exponentially. Imagine 10 scripting manics generating 10000000000’s of objects in seconds – and then they quit and you get a new batch of 20-year-old scripting maniacs, et al. After a couple days your management environment will be out of control. You HAVE to use groups to keep the virtual world manageable. Now in the future groups will also change and be enhanced to manage the scope creep. There will be tagging, labels, etc. just like you see in CheckPoint’s R80 and Google gmail. But in the end, there will be several forms of grouping. I know, I know….Doesn’t look so powerful does it? So this is the crux of my rant. Currently both network and security geeks provide separation (grouping) via subnets. Once we created a subnet, we then can create a firewall rule to protect it. Notice below that all firewall rules are based on networking. securitysubnets

Now I was never sure how a subnet alone prevents Himachi/HeartBleed/etc from spreading throughout your network, but that’s what we do because that is what we have always done since the dawn of time (aside: subnets only stop broadcast storms). Like lemmings walking off a cliff we are planning our future based on what we have done in the past. But I claim in the future we will provide separation based on SECURITY GROUPS. (and not networking). A DMZ Security Group will be made up of DMZ machines and NOT a subnet. Remember from my Part Eins rant about how networking will change and routing will become less important. Well this is another nail in the coffin. We won’t need routing because the world is becoming L2 Ethernet (no IP addresses) and security groups (no IP addresses) and so without IP addresses who needs routing? And if The Cloud is hosted on a big Borg Cube, why do we even need classic IPv4 networks to transfer packets, it might just be some combination of virtual guest UIDs (instead of IPv4 addresses) and distributed shared memory communication. For example, in the old old days an operating system called Multics all communications were performed via distributed shared files. Everything was a file, even networking.

Next Gen Firewalls

Now start thinking about NGF. Policy rules are based on USERs/Machines and Services. So the rule looks like:

r80firewallrulebase

  • “John Adams” – Do you see any IP addresses? Does it have to be an IP address?
  • HR – Is this a subnet or a group of people or a group of machines? In SDN – who cares? Could be UIDs.
  • Facebook – Is this  a IPv4 port or a network protocol? In NGF it is a network protocol on ANY port

So even in NGF, you are starting to see the disappearance or the REQUIREMENT for IPv4 constructs.  People can be AD credentials, Facebook is a protocol not a port, HR could be a group of VMware objects imported from VMware and could be MAC addresses, could be UID’s or VMware security tabs created by NSX – Basically you don’t care what is underneath.

 Service Chaining/Traffic Steering.

Yet another nail in the Network coffin. In the virtual world, you don’t always depend upon IP routing to direct the flow of traffic. You can use Traffic Steering. Right now if packet X has IP 1.1.1.1 it will always go to router next hop 1.1.1.2.

In the virtual world, you can build rules that say “Traffic from Security Group X to Server Y, will always go through FirewallZ”. Do you see any IPv4 routing in that statement? What if FirewallZ is in Siberia on not on the direct subnet – doesn’t matter NSX will direct it to Siberia somehow.

traffic steering

TUNNELS

Notice that they are on the same subnet but in two different physical locations? How is this done? VXLAN!!!

vmtags

VXLAN is the magic tunneling protocol SDN uses to make virtual guests float. In the physical world subnets usually are in 1 physical location (e.g. DMZ is physically located connected to firewall). With VXLAN tunneling, you can have virtual guests all over the world on the same subnet, so they can float and maintain their same network/operational context.

vxlan2

How does it work? Well in the above, you can see 4 virtual guests in different geographic locations all on the same subnet 1.1.1.X. NSX keeps track of where the subnet is by a VNID (Virtual Network ID). In this case it is VNID 12345. NSX uses VXLAN tunnels by encapulating VXLAN packets inside UDP port 4789 packets.

Now tunneling is not the most efficient way of transporting network packets. If you have 2 high bandwidth applications talking to each other over a 4000 mile encrypted tunnel, chances are there will be lots of latency. But technology moves on and in time network bandwidth will be almost as free as water so latency will scale. Historically it always has.

What will blow up????

Let’s review a couple things…

  1. The CLOUD is not SDN and SDN is not The CLOUD. Slide8 The Cloud is where virtual guests are floating through time and space not knowing or carrying what physical platform they are on. SDN is the underlying infrastructure that magically allows them to float…securely. In the above picture SDN is NSX in vmWare land and ACI in Cisco land.
  2. SDN will change: In my definition in today’s technology ‘network infrastructure’ you might assume we will have routers, switches, IP addresses, load balancers, etc 25 years from now. WRONG. 25 years from now the ‘network infrastructure’ might be the backplane of an enormous gyrating Borg Cube with lights (aka ‘War Games’) with no network. All the virtual guests will be running in the Borg Cube and use distributed shared memory (vs. IPv4) to share data. Who knows? But those communication channels still exchange packets hence I use the term ‘network infrastructure’.
  3. The Cloud  – 10 years out I am trying to decide what The Cloud will look like 10 years out. If we go the Google route with 1000000’s of generic Linux servers, then you have to transport packets between systems. If you pack it all into a gigantic Borg Cube, you’ll have a pica-sec latency backplane with oodle’s of terabit/second throughput….but you will be wedded to an evil OEM. I’m will guess a enterprise will buy multiple Borg Cubes for redundancy because they want to be able to call 1-800-xxx-xxxxx and scream at someone if it blows up.
  4. Rapid Deployment – Rapid Destruction Kelman from CheckPoint’s quote. Scripts can deploy quickly and just as quickly destroy the whole environment. In addition you now have an even more concentrated group of employees with super uber admin privileges administrating the Borg Cube. One bad apple and your enterprise is gone.
  5. Single Point of Failure – The Borg Cube – Any failure in SDN internals or Cloud management will bring down the whole Borg. You know how firewall clusters only fail over in the perfect world? Same thing here.
  6. Orchestration – See Rapid Deployment Rapid Destruction
  7. Staffing – Need to know networking, security, scripting.
  8. Licensing – Will be interesting how licensing models will change. Currently licensing is based a lot on IP addresses. Also licensing is based on the physical world..deploying 400 firewalls is a big deal now but imagine deploying 1000000000’s of firewalls with scripts. In addition, retiring 400 firewalls takes years but now you can do it in a second. So what will licensing look like in this IP-less dynamic world? It is a nightmare now with many products.
  9. Compliance – Remember application weenies want to just fire and forget. The CIO will want you to deploy a 600 server farm today and worry about security later. So how do you ensure that these dynamic environments maintain a security compliant profile? Not sure what products can adapt to this dynamic environment at this point.
  10. Debug vs Deploy – Debugging will be a nightmare in this dynamic environment created by scripts. Have you ever debugged in a load balanced environment when packets are never following the same path? This will be even more fun with encrypted tunnels, floating guests, scripted deployments….
  11. VMware security architecture issue – Rumor has it (I heard this through the grapevine, have not verified details) that VMware based firewalls (Palo, CheckPoint, etc) are not totally embedded within the hypervisor. When the hypervisor sees traffic that needs to be processed by a firewall, it forwards it to a virtual guest that is a firewall. So while the abstraction is that every virtual guest has a mini-firewall running inside of it, the reality is that there could be only 1 virtual guest firewall that manages security for all the virtual guests. So this means a Borg cube with 10000000 virtual guests might have 1 actual firewall managing security for 1000000 virtual guests.

    So when talking to vendors ask them explicitly how firewall processing works and how it differs from VMware native firewalls. I will too.

Summary

  1. Classic IPv4 networking will go away away over time as network speeds, bandwidth, latency all improve. Will be replace by The Borg, UIDs, share file systems or similar.
  2. Orchestration/Scripting/Automation will replace people, outsourcing
  3. Security will be an afterthought…always is in new technology
  4. Failures will be catastrophic and really cool to talk about over beers
  5. If CheckPoint/Tufin play it right, their management framework could win in this virtual world. Ideal would be if VMware bought CheckPoint for their management environment  intellectual property.
Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: