WO2018141392A1

WO2018141392A1 - Firewall support for multipath connections

Info

Publication number: WO2018141392A1
Application number: PCT/EP2017/052277
Authority: WO
Inventors: Andreas Ripke; Fabian SCHNEIDER
Original assignee: NEC Laboratories Europe GmbH
Priority date: 2017-02-02
Filing date: 2017-02-02
Publication date: 2018-08-09

Abstract

A method of managing multipath connections at a firewall device, wherein one of the hosts (3) of the multipath connections is inside a firewall domain (2a) of the firewall device (2) and the other of the hosts (4) is outside the firewall domain (2a) of the firewall device (2), and wherein the method comprises receiving, by the firewall device (2), messages exchanged between the two hosts (3; 4) during an initial handshake procedure executed for establishing a first subflow of a multipath connection, obtaining, from said messages, connection information including keys used by the hosts (3; 4) for the multipath connection, and on the basis of said keys, identifying any subsequent subflows of already established multipath connections and applying to an identified subsequent subflow the same action as for the initial subflow.

Description

FIREWALL SUPPORT FOR MULTIPATH CONNECTIONS

The present invention relates to a method of managing multipath connections at a firewall device, wherein one of the hosts of the multipath connections is outside a firewall domain of the firewall device and the other of the hosts is inside the firewall domain of the firewall device.

Furthermore, the present invention relates to an apparatus for managing multipath connections.

Recently, multipath protocols have risen as an evolution of traditional single-path protocols such as TCP (Transmission Control Protocol), promising a higher reliability, as well as better resource usage and congestion avoidance. Multipath TCP (MPTCP), which has been standardized by the IETF (for reference, see Ford et a I./ "RFC 6824: TCP Extensions for Multipath Operation with Multiple Ac/dresses", tools.ietf.org/html/rfc6824), is built on multiple TCP connections and is an extension to TCP (Transmission Control Protocol) to provide the ability to simultaneously use multiple paths between peers using different IP addresses and/or TCP ports. That is, in MPTCP the logical connection between two peers can be multiplexed via multiple TCP connections (which are called subflows in MPTCP terminology).

In case a local admin domain operates a very restrictive firewall policy, a particular firewall may not be able to determine whether or not a particular TCP connection is related to another TCP connection in terms of MPTCP. For example, typically a firewall FW1 is unaware that two subflows subl and sub2 are related to each other. Or similarly, a firewall FW2 is generally unaware of a connection sub3 being related to connections subl and sub2. The main reason for this unawareness is that source and destination IP addresses of the subflows might differ, as well as the TCP source and destination address port numbers.

Hence when using a very restrictive firewall policy where only very few destination port numbers are allowed or only a group of destination addresses, then the use of multipath capable protocols like MPTCP might be affected. One common solution is to have the local system administrator manually update the firewall rule tables to make it fit with foreseeable connection requests. Alternatively, clients could explicitly use firewall control protocols like PCP (Port Control Protocol) or UPNP (Universal Plug and Play) to change the rule tables, if possible, before connection establishment. Using such protocols, however, has the disadvantage of needing to explicitly code such mechanism into the multi-path protocol implementation. Another drawback is that it is not guaranteed that a firewall does actually support any firewall control protocols.

In view of the above it is an objective of the present invention to improve and further develop a method of managing multipath connections at a firewall device and an apparatus for managing multipath connections in such a way that dynamic connection establishment of multi-path protocols is effectively supported, thereby avoiding or at least partially alleviating the above issues.

In accordance with the invention, the aforementioned objective is accomplished by a method of managing multipath connections at a firewall device, wherein one of the hosts of the multipath connections is inside a firewall domain of the firewall device and the other of the hosts is outside the firewall domain of the firewall device, wherein the method comprises, by the firewall device, receiving messages exchanged between the two hosts during an initial handshake procedure executed for establishing a first subflow of a multipath connection, obtaining, from said messages, connection information including keys used by the hosts for the multipath connection, and on the basis of said keys, identifying any subsequent subflows of already established multipath connections and applying to an identified subsequent subflow the same action as for the initial subflow.

Furthermore, the above objective is accomplished by an apparatus for managing multipath connections, comprising a receiver configured to receive messages exchanged between two hosts during an initial handshake procedure executed for establishing a first subflow of a multipath connection, and a controller configured to obtain, from said messages, connection information including keys used by said hosts for the multipath connection, and to identify any subsequent subflows of already established multipath connections on the basis of said keys, and to apply to an identified subsequent subflow the same action as for the initial subflow.

