Flow "Normal Form"

During the last weekend and after fighting for several hours with a match rule that wouldn't for the live of me get installed on openvswitch I learned about the flow "Normal Form".

I will try to describe what the flow "Normal form" description is with an example:

If you want to install a rule to match a layer 3 field, for example an IP address, then the dl_type cannot be wildcarded, it has to be explicitly defined. In case of IP, dl_type has to be equal to 0x0800.

Same thing for a layer 4 match. If you want to match for a TCP or UDP port, then nw_proto cannot be a wildcard. It has to be explicitly defined as TCP or UDP.

So lesson learned: if you want to install a TCP matching rule you have to explicitly define a dl_type of 0x0800 and nw_proto of 6.

Another lesson that I also learned: sometimes it is good to read the man pages.

More info on the section "Flow Syntax" of the ovs-ofctl command.

Security Services in a Software Defined Network

At a very high level of abstraction, a traditional network could be thought of a set of  forwading elements (router, switch, firewall, load balancer, etc.) each one with a “control plane” that must cooperate with it peers so they all can come with a consensual view of the overall state of the network. Based of this “state” each forwarding device takes a “local” decision about the best way to forward the packet from its ingress interface to one of its potentially many egress interfaces. This consensual view of the state of the network is enabled by traditional protocols such as ARP, Spanning-Tree, OSPF, BGP and a long list of other layer 2 and layer 3 protocols. This state of affairs could be best characterized by the phrase “Think globally, act locally”.

A Software Defined Network (SDN) is a network which has a centralized control plane and one or potentially many physically distributed forwarding devices (a.k.a. “data planes”). This “centralized control plane”, or as it is also known, “the controller”, has complete knowledge of the state of each of the forwarding elements of the network (i.e. routers, switches) and can be made to modify on-demand and programatically  the way each of these forwading elements should forward the packet through the network.

The controller can change the forwarding behavior of the elements of the network through the use of the “Openflow” protocol. Openflow is the “language” used by the controller to modify the behavior of how packets should be forwarded by the network.

On a SDN and depending on the logic programmed in the controller, each forwarding element can become a router, a switch, a load balancer, a firewall, an access control device, a behavior analysis device or a traffic redirector for packet analysis (a la IPS/IDS) among many other possibilities.

On a SDN there are many of examples of how “traditional” security services (packet filtering, switch port-security, DHCP protection, ARP poisoning protection, etc.) could be deployed efficiently.

Arguably, the first security service that could easily be implemented on a SDN is a packet filtering device. On this scenario the controller would install a new forwarding rule on the forwarding device only if some policy allows this to happen. Packets matching the policy rules would be allowed to be forwarded by the network while non-conformant packets will be denied access to the network at the forwarding’s device ingress port. At a high-level, this behavior emulates a network-wide distributed access-list system managed from a central point.

The controller could also be programmed to act as a DHCP proxy of sorts. This will allow the controller to get full knowledge of the IPs and and MAC addresses located in each physical port of every forwarding element of the network infrastructure. This knowledge would allow the controller to only install forwarding rules for specific source MAC addresses and source IP addresses at the forwarding device. If the ingress packet matches this rule, it gets forwarded. If not, then the packet could be discarded. There is also the option that in case someone tries to insert rogue packets (spoofed IP address, spoofed MAC address, spoofed ARP packets) onto the network, the controller could install a new flow to route this illegal packet from the ingress port to a kind of centralized packet-sink where security researchers could gather information of where on the network are spoofed packets being generated. Think of it as a sort of backscatter analysis tool for ARP-poisoning/Packet-spoofing attacks.

SDN may also enable new ways of delivering traditional security services: the on-demand and centralized provisioning of firewalling, IPS, tunneling, encryption and many other services. Think of it as “centralized security providers” whose services gets invoked every time the controller on-demand and programmatically route the traffic from it’s normal flow to theses providers. The re-routing of traffic through these services could be triggered by abnormalities in traffic patterns or by any other type network anomalous behavior. 

These are interesting times to be involved in the networking world.

DOS'ing flow-mods with an action of CONTROLLER?

Food for thought: Is it not that every flow-mod with an action of CONTROLLER (that is, send the packet to the controller) is a rule begging to be exploited by a rogue machine injecting spoofed packets to overwhelm the processing capacity of the controller? How to avoid this without starving to death legitimate flows needed by the controller to make a decision? Wouldn't one of the options be that on the controller side rate-limiting the number of PacketIns per dpid/port? What would be the impact of this?

