The present invention relates to a method for realizing conditional filtering for time-deterministic firewalls.
Firewalls are needed in computer networks for filtering the data packets sent in the network and for forwarding or discarding them according to rules.
Packet filters (firewall or switch with ACL rules) examine packets and decide based upon a set of rules. This set of rules can be saved in the firewall.
The increased volume of real-time traffic means that firewalls must also be able to process packets in real time (i.e., with a specified delay or processing time). The available time budget may be too small for the complete analysis of the packet with regard to all firewall rules. This can depend upon the load on the firewall (e.g., firewall takes too long because other calculations were processed with priority) or upon parallel processes on the firewall (CPU is being used for something else).
Today, firewalls have no time budgets. As a result, firewalls can forward packets with too much delay/latency, and time-critical packets can therefore arrive too late at the recipient in the network. Likewise, greatly varying processing times cause problems, since they can lead to bursts of package processing and a backlog of packages. A constant processing time is therefore advantageous in many cases, especially for the accurate prediction and planning of packet flows in the network.
So far, this problem has not been examined in depth in the research, because firewalls have not been used in conjunction with time-critical traffic. This invention describes a method for dealing with this situation.
The object of the present invention is therefore to implement a method for ensuring that time-critical packets arrive at the recipient in good time. Accordingly, the invention sets itself the object of demonstrating a method for conditional filtering for time-deterministic firewalls.
This object is achieved by the features of the main claim.
For this purpose, a method is proposed which ensures that data packets in a network arrive at the recipient at specified times. The aim of the method is to be able to predict the time it takes for a data packet from the sender to reach the destination, in order to be able to control and predict data traffic in the network using these defined times.
In order to achieve a constant processing time of a packet through a firewall, it may be useful to terminate the analysis of a packet after a fixed time tmax and to send the packet through the firewall without a complete evaluation.
We assume the complete processing time to be tprocess. Normally, after arriving at time to, the packet would be sent at time t0+tprocess. The time duration tprocess can be variable, since it depends upon the processing time of the firewall and the number of filter rules. A rule set of a firewall usually consists of several (many) rules. In order to achieve a constant processing time, a mechanism is proposed which limits this: When the maximum processing time tmax is reached, the processing of the rules is interrupted, and a predetermined result is assumed. The packet is sent at time t0+tmax (which may be less than t0+tprocess). Alternatively, the check can be terminated by discarding the packet after this fixed time. This ensures that subsequent packets only have to wait a defined time.
Forwarding or discarding 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.
In case of forwarding the packet, the packet is forwarded without complete filtering after the maximum processing time tmax. This is useful for packets where the timely delivery is more important than the complete evaluation of all firewall rules. Discarding the packet after tmax is useful for low-priority packets, in order to avoid spending too much processing time on these less important packets, which in turn could delay high-priority packets.
The decision about which firewall action to apply (discard or forward) can either be configured for traffic classes, or be determined based upon the packet using the matching rules of the firewall. This allows different actions to be defined for different packages based upon the package characteristics. This corresponds to the normal function of a firewall.
In addition, the maximum processing time tmax can be configured based upon the traffic class, or any matching rules can be used to define tmax. For this purpose, new rules can be introduced in the firewall which contain a reassignment of a processing strategy (forward or delete) and/or a time budget tmax as the decision.
Since, when sending a packet according to this method, a packet is forwarded after incomplete checking at time t0+tmax, a security problem may arise (send upon decision). Likewise, important low-priority packets may be lost (discarded upon decision).
To address these problems, we additionally provide for not only sending and discarding incompletely processed packets at time t0+tmax, but also for keeping a copy of the packet in a buffer memory, in order to fully analyze this copy later as soon as the firewall has enough performance reserves to process the remaining rules. For this purpose, unfinished, terminated packets are copied into a buffer memory and fed back into filtering when processing capacity becomes available. In this second, later, filtering step, only the rules that have not yet been applied need to be considered. Therefore, when the filtering of a packet is terminated, the rule position at which the filtering was interrupted and how the packet was handled are also buffered (forwarding or deletion).
In the second (later) filter pass, it can be determined for the buffered packets that forwarding or deletion was incorrect. In case of false forwarding, another system can then be informed (e.g., an attack detection system), or an explicit deletion rule for subsequent traffic can be inserted into the firewall. This additional rule is inserted at the beginning of the rule list of the firewall to make processing this rule more likely. In case of false deletion, the buffered copy of the packet can be retransmitted after complete filtering.
Since the buffer is limited for packets to be analyzed later, the buffer can be configured to buffer packets only for a certain period of time. They can then be deleted or sent. The buffer can also be configured such that, if there is not enough space in the buffer, either old or newly arriving packets are discarded.
The buffering and/or the second filtering pass can also be performed on an external network device.
The described method achieves two things: a) it achieves a guaranteed processing time for packets regardless of the load on the firewall. B) it contributes to load smoothing, since packets can be reprocessed during times of lower load.
Further features are apparent from the accompanying figures. In the drawings:
Depending upon the number of rules to be processed, the performance of the firewall 2, and the amount of work for the firewall 2 when the data packet arrives at the input 4 of the firewall, the data packet requires a processing time tprocess.
However, there are situations in which a fast forwarding of a data packet is more important than the complete processing of all filter rules in the firewall 2.
In order to achieve time-deterministic behavior, it is now introduced that data packet 3 can be sent according to a predefined termination criterion, even if the filtering in the firewall 2 has not yet been completed at this time. As a termination criterion, a predetermined time tmax is defined in
After the time tmax has elapsed, the data packet 3 is sent to the output 7 of the firewall 3 and thereby forwarded to the network 1.
For this purpose, it is helpful if data packet 3 is accordingly marked so that it can also be seen later that, for this data packet 3, complete filtering by firewall 2 was not performed.
After a filter rule has been processed, the time that has passed since the arrival time 11 is recorded. This elapsed time is then checked as to whether 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 output of the firewall and therefore sent 16, even though not all filter rules have been processed yet.
Instead of sending 16 data packets, a firewall action can also be performed. This can include forwarding or discarding the data packet (3).
If the termination criterion 15 has not yet been reached, it is queried 14 as to whether further rules should be implemented by the filtering in the firewall. If this is the case, the data packet is subjected to further filtering 12.
If no further filter rules need to be processed, the data packet can also be forwarded for sending 16. In time-deterministic networks, a data packet arriving earlier is not critical, while a data packet arriving late at the recipient should be avoided.
Depending upon the number of rules to be processed, the performance of the firewall, and the arising workload of the firewall upon the arrival of the data packet at the input 4 of the firewall, the data packet requires a processing time tprocess.
However, there are situations in which a rapid forwarding of a data packet is more important than the complete processing of all filter rules in the firewall 2.
In order to achieve time-deterministic behavior, it is now introduced that data packet 3 can be sent according to a predefined termination criterion, even if the filtering in the firewall 2 has not yet been completed at this time. As a termination criterion, a predetermined time tmax is defined in
After the time tmax has elapsed, the data packet 3 is sent to the output 7 of the firewall 3 and therefore forwarded to the network 1.
For this purpose, it is helpful if data packet 3 is accordingly marked so that it can also be seen later that, for this data packet 3, complete filtering by firewall 2 was not performed.
Unlike in
If the network participant can spare the necessary resources by use of the buffer, the previously terminated filtering is then continued 7′. This further rule processing can then be carried out by the firewall 2 itself or by the network participants by use of the buffer.
For this purpose, it is proposed not only to mark the data packet in the buffer as one for which filtering was terminated, but also which filter rules still need to be processed until filtering is complete.
The time that is required for this further filtering must be calculated. It is determined from the defined maximum processing time after which the processing of firewall 2 was initially terminated and the processing time for post-processing. The difference between the two times is then the processing time for post-processing.
Once the post-processing is complete, a firewall action can be initiated. This can mean reforwarding 8′ the data packet or discarding the data packet.
After a filter rule has been processed, the time that has passed since the arrival time 11 is recorded. This elapsed time is then checked as to whether 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 output of the firewall and therefore sent 16, even though not all filter rules have been processed yet.
Instead of sending 16 data packets, a firewall action can also be performed. This can include forwarding or discarding the data packet (3).
If the query 17 shows that not all rules have been processed, the data packet is also transferred to a buffer.
If the termination criterion 15 has not yet been reached, it is queried 14 as to whether further rules shall be implemented by the filtering in the firewall. If this is the case, the data packet is subjected to further filtering 12.
If no further filter rules need to be processed, the data packet can also be forwarded for sending 16. In time-deterministic networks, a data packet arriving earlier is not critical, while a data packet arriving late at the recipient should be avoided.
If a data packet has been marked for later post-processing, and/or the data packet has been stored in the buffer for subsequent processing 18, this subsequent processing 18 takes place at a later point in time when the network participant can spare resources for it.
The filtering is continued at the point at which the termination criterion caused a termination of the processing in the firewall. After the conclusion of filtering, the data packet is then subjected to a firewall action 20 and is thereby forwarded or discarded.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2022 103 927.7 | Feb 2022 | DE | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2023/054098 | 2/17/2023 | WO |