(51) Int Cl.: H04L 29/06 ( ) H04L 12/24 ( )

(1)

Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the

1 2

31 754

B1

&

(11)

EP 1 231 754 B1

(12)

EUROPEAN PATENT SPECIFICATION

(45) Date of publication and mention

of the grant of the patent:

16.03.2011 Bulletin 2011/11

(21) Application number: 02100042.7 (22) Date of filing: 21.01.2002

(51) Int Cl.:

H04L 29/06(2006.01) _{H04L 12/24}(2006.01)

(54) Handling information about packet data connections in a security gateway element

Handhabung von Information über Datenpaketverbindungen in einer Sicherheitsdurchgangsvorrichtung

Traitement d’information sur les connections paquets de données dans une passerelle de sécurité (84) Designated Contracting States:

DE FR GB

(30) Priority: 12.02.2001 FI 20010256 (43) Date of publication of application:

14.08.2002 Bulletin 2002/33

(73) Proprietor: Stonesoft Corporation

00210 Helsinki (FI)

(72) Inventor: Syvänne, Tuomo

01450 Vantaa (FI)

(74) Representative: Äkräs, Tapio Juhani et al

KOLSTER OY AB P.O. Box 148 (Iso Roobertinkatu 23) 00121 Helsinki (FI) (56) References cited: EP-A- 0 856 974 WO-A-00/05852 WO-A-00/62167 US-A- 5 577 209 US-A- 5 905 859 US-A- 5 907 602 US-A- 6 044 402 US-A- 6 158 010

• BELLOVIN S M ET AL: "NETWORK FIREWALLS" IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER. PISCATAWAY, N.J, US, vol. 32, no. 9, 1 September 1994 (1994-09-01), pages 50-57, XP000476555 ISSN: 0163-6804

• HARI A ET AL: "DETECTING AND RESOLVING PACKET FILTER CONFLICTS" PROCEEDINGS IEEE INFOCOM 2000. THE CONFERENCE ON COMPUTER COMMUNICATIONS. 19TH. ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER ANDCOMMUNICATIONS SOCIETIES. TEL AVIV, ISRAEL, MARCH 26-30, 2000, PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER COMMUN, vol. VOL. 3 OF 3. CONF. 19, 26 March 2000 (2000-03-26), pages 1203-1212, XP001044214 ISBN: 0-7803-5881-3

(2)

5 10 15 20 25 30 35 40 45 50 55 Description

BACKGROUND OF THE INVENTION 1. Field of the Invention

[0001] The invention relates in general to handling in

a security gateway element a connection data structure, in which information about allowed packet data connec-tions is stored. In particular the invention relates to han-dling the connection data structure in a flexible way. 2. Description of Related art

[0002] The local networks of various organizations and

enterprises are nowadays connected to the public Inter-net. To protect a local network, special gateway is usually used to connect the local network to a public network. This special gateway is often called a security gateway or a firewall, and the purpose of a security gateway is to prevent authorized access to the local network. Typically there is need to restrict access to a local network from a public network and/or to restrict access from the local network to the public network or further networks con-nected to the public network. On data packet level this means that data packets, which are entering and/or ex-iting a local network, are screened or filtered in a security gateway. In addition to filtering data packets a security gateway may secure data packets transmitted between, for example, some communication entities. In this case the security gateway is both a firewall and a VPN (Virtual Private Network) gateway.

[0003] Figure 1 illustrates an example with a first local

network 12, a second local network 14 and a public net-work 10. The public netnet-work may be, for example, the Internet. The local networks 12, 14 are connected to the public network 10 via security gateway elements 16 and 18, respectively. A security gateway element 16, 18 may be implemented as one network node (server) or as a cluster of nodes. Term security gateway element is used in this description to refer to a network node or to a cluster of network nodes, where stateful (see below) data packet screening is performed and which connects at least two networks to each other. A security gateway element may be, for example, a plain firewall node screening packets or a firewall node provided with VPN functionality, or a cluster of such nodes.

[0004] Screening of data packets in a network element

may be stateless or stateful. Stateless screening refers to packet filtering, where each packet is handled accord-ing to a set of rules (or other screenaccord-ing information, see below) without any information about history of packets. Stateless screening is typically used, for example, in rout-ers. Stateful screening refers to a situation, where a data packet initiating a packet data connection is accepted using a set of rules, and consequently information about an accepted packet data connection is stored in the net-work element for handling the rest of the data packets

belonging to the opened packet data connection. Secu-rity gateways typically perform stateful screening of data packets. The main reason for using stateful screening is security. Typically, it is required to restrict access from a public network to a local network while allowing entities in the local network to access public network. In stateless screening there must be rules, which allow possible reply packets from the public network to the local network to pass a network element. Many other data packets than proper reply packets may be accepted using such rules. When statefull packet screening is used only those data packets, which are really part of an opened packet data connection, can be accepted.

[0005] The screening of first data packets in stateful

screening is usually done using information specifying at least parts of allowed data packet headers and corre-sponding instructions for processing a data packet. The screening information is usually an ordered set of rules. Figure 2 illustrates as an example a set 20 of rules, having a first rule Rule1, a second rule Rule2, and so forth. The order of the rules in the rule set typically defines the order in which a header of a data packet is compared to the rules. The instructions specified in the first rule, to which the header of a data packet matches, states the action to be carried out for said data packet. The rules are typ-ically listed in a rule file in the order in which they are processed: a rule file thus typically comprises a sequence of rules Rule1, Rule2, ..., RuleN. The rule file is typically stored in a security gateway element, for example in se-curity gateway 16.

[0006] A typical format for the rules is the following:

header information, action. The header information typ-ically involves source address (src), destination address (dst) and protocol (prot) relating to a data packet, and a rule typically has the following form: src, dst, prot, action. This means that for a data packet, which has the indicated header information, the indicated action is carried out. Typically the action defines whether the data packet is discarded or allowed to proceed. As a data packet is proc-essed, its header information is compared to the header information indicated by the rules; the rules are proc-essed in the order defined by the ordered set. Typically the last rule in the ordered set of rules (e.g. RuleN in Figure 2) does not allow any packet to proceed. This means a data packet, whose header information does not match the header information indicated in any of the preceding rules, is discarded.

[0007] In stateful screening information about ongoing

data packet connections or about packet data connec-tions relating to ongoing connecconnec-tions is typically stored in a data structure, which is here called a connection data structure. A data packet initiating a packet data connec-tion and arriving at a security gateway element, is com-pared to the screening information. If a rule allowing the data packet to traverse the security gateway element is found, a corresponding entry is made to the connection data structure. Typically, a connection data structure en-try comprises some header information of the

(3)

corre-5 10 15 20 25 30 35 40 45 50 55

