Network Traffic Monitoring using OpenFlow

These days you don’t have to shell out thousands of pounds for an OpenFlow switch. Especially if you don’t mind lesser number of ports and devices that are not blazingly fast. I purchased a Zodiac FX OpenFlow switch and have been trying out different projects with it. The switch has 4 ports at 100M each with Port 4 reserved for management.

Figure 1: Network Setup for Traffic Snooper

To make a Traffic Snooper we need to mirror ports that allow ingress into and egress from the internal network. Port mirroring means sending same traffic to the target port as well as a mirror port. We may also filter traffic that is mirrored (e.g. we may only want to mirror Layer 4: UDP traffic). 

For the Zodiac FX, I selected Port 2 to be the mirror port. Traffic exiting the internal network will arrive on Port 1 and be sent out from Port 2 and Port 3 (Apply Action List). Similarly traffic entering the internal network from the Internet will arrive on Port 3 and be sent out from Port 2 and Port 1.

Thus Port 2 will receive packets from both the directions. Port 2 is attached directly to a Raspberry Pi with Link Local addressing enabled. This means that the port on the Raspberry Pi has a link local IP address assigned to it. We don’t really care about this because we are already forcing the traffic to come this way using a static flow. 

On the Traffic Snooper Pi I run my Python based Traffic collector. This utilises raw sockets to listen for traffic. All data is converted into hex and dumped into the Analytics Store database (Mongo DB). This is a fairly simple utility perfect for a lightweight platform like the Pi. It does not do any processing of the network data. It simply stores it in a database. The source code is attached for both the Snooper and the static controller which uses Ryu.

Snooper.py: https://docs.google.com/document/d/e/2PACX-1vTVV-G17M-TrLfGd2gt0B-5aK_NshjZ1-F1tWvrQwbTHR4Z-FYoaAzfOYdMVtGxP3B1ODLoWWiQiWS3/pub

The Traffic Snooper needs the following to read from the raw socket that is getting data from port 2 of the switch (the mirrored port):

s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.htons(3))

The line above can be interpreted as:

Open a socket that uses Address Family (AF) of Packets (you will need to run snooper with sudo to provide access) that will allow access to Layer 2 information. The socket is a raw type – therefore Layer 2 headers will not be stripped. Finally we provide the host to network byte order conversion (htons). 

This gives us a socket that pulls the packet with all the information (headers) intact and also ensures the byte ordering is correct.

The Traffic Snooper also stores the packet hash to ensure we do not store duplicate packets (this can be disabled if required).

Note: port 2 will not get any direct assignment of IP address (we don’t want any traffic to use this port for communication – only mirrored traffic should use this port) and should default to a ‘link-local’ IP address. In case of IPv4, link-local addresses are defined in the address block 169.254.0.0/16

Static_Controller.py: https://docs.google.com/document/d/e/2PACX-1vRU8ZAa5Vl03UwC5K61Rt9Me0y0tvKq_0s8lCm7aH9t7vN_Z6qnUMQgINPFdCrt9BM-kBkJh3uuJCyw/pub

The installed flows:

The OpenFlow Specification allows multiple Apply Actions. We use this to create duplicated traffic flows.
Flow 1: All traffic coming in from port 3 is forwarded to port 2 and 1. Here port 2 is the port connected to the analyser.

Flow 2: All traffic coming in from port 1 is forwarded to port 2 and 3.

Note: The controller is a static controller. In other words we use Ryu to install flows and then the controller is disconnected (thus flow timeout=0). To achieve this we use the ‘safe’ mode on the Zodiac FX which does not remove the flows that have been installed. As the Zodiac FX is a pure OpenFlow switch it does not support standalone mode.

Next Step: Next post will look at the traffic analyser that breaks down the incoming packet and pulls out various protocol related information.

Follow-up: I have used Zodiac FX for this post and not something like OpenVSwitch (which has several advanced features such as port mirroring and built in learning switch in ‘standalone’ mode) because I wanted to use a pure OpenFlow device that does nothing till you don’t provide the flows. 