A minimalistic POX LLDP based network topology discovery component

Just uploaded to github a minimalistic POX network topology discovery component.

From the README file:

"...discovery.py is a small python class that can be used to create a topological view of a set of openflow enabled switches. The main idea behind discovery.py is to provide a Networkx based topology component which reflects the underlying network giving the networking researcher a programatic object which can be manipulated by the many graph analysis tools provided by Networkx (http://networkx.github.com/)..."

This is a work in progress to my goal of having a platform that I can use to research about what new security primitives (access control, behavioral analysis, on-demand network security services among others) could be deployed in a Software Defined Network.

Link to the github repository where you will be able to find more information about this component.

Hope you may find it useful. Comments and feedback are more than welcome.

Happy SDN'ing

networkx, graph generators, mininet and network topologies for openflow testing

networkx is probably the best (the only?) python library to build and manipulate Graphs.

Mininet is IMHO the best library/framework/tool/black-magic-thingy for building and experimenting with openflow/SDN using openvswitches on Linux. There is no enough karma  in the Universe to thank the guys at University of Stanford (Bob Lanz, Brandon Heller and Team) for the development of this tool.

That said, if you want to use other than the "default" topologies in mininet (linear, tree, etc.) you have to build them using mininet's own API. A combination of addHost()and addSwitch()methods from Topo's Class (mininet/mininet/topo.py) plus your own logic and algorithmic witchcraft.

When you want to work with more complex topologies, for example a 10 node Erdos-Renyi network with a probability of 0.6 of an edge between nodes, then this method gets quickly out of control, specially for lesser minds like "yours truly" (that would be me).

On the other side, networkx has Graph Generators that can create these kind of topologies with just one function call. It cannot get easier than that.

That's where mn_nx_topos.py tries to fill its niche. The idea behind mn_nx_topos.py is to provide a set sub-classes derived from mininet.topo.Topo to help with the creation of complex mininet network topologies. It also provides a very basic and simple function to graph them using python's matplotlib library  so you can get a visual aid of your network from mininet's command line.

Example: You want your mininet network "emulate" an Erdos-Renyi random network with 7 nodes and a 0.6 probability of edges between nodes so you can test your new spanning_tree openflow application (why would someone need to use spanning tree in a openflow/SDN network is left as an exercise for the reader).

javier@u1210:~/mn_nx_topos$ sudo mn --custom mn_nx_topos.py 
--topo erdos_renyi,n=7,p=0.6 --controller=remote,ip=127.0.0.1,port=6633

*** Creating network
*** Adding controller
*** Adding hosts:
h0 h1 h2 h3 h4 h5 h6
*** Adding switches:
s0 s1 s2 s3 s4 s5 s6
*** Adding links:
(h0, s0) (h1, s1) (h2, s2) (h3, s3) (h4, s4) (h5, s5) (h6, s6) 
(s0, s6) (s1, s4) (s1, s5) (s2, s3) (s2, s4) (s3, s5) (s4, s5) 
(s4, s6) (s5, s6)
*** Configuring hosts
h0 h1 h2 h3 h4 h5 h6
*** Starting controller
*** Starting 7 switches
s0 s1 s2 s3 s4 s5 s6
*** Starting CLI:
mininet>

And now from the mininet command prompt you could type...

mininet> py net.topo.graph()

...and then get a visual aid about the network you just created (blue = switches, red = hosts)

Please be forgiving with the graph, there are so many things to improve and no enough time to do it (yeah! i know, typical procastinator)

You can download mn_nx_topos.py from my github repository.

Or you can also git-clone it and do your own modifications:

javier@u1210:~$ git clone https://github.com/jliendo/mn_nx_topos.git

If you find these classes useful please let me know. If there are bugs or what-nots please drop me a line and I will try to fix them.

Enjoy and happy SDN'ing

POX and scapy

Note to self.

When trying to do packet manipulation using scapy inside POX (i.e. inside a _handle_PacketIn event), use the *data* field passed to the call back.

That is, do the following:

...
from scapy.all import *
...
...
    def _handle_PacketIn(self, event):
        packet = Ether(event.data)
...
...

NOX Quick Introduction

There is a very good presentation describing the NOX architecture at a high level buried in the NOX mailling list. I'm posting it here as a reference in case this may help this document see some more light.


NOX A "Quick" Overview by K.K. Yap and Kyriakos Zarifis