sponding data packet and possibly further additional in-formation. Data packets other than packets initiating a packet data connection are then compared to the con-nection data structure and, if a corresponding entry is found, the packet is allowed to traverse the security gate-way element. Thus, only data packets relating to open packet data connections are accepted. As a further ad-vantage, stateful screening may require less processing power than stateless screening, as data packets of an open packet data connection are checked only against the connection data structure, and there is no need to check if the data packets are in accordance with the giv-en, possibly long, set of rules.

[0008] The part of the connection data structure that

is related to one currently open packet data connection traversing a security gateway element is called an entry. When a packet data connection is closed, the corre-sponding entry is typically removed (or deleted or cleared) from the connection data structure. The number of entries having information about packet data connec-tions thus typically varies as function of time.

[0009] Information about other data packets, which a

security gateway element should allow to proceed, may also be dynamically updated to the connection data struc-ture. In many cases a given set of rules is just basic in-formation for making a decision about allowing a certain data packet to proceed. Additional information may also be needed. Consider, for example, FTP (File Transfer Protocol), which has a control connection and the files are transferred using a separate data connection. This separate data connection should be allowed even though a network element outside the local network initiates the FTP data connection, if a related control connection has been established and a request for opening the data con-nection has been detected within the control concon-nection before the data connection is attempted. A security gate-way element should thus be prepared to receive a data packet initiating such a FTP data connection and to allow such a data packet to proceed. Typically, such a data packet initiating a FTP data connection would not be lowed to proceed on the basis of the rules. It is only al-lowed on the basis of the prior information transferred within the FTP control connection.

[0010] The connection data structure, where

informa-tion about data packets that are allowed to arrive and be processed in a security gateway element, may be, for example, a connection data structure 30 described in Fig-ure 3. In the connection data structFig-ure 30 each entry 31 corresponds to a data packet having the header tion 32 specified in the table entry. The header informa-tion 32 typically comprises the source address, the des-tination address, the source port and the desdes-tination port. A connection data structure entry typically comprises fur-ther additional information 33. This additional information may comprise information about the protocol to which the data packet relates. The protocol may be, for exam-ple, TCP (transmission control protocol) or UDP (User Datagram Protocol). Furthermore, the additional

infor-mation may specify NAT (Network Address Translation) details, encrypting keys, routing information and/or a pro-gram code, which is used to investigate and optionally modify the contents of a data packet. Term protocol-spe-cific program code is here used to refer to program code, which may be either a separate program, an integrate part of a kernel or a kernel module, and which is used to investigate and optionally modify the contents of data packets. A FTP-specific program code, for example, typ-ically monitors the content of data packets relating to a FTP control connection, and when it finds out that a FTP data connection is to be established, it creates a connec-tion data structure entry for the FTP data connecconnec-tion or otherwise informs the software running in the security gateway element to let data packets relating to said FTP data connection to proceed. There may be separate pro-tocol-specific program codes for various protocols or ap-plication programs.

[0011] The set of rules, or other screening information,

is updated every now and then. It may be updated, for example, periodically to ensure that too old screening information is not used. Alternatively, new screening in-formation may be delivered to a security gateway ele-ment from a manageele-ment system after the screening formation has been modified, that is, new screening in-formation is pushed to the security gateway element from the management system.

[0012] In current security gateway elements, when

screening information is updated, a connection data structure is typically cleared. Clearing the connection da-ta structure causes esda-tablished connections to fail since the connection data structure entry which is required for accepting the packets other that the packet initiating a connection are lost. This is a problem especially in cir-cumstances, where connections should be as reliable as possible.

[0013] A second way to handle ongoing packet data,

when screening information is updated, is to maintain information about the open connections in the connection data structure. This way existing packet data connections survive, and the packet data connections are as reliable as possible. There may, however, be existing packet data connections which are not in accordance with the updat-ed screening information, and this may cause security risks. Some security gateways give the user a possibility to select between dropping all existing packet data con-nections and allowing all existing packet data connec-tions. Such a selection is a selection between security and network usability.

[0014] A further way to handle ongoing packet data

connections when screening information is updated may have, for example, the following features. Before clearing a connection data structure, the connection data struc-ture is copied to a previous connection data strucstruc-ture. The connection data structure is then cleared, and there-fore all arriving data packets are handled using the up-dated screening information. Typically only data packets initiating a packet data connection may be compared to

(4)

5 10 15 20 25 30 35 40 45 50 55

screening information. It is possible, however, to make an exception to this rule. In this case, all arriving data packets are compared to the screening information. If the updated screening information contains a rule allow-ing said data packet to pass but the packet is not a packet initiating a new connection, it is checked if the previous connection data structure contains an entry allowing the data packet to proceed. If such entry is found, an entry relating to this packet data connection is added to the connection data structure. These features prevent some existing packet data connections to be dropped. For ex-ample FTP data connection is, however, dropped, as it is accepted on the basis of the FTP control connection, not directly on the basis of a rule.

[0015] WO0062167 discloses an Intrusion and Misuse

Deterrence System (IMDS) that passively detects net-work intruders. The IMDS creates a synthetic netnet-work complete with synthetic hosts and routers to monitor packet flow in an enterprise until it determines that a pack-et is destined for the synthpack-etic npack-etwork. Since there are no legitimate users on the synthetic or virtual network, the IMDS identifies the source of the packet and notifies a system administrator of the presence of a network in-truder.

[0016] EP0856974 discloses a "session cache" that

tracks cache rule versions and dynamic filter rule ver-sions in such a way that outdated cache rules are detect-ed, deleted from memory and replaced upon being called upon and before being applied to a packet, while rules unaffected by a change in a local rule base are left intact in the cache.

[0017] US5577209 discloses a secure network

inter-face unit (SNIU) coupled between each host or user com-puter unit, which may be non-secure, and a network, which may be non-secure, and a security management (SM) architecture, including a security manager (SM) connected to each of the SNIUS for controlling their op-eration and configuration on the network. The SM archi-tecture is implemented to ensure user accountability, configuration management, security administration, and cryptographic key management among the SNIUS.

[0018] BELLOVIN S M ET AL: "NETWORK

FIRE-WALLS" IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER. PISCATAWAY, N.J, US, vol. 32, no. 9, 1 September 1994 (1994-09-01), pages 50-57, XP000476555 ISSN: 0163-6804, provides a review on network firewalls.

[0019] HARI A ET AL: "DETECTING AND

RESOLV-ING PACKET FILTER CONFLICTS" PROCEEDRESOLV-INGS IEEE INFOCOM 2000. THE CONFERENCE ON COM-PUTER COMMUNICATIONS. 19TH. ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER ANDCOM-MUNICATIONS SOCIETIES. TEL A VIV, ISRAEL, MARCH 26-30, 2000, PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER COMMUN, vol. VOL. 3 OF 3. CONF. 19, 26 March 2000 (2000-03-26), pages 1203-1212, XP001044214 ISBN: 0-7803-5881-3, discloses a new way for detecting and resolving packet

filter conflicts.

SUMMARY OF THE INVENTION

[0020] Object of the invention is to present a flexible

method and arrangement for handling information about existing packet data connections in a security gateway element. A further object is to present such a method and arrangement for handling information about existing packet data connections which allows packet data con-nections via a security gateway element to be reliable even when screening information is updated.

[0021] Objects of the invention are achieved by

clas-sifying, after screening information is updated, packet data connections to packet data connections in accord-ance with new screening information and packet data connections in conflict with new screening information.

[0022] A method according to the invention is a method

for handling information about packet data connections, which arrive at a security gateway element, in order to have in a connection data structure information about packet data connections in accordance with current screening information, said connection data structure comprising a number of entries representing a number of packet data connections, said method comprises the step of:

- storing data packet header information about packet data connections, which are in accordance with first screening information, in said connection data struc-ture, and

- receiving updated screening information, said updat-ed screening information forming either by itself or in connection with said first screening information second screening information,

and said method is characterized in that if further com-prises the step of:

- after receiving said updated screening information, comparing entries of said connection data structure to said second screening information, resulting in a classification of said entries as first entries, said first entries representing packet data connections in ac-cordance with said second screening information, and as second entries, said second entries repre-senting packet data connections in conflict with said second screening information.

[0023] A security gateway element according to the

invention is a gateway element comprising

- means for processing data packets so that data packet connections in accordance with current screening information are allowed to proceed,

- means for storing first screening information used as current screening information,

(5)

in-5 10 15 20 25 30 35 40 45 50 55

formation about packet data connections in accord-ance with the first screening information, and

- means for receiving updated screening information, which by itself or together with the first screening information forms second screening information, and the security gateway element is characterized in that it further comprises

- means for comparing entries in said connection data structure to second screening information, resulting in a classification of said entries as first entries, said first entries representing packet data connections in accordance with said second screening information, and as second entries, said second entries repre-senting packet data connections in conflict with said second screening information.

[0024] The invention further relates to a management

system relating to at least one security gateway element, said management system comprising

- means for defining screening information, and

- means for delivering screening information to said at least one security gateway element,

and said management system being characterized in that if further comprises

- means for receiving from said at least one security gateway element information indicating all or some of packet data connections that said at least one se-curity gateway element, after updating screening in-formation in said at least one security gateway ele-ment, has classified to be in conflict with the delivered screening information,

- means for representing said information indicating all or some packet data connections to a user, said means arranged to produce a confirmation as a re-sponse to user actions, and

- means for sending said confirmation to said at least one security gateway element.

[0025] The invention relates also to a computer

pro-gram comprising propro-gram code for performing all the steps of a method in accordance with the invention, when said program is run on a computer.

[0026] The invention further relates to a computer

pro-gram product comprising propro-gram code means stored on a computer readable medium for performing a method according to the invention, when said program product is run on a computer.

[0027] A connection data structure according to the

invention is a data structure comprising a number of en-tries representing a number of packet data connections, said entries comprising header information of data pack-ets, and the connection data structure is characterized in that at least one of said entries further involves accept-ance information relating to grounds for accepting the represented packet data connections to traverse a secu-rity gateway element when, after screening information is updated in said security gateway element, packet data

connections are classified to packet data connections in accordance with the updated screening information and packet data connections in conflict with the updated screening information.

[0028] According to an embodiment of the invention at

least one of said entries further comprises information indicating the current screening information at the time of creation of said entry.

[0029] The appended dependent claims describe

some preferred embodiments of the invention. The fea-tures described in one dependent claim may be further combined with features described in another dependent claim to produce further embodiments of the invention.

[0030] The packet data connections discussed here

are typically packet data connections on IP protocol. In this specification and in the appended claims, term pack-et data connection refers here to a bi-directional flow of data packets. Examples of such packet data connections are TCP connections, bi-directional UDP packet flows, UDP queries, ICMP (Internet Control Message Protocol) queries and replies.

[0031] In this specification and in the appended claims,

term entry refers to a piece of information relating to one packet data connection. An entry typically comprises in-formation at least about data packet headers. Term con-nection data structure refers to a data structure, whose entries represent packet data connections arriving at a security gateway. A connection data structure may be, for example, a table or a linked list or any other more versatile data structure.

[0032] According to the invention, packet data

connec-tions represented in a connection data structure are clas-sified as packet data connections in accordance with up-dated screening information and as packet data connec-tions in conflict updated screening information. After this classification it is possible to ensure that packet data con-nections in accordance with updated screening informa-tion are allowed to traverse a security gateway element. This is the main advantage of the invention. Furthermore, it is possible to inspect the packet data connections in conflict with updated screening information before pos-sibly rejecting part or all of these packet data connections. This can be made, for example, by representing a list of existing packet data connections that are not allowed with new set of rules to the administrator, who can then decide if he or she wants to terminate those or not.

[0033] The screening information is typically a set of

rules. It may be, for example, an ordered sequence of rules, and a data packet is processed by comparing head-er information of the data packet to the rules, rule by rule, in the order dictated by the sequence numbers. Alterna-tively, screening information may be a hierarchically or-dered, so that a certain rule may have a number of sub-rules and, typically, header information common to all said subrules is specified in said certain rule. In this case data packets are compared to subrules only if the header information of a data packet matches first the header information specified in the rule, to which the subrules

(6)

5 10 15 20 25 30 35 40 45 50 55 are subordinates.

BRIEF DESCRIPTION OF THE DRAWING

[0034] The invention is now described in more detail

with reference to the accompanying drawing, where Figure 1 illustrates two local networks connected to

a public network via security gateways, Figure 2 illustrates a set of rules for screening data

packets according to prior art,

Figure 3 illustrates a prior art connection data struc-ture,

Figure 4 illustrates as an example a flowchart of a method according to the invention, where interaction with a management system is involved,

Figure 5 illustrates as an example a connection data structure according to the invention, Figure 6 illustrates as examples flowcharts of two

methods according to the invention, where different information relating to existing packet data connections is compared to new screening information,

Figure 7 illustrates as examples flowcharts of two methods according to the invention, where different ways to carry out the comparison are involved,

Figure 8 illustrates as an example a flowchart of a method for testing validity of screening in-formation update employing the invention, Figure 9 illustrates as an example a flowchart of a method for updating screening information, said method employing the invention, and Figure 10 illustrates as an example a security gate-way element and a management system according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0035] Figures 1-3 are discussed in more detail above

in connection with the prior art description.

