Sunday, March 15, 2015

Who do you trust? - nobody

It is not about me. I do have faith in the human race and there are people that I trust.

It is about a new security model proposed by Forrester Research in 2010.   

Traditional Network Security
The problem with the traditional network security model is that it assumes anything outside the network is untrusted while everything inside the network is trusted.  Heavy emphasis is put at the edge for network access control.  Once a user is in the network, there is not much control. 

There is the Role Based Network Control (RBAC) in which based on the credential of a user and sometimes based on where and when the user is trying to access the network, a role is assigned to the user after the user successfully authenticates with proper credential. It is more useful when RBAC is implemented at the application level. To implement RBAC at the network level, security control is still limited.

With the proliferation of server virtualization, virtual machine can move from one host to another host.  This makes the application of security control more difficult - where is the perimeter?

Before we go on we need to spell out 2 definitions: 
  • East-West traffic: it is the traffic between servers within a datacenter
  • North-South traffic: it is the traffic between client and server

Traditional security model mostly tailor to north-south traffic and not much is done for east-west traffic.

Zero Trust Security Model
The "Zero Trust" security model is proposed by John Kindervag, a senior research analyst at Forrester Research.  His report can be found here (you have to paid to read the full report).  Well, we can also listen to John Kindervag talk about this "Zero Trust" model here in YouTube.  Actually the name of this security model captured the essence - "Trust no one".  From the YouTube video, John Kindervag mentioned 3 concepts for "Zero Trust" security model:
  1. All resources are accessed in a secure manner regardless of location
  2. Access control is on a "need-to-know" basis and is strictly enforced
  3. Inspect and log all traffic
To implement this on the traditional 3 tier network (access/aggregate/core) is not easy.

Today let's take a look at VMware and Cisco products that utilizes this "Zero Trust" security model.  This security model also protects east-west traffic between servers.

VMware implemented Zero Trust security model in its NSX product.

VMware NSX is well known as a Software Defined Network (SDN) feature.  I have in another post stating that NSX is also a security product and according to Chris King, vice president of product marketing for VMware's Networking and Security Business Unit, a lot of customers show interest in NSX because of its inherited security feature because of it design. 

NSX is a network virtualization platform and is able to automate, provision and managed network connectivity in a data center.  With NSX there are 3 levels of security that can be accomplished:

  1. Isolation
  2. Segmentation
  3. Advance Segmentation with 3rd party security partners

In traditional network, Access Control List (ACL) is used for isolation.  With a virtualized network, the virtual network is by default isolated from the physical network.  Each virtualized network are also being isolated with one another.  This follows the zero trust principle a the virtualized network level.

In NSX, there is a concept of micro-segmentation.  In the traditional network segmentation is done through VLANs.  With a virtualized network, segmentation is not limited to a VLAN but can be fine tuned to smaller group of virtualized resource or even to an individual virtual machine.  In fact, as this will be explain again later in this post is that micro-segmentation is how VMware achieved the zero trust security principle.

Advanced Segmentation with 3rd party security partner
With service chaining, NSX in a virtualized network can direct the data traffic to 3rd party security appliances for deeper packet inspection and ACL parsing. 

The main idea for NSX to accomplish the zero trust security model is to have a distributed firewall (one on each ESXi host) and that traffic is inspected before being sent out to the traffic. Even if 2 VMs are connected to the same vSwitch, the distributed firewall is going to inspect the data traffic before sending to the destination VM. Without the distributed firewall, the 2 virtual machines connected to the same vSwitch are able to pass traffic between each other.

This diagram explain the concept that with the distributed firewall implemented at the hypervisor level, we can accomplished the zero trust security model where all traffic is being inspected and filtered according to the security policy defined:
image source:

Cisco's Application Centric Infrastructure (ACI) supports the concept of this Zero Trust security model.

As the name of this feature suggests it is all about - Application.

Traditional network security is network based, ACI decouples the security policy and segmentation from the network and defined "application friendly" policy model.  Security policy model in ACI is not only MAC address and IP address or its port number.  In ACI the security policy is defined by:
  1. Endpoint Groups (EPG)
  2. Policy Contract
  3. Application Network Profile
