Netfilter/iptables for ORBIT

This document briefly describes netfilter framework, and lists some of its capabilities. Motivation is to see how regular users of ORBIT can make use of it (if they will ever need it).

Overview

​Netfilter is a packet filtering framework that appeared with Linux kernel version 2.4. It has a complete re-design and netfilter framework can be thought as a successor of ipchains/ipfwadm that were used with 2.0/2.2 kernels.

In many contexts, netfilter and iptables are used interchangeably. The correct way to perceive this is explained as follows. Netfilter is the name given to the overall framework of this packet filtering oriented project. Under this project, there are four main components

• netfilter

This is at the heart of the framework (so, gives its name to the overall framework) and it provides a means for any given kernel module (not necessarily part of netfilter framework) to deal with network packets by letting them register callback functions with the network stack.

• ip_tables

Provides a generic table structure for rulesets and these rules are matched with packets to map them to specific actions. Similar to other components, it uses netfilter for this purpose. Also, (confusingly enough) the name of the userspace program that allows managing the rulesets of ip_tables is called iptables.

• connection tracking

Connection tracking is an integral part of NAT, but it is implemented as a separate module to allow for extensions. It is the `state' module of the framework.

• NAT subsystem

As the name implies, it realizes the NAT process except connection tracking part. NAT, in netfilter terms, should be considered as two different types: Source NAT (SNAT) and Destination NAT (DNAT).

Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the medium. Masquerading is a specialized form of SNAT.

Destination NAT is when you alter the destination address of the first packet: i.e. you are changing where the connection is going to. Destination NAT is always done before routing, when the packet first comes off the wire. Port forwarding, load sharing, and transparent proxying are all forms of DNAT.

Currently, netfilter provides the following hooks to be excited:

The arrows indicate the travel direction of packet as it visits each netfilter hook.

Possible Usage Scenarios

• Easy Packet Filtering

User's experiment is using any standard available routing protocol for Linux (AODV, DSR, Lunar etc.) and he/she is not modifying/maintaining this routing protocols source code. So, by employing iptables, he/she can do stateless or stateful packet filtering (IPv4 or IPv6) based on

• host names, IP addresses, MAC addresses, or physical/logical interface itself
• TCP, UDP, or ICMP protocols
• TCP flags through TCP extensions
• Packet lengths
• Packet type (host/broadcast/multicast)
• TTL / ToS / More Fragments etc.
• IP states through connection tracking

In addition to acting on the above stated conditions, user might use iptables only to log those cases, without doing anything.

• Random Packet Drop

User might use iptables easily to deploy a random packet drop probability between .1⇐p⇐.99 This way, a packet level link quality enforcement (including wired side) can be implemented

• String Search in Packets

User can specify strings to be matched and processed through iptables. This is rather useful for debugging purposes, not content based routing/filtering (it will be real slow otherwise). An example would be checking a custom routing protocols update message to see if a specific destination IP is included in payload.

• IP Header modifications

User can do some basic IP header field manipulations (mangling) like altering the TOS/DSCP/ECN bits of the IP header, without dealing with reading packet to userspace or modifying kernel source.

• Rough Packet Timing

Users may filter or log packets that belong to a time window based on their time of arrival. However, this would have a granularity of at most one minute. Might be used for analyzing a snapshot of packets during a long experiment.

• Forwarding and NAT

By making use of the above matching opportunities, users may define rules to bypass the existing routing mechanism on the node and forward/rewrite packets regardless of nodes normal action plan (by exciting prerouting chain). This can be used to enforce fixed routes, or pseduo multi-hops (through MAC address based drops).

Also, if the experiment requires, user can implement a transparent proxy on a node to check the performance of the scheme under investigation with such a proxy in network.

• More scenarios TBA