HK1063904A - Firewall with index to access rule - Google Patents

Description

Firewall with index to access rules

The present invention relates generally to the field of communications, and more particularly to packet control devices.

In packet-based communication networks, it is necessary to control packet access between an unsecured network, such as a public network, and a secured network, such as an internal network of a business organization, in order to prevent unauthorized access to data held on the secured network. The access control is performed by a so-called firewall. Firewalls provide an interface between secure and unsecure networks and include a filter for inspecting packets routed through the interface under the control of the firewall controller. The check is made by comparing the characteristics of the received packets according to a series of rules. This allows control of IP traffic transmitted to and from the protected network. If a rule is found to match a packet, it is passed along with the bandwidth constraint, otherwise the packet is rejected. The filters of the firewall may be implemented in hardware or software. The main difference from a practical point of view is the bandwidth capacity. The software filter has a lower bandwidth due to processing power limitations.

The filter provides an arbitrary interface for IP packets between the unprotected side, e.g. the internet, and the protected side, e.g. a virtual private network. It is responsible for deciding which packets it will transport across the IP boundary between protected and unprotected networks. The filter does not decide which rules are established: this is the responsibility of the elements within the system that need to be routed through the firewall. The filter makes a decision for each packet by comparing the data in the packet header to the rule. When a packet arrives at the filter, it is processed in one of the following ways depending on the destination IP address, destination port number, protocol, or other factors. It may also be rejected, in which case the packet will be dropped, or it may be accepted as a valid packet, in which case it is transmitted.

Packet filters for use with IP telephony require the establishment of a large number of fast-changing rules as determined by a Call Control Function (CCF) or "gatekeeper". (a defined directory is provided at the end of the description). This is in contrast to typical data firewalls that use relatively few rules that are primarily static and controlled by network management. Thus, IP telephony calls require processing that is different from traditional data traffic because IP telephony packets need to be examined "in real time" because delay and delay variation are critical to quality of service.

We now consider the case of an IP telephone call between two endpoints, an originating endpoint located in an unsecured network and a destination endpoint located in a secured network. In IP telephony over a firewall, packets are directed to the address/port number on the firewall: packets from the insecure endpoint to the insecure side of the firewall and packets from the secure endpoint to the secure side.

In the prior art, these IP address and port number code values on the firewall are determined by the endpoint of the call. Each packet received by the filter is checked in turn according to existing rules until the rule that transmitted the packet is found or until all rules have been tried without finding the rule that transmitted the packet, in which case the packet is discarded. Hashing may be used to represent the possible locations of the rules associated with the packet. According to hashing, an index value points to a location: if the location does not include a rule, then the packet is dropped; if the location includes a rule, the packet is checked according to the rule. Once the packet has been evaluated according to the rule, a check is made if the location includes an indicator to a second rule in a different location, the packet also being checked according to the second rule. This second location may also include another indicator to a third rule according to which the packet is to be checked, and so on: therefore, the rule check is non-deterministic. Although in prior art devices a single access may sometimes prove sufficient, this situation cannot be guaranteed, so the bandwidth of prior art firewalls is limited to allow for the handling of multiple accesses to the rule table of special packets.

Packet inspection typically involves inspecting the protocols being used and the source and destination IP addresses and port numbers. This is essentially the same process used by normal data firewalls, where rules are maintained by network management. A similar process occurs in packet routers, where the rules are primarily used to decide on which exit interface to route a packet. However, all of these prior art processes require a significant amount of processing power/time or require expensive hardware, such as content-addressable memory that performs access to each location simultaneously; and this effectively limits the maximum bandwidth to which packets can be transmitted through the filter.

The present invention provides a communication system comprising a packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value; the packet control means comprising indexing means for generating an index value from a control value associated with a packet, and means for using the index value to access a rule for inspecting the packet from the plurality of rules; wherein the packet inspection always requires one separate access to multiple rules.

The invention also provides a communication system comprising a packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value; the packet control means comprising indexing means for generating an index value from a control value associated with a packet, and means for using the index value to identify a rule from a plurality of rules for inspecting the packet; wherein the control value is set by the packet control means.

The invention also provides a communication system comprising a packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value; the packet control means comprising indexing means for generating an index value from a control value associated with a packet, and means for using the index value to identify a rule from a plurality of rules for inspecting the packet; wherein the communication system further comprises packet value means external to the packet control means, wherein the control value is set by the packet value means in cooperation with the packet control means.