[0036] Figure 4 illustrates as an example a flowchart

of a method 400, which is a method for handling infor-mation about packet data connections, which arrive at a security gateway element and which are in accordance with current screening information.

[0037] In step 401 information about packet data

con-nections, which are in accordance with first screening information, is stored in a connection data structure, said connection data structure consequently comprising a number of entries representing a number of existing packet data connections arriving at a security gateway element. In step 402 updated screening information is received. This updated screening information forms new (second) screening information on its own or together with the first screening information. Typically this updated screening information is pushed from a management

system. It is possible that a security gateway element asks for updated screening information if, for example, too long time has elapsed since it has received the latest update.

[0038] In step 403 entries of said connection data

structure are compared to new (second) screening infor-mation. As a result, the entries are classified as first en-tries representing packet data connections in accord-ance with said second screening information or as sec-ond entries representing packet data connections in con-flict with said second screening information.

[0039] Steps 404-406 relate to interaction between a

management system and a security gateway element. In step 404 a security gateway element indicates the packet data connections, which are mentioned in a con-nection data structure and which are conflicting the new screening information. In step 405 a security gateway element requests, either implicitly by indicating the pack-et data connections in step 404 or explicitly, a confirma-tion whether to reject the conflicting packet data connec-tions. A user of a management system may at this point decide, which packet data connections are rejected or, for example, if the entries corresponding to those packet data connections are modified. If a confirmation is re-ceived (step 406), the conflicting packet data connections and relating connection data structure entries are proc-essed according to said confirmation. If a confirmation is not received, a security gateway element may, for exam-ple, reject the conflicting packet data connections. Typ-ically data packets relating to conflicting packet data con-nections are allowed to proceed until a confirmation to reject those data packets is received or a timeout occurs.

[0040] Method 400 and especially the steps relating to

interaction between a management system and a secu-rity gateway element are presented here as an example. The details of methods employed in management sys-tems and security gateway elements in accordance with the invention may vary from those presented above.

[0041] Figure 5 illustrates as an example a connection

data structure 50 according to the invention. The con-nection data structure comprises information about pack-et data connections arriving at a security gateway ele-ment. In addition to header information 32 and additional information 33, which are discussed in more detail above in connection with prior art connection data structures and corresponding data structures, entry 51a of connec-tion data structure 50 comprises acceptance informaconnec-tion 55 relating to the grounds according to which the packet data connection represented by the entry 51a is allowed to traverse a security gateway element. This acceptance information may be, for example, a rule identifier 55a of that rule, according to which the packet data connection is allowed. Alternatively, it is possible that data packet connections are allowed, if the user (or process) opening the packet data connection is authenticated. This authen-tication may be performed in a variety of ways. In this case typically a user (process) identifier 55b of a validly authenticated user (process) may be stored in a

(7)

connec-5 10 15 20 25 30 35 40 45 50 55

tion data structure entry. Furthermore a packet data con-nection may be allowed, because a relating concon-nection is allowed. This is the case for example, for FTP protocol, as described in connection with the description of prior art. In this case, information 55c indicating a relating rule is present in the connection data structure. This informa-tion may be part of the entry in a connecinforma-tion data struc-ture, or the relating connection may be concluded from the structure of the connection data structure. For exam-ple, connections relating to a certain control connection may be represented by linking entries of said connections to the entry of the control connection. A further example of acceptance information is information 55d relating to a secure tunnel (a VPN tunnel) within which the data packet connection is.

[0042] Typically all elements of a connection data

structure 50 according to the invention comprise accept-ance information 55, as illustrated in Figure 5. Figure 6a below illustrates a method, where a connection data structure according to the invention is used. Connection data structure entries may further or alternatively com-prise information 56 indicating which version of the screening information was used when the connection da-ta structure entry was created. This information 56 may be, for example, a time stamp 56a or a version number 56b of the screening information. Figure 7b below illus-trates a method where such information is useful.

[0043] Figure 6 illustrates as examples flowcharts of

two methods 600 and 610 according to the invention. In methods 600 and 610 different information, information which typically is stored in connection data structure en-tries, is compared to new (second) screening information. Figure 6a illustrates method 600, where a connection data structure 50, for example, is used. The first step of method 600 is similar to step 401. In step 602 acceptance information relating to an entry is stored. This acceptance information is typically stored in the corresponding entry. In step 402 updated screening information is received, as in method 400. Thereafter, in step 602 (which is a more detailed description of step 403) acceptance infor-mation stored in connection data structure entries is com-pared to new (second) screening information.

[0044] If the acceptance information is a rule identifier,

in step 602 it is typically checked that a rule having the same identifier is present also in the new (second) screening information and that it is not preceded by a rule inhibiting said packet data connection to be accepted based on the specific, identified rule. If the acceptance information is a user identifier, it typically implies that this specific user has been validly authenticated. Therefore it is checked if a rule allowing a packet data connection by the specified user is present in the new (second) screening information. If the acceptance information in-dicates a relating packet data connection, it is typically checked if the relating connection still exists and if it is allowed according to the new (second) screening infor-mation. If the acceptance information is a relating secure tunnel, e.g. a VPN tunnel, it is checked, if a rule allowing

a connection using said specified tunnel is present in the new (second) screening information and if the encrypting methods are still valid.

[0045] Figure 6b illustrates method 610, where a prior

art connection data structure or other connection data structure not specifying acceptance information may be employed. The first and second steps of method 600 are similar to steps 401 and 402 of method 400. In the third step 611, which is a more detailed description of step 403, header information stored in connection data struc-ture is compared to new (second) screening information. The connection data structure entries may be treated similarly as data packets, which are processed in a se-curity gateway element. The header information stored in a connection data structure entry is sufficient for this. If a rule (or other corresponding piece of screening infor-mation) in new (second) screening information allows a data packet having the header information specified in an entry to proceed, the entry is kept in the connection data structure, otherwise the entry is typically deleted.

[0046] In many cases it is advantageous to use the

method of Figure 6a, in other words to store acceptance information relating to the packet data connections. This enhances especially the handling of more complicated protocols that, say, just plain TCP. For example, in case of FTP connection the rule allowing the packet data con-nection covers both the control concon-nection and the data connection, even though data connection is not allowed as such without the control connection. Nevertheless, it is possible to verify that also a certain FTP data connec-tion is in accordance with the new screening informaconnec-tion, if the rule that allowed the control connection relating to this certain FTP data connection is in accordance with the new screening information. This implies also to any other (complicated) protocols in which opening one or more connections requires that some other connection is opened first, or to any other connections that are not accepted purely on the basis of a rule, but require for example authentication.

[0047] Figure 7 illustrates as examples flowcharts of