According to the invention it has been recognized efficient support of connection establishment of multipath protocols can be achieved by enabling firewall devices to identify any subsequent subflows of already established multipath connections on the basis of the keys used by the communication hosts for the connection. Therefore, in accordance with the invention, when communication hosts execute an initial handshake procedure for establishing a first subflow of a multipath connection, the firewall devices, when receiving messages of this handshake procedure, obtain the keys contained in these messages, and they use the keys for identifying any subsequent related subflows. According to embodiments, a subflow may be considered RELATED when it is related to another already ESTABLISHED connection. Some good examples of connections that can be considered as RELATED are the FTP-data connections that are considered RELATED to the FTP control port. Consequently, embodiments of the present invention provide a method for firewalls to automatically detect the creation of multipath protocol subflows that are related to existing allowed connections.

It should be noted, however, that for a firewall device it is not obvious whether different connections using different addresses and ports are related to each other, i.e., associating a new, e.g. MPTCP, subflow with an existing MPTCP connection. Every protocol needs a dedicated mechanism to infer if connections are in fact related. According to embodiments, in order to detect related connections the firewall devices may parse the multi-path protocol headers and extract the identifier that also allows the multi-path endpoints to correlate different connections.

The solution according to the present invention has the advantage that there is no need for a communication host who wishes to establish a multipath connection with two or more subflows to explicitly use firewall control protocols like PCP or UPNP. At the same time, it relieves the network administrator of manually adjusting the firewalls configurations, thereby reducing network management overhead. Another advantage lies in the fact that the solution is transparent to the communication endpoints.

According to an embodiment the firewall device may obtain the keys used for a multipath connection only after having decided to allow the multipath connection. In reverse, this means that the firewall device, in case it decides to reject a multipath connection, does not need to obtain and store the keys used for this multipath connection, which relieves the firewall device from operational overhead. In addition, it keeps a database used by the firewall device for storing the keys as small as possible, which not only saves storage capacity, but also accelerates a lookup process for the firewall device to identify subflows as belonging to an already established multipath connection.

Typically, according to most of the existing multipath protocols, the hosts of a multipath connection generate a connection token that is used for identifying any subsequent subflows of the multipath connection. For instance, in MPTCP this connection token is generated during the initial three-way handshake after the keys of the hosts have been exchanged. In any case, each multipath protocol stipulates specific token generation rules that have to be applied by the hosts for connection token generation. According to an embodiment of the present invention the firewall device generates, on the basis of obtained keys of a multipath connection, a verification token by applying the same token generation rules the hosts of the multipath connection apply for generating the above-mentioned connection token. In this context it may be assumed that the firewall device is enabled to recognize the respective multipath protocol and is pre-provisioned with protocol specific token generation rules.

According to an embodiment the firewall device maintains connection records by storing for each multipath connection the keys used for the multipath connection and/or the corresponding verification token, preferably together with the respective hosts' IP addresses and port numbers. For instance, in conventional stateful firewall implementations, firewalls are configured to store quintuples including information on the transport protocol used (e.g. TCP or UDP), the IP addresses of the two hosts of the communication, as well as the hosts' port numbers. According to an embodiment of the invention, such quintuple may be extended to a septuple that additionally includes the keys used by the hosts for the multipath connection, or to an octuple additionally including also the communication token derived from the keys.

According to an embodiment, when the firewall device encounters a new subsequent subflow, the firewall device may first obtain the connection token that identifies this subflow. For instance, in case of MPTCP, the firewall device may extract the connection token from the SYN+MP_JOIN message. Next, the firewall device may search the verification tokens that are currently stored in its connection records for the respective connection token. In case the firewall device finds the connection token in its connection records, i.e. the connection token is identical to a verification token contained in the firewall device's connection records, the firewall device identifies the subflow as being related to the corresponding, already established multipath connection. In this case, the firewall device will allow the subflow, i.e. the firewall device enables the subflow to flow. On the other hand, if the connection token of the subflow can not be found among the verification tokens in the firewall device's connection records, the firewall device will identify the subflow as being unrelated to any established multipath connection and, consequently, the subflow will be rejected by the firewall device.