OVS Implementation

It is fairly straight forward if you want to setup your Pi as a OVS switch. You will need USB-Ethernet plugs and a freshly formatted Pi. I used the lightweight no-desktop ‘Stretch’.

This is a good guide to follow: 
https://www.telematika.org/post/piovs-raspberry-pi-open-vswitch/

I only needed the ‘Install OVS’ and ‘Configure Interfaces’ step.

Below are the three interfaces I created, ‘eth2’ is the interface to the snooper and ‘eth3’ the ‘internet’ interface.

auto eth1
iface eth1 inet manual
hwaddress ether 00:0e:c6:de:54:15
auto eth2
iface eth2 inet manual
hwaddress ether 00:0e:c6:df:ae:ac
auto eth3
iface eth3 inet manual
hwaddress ether 00:0e:c6:df:ae:c2
auto ovsbr0
allow-ovs ovsbr0
iface ovsbr0 inet manual
ovs_type OVSBridge

There are few things to watch out for:

  1. The interface on the Raspberry Pi running the snooper application  should not be reachable from the network. This is because we do not want any traffic headed for that port. We only want to record traffic flowing between 1 and 3. Therefore, the Pi connected to port 2 of the switch should have two interfaces. One that has a valid local network address – to allow snooper to access the database server for example. The second which is connected to the switch interface 2 which receives the copied traffic. This second interface should have a link local IP address to ensure all the traffic received there either for port 1 or 3.
  2. Set the fail mode to ‘secure’ in OVS. If you do not set the fail mode in OVS to ‘secure’ then it will fall back to learning switch mode (standalone mode) and start faithfully switching traffic. This will mean (in short) your snooper Pi will have an IP address assigned to the port that is sniffing the mirrored traffic. Once you install the flows then the traffic will be mirrored but you can still get extra packets not part of the flow that we are monitoring.
  3. Use ‘sudo ovs-vsctl get-fail-mode <bridge_name>‘ to get the fail mode and then ‘sudo ovs-vsctl set-fail-mode <bridge_name> secure‘ to set to secure mode (replace bridge_name with the name of your OVS bridge). This will disable the learning switch and you will need to use the static-controller to setup the snooper flows.
  4. You can use ‘sudo ovs-appctl fdb/show <bridge_name>‘ to show the forwarding db (this stores the result of the mac learning) and ‘sudo ovs-appctl fdb/flush <bridge_name>‘ to clear the forwarding db.

5G Networks – Just Over the Horizon

Introduction

How many times have you heard yourself say ‘this call might fail because I am boarding a bus/train/aircraft’? How many times have you tried making a call while in a busy area and found that the call does not get through? How many times have you lost mobile signals on a highway and not been able to make a call let alone access 3G/4G data? How many times have you struggled to send an email as you go in and out of a metro (underground) station? How many times have you screamed silently when connecting to a ‘free’ wifi is harder than learning how to fly a plane!

Finally how confident are you that high data rate services such as video calls, live streaming, YouTube etc. will continue to work as you commute, attend events (such as concerts), travel or just take a walk in a mall (reinforced concrete and steel are bad for mobile signals!).

5G networks aim to address many of these problems ‘out of the box’.

There are several major projects underway all over the world to produce specifications, proof of concepts, commercial and technology test beds. The European Commission is heavily involved via the 5G-PPP (Public Private Partnership) initiative which also means there is decent amount of funding available.

So what is 5G? How is it different from 4G? What are its major use cases? I will attempt to answer some of these questions in this post.

What is 5G?

Firstly while 5G is obviously about connecting wireless smart devices, it involves a whole lot more. Unlike our familiar 4G/3G network which is mostly restricted to the wireless domain, 5G aims to be a fusion of wireless and wired. The reason I call it a fusion is because the main thrust of 5G is towards removing boundaries between different domains (mobile, wifi, wired broadband) from the end user perspective and provide seamless access.

Seamless, On-demand Services

To enable seamless access for the user, all the various network functions and resources need to be packaged as a product, made accessible through a standard interface. On top of this you need a catalogue based mechanism which effectively allows stitching together of these resources and functions to provide a service to the end user.