two methods 700 and 710 according to the invention. In these methods different ways to carry out the comparison of the connection data structure entries are used.

[0048] Figure 7a illustrates method 700, where a

snap-shot of the connection data structure is taken (step 701) after receipt of updated screening information. The con-nection data structure may be, for example, a data struc-ture to which a kernel process compares arriving data packets and which a kernel process updates. The snap-shot may be, for example, taken so that the actual con-nection data structure is all the time updated by a kernel process (using, when needed, the new screening infor-mation), but another process (which may be a user proc-ess and which typically performs the comparing of con-nection data structure entries in step 403, 702) sees the contents of the connection data structure at a certain mo-ment in time. At least some of the connection data struc-ture entries, which represent packet data connections

(8)

5 10 15 20 25 30 35 40 45 50 55

conflicting the new screening information, are typically deleted (step 703). It is possible that some of the con-nection data structure entries representing packet data connections in accordance with the new screening infor-mation are modified (step 704). If a connection data struc-ture entry comprises, for example, information about an interface, via which data packets of said packet data con-nection arrive at the security gateway element, this infor-mation may be modified for example for enforcing a check according to new anti-spoofing settings.

[0049] The above example of providing a snapshot of

a connection data structure to a user process is given as an example of implementing a method in accordance with the invention. Some operating systems have functionality to provide to various processes various views about a certain object.

[0050] In method 710, which is illustrated in Figure 7b,

the connection data structure entries are compared - one by one - to new (second) screening information. It is pos-sible to make this comparison and allow entries to be added to the connection data structure at the same time. One way to do this is to store - typically to the connection data structure entries themselves - information about the screening information version, based on which an entry has been added to the connection data structure. This information is stored in step 711. In comparing connec-tion data structure entries (step 403, 712), those entries which are based on the new screening information, need not be compared.

[0051] It is possible to interrupt the processing of those

data packets, which do not initiate packet data connec-tions, for the duration of the comparison in steps 403, 702, 712. This prevents data packets relating to packet data connections conflicting the new screening informa-tion from traversing the security gateway element. As the comparison typically takes only some milliseconds, a de-lay, which may be caused for data packets relating to packet data connections in accordance with the new screening information, is often practically negligible and should not affect these packet data connections.

[0052] The comparison (step 403) in methods 700 and

701 may be done, for example, by comparing header information stored in connection data structure entries to new screening information (cf. step 611) or by comparing acceptance information to new screening information (cf. step 602).

[0053] It is possible to combine the features presented

in method 400 together with those features presented either in method 600 or 610 and/or together with those presented either in method 700 or 710. Additionally, it is not required to perform all the steps presented in the Figures in order to use the invention, but some of the steps may be optionally ignored. Furthermore, the order of the steps in Figures is not meant to be restrictive. For example, steps 702/712 and steps 703 and 704 may be performed in the order presented in Figures or, for ex-ample, by interleaving steps 712 and 703 so that after an entry conflicting new screening information is found,

it is deleted and then a next entry conflicting new screen-ing information is searched for. Similarly, steps 712 and 704 may be interleaved, as well as steps 702, 703 and 704.

of a method 800 for testing validity of screening informa-tion update. In step 401 informainforma-tion about packet data connections is stored in a connection data structure. In step 801 information indicating that the next updated screening information is sent for testing purposes is ceived. After the updated screening information is re-ceived (step 402) and connection data structure entries are compared to the new screening information (step 403), information about said comparison is transmitted (step 802), for example, to a management system. This information may, for example, comprise a list of those packet data connections, which are in conflict with the new screening information. This method allows evalua-tion of the effect of certain updated screening informaevalua-tion. This method need not involve an actual security gateway element and an actual management system, but it may be used, for example, in simulations.

of a method 900 for updating screening information. In this method first screening information is saved (step 901) as a precaution, to allow rejection of updated screening information. After comparing connection data structure entries to new screening information, informa-tion about the packet data connecinforma-tions conflicting new screening information, for example, is transmitted (step 802). Thereafter either a confirmation for taking the new screening information into use is received (steps 904, 703, 704) or the confirmation is not received and the up-dated screening information is discarded (step 903). In this case the first screening information is still used in accepting data packet connections.

[0056] Figure 10 illustrates an example of a security

gateway element according to the invention. The security gateway element 1000 comprises means 1001 for processing data packets so that data packet connections in accordance with current screening information are al-lowed to proceed. The current screening information is stored in means 1002, and typically screening informa-tion is a set of rules. Typically the means 1001 are ar-ranged to compare a data packet first to entries in a con-nection data structure, where information about open packet data connections are stored, and only if a match-ing entry cannot be found, the data packet is compared to the current screening information. Typically, only data packets initiating a packet data connection are compared to the current screening information. Means 1003 are used for storing in the connection data structure informa-tion about current packet data connecinforma-tions in accordance with first screening information. The security gateway el-ement 1000 further comprises means 1004 for receiving updated screening information, which by itself or together with the first screening information forms second screen-ing information, which is to replace the first screenscreen-ing

(9)

5 10 15 20 25 30 35 40 45 50 55

information currently stored in means 1002.

[0057] The security gateway element 1000 is

charac-terized in that it further comprises means 1005 for com-paring entries of said connection data structure to second screening information, thus classifying entries in said connection data structure as first entries, said first entries representing packet data connections in accordance with said second screening information, or as second entries, said second entries representing packet data connec-tions in conflict with said second screening information.

[0058] The security gateway element 1000 further

comprises means 1006 for rejecting packet data connec-tions conflicting new (second) screening information, for example by deleting or modifying some of said second entries from said connection data structure. The security gateway element 1000 typically further comprises means 1007 for indicating to a management system all or some of the packet data connections conflicting the second screening information, and means 1008 for receiving a confirmation from the management system whether to reject all or some of the packet data connections conflict-ing the second screenconflict-ing information. Furthermore, it is possible that said means 1006 for rejecting packet data connections are arranged to delete all packet data con-nections conflicting the second screening information, if a confirmation is not received within a predefined period of time.

invention may further comprise any of the following means:

- means for receiving information indicating the re-ceipt of test update screening information,

- means for transmitting information about compari-son connection data structure entries to new (sec-ond) screening information, said information about comparison being typically a list of packet data con-nections conflicting the new screening information,

- means for storing first screening information as a precaution, and

- means for receiving a confirmation to use updated screening information.

[0060] Figure 10 illustrates also an example of a

man-agement system relating to at least one security gateway element. This management system 1050 comprises means 1051 for defining screening information, and means 1052 for delivering screening information to said at least one security gateway element. It further compris-es means 1053 for receiving from said at least one se-curity gateway element information indicating all or some of packet data connections conflicting the delivered screening information. Means 1054 for representing said information indicating all or some packet data connec-tions to a user are arranged to produce a confirmation as a response to user actions. A security gateway ele-ment 1000 typically comprises also means 1055 for send-ing said confirmation to said at least one security gateway