In real scenarios, subflows of a multipath connection between any two hosts will have to pass different firewall device in many cases. Therefore, embodiments of the invention aim at a collaboration between firewall devices. For instance, a firewall device may identify one or more other firewalls that may also encounter any subsequent subflows of a particular multipath connection. The firewall device may then transmit the keys of this multipath connection and/or the corresponding verification token to the identified one or more other firewalls, which enables these firewalls likewise to qualify a subflow as being related (or as not being related) to the multipath connection.

According to an embodiment, collaboration between firewall devices is even enhanced by synchronizing the firewall device's knowledge of communication keys and/or verification tokens and connection states of the associated multipath connections with all other firewalls belonging to the same administrative domain. That is, a group of firewall devices is orchestrated to efficiently support multipath protocols in a single admin domain. Specifically, collaboration among firewall devices, which allows identifying subflows of a common multipath connection on one or multiple firewall devices based on connection tokens, also makes it possible to apply firewall rules to logical multipath connections instead of each associated discrete subflow - where different rules would have matched and applied to otherwise. Furthermore, it enables an exchange of firewall decisions such as allow, reject, or class of services about multipath connection states across multiple and independent firewall devices in the same admin domain.

According to an embodiment multipath connection establishment may benefit from a collaborative operation of firewall devices as follows: When a firewall device encounters a new subsequent subflow and identifies this subflow, based on its own connection records, as being not related to any already established multipath connection, the firewall device may query other firewalls to provide information about a corresponding multipath connection. For instance, the firewall device may transmit the request as a broadcast message in the firewall device's administrative domain. The broadcast message may include the connection token obtained from messages of the new subsequent subflow exchanged between the respective hosts. A firewall device that receives such broadcast message may search its connection records for the respective connection token in order to find out whether the subflow is related to an already established multipath connection or not. The result of this search can be reported back to the requesting firewall device, which is thus enabled to make an informed decision, i.e. it can allow the subflow in case of a positive feedback, and can reject the subflow in case of a negative feedback.

According to an embodiment, an information server may be implemented in each administrative domain that is configured to manage collaboration among the firewall devices of the respective administrative domain. To this end, firewall devices may be configured to update a database of the information server by transmitting their connection records to the information server. These reports may be sent either on a regular basis or each time a firewall device's connection record changes. Consequently, when a firewall device encounters a new subsequent subflow and identifies this subflow, based on its own connection records, as being not related to any already established multipath connection, the firewall device may send a query directly to the information server of its administrative domain to provide information about a corresponding multipath connection. Upon receiving such query, the information server may provide the requesting firewall device the connection state information of a multipath connection to which the new subsequent subflow relates. Alternatively, the information server may provide the address of another firewall device which keeps the respective connection state information. Based on the connection state information received responsive to a request, a firewall device may then either reject or accept the new subsequent subflow.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end it is to be referred to the dependent patent claims on the one hand and to the following explanation of preferred embodiments of the invention by way of example, illustrated by the drawing on the other hand. In connection with the explanation of the preferred embodiments of the invention by the aid of the drawing, generally preferred embodiments and further developments of the teaching will be explained. In the drawing

Fig. 1 is a schematic view illustrating multipath connection management at a firewall device in accordance with a first embodiment of the present invention,

Fig. 2 is a message sequence diagram illustrating a three-way handshake for primary subflow establishment of a MPTCP connection in accordance with an embodiment of the present invention,

Fig. 3 is a message sequence diagram illustrating a four-way handshake for subsequent subflow establishment of a MPTCP connection in accordance with an embodiment of the present invention, and Fig. 4 is a schematic view illustrating multipath connection management among firewall devices in accordance with an embodiment of the present invention including a synchronization mechanism.

Until recently, communication between hosts was restricted to a single path per connection, yet multiple paths often exist between network devices or peers. The simultaneous use of these multiple paths for a communication session, e.g. TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. To this end, multipath protocols have been developed as enhancements of traditional single- path protocols such as TCP, promising higher reliability, as well as better resource usage and congestion avoidance. Specifically, a multipath TCP technology, called MPTCP, has been standardized by the IETF. Details of this technology, as assumed and understood in the context of the present invention, are specified in various IETF documents, in particular in RFC 6824 "TCP Extensions for Multipath Operation with Multiple Addresses".

