MidoNet Rule Chains


Initially, the protocols and standards used to connect networks were designed without any security in mind. The main focus was connectivity, less attention was directed on securing protocols and connections. Over the last decade, the use case of applications has expanded greatly. As a result, the attack surface has too expanded and the original security model is not sufficient. The network and security approach must change to support the new application and network service components. We now live in a world of microservice applications, consisting of multiple components, potentially interconnecting through dispersed geographic locations. This has forced the security paradigm to change, which needs to be set closer to the actual workload.

Traditionally networks use IP addressing as the main security classification method. Now, as we have fully entered the world of network virtualization and distributed systems, we are no longer restricted to this type of symantec. Midokura and their MidoNet solution enhances OpenStack security with intelligent classification / condition statements. Their Rule and Rule Chain solution permits finer grained security required to protect application deployments. They employ a fully open source distributed SDN controller and agent solution. Agents only subscribe to interesting objects, optimizing network performance. Kindly visit the following link to view my previous blog discussing MidoNet SDN architecture.

The following diagram displays an example of MidoNet Ingress Rules and Rule Chain solution.

Original Security Model

Firewalling technologies emerged in the 1980’s and we went through a number of generations. We started with basic generation one packet filters, then to stateful devices and application based firewalls. We have now moved into the world of VM based appliances and distributed firewalling offering better flexibility and agility. The transition was required to keep pace with application evolution. The monolithic application is now broken up into pieces, services spread throughout the network.

The application and its deployment model has changed considerable. Initially, we started with single application per server deployment. This presents considerable waste of physical resources, vendor lock in and limits scalability. Mapping applications to specific hardware does not scale. Applications are now abstracted from hardware; tiers may be spread over different physical servers and locations. The microservice application approach has driven containers which changes the security model required to properly secure workloads. Traditional security devices struggle to keep up with the agility and flexibility needed to support these new endpoints.


Static Networks and Physical Devices

Traditionally, we had physical security devices performing ingress and egress traffic filtering. They were usually deployed in one static location in the network; hanging off the core or distribution layer. Any traffic requiring scrubbing would have to find its way to the physical device. To support traffic steering, core nodes would require some kind of manual configuration to effectively steer traffic. The network was very static and could not be easily moved. If a VM moved to another location, its policies were tied to the old location. This may result in stretched firewall cluster designs or some other clustering proprietary kludge – increasing network complexity. Physical devices could not support any type of network agility.

A key requirement for the cloud is multi tenancy. Physical firewall devices were never originally designed to support the cloud and it’s multi tenant requirement. Overtime, they were evolved to do so but with a limited feature set. Vendors introduced VRF’s and Multiple Context to support multi tenancy but this was not a true multi tenant solution. VRF and Context still share the same underlying code. To prevent one tenant from affecting other tenants, administrators could implement resource restrictions per context. This might be useful to prevent slight noisy neighbor syndrome but it won’t prevent a DDoS attacked tenant from affecting other tenants on the same physical box. A DDoS attack usually turns over a physical box. It would be useful to have a firewall device that was distributed or in VM format that could be scaled based on traffic demand. Distributing firewall services among many nodes can withstand a DDoS attack much better than a single physical node with high density cards.

We then moved to firewall and security appliances in VM format. This was leap years better than the physical approach. Firewalls are automatically spun based on traffic demands and policies move with workloads. The VM approach greatly improves agility and is better equipped to meet application requirements than its physical counterpart. However, there is considerable feature parity between physical and VM appliances.

Traffic patterns have changed and this results in the adoption of a different security paradigm. We started with north to south, the majority of traffic left the data centre. Physical devices were OK at supporting this flow type and all traffic would enter and leave the security node. Now, a considerable amount of traffic stays within the data centre, known as east to west. Physical nodes deployed in static locations are causing considerable network choke as all east to west traffic must now flow through them. To support new traffic flows the security paradigm must change and filtering closer to the workload. Filtering closer to the workload means traffic does not necessarily need to go to a central chokepoint, offering optimal any to any traffic flow.  

In order to fully support today’s workloads and traffic flow we move into the world of distributed systems. Midokura offer a fully distributed model with enhanced security enhancements benefiting OpenStack deployments.


MidoNet Security Enhancing OpenStack

OpenStack Security Groups, also referred to as tenant-level firewalls, are a collection of rules controlling tenant ingress and egress traffic at a port level. This type of model changes the security paradigm and moves security application closer to the workload. We can now filter at a port level and neutron ports is where security groups get applied. Ports represent entry and exit points for data traffic and it’s here IP and MAC addresses are configured. OpenStack has a number of different types of ports. For example, “compute:nova” ports is a port associated with a virtual machine, “network:router_gateway” is a port associated with a gateway to an outside network.

As mentioned, security groups are applied to neutron ports. These rules are then translated by neutron into IPtables rules, applied to the appropriate compute node. IPtables is a built in firewall that carries out the filtering. It has a number of default chains and possible actions but its scope is limited. MidoNets security model is better integrated as it works directly with Open vSwitch kernel and does not rely on IPtables. Rules are translated and actions directly installed into Open vSwitch. IPtables is also based on Linux namespaces which are tied to the host and not distributed whereas the MidoNet architecture is completely distributed.

MidoNet provides filtering on the ingress/egress on logical device. Unlike IPtables which provides filters on the egress, traffic has to traverse the virtual network before finally getting dropped at the egress hosts. Letting potentially malicious traffic traverse would make the system less secure whereas MidoNet stops them immediately on the ingress hosts. MidoNet bypasses IPtables for a better security model.   