According to a preferred embodiment, the present invention provides a communication system in which the packet control means includes means for determining whether the packet control means should transmit or reject the packet.

The present invention also provides a method of filtering packets in a packet-based communication system including a packet control device; the method comprises the steps of receiving at the control device a packet comprising a control value, and using the control value to access a rule from a plurality of rules for use in inspecting the packet; wherein the packet inspection always requires a separate access to a plurality of rules.

The present invention also provides a method of filtering packets in a packet-based communication system including a packet control device; the method includes the steps of receiving at the control device a packet including a control value, using the control value to identify a rule from a plurality of rules for use in examining the packet, wherein the packet control device assigns the control value to the packet.

The present invention also provides a method of filtering packets in a packet-based communication system comprising packet control means and packet value means; the method comprises the steps of receiving at the control means a packet comprising a control value, using the control value to identify a rule from a plurality of rules for use in examining the packet, wherein the control value is assigned by the packet value means in cooperation with the packet control means.

According to another preferred embodiment of the invention, the method comprises the step of determining whether the packet control device should transmit or reject the packet.

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

FIG. 1 shows a block diagram of the main components of a conventional firewall filter;

fig. 2 through 4 show various methods of calculation of a rule index according to the present invention.

The following embodiments are described with respect to IP version 4, however, the present invention is also applicable to systems using IP version 6.

Referring to fig. 1, to establish an IP telephone call, the originating endpoint will send a registration packet carrying the IP address and port number of the firewall. The filter directs the registration packet to the firewall controller, which forwards the registration packet to the appropriate call control function (called a gatekeeper in h.323) for inspection. The registration packet includes the IP address and port number of the originating endpoint. If the check-in packet passes the checks performed by the CCF, the CCF sends an answer packet through the filter to the originating endpoint. In doing so, the firewall controller typically sets up two rules in the filter for the call (one for each direction). These rules will typically form part of a large table maintained in the firewall that includes rules for handling a large number of simultaneous calls. The IP address and port number on the unsecured side (i.e., originating side) of the filter are transmitted to the originating endpoint. This IP address and port number will then be used by the originating endpoint as the destination address for future packets that are part of the call. Also, the IP address and port number on the protected side of the filter (i.e., on the CCF side) are transmitted to the CCF. The CCF then uses this IP address and port number as the destination address for packets sent to the originating endpoint as part of the call. This procedure is applicable to a range of telephony protocols including h.323, MGCP, SIP and h.248. Conventionally, these firewall addresses and port numbers are assigned by the endpoints.

The firewall includes filters that process IP packets from interfaces with secure (30) and non-secure (20) networks. To perform this process, the filter uses data that has been established by the firewall controller through the control interface (10) with the filter. In particular, the source IP address, port number, destination address and port number, and the IP protocol are set by the firewall controller.

There are 64000 available port numbers, including 16384 user-defined ports and 49152 IANA-assigned ports (hereinafter "known ports").

The first check on one incoming packet is for packets using the ARP protocol because these are handled differently than the rest of the packets. ARP (address resolution protocol) packets are processed locally on the network interface. If the incoming packet is not an ARP, then the following tests are performed.

A check is performed to ensure that the IP version of the packet is the same as the version currently being operated on by the filter. Each filter can only operate one IP version and it must be the same for both directions of the filter. A check is performed on the length and protocol of the IP header. The filter performs a check on the IP header length field to ensure that the length of the packet header is greater than or equal to a predetermined minimum value, e.g., 20 octets. The filter also performs a check to determine if the IP protocol field of the packet header corresponds to a valid entry in an acceptable protocol table.

If these checks are passed, then an index to the rule table is generated and used to determine if a rule exists at that location. If any of the above checks fail, or if the location does not include a rule, then some statistics on the packet are recorded and the packet is discarded.

A check is performed to determine if the packet has a multicast IP address. If so, then a rule index is extracted from a multicast IP address table. The multicast IP address table provides a 20-bit index to be used for routing multicast packets through a filter similar to the device shown in fig. 2 and 3 (see below). The multicast packet will typically be routed to a firewall controller. Some statistics about the packet are recorded and the packet is passed for transmission to its destination.

