CA2434600A1 - Firewall with index to access rule - Google Patents
Firewall with index to access rule Download PDFInfo
- Publication number
- CA2434600A1 CA2434600A1 CA002434600A CA2434600A CA2434600A1 CA 2434600 A1 CA2434600 A1 CA 2434600A1 CA 002434600 A CA002434600 A CA 002434600A CA 2434600 A CA2434600 A CA 2434600A CA 2434600 A1 CA2434600 A1 CA 2434600A1
- Authority
- CA
- Canada
- Prior art keywords
- packet
- value
- index
- address
- control
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
- H04M7/0078—Security; Fraud detection; Fraud prevention
Abstract
A packet control means for checking packets according to a plurality of rules, in which each packet is associated with a control value; the packet control means comprising index means for generating an index value from the control value associated with a packet and means for using the index value to access a rule for checking the packet from the plurality of rules. The control value is set by the packet control means. Advantageously, the packet checking always requires a single access to the plurality of rules, allowing for faster operation.
Description
FIREWALL WITH INDEX TO ACCESS RULE
The present invention relates to the field of communications in general and to packet control means in particular.
In packet based communications networks there is a need to control packet access between insecure, e.g. public networks and secure networks, such as a network internal to a business organisation, in order to prevent unauthorised access to data held on the secure network. Access control is performed by so-called firewalls. A firewall provides the interface between the secure and insecure networks and contains a packet filter for checking, under control of a firewall controller, packets routed across the interface. Checking is done by comparing characteristics of received packets against a series of rules. This allows control of IP traffic passing to and from the protected network. If a rule is found that matches a packet it is allowed to pass, subject to bandwidth constraints, otherwise the packet is rejected. Filters for firewalls may be implemented in hardware or software. The principal difference from the practical point of view is the bandwidth capability. Software filter have a lower bandwidths due to processing power limitations.
The filter provides a discretionary interface for TP 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 1P boundary between the protected and unprotected networks. The filter does not decide which rules are set up:
this is the responsibility of elements within the system that require routes through the SUBSTITUTE SHEET (RULE 26) ri7 ..
04/02 '03 TUE 17:07. FAX 01245707838 . hIARCONI~ IP :f' _ -~-~-~ EPO I~LiNTCH
~.'JOi ~t ~ l . ' _, a . l . ' ' n , ' i'i ~~ , ~~
' . ~ 1. ~ ~~
1~ r ' . ~ 2 ' 1~
. . t~ . << ..
f~rewall. The filter makes the decision for each packet, by comparing data in the packet header ~t~ . , the rules. 'When a acket arrives at the fiIt ~ it is dealt with in one of the following ways ,,.
with P
t a on the destination 1P address, desti nation port~number, pxotocvl or other factors. Tt dependent g r c r be 'ecte in which case the packet .w'iIl be discded,~ or it can be accepted as a. valid can eithe red d, . . ;l . ~4t ' x . , 5 packet; in which case it is transported. ~. Ey ~ ~. . . . . .
.l t ;r, . .
. a . ;; .
US 5,951,651 {Lakshznan ..et al) is concerned with finding the appropriate rule in a packet filter I .~~' .
for each incoming packet. WO 00!02114 (~Ffnet)~ describes i~ Frrewall perfornning a look-up , r~. ' .
operation on the basis of two address values (i.e. the packet~source and destination addresses) to ..
i0 identify a sub--set of rules. Y-T5 Lin, et al "Orde ',re,'d Lookupivsrith Bypass Matching for Scalable . . ~ . t, . .
r~ , per~flows,Classification", Networld+Znteroli 2000, 2000/5!P1 describes briefly an arrangement .r for mapping between packets and sexviees using;a plurality~of databases_relating to protocol and ,5 ;t . . .
ports in which a sequence of look up operations are earried~out. . , , :, . Ii . i~ . . . _ .
I ~ ~y:~ ' ' 15 packet alters far use with IP telephony need to~set up large numbers of rapidly changing rules, ° .
. ' ~, i,~
as determined by a call control function, (CGF~~or "gatekeeper". (A list of definitions is provided ~.
at the end of the descziption). This is in contrast to norr~~al data firewahs, which use, relatively .
l ~; l ' ,fevrr rules v~rhich are mostly static and are ~.ontrolled ~y network management. Fence IP , _ ;l !e hon calls need different handling from cod ventiona~~~ata traffic as there is a need to cheek.
to p Y _ ; ~ .!
20 IP telephony packets in "real time" as delay and~delay varzatian is critical to quality of service. , .
' ~ . ~ fI ., sJt , 'a V~ _ l , l, i:~ :~t r. . ~ ~y ' .. :~ ~~
,. . .i~
n~~f~~t'~ ~FP~~T : ,; , ..
~ . . ~~,. , . , .
CA 02434600 2003-07-10 ~.~ y , Empfangszeit 4.Feb. 18:06 ' '' ' , ~ t_ U4/02 ' 03 TUE 17 : 0? FA$ , OI2457~ 7 g3e r hiARCONI IP =!~ ~-~.~ gP0 ~tNl~g (~] Of ,~i a .s , l .
' ' ~ !f t.
- ,. ~ri , .
., ' . 2A
'~ y ~ .
I ~ ~ . . :}~
We now consider the case.of ~n 1P telephony call bettveemtwo end points, the originating end.
' ~ . ; ~ :~ .
' paint being located in an insecure network and thte destination end point being located in a secure .
t;~ tt network. ~n xP telephony via a firewall, packets; are directed to addresseslport numbers on the ;
The present invention relates to the field of communications in general and to packet control means in particular.
In packet based communications networks there is a need to control packet access between insecure, e.g. public networks and secure networks, such as a network internal to a business organisation, in order to prevent unauthorised access to data held on the secure network. Access control is performed by so-called firewalls. A firewall provides the interface between the secure and insecure networks and contains a packet filter for checking, under control of a firewall controller, packets routed across the interface. Checking is done by comparing characteristics of received packets against a series of rules. This allows control of IP traffic passing to and from the protected network. If a rule is found that matches a packet it is allowed to pass, subject to bandwidth constraints, otherwise the packet is rejected. Filters for firewalls may be implemented in hardware or software. The principal difference from the practical point of view is the bandwidth capability. Software filter have a lower bandwidths due to processing power limitations.
The filter provides a discretionary interface for TP 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 1P boundary between the protected and unprotected networks. The filter does not decide which rules are set up:
this is the responsibility of elements within the system that require routes through the SUBSTITUTE SHEET (RULE 26) ri7 ..
04/02 '03 TUE 17:07. FAX 01245707838 . hIARCONI~ IP :f' _ -~-~-~ EPO I~LiNTCH
~.'JOi ~t ~ l . ' _, a . l . ' ' n , ' i'i ~~ , ~~
' . ~ 1. ~ ~~
1~ r ' . ~ 2 ' 1~
. . t~ . << ..
f~rewall. The filter makes the decision for each packet, by comparing data in the packet header ~t~ . , the rules. 'When a acket arrives at the fiIt ~ it is dealt with in one of the following ways ,,.
with P
t a on the destination 1P address, desti nation port~number, pxotocvl or other factors. Tt dependent g r c r be 'ecte in which case the packet .w'iIl be discded,~ or it can be accepted as a. valid can eithe red d, . . ;l . ~4t ' x . , 5 packet; in which case it is transported. ~. Ey ~ ~. . . . . .
.l t ;r, . .
. a . ;; .
US 5,951,651 {Lakshznan ..et al) is concerned with finding the appropriate rule in a packet filter I .~~' .
for each incoming packet. WO 00!02114 (~Ffnet)~ describes i~ Frrewall perfornning a look-up , r~. ' .
operation on the basis of two address values (i.e. the packet~source and destination addresses) to ..
i0 identify a sub--set of rules. Y-T5 Lin, et al "Orde ',re,'d Lookupivsrith Bypass Matching for Scalable . . ~ . t, . .
r~ , per~flows,Classification", Networld+Znteroli 2000, 2000/5!P1 describes briefly an arrangement .r for mapping between packets and sexviees using;a plurality~of databases_relating to protocol and ,5 ;t . . .
ports in which a sequence of look up operations are earried~out. . , , :, . Ii . i~ . . . _ .
I ~ ~y:~ ' ' 15 packet alters far use with IP telephony need to~set up large numbers of rapidly changing rules, ° .
. ' ~, i,~
as determined by a call control function, (CGF~~or "gatekeeper". (A list of definitions is provided ~.
at the end of the descziption). This is in contrast to norr~~al data firewahs, which use, relatively .
l ~; l ' ,fevrr rules v~rhich are mostly static and are ~.ontrolled ~y network management. Fence IP , _ ;l !e hon calls need different handling from cod ventiona~~~ata traffic as there is a need to cheek.
to p Y _ ; ~ .!
20 IP telephony packets in "real time" as delay and~delay varzatian is critical to quality of service. , .
' ~ . ~ fI ., sJt , 'a V~ _ l , l, i:~ :~t r. . ~ ~y ' .. :~ ~~
,. . .i~
n~~f~~t'~ ~FP~~T : ,; , ..
~ . . ~~,. , . , .
CA 02434600 2003-07-10 ~.~ y , Empfangszeit 4.Feb. 18:06 ' '' ' , ~ t_ U4/02 ' 03 TUE 17 : 0? FA$ , OI2457~ 7 g3e r hiARCONI IP =!~ ~-~.~ gP0 ~tNl~g (~] Of ,~i a .s , l .
' ' ~ !f t.
- ,. ~ri , .
., ' . 2A
'~ y ~ .
I ~ ~ . . :}~
We now consider the case.of ~n 1P telephony call bettveemtwo end points, the originating end.
' ~ . ; ~ :~ .
' paint being located in an insecure network and thte destination end point being located in a secure .
t;~ tt network. ~n xP telephony via a firewall, packets; are directed to addresseslport numbers on the ;
3 ~ . ~.
' S , ~rewall: packets from the insecure endpoint to ; ~ a insecuie side. of the firewall . and those from '.
J. ' _ ~ the secure endpoint to the secure side, l F t: ' ., s , t; : .. . . . .
1 . j: ;
,. ~ r - y, ~~
~ In the prior art, the value of these IP addresses :and part .numbers on the ~rewall ire determined ,~
' ~ ' ~~ ~~~
by the,endpoints of the call, Mach packet recciwed by the~'~itex is checked against the existing J.0 ' roles in.turn until either a xule that passes the pa~ kct is fau -'d or ~ . - , f ~~ ~ ~
l : S! .
. . ~ ( t, ', . t' ' ~. , r.
' ' ' S ;r art l . ~!I
f.;
. . 1' .. ?' ~
:t "
l I~ r~
t.
( .Y
' ' . ~i" _ ' ~
I. 1 , v ' ' ' ~ ,~ ..
.5 r ' , ' , (t ' ~ ' t i(~~
E ('~, ' ~~ ~ l ~ ~ y. ' .
~ 1.1 . ~( .~t .
l ~~~111t~~ia SNi"i=T
,' ..
t Empfangszeit 4.Fe6. 18:06 ~t ~ ' CA 02434600 2003-07-10 ' ~' l . , ' l' case the packet is discarded. Hashing can be used to indicate the likely location of a rule relevant to that packet. With hashing, the index value points to a location: if the location does not contain a rule, then the packet is discarded; if the location contains a rule, the packet it checked against it. Once the packet has been evaluated against the rule, a check is made in case the location contains a pointer to a second rule in a different location, against which the packet is also to be checked. This second location may also contain yet another pointer to a third rule, against which the packet is to be checked, and so on: thus the rule checking is non-deterministic. Although a single access may sometimes prove'~sufficient in the arrangements of the prior art, this is not guaranteed to be the case so that the bandwidth of prior art firewalls is restricted to allow for the handling of multiple access to the rule table for particular packets.
Packet checking typically involves checking the protocol being used and the source and destination IP addresses and port numbers. This is essentially the same process as used I5 by normal data firewalls, where the rules are maintained by network management. A
similar process occurs in packet routers where the rules are primarily for deciding on which exit interface to route the packet. However, all these prior art processes require a lot of processing power/time or require expensive hardware such as content addressable memory that carnes out accesses to every location m parallel; and this effectively limits the maximum bandwidth for passing packets through the filter.
The present invention provides a communications system comprising a packet control means for checking packets according to a plurality of rules, in which each packet is associated with a control value; the packet control means comprising index means for SUBSTITUTE SHEET (RULE 26) y94/02 ' 43 TLtE 17: U? FAX Q12451078~8 , ~fARGONI iP ~' . -~~.~ EPO hiLiNICH
l [~ 00 ~;i s. , l ~ - . . ~' ~f~ .
..
;;
. .. _ ~~ iii . , .
. . , i~ , . .
. 4~ .I
i~ .
The present invention provides. a communicatian~ system comprising a packet control means far l: _;. , ~i ., checking packets according to a plurality of ru~'es, iz~ whi'ch each packet is associated with a 1. .:.
control value; the packet control means eomprisEng.index.~lmeans for generating an index value .
from the control Value associated with a packet!and meansJFor using the index value to access a . ~ ;#.
..
rule far checking the packet from the plurality; ~of rules;' iii which the packet checking alwajrs ~ ~~
' S , ~rewall: packets from the insecure endpoint to ; ~ a insecuie side. of the firewall . and those from '.
J. ' _ ~ the secure endpoint to the secure side, l F t: ' ., s , t; : .. . . . .
1 . j: ;
,. ~ r - y, ~~
~ In the prior art, the value of these IP addresses :and part .numbers on the ~rewall ire determined ,~
' ~ ' ~~ ~~~
by the,endpoints of the call, Mach packet recciwed by the~'~itex is checked against the existing J.0 ' roles in.turn until either a xule that passes the pa~ kct is fau -'d or ~ . - , f ~~ ~ ~
l : S! .
. . ~ ( t, ', . t' ' ~. , r.
' ' ' S ;r art l . ~!I
f.;
. . 1' .. ?' ~
:t "
l I~ r~
t.
( .Y
' ' . ~i" _ ' ~
I. 1 , v ' ' ' ~ ,~ ..
.5 r ' , ' , (t ' ~ ' t i(~~
E ('~, ' ~~ ~ l ~ ~ y. ' .
~ 1.1 . ~( .~t .
l ~~~111t~~ia SNi"i=T
,' ..
t Empfangszeit 4.Fe6. 18:06 ~t ~ ' CA 02434600 2003-07-10 ' ~' l . , ' l' case the packet is discarded. Hashing can be used to indicate the likely location of a rule relevant to that packet. With hashing, the index value points to a location: if the location does not contain a rule, then the packet is discarded; if the location contains a rule, the packet it checked against it. Once the packet has been evaluated against the rule, a check is made in case the location contains a pointer to a second rule in a different location, against which the packet is also to be checked. This second location may also contain yet another pointer to a third rule, against which the packet is to be checked, and so on: thus the rule checking is non-deterministic. Although a single access may sometimes prove'~sufficient in the arrangements of the prior art, this is not guaranteed to be the case so that the bandwidth of prior art firewalls is restricted to allow for the handling of multiple access to the rule table for particular packets.
Packet checking typically involves checking the protocol being used and the source and destination IP addresses and port numbers. This is essentially the same process as used I5 by normal data firewalls, where the rules are maintained by network management. A
similar process occurs in packet routers where the rules are primarily for deciding on which exit interface to route the packet. However, all these prior art processes require a lot of processing power/time or require expensive hardware such as content addressable memory that carnes out accesses to every location m parallel; and this effectively limits the maximum bandwidth for passing packets through the filter.
The present invention provides a communications system comprising a packet control means for checking packets according to a plurality of rules, in which each packet is associated with a control value; the packet control means comprising index means for SUBSTITUTE SHEET (RULE 26) y94/02 ' 43 TLtE 17: U? FAX Q12451078~8 , ~fARGONI iP ~' . -~~.~ EPO hiLiNICH
l [~ 00 ~;i s. , l ~ - . . ~' ~f~ .
..
;;
. .. _ ~~ iii . , .
. . , i~ , . .
. 4~ .I
i~ .
The present invention provides. a communicatian~ system comprising a packet control means far l: _;. , ~i ., checking packets according to a plurality of ru~'es, iz~ whi'ch each packet is associated with a 1. .:.
control value; the packet control means eomprisEng.index.~lmeans for generating an index value .
from the control Value associated with a packet!and meansJFor using the index value to access a . ~ ;#.
..
rule far checking the packet from the plurality; ~of rules;' iii which the packet checking alwajrs ~ ~~
requires a single access to the plurality of rules. ' ~~ ' '_ , .,:
. . . ~' .
l ~ ~ ' ,~, ~ ' :.
- According to a preferred erx~bodi~ient the controls value is set by the packet control tneatts. .
. l.. ~ 3;; ~ . . ~ .
l 4, . . . . , l . . C' . . . .
,. 1~ ~ #' l ~ r t j' .
According to a preferred embodiment, the communications system comprises packet waiue .t . . ._ . 91i .
. means, external to the packet control means, in 'which the control value is set by the packet value .
means in collaboration with the packet ef~ntrol ~ pans. . .~~ . .
. ~ : ~.y .
. , y ; . t,., ., .r; . _ .
;y if ..
. . ~; . :, ~ ..
. . l ~. II ..
,t ~ . >>~! , .
'l t , l l, jq .
l ii . 1;1 . ' , J. It.
' ~ ~. , l ,. , ' ~ .
l. ' ~, J
s tT l .
1 ~ , jfi ~~iVi~ND~D SW~~'C~ , h ;
l. . , r Empfangszeit 4.Feb, 18;06 , i~ x,.
. :. , 04/02 '03 TLiE 17:07 FAg 01,245707836 ~ iuARCONI IP ~ . . aaa EPOWfLFNIC$ f~Ot '1.
),vi . , E .
. ~
' . p: ~ t , _ ' ~f t ' . . . ~~~ - , .
S f v.
. , y .,:
. ~;
According to a preferred embodiment, the invention provides a communications system in which ,z ' the packet control means compzises means fur;determining whether the packet eantroi means ~y: , y:
' ~ shouid pass or reject the packet. ~ -. j .
', r v ~~
.:t .
1, The present invention further pxovides a iri ~ hod of filtering packets in a gasket-based .
. ,~
communications system comprising a packet control means; the method including the steps of . ~ . ..
receiving. a packet comprising a control value ' ~t the control- means and the step of using the ..
control value to access a rule from a plurality of hales for, rise in checking the packet; in which the gasket checking always requires a single access to the plurality of.
rules.
;, . , ._ 10 ~ ' ' , : ~ : a v . . ,1 .~
,;.
According to a preferred embodiment, the packer control rrieans allocates the control value to the packet, ~ ~ , ~ t.; ' .
U ~;
~,i: . . .
- ,~ v~ , According to a preferred embbdiment, the piesent inveiidon provides ~a method of 'filtering . . . .,. .
. 1 , 1S packets in a packet-based communieatior~s syst'e'm comprising a packet value means; the method .
including the steps of receiving a packet corn~pix"sing a control value at the co~itrol rneat~s and the .
step of using the control value to identify a rule far use in checking . ~ n . ' j:
e~
_ r1 .
. 1 ;.. , 1,' . ; . , 1 ~y ~ ~
.,, .
I:IVI~~f~ aHi~ET ' ~ ~ .
~w Er~pfaagsze'it 4.Feb. 18106 1 ;., , ~
to the drawings in which:
Figure 1 shows a block diagram of the main components of a conventional firewall filter;
Figures 2 to 4 show various ways for calculation of the Rule Index according to the present invention.
The following embodiments are described in relation to IP version 4, however the invention also applies to systems using IP version 6.
Referring to Figurel, to set up an IP telephony call, the originating endpoint will send a registration packet bearing 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 (known as a gatekeeper in H.323) for checking. The registration packet contains the IP address and port number of the originating end point. If the registration packet passes the checks performed by the CCF, the CCF sends a reply packet to the originating endpoint via the filter.
In doing so, the firewall controller typically sets up two rules in the filter for that call (one for each direction). These rules will normally form part of a large table held in the firewall containing other rules for dealing with large numbers of concurrent calls. The IP
address and port number on the insecure side of the filter (i.e. the originating side) is communicated to the originating end point. This IP address and port number will then be used by the originating end point as the destination address of future packets as part SUBSTITUTE SHEET (RULE 26) of that call. Similarly, the IP address and port number on the protected side of the filter (i.e. on the CCF side) is communicated to the CCF. The CCF then uses this IP
address and port number as the destination address for packets sent to the originating end point as part of that call. This process is applicable to a range of telephony protocols including H.323, MGCP, SIP and H.248. These firewall addresses and port numbers are conventionally assigned by the end points.
The firewall comprises a filter that processes the IP packets that come from the interfaces with the secure (30) and insecure (20) networks. In order to perform this processing the filter uses data that has been set-up by the firewall controller across the control interface (10) with the filter. In particular, the source IP address, port number, the destination address and port number, and the IP protocol are set by the firewall controller.
There are 64 thousand ports number available including 16384 user defined ports and 49152 ports assigned by IANA (referred to below as "well known ports") The first check on an incoming packet is for packets using the ARP protocol as these are handled differently to the rest. ARP (Address Resolution Protocol) packets are dealt with locally on the network interface. If the incoming packet is not an ARP
then the following tests are carried out.
A check is performed to ensure that the IP version of the packet is the same as that currently operated by the filter. Each filter can only operate one IP version and it must SUBSTITUTE SHEET (RULE 26) g be the same for both filter directions. Checks are performed on the length of the IP
header and the protocol. A check is performed by the filter on the IP header length field to ensure that the length of the packet header is at or above a predefined minimum, e.g.
20 octets. The filter also performs a check to establish if the 1P protocol field of the packet header corresponds to a valid entry in the acceptable protocol table.
If these checks are passed then an index to the rule table is generated and used to establish if there is a rule present at that location. If any of the above checks fail, or if the location does not contain~~a rule, some statistics about the packet are logged and the IO packet is discarded.
A check is performed to establish if the packet has a multicast IP address. If it has 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 to route multicast packets through the filter akin to the arrangements shown in figures 2 & 3 (see below). Multicast packets will normally be routed to the firewall controller. Some statistics are logged about the packet and it is passed for transmission to its destination.
Flags within a rule determine which items of data are changed within the packet header and which items of statistical information are updated by the filter. The destination IP
address within the packet header may be changed to a modified destination address stored in the rule. The destination port number within the packet header may be changed to a modified destination port number stored in the rule. The source address may be changed to a modified source address stored in the rule. The source port number SUBSTITUTE SHEET (RULE 26) within the protocol header may be changed to a modified source port number stored in the rule.
The above changes to the header are required to ensure that packets are directed correctly from a first endpoint to the filter and then from the filter to a second endpoint, and vice versa on the return journey. The differentiated services (or "diffserv") bits from the rule, i.e. the set of bits in the packet header that allow routers to differentiate between different classes of packets e.g., different priorities, may be added to the packet header in the appropriate place. The packet header checksums are recalculated after any data changes have taken place.
Figures 2 to 4 show how the rule index is calculated for different types of incoming packets. In the figures the Ieast significant bit (bit 0) is at the right hand side of each field.
According to a preferred embodiment of the present invention, the allocation of IP
addresses and port numbers to the firewall filter is performed by a firewall control function that is arranged to generate unique locations in such a way as to allow for rapid identification of the appropriate rule for subsequent packets forming part of the same call. According to a further preferred embodiment of the present invention, the allocation of IP addresses and port numbers to the firewall filter is performed by a platform external to the firewall that is arranged to generate unique locations in collaboration with the firewall control function in such a way as to allow for rapid identification of the appropriate rule for subsequent packets forming part of the same SUBSTITUTE SHEET (RULE 26) Ball. Rather than using a process of checking each rule in turn, the invention advantageously provides for using a field from received packets whose content is set locally to the firewall (as described above), as opposed to being set by endpoints to provide an index directly to the relevant rule (or to the relevant location in the table of 5 rules). Hence, if an appropriate rule has been set up the index value will point directly to it. If the index value does not indicate a valid rule, then the packet concerned is rejected. Even in rejecting packets, the invention provides increased efficiency. Hence, according to the present invention, the decision to pass or reject a packet is always achieved with a single access to the rule table.
Figure 2 shows calculation of the rule index for non-TCP/UDP protocols. For protocols other than TCP or UDP the rule index is calculated based on a value in a "1P
Protocol Index Table" indicated by the 8-bit protocol DJ value along with 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 indicated entry is the table indicates whether the protocol is valid or not. If the protocol is valid, then the rule index is formed by taking the least significant 6 bits from the IP address along with the least significant 14 bits taken from the indicated entry in the IP Protocol Index Table that relates to that protocol.
Figure 3 shows calculation of the rule index for "well known ports". If the protocol is TCP or UDP and the port number is in the range 0000 - BFFF hexadecimal the port number is used as an index to the "well known port" table. The "well known port" table contains port numbers with specific identities as defined by IANA (e.g. 79 =
finger).
SUBSTITUTE SHEET (RULE 26) This table is used to establish if the port is supported on this filter.
Assuming that the port is supported, an index to the rule data is based on a value from the table indicated by the destination port number along with the IP address. The rule index is formed by taking the least significant 6 bits from the IP address along with the least significant 14 bits taken from the entry in the Well Known Port number table indicated by that port number. If a port is not supported, then packets sent to it are discarded.
Figure 4 shows calculation of the rule index for User Ports. For TCP and UDP
protocols where it is not a Well Known Port (i.e. the port number is in the range C000-FFFF hexadecimal) the rule index is formed from part of the port number and the IP
address. The rule index is formed by taking the least significant 6 bits from the IP
address along with the least significant 14 bits of the port number.
The exception to the above is for any IPSEC packets. There are two versions of IPSEC
protocol types, IP protocol 50 ESP (Encapsulating Security Payload) and IP
protocol 51 AH (Authentication Header). Both these versions include a Security Parameters Index (SPI). For ESP this field is in the first 32 bits and for AH in the second 32 bits of the Security Header. The SPI, along with the destination IP address and protocol uniquely identify the packet. Formatting the rule index for these packets is achieved by a similar process to that described above for user ports but using the lowest fourteen bits of the SPI and the lowest 6 bits of the IP address rather than the destination port number. Note that after the rule index is formulated the filter carries out check and replace functions according to the values in the control field of the rule data. For the IPSEC
packet the principle difference is that there is just the one value, the SPI, rather than the source and SUBSTITUTE SHEET (RULE 26) destination port numbers, though this value is stored in the same location.
This value will still be checked and replaced if required, as directed by the rule.
The rule index is used to access the rule and the checks stipulated by the rule control and validity word (a part of the rule that determines criteria used in checking the packet) are performed. If these checks are passed, the packet header addresses and ports etc., are translated as required.
The IP header checksums are recalculated and the UDP/TCP header checksums are adjusted, if required, i.e. due to IP addresses from the IP header that are changed. The valid packet statistical information is updated to include the present packet.
If any of the checks fail then some statistics about the packet are logged and the packet is discarded.
Packets may be discarded for any one of the following reasons.
The IP version within the packet does not match that of the filter e.g. IPv4 when the filter is running IPv6 or vice versa ~ Incorrect destination IP address: each filter has a range of IP addresses that it acts for, including multicast addresses and private IP addresses. Any packet with an IP
address that is not in the filter's range will be rejected.
~ The header length of the packet is less than the minimum size needed to verify the packet as correct.
~ The protocol is one not accepted by the filter. The filter supports a number of protocols that are acceptable and if the protocol field of the packet header' is not in SUBSTITUTE SHEET (RULE 26) this list the packet is rejected.
~ The rule index calculated from the IP address and port number (or SPI for 1PSEC ) references a rule that is not in an open state that will allow transfer of packets ~ The sender's 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 ll~
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 'C000' hexadecimal (which therefore is for a "well known port") but no entry in the "well known port" table exists.
~ 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 1P address and port number (or SPI for IPSEC) references a rule that is not set up.
The present invention applies to packet filters whether implemented in hardware or software. The present invention is not limited to 1P over Ethernet, but applies to other network types such as packet over SONETISDH, and ATM AALS. The present invention achieves optimum performance whilst using cheap random access memory.
SUBSTITUTE SHEET (RULE 26) Definitions Address Resolution Protocol (ARP) A protocol for mapping an IP address to a physical machine address that is recognised in the local network.
Gatekeeper An entity in an IP Telephony network. It performs a) RAS of other entities in the network, b) address translation for parties making calls and c) control of Gateways.
H.225 ITU-T standard defining call signalling protocols and media stream packetization for packet-based multimedia communications systems.
H.323 ITU-T standard for packet-based multimedia communications systems.
IANA IANA.
ITU-T International Telecommunications Union -Telecommunications IETF Internet Engineering Task Force.
Internet Protocol (IP) The network layer protocol for IP networks, providing unreliable point-to-point transfer of data packets (datagrams). The currently used standard is version 4 (IPv4) defined in IETF
RFC 791. This will be replaced in the future by version 6 (IPv6) defined in IETF RFC
2460.
SUBSTITUTE SHEET (RULE 26) Definitions 1P Telephony , The technology of telephony over IP
Voice over Internet, protocol based networks.
Multimedia over IP
Media Gateway Control Protocol A proposed protocol of the ITU-T
(MGCP) MEGACO working group, for control of Media Gateways by Gatekeepers. Defined in Internet Draft document draft-huitema megaco-mgcp-vOrl -OS.
MEGACO MEGACO defines the protocols used between elements of a physically decomposed multimedia gateway. The MEGACO framework is described in IETF
Internet Draft document draft-ietf ynegaco-protocol-~4.
Registration, Admission and Status Signalling function within the H.323 (RAS) protocol providing registration for entities in a network, authentication of users making IP
Telephony calls, and status information on registrations. RAS uses H.225 messages.
The RAS signalling channel is opened prior to the establishment of any other channels between H.323 endpoints.
Transmission Control Protocol (TCP) A connection-oriented, reliable transport-layer protocol designed to operate over the IP protocol. Defined by IETF RFC 793.
User Datagram Protocol (UDP) A connectionless, unreliable transport layer protocol designed to operate over the 1P
protocol. Defined in IETF RFC 76~.
SUBSTITUTE SHEET (RULE 26)
. . . ~' .
l ~ ~ ' ,~, ~ ' :.
- According to a preferred erx~bodi~ient the controls value is set by the packet control tneatts. .
. l.. ~ 3;; ~ . . ~ .
l 4, . . . . , l . . C' . . . .
,. 1~ ~ #' l ~ r t j' .
According to a preferred embodiment, the communications system comprises packet waiue .t . . ._ . 91i .
. means, external to the packet control means, in 'which the control value is set by the packet value .
means in collaboration with the packet ef~ntrol ~ pans. . .~~ . .
. ~ : ~.y .
. , y ; . t,., ., .r; . _ .
;y if ..
. . ~; . :, ~ ..
. . l ~. II ..
,t ~ . >>~! , .
'l t , l l, jq .
l ii . 1;1 . ' , J. It.
' ~ ~. , l ,. , ' ~ .
l. ' ~, J
s tT l .
1 ~ , jfi ~~iVi~ND~D SW~~'C~ , h ;
l. . , r Empfangszeit 4.Feb, 18;06 , i~ x,.
. :. , 04/02 '03 TLiE 17:07 FAg 01,245707836 ~ iuARCONI IP ~ . . aaa EPOWfLFNIC$ f~Ot '1.
),vi . , E .
. ~
' . p: ~ t , _ ' ~f t ' . . . ~~~ - , .
S f v.
. , y .,:
. ~;
According to a preferred embodiment, the invention provides a communications system in which ,z ' the packet control means compzises means fur;determining whether the packet eantroi means ~y: , y:
' ~ shouid pass or reject the packet. ~ -. j .
', r v ~~
.:t .
1, The present invention further pxovides a iri ~ hod of filtering packets in a gasket-based .
. ,~
communications system comprising a packet control means; the method including the steps of . ~ . ..
receiving. a packet comprising a control value ' ~t the control- means and the step of using the ..
control value to access a rule from a plurality of hales for, rise in checking the packet; in which the gasket checking always requires a single access to the plurality of.
rules.
;, . , ._ 10 ~ ' ' , : ~ : a v . . ,1 .~
,;.
According to a preferred embodiment, the packer control rrieans allocates the control value to the packet, ~ ~ , ~ t.; ' .
U ~;
~,i: . . .
- ,~ v~ , According to a preferred embbdiment, the piesent inveiidon provides ~a method of 'filtering . . . .,. .
. 1 , 1S packets in a packet-based communieatior~s syst'e'm comprising a packet value means; the method .
including the steps of receiving a packet corn~pix"sing a control value at the co~itrol rneat~s and the .
step of using the control value to identify a rule far use in checking . ~ n . ' j:
e~
_ r1 .
. 1 ;.. , 1,' . ; . , 1 ~y ~ ~
.,, .
I:IVI~~f~ aHi~ET ' ~ ~ .
~w Er~pfaagsze'it 4.Feb. 18106 1 ;., , ~
to the drawings in which:
Figure 1 shows a block diagram of the main components of a conventional firewall filter;
Figures 2 to 4 show various ways for calculation of the Rule Index according to the present invention.
The following embodiments are described in relation to IP version 4, however the invention also applies to systems using IP version 6.
Referring to Figurel, to set up an IP telephony call, the originating endpoint will send a registration packet bearing 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 (known as a gatekeeper in H.323) for checking. The registration packet contains the IP address and port number of the originating end point. If the registration packet passes the checks performed by the CCF, the CCF sends a reply packet to the originating endpoint via the filter.
In doing so, the firewall controller typically sets up two rules in the filter for that call (one for each direction). These rules will normally form part of a large table held in the firewall containing other rules for dealing with large numbers of concurrent calls. The IP
address and port number on the insecure side of the filter (i.e. the originating side) is communicated to the originating end point. This IP address and port number will then be used by the originating end point as the destination address of future packets as part SUBSTITUTE SHEET (RULE 26) of that call. Similarly, the IP address and port number on the protected side of the filter (i.e. on the CCF side) is communicated to the CCF. The CCF then uses this IP
address and port number as the destination address for packets sent to the originating end point as part of that call. This process is applicable to a range of telephony protocols including H.323, MGCP, SIP and H.248. These firewall addresses and port numbers are conventionally assigned by the end points.
The firewall comprises a filter that processes the IP packets that come from the interfaces with the secure (30) and insecure (20) networks. In order to perform this processing the filter uses data that has been set-up by the firewall controller across the control interface (10) with the filter. In particular, the source IP address, port number, the destination address and port number, and the IP protocol are set by the firewall controller.
There are 64 thousand ports number available including 16384 user defined ports and 49152 ports assigned by IANA (referred to below as "well known ports") The first check on an incoming packet is for packets using the ARP protocol as these are handled differently to the rest. ARP (Address Resolution Protocol) packets are dealt with locally on the network interface. If the incoming packet is not an ARP
then the following tests are carried out.
A check is performed to ensure that the IP version of the packet is the same as that currently operated by the filter. Each filter can only operate one IP version and it must SUBSTITUTE SHEET (RULE 26) g be the same for both filter directions. Checks are performed on the length of the IP
header and the protocol. A check is performed by the filter on the IP header length field to ensure that the length of the packet header is at or above a predefined minimum, e.g.
20 octets. The filter also performs a check to establish if the 1P protocol field of the packet header corresponds to a valid entry in the acceptable protocol table.
If these checks are passed then an index to the rule table is generated and used to establish if there is a rule present at that location. If any of the above checks fail, or if the location does not contain~~a rule, some statistics about the packet are logged and the IO packet is discarded.
A check is performed to establish if the packet has a multicast IP address. If it has 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 to route multicast packets through the filter akin to the arrangements shown in figures 2 & 3 (see below). Multicast packets will normally be routed to the firewall controller. Some statistics are logged about the packet and it is passed for transmission to its destination.
Flags within a rule determine which items of data are changed within the packet header and which items of statistical information are updated by the filter. The destination IP
address within the packet header may be changed to a modified destination address stored in the rule. The destination port number within the packet header may be changed to a modified destination port number stored in the rule. The source address may be changed to a modified source address stored in the rule. The source port number SUBSTITUTE SHEET (RULE 26) within the protocol header may be changed to a modified source port number stored in the rule.
The above changes to the header are required to ensure that packets are directed correctly from a first endpoint to the filter and then from the filter to a second endpoint, and vice versa on the return journey. The differentiated services (or "diffserv") bits from the rule, i.e. the set of bits in the packet header that allow routers to differentiate between different classes of packets e.g., different priorities, may be added to the packet header in the appropriate place. The packet header checksums are recalculated after any data changes have taken place.
Figures 2 to 4 show how the rule index is calculated for different types of incoming packets. In the figures the Ieast significant bit (bit 0) is at the right hand side of each field.
According to a preferred embodiment of the present invention, the allocation of IP
addresses and port numbers to the firewall filter is performed by a firewall control function that is arranged to generate unique locations in such a way as to allow for rapid identification of the appropriate rule for subsequent packets forming part of the same call. According to a further preferred embodiment of the present invention, the allocation of IP addresses and port numbers to the firewall filter is performed by a platform external to the firewall that is arranged to generate unique locations in collaboration with the firewall control function in such a way as to allow for rapid identification of the appropriate rule for subsequent packets forming part of the same SUBSTITUTE SHEET (RULE 26) Ball. Rather than using a process of checking each rule in turn, the invention advantageously provides for using a field from received packets whose content is set locally to the firewall (as described above), as opposed to being set by endpoints to provide an index directly to the relevant rule (or to the relevant location in the table of 5 rules). Hence, if an appropriate rule has been set up the index value will point directly to it. If the index value does not indicate a valid rule, then the packet concerned is rejected. Even in rejecting packets, the invention provides increased efficiency. Hence, according to the present invention, the decision to pass or reject a packet is always achieved with a single access to the rule table.
Figure 2 shows calculation of the rule index for non-TCP/UDP protocols. For protocols other than TCP or UDP the rule index is calculated based on a value in a "1P
Protocol Index Table" indicated by the 8-bit protocol DJ value along with 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 indicated entry is the table indicates whether the protocol is valid or not. If the protocol is valid, then the rule index is formed by taking the least significant 6 bits from the IP address along with the least significant 14 bits taken from the indicated entry in the IP Protocol Index Table that relates to that protocol.
Figure 3 shows calculation of the rule index for "well known ports". If the protocol is TCP or UDP and the port number is in the range 0000 - BFFF hexadecimal the port number is used as an index to the "well known port" table. The "well known port" table contains port numbers with specific identities as defined by IANA (e.g. 79 =
finger).
SUBSTITUTE SHEET (RULE 26) This table is used to establish if the port is supported on this filter.
Assuming that the port is supported, an index to the rule data is based on a value from the table indicated by the destination port number along with the IP address. The rule index is formed by taking the least significant 6 bits from the IP address along with the least significant 14 bits taken from the entry in the Well Known Port number table indicated by that port number. If a port is not supported, then packets sent to it are discarded.
Figure 4 shows calculation of the rule index for User Ports. For TCP and UDP
protocols where it is not a Well Known Port (i.e. the port number is in the range C000-FFFF hexadecimal) the rule index is formed from part of the port number and the IP
address. The rule index is formed by taking the least significant 6 bits from the IP
address along with the least significant 14 bits of the port number.
The exception to the above is for any IPSEC packets. There are two versions of IPSEC
protocol types, IP protocol 50 ESP (Encapsulating Security Payload) and IP
protocol 51 AH (Authentication Header). Both these versions include a Security Parameters Index (SPI). For ESP this field is in the first 32 bits and for AH in the second 32 bits of the Security Header. The SPI, along with the destination IP address and protocol uniquely identify the packet. Formatting the rule index for these packets is achieved by a similar process to that described above for user ports but using the lowest fourteen bits of the SPI and the lowest 6 bits of the IP address rather than the destination port number. Note that after the rule index is formulated the filter carries out check and replace functions according to the values in the control field of the rule data. For the IPSEC
packet the principle difference is that there is just the one value, the SPI, rather than the source and SUBSTITUTE SHEET (RULE 26) destination port numbers, though this value is stored in the same location.
This value will still be checked and replaced if required, as directed by the rule.
The rule index is used to access the rule and the checks stipulated by the rule control and validity word (a part of the rule that determines criteria used in checking the packet) are performed. If these checks are passed, the packet header addresses and ports etc., are translated as required.
The IP header checksums are recalculated and the UDP/TCP header checksums are adjusted, if required, i.e. due to IP addresses from the IP header that are changed. The valid packet statistical information is updated to include the present packet.
If any of the checks fail then some statistics about the packet are logged and the packet is discarded.
Packets may be discarded for any one of the following reasons.
The IP version within the packet does not match that of the filter e.g. IPv4 when the filter is running IPv6 or vice versa ~ Incorrect destination IP address: each filter has a range of IP addresses that it acts for, including multicast addresses and private IP addresses. Any packet with an IP
address that is not in the filter's range will be rejected.
~ The header length of the packet is less than the minimum size needed to verify the packet as correct.
~ The protocol is one not accepted by the filter. The filter supports a number of protocols that are acceptable and if the protocol field of the packet header' is not in SUBSTITUTE SHEET (RULE 26) this list the packet is rejected.
~ The rule index calculated from the IP address and port number (or SPI for 1PSEC ) references a rule that is not in an open state that will allow transfer of packets ~ The sender's 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 ll~
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 'C000' hexadecimal (which therefore is for a "well known port") but no entry in the "well known port" table exists.
~ 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 1P address and port number (or SPI for IPSEC) references a rule that is not set up.
The present invention applies to packet filters whether implemented in hardware or software. The present invention is not limited to 1P over Ethernet, but applies to other network types such as packet over SONETISDH, and ATM AALS. The present invention achieves optimum performance whilst using cheap random access memory.
SUBSTITUTE SHEET (RULE 26) Definitions Address Resolution Protocol (ARP) A protocol for mapping an IP address to a physical machine address that is recognised in the local network.
Gatekeeper An entity in an IP Telephony network. It performs a) RAS of other entities in the network, b) address translation for parties making calls and c) control of Gateways.
H.225 ITU-T standard defining call signalling protocols and media stream packetization for packet-based multimedia communications systems.
H.323 ITU-T standard for packet-based multimedia communications systems.
IANA IANA.
ITU-T International Telecommunications Union -Telecommunications IETF Internet Engineering Task Force.
Internet Protocol (IP) The network layer protocol for IP networks, providing unreliable point-to-point transfer of data packets (datagrams). The currently used standard is version 4 (IPv4) defined in IETF
RFC 791. This will be replaced in the future by version 6 (IPv6) defined in IETF RFC
2460.
SUBSTITUTE SHEET (RULE 26) Definitions 1P Telephony , The technology of telephony over IP
Voice over Internet, protocol based networks.
Multimedia over IP
Media Gateway Control Protocol A proposed protocol of the ITU-T
(MGCP) MEGACO working group, for control of Media Gateways by Gatekeepers. Defined in Internet Draft document draft-huitema megaco-mgcp-vOrl -OS.
MEGACO MEGACO defines the protocols used between elements of a physically decomposed multimedia gateway. The MEGACO framework is described in IETF
Internet Draft document draft-ietf ynegaco-protocol-~4.
Registration, Admission and Status Signalling function within the H.323 (RAS) protocol providing registration for entities in a network, authentication of users making IP
Telephony calls, and status information on registrations. RAS uses H.225 messages.
The RAS signalling channel is opened prior to the establishment of any other channels between H.323 endpoints.
Transmission Control Protocol (TCP) A connection-oriented, reliable transport-layer protocol designed to operate over the IP protocol. Defined by IETF RFC 793.
User Datagram Protocol (UDP) A connectionless, unreliable transport layer protocol designed to operate over the 1P
protocol. Defined in IETF RFC 76~.
SUBSTITUTE SHEET (RULE 26)
Claims (29)
1. A communications system comprising a packet control means for checking packets according to a plurality of rules, in which each packet is associated with a control value;
the packet control means comprising index means for generating an index value from the control value associated with a packet and means for using the index value to access a rule for checking the packet from the plurality of rules;
in which the packet checking always requires a single access to the plurality of rules.
the packet control means comprising index means for generating an index value from the control value associated with a packet and means for using the index value to access a rule for checking the packet from the plurality of rules;
in which the packet checking always requires a single access to the plurality of rules.
2. The communications system of Claim 1 in which the control value is set by the packet control means.
3. The communications system of Claim 1 in which the communications system also comprises packet value means, external to the packet control means, in which the control value is set by the packet value means in collaboration with the packet control means.
4. The communications system as claimed in any above claim in which the packet control means comprises means for determining whether the packet control means should pass or reject the packet.
5. The communications system as claimed in any above claim in which the control value comprises an address and/or a port number (PN).
6. The communications system as claimed in claim 5 in which the index means comprises a means for using the PN value as a pointer into a look-up table; in which the index means also comprises a means for generating the index value; from the combination of the address and the look up table value indicated by the PN.
7. The communications system of any one of claims 1 to 4 in which the control value comprises an address and a protocol value.
8. The communications system of claim 7 in which the index means comprises a means for using the protocol value as a pointer into a look-up table in which the index means also comprises means for generating the index value based on the address and the look-up table value indicated by the protocol value.
9. The communications system as claimed in any above claim in which the index means comprises means for detecting multi-cast packets and for identifying a single rule for such packets.
10. The communications system as claimed in any above claim in which the control value is unique at any point in time for packets received from a particular source and relating to a particular call.
11. The communications system as claimed in any above claim in which the address is an internet protocol address.
12. The communications system as claimed in any above claim in which the PN is a User Datagram Protocol (UDP), Transmission; Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP) PN.
13. The communications system as claimed in any above claim in which the packet control means comprises a firewall.
14. The communications system as claimed in any above claim in which the packets carry telephony traffic.
15. A method of filtering packets in a packet based communications system comprising a packet control means; the method including the steps of receiving a packet comprising a control value at the control means and the step of using the control value to access a rule from a plurality of rules for use in checking the packet; in which the packet checking always requires a single access to the plurality of rules.
16. The method of Claim 15 in which the packet control means allocates the control value to the packet.
17. The method of Claim 15 in which the communications system comprises a packet value means; in which the packet value means, allocates the control value in collaboration with the packet control means.
18. The method of claim 15 to 17 including the step of determining whether the packet control means should pass or reject the packet.
19. The method of any one of claims 15 to 18 in which the control value comprises a PN and/or an address.
20. The method of claim 19 in which the index means uses the PN value as a pointer into a look-up table; in which the index means also generates the index value from the combination of the address and the look-up table value indicated by the PN.
21. The method of any one of claims 15 to 18 in which the control value comprises an address and a protocol value.
22. The method of claim 21 in which the index means uses the protocol value as a pointer into a look-up table; in which the index means generates the index value based on the address and the look-up table value indicated by the protocol value.
23. The method as claimed in any one of claims 15 to 22 in which the index means comprises means for detecting mufti-cast packets and for identifying a single rule for such packets.
24. The method as claimed in any one of claims 15 to 23 in which the control value is unique at any point in time for packets received from a particular source and relating to a particular call.
25. The method as claimed in any one of claims 15 to 24 in which the address is an Internet protocol address.
26. The method as claimed in any one of claims 15 to 25 in which the PN is a UDP, TCP or SCTP PN.
27. The method as claimed in any one of claims 15 to 26 in which the packet control means comprises a firewall.
28. The method as claimed in any one of claims 15 to 27 in which the packets carry telephony traffic.
29. The 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 table of rules for identifying the appropriate rule.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB0100713.7 | 2001-01-11 | ||
| GB0100713A GB2371186A (en) | 2001-01-11 | 2001-01-11 | Checking packets |
| PCT/GB2002/000040 WO2002056562A1 (en) | 2001-01-11 | 2002-01-07 | Firewall with index to access rule |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2434600A1 true CA2434600A1 (en) | 2002-07-18 |
Family
ID=9906643
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002434600A Abandoned CA2434600A1 (en) | 2001-01-11 | 2002-01-07 | Firewall with index to access rule |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20040100972A1 (en) |
| EP (1) | EP1352503A1 (en) |
| JP (1) | JP2004522335A (en) |
| CN (1) | CN1496642A (en) |
| AU (1) | AU2002219332B2 (en) |
| CA (1) | CA2434600A1 (en) |
| GB (1) | GB2371186A (en) |
| WO (1) | WO2002056562A1 (en) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7249379B2 (en) * | 2002-02-01 | 2007-07-24 | Systems Advisory Group Enterprises, Inc. | Method and apparatus for implementing process-based security in a computer system |
| US7062680B2 (en) * | 2002-11-18 | 2006-06-13 | Texas Instruments Incorporated | Expert system for protocols analysis |
| US8112482B1 (en) * | 2004-04-14 | 2012-02-07 | Sprint Spectrum L.P. | System and method for securing access to electronic mail |
| US8265060B2 (en) | 2004-07-15 | 2012-09-11 | Qualcomm, Incorporated | Packet data filtering |
| US8042170B2 (en) * | 2004-07-15 | 2011-10-18 | Qualcomm Incorporated | Bearer control of encrypted data flows in packet data communications |
| CN1997010B (en) * | 2006-06-28 | 2010-08-18 | 华为技术有限公司 | An implementation method for packet filtering |
| US8099774B2 (en) * | 2006-10-30 | 2012-01-17 | Microsoft Corporation | Dynamic updating of firewall parameters |
| IL181427A0 (en) * | 2007-02-19 | 2007-07-04 | Deutsche Telekom Ag | Novel dynamic firewall for nsp networks |
| DE102007053691A1 (en) * | 2007-11-10 | 2009-05-14 | Manroland Ag | Communication network of a printing press control |
| US8102783B1 (en) | 2009-02-04 | 2012-01-24 | Juniper Networks, Inc. | Dynamic monitoring of network traffic |
| JP5158021B2 (en) * | 2009-05-27 | 2013-03-06 | 富士通株式会社 | Tunnel communication apparatus and method |
| US9237128B2 (en) * | 2013-03-15 | 2016-01-12 | International Business Machines Corporation | Firewall packet filtering |
| KR101563059B1 (en) * | 2012-11-19 | 2015-10-23 | 삼성에스디에스 주식회사 | Anti-malware system and data processing method in same |
| US9444914B2 (en) | 2013-09-16 | 2016-09-13 | Annapurna Labs Ltd. | Configurable parser and a method for parsing information units |
| US11425095B2 (en) | 2016-05-01 | 2022-08-23 | Nicira, Inc. | Fast ordering of firewall sections and rules |
| US11310202B2 (en) * | 2019-03-13 | 2022-04-19 | Vmware, Inc. | Sharing of firewall rules among multiple workloads in a hypervisor |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU707905B2 (en) * | 1996-04-24 | 1999-07-22 | Nortel Networks Corporation | Internet protocol filter |
| US6147976A (en) * | 1996-06-24 | 2000-11-14 | Cabletron Systems, Inc. | Fast network layer packet filter |
| US6510151B1 (en) * | 1996-09-19 | 2003-01-21 | Enterasys Networks, Inc. | Packet filtering in connection-based switching networks |
| US6233686B1 (en) * | 1997-01-17 | 2001-05-15 | At & T Corp. | System and method for providing peer level access control on a network |
| US5951651A (en) * | 1997-07-23 | 1999-09-14 | Lucent Technologies Inc. | Packet filter system using BITMAP vector of filter rules for routing packet through network |
| US7143438B1 (en) * | 1997-09-12 | 2006-11-28 | Lucent Technologies Inc. | Methods and apparatus for a computer network firewall with multiple domain support |
| SE513828C2 (en) * | 1998-07-02 | 2000-11-13 | Effnet Group Ab | Firewall device and method for controlling network data packet traffic between internal and external networks |
| US6341130B1 (en) * | 1998-02-09 | 2002-01-22 | Lucent Technologies, Inc. | Packet classification method and apparatus employing two fields |
| US6400707B1 (en) * | 1998-08-27 | 2002-06-04 | Bell Atlantic Network Services, Inc. | Real time firewall security |
| US6798777B1 (en) * | 2000-04-17 | 2004-09-28 | Juniper Networks, Inc. | Filtering and route lookup in a switching device |
| US7039053B1 (en) * | 2001-02-28 | 2006-05-02 | 3Com Corporation | Packet filter policy verification system |
| US6816455B2 (en) * | 2001-05-09 | 2004-11-09 | Telecom Italia S.P.A. | Dynamic packet filter utilizing session tracking |
| US7107609B2 (en) * | 2001-07-20 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Stateful packet forwarding in a firewall cluster |
-
2001
- 2001-01-11 GB GB0100713A patent/GB2371186A/en not_active Withdrawn
-
2002
- 2002-01-07 AU AU2002219332A patent/AU2002219332B2/en not_active Ceased
- 2002-01-07 JP JP2002557096A patent/JP2004522335A/en active Pending
- 2002-01-07 WO PCT/GB2002/000040 patent/WO2002056562A1/en active Application Filing
- 2002-01-07 CA CA002434600A patent/CA2434600A1/en not_active Abandoned
- 2002-01-07 CN CNA028063309A patent/CN1496642A/en active Pending
- 2002-01-07 EP EP02729429A patent/EP1352503A1/en not_active Withdrawn
- 2002-01-07 US US10/250,958 patent/US20040100972A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CN1496642A (en) | 2004-05-12 |
| WO2002056562A9 (en) | 2003-11-13 |
| AU2002219332B2 (en) | 2006-12-21 |
| EP1352503A1 (en) | 2003-10-15 |
| US20040100972A1 (en) | 2004-05-27 |
| GB2371186A (en) | 2002-07-17 |
| JP2004522335A (en) | 2004-07-22 |
| GB0100713D0 (en) | 2001-02-21 |
| WO2002056562A1 (en) | 2002-07-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7782902B2 (en) | Apparatus and method for mapping overlapping internet protocol addresses in layer two tunneling protocols | |
| AU2002219332B2 (en) | Firewall with index to access rule | |
| US8537818B1 (en) | Packet structure for mirrored traffic flow | |
| US8191119B2 (en) | Method for protecting against denial of service attacks | |
| US7730521B1 (en) | Authentication device initiated lawful intercept of network traffic | |
| Conta et al. | Internet control message protocol (icmpv6) for the internet protocol version 6 (ipv6) specification | |
| US6940862B2 (en) | Apparatus and method for classifying packets | |
| US6965599B1 (en) | Method and apparatus for relaying packets based on class of service | |
| US6970475B1 (en) | System and method for handling flows in a network | |
| CN1757220B (en) | Apparatus and method for detecting tiny fragment attacks | |
| AU2002219332A1 (en) | Firewall with index to access rule | |
| US7898966B1 (en) | Discard interface for diffusing network attacks | |
| US20040125797A1 (en) | Flow labels | |
| US20040128554A1 (en) | Apparatus and method for allowing peer-to-peer network traffic across enterprise firewalls | |
| EP2057552A2 (en) | System and method for distributed multi-processing security gateway | |
| US20080298370A1 (en) | Router | |
| EP1859584A1 (en) | Processing realtime media streams | |
| US8510840B2 (en) | Method and apparatus for detecting scans in real-time | |
| US20050177717A1 (en) | Method and apparatus for defending against denial on service attacks which employ IP source spoofing | |
| US20080219178A1 (en) | Method of data analysis in a packet switched network | |
| Conta et al. | Rfc 4443: Internet control message protocol (icmpv6) for the internet protocol version 6 (ipv6) specification | |
| KR101005213B1 (en) | Method for routing data packets, and devices for implementing the method | |
| Yoo | Protocol anomaly detection and verification | |
| US7920564B1 (en) | Differential services support for control traffic from privileged nodes in IP networks | |
| US9118555B1 (en) | Secure unauthenticated virtual local area network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |