Changes between Initial Version and Version 1 of Internal/netfilter

Timestamp:

Apr 16, 2006, 3:15:32 AM (19 years ago)

Author:

ergin

Comment:

—

Internal/netfilter

@@ +1 @@
+= 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 ==
+
+[http://www.netfilter.org/ 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:
+
+[[Image(netfilter1.png)]]
+                 
+
+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'''