Problems with 2.2
- No infrastructure established for passing packet to userspace
- Kernel coding is hard
- Kernel coding must be done in C/C++
- Dynamic filtering policies do not belong in kernel
- 2.2 introduced copying packets to userspace via netlink, but
reinjecting packets is slow, and subject to `sanity' checks
(eg. reinjecting packet claiming to come from an existing
interface is not possible).
- Transparent proxying is a crock
- We look up every packet to see if there is a
socket bound to that address
- Root is allowed to bind to foreign addresses
- Can't redirect locally-generated packets
- REDIRECT doesn't handle UDP replies: redirecting UDP named
packets to 1153 doesn't work because some clients don't like
replies coming from anything other than port 53.
- REDIRECT doesn't coordinate with tcp/udp port allocation: a
user may get a port shadowed by a REDIRECT rule.
- Has been broken at least twice during 2.1 series
- 2.2.1 stats on code:
CONFIG_IP_TRANSPARENT_PROXY: 34 occurances in 11 files.
CONFIG_IP_FIREWALL: 10 occurrances in 5 files.
- Creating packet filter rules independent of interface addresses is
- Must know local interface addresses to distinguish locally-generated
or locally-terminating packets from through packets.
- Even that is not enough in cases of redirection or masquerading.
- Forward chain only has information on outgoing interface.
- Masquerading is tacked onto packet filtering
- Interactions between packet filtering and masquerading make firewalling
- At input filtering, reply packets appear to be destined for box itself
- At forward filtering, demasqueraded packets are not seen at all
- At output filtering, packets appear to come from local box.
- TOS manipulation, redirect, ICMP unreachable and mark (which can
effect port forwarding, routing, and QoS) are tacked onto packet
filter code as well.
- ipchains code is neither modular, nor extensible (eg. MAC address
filtering, options filtering, etc).
- Lack of sufficient infrastructure has led to profusions of
- Masquerading, plus per-protocol modules.
- Fast NAT by routing code (doesn't have per-protocol handling).
- Port forwarding, redirect, auto forwarding.
- No NAPT solution other than masquerading.
- Incompatibility between CONFIG_NET_FASTROUTE and packet filtering
- Forwarded packets traverse three chains anyway
- No way to tell if these chains can be bypassed
- Inspection of packets dropped due to routing protection (eg. Source
Address Verification) not possible.
- No way of atomically reading counters on packet filter rules.