The flags within the rules determine which data items within the packet header are changed and which statistics items are updated by the filter. The destination IP address within the packet header may be changed to the modified destination address stored in the rule. The destination port number within the packet header may be changed to the modified destination port number stored in the rule. The source address may be changed to the modified source address stored in the rule. The source port number in the protocol header may be changed to the modified source port number stored in the rule.

The above-described changes to the header are required to ensure that the packet is correctly directed from the first endpoint to the filter and then from the filter to the second endpoint, and vice versa on the return trip. Differentiated (differentiated) traffic (or "differentiated") bits from the rule, i.e., groups of bits in the packet header that allow the router to distinguish between different packet classes, e.g., different priorities, may be added to the packet header at appropriate locations. After any data change occurs, the packet header checksum is recalculated.

Fig. 2 to 4 show how the rule index is calculated for different types of incoming packets. In the figure, the lowest order bit (bit 0) is on the right hand side of each field.

According to a preferred embodiment of the invention, the assignment of IP addresses and port numbers to firewall filters is performed by a firewall control function arranged to generate unique locations so as to allow rapid identification of appropriate rules for subsequent packets forming part of the same call. According to another preferred embodiment of the invention the assignment of IP addresses and port numbers to firewall filters is performed by a platform outside the firewall, which is arranged to cooperate with the firewall control function to create unique locations in order to allow fast identification of appropriate rules for subsequent packets forming part of the same call. The present invention advantageously provides for the use of a field from a received packet, rather than the use of a process of checking each rule in turn, the contents of which field are set locally to the firewall (as described above) to directly index the relevant rule (or relevant location in the rule table), as opposed to being set by the endpoint. Thus, if an appropriate rule has been established, the index value will point directly to it. If the index value does not indicate a valid rule, then the packet that is subsequently involved is rejected. The invention provides increased efficiency even in rejecting packets. Thus, according to the invention, a single access to the rule table is always used to decide whether to transmit or reject a packet.

Fig. 2 shows the calculation of the rule index for the non-TCP/UDP protocol. The rule index for protocols other than TCP or UDP is calculated based on values in an "IP protocol index table" represented by an 8-bit protocol ID value and the IP address. The IP protocol index table is provided on the firewall. The value specified in the protocol field is used as an index into the protocol table. The item represented is a table indicating whether the protocol is valid. If the protocol is valid, then the rule index is constructed by taking the lowest 6 bits from the IP address and the lowest 14 bits from the entry represented in the IP protocol index table associated with the protocol.

FIG. 3 shows the calculation of the rule index for "known port". If the protocol is TCP or UDP and the port number is in the hexadecimal 0000-BFFF range, then the port number is used as an index to the "well-known ports" table. The "known port" table includes port numbers (e.g., 79 branch) with special identification as defined by IANA. This table is used to determine if the port is supported on this filter. Assuming that the port is supported, the index of the rule data is based on a value from the table represented by the destination port number and the IP address. The rule index is constructed by taking the lowest 6 bits from the IP address and the lowest 14 bits from the entry in the table of known port numbers represented by the port number. If a port is not supported, then packets sent to that port are dropped.

Fig. 4 shows the calculation of the rule index for a user port. For TCP and UDP protocols in which there are no known ports (i.e., port numbers in the hexadecimal C000-FFFF range), the rule index consists of a partial port number and an IP address. The rule index is constructed by taking the lowest 6 bits from the IP address and the lowest 14 bits of the port number.

The exception to the above is for any IPSEC packet. There are two versions of the IPSEC protocol type, IP protocol 50ESP (encapsulating security payload) and IP protocol 51AH (authentication header). Both versions include a Security Parameter Index (SPI). This field for ESP is in the first set of 32 bits of the security header and this field for AH is in the second set of 32 bits of the security header. The SPI and destination IP address and protocol uniquely identify the packet. Formatting of the rule index for these packets is done by a process similar to that described above for the user port but using the lowest 14 bits of the SPI and the lowest 6 bits of the IP address without the destination port number. Note that after the rule index is expressed, the filter performs checking and replacement functions according to the values in the control field of the rule data. The essential difference for an IPSEC packet is only that there is a value, SPI, rather than the source and destination port numbers, although this value is stored in the same location. This value will still be checked and replaced if necessary, as directed by the rules.

