- The Triad Elements—Address, Route, Rule
- RPDB—The Linux Policy Routing Implementation
- System Packet Paths—IPChains/NetFilter
- Summary
System Packet Paths—IPChains/NetFilter
Understanding the RPDB brings up the question of at what point within the system the RPDB operates. To understand this within the context of the system you need to first see the logic of packet traversal within the system. The best way to approach this traversal is to consider how the packet filtering mechanisms treat this flow.
The various packet filtering mechanisms within the Linux kernel structures deal directly with the conceptualization of the packet flow as a means to identify the control points. They do this so that they may apply their security mechanisms at the control points. These control points are also of interest to the Policy Routing structure because these are the same control points that you would think to operate upon with Policy Routing structures.
IPChains—Kernel 2.1/2.2
Start by considering the logical structure of the packet filtering mechanism within the Linux 2.1/2.2 kernel series. This kernel series is also the one within which the RPDB was implemented and the full scope of Policy Routing structures was developed. The relevant mechanism is that of IPChains. As the name implies, the IPChains packet filtering mechanism considers the implementation of logical control through "chains" of commands implemented to operate upon the defined control points.
The conceptual model is taken from the older IPFWADM model that was implemented in the Linux 1.3/2.0 series kernels. The model describes the traversal of a packet within the system by differentiating between two distinct types of packet sourcing. The first type of packet is one that originates externally to the system and then traverses the system. The second type of packet is one that is either originated from within the system or is originated externally but ends within the system.
This differentiation of origination actually suits the consideration of Policy Routing structures very well. There is a difference when a packet is sourced from the internal system as opposed to a transverse packet passing through the system. Suppose, for example, that you want to apply TOS tagging to the packet. The point at which you apply the tagging would be different for an internally generated packet than for one that passes through the system. In both cases, however, you will probably generate the tagging at an interface.
The concept as proposed with the release of IPFWADM and extended by IPChains is that there are three primary locations in the packet path: the INPUT, OUTPUT, and FORWARD chains. These are the locations at which you would want to intercept the packet. A transverse packet that crosses through the system crosses all three chains, whereas a packet that originates from within the system only crosses two.
Considering again the transverse packet, the logic of traversal is as shown in Figure 3.1.
){kind=link}
Figure 3.1 Packet paths for IPv4 packet filters in Linux 2.1/2.2.
You can see the three main chains: INPUT, OUTPUT, and FORWARD. Think again of the differentiation of the packet paths. Any packet can take one of three paths through the system:
A packet externally sourced that is destined for a service on this machine will enter the system, pass through INPUT, and be routed to the Local Machine.
A packet internally sourced that is destined for an external destination will be routed to OUTPUT.
A transverse packet will pass through INPUT, FORWARD, and OUTPUT, in that order.
Now a note on the actual logic of the packet paths. In all of these considerations the most important one is the location of the ROUTING diamond. This is the location of the RPDB. A packet filter may act on packets entering the system through the INPUT chain. And it may act on packets exiting the system through the OUTPUT chain. But the FORWARD chain actions are modified by the result of the output from the ROUTING. You will go through the examples of how to change the NAT and IP MASQUERADE addresses using this logic in Chapter 8. For now, you should note that the actions of the ROUTING control the connectivity to the Local Machine and also the connectivity to the FORWARD chain.
So using the IPChains packet filter you can modify and preselect the packets that are seen by the RPDB. Thus this acts as an extension of the RPDB rules. One of the more powerful features is the allowance in the RPDB rules to act upon a fwmark. A fwmark is a binary code set in the packet header by the packet filter software. Using this fwmark you can implement packet filter routing mechanisms. An even more powerful feature is the use of the u32 classifier for setting the TOS field in the packet. You will use both of these functions in Chapter 6 to perform advanced selection.
All of these types of tagging functions take place at the INPUT or OUTPUT chains. Now the interactions with the RPDB are only within the ROUTING section, but the interactions with Policy Routing are throughout the system. Consider the example of applying TOS tagging to the packet. If the packet is locally sourced, you would apply the TOS tag after the OUTPUT chain because that is where the tc utility operates. Conversely, for traversal packets you can apply the TOS tag either before the INPUT or after the OUTPUT chain. Also the IP MASQUERADE function of IPChains is applied within the FORWARD chain while the related NAT functions of the RPDB are applied within the ROUTING diamond. These concepts will become points of contention in Chapter 8.
NetFilter—Kernel 2.3/2.4
This contention of packet path location brings up the latest iteration of packet filtering in Linux. NetFilter is the extension of the traditional IPChains with a complete rewrite of the functionality especially with respect to the NAT and IP MASQUERADING functions. The new concept is to consider pure packet selection mechanisms as defining packet filtering while defining any packet selection mechanisms that change the packet information as packet mangling. This makes sense from many standpoints. It even casts a good light on the traditional split of consideration between routing and TOS/QoS structures as you will see in Chapter 6.
What NetFilter does is make this division of function obvious. Consider the packet paths in Figure 3.2.
){kind=link}
Figure 3.2 Packet paths for IPv4 packet filters in Linux 2.3/2.4.
Note that the dotted line tying together the two routing diamonds indicates that these are the same function, the RPDB. The reason for the split is that the routing function is entered in different places in the packet path.
This is due to another change in the packet path policy within NetFilter. The Input(2) and Output(4) chains now only refer to the Local Machine. When you consider that the primary function of a firewall is to protect machines behind it, and that implies transverse packets, then the packet path for NetFilter is much cleaner. Additionally, by placing the INPUT and OUTPUT chains as operating only upon the Local Machine you can create secured server machines.
Consider the path for a transverse packet. It enters the system and is processed by the entrance packet mangling and tagging stage, Pre-Route(1). This stage is where you would apply packet mangling operations such as fwmark and TOS/QoS tagging. The packet then enters the RPDB to obtain routing. From the RPDB it enters the primary firewall chain, Forward(3). The Forward chain is where the firewalling decisions are made. After the Forward chain it enters the exit packet mangling and tagging stage, Post-Route(5). The Pre-Route and Post-Route locations are where you would also apply NAT and IP MASQUERADING functions. Note that these NAT functions are not the same as the RPDB NAT. Indeed, if you want to really confuse matters you can apply both RPDB NAT and NetFilter NAT. You will try this in Chapter 8.
This transverse packet path, assuming you do not do any packet mangling, only then needs to be inspected by two entities, the RPDB and the Forward firewall chain. This is a great improvement in speed and logic when you start considering the interactions of Policy Routing and firewalling. For the purposes of a secured service machine, things are also more logically handled.
Consider the path for an externally sourced packet destined for an internal service. It enters the system and is processed by the entrance packet mangling and tagging stage, Pre-Route(1). This stage is where you would apply packet mangling operations such as fwmark and TOS/QoS tagging or perhaps the NetFilter NAT. The packet then enters the RPDB to obtain routing and is routed to the Input(2) chain. The Input chain provides the firewalling functions for packets destined to the Local Machine services.
The reverse scenario is the packet path for an internal service sourced packet destined for an external system, such as the reply packet to the one described in the previous paragraph. It exits the Local Machine and enters the Output(4) chains, which provides the firewalling functions. It then enters the RPDB for route processing and exits the system via the exit packet mangling and tagging stage, Post-Route(5).
Note that in all of these packet paths, the packet never crosses through more than one packet filter chain, and that in all cases the packet does get processed by the RPDB. So all of the functions associated with the Policy Routing structures under the RPDB may be applied to the packet.