Running HIP VPLS on a NanoPI R2S

Introduction

In our previous article we have demonstrated a working prototype of Host Identity Based Virtual Private Service or HIP-VPLS. Back then we used the Mininet framework. Here we are going to demonstrate how to deploy this system on a real hardware. We are going to use NanoPi R2S as the platform for HIP-VPLS. Just a reminder. Virtual Private LAN Services (VPLS) provide means for building Layer 2 communication on top of an existing IP network. VPLS can be built using various approaches. However, when building a production-grade VPLS solution one needs to have a clear picture of how such aspects as security, mobility, and L2 issues will be solved.

Host Identity Protocol (HIP) was originally designed to split the dual role of the IP addresses. In other words, HIP is a Layer 3.5 solution that sits between the IP and transport layers. HIP uses hashes of public keys as identifiers. These identifiers, or Host Identity Tags (HITs), are exposed to the transport layer and never change (well, strictly speaking, they might change if the system administrator will decide to rotate the RSA or ECDSA key pairs for instance, but that will happen rarely). On the other hand, HIP uses routable IP addresses (these can be both IPv4 or IPv6) as locators and are used to deliver the HIP and IPSec packets between the end-points. Overall, to identify each other and exchange secret keys, HIP relies on a 4-way handshake (also known as HIP base exchange, or HIP BEX for short). During the BEX, peers negotiate a set of cryptographic algorithms to be used, identify each other (since HITs are permanent and are bound to public keys HIP can employ a simple firewall based on HITs to filter out untrusted connections), exchange the keys (HIP can use Diffie-Hellman and Elliptic Curve Diffie-Hellman algorithms), and even protect from Denial of Service attacks using computational puzzles (these are based on cryptographic hash functions and ability of peers to find collisions in hash functions; the complexity of a solution is regulated by a responder in HIP BEX). HIP also supports mobility and uses a separate handshake procedure during which the peer notifies its counterpart about the changes in the locator (read the IP address used for routing purposes).

Hardware

In our deployment we have used the following setup. For HIP switches we have used the NanoPI R2S computing platform. We have used 8 port SNR switches to connect 3 NanoPI R2S that way we have mimicked the IP overlay in the setup. NanoPI R2S has two interfaces: one is facing LAN network, the other one is facing the WAN network. NanoPI R2S has the following characteristics: it has 1GB of memory, quad core CPU, 32GB SD card. To wire the routers we have used SNR switches (each switch had 8 1 GB/s ports, and two Small Form Factor (SFP) slots. The testbed configuration is shown on the figure below:

Deploying the system

To deploy the system, we have prepared an FriendlyWRT Linux image and flushed it on SD cards.

We then inserted the cards into NanoPI R2S and ran the following commands:

$ git clone https://github.com/strangebit-io/hip-vpls-hw

Next, we have run the following commands on each router:

#!/bin/bash
cd hip-vpls-hw
echo "Updating the system"
opkg update
echo "Installing libraries"
opkg install nano
opkg install rsync
opkg install python3
opkg install python3-pip
opkg install python3-netifaces
pip3 install pycryptodome
opkg install python3-netifaces
echo "Preparing directories"
mkdir /opt/hip-vpls/
cd ..
echo "Copying the files"
rsync -rv hiplib switchd.py switchfabric.py /opt/hip-vpls/
echo "Copying the service file"
cd startup
cp hip-vpls /etc/init.d/
chmod +x /etc/init.d/hip-vpls
/etc/init.d/hip-vpls enable
/etc/init.d/hip-vpls start

One interesting configuration option that we needed to set was related to promiscuous mode of the Ethernet card (otherwise the raw socket was not picking the unicast frames). So, we have modified the interface configuration as follows:

config interface 'loopback' option device 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd00:ab:cd::/48' config device option name 'eth0' option macaddr '3e:25:61:94:f3:36' config interface 'wan' option device 'eth0' option proto 'static' option ipaddr '1.1.1.4' option netmask '255.255.255.248' config device option name 'eth1' option macaddr '3e:25:61:94:f3:37' option promisc '1' config interface 'lan' option device 'eth1'

We have also reconfigured the firewall rules to allow all network traffic to pass through the router.

We then generated HITs for each HIP switch, configured hosts file and firewall rules (the configuration was previously described here

Experimental evaluation

Overall, the deployed system looked like this:

Using the IPERF tool we have measured the throughput between PC3 and Server0. The results were not so fascinating: we have obtained 1.5Mb/s throughput on a 1GB/s links. We are going to continue to improve the performance of the HIP-VPLS – currently we are trying to compile the source code into C code.