One major issue with traditional OpenStack security groups is that they are not true multi tenant. The grouping does not span and you cannot refer to group in a different group. Essentially, you can’t reference Neutron Security Groups across Tenants. For example, Tenant A wants to allow TCP communication to its VMs in SecGroup11 from Tenant B’s VMs in SecGroup22. Tenant A may add the rule, for example, “Allow TCP:8080 from <UUID of SecGroup22>” but traffic from VMs in SecGroup22 arrive in Tenant A with source address that has been translated. The work-around is to avoid referencing Security Group UUIDs from another tenant. For example, the rule in Tenant A’s SecGroup11 might be crafted as “Allow TCP:8080 from <SNAT address of Tenant B>

Traditional OpenStack security does not offer a true multi layer control security model. Unfortunately, this leaves the full power of OpenStack security groups only seen within a tenant. MidoNet overcomes this with their stateless approach to rules and rule chains.


MidoNet Rules and Rule Chains

MidoNet offers a similar concept to IPtable rule chains but with advanced level of functionality. MidoNet agents do not understand the concept of OpenStack security groups, instead they understand MidoNet rules and MidoNet rule chains, which are corresponding low level constructs. The configuration of security groups gets translated into rules and rule chains which are then implemented at a port level.

Rules are filters that specify an action to apply to matched traffic. They offer granular filtering, matching and action criteria with condition statements that express a boolean logic. Rule chains are an ordered list of rules that specify how packets should be treated. One advantage of a rule chain is that they are stateless, meaning they can be shared by multiple virtual devices.  

Networks in Neutron are represented as bridges in Midonet. Bridges contain port lists where MidoNet implements security groups. The infilter chain is inbound from the bridge or port but outbound from the VM. The outfilter chain is inbound to the VM. Only one filter can be assigned to a port but it may have many JUMP actions linking to other chains. The JUMP action allows you to jump to different policies and create special structures in the chain. It permits the sharing of a chain. The linking of chains provides powerful filtering characteristics and actions. There are many other actions including REDIRECT which is used for service insertion. MidoNet also offers the ability to label. Administrators can mark and then match on that marker later on in the network topology.

The plugin calls the MidoNet API and adds the rules in the MidoNet model stored Zookeeper. It then gets translated to MidoNet low level resources. All topology objects in the overlay are stored and synchronized. Agents connect to Zookeeper and subscribe to interesting objects. The MidoNet security groups operate in this manner.   


Rule Chain Analysis

The following diagram displays the list of MidoNet bridges, ports assigned to bridge2 and corresponding rule sets and JUMPs. The following steps examine infliter chain2, which has 5 rules attached.

A virtual port is always set to “plugged – no”. However, if the virtual port is bound to a physical port it’s plugged status can be either “yes” or “no”, depending on the physical status (UP/DOWN). Ports 3 and 4 are DHCP ports and Port 5 is the router interface.


Bridge2 contains 6 ports, labelled 0 to 5. Port 0 has infliter chain2 and outfliter chain3, same for port 1 and port 2. The in and out filter represents the direction in which the Rule chains are applied. The infilter is outbound from the VM and the outfilter is inbound to the VM.


Rule Chain 2 – this is an infilter so it’s outbound from the VM. It contains the following rules:

  • Rules 0 – 1 are part of the MidoNet model and represent anti spoofing rules for Layer 2 and Layer 3 traffic. The anti spoofing rules are a MidoNet enhancement and may be disabled.
  • Rule 2 permits return flows for connection tracking.
  • Rule 3 represents a JUMP action to the Neutron security group. The Neutron security group is referenced in Zookeeper so it gains all the benefits of a distributed security model.
  • Rule 4 drops everything but ARP. ARP is needed to learn MAC addresses.


Rule Chain 8 is a JUMP of rule 3. It represents the default Neutron security groups settings for outbound traffic.

  • Rule 0 and 1 permit all IPv4 and IPv6 outbound traffic. This is the default behavior of a default Neutron security group.


Rule Chain 3 on port 0 represents inbound to the VM. It is an outfitter from the bridge standpoint.


  • Rule 0 permits return traffic in the other direction.
  • Rule 1 is the JUMP to the Neutron security group, which is Chain 9.
  • Rule 2 contains the default drop rules. Drops everything but ARP.


Rule Chain 9 – this is an outfilter so it’s inbound to the VM. It contains the following rules:

  • Rule 0 – permitting SSH traffic. It uses source 0.0.0./0 permits SSH from any source.
  • Rule 1 – allows all IPv4 from all VM’s within the same security groups. This is behaviour for the default security group. For example, if two VM belong to the same security group, they can transfer traffic. We use protocol 0 to represent all traffic and “ip-address-group-src” to match all allowed source IP’s within the security group.
  • Rule 2 – same conditions from rule 1 apply to IPv6 traffic.
  • Rule 3 – permits ICMP ( protocol 1 )


Zookeeper which holds a lot of the state is an integral part of MidoNets distributed security group architecture. The screenshot display the port 0, chain 3 and rule 0 (of chain 8) objects in Zookeeper.


Matt Conran

About Matt Conran

Matt Conran is an independent consultant, blogger, and the publisher of network-insight.net. He is a 16 year veteran in the networking industry with core skillsets in Data Centre, WAN, MPLS, security and virtualization technologies. He has implemented multiple infrastructure projects with startups, governments, enterprises, and service provider customers, including being a lead Network Architect in major global greenfield deployments. He loves to travel and has a passion for landscape photography.

One Thought on “MidoNet Rule Chains

  1. Pingback: Midokura Security - Rule Chain solution - Technology Focused Hub

Post Navigation