FSM Realtime In-line Flow Blocking DPI Support for Router Mode
- Former user (Deleted)
Design
Architecture Diagram
FSM inspects the packets' data path for content filtering and IP threat detection purposes. The packets are exposed to the dedicated plugins that provide a verdict (block/pass). FSM accesses the datapath following the model illustrated in the opensync.io documentation at: https://www.opensync.io/s/EDE-021-030-501_FSM_Plugins.pdf.
OpenFlow rules can mirror traffic to the TAP interfaces managed by FSM, or can forward the packets to the TAP interfaces. In the latter case, FSM is responsible for injecting the packet back to the data path after inspection if the packet is deemed to be delivered to its final destination. The forwarding model is used for example in the management of DNS replies. These replies are forwarded the the DNS plugin, which decides to drop them (blocking action), inject them back to the data path (allowing action), or modify them prior to re-injecting them to the data path (redirecting action).
To access the packets mirrored/forwarded to the TAP interfaces, FSM currently uses libpcap. It is relatively efficient: there is no data copy involved. The re-injection of the packet in the datapath is done through a raw socket. This involves a data copy.
IP Flow Control
FSM marks the IP flow related to the inspected packet with a value known by the OpenFlow rules: INSPECT, BLOCK, ACCELERATE. The next packet of the same IP flow is processed by OpenFlow based on the flow mark.
The values technically affect the flow contexts managed by the Netfilter Conntrack. OpenFlow queries the Netfilter Conntrack modules to get the IP flow mark and to apply the relevant rule. Please refer to the publicly available Netfilter and OVS OpenFlow documentation for further details.
DPI Access to the IP Packets
OpenFlow rules mirror the traffic destined to the to the DPI engine.
Feature Benefits and Limitations
The benefit of the current approach is that it there is no impact on latency and throughput of the inspected traffic as it is mirrored to the DPI engines: as mentioned above, there is no data copy on the packet access, and no need to forward the packet back in the data path.
Current solution however infers a latency in blocking a flow. By the time FSM marks a flow for blocking, a few packets to be blocked have a window to get through. This can translate in web pages loading content that should be blocked, and messenger apps being able to send data.
Requirements
Realtime in-line flow blocking DPI support requires that blocking a flow has an immediate effect. Hence, this feature requires inline inspection of IP packets. The consequent action on the IP flows remain the same - i.e., the marking an IP flow.
Inline support requires openflow rules to forward each packet to FSM for inspection, and FSM to re-inject the packet if acceptable.
As explained above, access to the packet remains relatively efficient. The re-injection of a packet to the data path does have the potential to impact performance as it requires a copy of the packet.
Gateway in Router Mode
A gateway in router mode can be provisioned to use Netfilter nfqueues as it provides the ability to inspect and re-inject the transport datagram with no data copy. See https://www.netfilter.org/projects/libnetfilter_queue/index.html for details.
In this mode, FSM would access the traffic through nfqueues as opposed to the OVS TAP interfaces.
Gateway in Bridge Mode
Bridge mode is more problematic. Data can be received without a copy involved (AF_PACKET with memory mapped receive buffer), while the transmission of the inspected packet will involve a copy.
Published Content
https://www.opensync.io/s/ERE-021-061-701_FSM_Plugin_Requirements.pdf