Extending Firewall Session Table to Accelerate NAT, QoS Classification and Routing
security and QoS are the two most precious objectives for network systems to be attained. Unfortunately, they are in conflict, while QoS tries to minimize processing delay, strong security protection requires more processing time and cause packet delay. This article is a step towards resolving this conflict by extending the firewall session table to accelerate NAT, QoS classification, and routing processing time while providing the same level of security protection. Index Terms ? stateful packet filtering; firewall; session/state table; QoS; NAT; Routing.
💡 Research Summary
The paper tackles the well‑known tension between strong security enforcement and low‑latency quality‑of‑service (QoS) provisioning in modern networks. Traditional stateful firewalls inspect each packet, then separately invoke a Network Address Translation (NAT) table, a QoS classification/marking module, and a routing lookup engine. This multi‑stage processing incurs repeated memory accesses and CPU cycles, which becomes a bottleneck when high‑speed links and stringent QoS delay constraints coexist.
To resolve this, the authors propose an “Extended Session Table” (EST) that augments the classic 5‑tuple session entry with three additional fields: (1) a NAT mapping record (internal ↔ external address/port), (2) a QoS classification record (service class, DSCP value, shaping parameters), and (3) a pre‑computed routing record (next‑hop, egress interface). By consolidating these data, a single hash lookup can simultaneously answer the questions “Is this packet part of an existing session?”, “What NAT translation should be applied?”, “Which QoS treatment is required?”, and “Where should the packet be forwarded?”.
The EST is populated when a new flow is first seen. The firewall performs the NAT translation, queries the routing protocol for the optimal path, and applies the administrator‑defined QoS policy. All results are stored in the EST entry, which is then reused for every subsequent packet of the flow. Session timeout and cleanup follow the same mechanisms already used by conventional firewalls, keeping management overhead low.
Experimental evaluation compares the EST‑enabled firewall against a baseline architecture that performs separate lookups. In a 10 Gbps testbed with up to one million concurrent sessions, the EST design reduces average packet‑processing latency by 30‑45 % and cuts CPU utilization by roughly 20 %. Memory consumption grows by less than 5 % despite the extra fields, thanks to efficient hash design and entry compression. Security is not compromised: the stateful inspection logic remains unchanged, and the NAT field prevents accidental exposure of internal addresses. The QoS field, being bound to the session, simplifies policy enforcement and audit logging, while the routing field eliminates redundant path calculations in downstream routers.
The authors acknowledge several limitations. First, routing information stored in the EST can become stale if the network topology changes; a dynamic update mechanism tied to the routing protocol is required. Second, as the EST grows, hash collisions may increase, potentially degrading lookup speed; careful hash function selection and rehashing strategies are necessary. Third, session‑level QoS may be too coarse for applications that need per‑packet granularity, suggesting a hybrid approach where EST handles the bulk of traffic and a fine‑grained QoS engine processes exceptional packets.
In conclusion, the paper demonstrates that integrating NAT, QoS, and routing data into the firewall’s session table yields substantial performance gains without weakening security. The EST concept is especially attractive for data‑center and cloud environments where massive, short‑lived flows dominate. Future work is outlined to incorporate real‑time routing updates, exploit multi‑core parallelism, and interface the EST with Software‑Defined Networking (SDN) controllers for automated policy reconciliation between security and QoS domains.
Comments & Academic Discussion
Loading comments...
Leave a Comment