element.

[0061] A management system according to the

inven-tion may further comprise any of the following means in addition or alternatively to means 1053-1055:

- means for sending information indicating the receipt of test updated screening information,

- means for receiving information about comparison connection data structure entries to new (second) screening information, said information about com-parison being typically a list of packet data connec-tions conflicting the new screening information,

- means for deciding on a use of updated screening information based at least on said information about comparison, and

- means for sending a confirmation to use updated screening information.

invention may be one network node or a cluster of net-work nodes. The means 1001-1008 and 1051-1055, or any other means mentioned in connection with Figure 10 or in the appended claims, are typically implemented as a suitable combination of hardware and software. They are advantageously implemented using software pro-gram code means executed by a processor unit. A se-curity gateway element according to the invention may employ any method according to the invention. Some examples of such methods are described above.

[0063] In the view of the foregoing description it will be

evident to a person skilled in the art that various modifi-cation may be made within the scope of the invention. It should be apparent that many modifications and varia-tions to the above described examples are possible, all of which fall within the scope of the invention.

Claims

1. A method (400, 600, 610, 700, 710, 800, 900) for

handling information about packet data connections, which arrive at a security gateway element, in order to have in a connection data structure information about packet data connections in accordance with current screening information, said connection data structure comprising a number of entries represent-ing a number of packet data connections, said meth-od comprising the steps of:

- storing (401) data packet header information about packet data connections, which are in ac-cordance with first screening information, in said connection data structure, and

- receiving (402) updated screening information, said updated screening information forming ei-ther by itself or in connection with said first screening information second screening infor-mation,

(10)

5 10 15 20 25 30 35 40 45 50 55

characterized in that said method further

compris-es the step of:

- after receiving said updated screening infor-mation, comparing (403) entries of said connec-tion data structure to said second screening in-formation, resulting in a classification of said en-tries as first enen-tries, said first enen-tries represent-ing packet data connections in accordance with said second screening information, and as sec-ond entries, said secsec-ond entries representing packet data connections in conflict with said sec-ond screening information.

2. A method according to claim 1, characterized in that it further comprises the step of:

- storing (601) for a packet data connection ceptance information relating to grounds for ac-cepting that packet data connection,

and in that said acceptance information is used (602) in comparing entries of said connection data structure to said second screening information.

3. A method according to claim 2, characterized in that said acceptance information is stored to a same

connection data structure entry (50) as data packet header information about a packet data connection.

4. A method according to claim 2, characterized in that said screening information comprises a number

of rules and said acceptance information is a rule identifier (55a) of that rule with which a packet data connection is in accordance.

5. A method according to claim 2, characterized in that said acceptance information is information

(55b) identifying an authenticated entity.

6. A method according to claim 2, characterized in that said acceptance information is information (55c)

identifying a relating packet data connection.

7. A method according to claim 6, characterized in that a specific form of said packet data connection

data structure indicates said relating packet data connection.

8. A method according to claim 2, characterized in that said acceptance information is information

(55d) identifying a secured tunnel, within which the packet data connection is tunneled.

9. A method (610) according to claim 1, characterized in that in comparing (403, 611) entries of said

con-nection data structure to said second screening in-formation, it is checked if packet data header

infor-mation stored in said entries is in accordance with second screening information.

10. A method (700) according to claim 1, characterized in that it further comprises the step of:

- deleting (703) at least one of said second en-tries from said connection data structure.

- modifying (704) at least one of said first entries in said connection data structure.

- storing (701) contents of said connection data structure at a certain time in order to use the stored contents in comparing of entries of said connection data structure.

- storing (711) in a connection data structure en-try (50) information (56) indicating current screening information version at the time of add-ing a connection data structure entry,

and in that in comparing (403, 712) entries of said connection data structure to second screening mation, only entries specifying first screening infor-mation as current screening inforinfor-mation are com-pared.

14. A method (400) according to claim 1, characterized in that it further comprises the steps of:

- indicating (404) to a management system all or some of the packet data connections conflict-ing the second screenconflict-ing information and rep-resented by said the second entries, and - requesting (405) a confirmation from the man-agement system whether to reject packet data connections conflicting said second screening information.

15. A method (400) according to claim 14, character-ized in that said packet data connections conflicting

said second screening information are rejected (408) after a predefined period of time in the absence of the confirmation by deleting relating entries of said connection data structure

16. A method (800) according to claim 1, characterized in that it further comprises the steps of:

(11)

5 10 15 20 25 30 35 40 45 50 55

- receiving (801) information indicating that the second screening information is only for test use, and

- transmitting (802) information about results of said comparison.

- storing (811) said first screening information as a precaution, enabling the return to using said first screening information as current screening information.

- modifying (703, 704) said connection data structure based on said comparison.

19. A security gateway element (1000) comprising

- means (1001) for processing data packets so that data packet connections in accordance with current screening information are allowed to proceed,

- means (1002) for storing first screening infor-mation used as current screening inforinfor-mation, - means (1003) for storing in a connection data structure information about packet data connec-tions in accordance with the first screening in-formation, and

- means (1004) for receiving updated screening information, which by itself or together with the first screening information forms second screen-ing information, characterized in that it further comprises

- means (1005) for comparing entries in said connection data structure to second screening information, resulting in a classification of said entries as first entries, said first entries repre-senting packet data connections in accordance with said second screening information, and as second entries, said second entries represent-ing packet data connections in conflict with said second screening information.

20. A security gateway element according to claim 19, characterized in that said means for processing

data packets are arranged to compare data packets to said connection data structure and in that said security gateway element further comprises means (1006) for rejecting packet data connections in con-flict with second screening information.

21. A security gateway element according to claim 20, characterized in that it further comprises

- means (1007) for indicating to a management system all or some of the packet data connec-tions conflicting the second screening informa-tion, and

- means (1008) for receiving a confirmation from the management system whether to reject all or some of the packet data connections conflicting the second screening information.

22. A security gateway element according to claim 21, characterized in that said means (1006) for

reject-ing packet data connections are arranged to delete all packet data connections conflicting the second screening information, if a confirmation is not re-ceived within a predefined period of time.

23. A management system (1050) relating to at least one

security gateway element, said management system comprising

- means (1051) for defining screening informa-tion, and

- means (1052) for delivering screening informa-tion to said at least one security gateway ele-ment,

characterized in that said management

sys-tem further comprises

- means (1053) for receiving from said at least one security gateway element information indi-cating all or some of packet data connections that said at least one security gateway element, after updating screening information in said at least one security gateway element, has classi-fied to be in conflict with the delivered screening information,

