1. Field
The present application generally relates to packet switch appliances, and, more particularly, to state-based filtering on a packet switch appliance.
2. Related Art
Packet switch appliances can be used to forward packets in a packet-switching network, based on their address information, to their destination terminals. Typically, packet switch appliances have one or more network ports for connection to the packet-switching network. The network port of a packet switch appliance can include a filter, which either drops or forwards packets. Packet switch appliances may also have one or more instrument ports connected to one or more network instruments, typically used to monitor packet traffic, such as packet sniffers, intrusion detection systems, intrusion prevention systems, or forensic recorders.
Conventional packet switch appliances typically have static filters, which use fixed values as filter criteria. Static filters can be used to filter packets used in static protocols because static protocols have fixed offsets and attributes whose values remain fixed as defined by their respective standards. For example, source or destination port 23 in the TCP header can be used as the static filter to filter telnet packets. Static filters of conventional packet switch appliances, however, are not able to perform state-based filtering because state-based protocols have some attributes whose values may be dynamically negotiated and thus change with state changes.
In one exemplary embodiment, a packet switch appliance includes a plurality of ports. One of the plurality of ports is configured to operate as a network port connected to a packet-switching network. Another of the plurality of ports is configured to operate as a first instrument port connected to a network instrument. To filter packets, one or more packets or copies of packets received through the first network port are examined prior to the packets or copies of packets being sent out the first instrument port to determine a current state of a state-based protocol, which includes a plurality of potential states. A filter is created or modified for the first network port or the first instrument port based on the determined current state of the state-based protocol.
The present application can be best understood by reference to the following description taken in conjunction with the accompanying drawing figures, in which like parts may be referred to by like numerals:
The following description sets forth numerous specific configurations, parameters, and the like. It should be recognized, however, that such description is not intended as a limitation on the scope of the present invention, but is instead provided as a description of exemplary embodiments.
With reference to
As discussed above, traffic (i.e., packets) flowing through packet switch appliance 102 can be filtered using static filters. A static filter examines a packet and makes a pass or drop decision based on one or more filter criteria. The one or more filter criteria of the static filter may be user-specified bit or byte patterns at certain offsets from the beginning of the packet. Note, the bit or byte pattern does not need to be explicitly specified by a user at a command line interface in order for the bit or byte pattern to be user specified. For example, if a user wants to filter on all telnet packets, the user may specific a “telnet” filter at a command line interface or any other user interface. Although the user did not explicitly specify the bit or byte pattern at the command line interface, the user specifying the “telnet” filter does result in the static filter using port value 23 at the transmission control protocol (TCP) header of packets as the filter criteria.
As also discussed above, state-based protocols typically include a plurality of states. One example of a state-based protocol is VoIP over session initiated protocol (SIP) protocol. VoIP includes an initialization state. SIP protocol includes a call request state to the callee. In a subsequent state, the callee acknowledges back to establish a call using real-time transport protocol (RTP) ports. In a termination state, the call is terminated. State-based protocols may also include tracking establishments of multi-protocol label switching (MPLS) label paths.
Instead of fixed values, attribute values of a state-based protocol typically change with state changes. For example, in VoIP, RTP port numbers may be dynamically negotiated during the initialization state of each call session. Thus, static filters, which use fixed values for filter criteria, cannot be used for state-based filtering.
In step 202 (
In step 204 (
Ingress filter 304 examines a packet at network port 104a and makes a pass or drop decision at network port 104a based on one or more filter criteria. In contrast, egress filter 306 examines a packet at instrument port 106a and makes a pass or drop decision at instrument port 106a based on one or more filter criteria.
When creating an ingress filter 304 and/or egress filter 306, state-based filtering module 302 sets one or more values of the one or more filter criteria for ingress filter 304 and/or egress filter 306 based on the determined current state of the state-based protocol. The newly created ingress filter 304 and/or egress filter 306 is assigned to the network port 104a and/or instrument port 106a.
When modifying an ingress filter 304 and/or egress filter 306, state-based filtering module 302 adjusts one or more values of the one or more filter criteria of ingress filter 304 and/or egress filter 306 based on the determined current state of the state-based protocol. Note, the act of modifying includes removing an existing ingress filter 304 and/or egress filter 306 based on the determined current state of the state-based protocol.
As one exemplary use of process 200 (
As a further example, assume the VoIP call described above is handled using SIP. When the VoIP call is established, a dynamic RTP port number will be determined. The voice traffic passes through this RTP port number as packets. State-based filtering module 302 creates or modifies a filter to filter on this RTP port number until the call is terminated or the connection is broken as reported by some timeout event. Note, the SIP protocol can be used to establish many different types of sessions other than a VoIP session.
The following provides exemplary command line input commands that can be used to create a filter for filtering packets belonging to a phone call involving the phone number 5551234:
The first command configures port 1 as a network port. The second command configures port 4 as an instrument port. The third command establishes a connection between port 1 and port 4 (i.e., the network port and the instrument port).
The fourth command creates an application filter that allows all packets belong to phone number 5551234 to pass through. The “appgroup” field specifies the application as being VoIP. The “protocol” field specifies the protocol as being SIP. Since SIP can support many different types of sessions, the “siptype” field specifies the type as being phone. The “phone” field specifies 5551234 as the phone number. An alias of “sipphone 1” is created for the phone number 5551234.
The fifth command assigns the application filter to port 1, which is a network port. Thus, in this example, the filter is an ingress filter. As noted above, the filter can be configured as an egress filter and assigned to port 4, which is an instrument port.
As noted above, state-based filtering module 302 can be implemented as computer executable instructions. With reference to
In particular, when the commands are entered, state-based filtering module 302 (
In one exemplary embodiment, rather than directing all traffic to processor 116, a hardware filter can be used to only direct traffic specific to a specific flow to processor 116. In particular, in certain protocols, the first packet of a flow can be identified by examining for a specific pattern in a specific field, which is located at a fixed offset from the beginning of packets. For example, for VoIP over SIP, the first packet for the initialization of a phone call to phone number 5551234 can be identified by examining for an SIP packet that has the INVITE operator in the SIP header and the phone number 5551234, which are fields located at fixed offsets from the beginning of packets. In this manner, the amount of traffic having to be processed by processor 116 is reduced.
The examples above involved filtering based on a single phone number. It should be recognized, however, that appropriate command line input commands can be used to create filters to perform more sophisticated filtering of phone numbers.
For example, the “phone” field mentioned above can include multiple terms using various syntax. Two terms are separated by a term divider, such as a semicolon. Each term can include one or more “from” phones and one or more “to” phones. Multiple “from” phones and/or “to” phones can be separated using various symbols. For example, a “|” symbol can be used to separate multiple “from” phones and/or “to” phones. Also, various symbols can be used to specify relationships between the “from” phones and the “to” phones. For example, a “>” symbol can be used to specify that the “from” phones and “to” phones can not be interchanged, and a “^” symbol can be used to specify that the “from” phone and “to” phones can be interchanged.
As one example of a more sophisticated filtering of phone numbers, assume the “phone” field is “4085551234|4085555678>01178121234567;4085552345^4155556789”. The first term (“4085551234|4085555678>01178121234567”) means that either of “from” phone 4085551234 or phone 4085555678 makes calls to international “to” phone 01178121234567. In the first term, because the “from” phones and the “to” phone are separated by the “>” symbol, the “from” phones and the “to” phone cannot be interchanged. Thus, packets related to a call from phone 01178121234567 to either phone 4085551234 or phone 4085555678 will not be filtered. The second term (“4085552345^4155556789”) means that phone 4085552345 calls phone 4155556789. In the second term, because the “from” phone and the “to” phone are separated by the “A” symbol, the “from” phone and the “to” phone can be interchanged. Thus, packets related to a call from phone 4085552345 to phone 4155556789 as well packets related to a call from phone 4155556789 to phone 4085552345 will be filtered.
In addition to phone numbers, the “phone” field can use codes to specify phone regions. For example, the following codes can be used to specify the following four typical phone regions:
As one example of a more sophisticated filtering of phone numbers, assume the “phone” field is “4085551234|4155555678^I;5105552345”. The first term (“4085551234|4085555678^I”) means that either of “from” phone 4085551234 or phone 4085555678 makes or receives international calls. The second term (“5105552345”) means that phone 5105552345 can either call any number or receive calls from any number.
The above examples relate to handling VoIP calls using SIP protocol. It should be recognized, however, that process 200 can be used with regard to various state-based protocols. For example,
As mentioned above, packet switch appliance 102 (
With reference again to
With reference to
In one exemplary embodiment, process 200 (
System CPU 804 may not be able to handle the packets or copies of packets forwarded from network switch chip 114, particularly if packets are entering the ingress port at line rate. Thus, in the present exemplary embodiment, state-based filtering module 302 (
As depicted in
In the embodiment of packet switch appliance 102 depicted in
Although exemplary embodiments have been described, various modifications can be made without departing from the spirit and/or scope of the present invention. Therefore, the present invention should not be construed as being limited to the specific forms shown in the drawings and described above.
This application is a continuation of U.S. patent application Ser. No. 12/148,481, filed Apr. 17, 2008, now U.S. Pat. No. 8,315,256, the entire disclosure of which is expressly incorporated by reference herein.
Number | Name | Date | Kind |
---|---|---|---|
6816455 | Goldberg et al. | Nov 2004 | B2 |
6839349 | Ambe et al. | Jan 2005 | B2 |
7149230 | Coffin et al. | Dec 2006 | B2 |
7848326 | Leong et al. | Dec 2010 | B1 |
20040013112 | Goldberg et al. | Jan 2004 | A1 |
20050053073 | Kloth et al. | Mar 2005 | A1 |
20050190772 | Tsai et al. | Sep 2005 | A1 |
20050190799 | Coffin et al. | Sep 2005 | A1 |
20050229246 | Rajagopal et al. | Oct 2005 | A1 |
20050254490 | Gallatin et al. | Nov 2005 | A1 |
20050265248 | Gallatin et al. | Dec 2005 | A1 |
20050265364 | Gallatin et al. | Dec 2005 | A1 |
20050271065 | Gallatin et al. | Dec 2005 | A1 |
20060067231 | Ikoma et al. | Mar 2006 | A1 |
20070047457 | Harijono et al. | Mar 2007 | A1 |
20070147380 | Ormazabal et al. | Jun 2007 | A1 |
20080225874 | Lee | Sep 2008 | A1 |
20090103551 | Lin | Apr 2009 | A1 |
Entry |
---|
Non-final Office Action dated Dec. 1, 2009, for U.S. Appl. No. 12/148,481. |
Final Office Action dated Mar. 25, 2010, for U.S. Appl. No. 12/148,481. |
Non-final Office Action dated Nov. 9, 2010, for U.S. Appl. No. 12/148,481. |
Final Office Action dated Apr. 21, 2011, for U.S. Appl. No. 12/148,481. |
Advisory Action dated Jul. 12, 2011, for U.S. Appl. No. 12/148,481. |
Non-final Office Action dated Jan. 18, 2012, for U.S. Appl. No. 12/148,481. |
Notice of Allowance and Fee(s) Due dated Jul. 20, 2012, for U.S. Appl. No. 12/148,481. |
Number | Date | Country | |
---|---|---|---|
20130034107 A1 | Feb 2013 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12148481 | Apr 2008 | US |
Child | 13649020 | US |