Think of it like preparing a new dish. Once you get the recipe, you go to your local supermarket and gather the ingredients (resources) from a clearly laid out aisle. Then you come home and gather various cooking implements (functions) to process the ingredients. Finally you follow the recipe and transform the ingredients using the cooking implements into a dish – which you serve to the end user.

This is broadly speaking what a 5G network will attempt to do – while keeping track of the Quality of Service and ensuring Service Levels do not fall below an advertised limit. This equates to maintaining food quality at a certain advertised level irrespective of whether you are cooking at a campsite or in your own kitchen or in a restaurant.

For example if you are attempting to watch a HD video stream while on the move – all the resources and functions you need (and this is not a static set – as you may move in and out of various radio access technology domains such as 3G, 4G and Wifi) should be provided at a given point in time so that there is no disruption in the video stream.

Dawn of IoT

5G networks are also being designed, from the ground up, to support so called ‘machine type communication’. Machine type communication is characterised by a very large number of simple low-power sensors that require a data-link to push data to a gateway server. The data-link is usually wireless and often has low-bandwidth requirements. Several specialised sensor-gateway protocols are being developed (e.g. LoraWAN), but at a given level all that traffic will end up using 5G network links.

There are other machine type communication requirements that behave more like humans i.e. they require always on (mission critical) connections. For example an autonomous car may use an active data-link to pull down maps, upload sensor data or initiate transactions on behalf of the driver (e.g. pay tolls).

Current networks will find it almost impossible to maintain and service such a large number of hosts with such a wide spectrum of requirements.  In fact this is not a trivial use-case.

 

 

Comparing 5G with 4G

In this section I will highlight the principle differences between 5G and 4G and what features we can look forward to in the next decade:

End to End Latency: Latency is the time taken for a packet to travel from its source to its destination, lower the better. 4G = 25 milliseconds to 5G < 5 milliseconds (5 times less)

Reliability: Percentage of packets that are successfully passed through the network. In this case higher the better. 4G = 99.99% to 5G = 99.999% which means 1 in 100,000 packets is lost.

Service Deployment Time: The time to setup a new service should be as less as possible thereby allowing a faster time to market; basically no one likes to wait! The target is to reduce it from the current 4G wait of 90 days to 90 minutes for 5G.

Energy Efficiency: Energy Efficiency needs to be improved to 10% of current consumption! This is not an easy task and requires a new generation of hardware and software systems.

Device Density: Current networks (4G) support up to 1000 devices per sq. km. but for 5G networks the target density is 1 million per sq. km. Before you start asking how you could fit a million devices per sq. km (maybe if everyone is pushed underground because of nuclear war) remember the machine-type communication use-case with hundreds of thousands of sensors in a city centre environment which contains high density business spaces.

Mobility: Everyone loves fiddling with their phones while commuting. But the second you step on a train or enter an underground system things start going bad unless there is train based ‘free wifi’ or mobile signal boosters are installed. 4G works fairly well for up to 100-150 kmph speeds  (e.g. local trains) but fails badly as you get on the super-fast trains (e.g. intercity express trains that run above 200 kmph). 5G networks are being designed to support ground transport speeds of 500 kmph.

Peak Data Rates: This is a fairly straight forward one, 4G supports 100 Mbps and 5G aims to kick this up to 10Gbps. The one thing to note is that this is an ‘up to’ measure so not all users or locations will get the max (up to) limit. In urban locations a guaranteed minimum speed of 50 Mbps has been promised.

High Data Density: To support large number of human and machine hosts concentrated in a small area the 4G data density of 10 Gb/s/sq. km needs to increase to 10 Tb/s/sq. km.

Universal Provisioning: To improve services in rural or so-called low ARPU (Average Revenue Per User/Unit) areas. This is very important not just for the people living in rural communities but also for service continuity (e.g. while driving on a highway). The challenge is to find a trade-off between financial viability and service offerings in rural locations. 5G networks aim to solve this problem.