A Case for a Stateful Middlebox Networking Stack

Statful middleboxes such as intrustion detection systems, application-layer firewalls, and protocol analyzers are increasingly popular as they perform critical operations in modern networks. Such middleboxes typically operate by maintaining flow states of live TCP connections that pass through a network. Despite its growing demand, developing a stateful middlebox remains a challenging task. The root of complexity stems from a lack of common programming abstraction for middleboxes that clearly separates flow management from custom middlebox logic. As a result, middlebox developers often resort to writing a complex flow management module from scratch, which results in tens of thousands of code lines that are hardly portable [4, 2]. This is in stark contrast to developing networking applications for end nodes, which significantly benefits from a nice network abstraction layer such as Berkeley socket API. The lack of a reusable networking stack for middleboxes makes the code highly dependent on a custom packet library, which greatly reduces readability, modularity, and extensibility. In this work, we formulate a general-purpose flow management stack that serves the basic requirements of monitoring middlebox applications. The flow management stack should satisfy three requirements. First, it should abstract TCP state management such that the developers can focus on the custom middlebox processing instead of dealing with low level detail. Clear separation of flow management and a custom middlebox logic is the key to high code readability and modularity. Second, it should be flexible enough to express any packet or flow-level event that triggers a special middlebox operation. An event can be as simple as TCP state change or packet retransmission. Or one should be able to extend a basic event by evaluating an arbitrary function (e.g., retransmitted packet whose content is different from the original packet). A flexible event-based system enables a developer to write a middlebox application as a set of logical middlebox events and their event handlers. Third, the flow management stack should allow efficient resource management. Depending on the needs of a middlebox, a developer might want to avoid the flow reassembly on the server side while she actively monitors the flow content from the client side. Or one should be able to deallocate all resources for a flow even if the flow has not terminated yet.