In an MPTCP connection, one logical connection consists of multiple connections (generally denoted as subflows) using different paths. Insofar, MPTCP relies on the existence of multiple paths at the end-systems. Typically, multiple paths are provided through different IP addresses obtained by different ISPs.

As will be easily appreciated by those skilled in the art, although the embodiments described hereinafter are specifically based on the MPTCP protocol, the present invention is not restricted to this protocol, but can be applied in connection with any other existing multipath capable solution, as well as with any upcoming future multipath communication protocol having similar characteristics as MPTCP, such as SCTP (Stream Control Transmission Protocol). The described embodiments can be straightforwardly adapted to the respective multipath protocols.

Referring now to Fig. 1 , a schematic of an example of multipath connection management at a firewall device is shown. The illustrated scenario depicts a firewall domain 2a that is controlled by a firewall device 2, denoted FW1. A multipath connection is established between a client 3 located inside the firewall device's 2 domain 2a and a server 4 located outside the firewall device's 2 domain 2a.

Generally, administering firewall rules can become a tedious task when MPTCP connections contain subflows with (usually unpredictable) new addresses. For instance, in the scenario of Fig. 1 a multipath connection established between the client 3 and the server 4 includes an initial subflow - subflow 'subV - and a subsequent subflow - subflow 'sub2'. Here, since subflow 'sub2' uses IP addresses and ports of the client 3 and the server 4 different from those used by subflow 'subV, the firewall device 2 normally will be unable to recognize that subflow 'sub2' is related to subflow 'subV, i.e. that both subflows belong to the same multipath connection.

Embodiments of the present invention overcome the above problem by providing a method that enables firewall devices to automatically detect the creation of multipath protocol subflows that are related to existing allowed connections. Fig. 2 illustrates processing of multipath protocol signaling between two hosts by the firewall device according to such an embodiment. The illustrated message exchange diagram corresponds to the scenario illustrated in Fig. 1 , i.e. client 3 located inside the firewall device's 2 domain 2a establishes a multipath connection with server 4 located outside the firewall device's 2 domain 2a. In Figs. 1 and 2, like reference numerals denote like components.

Fig. 2 is a message exchange diagram in accordance with an embodiment of the present invention using the standardized multipath transport protocol, MPTCP. According to this specific embodiment, the method comprises the following steps:

At 210, the method starts with MPTCP-capable endpoint C, client 3, establishing its first subflow by sending a SYN packet with the MP_CAPABLE option set towards server 4. The TCP option MP_CAPABLE is used to transmit a key used by the client 3 for the MPTCP connection and to signal MPTCP awareness to the server 4. As shown in Fig. 2 and as will be easily appreciated by those skilled in the art, the SYN packet may include further information, e.g. certain flags. However, since this information is irrelevant with respect to the present invention, a detailed explanation thereof is omitted at this point.

Since the client 3 and the server 4 are located on opposite sides of the firewall device 2, the SYN packet has to traverse the firewall device 2. Upon receipt of the SYN packet, the firewall device 2, in accordance with conventional stateful packet processing, analyzes the SYN packet, and it stores in relation to the MPTCP connection a quintuple, including information on the transport protocol used, the IP addresses both of the originator and the intended recipient of the message (i.e. of client 3 and of server 4), and the respective port numbers both on the client 3 and on the server 4. However, in accordance with an embodiment of the invention the firewall device 2 additionally obtains and stores the key used by the client 3 for the MPTCP connection. Specifically, the firewall device 2 keeps connection records where the above listed information is stored for each allowed MPTCP connection.