image source:
Endpoint Group
Devices with a common policy is put together as a group. It can be based on application friendly attributes such as OS, patch level, application type, application component or function.  Endpoint Group once created can be used to define security zones, trust boundaries or risk profile.  In ACI the default is no trust.

Policy Contract
The contract defines how data traffic is delivered between Endpoint Groups (EPG). This is is how the security rules are applied to devices regardless of where they are. In a virtualized environment, virtual machine migration is common. This contract defines filters and any associated action.  This is similar to our traditional firewall rules which based on the 5 tuples.  Policy contract enforcement for Endpoint Groups can be unidirectional or bidirectional.

Application Network Profile
In the diagram above this is stated as Service Chains.  Service chaining is a concept in which it defines the flow of the data traffic from one network service to another service.  Service chaining is a hot and important topic for Network Function Virtualization (NFV).

Trust and no trust
I believe the networking industry is catching up with the server and storage virtualization technology.  In a network we should trust no one but in our daily life we should have a certain trust level to other people that we come into contact with.  Everyday we are creating and updating out "Human Centric Profile" as to who and how much we can trust the people we know.

Reference:"Cisco ACI Security: A New Approach to Secure the Next-Generation Data Center." Cisco. N.p., n.d. Web. 13 Mar. 2015.
Egy, and White. Data Center Micro-Segmentation (n.d.): n. pag. Web.

Thursday, March 12, 2015

Network Virtualization for OVS (Open vSwitch) - Open Virtual Network

Open vSwitch is a open source virtual switch that provide logical switching on hypervisors similar to the VMware vSwitch and the Cisco Nexus 1000V. Full feature of Open vSwitch can be found here.  We can find good resource on Open vSwitch here and here

Open vSwitch has 3 main components:
  • ovsdv-vswitchd
  • ovsdb-server
  • Kernel module
image source:

This diagram explain the operation of Open vSwitch very well.  Visually we can see the various components in a physical host (a picture is worth a thousand words).

image source:

When we look at the features supported by Open vSwitch (OVS), we see that the list is very comprehensive for a switch.  (note: a switch is for layer 2 switching, check out my other post if you are not familiar with the 7 Layers of the OSI model).  There are 2 features on the list that makes OVS a good tool for OpenStack.  The 2 features are:
  1. OpenFlow protocol support
  2. Multiple tunneling protocols (GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)
According to this article, OVS is the most popular plugin for OpenStack.

Open Virtual Network
On Jan 13, 2015, it was announced that a new sub-project was created under the OVS project - Open Virtual Network (OVN).

The main idea of Open Virtual Network is provide a lightweight control plane that provides native support for common virtual networking abstractions.  

Open Virtual Network (OVN) will include:
  • logical switches and routers,
  • security groups, and
  • L2/L3/L4 ACLs,
and they are to be implemented on top of a an overly network such as VXLAN, NVGRE or GENEVE.   This is  most suitable to integrate with OpenStack Neutron as a plugin.

This article further explain that OVN provide Neutron with improved data plane performance through shortcut, distributed logical L3 processing and in-kernel based security groups, without running special OpenStack agents on hypervisors. Lastly, it will provide a scale-out and highly available gateway solution responsible for bridging from logical into physical space.

OVN will also work with Linux container systems.  Containers are also widely deployed in the OpenStack platforms. I also had a blog post on this topic on my OpenStack for Beginners series.

Open Virtual Network Architecture
Open Virtual Network builds on top of OVS and has the following layers:
  1. Open vSwitch
  2. OVN Controller
  3. OVN Database
Detail of the OVN architecture can be found in this OVN Architectural Guide.

1. Open vSwitch
As Open Virtual Network is a sub-project OVS and is therefore a natural layer for the foundation.  OVS has special extension for OpenFlow support and thus OVN is tailor to how OVS used OpenFlow.  OVN may not work with other OpenFlow implementation.

