CONDITIONAL FILTERING FOR TIME-DETERMINIST FIREWALLS
Patent Information
- Application Number
- DE502023004811
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2022-02-18
- Filing Date
- 2023-02-17
- Publication Date
- 2026-08-27
- Estimated Expiration
- 2043-02-17
AI Technical Summary
Existing firewalls struggle to process time-critical packets in real-time due to variable processing times and load, leading to excessive delays and packet buildup, which is not adequately addressed in current research.
Implementing a method for conditional filtering in firewalls that limits processing time to a predefined maximum (`t_max`) and buffers incomplete packets for later processing, ensuring timely delivery of packets by aborting analysis after `t_max` and storing them for full evaluation when capacity allows.
Guarantees consistent packet processing times, reduces latency, and smooths network load by allowing reprocessing during low-traffic periods, thus ensuring timely arrival of critical packets.
Description
[0001] The present invention relates to a method for implementing conditional filtering for time-deterministic firewalls. The following documents constitute relevant prior art in the technical field of the present application: US 2012 / 140630 A1, US 2003 / 051165 A1 and US 2017 / 111295 A1.
[0002] Firewalls are needed in computer networks to filter data packets sent within the network and forward or discard them according to rules.
[0003] Packet filters (firewalls or switches with ACL rules) examine packets and make decisions based on a set of rules. This rule set can be configured in the firewall.
[0004] The increased volume of real-time traffic means that firewalls must also be able to process packets in real time (i.e., with a predefined delay or processing time). The available time budget may be too small for a complete analysis of the packet against all firewall rules. This can be due to the firewall's load (e.g., the firewall takes too long because other computational operations were prioritized) or to parallel processes running on the firewall (the CPU is being used for something else).
[0005] Today's firewalls don't have time budgets. This can lead to firewalls forwarding packets with excessive delay / latency, causing time-critical packets to arrive late at their destination on the network. Similarly, highly variable processing times cause problems, as they can lead to choppy packet processing and packet buildup. A consistent processing time is therefore advantageous in many cases, especially for accurately predicting and planning packet flows within the network.
[0006] This problem has not been studied extensively in research to date, as firewalls have not been used in conjunction with time-critical traffic. This invention describes a method to address this situation.
[0007] The object of the present invention is therefore to implement a method for ensuring that time-critical packets arrive at the recipient in a timely manner. Accordingly, the invention aims to demonstrate a method for conditional filtering for time-deterministic firewalls.
[0008] This problem is solved by a method according to claim 1. Advantageous embodiments are the subject of the dependent claims.
[0009] A method is proposed to ensure that data packets arrive at the receiver in a network at predefined times. The goal of this method is to predict the time a data packet takes to travel from sender to destination, in order to control and predict network traffic based on these defined times.
[0010] To achieve a constant processing time of a packet by a firewall, it may be useful to abort the analysis of a packet after a fixed time t max and send the packet without a complete evaluation by the firewall.
[0011] We define the total processing time as `t process`. Normally, the packet would be sent at time `t 0 + t process` after arriving at time `t 0`. The duration of `t process` can vary, as it depends on the firewall's processing time and the number of filter rules. A firewall rule set typically consists of several (many) rules. To achieve a constant processing time, a mechanism is proposed that limits it: When the maximum processing time `t max` is reached, rule processing is interrupted, and a predefined result is assumed. The packet is then sent at time `t 0 + t max` (which may be less than `t 0 + t process`). Alternatively, the check can be terminated by dropping the packet after this fixed time. This ensures that subsequent packets only have to wait a defined period.
[0012] Forwarding or dropping the packet is defined as a firewall action in the firewall rule set. Firewall actions can be common firewall actions such as Accept, Drop, Reject, and / or Log. These actions can also be combined.
[0013] If a packet is forwarded, it will be forwarded without full filtering after the maximum processing time t max. This is suitable for packets where timely delivery is more important than a complete evaluation of all firewall rules. Discarding the packet after t max is useful for low-priority packets to avoid spending too much processing time on these less important packets, which could in turn delay high-priority packets.
[0014] The decision regarding which firewall action to apply (drop or forward) can either be configured for traffic classes or determined based on the packet using the firewall's matching rules. This allows different actions to be defined for different packets based on their characteristics. This is the normal function of a firewall.
[0015] Additionally, the maximum processing time tmax can be configured based on the traffic class, or any matching rules can be used to define tmax. New rules can be introduced in the firewall for this purpose, which include the decision of reassigning a processing strategy (forwarding or deleting) and / or a time budget tmax.
[0016] Since sending a packet using this method might result in a packet being forwarded after incomplete inspection at time t0 + tmax, a security problem may arise (when deciding to send). Similarly, important lower-priority packets could be lost (when deciding to discard).
[0017] To address these problems, we additionally plan to not only send and discard incompletely processed packets at time t 0 + t max, but also to store a copy of the packet in a buffer. This copy will then be fully analyzed later, once the firewall has sufficient processing capacity to complete the remaining rules. To achieve this, incompletely aborted packets are copied to a buffer and reintroduced into the filtering process when processing capacity becomes available. In this second, later filtering step, only the rules not yet applied need to be considered. Therefore, when filtering is aborted for a packet, the system also buffers the rule position at which the filtering was interrupted and how the packet was handled (forwarded or deleted).
[0018] In the second (later) filter pass, it can be determined for the cached packets that a forwarding or deletion was incorrect. In the case of incorrect forwarding, another system can be notified (e.g., an attack detection system), or an explicit deletion rule for subsequent traffic can be added to the firewall. This additional rule is placed at the beginning of the firewall's rule list to increase the likelihood of it being processed. In the case of incorrect deletion, the cached copy of the packet can be forwarded after a complete filtering process.
[0019] Since the buffer for packets to be analyzed later is limited, it can be configured to cache packets only for a specific period. Afterward, they can be deleted or sent. Similarly, the buffer can be configured to discard either old or newly arriving packets if there is insufficient space.
[0020] The buffering and / or the second filtering pass can also be performed on an external network device.
[0021] The described method achieves two things: a) it guarantees a processing time for packets regardless of the firewall load. b) it contributes to load smoothing, as packets can be reprocessed during periods of lower load.
[0022] Further features can be seen in the attached figures. They show Figure 1: Timing diagram for packet filtering with a termination criterion; Figure 2: Block diagram for Figure 1 Figure 3: Timing diagram for packet filtering with downstream filtering; Figure 4: Block diagram of Figure 3 .
[0023] Figure 1 The time diagram shows the method according to the invention. Here, a data packet 3 is fed into a network 1 and a firewall 2 to be examined according to the rules stored in the firewall 2. The arrival time of the data packet is denoted by t0.
[0024] Depending on the number of rules to be processed, the performance of Firewall 2, and the processing time required by Firewall 2 upon arrival of the data packet at port 4, the data packet requires a processing time tprocess. However, there are situations where fast forwarding of a data packet is more important than the complete processing of all filter rules in Firewall 2.
[0025] To achieve time-deterministic behavior, it is now introduced that data packet 3 can be sent after a predefined abort criterion, even if filtering in firewall 2 is not yet complete at that time. The abort criterion is defined in Figure 1 A predetermined time t max is defined, which is the maximum waiting time allowed for filtering a data packet 3 in firewall 2. Once this time has elapsed, the filtering is aborted 7 and the data packet is forwarded 8.
[0026] After the time t max has elapsed, the data packet 3 is then sent to output 7 of the firewall 3 and thus forwarded into network 1.
[0027] For this purpose, data packet 3 is marked accordingly, so that it is still recognizable later that no complete filtering by firewall 2 was carried out for this data packet 3.
[0028] Figure 2 clarifies the procedure according to Figure 1 as a block diagram. First, a data packet or data frame is received by the firewall 10. A timestamp is created, or the time of receipt is determined upon arrival 11 at the firewall in a functionally equivalent manner. Then, the firewall begins filtering 12.
[0029] After a filter rule has been processed, the time elapsed since the arrival time (11) is recorded. This elapsed time is then checked to see if it already corresponds to a predefined maximum filtering time. If this time is reached, the termination criterion (15) is met. In this case, the data packet is routed to the firewall exit and thus sent, even though not all filter rules have been processed yet (16).
[0030] Instead of sending 16 of the data packets, a firewall action can also be performed. This can involve forwarding or discarding the data packet (3).
[0031] If the termination criterion 15 has not yet been reached, the system queries (14) whether further rules should be applied through filter processing in the firewall. If so, the data packet is subjected to further filter processing (12).
[0032] If no further filter rules need to be processed, the data packet can also be directed to send 16. In time-deterministic networks, an earlier arriving data packet is uncritical, while a data packet arriving late at the receiver should be avoided.
[0033] Figure 3 The time diagram shows the inventive method according to Figure 1This involves the intermediate storage of data packets and subsequent processing of the data packet. A data packet 3 is fed into a firewall 2 in a network 1 to be examined according to the rules stored in firewall 2. The arrival time of the data packet is described by t0.
[0034] Depending on the number of rules to be processed, the performance of the firewall, and the workload incurred by the firewall upon arrival of the data packet at inlet 4, the data packet requires a processing time tprocess. However, there are situations where fast forwarding of a data packet is more important than the complete processing of all filter rules in firewall 2.
[0035] To achieve time-deterministic behavior, it is now introduced that data packet 3 can be sent after a predefined abort criterion, even if filtering in firewall 2 is not yet complete at that time. The abort criterion is defined in Figure 1 A predetermined time t max is defined, which is the maximum waiting time allowed for filtering a data packet 3 in firewall 2. Once this time has elapsed, the filtering is aborted 7 and the data packet is forwarded 8.
[0036] After the time t max has elapsed, the data packet 3 is then sent to output 7 of the firewall 3 and thus forwarded into network 1.
[0037] For this purpose, data packet 3 is marked accordingly, so that it is still recognizable later that no complete filtering by firewall 2 was carried out for this data packet 3.
[0038] Unlike in Figure 2Data packet 3 is fed into a buffer. This buffer can be integrated into firewall 2, but another network device can also be used for this purpose.
[0039] If the network participant can spare the necessary resources using the cache, the previously interrupted filtering is now resumed (7'). This further rule processing can then be carried out again by Firewall 2 itself or by the network participant using the cache.
[0040] It is proposed to not only mark the data packet in the cache as one for which filtering was aborted, but also to indicate which filter rules still need to be processed until complete filtering.
[0041] The time required for this further filtering must be calculated. It is determined by the defined maximum processing time, after which the processing of Firewall 2 was initially aborted, and the processing time of the subsequent processing. The difference between these two times is then the processing time for the subsequent processing.
[0042] Once post-processing is complete, a firewall action can be initiated. This could mean forwarding the data packet again or discarding the data packet.
[0043] Figure 4 clarifies the procedure according to Figure 3 as a block diagram. First, a data packet or data frame is received by the firewall 10. A timestamp is created, or the time of receipt is determined upon arrival 11 at the firewall in a functionally equivalent manner. Then, the firewall begins filtering 12.
[0044] After a filter rule has been processed, the time elapsed since the arrival time (11) is recorded. This elapsed time is then checked to see if it already corresponds to a predefined maximum filtering time. If this time is reached, the termination criterion (15) is met. In this case, the data packet is routed to the firewall exit and thus sent, even though not all filter rules have been processed yet (16).
[0045] Instead of sending 16 of the data packets, a firewall action can also be performed. This can involve forwarding or discarding the data packet (3).
[0046] If query 17 indicates that not all rules have been processed, the data packet is additionally transferred to a temporary storage area.
[0047] If the termination criterion 15 has not yet been reached, the system queries (14) whether further rules should be applied through filter processing in the firewall. If so, the data packet is subjected to further filter processing (12).
[0048] If no further filter rules need to be processed, the data packet can also be directed to send 16. In time-deterministic networks, an earlier arriving data packet is uncritical, while a data packet arriving late at the receiver should be avoided.
[0049] If a data packet has been marked for later processing and / or the data packet has been included in the buffer for subsequent processing 18, this subsequent processing 18 will take place at a later time when the network participant can spare resources for it.
[0050] The filtering process continues from the point where termination criterion 15 caused the processing to be aborted in the firewall. After filtering is complete, the data packet is then subjected to a firewall action 20 and thus either forwarded or discarded. REFERENCE MARK LIST
[0051] 1 Network 2 Firewall 3 Data packet 4 Input 5 Processing 6 Output 7 Cancel rule processing 7 Continue rule processing 8 Forwarding 8 Forward again 10 Receipt 11 Arrival time 12 Processing 13 Determine processing time 14 Query for further rules 15 Abort criterion 16 Send 17 Query for further rules 18 Later processing 20 Firewall Action
Claims
1. Method enabling data packets (3) to arrive at the receiver at definable times in a network (1), comprising a firewall (2), containing filter rules, in a computer network (1), wherein each data packet (3) is assigned a time budget for processing in the firewall (2), wherein a definable firewall action (20) is carried out for the respective data packet after the time budget has expired, wherein the firewall action (20) is also carried out if the processing of the filter rules in the firewall (2) has not yet been completed when the time budget expires, wherein, in the event that the processing of the filter rules in the firewall (2) has not yet been completed after the time budget has expired, the corresponding data packet is marked and provided with additional information, wherein this marking contains the filter rules that are still outstanding and have not yet been processed by the firewall (2).
2. Method according to Claim 1, characterized in that a processing time of the firewall (2) spans the time from the entry (4) of a data packet (3) at the firewall (2), through processing (5), to the data packet exiting (6) the firewall (2).
3. Method according to either of Claims 1 and 2, characterized in that the time budget for the processing of the data packet (3) in the firewall (2) corresponds to a definable maximum time (15) that may be less than the time (12) of the processing by the firewall (2).
4. Method according to Claim 3, characterized in that the data packet (3) is sent (16) to the exit (7) of the firewall (3) as a firewall action (20) following a stop criterion (15).
5. Method according to Claim 4, characterized in that the data packet (3) is discarded as a firewall action (20) following a stop criterion (15).
6. Method according to Claim 4 or 5, characterized in that the expiry of the defined maximum time (15) is defined as a stop criterion (15).
7. Method according to one of Claims 1 to 6, characterized in that, in the event that the processing of the filter rules in the firewall (2) has not yet been completed after the time budget has expired, the corresponding data packet is stored in a buffer memory.
8. Method according to Claim 7, characterized in that the buffer memory is arranged in a network subscriber outside the firewall (2).
9. Method according to Claim 7 or 8, characterized in that a data packet (3) from the buffer memory is post-processed after the firewall action in order to complete the processing of the filter rules of the firewall (2).
10. Method according to Claim 9, characterized in that, after the filter rules have finished being processed, a firewall action (20) is likewise carried out.
11. Method according to one of Claims 1 to 10, characterized in that data packets (3) have their time recorded upon arrival (11) at the entry (4) to the firewall (2).
12. Method according to one of Claims 1 to 10, characterized in that the processing time corresponds to the time required by the filter processing (12) of the firewall (2) for a data packet (3).
13. Method according to one of Claims 7 to 10, characterized in that the subsequent processing (18) of the filter rules for a data packet (3) in the buffer memory is carried out by a network subscriber outside the firewall (2).