You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
34 lines
4.7 KiB
34 lines
4.7 KiB
\section{ShortCut Implementation}
|
|
\label{implementation_shortcut}
|
|
ShortCut uses knowledge about the device it is run on as well as sent and received packets.
|
|
It should then be able to manipulate routing table entries in case certain conditions are met, e.g. if a specific ip table entry was hit, using the data accessible.
|
|
|
|
The routing table manipulation has to take effect as fast as possible. Furthermore the performance impact of the ShortCut implementation has to be evaluated.
|
|
|
|
|
|
|
|
\subsection{Identifying packets}
|
|
\label{identifying_packets}
|
|
To determine which route should be deleted from the routing table, ShortCut has to gather knowledge about the packets forwarded by the router. The already implemented FRR explained in \cref{implementation_rrt} adds routing tables which will be used depending on the interface the packet was received on. These alternative routes are also added to the default routing table with a lower priority metric, in case the link directly connected to the router would fail.
|
|
|
|
To identify a packet that is returning we already use the incoming interface when implementing FRR. If we would however be able to execute a function when such a packet is received, we would also be able to delete the old invalid routing table entry. For this there are several approaches which could be used.
|
|
|
|
The programming language P4 (\cite{Bosshart.2014}) can be used to write router logic and compile it so that a Mininet routers behaviour could be changed completely. This would also allow us to execute additional functionality in certain cases, e.g. if a specific ip route table entry is hit, but would require a manual implementation of core router functionalities like ARP handling.
|
|
In the context of this work this is not feasible.
|
|
|
|
Another possible solution is the usage of low-complexity controllers, but to be able to accurately identify returning packets, the controller needs in depth knowledge about the routings and policy rules of a router. The easiest way to achieve this would be the implementation of subnets, routes and most of the logic inside the controller through flow table entries, but this would require a re-implementation of most of the routing logic as well.
|
|
|
|
A far more easily implemented solution is packet filtering, which allows us to use most of the pre-existing functionality and logic while still being able to react to certain packets. In most linux distributions this functionality is already supplied using the \textit{nftables} package, which is mostly used for firewalls and therefore has the ability to specify rules for packets which will then be inserted to a multitude of targets, e.g. log files or a so called "netfilter queue".
|
|
|
|
\subsection{Implementation using nftables}
|
|
|
|
Netfilter tables (\textit{nftables}) is a packet filtering tool for implementing firewalls in linux kernels and uses tables to store chains, which are a set of rules for incoming packets hooked to different parts of the network stack. These hook points are provided by the Netfilter kernel interface.
|
|
|
|
It is certainly possible to write software using these hooks directly, but in the scope of this work we will use \textit{nftables} to expose packets using \textit{nftables} rule definitions and their possible targets.
|
|
The targets include log files in which information about a received packet can be stored. An outside software could then monitor said log files and react to entries fitting a certain rule. \textit{nftables} even provides the option to write log prefixes to identify entries.
|
|
|
|
When trying this method it was quickly discovered that even though this would be achievable in a realistic environment with linux kernel based routers, using this method in a namespaced networking environment like Mininet is not possible because logging to the default log file, which is a system log file, is disabled in the kernel. This measure was taken because logging to a system log, which is shared by each networking component in a namespaced network, could cause the host system to suffer from a self-inflicted denial of service attack.
|
|
|
|
A far more sophisticated and also achievable approach in a namespaced networking environment is the usage of "netfilter queues". These were created for the purpose of exposing packets to a userspace software, which is exactly what we are trying to do.
|
|
Netfilter queues can be numbered and are unique to their namespaced component, so that the netfilter queue 1 on router 1 will be different from the netfilter queue 1 on router 2. This is important because it saves us the manual distinction of netfilter queues. A packet hitting a netfilter table rule can then be added to a queue, which can be monitored by e.g. a python script. The python script would then be able to manipulate the ip route tables.
|
|
|
|
|