OVN used the OVS integration guide ( in the OVS repository.  This defines the interaction between the OVN controller and the hypervisor or container that used the OVS.

2. OVN Controller
This controller resides on each hypervisor and is not a centralized model that is popular on most SDN implementation.  The OVN controller runs on the hypervisor or host as a daemon.  The OVN controller on the southbound interface with the ovs-switchd using the OpenFlow protocol and the ovsdb-server using the OSVDB protocol. And on the northbound interfaces with the OVN Database using the OSVDB protocol.

This diagram is taken from the OVN Architecture Guide:
                             OVN Database
                          (OVSDB Protocol)
   |                                |                                  |
   |                                |                                  |
   |                           ovn-controller                          |
   |                              |     |                              |
   |                              |     |                              |
   |               +--------------+     +--------------+               |
   |               |                                   |               |
   |               |                                   |               |
   |       (OVSDB Protocol)                       (OpenFlow)           |
   |               |                                   |               |
   |               |                                   |               |
   |         ovsdb-server                         ovs-vswitchd         |
   |                                                                   |
   +---------------------------- Hypervisor ---------------------------+

3. OVN Database
At this initial state of OVN, OVSDB is being used as the OVN Database. One of the design goal for the OVN Database is high availability but the ovsdb-server does not support clustering and it is important to resolve this issue as the OVN is supported to be a production ready feature.

This OVN Database stores 3 types of information:
  1. Physical Network Information
  2. Logical Network Information
  3. Binding (logical element location, logical port and MAC address association)
Cloud Management System
Open Virtual Network requires a Cloud Management System such as OpenStack to function.  There is a plugin available for OpenStack and OVN integration.  This plugin translate the Cloud Management System configuration into the OVN Logical network information (in the form of logical data path flows) that are stored in the OVN Database.

More to come in the near future
Hopefully, we can see more development of this Open Virtual Network soon and if I am able to attend the OpenStack Vancouver summit I will certainly gather more information in this area and share them in this blog.

"Features." Features. N.p., n.d. Web. 12 Mar. 2015.
 "OVN, Bringing Native Virtual Networking to OVS." Network Heresy. N.p., 13 Jan. 2015. Web. 12 Mar. 2015.

Friday, March 6, 2015

Computer Networking 101 Part 4: You are right and I am not wrong

Usually we see things as either right or wrong but there are so many gray areas.

I have a friend who has a customer facing job and often times we don’t want to tell the customer that they are wrong.  One of his famous lines is 

You are right and I am not wrong”.  

 I think this has saved his day a few times with the customer.

So how does this related to computer networking?

Today we are going to take a look at one view to logically divide a switch/router according to its function.  There are other ways to look at a switch/router but this is the most common way and if you are to read the hottest technology SDN you will have to know this logical view of looking at a switch/router.  

Also, to use this "You are right and I am not wrong" as the title, I am trying to make a boring subject a little more fun.  This is something I learn in a conference. A successful presenter will be talking on a boring subject and yet the audience is still willing to listen because it is fun. This is a boring but important concept and this is why I decided to touch on this.

There are tons of good articles about this subject - different planes of a networking device.  Why do you want to spend time reading this blog post?  Can I write better then those networking experts?  Well, I will try and ....

I hope you will still read on:
image source:

As I have mentioned in my previous post, various vendors claim they have a SDN solution and each has it own definition and implementation of SDN (Software Defined Networking).  One of the ways to describe SDN is the “separation of the control and data plane”. If you “Google” SDN, a lot of article will use the beginning of to explain what control and data plane is before getting into SDN.

Traditional switch or router from networking equipment vendors comes in the form of a physical device with propitiatory software running on it.

image source:

With the arrival of the "Software Defined ___" era, SDN is a hot topic because it can catch up with the server virtualization.  There is a saying, we use a few minutes to provision a virtual machine (server) but we have to wait for weeks to get the networking or security (firewall) done.

When we need to virtualize networking equipment, the very first thing is to logically divide the equipment according to its functions.  Networking equipment can be divided into 3 functions:
  1. Data Plane (sometimes call the Forwarding Plane also)
  2. Control Plane
  3. Management Plane
We can define what each plane is but how are they related is not so easy to explain. 

This diagram from this blog post by explains the relationship of the 3 planes very nicely:
image source:

Data Plane
This is the logical function to switch or route the data from one port to another port so that it can reach its destination.

Control Plane
This is the logical functions that builds the Forwarding Information Base for switch or routers.  Remember in my previous post, layer 2 switch uses "source learning" and routing protocols are used by layer 3 routers to build this Forwarding Information Base.

Management Plane
This is the logical function where user configure the networking device via the console of the device, SNMP (Simple Network Management Protocol) or NETCONF (Network Configuration Protocol).

If you want to dig into this right now I recommend this article as well as this article.  This post is meant for beginners to pick up the essential concepts of networking. Keeping the information as simple as possible and yet capture the essence.

Hope you enjoy reading this post.  Stay tune for more post in the coming days.

Thursday, March 5, 2015

Computer Networking 101 Part 3: Where should it go? - forwarding decision

In the previous 2 posts of this Computer Networking series, we have talked about the 7 Layers of the OSI Model and reaching the destination.

On the topic of reaching the destination, networking equipment has to deal with 3 types of traffic and one of their job is to make forwarding decisions.  Where should this frame/packet go?

Today, lets look at the networking equipment.  There are different kinds of networking equipment - switch, router, load balancer, firewall ... etc. We will concentrate on switch and router.  In layer 2 we switch and in layer 3 we route.  Layer 2 switches has become a commodity.  For layer 3 router, everyone knows about Cisco, Juniper and Arista.  Of course there is Alcatel-Lucent that makes core router and the enterprise division that I work for that makes switch/router.

Layer 2 Switch
Forwarding decision for layer 2 switch is relatively simple.  If the destination is unknown or if the destination MAC address is ff:ff:ff:ff:ff:ff, the packet is to be flood to all the ports of the same VLAN.  Layer 2 multicast frames are treated as broadcast traffic.  When a frame is seen on a port the source MAC address is being learned.  Next time when a packet with this MAC address as the destination MAC address, the layer 2 switch knows to switch directly to this port.  With Source MAC address learning (most people call this source learning), the layer 2 switch will create the Forwarding Information Base that provide the necessary information for forwarding decisions.

Most layer 2 switches has something call the TCAM to store the MAC address and they are able to use the hardware to perform the known destination switching.

Layer 3 Router
In the past there were different routable protocol such as AppleTalk, DECnet, IPX, SNA ... etc.  With the blooming of the internet, we hardly seen the use of these protocols since we have converged into a IP exclusive network.

The forwarding decision of a layer 3 router is relatively more complex. The decision is based on the routing table/Routing Information Base (RIB). From the routing table the Layer 3 router can create the forwarding table/Forwarding Information Base.

The content of the routing table varies by vendors but they contain similar information.  From a TechTarget article, routing table has the following elements: 
  • Destination: The IP address of the packet's final destination
  • Next hop: The IP address to which the packet is forwarded
  • Interface: The outgoing network interface the device should use when forwarding the packet to the next hop or final destination
  • Metric: Assigns a cost to each available route so that the most cost-effective path can be chosen
  • Routes: Includes directly-attached subnets, indirect subnets that are not attached to the device but can be accessed through one or more hops, and default routes to use for certain types of traffic or when information is lacking.
The routing table is created by various IP routing protocols.  Before we talk about routing protocol we need to know what an Autonomous System (AS) is. An Autonomous System is basically an administrative domain.  Each Autonomous System is assigned a globally unique number – Autonomous System Number (ASN). 

There are 3 major types of routing protocol:
  1. Interior Gateway Protocol (type 1): Link-State Routing Protocol
  2. Interior Gateway Protocol (type 2): Distance-vector Routing Protocol
  3. Exterior Gateway Protocol 
Within an Autonomous System, Interior Gateway Protocol is used and for route exchange between 2 Autonomous System the Exterior Gateway Protocol is used.

The basic idea is that routing protocol allow router to exchange route information so that the router can build the routing table which in tern based on efficiency or least number of hops to create the forwarding table. 

In this article we are to touch on the terms and basic concept only to give an overview of computer networking.  We are not going to go into the difference between these routing protocols.  (Note: if there is any concept that you want to know in a more in-depth manner, please let me know and I will use another post to explore that topic)

The different planes of a networking equipment

Networking equipment can also be divided into 3 functions:
  1. Data Plane
  2. Control Plane
  3. Management Plane
The separation of the data and control plane is often being used as a definition for the hot topic Software Defined Networking (SDN).  This is not a complete definition of SDN because there are different view of what SDN really is.  I will certainly blog about this subject within this year as I am going to take the VMware VCIX-NV (network virtualization) certification.

"What Is Routing Table? - Definition from" SearchNetworking. N.p., n.d. Web. 05 Mar. 2015.