The rule index is used to access the rule and the checks specified by the rule control and validity word (part of the rule that determines the criteria used in checking packets) are performed. If these checks are passed, the packet header address and port, etc., are translated as needed.

If needed, i.e. because the IP address from the IP header is changed, the IP header check sum is recalculated and the UDP/TCP header check sum is adjusted. The valid packet statistics are updated to include the present packet. If any of the checks fail, then some statistics on the packet are recorded and the packet is discarded.

The packet may be dropped for any of the reasons described below.

The IP version within the packet does not match the IP version of the filter, e.g., when the filter runs IPv6, it is IPv4 within the packet, and vice versa.

Wrong destination IP address: each filter has a range of IP addresses for its proxy, including multicast addresses and private IP addresses. Any packet with an IP address that is not within the scope of the filter will be rejected.

The header length of the packet is shorter than the minimum required to check whether the packet is correct.

The protocol is not one accepted by the filter. The filter supports a number of acceptable protocols and if the protocol field of the packet header is not in this list, the packet is rejected.

The rule index calculated from the IP address and port number (or SPI of IPSEC) references a rule that will allow packet forwarding that is not in an open state.

The sender IP address in the packet header does not match the original source IP address field in the rule data.

The protocol field from the packet header does not match the original protocol ID field of the rule data.

The source port number from the packet header does not match the original source port number in the rule data.

The destination port in the packet header does not match the original destination port number from the rule data (for non-IPSEC packets).

The destination SPI in the packet header does not match the original destination SPI from the rule data (for IPSEC packets-see below).

The destination port number is less than hexadecimal "C000" (which is used for "known port"), but no entry exists in this "known port" table.

The destination IP address field of the packet header does not match the original destination IP address field of the rule data.

The rule index calculated from the IP address and port number (or SPI of IPSEC) references an unestablished rule.

The present invention applies to packet filters implemented in either hardware or software. The invention is not limited to IP over ethernet but is applicable to other network types such as packet over SONET/SDH and ATM AAL 5. The invention achieves the best performance when using cheap random access memories.

Definition of

Address Resolution Protocol (ARP) is a protocol used to map IP addresses to physical machine addresses identified in a local network.

An entity in an IP telephony network is gatekeeper. It performs a) RAS of other entities in the network, b) address translation for the caller c) gateway control.

H.225 defines the ITU-T standard for call signaling protocols and packetization of media streams for packet-based multimedia communication systems.

H.323 is used in the ITU-T standard for packet-based multimedia communication systems.

IANA IANA

ITU-T International telecommunication Union-Telecommunications

IETF Internet engineering task force

Internet Protocol (IP) is used as a network layer protocol for IP networks to provide unreliable point-to-point delivery of data packets (datagrams). The currently used standard is version 4(IPv4) defined in IETF RFC 791. It will be replaced in the future by version 6(IPv6) as defined in IETF RFC 2460.

The IP telephone is used for the telephone call,

the voice over the internet is presented to the user,

telephony of multimedia over IP protocol-based networks

Media Gateway Control Protocol (MGCP) one proposed protocol of the ITU-T MEGACO working group for controlling media gateways by gatekeepers. Is defined in the Internet draft file draft-huitema-megaco-mgcp-v0r 1-05.

MEGACO defines the protocols used between elements of a physically decomposed multimedia gateway. The MEGACO framework is described in the IETF Internet draft document draft-IETF-MEGACO-protocol-04.

Registration, admission and status (RAS) the signaling function within the h.323 protocol provides entities within the network with registration, authentication of the subscriber making an IP telephone call, and status information regarding the registration. RAS uses h.225 messages. The RAS signaling channel is opened prior to the establishment of any other channel between h.323 endpoints.

The Transmission Control Protocol (TCP) is a connection-oriented, reliable transport layer protocol designed to operate over the IP protocol. Defined by IETF RFC 793.

User Datagram Protocol (UDP) is a connectionless, unreliable transport layer protocol designed to operate over the IP protocol. Is defined in IETF RFC 768.

Claims (29)

1. A communication system comprising packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value;

said packet control means including indexing means for generating an index value from said control value associated with a packet, and means for using said index value to access a rule from a plurality of rules for inspecting said packet;

wherein said packet inspection always requires one individual access to multiple rules.