At 220, the initial MPTCP handshake procedure proceeds by the server 4 sending back to the client 3 an acknowledgment in form of a SYN packet with the ACK option and the MP_CAPABLE option set. Again, when this message traverses the firewall device 2, the firewall device 2 obtains the key from the message (this time the server's 4 key) and stores it in relation to the MPTCP connection (together with the above listed information).

In addition to the above listed information, the firewall device 2 calculates and stores a verification token for the MPTCP connection. This verification token is generated by applying to the keys of the connection the same predefined, protocol-specific token generation rule that is also applied by the communication hosts 3, 4 for generating a connection token that is used by the communication hosts 3, 4 as an identifier for the connection.

At 230, the initial handshake procedure for establishing a first subflow of an MPTCP connection terminates, as usual, by the client 3 sending an acknowledgment 'ACK + MP_CAPABLE' to the server 4. Turning now to Fig. 3, this figure illustrates, in accordance with an embodiment, a message exchange between the client 3 and the server 4 for establishing a second subflow or, more generally, any subflow subsequent to the first subflow.

At 310, the client 3 starts with sending a SYN + MP_JOIN packet towards the server 4. This packet includes a connection token that is used by the communication hosts 3, 4 for identifying the connection. The connection token has been generated by the client 3 from the server's 4 key, as received during the initial handshake procedure (cf. step 220 of Fig. 2), by applying a predefined, protocol specific, token generation rule.

Upon receipt of this message, the firewall device 2 first extracts the connection token from the message. Then, the firewall device 2 searches the verification tokens in its connection records for this specific connection token. If the connection token is contained among the verification tokens of the firewall device's 2 connection records of already established connections, the firewall device 2 will identify the subflow as being related to the initial subflow of the respective MPTCP connection. Since in connection with Fig. 1 it has been assumed that the firewall device 2 allowed this MPTCP connection, the firewall device may also allow the subsequent subflow to which Fig. 2 refers, and it may enable this subflow to flow.

On the other hand, if the connection token is not contained among the verification tokens of the firewall device's 2 connection records, the firewall device 2 will identify the subflow as being unrelated to any of the already established MPTCP connections. Consequently, the firewall device 2 will reject the corresponding subflow.

In case the subflow is allowed, the SYN + MP_JOIN packet is passed on to the server 4 and the subflow establishment procedure proceeds with the standardized message exchange, as shown at 320, 330, and 340.

For MPTCP according to RFC6824, the exchange of keys in the initial MP_CAPABLE handshake (as described above in connection with Fig. 2) provides material that is used to authenticate the endpoints when new subflows will be set up. All future subflows will identify the connection using a 32-bit connection token which is produced by applying a specific token generation rule, which in case of MPTCP is to generate a cryptographic hash of the keys. Generally, the algorithm for this process is dependent on the authentication procedure selected, and the specific rules may be exchanged during the initial handshake. The connection token, generated from the key, is used to identify which MPTCP connection it is joining. According to an embodiment, the so-called Hash-based Message Authentication Code (HMAC) may be used for authentication, as shown at 320 in Fig. 3. The HMAC uses the keys exchanged in the MP_CAPABLE handshake, and the random numbers (nonces) exchanged in the MP_JOIN options, as shown at 310 in Fig. 3.

Since the connection tokens serve as connection identifiers of MPTCP connections, they can also be used for an inter-firewall device protocol to mark and distinguish any exchanged connection state information, as will be described hereinafter in detail in connection with Fig. 4.

Fig. 4 depicts a scenario with an administration domain 1 controlled by two firewall devices 2, denoted FW1 and FW2. Here, the scenario is shown from the client's 3 viewpoint where the firewall devices 2 control the outgoing connection establishment. However, the converse scenario would be even more problematic, as there is less control which incoming firewall device 2 (i.e. FW1 or FW2 in the illustrated scenario) is used by the different subflows. If client 3 and server 4 swap positions in Fig. 4, then the multipath connection establishment from the viewpoint of the server's 3 administration domain 1 - being controlled by two firewalls 2 - would be realized in an analogous manner.

According to the scenario of Fig. 4, a first subflow 'subV of a MPTCP connection has been established between the client 3 and the server 4, in accordance with the methods described in connection with Figs. 2 and 3. Consequently, as already described above, during this connection establishment firewall device FW1 has collected the keys used by the endpoints for the MPTCP connection from signaling messages of the initial handshake procedure, and it has stored these keys in its connection records. Hence, firewall device FW1 is able to identify any subsequent subflows that want to join the existing MPTCP connection on the basis of tokens generated from the keys, as already described above. For instance, in the scenario Fig. 4, firewall device FW1 would be able to identify subflow 'sub2' as being related to the initial subflow 'subV of the respective MPTCP connection. Consequently, firewall device FW1 can enable the same connection state for subflow 'sub2' it has already applied for subflow 'subV, i.e. allowing subflow 'sub2' and enabling it to flow.

After subflow 'sub2' has been established, the client 3 tries to establish another subflow with the server 4, denoted 'sub3' in Fig. 4. However, unlike subflows 'subV and 'sub2', subflow 'sub3' is not routed via firewall device FW1 , but (for non- relevant reasons) via firewall device FW2. In this regard it is important to note that independently operating firewall devices 2 for different routes in the same administration domain 1 are normally not aware of each other's rules or state tables. Consequently, with multipath capable protocols like MPTCP taking disjunctive routes and passing through different firewalls 2 detecting related state gets more difficult.

In view of the above, embodiments of the present invention support firewall devices 2 to exchange information, so that subflows on disjoint paths can also be automatically detected. Specifically, firewall devices 2 may record the multipath connection attempts and provide this information for subsequent and related connection attempts on the same firewall device FW1 (like in case of 'sub2') or on another firewall device FW2 (like in case of 'sub3') of the same administration domain 1.

In the embodiment of Fig. 4, firewall device FW1 transmits either the keys of the MPTCP connection or the respective verification token derived from these keys by applying the appropriate token generation rules (or both, i.e. keys and verification token) to firewall device FW2. In addition, firewall device FW1 may also transmit the respective connection state information for the MPTCP connection to firewall device FW2. Generally, i.e. in real deployment scenarios, firewall device FW1 may transmit the respective information not only to a single firewall device, but to all firewall devices which might encounter subsequent new subflows of a particular MPTCP connection. In Fig. 4, this synchronization process is indicated as 'token sync' among the firewall devices 2. In this context it is explicitly noted that, unlike other known firewall state table synchronization schemes (like OpenBSD/pf/pfsync or Linux/Netfilter/conntrackd) that aim at failover situations with redundant replica firewall devices, according to the embodiment of Fig. 4 only a selected subset of state information is synchronized among a selected group of otherwise independently operating firewall devices 2.

For performing synchronization, the firewall devices 2 may be equipped with dedicated synchronization interfaces. According to an embodiment the synchronization process may be implemented by a push mechanism that proactively spreads keys, tokens, and/or state information to other firewall devices. For instance, each time a firewall device allows an initial subflow of a new MPTCP connection it may transmit a corresponding push message to other firewall devices of the same administration domain. Alternatively, each firewall device may transmit push messages on a regular basis.

By making use of the above synchronization process, when encountering a new subsequent subflow (which uses the TCP option MP_JOIN) on any firewall device 2, this subflow can be identified as RELATED to an already established MPTCP connection on any other firewall device 2 in the administration domain 1. Hence, a state RELATED is expanded to be valid across multiple firewall devices 2.

According to an alternative embodiment, on encountering an unknown new subsequent subflow a firewall device 2 could ask other firewall devices 2 if they know the corresponding MPTCP connection. This way, information is only requested when needed at the price of some delay. In contrast to the push mechanism described above, this implementation employs a pull mechanism where state information (including the respective keys and/or tokens) is spread to other firewall devices 2 reactively. For instance, according to an embodiment a pull request may be realized with a broadcast message in the admin domain 1 or by contacting a known dedicated information server 5 which provides either the state information or provides the firewall address which keeps the state information, as indicated by the dotted-line arrows in Fig. 4. Both the push mechanism and the pull mechanism provide an updating mechanism to orchestrate the behavior of a set of independent firewall devices 2 to seamlessly support multipath protocols trying to exploit as many different and disjunctive paths as possible.

A decision of whether to use a pull mechanism or a push mechanism to spread the state information among firewall devices 2 may be taken depending on the topology knowledge of the firewall devices 2: If the topology is known by a firewall device 2, then the state information can be pushed proactively to the respective other firewall devices 2, which ensures lower latencies for subsequent related connection setups. Otherwise, if the topology is not known by a firewall device 2, then the state information must be pulled reactively from other firewall devices 2.

For synchronizing the tokens across different firewall devices 2, it proves to be advantageous to employ existing firewall state synchronization protocols such as OpenBSD's pfsync (as described, e.g., in http://man.openbsd.org/OpenBSD- current/man4/pfsync.4) or Linux's conntrackd (as described, e.g., in http://conntrack-tools.netfilter.org/manual.html). Generally, it is important that the semantics of a state information exchange protocol between firewall devices 2 or a firewall device 2 and an information server 5 contain sufficient details to identify the requested connection and the according action or verdict.

According to an embodiment a push message transmitted by a firewall device 2 is designed to contain the connection keys in case the connection is accepted by the firewall device 2. Connection attempts dropped by the firewall device 2 do not require any push requests to be sent to other firewall devices 2. Firewall devices 2 that receive the push message can use the connection keys to calculate the connection identifier (token) of the multipath connection, as described above. A push message is the implicit verdict to let the connection pass and contains the implicit state 'established'. Additional information like class of service could be added the push message. A pull request, independent of whether transnnitted via broadcast or by explicitly addressing a particular firewall device 2 or a dedicated information server 5, may be designed to contain the token to identify the connection and the return message should contain the action to be applied on this connection like drop or pass. For the latter the state is 'established'.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for managing multipath connections at a firewall device (2), wherein one of the hosts (3) of the multipath connections is inside a firewall domain (2a) of the firewall device (2) and the other of the hosts (4) is outside the firewall domain (2a) of the firewall device (2), the method comprising, by the firewall device (2): receiving messages exchanged between the two hosts (3; 4) during an initial handshake procedure executed for establishing a first subflow of a multipath connection,

obtaining, from said messages, connection information including keys used by the hosts (3; 4) for the multipath connection, and

on the basis of said keys, identifying any subsequent subflows of already established multipath connections and applying to an identified subsequent subflow the same action as for the initial subflow.

2. Method according to claim 1 , wherein the firewall device (2) obtains the keys used for a multipath connection only after having decided to allow said multipath connection.

3. Method according to claim 1 or 2, further comprising, by the firewall device (2):

on the basis of obtained keys of a multipath connection, generating a verification token by applying the same token generation rules the hosts (1 ; 2) of said multipath connection apply for generating a connection token that is used by the hosts (3; 4) for identifying any subsequent subflow of said multipath connection.

4. Method according to claim 3, wherein the firewall device (2) maintains connection records by storing for each multipath connection the keys used for said multipath connection and/or the corresponding verification token, preferably together with the respective hosts' (3; 4) IP addresses and port numbers.

5. Method according to claim 3 or 4, wherein the firewall device (2), upon encountering a new subsequent subflow, performs the steps of: obtaining the connection token that identifies said subflow, searching the verification tokens in its connection records for the respective connection token, and

identifying said subflow as being either related or not related to an already established multipath connection, depending on whether said connection token is found or not found among the verification tokens in its connection records.

6. Method according to any of claims 1 to 5, further comprising, by the firewall device (2):

identifying one or more other firewall devices (2) that may encounter any subsequent subflows of a multipath connection, and

transmitting the keys of the multipath connection and/or the corresponding verification token to the identified one or more other firewall devices (2).

7. Method according to any of claims 1 to 6, further comprising synchronizing a firewall device's (2) knowledge of communication keys and/or verification tokens and connection states of the associated multipath connections with all other firewall devices (2) belonging to the same administrative domain (1 ).

8. Method according to any of claims 1 to 7, wherein a firewall device (2), upon encountering a new subsequent subflow that is identified as being not related to any already established multipath connection, queries other firewall devices (2) to provide information about the corresponding multipath connection.

9. Method according to claim 8, wherein said request is realized by transmitting a broadcast message in the firewall device's (2) administrative domain (1 ) that includes the connection token the firewall device (2) has obtained from messages of said new subsequent subflow exchanged between the respective hosts (3; 4).

10. Method according to claim 8 or 9, wherein said request is realized by contacting an information server (5) in the firewall device's (2) administrative domain (1 ) that provides, if available, either the connection state information of a multipath connection to which said new subsequent subflow relates or provides the address of another firewall device (2) which keeps the connection state information.

1 1. Method according to any of claims 8 to 10, wherein the firewall device (2) either rejects or accepts said new subsequent subflow in accordance with connection state information received responsive to said request.

12. Apparatus for managing multipath connections, in particular for executing a method according to any of claims 1 to 1 1 , comprising:

a receiver configured to receive messages exchanged between two hosts (3; 4) during an initial handshake procedure executed for establishing a first subflow of a multipath connection, and

a controller configured:

to obtain, from said messages, connection information including keys used by said hosts (3; 4) for the multipath connection, and

to identify any subsequent subflows of already established multipath connections on the basis of said keys, and to apply to an identified subsequent subflow the same action as for the initial subflow.

13. Apparatus according to claim12, wherein the apparatus is included within a firewall device (2).

14. Computer readable medium including software instructions which, when executed by a processor, adapt the processor to perform a method according to any of claims 1 to 1 1.