- means (1054) for representing said information indicating all or some packet data connections to a user, said means arranged to produce a confirmation as a response to user actions, and - means (1055) for sending said confirmation to said at least one security gateway element.

24. A computer program comprising program code for

performing all the steps of Claim 1 when said pro-gram is run on a computer.

25. A computer program product comprising program

code means stored on a computer readable medium for performing the method of Claim 1 when said pro-gram product is run on a computer.

26. A connection data structure (50) comprising a

number of entries (51) representing a number of packet data connections, said entries comprising header information (32) of data packets,

character-ized in that at least one of said entries further

in-volves acceptance information (55) relating to grounds for accepting the represented packet data

(12)

5 10 15 20 25 30 35 40 45 50 55

connection to traverse a security gateway element when, after screening information is updated in said security gateway element, packet data connections are classified to packet data connections in accord-ance with the updated screening information and packet data connections in conflict with the updated screening information.

27. A connection data structure according to claim 26, characterized in that each entry of said connection

data structure comprises entry-specific acceptance information.

28. A connection data structure according to claim 26, characterized in that said acceptance information

is a rule identifier (55a) of that rule with which a pack-et data connection is in accordance.

is information (55b) identifying an authenticated en-tity.

is information (55c) identifying a relating packet data connection.

31. A connection data structure according to claim 26, characterized in that a specific form of said

con-nection data structure indicates said relating packet data connection.

is information (55d) identifying a secured tunnel, within which the packet data connections is tunneled.

33. A connection data structure according to claim 26, characterized in that at least one of said entries

further comprises information (56) indicating the cur-rent screening information at the time of creation of said entry.

34. A connection data structure according to claim 33, characterized in that said information indicating the

current screening information at the time of creation of said entry is a time stamp.

35. A connection data structure according to claim 33, characterized in that said information indicating the

current screening information at the time of creation of said entry is a version identifier.

Patentansprüche

1. Verfahren (400, 600, 610, 700, 710, 800, 900) zur

Handhabung von Information über Datenpaketver-bindungen, die an einem Sicherheitsgateway-Ele-ment ankommen, um in einer Verbindungsdaten-struktur Information über aktueller Filterungsinfor-mation entsprechende Datenpaketverbindungen zu haben, wobei die besagte Verbindungsdatenstruk-tur eine Anzahl von Einträgen aufweist, die eine An-zahl von Datenpaketverbindungen repräsentiert, wobei das besagte Verfahren die Schritte aufweist: - Speicherung (401) von Datenpaket-Headerin-formation über erster FilterungsinDatenpaket-Headerin-formation ent-sprechende Datenpaketverbindungen in der be-sagten Verbindungsdatenstruktur und

- Empfangen (402) von aktualisierter Filterungs-information, wobei die besagte aktualisierte Fil-terungsinformation entweder allein oder in Ver-bindung mit der besagten ersten Filterungsin-formation zweite FilterungsinFilterungsin-formation ausbil-det,

dadurch gekennzeichnet, dass das besagte

Verfahren weiterhin den Schritt aufweist, bei dem

- nach dem Empfangen der besagten aktuali-sierten Filterungsinformation Einträge der sagten Verbindungsdatenstruktur mit der be-sagten zweiten Filterungsinformation vergli-chen werden (403), was zu einer Klassifizierung der besagten Einträge als erste Einträge, wobei die besagten ersten Einträge der besagten zweiten Filterungsinformation entsprechende Datenpaketverbindungen repräsentieren, und als zweite Einträge führt, wobei die besagten zweiten Einträge in Konflikt mit der besagten zweiten Filterungsinformation stehende Daten-paketverbindungen repräsentieren.

2. Verfahren nach Anspruch 1, dadurch gekenn-zeichnet, dass es weiterhin den Schritt aufweist,

bei dem

- für eine Datenpaketverbindung Akzeptanzin-formation, die sich auf Gründe für Akzeptieren dieser Datenpaketverbindung bezieht, gespei-chert wird (601),

und dass die besagte Akzeptanzinformation dafür verwendet wird (602), Einträge der besagten Ver-bindungsdatenstruktur mit der besagten zweiten Fil-terungsinformation zu vergleichen.

3. Verfahren nach Anspruch 2, dadurch gekenn-zeichnet, dass die besagte Akzeptanzinformation

in demselben Verbindungsdatenstruktureintrag (50) wie Datenpaket-Headerinformation über eine Da-tenpaketverbindung gespeichert wird.

(13)

gekenn-5 10 15 20 25 30 35 40 45 50 55

zeichnet, dass die besagte Filterungsinformation

eine Anzahl von Regeln aufweist und die besagte Akzeptanzinformation eine Regelkennung (55a) derjenigen Regel ist, der eine Datenpaketverbin-dung entspricht.

eine authentifizierte Einheit identifizierende Informa-tion (55b) ist.

eine zugehörige Datenpaketverbindung identifizie-rende Information (55c) ist.

7. Verfahren nach Anspruch 6, dadurch gekenn-zeichnet, dass eine spezifische Form der besagten

Datenpaketverbindungsdatenstruktur die besagte zugehörige Datenpaketverbindung anzeigt.

Information (55d) ist, die einen gesicherten Tunnel identifiziert, innerhalb dessen die Datenpaketverbin-dung getunnelt wird.

9. Verfahren (610) nach Anspruch 1, dadurch ge-kennzeichnet, dass es, wenn Einträge der

besag-ten Verbindungsdabesag-tenstruktur mit der besagbesag-ten zweiten Filterungsinformation verglichen werden (403, 611), überprüft wird, ob in den besagten Ein-trägen gespeicherte Datenpaket-Headerinformation der zweiten Filterungsinformation entspricht.

10. Verfahren (700) nach Anspruch 1, dadurch ge-kennzeichnet, dass es weiterhin den Schritt

auf-weist, bei dem

- zumindest einer der besagten zweiten Einträge in der besagten Verbindungsdatenstruktur ge-löscht wird (703).

auf-weist, bei dem

- zumindest einer der besagten ersten Einträge in der besagten Verbindungsdatenstruktur mo-difiziert wird (704).

auf-weist, bei dem

- der Inhalt der besagten Verbindungsdaten-struktur zu einem bestimmten Zeitpunkt gespei-chert wird (701), um den gespeigespei-cherten Inhalt

beim Vergleichen von Einträgen der besagten Verbindungsdatenstruktur zu verwenden.

auf-weist, bei dem

- Information (56), die eine aktuelle Filterungs-informationsversion zum Zeitpunkt der Hinzufü-gung eines Verbindungsdatenstruktureintrags identifiziert, in einem Verbindungsdatenstruk-tureintrag (50) gespeichert wird (711),