2. A communication system comprising packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value; said packet control means including indexing means for generating an index value from said control value associated with a packet, and means for using said index value to identify a rule from a plurality of rules for inspecting said packet; wherein the control value is set by the packet control means.

3. A communication system comprising packet control means for checking packets according to a plurality of rules, wherein each packet is associated with a control value;

said packet control means including indexing means for generating an index value from said control value associated with a packet, and means for using said index value to identify a rule from a plurality of rules for inspecting said packet;

wherein the communication system further comprises packet value means external to the packet control means, wherein the control value is set by the packet value means in cooperation with the packet control means.

4. A communication system as claimed in any preceding claim, wherein the packet control means comprises means for determining whether the packet control means should transmit or reject the packet.

5. A communication system as claimed in any preceding claim, wherein the control value comprises an address and/or a Port Number (PN).

6. A communications system as claimed in claim 5, wherein said indexing means comprises a means for using said PN value as an indicator into a look-up table; wherein said indexing means further comprises a means for generating said index value from a combination of said address and a look-up table represented by said PN.

7. A communication system as claimed in any one of claims 1 to 4, wherein the control value comprises an address and a protocol value.

8. The communication system of claim 7 wherein said indexing means comprises a means for using said protocol value as an indicator into a look-up table; wherein the indexing means further comprises means for generating the index value based on the address and a lookup table value represented by the protocol value.

9. A communication system as claimed in any preceding claim, wherein the indexing means comprises means for detecting multicast packets and identifying individual rules for those packets.

10. A communication system as claimed in any preceding claim, wherein the control value is unique to packets received from a particular source and relating to a particular call at any point in time.

11. A communication system as claimed in any preceding claim, wherein the address is an internet protocol address.

12. A communication system as claimed in any preceding claim, wherein the PN is a User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP) PN.

13. A communication system as claimed in any preceding claim, wherein the packet control means comprises a firewall.

14. A communication system as claimed in any preceding claim, wherein the packets carry telephony services.

15. A method of filtering packets in a packet-based communication system comprising a packet control device; the method comprises the steps of receiving in the control device a packet comprising a control value, and using the control value to access a rule from a plurality of rules for use in inspecting the packet; wherein the packet inspection always requires one single access to multiple rules.

16. A method of filtering packets in a packet-based communication system comprising a packet control device; the method comprises the steps of receiving in the control device a packet comprising a control value, and using the control value to identify a rule from a plurality of rules for use in examining the packet; wherein the packet control means assigns the control value to the packet.

17. A method of filtering packets in a packet-based communication system comprising a packet control means and packet value means; the method comprises the steps of receiving in the control device a packet comprising a control value, and using the control value to identify a rule from a plurality of rules for use in examining the packet; wherein the control value is assigned by the grouping value means in cooperation with the grouping control means.

18. A method as claimed in claims 15 to 17, comprising the step of determining whether the packet control device should transmit or reject the packet.

19. A method as claimed in any one of claims 15 to 18, wherein the control value comprises a PN and/or an address.

20. The method of claim 19, wherein the indexing means uses the PN value as an indicator into a look-up table; wherein the indexing means further generates the index value from a combination of the address and a lookup table value represented by the PN value.

21. A method as claimed in any one of claims 15 to 18, wherein the control value comprises an address and a protocol value.

22. The method of claim 21, wherein the indexing means uses the protocol value as an indicator into a look-up table; wherein the indexing means generates the index value based on the address and a lookup table value represented by the protocol value.

23. A method according to any one of claims 15 to 22, wherein said indexing means comprises means for detecting multicast packets and identifying a single rule for those packets.

24. A method as claimed in any one of claims 15 to 23, wherein the control value is unique to packets received from a particular source and relating to a particular call at any point in time.

25. A method as claimed in any one of claims 15 to 24, wherein the address is an internet protocol address.

26. A method according to any one of claims 15 to 25, wherein the PN is a UDP, TCP or SCTP PN.

27. A method as claimed in any one of claims 15 to 26, wherein said packet control means comprises a firewall.

28. A method as claimed in any one of claims 15 to 27, wherein the packets carry telephony traffic.

29. A method as claimed in any one of claims 15 to 28, including the step of using the address and PN as an index into a rule table for identifying appropriate rules.