und dass, wenn Einträge der besagten Verbindungs-datenstruktur mit der zweiten Filterungsinformation verglichen werden (403, 712), nur die Einträge, die erste Filterungsinformation als aktuelle Filterungsin-formation definieren, verglichen werden.

14. Verfahren (400) nach Anspruch 1, dadurch ge-kennzeichnet, dass es weiterhin die Schritte

auf-weist, bei denen

- alle oder einige Datenpaketverbindungen, die in Konflikt mit der zweiten Filterungsinformation stehen und von den besagten zweiten Einträgen repräsentiert werden, einem Verwaltungssy-stem angezeigt werden (404) und

- eine Bestätigung vom Verwaltungssystem da-für angefordert wird (405), ob mit der besagten zweiten Filterungsinformation in Konflikt ste-hende Datenpaketverbindungen abgelehnt werden.

15. Verfahren (400) nach Anspruch 14, dadurch ge-kennzeichnet, dass die besagten mit der besagten

zweiten Filterungsinformation in Konflikt stehenden Datenpaketverbindungen nach einer vorbestimmten Zeitperiode in Abwesenheit von der Bestätigung ab-gelehnt werden (408), indem zugehörige Einträge der besagten Verbindungsdatenstruktur gelöscht werden.

16. Verfahren (800) nach Anspruch 1, dadurch ge-kennzeichnet, dass es weiterhin die Schritte

auf-weist:

- Empfangen (801) von Information, die anzeigt, dass die zweite Filterungsinformation nur zu Testzwecken vorgesehen ist, und

- Übertragen (802) von Information über Ergeb-nisse des besagten Vergleichs.

auf-weist, bei dem

(14)

Si-5 10 15 20 25 30 35 40 45 50 55

cherheitsmaßnahme gespeichert wird (811), was wieder die Verwendung der besagten er-sten Filterungsinformation als aktuelle Filte-rungsinformation ermöglicht.

auf-weist, bei dem

- die besagte Verbindungsdatenstruktur auf-grund des besagten Vergleichs modifiziert wird (703, 704).

19. Sicherheitsgateway-Element (1000) mit

- Mitteln (1001) zum Verarbeiten von Datenpa-keten, so dass aktueller Filterungsinformation entsprechende Datenpaketverbindungen vor-gehen können,

- Mitteln (1002) zum Speichern von als aktuelle Filterungsinformation verwendeter erster Filte-rungsinformation,

- Mitteln (1003) zum Speichern von Information über der ersten Filterungsinformation entspre-chende Datenpaketverbindungen in einer Ver-bindungsdatenstruktur und

- Mitteln (1004) zum Empfangen von aktualisier-ter Filaktualisier-terungsinformation, die allein oder zusam-men mit der ersten Filterungsinformation zweite Filterungsinformation ausbildet, dadurch

ge-kennzeichnet, dass es weiterhin aufweist:

- Mittel (1005) zum Vergleichen von Einträgen in der besagten Verbindungsdatenstruktur mit zweiter Filterungsinformation, was zu einer Klassifizierung der besagten Einträge als erste Einträge, wobei die besagten ersten Einträge der besagten zweiten Filterungsinformation ent-sprechende Datenpaketverbindungen reprä-sentieren, und als zweite Einträge führt, wobei die besagten zweiten Einträge in Konflikt mit der besagten zweiten Filterungsinformation stehen-de Datenpaketverbindungen repräsentieren.

20. Sicherheitsgateway-Element nach Anspruch 19, da-durch gekennzeichnet, dass die besagten Mittel

zum Verarbeiten von Datenpaketen angeordnet sind, Datenpakete mit der besagten Verbindungs-datenstruktur zu vergleichen, und dass das besagte Sicherheitsgateway-Element weiterhin Mittel (1006) zum Ablehnen von in Konflikt mit der zweiten Filte-rungsinformation stehenden Datenpaketverbindun-gen aufweist.

21. Sicherheitsgateway-Element nach Anspruch 20, da-durch gekennzeichnet, dass es weiterhin

auf-weist:

- Mittel (1007) zum Anzeigen aller oder einiger

Datenpaketverbindungen, die in Konflikt mit der zweiten Filterungsinformation stehen, einem Verwaltungssystem und

- Mittel (1008) zum Empfangen einer Bestäti-gung vom Verwaltungssystem, ob alle oder ei-nige Datenpaketverbindungen, die in Konflikt mit der zweiten Filterungsinformation stehen, abgelehnt werden.

22. Sicherheitsgateway-Element nach Anspruch 21, da-durch gekennzeichnet, dass die besagten Mittel

(1006) zum Ablehnen von Datenpaketverbindungen angeordnet sind, alle in Konflikt mit der zweiten Fil-terungsinformation stehenden Datenpaketverbin-dungen zu löschen, falls eine Bestätigung innerhalb einer vorbestimmten Zeitperiode nicht empfangen wird.

23. Verwaltungssystem (1050) für zumindest ein

Sicher-heitsgateway-Element, welches Verwaltungssy-stem aufweist:

- Mittel (1051) zum Definieren von Filterungsin-formation und

- Mittel (1052) zum Liefern von Filterungsinfor-mation an das besagte zumindest eine Sicher-heitsgateway-Element,

dadurch gekennzeichnet, dass das besagte

Ver-waltungssystem weiterhin aufweist:

- Mittel (1053) zum Empfangen von Information vom besagten zumindest einen Sicherheitsga-teway-Element, die alle oder einige Datenpaket-verbindungen anzeigt, die das besagte zumin-dest eine Sicherheitsgateway-Element, nach-dem Filterungsinformation im besagten zumin-dest einen Sichterheitsgateway-Element aktua-lisiert geworden ist, klassifiziert hat, in Konflikt mit der gelieferten Filterungsinformation zu ste-hen,

- Mittel (1054) zum Repräsentieren der besag-ten alle oder einige Dabesag-tenpaketverbindungen ei-nem Benutzer anzeigenden Information, wobei die besagten Mittel angeordnet sind, eine Be-stätigung als Antwort auf Benutzeraktionen zu erzeugen, und

- Mittel (1055) zum Senden der besagten Be-stätigung an das besagte zumindest eine Sichterheitsgateway-Element.

24. Computerprogramm mit Programmcode zur

Ausfüh-rung aller Schritte des Anspruchs 1, wenn das be-sagte Programm auf einem Computer abläuft.

25. Computerprogrammprodukt mit auf einem

compu-terlesbaren Medium gespeicherten Programmcode-mitteln zur Ausführung des Verfahrens nach

(51) Int Cl.: H04L 29/06 ( ) H04L 12/24 ( )

1 2

31 754

B1

&   

EP 1 231 754 B1

EUROPEAN PATENT SPECIFICATION

&