JP2008524965A - Network interface and firewall devices - Google Patents

Abstract

Network processing devices provide a novel architecture for performing firewall and other network interface management operations. The UPM (Unified Policy Management) architecture uses the same memory and processing structure to integrate firewall policy management into routing and switching decisions. In other embodiments, a Reconfigurable Semantic Processor (RSP) uses a parser that identifies different syntax elements. These syntax elements are then used by one or more semantic processing units (SPUs) to perform different firewalls, network interfaces, routing, switching, and other packet processing tasks.
[Selection] Figure 1

Description

Related applications

  This application is based on US patent application No. 11 / 187,049 entitled “Network Interface and Firewall Device” filed on July 21, 2005, “Pushdown Automaton” filed on July 22, 2005. US Patent Application No. 60 / 701,748 entitled "Invention Detection System" and US Patent Application No. 60 / 701,748 entitled "Intrusion Detection System" filed May 9, 2005 Claims priority based on patent application No. 11 / 125,956. US Patent Application No. 11 / 125,956, entitled “Intrusion Detection System”, claims the priority of US Provisional Patent Application No. 60 / 639,002 filed on December 21, 2004, and This is a continuation-in-part of copending US patent application No. 10 / 351,030 filed on January 24, 2003. All of the above applications are incorporated herein by reference in their entirety.

Background of the Invention

  The openness of the Internet has led to various attacks on machines connected to the Internet. These attacks are performed by sending a packet sequence that makes it impossible for the target machine to operate correctly. This attack may be an attack that crashes the target machine, denial of service (DoS), distributed denial of service (DDoS), makes this machine unusable, It is categorized as an attack that modifies the files and software on this target machine to either corrupt the data or act as a DoS attack source clone.

  Many attacks are generated on machines that are connected to the public Internet and break into the enterprise through the company's connection to the Internet. Some companies have more than one connection point to the Internet. Therefore, network devices (also called firewalls) located at the interface between the two networks are used to prevent these attacks. For example, a firewall may be placed between the public and private Internet, between two Internet Service Provider (ISP) networks, between two local area networks, or some other network . If a firewall device is located at every Internet connection point, a perimeter firewall is formed around its internal network and machines.

  This firewall has a function to prevent an unauthenticated attack packet from entering a private network and, in some cases, a function to prevent unauthorized transmission from inside the private network. Other uses of the firewall include modifying information inside the packet. For example, a firewall can also be used as a network address translator (NAT) to translate between public Internet protocol (IP) addresses and private Internet protocol (IP) addresses.

  Traditionally, firewall operations are primarily as a collection of software modules running on either an embedded processor such as PowerPC® or an Intel class x86 processor (“Intel” is a registered trademark). Has been executed. The problem is that these hardware architectures do not have the processing power to effectively perform the firewall operations described above. For this reason, when packets flow from the source to the destination, each of them is examined, and various rules for determining whether the packets are valid are applied to completely prevent various attacks and remove them. It is difficult if not impossible.

  The present invention aims to solve this problem and problems associated with the prior art.

  Network processing devices provide an unprecedented architecture for controlling the management operations of firewalls and other network interfaces. In another aspect of the invention, a unified policy management (UPM) architecture uses the same memory and processing structure to integrate firewall policy management with routing and switching decisions. In another embodiment, a Reconfigurable Semantic Processor (RSP) uses a parser to identify different syntax elements. These identified syntax elements are then used by one or more Semantic Processing Units (SPUs) to perform different firewall, network interfaces, routing, switching and other packet processing operations.

  The foregoing objects, features, and advantages of the present invention, as well as other features, objects, and advantages will become apparent from the following detailed description of the preferred embodiments of the present invention that is described in conjunction with the accompanying drawings.

Detailed description

  FIG. 1 shows a private Internet Protocol (IP) network 24 connected to a public IP network 12 via a network interface device 25A. This public IP network 12 may be any wide area network (WAN) that provides packet switching. The private network 24 is a company enterprise network, an Internet service provider (ISP) network, a home network, or the like that needs to communicate with the public IP network 12.

  The network processing devices 25A-25D in the private network 24 may be any type of communication device as long as they communicate over a packet switched network. For example, the network processing devices 25A and 25B may be routers, switches, gateways, firewalls, and the like. The endpoint 25C is a personal computer (PC), and the endpoint 25D is a server such as an Internet web server. The PC 25C may be connected to the private network 24 via a wired connection such as a wired Ethernet connection, or a wireless connection using, for example, the IEEE 802.11 protocol.

  A reconfigurable semantic processor (RSP) 100 operates in any combination of network devices 25A-25D in the private network 24. Different RSPs 100 collect and analyze both network traffic 22 entering the private network 24 and network traffic 22 passing through the private network 24. In this example, the RSP 100A in the network processing device 25A is configured to operate as a firewall and normal network interface for the private network 24. Although the network interface operations and normal firewall operations described below are shown to be performed within RSP 100, some of these operations can also be performed within other traditional computer architectures. I understand that there are also.

  In one example, the RSP 100A is configured to detect and prevent denial of service (DoS) attacks 16. An external PC 14 connected to the public IP network 12 may generate a DoS attack that is intended to bring down one or more network processing devices 25A-25D in the private network 24. The RSP 100A monitors all incoming packets 20 received from the public IP network 12, and discards all packets associated with the DoS attack 16 in the packet stream 20. In addition to detecting and discarding packet 16, RSP 100A may also perform another network interface operation 26 on packet 22 that has not been discarded as associated with DoS attack 16. For example, RSP 100A can detect and filter viruses and malware, network address translation (NAT), routing, statistical analysis, logging, public IP network 12 and private IP network 24. It is possible to provide an appropriate combination of functions such as other packet conversion operations required for packets transferred between the two. All of these operations are described in more detail below.

  In another example, the RSP 100 is located at another network processing device located inside the private network 24, or at another major access point that is the entrance to the private network 24. It may be incorporated (installed) in another network processing device. For example, the RSP 100B may be located in the server 25D to provide operations 26 such as similar authentication, routing, statistical analysis, etc., described in more detail below. In other ways, some of the packet operations 26 may be performed in the RSP 100B and not in the RSP 100A. For example, RSP 100B may perform statistical analysis and DoS filtering in addition to all other packet analysis filtering and packet conversion performed by RSP 100A.

  Each of the other network processing devices 25B and 25C in the private network 24 has one or more RSPs 100 configured to perform any of the operations described below. Also good. Platforms using this RSP 100 also allow packets or other data over wireless interfaces (eg, cellular code division multiple access (cellular CDMA), time division multiple access (TDMA), 802.11, Bluetooth, etc.). It may be any wireless device that receives the stream (eg, a wireless PDA, wireless mobile phone, wireless router, wireless access point, wireless client, etc.).

Reconfigurable Semantic Processor (RSP)
FIG. 2A shows a block diagram of a reconfigurable semantic processor (RSP) 100 that is used to perform firewall operations and other network interface operations in one embodiment, described below. The RSP 100 includes an input buffer 140 for buffering a packet data stream received via the input port 120, and an output buffer 150 for buffering a packet data stream output via the output port 152. Have.

  The Direct Execution Parser (DXP) 180 is a packet or frame received at the input buffer 140 (eg, an input “stream”) and a packet or frame output to the output buffer 150 (eg, an output “stream”). And controls the processing of packets or frames (eg, recirculation “streams”) that are recirculated in recirculation buffer 160. Input buffer 140, output buffer 150 and recirculation buffer 160 are preferably first-in first-out (FIFO / first-in-first-out) buffers.

  The DXP also controls packet processing by a Semantic Processing Unit (SPU) 200. The semantic processing unit 200 controls data transfer between the buffer 140, the buffer 150 and the buffer 160, and the memory subsystem 215. The memory subsystem 215 stores packets received from the input port 120 and is used for integrated policy management (UPM) operations and other firewall operations, as described below, for access control lists (ACLs). ) Store the table in the CAM 220.

  The RSP 100 uses at least three tables to perform a given firewall operation. A code 178 for retrieving the production rule (PR) 176 is stored in a parser table (PT) 170. The grammar generation rule 176 is stored in a production rule table (PRT) 190. A code segment 212 executed by the SPU 200 is stored in a Semantic Code Table (SCT) 210. The code 178 in the parser table 170 is stored in a manner such as a matrix format (row-column format) or a content addressable format. In matrix format, the rows of the parser table 170 are indexed by the non-terminal code NT 172 provided by the internal parser stack 185, and the columns are input data values extracted from the beginning of the data in the input buffer 140. Indexed by DI [N] 174. In the content addressable format, a concatenation of the non-terminal code 172 from the parser stack 185 and the input data value 174 from the input buffer 140 forms an input to the parser table 170.

  Production rule table 190 is indexed by code 178 from parser table 170. Tables 170 and 190 are linked as shown in FIG. 2A so that queries against parser table 170 send back (applicable) production rule 176 corresponding to non-terminal code 172 and input data value 174 directly. May be. The DXP 180 replaces the non-terminal code at the top of the parser stack 185 with a production rule (PR) 176 sent back from the PRT 190, and then continues to analyze the data from the input buffer 140.

  The semantic code table 210 is also indexed by the code 178 generated by the parser table 170, the generation rule 176 generated by the generation rule table 190, or both. Typically, the analysis result is that the DXP 180 determines, for a given production rule 176, the semantic entry point (SEP) routine 212 from the semantic code table 210 is loaded and executed by the SPU 200. Enable.

  The SPU 200 has several access paths to the memory subsystem 215 that provides a memory interface configured to be addressable by context symbols. Memory subsystem 215, parser table 170, generation rule table 190, and semantic code table 210 may be internal memory devices or external memory devices such as dynamic random access memory (DRAM) and content addressable memory (CAM) or the like. Use a combination of resources. Each table or context may only provide one or more other tables or contexts to the context interface for the shared physical memory area.

  A maintenance central processing unit (MCPU) 56 is connected between the SPU 200 and the memory subsystem 215. The MCPU 56 executes all of the functions desirable for the RSP 100 that can be reasonably performed by conventional software and hardware. These functions are usually functions that are rarely used and are not executed with the highest priority (not important in time), and are not intended to be included in the SCT 210 due to the complexity of the functions. The MCPU 56 preferably also has a function to request the SPU 200 to execute a task instead of the MCPU.

  The memory subsystem 215 has an array machine context data memory (AMCD) 230 for accessing data in the DRAM 280 via a hash function (hashing function) or content addressable memory (CAM) search. The encryption processing block 240 performs encryption, decryption, and authentication of data, and the context control block cache 250 caches the context control block to the DRAM 280 and caches the context control block from the DRAM 280. The normal cache 260 caches data used in basic operations, and the streaming cache 270 is used while the data stream is being written to DRAM 280 and while the data stream is being read from DRAM 280. Cache the data stream. The context control block cache 250 is preferably a software controlled cache. That is, SPU 200 preferably determines when a cache line is used and when it is free. Electrical circuits 240, 250, 260 and 270 are connected between DRAM 280 and SPU 200, respectively. The TCAM 220 is connected between the AMCD 230 and the MCPU 56 and stores an access control list (ACL) table and other parameters in a manner that sufficiently improves the performance of the firewall.

  More detailed design optimization for the functional blocks of RSP 100 can be found in co-pending US patent application No. 10 / 351,030, filed Jan. 24, 2003, entitled "Reconfigurable Semantic Processor". Are listed. This patent application is incorporated herein by reference in its entirety.

Use of RSP for Firewall Operation and Network Interface Operation The firewall operation and other network interface operation 26 described above in connection with FIG. 1 implements RSP 100 using production rules and semantic entry point (SEP) routine 212. Implemented. Packets arriving at the input port 120 of the RSP device 100 are parsed using the grammar table entry in the parser table 170 and processed semantically by the SEP routine 212. The SEP routine 212 determines to perform any of the following operations 1-5.
1. Accept the packet as it is and send it to output port 152.
2. Exclude the packet from further analysis and do not forward it.
3. After modifying the packet, send it to output port 152.
4. Hold the packet, wait for additional packets for the current session to arrive, and determine the final disposition for the packet.
5. Direct the packet to a specific destination or send it back into the RSP for further analysis.

  The grammar rules in the parser table 170 are configured to flag the SPU 200 for packets with known or suspicious anomalies while allowing them to pass acceptable packets. As an example of passage determination (whether or not to pass) according to the grammar, there is a TCP flag setting. The TCP flag field has 8 bits inside, and only some combinations are valid. This grammar rule is encoded in the parser table 170 to allow all acceptable TCP sequences and reject unacceptable TCP sequences. For example, a message of a combination of TCP SYN and FIN provided in the same packet is not a valid combination and is directly excluded (dropped) by the DXP 180.

  Some unacceptable packets or operations may only be determined by the auxiliary SEP routine 212. These are mainly related to session and protocol situations. In one example, a TCP data payload segment may be sent before sending the corresponding TCP SYN message. In this example, SEP routine 212 excludes from memory 280 packets for TCP sessions that have not been previously sent a TCP SYN message.

  The Direct Execution Parser (DXP) 180 can either directly reject a packet without consuming additional cycles within the SPU 200, or directly forward a non-attack packet in DoS processing. Using associated parser grammars offers improved performance (compared to systems using traditional firewalls). Traditional firewalls must match each packet against a list of "problematic" rules. This list grows over time as new attacks are discovered. Conversely, the parser grammar can be written to describe only problem-free packets and only those problem-free packets are allowed to pass through RSP 100. In this way, problematic packets are automatically excluded or processed directly by the SPU 200. This provides a more scalable packet monitoring operation.

RSP Parser and Production Rule Table
The operation of RSP 100 as a firewall or integrated policy management (UPM) can be better understood with special examples. In the example described below, RSP 100 provides Denial of Service (DoS) filtering of TCP packets. However, those skilled in the art will appreciate that the concepts described below can be easily applied to any type of firewall operation for any data stream transmitted using any communication protocol. Similar concepts can be easily applied to the Integrated Policy Management (UPM) operation described below.

  Firewall and UPM operations include parsing and detecting the syntax for the input data stream. These operations are described in conjunction with FIGS. 2B and 2C. First, referring to FIG. 2B, code (related to a plurality of different grammars) may exist simultaneously in the parser table 170 and the generation rule table 190. For example, code 300 is associated with parsing the format of a media access control (MAC) packet header, code 302 is associated with processing an IP packet, and another set of codes, code 304, is a transfer control protocol ( (TCP) Packet processing related. Another code 306 in the parser table 170 is associated with another firewall or denial of service (DoS) operation described in more detail below.

  The PR code 178 is used to access the corresponding generation rule 176 stored in the generation rule table 190. Unless required in performing a particular search, an input value 308 (eg, a non-terminal (NT) symbol 172 concatenated with the current input value DI [n] 174 (where n is the match width selected in bytes)) is It need not be assigned in any particular order within the PR table 170.

  In one embodiment, parser table 170 also includes an addresser 310 that receives NT symbols 172 and data values DI [n] 174 from DXP 180. Addresser 310 concatenates NT symbol 172 with data value DI [n] 174 and sends this concatenated value 308 to parser table 170. Conceptually, it is often useful to view the structure of the production rule table 170 as a matrix with one PR code 178 for each unique combination of NT code 172 and data value 174, The present invention is not so limited. Different types of memory and memory configurations may be appropriate for different applications.

  In one embodiment, parser table 170 is implemented as a content addressable memory (CAM), and addresser 310 uses NT code 172 and input data value DI [n] 174 as a key for CAM to retrieve PR code 178. Is used. The CAM is preferably a ternary CAM (TCAM) populated with TCAM entries. Each TCAM entry includes an NT code 312 and a DI [n] match value 314. Each NT code 312 can hold multiple TCAM entries.

  Each bit of DI [n] match value (DI [n] match value) 314 is set to “0”, “1”, or “X”. This “X” represents “Don't Care”. With this function, the PR code 178 requires that the parser table 170 match only a few bits or bytes of DI [n] 174 with the encoded pattern in order to find a match. And

  For example, a line of TCAM has an NT code NT_TCP_SYN 312A for a TCP SYN packet, which then represents content such as the destination IP address and TCP message identifier that would be present in the TCP SYN packet ( additional) Byte 314A follows. The remaining bytes of this TCAM line are set to “Don't Care”. Thus, when NT_TCP_SYN 312A and a few bytes of DI [N] are presented to the parser table 170, if the first set of bytes in DI [N] contains a TCP SYN message identifier, then the DI [N] A match will occur no matter what the remaining bytes contain.

  The TCAM in parser table 170 generates a PR code 178A corresponding to the TCAM entry that matches NT 172 and DI [N] 174, as described above. In this example, PR code 178A is associated with a TCP SYN packet. This PR code 178A may be sent back to the DXP 180, sent back directly to the PR table 190, or both. In one embodiment, PR code 178A is the row index of the TCAM entry that creates a match.

  FIG. 2C shows one possible implementation of the production rule table 190. In this embodiment, addresser 320 receives PR code 178 from either DXP 180 or parser table 170 and receives NT symbol 172 from DXP 180. Preferably, the received NT symbol 172 is the same NT symbol as the NT symbol sent to the parser table 170, where the NT symbol was used to generate the received PR code 178. is there.

  The addresser 320 uses these received PR codes 178 and NT symbols 172 to access the corresponding production rules 176. The addresser 320 is not necessary in some embodiments, but if used, it can be provided as part of the DXP 180 or PRT 190, or as an intermediate functional block. Can do. For example, if the parser table 170 or DXP 180 creates the address directly, no addresser is required.

  The generation rule 176 stored in the generation rule table 190 includes three data segments. These data segments include a symbol segment 177A, an SPU entry point (SEP) 177B segment, and a skip byte segment 177C. These segments may be fixed length segments or variable length segments, and are preferably null-terminated. Symbol segment 177A has a plurality of symbols transferred (pushed) onto DXP parser stack 185 (FIG. 2A). The plurality of symbols includes both or one of a terminal symbol and a non-terminal symbol. The SEP segment 177B has an SPU entry point (SEP) that the SPU 200 uses to process segments of data. In one embodiment described below, SEP segment 177B corresponds to ACL (ACL = Access control list) predicates and other syntactic elements identified in the currently analyzed packet.

  The skip byte segment 177C has a skip byte value that the input buffer 140 uses to increment its buffer pointer and proceed with processing the input stream. Also, other information useful in the production rule processing can be stored as part of the production rule 176.

  In this example, production rule 176 indexed by production rule code 178A corresponds to the identified TCP SYN packet in input buffer 140. SEP segment 177B points to SPU code 212 in semantic code table 210 of FIG. 2A. The SPC code 212, when executed by the SPU 200, performs an (on) DoS operation on the identified TCP SYN packet, as will be described below with reference to FIG. 4-11.

  In one embodiment, SPU 200 has an array of semantic processing elements that can be executed in parallel. SEP segment 177B in production rule 176A activates one or more SPUs 200 to perform the same firewall operation on different packets in parallel or to the same packet. And perform different firewall operations. It should be apparent that similar operations can be used to detect any firewall operations described below, network interface operations, and other types of packet or data identification required for UPM operations. .

  As described above, parser table 170 may include other grammars associated with TCP SYN packets or other grammars not associated with TCP SYN packets. For example, the IP grammar 302 included in the parser table 170 may identify an identified NT_IP in the input buffer 140 that is used in combination with the identified TCP SYN message to control DoS processing (see FIGS. 4-11 below). A production rule code 178 associated with the destination address may be included.

The matching data value 314 in the production rule code 302 includes the destination IP address of the network processing device located in the private network 24 of FIG. If the input data DI [I] 174 associated with the NT_IP code 172 does not hold the destination address included in the match value 314 for the PR code 302, the default generation rule code 178 is supplied to the generation rule table 190. Also good. This default generation rule code 178 points to a generation rule 176 in the generation rule table 190 that directs the DXP 180, the SPU 200, or both to discard the packet from the input buffer 140.

Denial of Service (DoS)
FIG. 3 illustrates how a DoS attack 16 can endanger the network processing device 406. In general, the purpose of preventing DoS attacks is to prevent malicious packets from gaining access to network processing devices within the private network 24. The following discussion discusses an example of a DoS attack associated with flooding a network device with a large number of packets. However, there are many other types of malicious attacks associated with one or a few malicious packets. For example, other malicious attacks may be associated with one or more packets that disrupt normal operation of the network processing device protocol. All of these attacks on network processing devices or networks are usually referred to below as DoS attacks and are all within the scope of the system.

  With reference to FIG. 3, the attack device 14 is usually, but not necessarily, operating outside the private network 24 and flooding the private network 24 with a large number of packets. In one example, the attacking computer 14 sends floods of Transfer Control Protocol (TCP) synchronization (SYN) packets 400 to a destination address in the private network 24. In another example, the attacker 14 sends a packet fragment 402 to a destination address in the private network 24. In either case, packet 16 causes one or more network devices 406 in private network 24 to maintain state 408 for each different received TCP SYN packet 400, and for each set of received packet fragments 402. State 410 is maintained.

  TCP SYN attack 400 and packet fragment attack 402 are just examples of many different types of DoS attacks that could be performed. For example, an attacker can stop a network device by sending a TCP End (FIN) packet or overlapping packet fragments. In a DoS attack based on another port, the worm is placed in a machine in the private network 24. The worm is then commanded by the attacker 14 to send a bogus message from inside the private network 24. This DoS attack may be initiated via an Internet Control Message Protocol (ICMP) message.

  Whenever a new TCP SYN packet 400 is received by the network processing device 406, a new TCP session state 408 is maintained and a corresponding TCP ACK message 404 is sent back to the sending device (the attacker 14). However, the attacker 14 ignores the TCP ACK reply 404 and continues to send new TCP SYN messages to the private network 24 instead. The attacker 14 may insert a forged source address in the TCP SYN message 400. In this case, since the network device 406 sends the TCP SYN ACK message 404 to another victim computer, the victim computer is forced to load the TCP SYN ACK message 404 flood.

  This network processing device 406 is required to maintain a TCP state 408 corresponding to each TCP SYN message 400 for some predetermined period of time. Maintaining a large amount of counterfeit TCP state 408 causes the resources in network device 406 to be exhausted until other legitimate IP traffic is severely slowed down or stopped.

  In a similar scenario, the attacker 14 may send a packet fragment 402 with an associated sequence number. Network processing device 406 must maintain state 410 until each packet fragment in sequence 402 has been received or until some timeout period expires. The attacker 14 intentionally excludes the packet fragment 402 from the sequence. This requires the network device 406 to maintain a state 410 for each set of packet fragments for the duration of the timeout period, thereby exhausting processing resources.

  The conventional technique for preventing these types of DoS attacks has been to limit the rate of the input packet 16. For example, the network processing device 406 identifies the destination address for all TCP SYN packets. TCP SYN packets destined for a specific destination address are excluded when the number of received packets exceeds a predetermined rate.

  However, a large amount of device resources are used to continuously monitor and track each DoS attack. Network processing device 406 is required to monitor all incoming packets for each possible DoS threat. For example, the network processing device 406 is required to identify each TCP SYN packet and each packet fragment. Even this process is severe. However, the network processing device 406 is also required to track the number and rate of received packets, and if necessary, also excludes similar types of packets that reach the DoS rate threshold. Is done. One problem is that current computer architectures lack the ability to perform these DoS operations at current network line rates.

  With reference to FIG. 4, the firewall 420 efficiently identifies DoS attacks and prevents DoS attacks by limiting the rate of packets in a unique manner. In the following description, any packet that may be part of a DoS attack is referred to as a DoS candidate packet. For example, TCP SYN packets may be used in DoS attacks. Therefore, the TCP SYN packet is identified as a DoS candidate packet by the firewall 420. Since a fragment packet may also be used in a feasible DoS attack, this packet is also identified as a DoS candidate packet by the firewall 420.

  The firewall 420 limits the rate of DoS candidate packets related to the related destination address. Identifying and managing the destination address for each feasible DoS attack can require a large amount of processing resources. However, the architecture used within the firewall 420 is higher performance and more scalable than the traditional firewall architecture, so this architecture can handle many different DoS attacks at higher line rates. Can be monitored and excluded.

Zone (Zones)
Policy management can assign different zones to network processing devices or networks. These different zones may be associated with, for example, different external network interfaces or internal network interfaces within the network processing device. These zones may be indicated independently of DoS operations due to network policy management considerations. On the other hand, certain aspects of the firewall 420 take into account the different interface zones that the policy manager has specified in advance when analyzing DoS threats.

  For example, first zone 1 may be associated with public IP traffic received from public network 12 via interface 426. Second zone 2 may be associated with moderately reliable virtual private network (VPN) traffic received on private network 12 via VPN tunnel 424. For example, the VPN tunnel 424 may be established between the private network 24 and the home computer 422. This home computer 422 may be operated by employees of a company operating a private network 24. Third zone 3 may originate from the interior of private network 24 and be associated with highly reliable IP traffic received via interface 428.

  Each zone may be associated with a different level of trust and thus may be assigned different DoS rate limits. This DoS rate limit is defined as the number of specific types of DoS candidate packets (for example, packets containing TCP SYN messages) with the same destination address that are allowed to pass through the firewall 420 for a specific period of time. Involved. Once the rate limit limit is reached, all additional packets with the same DoS type and the same destination address are excluded. For example, packets received from zone 1 via interface 426 are associated with the lowest reliability because they were received from untrusted sources via public network 12. Therefore, packets received from zone 1 may be assigned a lower DoS rate limit value (limit) compared to other zones.

  Zone 2 has medium reliability, presumably because the packet is received from a known resource 422. Therefore, Zone 2 may be assigned a higher DoS rate limit than Zone 1. For example, a TCP SYN packet with the same destination more than a TCP SYN packet with the same destination address allowed to pass through zone 1 for a specified period passes through zone 2 for a specified period Is allowed to. In this example, zone 3 is highly reliable because all packets received on interface 428 are from machines located in private network 24. Therefore, higher DoS rate limits may be assigned to packets received in zone 3.

  The zone associated with the received packet may be identified by source address or port information. For example, another processing device used within RSP 100 or firewall 420 may identify the zone associated with an incoming packet based on the VLAN ID of the associated source address and the interface through which the packet is received. You may decide. The firewall 420 then manages the DoS attack based in part on the identified zone associated with the packet. For example, packets associated with potential DoS threats can be counted, managed, and rate limited according to their associated zones. This allows the firewall 420 to allocate DoS resources to different interfaces more efficiently according to the reliability associated with them. This will be described in more detail below.

  With reference to FIG. 5, one embodiment of the firewall 420 shown in FIG. 4 includes a processor 442 that receives an input packet stream 440 that may include DoS candidate packets and non-DoS candidate packets. . The processor 420 first identifies packets (DoS candidate packets) that may be associated with a DoS attack in the packet stream 440. For example, the processor 442 may identify all incoming packet fragments or incoming packets that contain a TCP SYN message as DoS candidate packets.

  The processor 442 accesses the table 464 and identifies the zone 468 associated with the identified DoS candidate packet. For example, the processor 442 may match the port value in the identified DoS packet with the port number entry 466 in the table 464. The processor may then consider zone 468 in table 464 as being associated with a matching port number entry 466.

  The processor 442 uses the combination of the destination address 472 for the identified DoS packet and the associated zone value 468 as an address to the content addressable memory (CAM) 444. This CAM 444 accommodates a DoS entry 445 that is a combination of a destination address value and a zone value. The address location in CAM 444 is used as a pointer to static random access memory (SRAM) 450.

  The memory location in SRAM 450 is divided into fields including DoS attack flag 452, time stamp 454, generation value 456, and offset 458. The DoS attack flag 452 is set every time the number of packets related to a specific destination address exceeds a predetermined DoS rate limit value. As described above, the DoS rate limit value can be customized for different zones 448.

  The time stamp 454 is set each time a new entry is added to the TCAM 444 and reset every time the age of the time stamp exceeds a predetermined DoS period. The generation value 456 is used by the processor 442 to allocate and manage DoS entries in the TCAM 444, SRAM 450, and dynamic random memory (DRAM) 462. The offset value 458 is used as a pointer to the DRAM 462. The DRAM 462 has a set of counters 460 that keep track of the number of packets for a particular destination address received by the firewall 420 within the DoS period.

  The processor 442 identifies new DoS candidate packets 474 that may be part of a DoS attack. The destination address 472 and zone value 468 for the newly identified packet 474 is used as the address to the CAM 444. Since the new DoS candidate packet 474 will not match any existing entry, the processor 442 adds a new DoS entry 445 for the packet 474 to the CAM 444.

  The DoS attack flag 452 corresponding to the new DoS entry in the CAM 444 is cleared (erased), and the time stamp 454 is set to the current time value. The generation value 456 is set as described in more detail in FIG. 6 below, regardless of what generation is currently running in the processor 442. The processor 442 uses the address offset value 458 to increment the corresponding counter 460 in the DRAM 462 to 1. The processor 442 then processes the next packet in the packet stream 440.

  Packets in packet stream 440 that do not meet the criteria for a potential DoS attack are not identified as DoS candidate packets 441. For example, the packet 441 may not be a packet fragment but a regular IP packet that does not include a TCP SYN message. In this case, the processor 442 allows these packets 441 to pass through the firewall 420 without undergoing any further DoS processing.

  The next packet in the packet stream 440 may be identified as a potential DoS attack (DoS candidate packet). In this example, the next identified packet may already have a corresponding DoS entry in CAM 444. For example, one or more TCP SYN packets or packet fragments with the same destination address may have been received by the firewall 420 prior to this within the same DoS period. As a result, the destination address 472 and zone 468 for the packet will match one of the entries in the CAM 444. The address 449 corresponding to the matched (matched) CAM entry 445 is then used as the address to the SRAM 450.

  The processor 442 first checks the DoS attack flag 452 in the SRAM 450. If the DoS attack flag 452 is set, the processor 442 excludes the corresponding packet in the packet stream 440. If necessary, processor 442 may then update time stamp 454 and generation value 456.

  If the DoS attack flag 452 is not set, the processor 442 allows the associated packet in the packet stream 440 to pass through the firewall 420. The processor 442 then updates the DoS status information in the SRAM 450 and DRAM 462. For example, the processor 442 increments the corresponding counter 460 in the DRAM 462 and then compares the timestamp 454 with the current time value. If the time stamp 454 is not too old, the corresponding value of the counter 460 in the DRAM 462 is validated and compared to the DoS rate limit value. If the counter value 460 is below the DoS rate limit value, the processor 442 proceeds to process the next packet in the packet stream 440.

  If the timestamp 454 is too old when compared to the current time value, the corresponding count value 460 in the DRAM 462 is stale and reset to zero. Similarly, the time stamp 454 is reset to the current time value. This effectively resets the count 460 within each predetermined period. If time stamp 454 is valid (not too old) and incremented count 460 in DRAM 462 is above the DoS rate limit, processor 442 sets the corresponding DoS attack flag 452. As a result, the processor 442 excludes similar packets having the same destination address.

Generation
Generation value 456 is used to manage DoS entries in CAM 444, SRAM 450 and DRAM 462. With respect to the example of FIG. 6, CAM 444 is logically divided into four different generation sections 480. However, this is only one example, and the system can be configured to have any number of generation sections with arbitrarily configurable sizes.

  The processor 442 of FIG. 5 can identify and manage DoS attacks more efficiently by inserting and removing multiple DoS entries according to multiple generations 480. With reference to FIGS. 5-7, the processor 442 begins entering a DoS entry into the current generation 480 at operation 490. As shown in FIG. 6, the DoS entry 482 is entered into the current generation 0. In operation 492, the processor 442 removes one entry 484 from the next generation 1 for each entry 482 added to the current generation 0. This ensures that the CAM 444 always holds an available area when the processor 442 moves on to the next generation.

  DoS entry 482 may already exist in CAM 444. In this example, the processor 442 switches, in operation 494, the generation value 456 currently assigned to the existing DoS entry to that of the current generation. For example, suppose DoS entry 482 is received while processor 442 is operating within generation 0. This DoS entry 482 may match the existing DoS entry 489 that is currently assigned to generation 2. In operation 494, the processor 442 moves the DoS entry 489 from generation 2 to generation 0 (switch / switch). When processor 442 reassigns generation value 456 in SRAM 450 from 2 to 0, DoS entry 489 is logically moved to generation 0 instead of being physically moved to another location in CAM 444. You can understand that.

  Moving an existing DoS entry to the current generation ensures that entries for an active DoS that have been in the CAM 444 for a relatively long period of time will not be discarded by the processor 442. For example, a DoS attack may last for a long time. Each newly received packet associated with the same DoS attack will update the existing DoS entry in CAM 444 to the current generation value. This is equivalent to an active DoS attack, while other old DoS entries that did not grow into DoS attacks and other old DoS entries that no longer correspond to active DoS attacks are removed from CAM 444. Ensure that DoS entries remain in CAM 444.

  In operation 496, the processor 442 determines when a switch to the next generation should be made. Different events may cause the processor 442 to move on to the next generation. The processor 442 may move to the next generation at operation 498 if the current generation is filled with entries. This can happen, for example, when an attacker sends a large number of TCP SYN messages with different destination addresses.

  The processor 442 may move to the next generation within the operation 498 when the predetermined period expires. This ensures that all time stamps 454 (FIG. 5) correspond to the current time period tracked by the processor 442. For example, the time stamp 454 in SRAM 450 combined with the associated count value in DRAM 462 determines the rate of packets for the different destination addresses currently being received. When the timestamp period expires, the processor 442 needs to reset both the timestamp value 454 and the associated count value 460.

  However, the old DoS entry may remain in the CAM 444 after the current time value is used by the processor 442, rolled over, and reset to zero. In this case, the processor 442 may inadvertently add a count value to the count 460 in the DRAM 462 corresponding to the previous time stamp period. This may cause the counter 460 to erroneously count packets over a plurality of time stamp periods, leading to false detection of a DoS attack. In other words, counting a plurality of time stamp period packets leads to false indication of the actual packet rate.

  To solve this possible rollover problem, the processor 442 automatically moves to the next generation after a certain period of time, regardless of the number of entries in the current generation, in operation 496. If this predetermined period is increased by the total number of generations (in this example, the total number of generations is 4), it will be less than the rollover timestamp period used by the processor 442.

  For example, the processor 442 may maintain a current timer that rolls over every 4 seconds. The predetermined time stamp period used to move to the next generation may be set every 0.5 seconds. This ensures that all stagnant DoS entries in CAM 444 are removed every 2 seconds. As such, processor 422 ensures that all timestamps 454 in SRAM 454 will be associated with the same timestamp period. This also has the unexpected advantage that the SRAM 450 can reduce the number of bytes used for the time stamp 454. In other words, this timestamp value 454 requires only a sufficient number of bits to track a period (time) of about 2 seconds or more.

  If neither the size limit nor the time stamp period is reached in operation 496, the processor 442 continues to fill the current generation with new DoS entries, and the existing DoS entry to the current generation in operations 490-494. And keep reassigning. If at operation 496 either the size limit or the time stamp period has been reached, the processor 442 moves to the next generation at operation 498 and begins adding entries to the new generation. For example, the processor 442 begins to move the new DoS entry 486 to generation 1 and, accordingly, begins to remove the existing DoS entry 488 from the next generation 2.

Streamlining DoS Attach Identification
Turning briefly back to FIG. 5, if an incoming packet 440 is identified in CAM 444, the associated counter 460 in DRAM 462 is incremented and the number of similar packets are tracked by time stamp 454. It may be necessary to determine if the threshold for DoS attacks has been reached. However, the time required to access DRAM 462 may delay DoS attack determination and subsequent packet exclusion. This may also delay processing of other packets that have passed through the firewall 420. The DoS attack flag 452 is used by the processor 442 to quickly identify DoS packets that are part of the current DoS attack.

  5 and 8, the DoS attack flag 452 is used in conjunction with other processing operations to identify DoS attacks and reduce the inevitable delay in processing them. In operation 540, the processor 442 receives the packet. The processor 442 determines, at operation 542, whether the received packet has a new destination address and zone that is not currently included in the CAM 444 as a DoS entry.

  If there is no pre-existing entry in CAM 444, the packet is allowed to pass through firewall 420 immediately. Such a packet is not currently identified in CAM 444, so it is not part of the current DoS attack and will not be excluded thereafter. After the packet is allowed to pass, the processor 442 performs a DoS management operation after the fact (after allowing the packet to pass). This ensures that other packets following the identified packet are not delayed in vain.

  In this “after allowing the packet to pass” maintenance, processor 422 adds a new DoS entry to the current generation at operation 546, as described above in connection with FIGS. Remove the DoS entry from the generation. At operation 550, the processor 442 clears the DoS attack flag 452 (if not already cleared), sets a new timestamp value 454 (provides), sets a current generation value 456 (provides), and DRAM 462 The corresponding counter 460 is incremented.

  If necessary, processor 442 changes the current generation at operation 552. For example, as described above, the processor 442 changes the current generation when the current generation is filled with entries or when a predetermined time stamp period expires. Since the time stamp 454 for the new DoS entry is only set (provided), even if the new DoS entry reaches the current DoS entry limit for the current generation, the time stamp period does not expire.

  Returning to operation 542, the processor 442 may receive a packet having a destination address and zone corresponding to the DoS entry currently present in the CAM 444. The DoS attack flag 452 in the SRAM 450 corresponding to the matched CAM entry is immediately read by the processor 442 at operation 560. If the corresponding DoS attack flag 452 is set (provided), the packet is immediately excluded in operation 580. This packet may be removed by finally overwriting the packet in the memory without outputting the packet.

  If necessary, the processor 442 updates the information in the SRAM 450 in operations 582-586. However, since the DoS attack flag 452 is already set, the processor 442 need not increment the associated counter in the DRAM 462. For example, at operation 582, the processor 442 may update the generation value 456 for the DoS entry with the current generation. Subsequently, in operation 584, the processor 442 determines whether the time stamp 454 has expired. For example, if the time difference between the current timestamp value being tracked by the processor 442 and the timestamp 454 is longer than a predetermined period (eg, one second), the timestamp 454 is reset to the current timestamp value. Is done. Accordingly, at operation 586, the associated counter value 460 and DoS attack flag 452 may be cleared.

  Since the time stamp 454 may need to be reset very rarely (eg, every second), the count value in DRAM 462 needs to be accessed very rarely at operation 586. It becomes. This is particularly important because DRAM 462 requires a longer access time than SRAM 450. Accordingly, the time required for processor 442 for DoS management is reduced. On the other hand, since the DoS management operation is performed after the packet is excluded in operation 580, the other incoming packets 440 (FIG. 5) are not wasted by the processor 442. As a result, the firewall 420 can filter packets at a line rate (line speed) of gigabits or more without substantially delaying processing of other legitimate packets during a DoS attack.

  In operation 560, the packet may have a DoS entry that is present in CAM 444 but the associated DoS attack flag 452 is not set. In operation 562, the packet is allowed to pass through the firewall 420. If necessary, the processor 442 updates the generation information 456 for the matched DoS entry in the CAM 444 at operation 564. For example, the current generation 456 identified (attention) in the SRAM 450 is set to the current generation. If necessary, the processor 442 at operation 564, as described above with respect to FIGS. 6 and 7, when the generation period expires or when the maximum number of generation entries in the current generation reaches a predetermined limit, the current generation. May be changed.

  The counter 460 for the existing DoS entry is incremented at operation 566 and the processor 442 verifies the age of the count value 460 and the associated timestamp 454 at operation 568. In operation 570, if the timestamp value is greater than the timestamp duration value (the timestamp is an expired timestamp), the count 460 and timestamp 454 are reset in operation 572.

  If the time stamp is valid at operation 570, the processor 442 determines at operation 574 whether the counter 460 has exceeded the threshold for DoS attacks. If the counter 460 has not exceeded the threshold for DoS attacks, the processor 442 returns to operation 540 to process the next DoS candidate packet identified for a possible (potential) DoS attack. If the counter 460 exceeds the threshold for DoS attacks, then in operation 576, the DoS attack flag 452 is set.

  Note that in one embodiment, the DoS attack flag 452 is set after the associated packet has passed through the firewall 420. This additional one packet is usually not so detrimental to the operation of the subject machine in the private network 24 (FIG. 3). On the other hand, the ability to pass packets through firewall 420 without having to wait for DoS management operations to complete improves the performance of the firewall. In addition, the operations described above may only be performed on packets that are associated with possible DoS attacks (DoS candidate packets), so the amount of processing required for DoS management and monitoring is all received. Significantly less than other firewall architectures that handle packets for possible DoS attacks.

Implementing DoS within RSP (Implementing DoS in RSP)
Again, with reference to FIG. 5, any processor 442 may be used to implement the firewall system described above. However, to further improve performance, the processor 442 in one embodiment is implemented using the reconfigurable semantic processor (RSP) 100 described above in FIGS. 2A-2C. FIG. 9 shows in more detail how RSP 100 is used to prevent DoS. For ease of explanation, some of the processing components in RSP 100 described above in FIGS. 2A-2C are not shown in FIG.

  Input packet 600 is received in input buffer 140. The DXP 180 has a grammar in the associated parser table 170 (FIG. 2A) that identifies a packet 600 that may be associated with a potential DoS attack (DoS candidate packet). For example, the parser grammar may identify any incoming packet 600 that includes TCP SYN messages, TCP FIN messages, packet fragments, and the like. When the DoS candidate packet is identified, the DXP 180 sends a DoS identification message 602 to the SPU 200. This message 602 activates the SEP code 620 executed by the SPU 200 from the SCT 210. DoS SEP code 620 causes SPU 200 to perform the different DoS operations described above in connection with FIGS. 3-8.

  Memory subsystem 215 contains DRAM 462, CAM 444 and SRAM 450 previously shown in FIG. Array machine context data memory (AMCD) 230 in one embodiment is used to access data in DRAM 462 or SRAM 450 via hash function (hashing function) or content addressable memory (CAM) 444.

  AMCD 230 has a free table 604 that includes bits 605 that are each associated with an entry in CAM 444. All unused entries in CAM 444 are represented as 0 bit 605 in free table 604, and all valid DoS entries in CAM 444 are represented as associated 1 bit 605. The AMCD 320 corresponds to a find first zero (FFZ) instruction from SPU 200 that identifies the first 0 bits in free table 604.

  When it is necessary to identify a location in CAM 444 to load a new DoS entry, SPU 200 executes an FFZ instruction on free table 604. The FFZ instruction returns the position of the first 0 bit in the free table 604. The 0 bit is then used as a pointer to the corresponding entry in CAM 444. SPU 200 loads the destination address and zone for the new packet to the destination location identified in CAM 444.

  As described above in connection with FIG. 6, DoS entries are added to the current generation in CAM 444, while other DoS entries are removed from the new generation. SPU 200 uses generation table 608 to quickly identify which entries in CAM 444 should be removed from the new generation. Each generation in CAM 444 has an associated generation table 608A-D. Each valid DoS entry associated with a particular generation in CAM 444 has a corresponding set of 0 bits in the associated generation table 608. For example, the third entry in CAM 444 contains a DoS entry associated with generation 0. Therefore, the SPU 200 sets the third bit of the generation table 608A to 0.

  If the DoS entry is removed for generation 0, SPU 200 performs an FFZ operation on generation table 608A. The third bit in generation table 608A is identified and then used by SPU 200 to invalidate the corresponding third DoS entry in CAM 444. For example, the SPU 200 sets the third bit in the generation table 608A to 1 and sets the third bit in the free table 604 to 0. Of course, this is just one example of how tables 604 and 608 operate. Other table configurations can be used as well.

  As mentioned above, these DoS management operations that identify valid entries in CAM 444 and which entries to remove from CAM 444 have already been removed by SPU 200. , If the SPU 200 already allows the associated packet to pass through the RSP 100, this can be done.

  The memory subsystem 215 also has a table 606 used by the SPU 200 to identify zones that have already been identified by the policy manager. For example, the packet may have a port number identified by DXP 180. The SPU 200 may compare this port number with the packet tag 610A in the table 606 to identify the zone 610B receiving the packet. Table 606 may include a packet rate 610C associated with each zone for identifying DoS attacks. The timer 612 is used by the SPU 200 to generate a time stamp for each DoS entry in the SRAM 450, and is further used by the SPU 200 to determine when the time stamp period for each time stamp expires. Generation table 614 identifies the current generation.

  The RSP 100 can also identify and discard any packet that has a forged IP address. For example, a set of IP addresses is stored as a multicast destination address. Any received packet with a source address corresponding to the stored multicast address can be detected by the DXP 180 and removed immediately.

  10 and 11 show at a high level how the RSP 100 performs the DoS operations described above. Referring generally to FIG. 9 and with particular reference to FIGS. 10 and 11, in operation 650, DXP 180 analyzes the incoming packet 600. The grammar in parser table 170 is also used by DXP 180 to identify DoS candidate packets in operation 652. At the same time, DXP 180 may instruct SPU 200 to store input packet 600 in DRAM 462 or temporarily hold the packet in input buffer 140. In operation 654, DXP 180 also identifies the destination address for the packet and the zone in which the packet was received.

  Once the DoS candidate packet is identified, DXP 180 signals in operation 656 to load SPU 200 with DoS SEP code 620 associated with the required DoS operation. For example, the SEP code 620 may be associated with a particular type of DoS operation associated with an identified TCP SYN packet or an identified packet fragment.

  The SPU 200 compares the identified destination address and associated zone information with entries in the CAM 444 at operation 658. In operation 660, if there is a corresponding DoS entry in CAM 444, the SPU 200 permits the packet to pass through the firewall in operation 662. This simply means that the SPU 200 continues with any other firewall operations required for the corresponding packet in DRAM 462 before sending the packet to the output buffer 150. That is, if the packet is not yet stored in DRAM 462, SPU 200 may allow that packet in input buffer 140 to be stored in DRAM 462 for further processing. .

  SPU 200 then performs any required DoS management. For example, the SPU 200 reads the table 614 in the AMCD 320 at operation 664 to determine which generation is currently operating for the associated DoS operation. The SPU 200 also reads the tables 604 and 608 and determines where in the CAM 444 new DoS entries are added and which DoS entries are removed from the new generation. In operation 666, SPU 200 updates CAM 444 with the new DoS entry and reads the content at the corresponding memory location in SRAM 450. Finally, in operation 668, SPU 200 updates the time stamp and generation information in SRAM 450 and the count information in DRAM 462.

  Referring to FIG. 11, if the destination address and zone for the packet is already a DoS entry in CAM 444, SPU 200 reads the corresponding memory location in SRAM 450 at operation 700. In operation 702, the SPU 200 checks whether the DoS attack flag is set. If the DoS attack flag is set, the SPU immediately removes the packet from DRAM 462 or input buffer 140 in operation 704. For example, the SPU 200 may set a drop flag in the DRAM 462 indicating that the packet is invalid.

  This invalid packet is not subsequently read from the DRAM 462 and is eventually overwritten with other data. If not already stored in DRAM 462, the packet is removed from input buffer 140. If the DoS attack flag is not set, the SPU 200 immediately releases the packet for further processing in operation 706. For example, the packet may be sent immediately from the input buffer 140 to a specific location in the DRAM 462. If already in DRAM 462, the packet may be passed to another SPU 200 for further firewall processing, or sent to output buffer 150 if no further firewall processing is required. Alternatively, the SPU 200 may send the packet from the DRAM 462 to the recirculation buffer 160 for re-analysis by the DXP 180. For example, the DXP 180 may identify other content associated with other firewall operations in the packet.

In operation 708, the SPU 200 updates the information in the SRAM 450 and, if necessary, increments the associated count 460 in the DRAM 462. SPU 200 then updates any necessary information in tables 604, 606, 608 and 614 in operation 710. SPU 200 then waits for a new SEP instruction 602 from DXP 180.

Integrated firewall / routing management
(Unified Policy Management)
With reference to FIG. 12, the firewall 804 operates between the first network 800 and the second network. The firewall 804 provides various network interface operations. For example, in addition to DoS attack identification and filtering as described above, the firewall performs packet translation between different network formats (eg, between IP version 4 (IPv4) and IP version 6 (IPv6)). Or you may need to perform a translation (Network Address Translation (NAT)) between a public IP address and a private IP address. This firewall 804 may be required to perform other virus detection and security operations as well.

  Other separate network computing devices 806 (eg, routers or switches) require that packets that have passed through the firewall 804 be routed or switched. For example, a packet received from router / switch 806 may then be further sent to other routers or switches 808 that send the packet to other network processing devices in network 812. Similarly, the router / switch 806 may route the packet to an endpoint such as a server 810 or a personal computer (PC) 814.

  The problem with this traditional architecture is that the firewall 804 and the routing device 806 operate autonomously. This requires separate processing and separate memory devices for each device 804 and 806. This not only increases the hardware cost of peripheral devices, but also limits scalability, and may prevent these peripheral devices from processing packets at the required line rate.

  For example, the firewall 804 may be required to monitor all incoming packets for possible TCP SYN packets. As described above, this may require the firewall 804 to identify the destination address for each incoming packet. TCP SYN packets that are not part of the DoS attack are then sent to the router 806. Router 806 must then find the destination addresses of multiple packets 805 received from firewall 804 again to route the packet to the appropriate destination. Accordingly, each network processing device 804 and 806 is required to perform several identical packet processing operations on the same multiple packets. As a result, each device 804 and 806 must maintain a separate packet state, packet buffer, and the like. This limits the overall scalability and processing power of the network processing device, as described above.

  As shown in FIG. 13, another aspect of the present invention processes packets more efficiently using unified policy management (UPM) within a network processing device 820. In one example, the UPM integrates traditional firewall and peripheral operations with packet transmission operations. Until now, this packet transmission operation has been executed by operating different processors independently. In one embodiment, a unique access control list (ACL) table is used by processor 822 to provide a variety of different UPM operations.

  The processor 822 receives the input packet stream 802 and then identifies a predicate set 854 associated with the individual packet 821. This predicate set 854 is depicted in more detail below in FIG. 14, but in general may be any information in the received packet as long as it relates to a firewall operation or a transmission operation. For example, the predicate set 854 may include, but is not limited to, an IP address, a TCP port number, an IP protocol identifier, and the like. In another unique aspect of the present invention, the predicate set 854 is a more advanced open system interconnect (Open System Interconnect) as well as other application layer information (eg, accessory identifiers and other text documents). OSI) layer information (for example, Session Initialization Protocol (SIP) information, Unuversal Resource Locator (URL) information, Simple Mail Transfer Protocol (SMTP) information, Hypertext Transfer Protocol (HTTP) information, File Transfer Protocol (FTP ) Information) etc.

  The access control list (ACL) table 840 is composed of different combinations of predicate sets 850 that may be associated with different UPM operations or other firewall operations. For example, a first set of firewall policies ACL 848 may be associated with different denial of service (DoS) operations that determine whether incoming packets 821 are allowed to pass through network processing device 820. The firewall policy ACL 848 provides other packet translation, authentication and filtering operations that may need to be performed by the network processing device 820 (eg, network address translation (NAT), virus detection and filtering, IP For example, conversion between versions).

  In another particularly unique aspect, the ACL table 840 may have a Forward Information Base (FIB) that associates different destination addresses 844 with different destination port numbers 846. FIB 842 may belong to a separate section of ACL table 840, may be integrated with a portion of firewall policy ACL 848, described in more detail below, or both.

  The ACL entry in table 840 also includes an action 852 that instructs processor 822 to allow or deny the associated packet from passing through network processing device 820. Other ACL actions 852 may direct the associated packet to a specific destination or to the processor 822 for further processing. In other situations, the firewall policy action 852 may instruct the processor 822 to route the associated packet 821 to a particular output port 846.

  The combination of firewall policies ACL 848 and FIB 842 in table 840 provides a variety of different UMP operations that are not normally performed within the same network processing device 820. For example, a small subset of UPM operations includes removing packets 838 as described above in connection with DoS or intrusion detection. The network processing device 820 can also modify or tag the packet 824 before it is sent to the destination address. For example, the packet 824 may be encapsulated into a specific channel 826 or tagged with a specific QoS level.

  In other UPM actions, an entry in the ACL 840 may instruct the processor 822 to record statistics of any packets 830 that have been passed or removed in the server 828. As briefly described above for other UPM operations, an entry in the ACL table 840 may cause the processor 822 to send the packet 834 to a different subnetwork 832 or device 836 according to different firewall policy metrics. For example, only packets 834 containing a special HTTP session may be routed to server 836 and all remaining packets may be routed to subnet 832.

  In the description above in connection with FIG. 13 and the further description below, routing and switching are used interchangeably. One skilled in the art will be aware that UPM system 820 can perform integrated layer 2 switching and / or layer 3 routing operations combined with other firewall policy metrics, as described in more detail below. You will understand that.

Access control list
FIG. 14 shows an example of an entry in the ACL table 840 described above with reference to FIG. Any combination of predicates and actions can be used in the ACL table 840, and FIG. 14 shows only a few examples. In one embodiment, the processor 822 (FIG. 13) concatenates one or more ACL predicates and uses the concatenated predicate set 854 as an address entry to a CAM having an ACL table 840. Actions that match actions for the first entry in the ACL table 840 and that match the predicate set 854 presented by the processor 822 are output by the CAM.

  The first entry 860 in the ACL table 840 includes a destination IP address predicate 860A, a source IP address predicate 860B, a TCP port number predicate 860C, an established TCP session predicate 860D, and an allow action 860E. In this example, ACL 860 is the first entry in ACL table 840. Of course, any sequence and combination of ACL entries may be loaded into the ACL table 840.

  The associated action 860E is output from the ACL table 840 when the predicate set 854 supplied by the processor 822 matches the predicates 860A-860D. In this example, ACL table 840 indicates that the destination IP address for input packet 821 (FIG. 13) matches the value in predicate 860A and the source IP address for input packet 821 (FIG. 13) is in predicate 860B. When the value matches, the permission action 860E is output. The IP addresses identified within predicates 860A and 860B may include only subnet addresses associated with complete source and destination IP addresses. Other bits in the IP address may be masked and output as a “ignore” value, similar to the way that the subnet mask is currently used in the routing table.

  To match ACL entry 860, packet 821 (FIG. 13) must also have an associated TCP port number corresponding to predicate 860C. Note that no source qualifier and destination qualifier are associated with the TCP port number predicate 860C. This means that either the same source TCP port number C or the same destination TCP port number C in the packet 821 matches the predicate 860C. Finally, in order to match ACL entry 860, input packet 821 must be part of an already established TCP session as required by established TCP predicate 860B. Predicate 860D may simply be a flag in predicate set 854 that is set by processor 822 when it is determined that input packet 821 is part of an already established TCP session. As such, ACL entry 860 will not match a packet containing a TCP SYN message attempting to establish a new TCP session.

  The next two ACL entries 862 and 864 are associated with the firewall policy associated with denial of service (DoS) attacks. In order to match ACL entry 862, the address in incoming packet 821 must match destination IP address predicate 862A and source IP address predicate 862B, respectively. In addition, input packet 821 must also be a TCP packet as required by type TCP predicate 862C. ACL 862 associates a specific destination IP address and source IP address for the TCP packet with a TCP DoS action 862D corresponding to the specific zone as described above in connection with FIG. Accordingly, action 862D may instruct processor 822 to perform a DoS operation as described above in connection with FIGS. 4-11 using a threshold for a particular packet rate corresponding to zone 1. .

  ACL entry 864 is associated with TCP DoS action 864D and includes a destination IP address predicate 864A identical to destination IP address predicate 862A. However, the predicate 864B includes a source IP address C different from the source IP address predicate 862B. This corresponds to packets received from different network interfaces. Thus, ACL action 864D is for TCP DoS operations for different corresponding zones 3. Therefore, the processor 822 that has received the action 864D may use a threshold for a different packet rate in order to determine a DoS attack.

  ACL entry 866 relates to conversion from Internet Protocol version 4 (IPv4) to Internet Protocol version 6 (IPv6). For example, the input packet 821 may be received on a network that operates using IPv6. On the other hand, the network operating on the other side of the network processing device 820 may use IPv4. Accordingly, the network processing device 820 may need to convert all IPv6 packets to IPv4 packets.

  The IP type field in the IP header of the input packet 821 recognizes the packet as IPv4 or IPv6. The processor 822 extracts the destination IP address and IP version identifier in the IP type field from the packet 821 and matches the format of this information to the format of the predicate set 854 applied to the ACL table 840. If predicate set 854 matches predicates 866A and 866B in ACL entry 866, processor 822 receives XLATEIPv6 action 866C. The XLATEIPv6 action 866C instructs the processor 822 to convert the input IPv6 packet 821 to IPv4 using a specific rule 5. For example, the IPv6-rule 5 may encapsulate the IPv6 packet into the IPv4 header in the processor 822 or divide a part of the IPv6 address into different company codes and host codes included in the IPv4 header. This conversion between IPv6 and IPv4 is shown in more detail in FIG.

  ACL entries 868 and 870 are associated with policies based on routing or switching operations. ACL entry 868 includes forwarding information base (FIB) routing criteria 868A and 868C combined with firewall policy metrics 868B. Similarly, ACL entry 870 includes FIB routing criteria 870A and 870C combined with firewall policy metrics 870B. These ACL entries 868 and 870 allow the network processing device 820 to route or switch packets to different ports based on both IP destination address and firewall policy metrics.

  For example, ACL entry 868 may include send action 868C. This send action 868C instructs the processor 822 to output the output packet 821 to port 3 for TCP packet type 868B having destination IP address G. On the other hand, the ACL entry 870 instructs the processor 822 to send a UDP packet type 870B having the same destination IP address to a different output port 4. Routing ACLs based on these policies may be used, for example, to route TCP bus threats to specific processing devices for further DoS processing. On the other hand, the UDP packet is routed to the destination address corresponding to the predicate 870A. Of course, the entries in ACL table 840 are just one example of the various ACLs that can be used to implement integrated policy management.

  FIG. 15 illustrates in more detail how the network processing device 820 of FIG. 13 implements UPM. The processor 822 receives the input packet 821 at operation 880 and generates a predicate set 854 from the input packet at operation 882. For example, the processor 822 matches the format of a predetermined set of IP packet fields with the format of the predicate in a predetermined order. If one of the IP packet fields is not present in the incoming packet 821, the next packet field in the list is extracted and then extracted before and combined with the formatted predicate.

  The processor 822 applies the predicate set 854 to the ACL table 840 at operation 884 and receives and executes the action sent back from the matched predicate entry in the ACL table 840 at operation 886. For simplicity, only three action categories are shown as returning from the ACL table 840 in FIG. However, any number of different actions can be configured in an ACL entry. If, in operation 892, an exclude (remove) action 852 is sent back from the ACL table 840, the processor 822 discards the packet in operation 900. The processor 822 may record any statistical information regarding the excluded (removed) packet until operation 902 begins operation on the next incoming packet 821.

  If pass action 852 is sent back from the ACL table at operation 890, processor 822 may route or switch the packet according to FIB 842 (FIG. 13) at operation 898. Pass action 890 may include a forwarding port number, but may instruct processor 822 to re-access ACL table 840 to obtain forwarding port information.

  If a steer ACL action 852 is sent back from the ACL table at operation 888, the processor 822 performs the firewall operation associated with this ACL action at operation 894. If applicable, processor 822 may send the packet in accordance with associated firewall policy metrics at operation 894. For example, as described above in connection with FIG. 14, steer ACL action 852 causes processor 822 to send a TCP packet over a specific port to a network processing device that is looking for DoS attacks. You may order.

  In other manners, steer ACL action 852 may instruct processor 822 to perform further firewall processing on the packet at operation 888. For example, steer ACL action 852 may instruct processor 822 to perform network address translation (NAT). In response, the processor 822 may extract another predicate set 854 from the packet 821 at operation 882, if necessary, and reapply the new predicate set 854 to the ACL table 840 at operation 884. In accordance with the next ACL action 852 sent back from the ACL table 840, the processor 882 may remove, pass or direct the packet upon completion of the NAT operation.

Forwarding Packets According to Upper Layers
FIG. 16 shows an example of another way to integrate routing and switching operations with firewall policy management. The ACL table 910 is similar to the ACL table 840 of FIG. However, the ACL table 910 combines the forwarding information base (FIB) with policy metrics 910D for layer 4 and policy metrics 910E for layer 7, respectively.

  An important point to note is that any combination of policy management metrics can be added to a conventional routing and switching forwarding table simply by adding a new predicate to table 910. Another important point to note is that routing and switching decisions are traditionally limited to Layer 2 and Layer 3 of the Open Systems Interconnection (OSI) Internet model. For example, a switch or a router normally makes a packet transfer determination based on a packet port number and an IP address.

  The ACL table 910 combined with the network processing device architecture shown in FIG. 13 can allow forwarding decisions to be made based on information contained in higher OSI layers. For example, some packet forwarding decisions in the ACL table 910 include information in the data link layer (layer 2), information in the network layer (layer 3), information in the forwarding layer (layer 4), and application layer (layer Based on information in 7). Of course, the transfer determination may be based on any other OSI layer.

  For further explanation, the ACL table 910 includes an IP destination address predicate 910A. This IP address predicate 910A is used to send each packet to a different output port identified by action 910C. The conventional subset mask in predicate 910B is used to mask bits in destination IP address predicate 910A. For example, in the first ACL entry 912, only the first three subnet fields “10.0.0” of the address are compared with the destination IP address for the incoming packet 821. In the ACL entry 916, only the first subnet field “10” is compared with the destination IP address for the incoming packet 821.

  In this example, the transfer determination is performed based on the destination IP address 910A in addition to the predicate 910D for layer 4 or the predicate 910E for layer 7. For example, an input TCP packet having a destination IP address “10.0.0.x” (x represents “ignore”) is routed to the output port 15. In another example, the input UDP packet having the destination IP address “10.0.0.x” is routed to the output port 5.

  TCP and UDP identifiers for incoming packets are identified by processor 822 at the same time processor 822 identifies the destination IP address during initial packet processing. The destination IP address and TCP or UDP identifier are then compared with entries in the ACL table 910 to determine the appropriate output port to send the packet. This shows an example of how a packet is forwarded based on layer 4 metrics.

  The ACL entry 914 is a conventional forwarding table entry, and sends a packet to a specific output port 2 when the input packet includes the subnet field “12.0.x.x” in the destination IP address.

  The ACL entry 916 makes a routing decision based on the destination IP address and layer 7 session internet protocol (SIP) metrics. For example, a non-SIP packet having an IP destination address “10.x.x.x” is routed to the output port 7 in the network processing device 820. On the other hand, the SIP packet having the IP destination address “10.x.x.x” is routed to the output port 4. This is useful for packets that contain Voice over IP (VoIP) SIP signals that need to be routed to a particular network processing device (eg, a SIP proxy server). Other non-SIP IP traffic is routed in the conventional manner according to the destination address. The SIP identifier used to be compared with the SIP predicate 910E in the ACL entry 916 is a flag generated by the processor 822 when the packet contains a SIP message.

  ACL entry 918 shows another example where routing is based on layer 7 metrics. This type of routing application may be used to access a web server, in which case it may be used to efficiently route subsequent URL packets to different locations. With respect to both FIG. 16 and FIG. 17, the enterprise may operate a web server 934. This web server 934 is accessed by different users 930 via the Internet 932. The web server 934 may display to the user 930 a web page 936 that provides different links to different business services. For example, the first URL link 938 connects user 930 to customer support, the second link 940 connects user 930 to car sales, and the third link 942 connects user 930 to furniture sales. You may connect.

Linked web servers that support each of these different data 938, 940, and 942 may be located at different Internet locations, but are not limited to, but may be located at different geographic locations. May be. For example, the customer support server 944 may be located at the Atlanta headquarters, the car sales server 946 may be located in Detroit, and the furniture sales server 949 may be located in Paris, France. ACL table 910 (FIG. 16) allows user 930 to more efficiently link URLs 938, 940 and 942
Used to connect to.

  For example, when the user clicks on the customer support link 938, the web server 934 generates a packet with the destination IP address “10.10.x.x” that includes the URL “Http: // DEST1”. The router 935 in FIG. 17 compares both the IP destination address and the URL with the entry in the ACL table 910. As such, router 935 routes the packet to customer support server 944 via output port 1. In addition, the router 935 receives a plurality of packets having the same destination IP address “10.10.x.x” except for those including the URL “fttp: DEST2”. The router 935 routes these packets to the automobile server 946 via port 2 accordingly. Packets with destination IP address “10.10.x.x” and associated URL / DEST3 are routed to furniture server 948 via port 3. This provides more direct routing to the required IP destination.

Unified Policy Management Using RSP (Unified Pollicy Management Using RSP)
As described above, integrated policy management (UPM) can be implemented within a conventional processor and computer system architecture, as shown in FIG. However, to further improve performance, UPM may be implemented in a reconfigurable semantic processor (RSP) similar to RSP 100 as previously shown in FIGS. 2A-2C.

  18 and 19, in operation 1000, DXP 180 in RSP 100 parses the packet in input buffer 140 and identifies all ACL predicates 954 needed to perform the UPM operation. Execute grammar. In operation 1002, the DXP 180 sends an instruction to the SPU 200 and activates the SEP code 212. SEP code 212 causes SPU 200 to convert the format of ACL predicate 954 to the format of predicate set 956. This predicate set 956 is then entered into the ACL table 979. In this example, part or all of the ACL table 979 is stored in one or more CAMs 220.

  The SPU 200 may combine any number of ACL predicates 954 with the ACL predicate 956 according to the grammar executed within the DXP 180 and the associated SEP code 212 invoked by the DXP 180. For example, the grammar in DXP 180 may identify a packet destination address and an ACL predicate 954 for the packet source address. Another predicate 954 may be identified for IPv6 to IPv4 translation or TCP DoS operations. If the DXP identifies that it is an IPv6 packet, the DXP 180 may activate the SEP code 212 that causes the SPU 200 to perform the task of combining the destination IP address predicate and the IPv6 packet type predicate. Similarly, if a TCP packet is identified, the DXP 180 may activate the SEP code 212 that causes the SPU 200 to perform the task of combining the destination IP address predicate 954 and the TCP packet type predicate 954 in the predicate set 956.

  In operation 1004, the SPU 200 places the ACL predicate set 956 in the ACL table 979 in the CAM 220. The SPU 200 processes the packet according to the ACL action 952 sent back from the CAM 220 in operation 1006. In operation 1010, the ACL action 252 may be a simple exclude instruction that causes the SPU 200 to discard the packet currently stored in DRAM 280 (FIG. 2A). In operation 1012, ACL action 952 may be an instruction that causes SPU 200 to send a packet in (stored in) DRAM 280 to output buffer 150.

  In another situation, ACL action 952 may cause SPU 200 to further activate SEP code 212 that may be associated with a particular firewall operation. For example, a set of ACL entries 980 may be associated with different firewall operations. ACL entry 980A may be associated with an intrusion detection system (DIS) license operation, described in more detail below. Another ACL entry 980B is described in a co-pending application entitled “Method and Apparatus for Intrusion Detection in Network Processing Devices” and may be associated with the IDS operations described therein. This co-pending application is US Patent Application No. 11 / 125,956 entitled “Intrusion Detection System” filed on May 9, 2005, the content of which is incorporated herein by reference. It shall be incorporated.

  Other ACL entries 980C-F may be associated with other firewall operations. Other firewall operations include network address translation (NAT), IPv4-IPv6 translation, denial of service (DoS) for TCP sessions, and DoS for packet fragments, as described above or described in more detail below. is there.

  For example, the SPU 200 may place in the CAM 220 an ACL predicate set 956 that matches the ACL entry 880E corresponding to the DoS TCP packet. The action included in the ACL entry 980E may be a pointer 982 pointing to the semantic code table 210. SPU 200 may activate and execute the SEP code at pointer location 982 in operation 1008 of FIG. In this example, SEP code 212 at location 982 causes SPU 200 to perform some or all of the TCP DoS operations as described above in connection with FIGS.

  After the TCP DoS operation initiated by the action in ACL entry 980E is completed, SEP code 212 may cause SPU 200 to perform any of a variety of other firewall operations. For example, as represented by path 1014, SPU 200 may be instructed to create another set of predicates 956 from ACL predicates 954 identified by DXP 180. The new predicate set 956 may then be re-entered in the ACL table 979 to perform other firewall operations. The SEP code 212 may instruct the SPU 200 to remove the packet as represented by path 1016 in FIG. 19 or send the packet to the output port as represented by path 1018.

  As described above in connection with FIGS. 13-17, RSP 100 may also implement integrated policy management. This integrated policy management integrates both routing and switching operations with other firewall policy management operations. Accordingly, the CAM 220 may include a forwarding information base 984 that includes an entry having a destination IP address and an associated destination port number. As described above in connection with FIG. 16, the FIB table 984 includes a conventional FIB entry 987 and other entries 986. These conventional FIB entries 987 and other entries 986 route packets according to both the destination address and other firewall policy metrics 988.

  The RSP 100 can easily switch between functions of a firewall function, a conventional router or switch function, or a combination of both. For example, path 990 (FIG. 18) in semantic code table 210 represents switching RSP 100 from DoS TCP operation to routing operation. The first predicate set 956 sent by the SPU 200 to the CAM 220 may match the DoS TCP entry 980E. Once execution of the SEP code 982 associated with the DoS TCP operation is complete, the SPU 200 may be instructed to send another set of predicates 956 to the CAM 220. New predicate set 956 may match entries 986 or 987 in FIB 984. An entry in FIB 984 may instruct SPU 200 to activate SEP code 992 in SCT 210 that performs conventional or UPM routing operations.

Alternatively, the first predicate set 956 placed in CAM 220 may match FIB entry 986 instead of initially matching DoS TCP entry 980E. The resulting action contained within entry 986 may instruct SPU 200 to send the associated packet via the output port to another device providing TCP DoS operation.

Network address translation (NAT) / port address translation (PAT)
With reference to FIG. 20, the RSP 100 may also be programmed for NAT / PAT operation. NAT / PAT operation refers to the IP address and / or port number of a packet passing through the firewall 1062, and the public IP address used to transport the packet over the public network 12. An operation that translates between private IP addresses that are used to carry packets over the private network 24.

  There are typically multiple unique private IP addresses associated with different network processing devices operating within the private network 24. On the other hand, one or a few public IP addresses are used to represent multiple private IP addresses. This translation from a public address to a private address prevents the internal machines in the private network 24 from being identified (protect the identity) and is mapped to multiple private addresses in the private network 24 Reduce the number of public addresses required.

  In another embodiment, one or more private IP addresses have a unique public IP address associated with them. This does not necessarily reduce the number of public IP addresses, but allows the firewall 1062 to hide the corresponding private IP addresses from the public network 12. This one-to-one mapping allows the firewall 1062 to reconfigure multiple public IP addresses to different network devices in the private network 24.

  The RSP 100 converts the public IP address 1058 of the input packet 1061 into a private IP address 1074. Private IP address 1074 is then used to route internal packet 1076 to the associated network processing device 1078 in private network 24. RSP 100 also receives a packet 1072 containing a private IP address 1070 from a local device 1078 in private network 24. If packet 1072 is directed to endpoint 1056 in private network 12, RSP 100 translates private IP address 1070 to public IP address 1052. This public IP address 1052 is used to route the packet 1050 to the endpoint 1056 via the public network 12.

  To explain in more detail, a device 1078 operating in the private network 24 may first send the packet 1072 to a destination in the public network 12 via the firewall 1062. The RSP 100 receives the packet 1072 and translates the private source IP address 1070 into a public IP address 1052 associated with the firewall 1062. In addition, a specific port number 1054 may be assigned to the output packet 1050 by the RSP 100. The RSP 100 then updates the lookup table 1064 by adding a private IP address entry 1068 and a corresponding port number entry 1066.

  The device 1056 that has received the output packet 1050 may send the packet 1061 back to the local device 1078. The device 1056 uses the public IP source address 1052 and port number 1054 in the packet 1050 as the destination address 1058 and port number 1060 of the packet 1061 sent back to the local device 1078. The RSP 100 maps the destination address 1058 and the port number 1060 in the packet 1061 to the port number entry 1066 in the search table 1064. The RSP 100 identifies the matching port number entry 1060 and the private IP address entry 1070 in the lookup table 1079 corresponding to it.

  RSP 100 replaces the public destination IP address 1058 in packet 1061 with the private IP address 1070 identified from the lookup table. During translation between private and public addresses, RSP 100 may de-assemble the packet, generate a checksum value, and then reassemble the packet.

  FIGS. 21-23 show in more detail an example of how the RSP 100 performs the NAT / PAT conversion described above. DXP 180 (FIG. 21) parses the incoming packet received from private network 24 and identifies private IP source address 1070 in operation 1100 (FIG. 22). DXP 180 signals SPU 200 to load microinstructions from SCT 210 in operation 1102. This microinstruction relates to converting a private IP source address 1070 to a public IP source address.

  The SPU 200 generates a public IP address and port number for the packet in operation 1104. The public IP address is usually the IP address assigned to the firewall 1062 (FIG. 20). In operation 1106, SPU 200 loads the 1072 port number of the packet and the corresponding private IP address into lookup table 1079. FIG. 21 shows an example of how the search table 1079 using the CAM 220 and SRAM 221 is implemented. The SPU 200 stores the port number associated with the output packet 1050 into the CAM location 220A via the AMCD 230 and stores the corresponding private IP address 1070 as the entry 221A in the SRAM 221.

  In operation 1108, the SPU 200 replaces the private IP source address 1070 of the packet 1072 containing the associated port number 1054 (FIG. 20) with the public source IP address 1052. SPU 200 may also generate a new checksum for this output packet 1050 at operation 1110. Eventually, SPU 200 sends packet 1050 with public IP address 1052 and port number 1054 from DRAM 280 to output port 152 at operation 1112.

  FIG. 23 illustrates how the RSP 100 translates the public destination IP address of an incoming packet into a private IP address. In operation 1120, the DXP 180 parses the incoming packet 1061 received from the public network 12 and identifies the associated 5-tuple address. In operation 1122, DXP 180 signals SPU 200 to load microinstruction 212 (FIG. 2A) from SCT 210. This microinstruction relates to translating the public IP destination address 1058 and port number 1060 into the corresponding private IP destination address 1074.

  The SPU 200 compares the public destination IP address 1058 and port number 1060 from the incoming packet 1061 with the IP address and port number entry 220A in the lookup table 1079 in operation 1124. For example, the SPU 200 uses the destination port number as an address to the CAM 220. The address in section 220A that matches the port number is used as a pointer to section 221A in SRAM 221. In operation 1126, the SPU 200 reads the private destination IP address identified from the SRAM 221 and replaces the packet's public IP destination address 1058 with the identified private IP address 1074. In operation 1128, SPU 200 also generates a new checksum for the converted packet. Eventually, SPU 200 outputs packet 1076 from DRAM memory 280 to private network 24 via output port 152 in operation 1130.

The RSP 100 may be configured to perform other modification and monitoring operations on the same packet both before and after the NAT / PAT operation. In this example, SPU 200 may send a packet with a new private IP address 1074 from DRAM 280 back to recirculation buffer 160 (FIG. 2A) for further firewall processing. Other firewall operations are then performed on the packets in recirculation buffer 160.

IPv6 / IPv4 Translation (IPv6 / IPv4 Translation)
With respect to FIG. 24, firewall 1062 may need to translate between Internet Protocol version 4 (IPv4) and IP version 6 (IPv6) or between other IP protocol versions. For example, the first network 1150 may use IPv6 while the second network 1160 may use IPv4. Therefore, the firewall 1062 needs to convert the 128-bit address area 1158 of the IPv6 packet 1156 into the 32-bit address area 1170 of the IPv4 packet 1172. Information other than the header and payload may also need to be converted between IPv4 and IPv6.

  In one example, the firewall 1062 converts the IPv6 packet 1156 into an IPv4 packet 1172. In this example, the firewall 1062 encapsulates the IPv6 packet 1156 and enters the IPv4 tunnel 1164. For the reverse conversion, the firewall 1062 converts the IPv4 packet into an IPv6 packet, or encapsulates the IPv4 packet 1172 and enters the IPv6 tunnel. These different transformations depend on the type of IP network connected by the firewall 1062.

  The incoming packet 1158 may include a media access control (MAC) header 1180, an IP header 1182 and a TCP header 1184. The type field 1186 specifies the IP version number for this IP header 1182. With reference to FIGS. 21, 24 and 25, DXP 180 (FIG. 21) parses incoming packet 1158 and identifies a particular IP version in type field 1186 at operation 1200 (FIG. 25). If the type field 1186 indicates IPv4 and IPv4 is also used in the network connected to the opposite end of the RSP 100, the DXP 180 will do some SEP for IP version conversion within the SPU 200. You don't have to start the code.

  However, if the type field 1186 indicates an IP version that is different from the IP version used at the opposite end of the RSP 100, the DXP 180 sends the SPU 200 to the SCT 210 (FIG. 2A) in operation 1202. Signals to load microinstruction. This microinstruction is for converting an input packet to an IP version of another network. In this example, the microinstruction causes the SPU 200 to convert an IPv6 packet into an IPv4 packet.

  The SPU 200 applies, in operation 1204, matching the IPv6 address identified by the DXP 180 with the section 220B in the CAM 220 (FIG. 21) associated with the 128-bit IPv6 address. The CAM 220 addresses the corresponding entry in the section 221B of the SRAM 221 that contains the corresponding 32-bit IPv4 address (address). The SPU 200 reads the IPv4 address output from the SRAM 221 in operation 1206, and replaces the IPv6 address in the packet with the specified IPv4 address in operation 1208. In the other way, the SPU 200 encapsulates the IPv6 packet and puts it into the IPv4 tunnel using the specified IPv4 address in the SRAM 221. At operation 1210, the SPU 200 generates a new checksum and, at operation 1212, sends either the translated IPv4 packet or the IPv4 tunnel containing the IPv6 packet from the DRAM 280 to the output port 152.

  A process similar to that described in FIG. 25 can be used to convert an input IPv4 packet into an IPv6 packet. The same process as described above can be used to convert between any other versions of IP packets that may be born in the future. The RSP 100 simply identifies the new IP version number and then activates a set of SEP codes. This SEP code is used by the SPU 200 to convert packets between the first IP version and the second IP version.

  IP version conversion can also be combined with the integrated policy management operations described above in connection with FIGS. 13-19. For example, the RSP 100 can route a packet identified as being of a different IP version to an associated different IP subnet that may support the identified IP version within the packet.

  One of the many unique features of the RSP 100 is that additional packet processing operations do not require additional hardware and without substantially increasing the complexity of the software or processing state. It can be done. For example, the same RSP configuration for NAT / PAT conversion as that shown in FIG. 21 can be used for conversion between IPv4 and IPv6. IPv6 to IPv4 address mapping 220B and 221B and vice versa IPv4 to IPv6 address mapping 220C and 221C, alongside IP public address 220A and IP private address 221A used for NAT / PAT translation, respectively (alongside) It may be stored in the CAM 220. In addition, parsing a huge IPv6 packet requires only a few additional cycles, so parsing a large 128-bit IPv6 header is a whole for the RSP 100. It only increases the rate of packet processing for a few cycles.

  By utilizing common DXP parsing, multiple different firewall operations can be performed more efficiently within the same RSP 100. For example, in FIG. 21, DXP 180 may perform several identical analysis operations for both NAT / PAT operations and IPv6 / IPv4 operations. For example, IP addresses are identified by DXP 180 for both NAT translation and IP version translation. Therefore, the same DXP address analysis result can be used for both NAT conversion and IP version conversion. Therefore, DXP 180 requires a small number of grammars in addition to NAT grammars.

  The RSP 100 is also not limited to processing any particular data size. As such, any IPv4 or IPv6 operation and any other IP version or address size processing that may be created in the future can be easily implemented using the same RSP architecture 100. RSP 100 adds these minimal new grammars to DXP 180, adds additional SEP code to be executed by SPU 200, and adds a few additional entries in CAM 220 and SRAM 221. Can be configured to handle IP version and address size.

  This is the opposite of traditional hardware architecture that requires a complete redesign to efficiently process IPv6 packets instead of IPv4 packets. For example, in a conventional processor (in), the data path size, register size, and logic elements would need to be redesigned for a larger 128-bit IPv6 address.

Virtual Private Network (VPN) Integration
FIG. 26 shows an example of how a virtual private network (VPN) tunnel 1207 is established over the Internet 1212. Computer 1216 requests file 1200 from enterprise server 1202. The server 1202 accesses the file 1200 and sends it back as an IP packet 1204 to the remote user 1216 via the VPN / firewall 1206.

  The firewall 1206 uses the IP security protocol encapsulation security payload (IPSec ESP) trailer 1210 and IP security protocol authentication header (IPSec AH) 1208 (such as IP Source Protection (IPSG)), for example. Encapsulate. These IPSec headers 1208 and 1210 are located in the layer 3 protocol. These headers are placed after the IP header and before the upper layer protocol header in the transport mode, and before the encapsulated IP header in the tunnel mode. The IPSec header 1210 and the AH header 1208 can be used individually or in combination with each other.

  The IPSec ESP header 1210 contains the information necessary to decrypt the received packet and, in some cases, the authentication digest required to authenticate the received packet 1204. . The IPSec AH header 1208 includes an authentication digest necessary for authenticating the received packet 1204. If IPSec packet 1218 includes IPSec AH header 1208, the authentication digest is located in the Layer 3 protocol. Otherwise, in IPSec ESP mode, only the authentication digest is placed behind the packet payload in the ESP trailer 1210.

  The IPSec packet 1218 is sent to the computer 1216 via the Internet 1212 as a VPN tunnel 1207. The VPN / firewall 1214 decrypts the IPSec packet 1218 according to the information in the AH header 1208 and the ESP header 1210. The decrypted IP packet 1204 is then transferred to the computer 1216. The VPN / firewall 1214 may perform any other firewall operation on the decrypted packet 1204 as described above.

  FIG. 27 shows in more detail the operations performed by the RSP 100 in the VPN / firewalls 1206 and 1214. RSP 100 first performs preliminary (initial) DoS filtering 1220 to filter IPSec packets 1218 received that exceed the threshold for the DoS attack rate. DoS filtering 1220 can filter any non-IPSec packet in a manner similar to that described above in connection with FIGS. 4-11.

  A security association (SA) search operation 1222 extracts an IP address, a packet session identifier, and a plurality of security parameter indexes (SPIs) 1226 from the IPSec packet 1218. These identify the required decryption and authentication techniques used by RSP 100. The SPI 1226 and other IP information is sent to a search table 1224 that is similar or identical to the search table and ACL table described above in connection with DoS, UPM, NAT conversion and IP version conversion. The search table 1224 sends back the decryption key 1228, the decryption algorithm identifier 1230, and the authentication algorithm identifier 1232.

  The associated decryption algorithm converts the bits in IPSec packet 1218 from an encrypted state to an unencrypted state. Examples of decryption algorithms include Data Encryption Standard (DES), Triple Data Encryption Standard (T-DES), Advanced Encryption Standard (AES), and CBC mode T-DES. The authentication algorithm performs a hash operation on the data to verify whether the bits in the IP packet 1204 are the same as the bits originally sent from the server 1202. Examples of authentication algorithms include MD5 and SHA1.

The results of SA search 1222 are provided to decryption operation 1234. Thereafter, decryption operation 1234 decrypts IPSec packet 1218 into original IP packet 1204. Further details on how SA search 1222 and decryption operation 1234 are performed are described in the following continuation application.
・ US patent application No. 11 / 127,445 filed on May 11, 2005
"MULTIPROCESSOR ARCHITECTURE WITH FLOATING DECRYPTION / ENCRYPTION / AUTHENTICATION BLOCKS" with fluid decryption / encryption / authentication blocks
・ US patent application No. 11 / 127,443 filed on May 11, 2005
"IP Security Decryption / Encryption / Authentication (IP SECURITY DECRYPTION / ENCRYPTION / AUTHENTICATION)"
・ US patent application No. 11 / 127,468 filed on May 11, 2005
"PIPELINED IP SECURITY DECRYPTION / ENCRYPTION / AUTHENTICATION"
・ US patent application No. 11 / 127,467 filed on May 11, 2005
“DEA engine with DMA interface”
These applications are hereby incorporated by reference into the present application.

  DXP 180 parses the incoming packet and identifies IPSec packet 1218 according to the identified IP type field. Subsequently, the grammar in DXP 180 identifies the SPI 1226 that is used by DXP 180 to activate SEP code 212 (FIG. 2A). The SEP code 212 instructs the SPU 200 to place the SPI 1226 in the ACL in the CAM 220 and then execute the decoding 1234 according to the output result from the CAM search. For example, the decryption key 1228, the decryption algorithm identifier 1230, and the authentication algorithm identifier 1232 can be stored in the same CAM / SRAM structure as previously described in connection with FIG. The output result from the CAM search is an ACL action that indicates an additional SEP code. This additional SEP code executes the decryption algorithm associated with identifier 1230 and the authentication algorithm associated with identifier 1232 using decryption key 1228.

  If unencrypted packets (for example, packets with the same 5-tuple) are received for the same IPSec session, the corresponding ACL entry in CAM 220 will exclude these packets to SPU 200 You may order. This prevents an unauthorized attacker from taking over the VPN session 1207.

  The decrypted IP packet is then sent to one or more different post-decryption operations. These post-decryption operations may include a transfer operation 1236 (this transfer operation 1236 may be similar to the operations in the UPM application described above). For example, the RSP 100 simply forwards the decrypted packet 1204 to the destination address in forwarding operation 1236 without any further firewall operation using the FIB described above in connection with FIGS. 13-19. May be.

  In other ways, the output from the decoding operation 1234 may pass through the second DoS filtering 1238. The second DoS filtering 1238 can perform DoS detection and DoS filtering on the currently decoded IP address and other identifiers in the IP packet 1204. For example, some predicates used for DoS operations and other UPM operations are currently decrypted. The decrypted predicate is identified and then used to perform a second DoS operation 1238, UPM operation, or some other firewall operation as required.

  For additional firewall operations, a co-pending US patent application entitled "TCP ISOLATION WITH SEMANTIC PROCESSOR TCP STATE MACHINE" filed July 14, 2005. TCP proxy operation 1240 disclosed in No. 11 / 181,528 may be included. The content of this continuation application is hereby incorporated by reference into the present application. In another feasible post-decryption operation 1242, RSP 100 converts the decrypted IP address to a public or private IP address as described above in connection with the NAT / PAT application. May be.

  Depending on which firewall operation was performed and the type of decrypted IP packet 1204, RSP 100 can perform any combination of post-decryption operations 1236, 1238, 1240 or 1242. Also good. Of course, any other firewall operation described above can also be performed.

Licensing with Firewall Policy Management With respect to FIG. 28, the ACL table 1506 combined with RSP 100 can be used to efficiently allocate antivirus (AV) licenses. Currently, AV licenses are assigned to individual machines 1514. The problem is that it is difficult for system administrators to manage these licenses. For example, for each new machine 1514 added to the network, additional licenses must be purchased and AV software installed. Once the license agreement is over, the network administrator must reinstall AV software on individual machines or re-enable those software. In addition, any uploads to AV software must be loaded into each computer 1514 individually.

  RSP 100 provides centralized license management. For example, AV software 1504 can be executed by RSP 100 in firewall 1502 in a manner similar to that described in the following co-pending US patent application: This co-pending application is US Patent Application No. 11 / 125,956, filed May 9, 2005, entitled "Method and Apparatus for Intrusion Detection in Network Processing Devices". . In other ways, the AV software 1504 may be executed by a conventional network processing device.

  Regardless of the above, RSP 100 determines which sub-networks 1520, 1522 and 1524 have AV licenses, and accordingly only packets destined for those licensed sub-networks. Apply AV software 1504. As shown in FIGS. 28 and 29, the RSP 100 receives a packet 1525 from the public Internet 1500 with a specific destination address 1527. The DXP 180 in the RSP 100 identifies the IP destination address 1527 and sends it to the SPU 200, which then causes the SPU 200 to execute the SEP code. In particular, this SEP code confirms whether or not the sub-network corresponding to the destination address 1527 has an AV license.

  For example, the SPU 200 sends the destination address 1527 of the packet to the CAM 220. This destination address 1527 may match (match) predicate 1528 in ACL entry 1526. Action 1530 associated with ACL entry 1526 indicates that there is a license for subnetwork 1522 (FIG. 28) associated with packet destination address 1527 that matches ACL predicate 1528. Action 1530 may be a pointer to additional SEP code. This SEP code instructs the SPU 200 to determine whether or not the number of connections currently established with the subnetwork 1522 is less than the number of assigned licenses. If the number of licenses purchased for the subnetwork 1522 is greater than the number of active connections, the AV software 1504 is applied to the packet 1525.

  SPU 200 or other processing elements within firewall 1502 may continue to maintain a count 1529 of the number of active connections between Internet 1500 and each subnetwork 1520, 1522 and 1524. it can. The memory 221 stores a count 1529 of active connections and the number of licenses 1531 purchased for each of the sub-networks connected to the firewall 1502.

  The SPU 200 can quickly determine whether the AV software 1504 should be applied to the packet 1525 by putting the already specified packet destination address 1527 in the CAM 220. The CAM 220 identifies a location in the SRAM 221 that contains the current connection count 1529 for the subnetwork 1522 and an available license 1531. If one or more AV licenses are valid, the SPU 200 applies the AV software 1504 to the packet 1525 before, during, or after other firewall operations.

  If the subnetwork is located on a public network, a tunnel may be established for all packets passing through the AV software 1504. For example, the sub-network 1524 may be located at a location away from the firewall 1502. If subnetwork 1524 is assigned an AV license, action 1530 in the corresponding ACL entry 1526 (this ACL entry 1526 matches the address for subnetwork 1524) will send a packet to SPU 200. Prior to sending to the subnetwork 1524, this packet may be encapsulated and ordered to enter the secure tunnel 1518.

  AV software 1504 is not applied to a sub-network that does not have an AV license. For example, no license key action 1530 is created for an ACL entry associated with a subnetwork 1520. Accordingly, the RSP 100 does not apply AV 1504 to packets destined for the sub-network 1520.

As shown in RSP sequence diagrams 30 and 31, a plurality of RSPs 100 can be connected together to provide sequential or parallel firewall operations. For example, in the configuration of FIG. 30, a plurality of RSPs 100A-100D are combined in series with each other to perform different firewall operations, routing operations, and intrusion detection system (IDS) operations. The first RSP 100A identifies the IP information from the input packet 1598 and extracts the IP information from the input packet 1598 by extracting the 5-tuple source and destination IP addresses and the port number.

  The second RSP 100B then performs operations related to TCP (eg, management of TCP sessions, filtering of all TCP packets related to DoS attacks, etc.) as described in connection with FIGS. 4-11. May be. The third RSP 100C may perform a packet processing operation that retrieves any HTTP session that may be carried in the packet. Finally, RSP 100D is a virus or other specific type of information (eg, “Method and Apparatus for Intrusion Detection in Network Processing Devices” filed on May 9, 2005). Search for any text or executable file in an HTTP session that may contain viruses or other specific types of information as described in co-pending US patent application No. 11 / 125,956) .

  Of course, any combination of RSPs 100 can perform any combination of various firewall and non-firewall operations, and FIG. 30 shows only one example. Each added RSP provides a significant linear improvement in performance. For example, the RSP 100A may send any parsed 1602 such as a firewall predicate, IDS token, non-terminal (NT) 312, generated code 178 and SEP code 177B (FIGS. 2B and 2C) to the next RSP 100B it can. When packet processing is complete, the RSP 100B can send similar status information 1602 to the RSP 100C.

  This prevents each subsequent RSP 100 from having to repeat a portion of the same analysis that has already been completed within the previous RSP. Furthermore, the architecture of DXP 180 (FIG. 2A) allows each RSP 100 to quickly change to the same state as the previous RSP by simply loading NT 132 into parser stack 185 (FIG. 2A). For example, RSP 100A may identify an ACL predicate that includes an IP destination address. RSP 100A places the ACL predicate and the associated NT 132 in message 1602 and sends it to RSP 100B along with the associated packet 1600. The RSP 100B can then initiate a TCP operation on the packet 1600 using the IP address information that has already been identified, left off from the RSP 100A. Thus, the RSP 100B does not need to re-parse the packet 1600 to rediscover, for example, the destination IP address.

  This is the opposite of conventional processor architectures that cannot immediately pass packet processor state. As a result, each conventional processor added to the packet processing system does not necessarily linearly improve the overall performance of the network processing device. In other words, doubling the number of packet processing devices using a conventional computer architecture does not necessarily double the overall processing capability. On the contrary, in this embodiment, if the number of RSPs 100 is doubled, the overall performance of the host network processing system is almost doubled.

  FIG. 31 shows another configuration of the RSP 100. In this configuration, one or more RSPs 100 operate in parallel. Based on the IP address extracted from the packet and other predicates, the first RSP 100A will determine if any other firewall operation is to be performed (if any). An initial UPM operation is performed to determine if these input packets 1598 need to be executed. RSP 100A then routes these packets to RSP 100B-G according to the identified firewall policy metrics.

  For example, based on the identified firewall predicate, packet 1598 may request DoS processing provided by RSP 100B. In response, RSP 100A routes to these packets RSP 100B. If RSP 100B determines that the destination subnet address for this packet has an associated IDS license, as described above in connection with FIGS. 28 and 29, this packet is RSP for anti-virus processing. It may be routed to 100C. Otherwise, RSP 100B may forward this packet to an endpoint in local network 1604.

If UPM routing in RSP 100A determines that the packet needs to be converted to IPv4 format, the packet is routed to RSP 100D. This packet 1598 is sent to the RSP 100E. Subsequently, the RSP 100E processes this packet according to various upper OSI layer data. For example, the RSP 100E may route this packet according to the HTTP information in this packet, as described above in connection with FIG.
Each of the other packets may be routed to the RSP 100F for performing other NAT operations and to the RSP 100G for performing other DoS operations.

Command line interface (CLI) / logging / statistics
Command line interface
Returning to FIG. 2A, a command line interface (CLI) 282 is combined with the MCPU 56 to allow an operator of the computer 284 to enter CLI commands and data 286 into the RSP 100. Thereafter, the MCPU 56 interprets the CLI command 286 received from the computer 284 and operates according to it. For example, CLI command 286 may instruct MCPU 56 to load a new ACL entry into TCAM 220 in memory subsystem 215. CLI command 286 may also instruct MCPU 56 to load data into any other memory component within memory subsystem 215.

  The CLI command 286 may also be used to configure other storage device components or tables within the RSP 100. For example, CLI command 286 instructs MCPU 56 to load a new parser grammar into parser table 170, load production rule 176 into production rule table 190, or semantically insert a new SEP code 212. The code table 210 may be instructed to load. CLI command 286 instructs MCPU 56 to read information from one of the storage components or tables in memory subsystem 215, or to read information from other processing components in RSP 100. Can be ordered.

Logging
The SEP code 212 can instruct the SPU 200 to record some of the detected events to the MCPU 56 for logging. For example, the SPU 200 may send some packets identified as being part of a DoS attack to the MCPU 56. If a DoS attack is detected, the SEP code 212 instructs the SPU 200 to send a sample of dropped packets to the MCPU 56. The SEP code 212 may instruct the SPU 200 to notify the MCPU 56 whenever a similar packet is excluded.

  The MCPU 56 formats the specific information contained in the excluded packets and statistics that also specify the number of excluded packets into a log. This log may be formatted into an IP packet with the IP address of the system log machine. In this case, the system log machine then receives and records events detected within the RSP 100. The packet containing this log may be sent by the SPU 200 via the output port 152 to the system log machine.

  Any event can be recorded by the RSP 100. Also, but not limited to, these events may include any event identified within the firewall operation described above. For example, the SEP code 212 may instruct the SPU 200 to send to the MCPU 56 a packet that matches (matches) a particular ACL entry in the CAM 220.

Statistic
Any required statistics can be recorded in the RSP 100 and stored elsewhere or sent to a logging system. For example, the SPU 200 may be programmed to count all received packets, excluded packets, and output packets. Another SEP code 212 may include a logging command in addition to other associated firewall operations. The RSP 100 identifies any statistical information associated with transmitted and received packets. Examples of statistics related to sent and received packets include the number of packets received, the size of received packets, the size and number of packets sent, the number of excluded packets, and bad checks This includes the number of packets with thumbs, the number of duplicated packets, and failed login attempts. This statistical value can be downloaded to the computer 284 via the CLI command 286 or transmitted as a packet via the output port 152 by the SPU 200 at regular intervals.

Certification
All of the firewall operations described above are certified and comply with certification standards accepted by various industries. These certification standards include the Institute for Computer Security Association (ICSA), the National Institute of Standards and Technology (NIST), the University of New Hampshire (UNH), and PLUG Fest.

Summation
Unprecedented use of the RSP architecture in combination with access control lists makes different firewalls, UPMs or other packet processing operations more efficient using the same hardware and minimal software reconfiguration Can be executed. These multiple firewall operations can utilize syntactic elements (eg, predicates) that have been verified by DXP or other previous firewall parsing operations. In this way, RSP provides a highly scalable firewall architecture.

  As described above, any of the operations described above can be performed on any network processing device and are not limited to operating on an edge device or a system conventionally referred to as a firewall. For example, DoS, UPM, and other operations may be performed on gateways, routers, servers, switches, and some other endpoint device. Further, most of the operations described above need not be performed using RSP 100, but instead may be performed within a conventional computer architecture.

Intrusion detection
In the following description, the word “virus” refers to any type of intrusion, unauthenticated data, spam, spyware, denial of service (DoS) attacks, or any other type of data that is considered an intrusion by a network processing device. , Signal, message transmission, etc. The word “virus”, otherwise called “malware”, is not limited to any particular type of unauthenticated data or message.

  FIG. 32A shows a private IP network 2024 connected to a public Internet Protocol (IP) network 2012 via a peripheral device (edge device) 2025A. The public IP network 2012 can be any wide area network (WAN) that provides packet switching. The private network 2024 is a corporate network, an Internet service provider (ISP) network, a home network, or the like that needs to defend against attacks (eg, viruses or other malware attacks coming from the public network 2012).

  The network processing devices 2025A-2025D in the private network 2024 may be any type of computer-related component as long as they communicate over a packet switched network. For example, the network processing devices 2025A and 2025B may be routers, switches, gateways, or the like. In this example, network processing device 2025A operates as a firewall and device 2025B operates as a router or switch. (Device 2025B operates as a router, switch, or device 2025C.) Endpoint 2025C is a personal computer (PC), and endpoint 2025D is a server such as an Internet web server. The PC 2025C may be connected to the private network 2024 via a wired connection such as a wired Ethernet connection or a wireless connection using, for example, the IEEE 802.11 protocol.

  Intrusion detection system (IDS) 2018 is implemented with any combination of network devices 2025A-2025D operating within private network 2024. Each IDS 2018 receives a packet stream 2022 of network traffic passing through the host network processing device 2025, parses it, and then identifies all packets 2016 that contain viruses in the packet stream 2022 and identifies them Discard. In one embodiment, IDS 2018 is implemented using a reconfigurable semantic processor (RSP) described in more detail below. However, it will be appreciated that IDS 2018 is not limited to embodiments using RSP, and other processing devices can also be used.

  In one embodiment, IDS 2018 is installed in edge router 2025A. The edge router 2025A connects the private network 2024 to the external public network 2012. In one embodiment, IDS 2018 may be implemented in a network processing device that has not traditionally performed IDS operations. For example, IDS 2018 may be implemented in a router or switch 2025B. In yet another example, IDS 2018 may be implemented in one or more endpoint devices (eg, in PC 2025C or web server 2025D). Implementing the intrusion detection system 2018 in different network processing devices 2025A-2025D will provide more complete intrusion detection, and the virus 2026 that has entered the private network 2024 via multiple different access points It can be removed except for those that have entered through 2025A. For example, a virus that accesses a private / internal network 2024 via an employee's personal computer 2025C can be detected and removed by IDS 2018 running on a PC 2025C, router 2025B, or server 2025D Can do.

  In another embodiment, IDS 2018 in network processing device 2025 is used to detect and remove virus 2016A due to private network 2024. For example, an operator of PC 2025C may generate virus 2106A that is directed to a network device operating within public IP network 2012. Use any combination of multiple IDS 2018 running in the internal network 2024 to identify and remove the virus 2016A before it is output to the public IP network 2012 be able to.

  Semantic processors allow for the incorporation and distribution of anti-virus operations across the entire private network 2024. For example, the semantic processor can perform intrusion detection operations within multiple ports of a network router or switch 2025B. The integrated intrusion detection system IDS 2018 is more robust than the current perimeter anti virus scheme and provides more effective intrusion detection than this current perimeter anti virus detection scheme. This intrusion detection scheme does not need to handle certain suspicious data types, such as email attachments, and is performed off-line for data flows at network transmission rates.

Intrusion Detection Using Syntactic Elements
FIG. 32B shows how a conventional intrusion detection system generates a filter. The input data stream 2071 includes a plurality of packets 2072. These packets 2072 include one or more headers 2072A and a payload 2072B. A conventional intrusion detection system indiscriminately compares each byte 2074 of each packet 2072 in the data stream 2071 with the threat signature 2058. All filters 2075 generated by comparison with the threat signature are then applied to the entire data stream 2071.

  This intrusion detection scheme consumes computing resources unnecessarily. For example, some information in the data stream 2071, such as header data 2072A, is unlikely to contain a threat. Nevertheless, the intrusion detection system of FIG. 32B blindly compares each byte in the data stream 2071 with the threat signature 2058. This unnecessarily burdens the computing resources performing intrusion detection.

  Also, the intrusion detection scheme of FIG. 32B does not distinguish the context between multiple packets that are currently being scanned for viruses. For example, the threat signature 2058 associated with an email virus applies to all packets 2072 regardless of whether the packet 2072 actually contains an email message. Accordingly, the threat signature 2058 associated with the email virus may be compared to a packet 2072 containing an HTTP message. This further limits the scalability of this intrusion detection system.

  FIG. 32C is a diagram illustrating an embodiment of IDS 2018 that verifies syntax elements in a data stream to detect viruses more efficiently. This IDS 2018 identifies the session context 2082 associated with the packet 2072 using a parser. For example, during an initial parsing operation, one or more media access control (MAC) address 2076A, Internet Protocol (IP) address 2076B, and Transfer Control Protocol (TCP) address 2076C may be identified. In this example, the parser may specify that packet 2072 contains a Simple Mail Transfer Protocol (SMTP) email message. These session context 2082 identifiers 2076A-2076D are otherwise called syntax elements.

  By identifying syntax element 2076, IDS 2018 can more efficiently detect and remove viruses or other malware threats. For example, IDS 2018 can customize further intrusion detection operations based on the session context 2082 detected at the beginning of the packet 2072. For example, session context 2082 identifies packet 2072 as containing an email message. As a result, IDS 2018 can search and identify additional syntactic elements 2076E-2076H that are specifically associated with email messages. More precisely, it identifies the semantic elements of email that may contain viruses.

  For example, IDS 2018 uses fields such as “To: (To):”, “From: (From):” and “Subject:” in email messages. Semantic elements 2076E-2076G containing information are identified. IDS 2018 may also identify the email attachment 2076H included in the email message. In this example, a virus or multiware may only be included in the syntax element 2076H that includes the email attachment. Other syntax elements 2076A-2076D would not be an intrusion threat. Thus, only the syntax element 2076H containing the email attachment is compared with the threat signature 2058.

  Other syntax elements 2076A-2076D may be used to help generate a filter 2070 that is used to filter the packet 2072. For example, filter 2070 has the same “from:” field as identified in syntax element 2076F, or the same IP source address as identified in syntax element 2076B. May be generated to filter all packets.

  Accordingly, IDS 2018 can detect intrusion attempts based on IP session context 2082, data stream traffic characteristics and syntax 2076. These intrusions are then detected by comparing the syntax element 2076 identified in the network traffic with a threat signature rule 2058 that describes the event considered to be troublesome. These rules 2058 can describe any activity (eg, a particular host connected to a particular service), and what activity corresponds to a warning (eg, a predetermined number of You can describe a signature that describes access to a known attack or a known vulnerability (assuming an attack against a different host constitutes a “scan”).

Fixed packet delay
FIG. 33 shows a delay buffer used in combination with IDS 2018. Intrusion monitoring operations 2040 may be performed locally within a reconfigurable semantic processor (RSP) 2100 or other intrusion monitoring circuitry operating within or external to the RSP 2100. Can be combined and executed.

  33 and 34, at block 2048A, RSP 2100 receives packet 2022 from input port 2120. The RSP 2100 may perform a preliminary (initial) threat filtering operation at block 2048B that discards a first category packet 2032A containing a virus or another type of threat. This initial filtering 2048B may be performed, for example, by accessing a table having a predetermined known threat signature. This initial filtering prevents certain data 2032A from being further processed by IDS 2018. For example, if a denial-of-service attack, a known virus attack, or an unauthenticated IP session can be detected, IDS 2018 can remove the associated packet without further processing.

  In block 2048C, the RSP 2100 stores the remaining packet 2022 in the packet delay buffer 2030. In one example, the packet delay buffer 2030 is a dynamic random access memory (DRAM) or another type of memory that is sized to temporarily buffer the input data stream 2022. At block 2048D, RSP 2100 further identifies the syntax of the input data stream. For example, RSP 2100 may identify a packet that includes an email message.

  The vast majority of intrusion attacks on Windows-based PCs result from email messages arriving as files or scripts within the message. The format of the data in the attack is a simple binary machine code or ASCII text. These messages can only be activated if they satisfy the delivery mechanism syntax and semantics. For example, an executable file in an e-mail message may be a Simple Mail Transfer Protocol / Point of Presence (SMTP /) file using the Multipurpose Internet Mail Extensions (MINE) file attachment format specified in Request For Comment (RFC) 2822. POP). Therefore, RSP 2100 may identify a packet corresponding to some combination of SMTP and MIME protocols at block 2048D.

  The RSP 2100 generates a token 2068 corresponding to the syntax identified for the data stream 2022 at block 2048E. For example, token 2068 may include certain subelements of the identified email message. Examples of subelements include the sender of the email message (“From:”), the email message destination (“To:”), the email message subject (“Subject:”), and the time the email was sent. ("Sent:"), and attachments included in email messages. Because the RSP 2100 analyzes this session information, threat filtering within a network processing device (eg, router, switch, etc.) is not limited to elements found within a single packet. In other words, it also filters attempts to hijack TCP sessions, attempts to bypass FTP streams, attempts to forge HTTPS certificates, and so on.

  The token 2086 is used at block 2048F to dynamically generate a second more thorough filter set that is customized to the syntax of the data contained in the packet delay buffer 2030. For example, the token 2068 is used to generate a filter 2070 that is associated with a virus contained within an email message. This is important for the scalability of IDS 2018. By generating a filter associated with the syntax of the data, this IDS can scan for threats more efficiently. For example, IDS 2018 saves time in applying inappropriate filters to the type of data currently being processed.

  The RSP 2100 applies this customized filter set 2070 to the data stored in the packet delay buffer 2030 at block 2048G. All packets 2032B containing the threat identified by filter 2070 are discarded. After this data is stored in the packet delay buffer 2030 for a predetermined time, the RSP 2100 outputs the data to the output port 2152 at block 2048H.

  This constant delay provided by the packet delay buffer 2030 gives time to the monitoring operation 2040. This time assesses the threat, determines if there is a new threat in the burden of processing, forms a set of filters 2070 associated with the syntax, and the data 2034 is output from output port 2152 It is time to apply these filters before. For a 1 Gbps (1 gigabit per second) Ethernet LAN system, the delay applied in the buffer 2030 is typically about 20 milliseconds (ms) to 50 milliseconds (ms). Of course, other constant delay times can also be used.

  The RSP 2100 uses unprecedented analysis techniques to process the data stream 2022. This allows RSP 2100 to perform IDS 2018 at the network line rate without taking intrusion monitoring operation 2040 offline from other input network routing operations that may be running within the same network processing device. Make it possible to do. This allows the RSP 2100 to process with a constant packet delay of the incoming packet 2022. This packet delay makes it difficult for an intruder to identify and avoid the network processing device 2025 (FIG. 32A) running the intrusion detection system.

  For example, an intruder monitors network delays while attempting to infect the private network 2024 (FIG. 32A) with a virus. If a longer response time is identified in a particular network path that is responding to repeated virus attacks, an intruder may determine that this path includes an intrusion detection system. If the other network path did not take longer than the others to respond to the attempted attack, the intruder concludes that this path does not contain an intrusion detection system and the identified network path May send viruses through ports or devices inside.

  By providing a constant packet delay between input port 2120 and output port 2152 that is independent of the type of data 2022 and the type of filter generated and applied to that data stream 2022, IDS 2018 prevents intruders from identifying the network processing device 2025 running IDS 2018. Of course, this is just one embodiment, and other IDS embodiments 2018 may not be performed with a constant packet delay.

  In another embodiment, the RSP 2100 only delays certain identified types of data while processing other data without constant delay. By identifying the syntax of the data stream, IDS 2018 can identify data streams that need to be scanned for viruses and data streams that do not need to be scanned for viruses. IDS 2018 then delays only the scanned data stream in a reasonable way. For example, the RSP 2100 may apply a certain delay to a packet identified as containing a TCP SYN message. If no irregularity is detected in this SYN packet, the RSP 2100 is received (subsequently) without a certain delay as described above with reference to FIG. TCP data packets may be received and processed. Therefore, an unestablished TCP session may be delayed while other traffic is not delayed.

  FIG. 35 is a more detailed description of the operations performed by IDS 2018 shown in FIG. Packets from data stream 2022 are received by packet input buffer (PIB) 2140 via input port 2120. The bytes from packet 2022 are processed by a direct execution parser (DXP) 2180 and a semantic processing unit (SPU) 2200. In this example, one or more SPUs 2200 can simultaneously perform an access control list (ACL) matching operation 2050, a session search operation 2052, and a token generation operation.

  ACL matching operation 2050 matches the incoming packets in data stream 2022 against the initial ACL list of filter 2064 that are known a priori. ACL matching operation 2050 removes packets that match ACL filter 2064 and then loads the remaining packets 2022 into delay FIFO 2030.

  Session search operation 2052 matches packet 2022 with a known and valid IP session. For example, the DXP 2180 may send information to a session search 2052 that identifies the TCP session, port number, and arrival rate for the TCP SYN message. Session search 2052 determines whether and when this TCP session and port number have been confirmed so far. If packets 2022 are identified as valid TCP / IP sessions, these packets 2022 may be sent directly to output buffer (POB) 2150.

  Generate token operation 2054 generates token 2068 according to the syntax of data stream 2022 identified by DXP 2180. In one example, the token generator 2054 generates a token 2068 that includes a 5-tuple data set. In this case, the 5-tuple data set includes the source IP address, destination IP address, source port number, destination port number, and protocol number associated with the packet being processed in the input buffer 2140. These tokens 2068 may include any anomaly (eg, unknown IP or TCP options) in the TCP packet.

In the example described below, part of the token 2068 also includes a syntax element associated with the email message. For example, DXP 2180 may identify packets associated with a Simple Mail Transfer Protocol (SMTP) session, as described in FIG. 32C. The token generation operation 2054 then extracts specific information such as SMTS / MIME attachments from the email session. An example of a token 2068 associated with an email message is generated using the following Type-Length-Value (TLV) format.
Token # 1
Type: SMTP / MIME Attachment (method for transferring files in email messages)
Length: # of bytes in the file
Value: actual file
In another example, DXP 2180 identifies a packet 2022 that is associated with a hypertext markup language (HTML) session in input buffer 2140. Token generation operation 2054 accordingly generates a token that is specifically associated with the following HTTP session and that identifies the following HTTP session:
Token # 2
Type: HTML Bin Serve (method for transferring files in web pages)
Length: # of bytes in file
Value: actual file
Token 2068 is formatted by token generation operation 2054 as described above so that the syntax information contained in token 2068 can be easily compared with threat signature 2058 by threat / virus analysis and anti-ACL agent 2056. . In one example, the countermeasure agent 2056 is a general purpose central processing unit (CPU) that compares the token 2068 with a predetermined threat signature 2058 stored in memory. For example, to measure agent 2056 to determine whether a new intrusion protection filter is necessary (decide), "BRO" - http://ee.ibl.gov/bro.html and, "SNORT" - http: // Various existing algorithms such as www.snort.org may be used. Both of these algorithms are hereby incorporated by reference into the present application. The threat signature 2058 may be supplied by, for example, a commercially available intrusion detection database available from SNORT or McAfee.

  The countermeasure agent 2056 dynamically generates an output ACL filter 2070 that corresponds to an example of matches between the token 2068 and the threat signature 2058. For example, threat signature 2058 may identify an email attachment virus contained within one of tokens 2068. The countermeasure agent 2056 then dynamically generates a filter 2070 that includes the source IP address of the packet that contains the email attachment that is infected with the virus. This filter 2070 is output to the ACL operation 2062. This operation then discards all packets 2016 that contain the source IP address identified by filter 2070 from within the delay FIFO 2030. Thereafter, the remaining packets are output to the output buffer 2150.

Reconfigurable Semantic Processor (RSP)
FIG. 36 shows a block diagram of a reconfigurable semantic processor (RSP) 2100 that is used to implement the IDS 2018 described above in one embodiment. The RSP 2100 includes an input buffer 2140 for buffering a packet data stream received via the input port 2120, and an output buffer 2150 for buffering a packet data stream output via the output port 2152. Have.

  Direct execution parser (DXP) 2180 recirculates packets or frames received at input buffer 2140 (eg, input “stream”) and packets or frames output to output buffer 2150 (eg, output “stream”). Controls the processing of packets or frames that are recirculated in buffer 2160 (eg, recirculating “streams”). Input buffer 2140, output buffer 2150, and recirculation buffer 2160 are preferably first-in-first-out (FIFO) buffers. In addition, the DXP 2180 controls packet processing by a semantic processing unit (SPU) 2200. This semantic processing unit (SPU) controls the transfer of data between the buffers 2140, 2150 and 2160 and the memory subsystem 2215. The memory subsystem 2215 stores packets received from the input port 2120 and also stores a threat signature 2058 (FIG. 35) that is used to identify threats in the input data stream.

  RSP 2100 uses at least three tables to perform a given IDS operation. A code 2178 for retrieving the generation rule 2176 is stored in the parser table (PT) 2170. The grammar generation rule 2176 is stored in a generation rule table (PRT) 2190. Code segments executed by the SPU 2200 are stored in a Semantic Code Table (SCT) 2210. The code 2178 in the parser table 2170 is stored in a manner such as a row-column format or a content addressable format. In row-column format, the rows of parser table 2170 are indexed by the non-terminating code NT 2172 provided by internal parser stack 2185, and the columns of parser table 2170 are extracted from the beginning of the data in input buffer 2140. Is indexed by the input data value DI [N] 2174. In the content addressable format, the concatenation of the non-terminal code 2172 from the parser stack 2185 and the input data value 2174 from the input buffer 2140 forms the input to the parser table 2170.

  Production rule table 2190 is indexed by code 2178 from parser table 2170. Tables 2170 and 2190 may be linked as shown in FIG. 36 such that queries against parser table 2170 send back directly production rules 2176 applicable to non-terminal code 2172 and input data value 2174. The DXP 2180 replaces the non-terminal code at the top of the parser stack 2185 with a production rule (PR) 2176 sent back from the PRT 2190, and then continues to analyze the data from the input buffer 2140.

  Semantic code table 2210 is also indexed by code 2178 generated by parser table 2170, generation rule 2176 generated by generation rule table 2190, or both. Typically, the analysis results allow DXP 2180 to detect whether SPU 2200 should load and execute code segment 2212 from semantic code table 2210 for a given production rule 2176.

  The SPU 2200 has a number of access paths to the memory subsystem 2215 that provides a structured memory interface that can be addressed by context symbols. Memory subsystem 2215, parser table 2170, generation rule table 2190 and semantic code table 2210 can be internal memory or external memory devices (eg synchronous dynamic random access memory (DRAM) or content addressable memory (CAM)) Or use a combination of these resources. Each table or context need only provide a context interface to a shared physical memory area that has one or more other tables or contexts.

  A maintenance central processing unit (MCPU) 2056 is connected between the SPU 2200 and the memory subsystem 2215. The MCPU 2056 implements functions desirable for the RSP 2100 that can be reasonably performed by conventional software and hardware. These functions are usually functions that are rarely used and are not executed with the highest priority (not important in time), and are not intended to be included in the SCT 210 due to the complexity of the functions. The MCPU 2056 preferably has a function of requesting the SPU 2200 to execute a task instead of the MCPU. In one embodiment, the MCPU 2056 assists in generating an access control list (ACL) that the SPU 2200 uses to filter viruses from the incoming packet stream.

  The memory subsystem 2215 includes an array machine context data memory (AMCD) 2230 for accessing data in the DRAM 2280 via a hash function (hashing function) or content addressable memory (CAM) search. The cryptographic processing block 2240 performs data encryption, decryption, and authentication, and the context control block cache 2250 caches the context control block to the DRAM 2280 and caches the context control block from the DRAM 2280. The normal cache 2260 caches the data used in the basic operations, and the streaming cache 2270 is responsible for these while the data stream is being written to the DRAM 2280 and while the data stream is being read from the DRAM 2280. Cache the data stream. The context control block cache 2250 is preferably a software controlled cache. That is, the SPU 2200 preferably determines when a cache line is used and when it is free. Circuits 2240, 2250, 2260 and 2270 are all connected between DRAM 2280 and SPU 2200. The TCAM 2220 is connected between the AMCD 2230 and the MCPU 2056.

  More detailed design optimization for the functional blocks of RSP 2100 is not within the scope of the present invention. For some examples of detailed architecture of applicable semantic processor functional blocks, see copending US patent application entitled "Reconfigurable Semantic Processor" filed January 24, 2003 Please refer to No. 10 / 351,030. This patent application is incorporated herein by reference in its entirety.

Intrusion Detecton in Fragmented Packets
The role of RSP 2100 in the intrusion detection context may be better understood by specific examples. In the following example, RSP 2100 removes a virus or other malware that is located in an email message. For those skilled in the art, the described concept can be easily applied to detect any type of virus or other type of malware, or to detect various types of intrusion on any data stream transmitted using any communication protocol. You will understand that you can.

  Initial intrusion detection operations include parsing and detecting the syntax of the input data stream. These are described in connection with FIGS. 37 and 38. As shown in FIG. 37, codes associated with many different grammars may exist simultaneously in the parser table 2170 and the production rule table 2190. For example, code 2300 is associated with parsing the MAC packet header format, code 2302 is associated with IP packet processing, and another set of codes 2304 is associated with TCP packet processing. Other codes 2306 in the parser table 2170 relate to the intrusion detection 2018 described above in connection with FIGS. 32A-35, and in this example, in particular, the simple mail transfer protocol in the data stream 2022 (FIG. 35). (SMTP) Identify the packet.

  The PR code 2178 is used to access the corresponding generation rule 2176 stored in the generation rule table 2190. Unless required in the execution of a particular search, a non-terminal (NT) symbol 2172 combined with an input value 2308 (eg, the current input value DI [n] 2174, where n is the match width selected in bytes) ) Need not be assigned in any particular order within the PR table 2170.

  In one embodiment, parser table 2170 also includes an addresser 2310 that receives data value DI [n] 2174 and NT symbol 2172 from DXP 2180. Addresser 2310 concatenates NT symbol 2172 with data value DI [n] 2174 and sends this concatenated value 2308 to parser table 2170. Conceptually, it is often useful to look at the structure of parser table 2170 as a matrix with one PR code 2178 for each unique combination of NT code 2172 and data value 2174. The invention embodiments are not so limited. Different types of memory and memory configurations may be appropriate for different applications.

  In one embodiment, parser table 2170 is implemented as a content addressable memory (CAM), and addresser 2310 uses NT code 2172 and input data value DI [n] 2174 as a key for CAM to retrieve PR code 2178. Use. The CAM is preferably a ternary CAM (TCAM) populated with TCAM entries. Each TCAM entry includes an NT code 2312 and a DI [n] match value 2314 (DI [n] match value). Each NT code 2312 can hold a plurality of TCAM entries.

  Each bit of DI [n] match value 2314 (DI [n] match value) can be set to “0”, “1”, or “X”. This “X” represents “Don't Care”. With this function, PR code 2178 requires that only a few bits or bytes of DI [n] 2174 match the coded pattern in order for parser table 2170 to find a match.

  For example, a line in the TCAM contains the NT code NT_SMTP 2312A for an SMTP packet, followed by an additional byte 2314A (eg, an email attachment file) indicating that the SMTP packet contains a particular type of content. Label) may follow. The remaining bytes of this TCAM line are set to “Don't Care”. Thus, when NT_SMTP 2312A and several bytes of DI [N] are presented to the parser table 2170, the first few bytes of DI [N] (first set of bytes of DI [N]) If so, a match will occur no matter what the remaining bytes of DI [N] contain.

  The TCAM in parser table 2170 generates PR code 2178A corresponding to the TCAM entry that matches NT 2172 and DI [N] 2174, as described above. In this example, PR code 2178A is associated with an SMTP packet that includes an email message. The PR code 2178A may be sent back to the DXP 2180, sent directly back to the PR table 2190, or both. In one embodiment, PR code 2178A is the row index of the TCAM entry that creates the conformance.

  FIG. 38 shows one possible implementation of the production rule table 2190. In this embodiment, the addresser 2320 receives the PR code 2178 from either the DXP 2180 or the parser table 2170 and receives the NT symbol 2172 from the DXP 2180. Preferably, the received NT symbol 2172 is the same NT symbol 2172 as the NT symbol sent to the parser table 2170 and is used to place the received PR code 2178.

  The addresser 2320 uses the received PR code 2178 and the NT symbol 2172 to access the corresponding generation rule 2176. The addresser 2320 is not necessarily required in some embodiments, but if used, it can be provided as part of the DXP 2180 or part of the PRT 2190, or as an intermediate functional block. Can be provided. For example, if the parser table 2170 or DXP 2180 creates the address directly, no addresser is required.

  The generation rule 2176 stored in the generation rule table 2190 includes three data segments. These data segments include a symbol segment 2177A, an SPU entry point (SEP) segment 2177B, and a skip byte segment 2177C. These segments may be fixed length segments or variable length segments, and are preferably null-terminated. Symbol segment 2177A has terminal symbols, non-terminal symbols, or both that are pushed onto parser stack 2185 (FIG. 36). SEP segment 2177B contains the SPU entry point (SEP) used by SPU 2200 during processing of the data segment. The skip byte segment 2177C has skip byte data used to increment its buffer pointer by the input buffer 2140 and proceed with the processing of the input stream. Also, other information useful in the production rule processing can be stored as part of the production rule 2176.

  In this example, one or more production rules 2176A indexed by production rule code 2178A correspond to SMTP packets identified in input buffer 2140. The SEP segment 2177B points to the SPU code 2212 in the semantic code table 2210 of FIG. This SPU code, when executed by SPU 2200, performs various ACL matching 2050 operations, session search 2052 operations and token generation 2054 operations as described above in connection with FIG. In one embodiment, SPU 2200 has an array of semantic processing elements that can be operated in parallel. SEP segment 2177B in generation rule 2176A may invoke one or more SPUs 2200 to perform ACL matching operation 2050, session search operation 2052 and token generation operation 2054 in parallel.

  As described above, the parser table 2170 may contain a grammar for processing another type of data not associated with an SMTP packet. For example, the IP grammar 2302 included in the parser table 2170 may include a production rule code 2178 associated with the identified NT_IP destination address in the input buffer 2140.

  The conformance data value 2314 in the generation rule table code 2302 may include the IP address of the network processing device to which the RSP 2100 belongs. If the input data DI [I] 2174 associated with the NT_IP code 2172 does not have a destination address contained in the conformance value 2314 for the PR code 2302, the default generation rule code 2178 is provided in the generation rule table 2190 May be. The default generation rule code 2178 may point to the generation rule 2176 in the generation rule table 2190. The generation rule 2176 here instructs the DXP 2180 and / or the SPU 2200 to discard the packet from the input buffer 2140.

Semantic processing unit (SPU)
As mentioned above, DXP 2180 identifies specific syntax elements in the input stream, such as IP sessions, TCP sessions (SMTP email sessions in the current example). These parsing operations are important to the overall performance of the IDS system 2018. Since DXP 2180 identifies the actual syntax of the input stream, subsequent IDS operations as described above in connection with FIG. 35 can now be performed more efficiently by SPU 2200.

  For example, the SPU 2200 need only apply the ACL filter associated with the email message to the parsed data stream. This provides several advantages. First, not all bytes of every packet need necessarily be compared with every threat signature 2058 (FIG. 35). Instead, only the subnet of the threat signature associated with the email message need be applied to the SMTP packet. This has the substantial advantage of increasing the scalability of IDS 2018. This also allows IDS 2018 to detect more viruses and malware and operate at higher packet rates.

  FIG. 39 illustrates in more detail the ACL matching operation 2050 and output ACL operation 2062 previously described in connection with FIG. At block 2040, the DXP 2180 signals the SPU 2200 to load the appropriate microinstruction from the SCT 2210. These microinstructions perform the ACL matching operation 2050 and the output ACL operation 2062 previously described in connection with FIG. As described above in connection with FIG. 38, DXP 2180 signals SPU 2200 via SPU entry point (SEP) segment 2177B included in production rule 2176A.

  In accordance with SPU code 2212 (FIG. 36) in SCT 2210 accessed in response to SEP segment 2177B, SPU 2200 obtains the particular syntax element in the input data stream identified by DXP 2180 at block 2402. For example, DXP 2180 may identify a 5-tuple syntax element that includes an IP source address, an IP destination address, a destination port number, a source port number, and a protocol type. Of course, this is only an example, and other syntax elements may be identified by the DXP 2180 in the data stream 2022 (FIG. 35).

  At block 2404, the SPU 2200 compares the syntax element identified by the DXP 2180 with a priori set of ACL filters contained in the TCAM 2220. For example, an a priori ACL filter set in TCAM 2220 may include various IP addresses associated with known threats. In one example, the SPU 2200 compares the syntax element for the packet in the input buffer 2140 with the a priori filter in the TCAM 2220 by sending a syntax element such as the IP address of the packet to the TCAM 2220 via the AMCD 2230. In this case, this IP address is used as an address to the TCAM 2220. TCMA 2220 sends the result back to SPU 2200 via AMCD 2230.

  The SPU 2200 verifies the result from TCAM 2220 at block 2406. The output from TCAM 2220 may indicate the presence of packet removal, packet storage, and possibly IP security (IPSEC) packets. For example, the TCAM 2220 may generate a packet removal flag if the IP address supplied from the packet in the input buffer 2140 matches one of the a priori filter entries in the TCAM 2220. If the IP address for input data stream 2022 does not match any of the entries in TCAM 2220, a packet storage flag is output. TCAM 2220 may also contain an entry corresponding to the encrypted IPSEC packet. If the IP address matches one of the IPSEC entries, TCAM 2220 outputs an IPSEC flag.

  The SPU 2200 removes all packets in the PIB 2140 that generate a packet removal flag in the TCAM 2220 at block 2408. The SPU 2200 can exclude a packet by simply instructing the input buffer 2140 to skip to the next packet. If the packet storage flag is output from the TCAM 2220, the SPU 2200 stores the packet from the input buffer 2140 in the DRAM 2280 in block 2410. DRAM 2280 operates as the delay FIFO 2030 described above in connection with FIGS. When the IPSEC flag is output from the TCAM 2220, the SPU 2200 may transmit the packet in the input buffer 2140 via the cryptographic processing circuit 2240 in the memory subsystem 2215. The decrypted packet is then sent back to the recirculation buffer 2160 of FIG. 36 and the ACL matching operation described above may be repeated.

  While the packet is stored in the DRAM 2280 (delay FIFO 2030 in FIG. 35), the MCPU 2056 (countermeasure agent 2056 in FIG. 35) dynamically moves the ACL filter 2070 corresponding to the token 2068 extracted from the input data stream. To generate. This is explained in more detail below in connection with FIG. The SPU 2200 compares, at block 2412, the packet stored in the DRAM 2280 with the dynamically generated ACL filter 2070 (FIG. 35) currently stored in the TCAM 2220. For example, the SPU 2200 may use the same 5-tuple as for the packet identified in block 2402.

  The SPU 2200 compares the 5-tuple for this packet with the dynamically generated filter 2070 in the TCAM 2220. All packets in DRAM 2280 that produce a packet removal flag result from TCAM 2220 are then deleted from DRAM 2280 by SPU 2200 at block 2414. After a predetermined fixed delay time, SPU 2200 outputs the remaining packets to output port 2152 at block 2416.

  It will be appreciated that the CAM 2220 may have other a priori filters. For example, the CAM 2220 may have filters associated with various protocols or data that may be included in the packet. DXP 2180 identifies the syntax element that needs to be applied to the filter in TCAM 2220 and sends it to SPU 2200.

  Within a certain time delay provided by the delay FIFO, it may not be possible to determine a virus or malware. For example, a virus may be included at the end of a huge multi-megabit message. In this situation, IDS 2018 may generate a virus notification message that is sent to the same recipient as the recipient of the packet. This virus notification message is a message that the packet contains a virus. The virus notification message notifies the recipient to discard the packet containing the virus.

  FIG. 40 illustrates operations performed by the SPU 2200 during the session search operation 2052 previously described in connection with FIG. At block 2430, DXP 2180 signals SPU 2200 to load the appropriate microinstruction from SCT 2210. In this case, these appropriate microinstructions are associated with performing a session search operation by sending the associated SEP segment 2177B, as described above in connection with FIG.

  In one example, the SPU 2200 receives the source and destination addresses and the source and destination port numbers for the incoming packet from the DXP 2180 at block 2432. SPU 2200 then compares this address and port number with the current session information for the packet contained in DRAM 2280. For some IP sessions, the SPU 2200 may need to reorder the fragmented packets in the delay FIFO 2030 running in the DRAM 2280 at block 2434. The SPU 2200 may remove all packets in the input buffer 2140 that are duplicates of previously received packets for the current IP session at block 2438.

  FIG. 41 illustrates the token generation operation 2054 described above in connection with FIG. At block 2450, the DXP 2180 parses data from the input stream as described above in connection with FIGS. At block 2452, DXP 2180 identifies a syntax element in the data stream in input buffer 2140 that may be associated with a virus or malware. In the above example, this identification may include DXP 2180 identifying (identifying) the packet containing the email message. On the other hand, what is the syntax element identified by DXP 2180, including IP address, IP data flow including source and destination addresses, traffic rate identified for a specific data flow, etc. It may be anything.

  The DXP 2180 signals the SPU 2200 to load the microinstruction associated with the particular token generation operation from the SCT 2210 at block 2454. More specifically, the microinstruction identified by SEP segment 2177B of FIG. 38 instructs SPU 2200 to generate a token for the particular syntax element identified by DXP 2180.

  The SPU 2200 then generates a token 2068 (FIG. 35) from the identified syntax element at block 2456. For example, SPU code 2212 (FIG. 36) may instruct SPU 2200 to extract syntax elements found from the identified email message. The SPU 2200 may generate a token that includes information from the “From:”, “To:” and “Title:” fields in the packet. The SPU 2200 may extract any email attachments that may be present in the data stream and generate a token.

For example, SPU 2200 may generate TLV token # 1 as described above in connection with FIG.
Token # 1
Type: SMTP / MIME Attachment (method for transferring files in email messages) Length: # of bytes in the file
Value: actual file
It will also be appreciated that DXP 2180 can identify many different types of syntax elements that may be associated with a threat. The DXP 2180 can invoke different SPU codes 2212 (FIG. 36) for different syntax elements. For example, as described above, DXP 2180 can also identify syntax elements that correspond to HTML messages. The DXP 2180 may send a SEP segment 2177B that instructs the SPU 2200 to generate an HTML token that may be similar to that shown below.
Token # 2
Type: HTML Bin Serve (method for transferring files in web pages)
Length: # of bytes in file
Value: actual file
The SPU 2200 formats the token for the simple application into the threat signature 2058 of FIG. 35 at block 2457. For example, the SPU 2200 formats the token into Type-Length-Value (TLV) data. The SPU 2200 may then send the formatted token at block 2458 to the MCPU 2056 of FIG. 36 or to an external threat / virus analysis and anti-ACL agent 2056 as described in connection with FIG.

  In one embodiment, the MCPU 2056 applies the token 2068 to the threat signature 2058 included in the TCAM 2220 to generate a dynamically generated set of ACL filters 2070. The SPU 2200 then matches the dynamically generated ACL filter 2070 in the TCAM 2220 with the packet stored in the DRAM 2280 delay FIFO in the output ACL operation 2062 described above in connection with FIG. All packets in the delay FIFO that match the ACL filter 2070 are removed.

  In one embodiment, TCAM 2220 may contain multiple tables including both threat signature tables and ACL filter tables. The threat signature table in TCAM 2220 is accessed by MCPU 2056, and the ACL filter in TCAM 2220 is accessed by multiple SPUs 2200 via AMCD 2230.

  In another embodiment, the external threat analysis device operates off-chip from RSP (off chip from RSP). In this example, an external TCAM may contain the threat signature. The SPU 2200 sends the token 2068 to the external threat analysis device. The external threat analysis device then outputs the dynamically generated ACL filter 2070 to the MCPU 2056. The MCPU 2056 then writes the dynamically generated ACL filter 2070 to the TCAM 2220. SPU 2200 then accesses the ACL filter in TCAM 2220 for ACL matching operation 2050 and output ACL operation 2062 described in connection with FIG.

  The actual generation of the ACL filter 2070 is well known to those skilled in the art and will not be described in further detail. However, it is unlikely that an intrusion detection system has dynamically generated an ACL filter according to tokens associated with identified syntax elements in the data stream.

Intrusion detection in fragmented packets Currently, there are text scanners that search for known patterns in Internet messages. To avoid false detection of threats, long sequences of text are usually matched using a regular expression style pattern matching technique. However, these techniques require that the bytes are contiguous or that the threat scanner uses extensive context memory.

For example, the virus script may be included as one long line as shown below.
For all files in the following (For all files in):
c: \; {open (xxx); delete (xxx); close (xxx);} end.
In response, the antivirus scanner must search the entire text string:
s / * open (*); delete (*); close (*) * /
On the other hand, an attacker may split the virus into multiple packet fragments as follows:
IP frag # 1: For all files in c: \; {open (xxx);
IP frag # 2: delete (xxx); close (xxx);} end;
A conventional virus scanner may not be able to detect a virus in the fragmented IP packet. When the TCP / IP protocol finally merges the fragmented messages back together, the virus has already penetrated the private network. RSP 2100 detects and reassembles the fragmented packet before performing the intrusion detection operation described above. This allows IDS to detect viruses that span multiple fragmented packets.

  FIG. 42A is a flowchart 2500 illustrating how the RSP 2100 of FIG. 36 detects a virus in a fragmented packet. 36 and 42A, at block 2502, a packet (data) is received at input buffer 2140 via input port 2120. At block 2510, the DXP 2180 begins parsing the header of the packet in the input buffer 2140. If the DXP 2180 determines that the received packet is an IP fragmented packet, the DXP 2180 stops analyzing the header of the received packet. The DXP 2180 preferably analyzes the IP header completely and does not analyze any headers that belong to the following layers (TCP, UDP, iSCSI, etc.). The DXP 2180 stops parsing if it is instructed by the grammar on the parser stack 2185 or by the SPU 2200.

  In the next block 2520, the DXP 2180 signals the SPU 2200 to load the appropriate microinstruction from the SCT 2210 and read the fragmented packet from the input buffer 2140. In the next block 2530, the SPU 2200 writes this fragmented packet to the DRAM 2280 via the streaming cache 2270. Although block 2520 and block 2530 are shown as two separate steps, alternatively, they may be performed as a single step with the SPU 2200 reading and writing the packet simultaneously. . The operation in which the SPU 2200 executes reading and writing at the same time is known as the SPU pipeline method. In this operation, the SPU 2200 operates as a conduit or pipeline for streaming data that is transferred between two blocks within the semantic processor 2100.

  In a next decision block 2540, the SPU 2200 determines whether a context control block (CCB / Context Control Brock) has been assigned for proper IP packet fragment collection and ordering. The CCB for collecting and ordering fragments corresponding to IP fragmented packets is preferably stored in DRAM 2280. CCB waits for further IP fragmented packets in semantic processor 2100 after a pointer to an IP fragment in DRAM 2280, a bit mask for an IP fragmented packet that has not yet arrived, and the allotted time And a timer value for releasing the data stored in the CCB in the DRAM 2280.

  The SPU 2200 uses the source IP address of the received IP fragmented packet combined with the ID (identification) and protocol from the header of the received IP packet fragment as a key to use the content address of the AMCD 2230. It is preferable to determine whether a CCB is allocated by accessing a search function of a dressable memory (CAM). Alternatively, this IP fragment key is stored in a remote CCB table in DRAM 2280. And in this way, these keys are accessed with the CAM by using the source IP address of the received IP fragmented packet combined with the ID and protocol from the header of the received IP packet fragment. Be made. By addressing the IP fragment key in this way, the problem of key duplication and key size adjustment is avoided.

  If the SPU 2200 determines that a CCB has not yet been assigned for fragment collection and ordering for a particular IP fragmented packet, the executing program proceeds to block 2550 where the SPU 2200 assigns a CCB. The SPU 2200 inputs a key corresponding to the assigned CCB to the IP fragment CCB table in the AMCD 2230, and starts a timer provided in the CCB. The key here is composed of the ID and protocol from the header of the received IP fragmented packet and the source IP address of the received IP fragment. When the first fragment for a given fragmented packet is received, the IP header is also saved in the CCB for later recirculation. For subsequent fragments, the IP header need not be preserved.

  Once the CCB is allocated for collection and ordering of IP fragmented packets, in the next block 2560, the SPU 2200 is a pointer to the IP fragmented packet (excluding the IP header) in DRAM 2280 Is stored in the CCB. The pointer to the fragment can be provided in the CCB as a linked list, for example. Preferably, the SPU 2200 also updates the bit mask in the newly allocated CCB by marking a portion of the mask corresponding to the received fragment as received.

  In a next decision block 2570, the SPU 2200 determines whether all of the IP fragments from the packet have been received. This determination is preferably accomplished using a bit mask in the CCB. One skilled in the art will appreciate that there are a number of techniques that are readily available to implement the bit mask (ie, a uniform tracking mechanism) that can be used with the present invention. If all of the IP fragments for an IP fragmented packet have not been received, the semantic processor 2100 suspends further processing for the fragmented packet until it receives another fragment.

  If all of the IP fragments have been received, in the next block 2580, the SPU 2200 reads the IP fragments from the DRAM 2280 in the correct order and then for further analysis and processing, such as the intrusion detection process described above. Write them to the recirculation buffer 2160. In one embodiment of the invention, the SPU 2200 writes only the special header and the first part of the reconstructed IP packet (with the fragmentation bit not set) to the recirculation buffer 2160.

  Special headers allow DXP 2180 to handle reassembled IP fragmented packets stored in DRAM 2280 without having to forward all of the IP fragmented packets to recirculation buffer 2160 Makes it possible to orient. The special header can consist of a non-terminal symbol specified to load the parser grammar containing IDS operation 2018, and a pointer to the CCB. As a result, parser 180 can typically analyze the IP header and then proceed to the analysis of higher layer (eg, TCP) headers. Once the reconstructed syntax elements in the recirculating buffer 2160 that may contain viruses are identified, the DXP 2180 sends the SPU 2200 from the SCT 2210 to the intrusion detection operations 2050, 2052 and Signal to load an instruction to execute 2054. For example, if the reconstructed packet is identified as containing an email message, the DXP 2180 instructs the SPU 2200 to generate tokens corresponding to the various email fields described above. .

  FIG. 42B is a flowchart illustrating how IDS 2018 performs intrusion detection operations on multiple TCP packets. At block 2592A, a Transfer Control Protocol (TCP) session is established between the initiator and the network processing device that hosts the RSP 2100. RSP 2100 has the appropriate grammar in parser table 2170 and PRT 2190 and has microcode in SCT 2210 to establish a TCP session. In one embodiment, one or more SPUs 2200 organize and maintain state regarding TCP sessions. The cleanup and maintenance of state for this TCP session includes CCB allocation in DRAM 2280 for TCP reordering, window size limits, and when no additional TCP packets arrive from the initiator within the allocated time frame. And a timer for terminating the TCP session.

  After the TCP session with the initiator is established, at next block 2592B, the RSP 2100 waits for a TCP packet corresponding to the TCP session established at block 2592A to arrive at the input buffer 2140. The RSP 2100 may have multiple SPUs 2200 to process incoming data, so that the RSP 2100 also waits for the next TCP packet corresponding to the TCP session established in block 2592A. In parallel, multiple packets can be received and processed.

  The TCP packet is received at input buffer 2140 via input port 2120 at block 2592C, and DXP 2180 parses the TCP header of the packet in input buffer 2140. The DXP 2180 sends microinstructions to the assigned SPU 2200. When executed, the microinstruction requests the assigned SPU 2200 to read the received packet from the input buffer 2140 and write the received packet to the DRAM 2280 via the streaming cache 2270. The assigned SPU 2200 then provides a TCP CCB, stores a pointer in the TCP CCB that points to the location of the received packet in the DRAM 2280, and then restarts the timer in the TCP CCB. The assigned SPU 2200 is then freed and can be assigned as determined by DXP 2180 for further processing.

  In a next block 2592D, the received TCP packets are reordered to determine the proper sequence of payload data, if necessary. As is well known in the art, TCP packets are considered in proper order if all previous packets have arrived. If it is determined that the received packets are in the proper order, the responsible SPU 2200 loads the microinstruction for recirculation from the SCT 2210.

  In the next block 2592E, the assigned SPU combines the TCP connection information from the TCP header with the TCP non-termination to create a special TCP header. The allocated SPU 2200 then writes a special TCP header to the recirculation buffer 2160. In other ways, a special TCP header may be sent to the recirculation buffer 2160 that has a corresponding TCP payload.

  In the next block 2592F, the special TCP header and reconstructed TCP payload are parsed by the DXP 2180 to identify additional syntax elements in the TCP data. All syntax elements identified as possibly containing an intrusion are processed by the SPU 2200 in accordance with the intrusion detection operation described above.

Distributed token generation
FIG. 43 shows one embodiment of a distributed IDS system operating in a network 2600. The network 2600 includes different network processing devices 2610 that perform different functions, such as an email server 2610A, a firewall 2610B, and a web server 2610C. Each different network device 2610A-C executes IDS 2620A-C, similar to IDS 2018 described above. In one embodiment, one or more IDS 2620 is implemented using an RSP 2100 similar to that described in connection with FIGS. 36-41. However, in other embodiments, one or more IDS 2620 is implemented using a different hardware architecture.

  Each network processing device 2610 is connected to a central intrusion detector 2670 that performs centralized intrusion analysis. IDS 2620A-2620C parses the input data stream and generates tokens 2640A-2640C similar to token 2068, respectively, described above in connection with FIG. The token 2640 is sent to the central intrusion detector 2670.

  43-44, the central intrusion detector 2670 receives tokens (26402640A-2640C) from each of IDS 2620 (2620A-2620C) at block 2802. FIG. Intrusion detector 2670 analyzes traffic patterns for different data flows in accordance with each token 2640 at block 2804. Subsequently, a plurality of filters are generated according to this analysis at block 2806. Further, at block 2808, multiple threat signatures may be generated according to this analysis. These new filters and threat signatures are then distributed to each IDS 2620 at block 2810.

  In one example, the firewall 2610B of FIG. 43 may generate a token 2640B that identifies a new data flow received from the public Internet 2630. This token 2640B is sent to the central intrusion detector 2670 and identifies the new source IP address A. Web server 2610C may send token 2640C to intrusion detector 2670. The first token 2640C_1 identifies a new source IP address A, and the second token 2640C_2 indicates that this new source IP address A was used to access a file in web server 2610C .

  Central intrusion detector 2670 correlates tokens 2640B, 2640C_1 and 2640C_2 to identify potential viruses or malware that may not normally be detected. For example, intrusion detector 2670 determines that the new source IP address A received in firewall 2610B in token 2640B is the same as IP address A in which the file in web server 2610C is also open. May be. In this example, it is assumed that an external link from the public Internet 2630 does not open a file on the internal network.

  In this case, since token 2640B was received from firewall 2610B, central intrusion detector 2670 concludes that IP address A was received from external public Internet 2630. Thus, the central intrusion detector 2670 sends a new filter 2750 to the IDS 2620B in the firewall 2610B and, in some cases, sends a new filter 2750 to the other network devices 2610A and 2610C. The filter 2750 prevents a packet having the source IP address A from entering the network 2600.

  In another example, IDS 2620A in email server 2610A generates token 2640A_1. This token 2640A_1 indicates that an e-mail has been received from an unknown source IP address A. IDS 2620A also sends token 2640A_2. This token 2640A_2 specifies the MIME attachment file included in the electronic mail specified in the token 2640A_1.

  The central intrusion detector 2670 is based on the previously received tokens 2640B, 2640C_1 and 2640C_2 (from) and that all data flows associated with IP source address A may contain viruses or malware. judge. In response, the central intrusion detector 2670 may dynamically generate a new signature 2660 that corresponds to the name of the MIME attachment included in the token 2640A_2, content, or both. The central intrusion detector 2670 sends the new signature 2660 to IDS 2620A in the email server 2610A and, in some cases, sends the new signature 2660 to all other IDS 2620s operating in the network 2600. IDS 2620A then adds a new signature to the set of threat signatures 2058 shown in FIG.

  In this way, the IDS system 2600 can generate filters and signatures according to both the syntactic content of the token 2640 and the type of network processing device 2610 that sends the token. For example, token 2640B generated by firewall 2610B may be treated as more suspicious than tokens generated from other network processing devices in the network. In addition, as described above, information about the new IP address (IP packet received from the public Internet) identified by the firewall 2610B, other information detected by the email server 2610A or the web server 2610C In combination with information about operations, viruses can be detected more completely.

  In another example, the central intrusion detector 2670 can disable any network processing device associated with a detected virus or other malware. For example, virus 2660 may be detected by IDS 2662 running in PC 2650. IDS 2662 notifies central intrusion detector 2670 about virus 2660. The central intrusion detector 2670 then disconnects the PC 2650 from the network 2600 until the source of the virus 2660 is identified and excluded.

Scalability of Tree Search
IDS 2018 described above improves current intrusion detection performance by scanning within a session context where threats may emerge. For the matching pattern (matching pattern), a parser tree is used instead of a regular expression. Intrusion detection and other threat detection in the packet data is performed by "scanning" the incoming packet stream for patterns that match known threat patterns.

  Regular expression scanners must scan all bytes of a packet and do not have the ability to determine which part of a packet may contain a threat. For example, a threat in an email may only enter through an email attachment. The defined body of an email message is a string of ASCII characters. Normally, the software will not take unexpected or malicious actions according to this string. Attachments to email messages are defined by specific published syntax and headers such as Multipurpose Internet Mail Extensions (MIME).

  In addition, in many cases, IP protocol headers used to forward email messages do not cause email clients to take malicious action. Usually, execution of scripts and programs in emails causes intrusion problems. Therefore, to detect a potential virus, only the MIME part of the email message needs to be scanned.

  In order to detect the MIME part of an email message, it is necessary to understand the protocol (TCP / IP) and email MIME format used to transfer the email message. The RSP 2100 quickly analyzes and starts virus scanning only on the MIME part of the message in a scalable manner. This reduces the number of packets that must be scanned and also reduces the number of bytes that must be scanned in each packet. The RSP 2100 performs parsing of the input data stream. This allows IDS 2018 to understand what type of data needs to be scanned and then understands the type of scan that needs to be performed. This allows IDS 2018 to more efficiently generate token 2068 corresponding to the syntax of the input stream.

  The other features of the DXP 2180 and RSP 2100 are optimized for this type of threat scanning, improving performance compared to regular expression scanners using traditional hardware architectures. For example, the LL (k) parser combined with the ternary content addressable memory (TCAM) used in the parser table 2170 and parser stack 2185 of FIG. 36 searches the input stream earlier than the regular expression engine ( search).

  Regular expression scanners are required to look ahead for variable length and variable length data to determine whether there is a match (determine a possible match). Unpredictable matching (wild card matching) also requires unique operations. On the other hand, the LL (k) parser combined with TCAM skips past long unpredictable (wildcard) wildcard strings and matches all specific bytes in a single clock cycle.

Modifying session content
With respect to FIG. 45, IDS 2018 can also be used to add to or modify information in the identified session context 2852. In other words, IDS 2018 is not limited to removing packets that are recognized as being included in an intrusion threat. FIG. 45 shows a PC 2864 that has established an IP link 2866 with a network processing device 2856. IDS 2018 runs within device 2856 and identifies a specific session context 2852 associated with IP link 2866 as described above. For example, IDS 2018 may identify HTTP messages, FTTP messages, SMTP email messages, etc. sent by PC 2864 to other endpoint devices operating within WAN 2850.

  IDS 2018 can be programmed to add to or modify specific types of content 2862 associated with the identified session context 2852. In one example, IDS 2018 may be programmed to remove credit card number 2858 in a document (sentence) included in an email message or FTTP message. In another example, IDS 2018 may add a watermark 2860 to any document (sentence) identified within an FTTP document (sentence) or an email document (sentence). For example, the IDS 2018 may add a digital watermark 2860 to a document (sentence) that includes the IP source address of the PC 2864.

  DXP 2180 in RSP 2100 identifies the various session contexts 2852 that are carried over IP link 2866 as described above. The SPU 2200 may then generate tokens associated with various types of content 2862 associated with the identified session context 2852. For example, the SPU 2200 may generate a token that includes an email attachment as described above in connection with FIG. The RSP 2100 searches for any document (sentence) contained in the email attachment.

  In the first example, DXP 2180 may identify any IP packet that is destined for external WAN 2850. At that time, the DXP 2180 instructs the SPU 2200 to search all documents (sentences) included in the packet and including the credit card number. If a credit card number is detected, IDS 2018 replaces this credit card number with a sequence of “X” to hide the credit card information. In the second example, the SPU 2200 may add a digital watermark 2860 to a document (sentence) detected within an FTTP session or email session. Thereafter, the document (sentence) including the corrected credit card information and digital watermark information is sent to a destination address corresponding to the FTTP session or the electronic mail session.

  Similar modifications can be made to any type of content 2862 associated with any identified session context 2852. For example, a particular IP source address or IP destination address can be changed to another IP address, which is then sent back to the IP network according to some identified session context 2852 or session content 2862.

  FIG. 46 shows an example of a pushdown automaton (PDA) engine 3040 that uses Context Free Grammar (CFG) to retrieve data more efficiently. Semantic table 3042 includes non-terminal (NT) symbols 3046 that represent various semantic states. These symbols 3046 are managed by the PDA engine 3040. Each semantic state 3046 also has one or more corresponding semantic entries 3044. These semantic entries 3044 are associated with semantic elements 3015 included in the input data 3014. The arbitrary portion 3060 of the input data 3014 is combined with the current non-terminal symbol 3062 and used for the entry in the semantic table 3042.

  The index 3054 is output by the semantic table 3042. This index 3054 corresponds to entries 3046 and 3044 that match the combination of symbol 3062 and input data segment 3060. The semantic state map 3048 identifies the next terminal symbol 3054 that represents the next semantic state of the PDA engine 3040. The next non-terminal symbol 3054 is pushed onto the stack 3052. This symbol 3054 is then popped from the stack 3052 for combination with the next segment 3060 of the input data 3014. The PDA engine 3040 continues to analyze the input data 3014 until a target search string 3016 is detected.

  First, stack 3052 may include terminal and non-terminal (NT) symbols that allow the semantic state of PDA engine 3040 to be nested within other semantic states. Thereby, a plurality of semantic states can be represented by a single non-terminal symbol. This also significantly reduces the number of states that the PDA engine 3040 must manage.

  46 and 47, there is typically no semantic state transition until the associated semantic element is detected. For example, the PDA 3040 initially operates in the first semantic state (SS1) 3070 and goes to the second semantic state (SS2) 3072 until the complete semantic element “WWW.” Is detected. Do not migrate. Similarly, the PDA engine 3040 remains in the semantic state (SS2) 3072 until the next semantic element “.ORG” is detected. If there is one semantic element, the PDA engine 3040 transitions from the semantic state (SS2) 3072 to the semantic state (SS3) 3074. Thus, one of the features of PDA engine 3040 is the number of semantic states 3070, 3072, and 3074 that correspond to the number of semantic elements that need to be retrieved in input data 3014.

  Conversely, the PDA engine 3040 of FIG. 46 may not require any more semantic state to retrieve longer strings. For example, FIG. 48 shows another search requesting the PDA engine 3040 to search for the character string “WWWW.XXXX.ORGG”. In this example, the PDA engine 3040 further searches for the letter “W” in the first semantic element “WWWW.” And further searches for the letter “G” in the second semantic element “.ORGG”. Required. The additional characters added to the new search string of FIG. 48 does not increase the number of semantic states 3070, 3072, 3074 previously required in FIG.

The PDA engine 3040 can reduce or eliminate state branching. The PDA engine 3040 removes these additional branch states by nesting the possibility of the second “WWW.” String into the semantic state 3072 that searches for the semantic element “.ORG”. This is represented by path 3075 in FIG. In this case, the PDA engine 3040 remains in the semantic state 3072 while searching for the second “ WWW. ” Possibility and “.ORG”.

  In other aspects of the PDA engine 3040, additional search characters can be added without substantially affecting or increasing the complexity of the semantic table 3042. FIG. 49 shows the third semantic element “.EXE” as added to the search performed by the PDA engine 3040 of FIG. The additional semantic element “.EXE” adds only one additional semantic state 3076 to the semantic table 3042.

  The PDA architecture of FIG. 46 provides a more compact and efficient state table. The state table here is more predictable and can be expanded in a stable linear state when further search criteria are added. For example, if a new string is added to the data search, the entire semantic table 3042 does not need to be rewritten and only requires an incremental additional semantic state.

Example Implementation
50-54 show in more detail an example PDA context free grammar executed by the PDA engine 3040 previously shown in FIG. First, regarding FIG. 50, the same search example is used when the PDA engine 3040 searches for the URL character string “WWW.XXX.ORG”. Of course, this is only an example, and any character string or combination of characters can be searched using the PDA engine 3040.

  It is noted that the PDA engine 3040 can also run in software such that the semantic table 3042, the semantic state map 3048 and the stack 3052 are all located in memory accessed by the central processing unit (CPU). But The normal purpose CPU then performs the operations described below. In another embodiment, a reconfigurable semantic processor (RSP), described in more detail below in connection with FIG. 47, is used.

  In this example, a content addressable memory (CAM) is used to implement the semantic table 3042. In other embodiments, static random access memory (SRAM) or dynamic random access memory (DRAM) may be used. Semantic table 3042 is divided into semantic state sections 3046 as described above. This semantic state section 3046 can accommodate a corresponding non-terminal (NT) symbol. In this example, the semantic table 3042 has only two semantic states. The first semantic state in section 3046A is identified by non-terminal NT1 and is associated with the semantic element “WWW.”. The second semantic state in section 3046B is identified by non-terminal NT2 and is associated with the semantic element “.ORG”.

The second section 3044 of the semantic table 3042 contains various semantic entries that correspond to the semantic elements in the input data 3014. There may be a plurality of the same semantic entries in the same semantic state section 3046. For example, semantic entry WWW. May be placed at different locations in section 3046A to identify different locations where semantic element “WWW.” May appear in input data 3014. This is only an example and is used to further optimize the operation of the PDA engine 3040. In another embodiment, only certain semantic entries may be used once, and input data 3014 may be sequentially transferred to input buffer 3061 to match the location of each different data.

  The second semantic state section 3046B in the semantic table 3042 effectively includes two semantic entries. The “ORG.” Entry is used to detect the “ORG.” String in the input data 3014, and the “WWW.” Entry is the second “WWW.” Character that may be in the input data 3014. Used to detect a row. Again, multiple different “.ORG” and “WWW.” Entries are optionally loaded into section 3046B of semantic table 3042 for analysis optimization. It is equally possible to use a single “WWW.” Entry and a single “ORG.” Entry (ie fewer entries than those shown in FIG. 50).

  In this example, semantic state map 3048 includes three different sections. On the other hand, fewer sections may be used. The next state section 3080 maps the matching semantic entry in the semantic table 3042 to the next semantic state used for the PDA engine. The Semantic Entry Point (SEP) section 3078 is used to initiate microinstructions for the Semantic Processing Unit (SPU) described in more detail below. This section is optional and the PDA engine 3040 may otherwise use the non-terminal symbol identified in the next state section 3080 to perform other operations that are then performed on the input data 3014. To decide.

  For example, when the non-terminal symbol NT3 is output from the map 3048, the corresponding processor (not shown) recognizes that the URL character string “WWW.XXX.ORG” is detected in the input data 3014. The processor then performs all subsequent processing required for the input data 3014 after the PDA engine 3040 recognizes the URL. Thus, the SEP section 3078 is just one example of optimization of the PDA engine 3040 and may or may not be included.

  The skip byte section 3076 identifies several bytes from the input data 3014 to be transferred to the input buffer 3061 in the next operation cycle. A match all parser entry table (MAPT) 3082 is used when there is no match in the semantic table 3042.

Execution
The special terminal “$” of the operation symbol is first pushed onto the stack 3052 with the first non-terminal NT1. This non-terminal NT1 represents the first semantic state associated with retrieving the URL. The NT1 symbol and first segment 3060 of the input data 3014 are loaded into the input buffer 3061 and sent to the CAM 3090. In this example, the content in input buffer 3061 does not match any entry in CAM 3090. Thus, the pointer 3054 generated by the CAM 3090 points to the default NT1 entry in the MAPT table 3082. The default NT1 entry instructs the PDA engine 3040 to move the next byte of input data 3014 to the input buffer 3061. The PDA engine 3040 then pushes the next non-terminal NT1 symbol onto the stack 3052.

  FIG. 51 shows the next PDA cycle after the next byte of input data 3014 has been moved to input buffer 3061. First URL semantic element 3060A (“WWW.”) Is currently housed in input buffer 3061. Non-terminal symbol NT1 is again popped from stack 3052 and combined with input data 3060 in input buffer 3061. When the contents of the input buffer 3061 and the semantic table 3042 are compared, a match occurs in the NT1 entry 3042B. Index 3054B associated with table entry 3042B points to semantic state map entry 3048B. The next state in entry 3048B includes non-terminal symbol NT2. This non-terminal symbol NT2 represents a transition to the next semantic state.

  Map entry 3048B also identifies the number of bytes required by PDA engine 3040 to transfer input data 3014 for the next analysis cycle. In this example, the string “WWW.” Is detected in the first 4 bytes in the input buffer 3061, so the skip byte value in entry 3048B is input to the PDA engine 3040 with the next (another) 8 bytes. Command to move to buffer 3061. The skip byte value depends on the hardware, and may vary depending on the size of the semantic table 3042. Of course, a larger hardware semantic table or another hardware implementation having a smaller width semantic table may be used.

  FIG. 52 shows the next PDA engine 3040 cycle after the next 8 bytes of input data 3014 have been moved to the input buffer 3061. Similarly, a new semantic state NT2 is pushed onto stack 3052 and then popped off stack 3052 and combined with the next segment of input data 3014. The content in the input buffer 3061 is again entered in the semantic table 3042. In the PDA cycle, the content in the input buffer 3061 does not match any semantic entry in the semantic table 3042. Thus, the default pointer 3054C for the NT2 state points to the corresponding NT2 entry in MAPT 3082. This NT2 entry instructs the PDA engine 3040 to move the next (additional) byte to the input buffer 3061 and push the same semantic state NT2 onto the stack 3052.

  FIG. 53 shows the next PDA cycle after the next byte of input data 3014 has been moved to input buffer 3061. In this example, there is still no match between the content in the input buffer 3061 and the NT2 entry in the semantic table 3042. Thus, the default pointer 3054C for semantic state NT2 points again to the NT2 entry in MAPT 3082. The default NT2 entry in table 3082 instructs PDA engine 3040 to move the next byte from input data 3014 to input buffer 3061 and push another NT2 symbol onto stack 3052. Note that there is no semantic state transition represented by the non-terminating NT2 during the last two PDA cycles (FIGS. 52 and 53). Therefore, even if the PDA engine 3040 receives “.OR” which is the first three characters of the second semantic element “.ORG”, there is no state transition.

  FIG. 54 shows the next PDA cycle in which the content in the input buffer 3061 matches the NT2 entry 3042D in the semantic table 3042. Corresponding pointer 3054D points to entry 3048D in semantic state map 3048. In this example, the entry 3048D indicates that the URL “WWW.XXX.ORG” has been detected by mapping to the next semantic state NT3. Note that PDA engine 3040 does not transition to semantic state NT3 until the complete semantic element “.ORG” is detected.

  The map entry 3048D also includes a pointer SEP1 that activates a microinstruction that is optionally executed by a semantic processing unit (SPU) (see FIG. 55). This microinstruction is for performing further operations on input data 3014 corresponding to the detected URL. For example, the SPU may also peel off additional input data 3014 from the other (peel off) to perform firewall operations, virus detection operations, etc. as described in the co-pending application below. Good. The simultaneous continuation application here refers to US patent application No. 11 / 187,049 entitled “Network Interface and Firewall Device” filed on July 21, 2005, and filed on May 9, 2005. US patent application No. 11 / 125,956 entitled “Intrusion Detection System”. Both of which are incorporated herein by reference.

  Map entry 3048D may instruct PDA engine 3040 to push a new semantic state represented by non-terminal NT3 onto stack 3052 at the same time that it invokes the SEP microinstruction for the SPU. This may cause the PDA engine 3040 to initiate another search for other semantic elements in the input data 3014 following the detected URL 3016. For example, as shown in FIG. 49, the PDA engine 3040 may start searching for a semantic element “.EXE” associated with an executable file that may be included in the input data 3014. Good. Also, as described above, searching for a new semantic element “.EXE” only requires the PDA engine 3040 to add an additional semantic state to the semantic table 3042.

  Also, as described above, the PDA engine 3040 does not have to maintain a separate state for each analyzed data item. State is maintained only for transitions between different semantic elements. For example, FIGS. 50, 52, and 53 illustrate data entries that do not perfectly match any of the semantic entries in the semantic table 3042. FIG. In these situations, the PDA engine 3040 continues to analyze the data without retaining any state for the mismatched data string.

  Also, as described above in connection with FIGS. 46-48, the semantic state within the PDA engine 3040 is substantially independent of the length of the search string. For example, searching for a longer search string “WWWW.” Instead of “WWW.” Simply replaces the semantic entry “WWW.” In the semantic table 3042 with the long semantic entry “WWWW.” This can be done simply by adjusting the skip byte value in the map 3048.

Reconfigurable Semantic Processor (RSP)
FIG. 55 shows a block diagram of a reconfigurable semantic processor (RSP) 2100 that is used to implement the pushdown automaton (PDA) engine 3040 described above in one embodiment. The RSP 3100 includes an input buffer 3140 for buffering a packet data stream received via the input port 3120, and an output buffer 3150 for buffering a packet data stream output via the output port 3152. Have.

  A direct execution parser (DXP) 3180 utilizes the PDA engine 3040 and receives packets or frames (eg, an input “stream”) received at the input buffer 3140 and packets or frames (eg, output) output to the output buffer 3150. “Stream”) and the processing of packets or frames that are recirculated in recirculation buffer 3160 (eg, recirculation “stream”). Input buffer 3140, output buffer 3150 and recirculation buffer 3160 are preferably first-in first-out (FIFO) buffers.

  In addition, the DXP 3180 controls packet processing by a semantic processing unit (SPU) 3200. This semantic processing unit (SPU) controls the transfer of data between the buffers 3140, 3150 and 3160 and the memory subsystem 3215. Memory subsystem 3215 stores packets received from input port 3120 and for integrated policy management (UPM), firewall, virus detection and some other operations described in the following continuation application: The access control list (ACL) to be used is stored in the CAM 3220.

  The simultaneous continuation application here refers to US patent application No. 11 / 187,049 entitled “NETWORK INTERFACE AND FIREWALL DEVICE” filed on July 21, 2005. , US Patent Application No. 11 / 125,956, entitled “INTRUSION DETECTION SYSTEM”, filed on May 9, 2005. Both of which are incorporated herein by reference.

  The RSP 3100 uses at least three tables to execute a predetermined PDA algorithm. A code 3178 for retrieving the generation rule 3176 is stored in the parser table (PT) 3170. In one embodiment, the parser table 3170 contains a semantic table 3042 shown in FIG. The grammar generation rule 3176 is stored in a generation rule table (PRT) 3190. The generation rule table 3190 may accommodate, for example, the semantic state map 3048 shown in FIG. Code segments 3212 executed by the SPU 3200 are stored in a semantic code table (SCT) 3210. These code segments 3212 may be activated according to the SEP pointer 3078 in the semantic state map 3048 shown in FIGS. 50-54.

  The code 3178 in the parser table 3170 is stored in a manner such as a matrix (row-column) format or a content addressable format. In the row-column format, the rows of the parser table 3170 are indexed by the non-terminal code NT 3172 provided by the internal parser stack 3185, and the columns of the parser table 3170 are extracted from the beginning of the data in the input buffer 3140. Is indexed by the input data value DI [N] 3174. In the content addressable format, as shown by the input buffer 3061 in FIG. 50-54, a concatenation of the non-terminal code 3172 from the parser stack 3185 and the input data value 3174 from the input buffer 3140 is obtained. Make entries for table 3170.

  The production rule table 3190 is indexed by the code 3178 from the parser table 3170. Tables 3170 and 3190 may be linked so that queries against parser table 3170 send directly back production rules 3176 applicable to non-terminal code 3172 and input data value 3174. The DXP 3180 replaces the non-terminal code at the top of the parser stack 3185 with a production rule (PR) 3176 sent back from the PRT 3190, and then continues to analyze the data from the input buffer 3140.

  Semantic code table 3210 is also indexed by code 3178 generated by parser table 3170, generation rule 3176 generated by generation rule table 3190, or both. Typically, the analysis results allow the DXP 3180 to detect whether the SPU 3200 should load and execute the semantic entry point (SEP) routine 3212 from the semantic code table 3210 for a given production rule 3176. To do.

  The SPU 3200 has several access paths to the memory subsystem 3215 that provides a structured memory interface that can be addressed by context symbols. Memory subsystem 3215, parser table 3170, generation rule table 3190 and semantic code table 3210 can be internal memory or external memory devices (eg synchronous dynamic random access memory (DRAM) or content addressable memory (CAM)) Or use a combination of these resources. Each table or context need only provide a context interface to a shared physical memory area that has one or more other tables or contexts.

  A maintenance central processing unit (MCPU) 3056 is connected between the SPU 3200 and the memory subsystem 3215. The MCPU 3056 executes functions desirable for the RSP 3100 that can be easily performed by conventional software and hardware. These functions are usually functions that are rarely used and are not executed with the highest priority (not important in time), and are not intended to be included in the SCT 210 due to the complexity of the functions. The MCPU 3056 preferably has a function of requesting the SPU 3200 to execute a task instead of the MCPU.

  The memory subsystem 3215 includes an array machine context data memory (AMCD) 3230 for accessing data in the DRAM 3280 via a hash function (hashing function) or content addressable memory (CAM) search. The encryption processing block 3240 performs data encryption, decryption, and authentication, and the context control block cache 3250 caches the context control block to the DRAM 3280 and caches the context control block from the DRAM 3280. The normal cache 3260 caches the data used in the basic operations, and the streaming cache 3270 is responsible for these while the data stream is being written to the DRAM 3280 and while the data stream is being read from the DRAM 3280. Cache the data stream. The context control block cache 3250 is preferably a software controlled cache. That is, SPU 3200 preferably determines when a cache line is used and when it is released. Circuits 3240, 3250, 3260 and 3270 are all connected between DRAM 3280 and SPU 3200. TCAM 3220 is connected between AMCD 3230 and MCPU 3056 and has access control list (ACL) tables and other resources that may be used to perform firewalls, integrated policy management, and other intrusion detection operations. Contains parameters.

  A more detailed design optimization for the functional blocks of the RSP 3100 is described in co-pending US patent application No. 10 / 351,030, filed January 24, 2003, entitled "Reconfigurable Semantic Processor". Are listed. This patent application is incorporated herein by reference in its entirety.

Parser table
As described above in connection with FIGS. 46-54, parser table 3170 is implemented as a content addressable memory (CAM) and NT code 2172 and input data value DI [n] 2174 are generated by CAM in PRT 3190. It may be used as a key for searching for the PR code 3178 corresponding to the rule. The CAM is preferably a ternary CAM (TCAM) populated with TCAM entries. Each TCAM entry includes an NT code and a DI [n] match value. Each NT code can hold multiple TCAM entries. Each bit of DI [n] match value can be set to “0”, “1”, or “X”. This “X” represents “Don't Care”. With this function, the PR code requires that only a few bits or bytes of DI [n] 2174 match the coded pattern in order for parser table 3170 to find a match. For example, a line in the TCAM may contain the NT code NT_IP for the IP destination address field, followed by 4 bytes representing the IP destination address corresponding to the device containing the semantic processor. The remaining 4 bytes of this TCAM line are set to “Don't Care”. Thus, when NT_IP and 8-byte DI [8] are presented to the parser table 3170, if the first 4 bytes of DI [8] contain the correct IP address, the end of DI [8] A match will occur no matter what the 4 bytes contain.

  TCAM uses the “Don't Care” function and there can be multiple TCAM entries for a single NT, so the TCAM is for a given NT code and DI [n] conformance value. Multiple matching TCAM entries can be found. TCAM prioritizes these matches across its hardware, and outputs only the top priority match. In addition, if the NT code and DI [n] match value (DI [n] match value) are presented to the TCAM, the TCAM receives all TCAM entries in parallel and receives the NT code and DI [n] match value. Try to fit with. Therefore, the TCAM has a function of determining whether a match is found in the parser table 3170 in one clock cycle of the semantic processor 3100.

  Another way of looking at this architecture is to look at it as a “variable look-ahead” parser. A constant data input segment (e.g., 8 bytes) is input to the TCAM, but due to the encoding of the TCAM, the next generation rule (or semantic entry as described in connection with FIGS. Allows to be generated based on any part of the byte input. If only one bit or one byte in any part of the current 8 bytes at the beginning of the input stream is relevant to the current rule, the TCAM entry ignores the rest during matching You may code as follows. In essence, the current “symbol” can be defined by some combination of 64-bits at the beginning of the input stream for a given production rule. In general, with reasonable coding, the number of analysis cycles, the number of NT codes, and the number of table entries can be reduced for a given analysis task.

  The implementation of the production rule table 3170 by TCAM is described in further detail in the following co-pending application. The simultaneous continuation application mentioned here is an invention called “PARSER TABLE / PRODUCTION RULE TABLE CONFIGURATION USING CAM AND SRAM” filed on July 14, 2005. No. 11 / 181,527, the name of which is incorporated herein by reference in its entirety.

  The system described above can use a dedicated processor system, microcontroller, or programmable logic device that performs all or some of the above operations. Also, some of the operations described above may be performed in software, and other operations may be performed in hardware.

  For convenience, the operations have been described as interconnected functional blocks or distinguishable software modules. However, this is not necessarily the case, and there are cases where these functional blocks or modules are equivalently integrated into a single logical device, program, or operation in an ambiguous manner. Also good. In any case, the functional blocks and software modules described above and the features of the flexible interface may be implemented by themselves or in combination with other operations in hardware or software.

  Having described and described the essence of the present invention in the preferred embodiment of the present invention, it should be understood that the present invention may be modified in construction and detail without departing from the essence thereof. We claim all modifications and variations that do not depart from the spirit and scope of the claims.

FIG. 2 is a block diagram of a network processing device using a reconfigurable semantic processor (RSP). It is a block diagram which shows the said RSP in more detail. It is a more detailed diagram showing a parser table and a generation rule table used in the RSP. FIG. 2 illustrates how a denial of service (DoS) attack invalidates a network processing device. FIG. 3 shows how a firewall associates DoS attacks with different zones. FIG. 5 is a more detailed view of the firewall shown in FIG. It is a figure which shows how the memory in a firewall is divided | segmented into different generation. FIG. 7 is a flowchart of how the firewall operates between the different generations shown in FIG. 6 is a flowchart showing how the firewall of FIG. 5 handles a DoS attack. FIG. 2B is a block diagram showing how the RPS shown in FIG. 2A is configured to handle a DoS attack. 10 is a flowchart showing how the RSP shown in FIG. 9 processes candidate packets. 10 is a flowchart showing how the RSP shown in FIG. 9 processes candidate packets. It is a block diagram which shows the firewall and routing apparatus which operate | move independently. FIG. 2 illustrates a packet processing architecture that provides integrated routing and firewall policy management (UPM). It is a figure which shows the sample entry in an access control list (ACL) table. 14 is a flowchart illustrating how the packet processor of FIG. 13 provides UPM. FIG. 6 is a block diagram illustrating another example of a UPM table that provides a send action based on upper layer packet characteristics. FIG. 6 is a block diagram illustrating an example of how an integrated UPM can be used to route packets according to different resource locator (URL) values. It is a block diagram which shows an example of how integrated policy management is performed in RSP. 19 is a flowchart showing how the RSP of FIG. 18 operates. It is a figure which shows how RSP is used for network address translation (NAT) and port address translation (PAT). FIG. 4 is a more detailed diagram showing how RSP is configured for NAT / PAT conversion and IP packet conversion. It is a flowchart which shows how RSP performs NTA / PAT conversion. It is a flowchart which shows how RSP performs NTA / PAT conversion. FIG. 3 is a diagram showing how RSP converts a packet between IPv4 and IPv6. It is a flow chart showing in more detail how RSP translates packets between IPv4 and IPv6. FIG. 3 shows how RSP is used for virtual private network (VPN) integration. FIG. 3 shows how RSP is used for virtual private network (VPN) integration. FIG. 3 shows how a firewall assigns anti-virus licenses to different sub-networks. FIG. 3 shows how a firewall assigns anti-virus licenses to different sub-networks. FIG. 3 shows how multiple RSPs are connected together for distributed firewall processing. FIG. 3 shows how multiple RSPs are connected together for distributed firewall processing. 1 is a block diagram illustrating an intrusion detection system (IDS) implemented in a private network. It is a block diagram which shows the limit of the conventional approach detection system (IDS). FIG. 32B illustrates one embodiment of the intrusion detection system (IDS) of FIG. 32A that identifies syntax elements in a data stream and uses the syntax elements to identify threats. FIG. 3 is a block diagram illustrating how an intrusion detection system (IDS) is implemented using a reconfigurable semantic processor (RSP). It is a flowchart which shows how the approach detection system (IDS) of FIG. 33 operate | moves. FIG. 34 is a detailed block diagram of an intrusion detection system (IDS) shown in FIG. 33. FIG. 34 is a block diagram of the reconfigurable semantic processor (RSP) shown in FIG. 33. FIG. 3 shows how an RSP direct execution parser (DXP) identifies packets containing email messages. FIG. 3 shows how an RSP direct execution parser (DXP) identifies packets containing email messages. FIG. 6 is a flowchart illustrating how RSP applies a threat filter to a data stream. It is a flowchart which shows how RSP performs a session lookup. It is a flowchart which shows how RSP produces | generates a token from an input stream. FIG. 6 is a flow chart showing how RSP reconstructs a fragmented packet prior to an entry detection operation. FIG. 5 is a flowchart showing how the RSP reorders TCP packets before an entry detection operation. FIG. 3 illustrates how a central ingress detector correlates tokens generated from different network processing devices. FIG. 6 is a flow chart illustrating how a central ingress detector correlates tokens generated from different network processing devices. FIG. 3 shows how IDS is used for modifying or removing information from a data stream. 1 is a diagram showing a PDA (PushDown Auomaton) engine. FIG. FIG. 47 is a semantic state diagram showing how the PDA engine of FIG. 46 performs a URL search. FIG. 4 is a semantic state diagram showing how the PDA engine uses the same number of semantic states to search for long strings. FIG. 3 shows how the PDA engine only uses one additional semantic state to search for additional semantic elements. It is a detailed diagram showing an example of how the PDA engine performs a URL search. It is a detailed diagram showing an example of how the PDA engine performs a URL search. It is a detailed diagram showing an example of how the PDA engine performs a URL search. It is a detailed diagram showing an example of how the PDA engine performs a URL search. It is a detailed diagram showing an example of how the PDA engine performs a URL search. FIG. 3 is a detailed diagram showing how a PDA engine is executed in a reconfigurable semantic processor (RSP).

Claims (45)

A method of monitoring and filtering DoS (Denial of Service) attacks,
Identifying packets associated with a possible DoS attack;
Tracking the state of the packet as a DoS entry in memory;
If there is no previous DoS entry in the memory, allowing a new packet to pass; and
Adding a new DoS entry to the memory for the new packet after the new packet has already been allowed to pass. Receiving a packet that already has a DoS entry in the memory;
If a DoS attack flag is set in the corresponding DoS entry, excluding the packet; and
The method of claim 1, further comprising: updating a time stamp, a counter, and a DoS flag for the corresponding DoS entry if the time stamp is older than a predetermined time. Receiving a packet that already has a DoS entry in the memory;
If a DoS attack flag is not set in the corresponding DoS entry, allowing the packet to pass; and
Incrementing a counter for the corresponding DoS entry after the new packet is already allowed to pass;
2. The method according to claim 1, further comprising: setting a DoS attack flag when the value of the counter is equal to or greater than a DoS attack threshold and the time stamp for the corresponding DoS entry is within a predetermined time. Method.   A network processing device with a processor configured to use the same memory subsystem as a forwarding information base (“FIB”) and for firewall policy management.   The processor determines destination addresses and firewall policy metrics contained in a plurality of packets to access control lists (Access Control Lists) in the memory subsystem to make both routing and switching decisions and perform firewall operations. 5. The network processing device of claim 4, wherein the network processing device is adapted to be compared with the same set of entries of “ACL”.   The ACL entry includes a predicate corresponding to a destination address and a firewall policy metric included in the packet, and an action indicating what firewall or transmission operation should be performed on the packet. The network processing device described. The processor is configured to identify an address and firewall policy metrics in a plurality of packets;
5. The network processing device of claim 4, comprising one or more semantic processing units that perform both a firewall operation and a packet transmission operation for the packet according to the identified address and firewall policy metrics. A direct execution parser that parses a plurality of packets to identify a syntax element associated with a plurality of network interface operations and then invokes a plurality of microinstructions according to the identified syntax element;
A semantic processor comprising: one or more semantic processing units that perform the network interface operation by executing the microinstructions activated by the direct execution parser. An input port configured to receive data symbols;
A direct execution parser stack storing stack symbols, wherein the parser processes the stack symbols in response to the received data symbols;
A parser table storing data of generation rule codes that can be indexed by a combination of at least one received data symbol and a symbol supplied by the parser;
A production rule table storing production rule data that can be indexed by the production rule code;
9. The semantic processor according to claim 8, further comprising a semantic code table that is accessible by the semantic processing unit and stores data of machine instructions indexed by the generation rule code.   The parser identifies a plurality of DoS packets that may be part of a DoS attack in some cases, causes the semantic processing unit to monitor the rate at which the DoS candidate packets are received, and according to the monitored rate The semantic processor according to claim 8, wherein it is determined whether to exclude or pass the packet of the DoS candidate.   An access comprising a packet semantic element identified by the parser and an entry having a predicate corresponding to the action, and an action used by the semantic processing unit to determine what firewall or transmission operation should be performed on the packet. The semantic processor according to claim 8, further comprising a control list (ACL).   And further comprising a forwarding information base (FIB) including a destination address and an output port corresponding to the destination address, wherein the semantic processing unit uses the combination of the predicate from the ACL and the destination address from the FIB. 12. The semantic processor according to claim 11, wherein the semantic processor is adapted to determine how to transmit and process.   The ACL includes different URL predicates associated with different output ports for the same destination address predicate, the parser identifies a destination address and URL value included in the packet, and the semantic processing unit includes: 13. The semantic processor of claim 12, wherein the semantic processor is adapted to send the packet to an output port identified by the ACL having a matched destination address and URL predicate.   Further comprising a Network Address Translation and / or Protocol Address Transmission (NAT / PAT) lookup table that matches the public address to the private address, the parser comprising a public address in the packet or 9. The semantic processor according to claim 8, wherein a private address is identified and the semantic processing unit is instructed to replace the public address or private address with a corresponding public address or private address from the lookup table.   An Internet Protocol (IP) version translation table that maps a first IP version format to a corresponding address in a second IP version format, wherein the parser identifies an IP version used in the packet, and the semantic The semantic processor of claim 8, instructing a processing unit to replace an address in the packet with a different address for the other IP version.   A virtual private network (VPN) table associated with an encryption key, an encryption algorithm identifier and / or SPI (Security Parameter Indices), wherein the parser identifies an SPI in the packet; Apply to the semantic processing unit the SPI that matches the identified SPI to the virtual private network table and then the certified key returned from the encryption key, encryption algorithm identifier and / or virtual private network The semantic processor of claim 8, wherein the packet is encrypted according to an algorithm identifier. A data parser that identifies syntax elements in the data stream;
An intrusion detection system comprising: a threat filtering circuit that filters threats from the data parser according to a syntax element identified by the data parser.   18. The intrusion detection system according to claim 17, further comprising a delay buffer used by the threat filtering circuit to delay the output of the data stream for a substantially constant time while filtering the threat.   The threat filtering circuit performs a first initial threat filtering of the data stream using a first set of a plurality of a priori access control list (ACL) filters, and a plurality of access controls generated according to the identified syntax element. 19. The intrusion detection system of claim 18, wherein a second set of data in the delay buffer is performed using a second set of list (ACL) filters.   18. The threat filtering circuit of claim 17, wherein the threat filtering circuit generates a token from the identified syntax element applied to a threat signature and dynamically generates a set of multiple threat filters corresponding to the syntax element. Intrusion detection system.   21. The token is generated only for syntax elements in the data stream that may be associated with a threat, and no token is generated for other parts of the data stream. Intrusion detection system as described in.   The intrusion detection system according to claim 17, wherein the data parser analyzes the data according to symbols included in a parser stack.   The parser has a parser table including production rule rule codes corresponding to the different syntax elements in the data stream, and according to the production rule rule code symbols from the parser stack and portions of the data stream 23. The intrusion detection system of claim 22 that is indexed.   And further comprising a production rule table including production rules indexed by the production rule code, wherein some of the production rules are adapted to filter the threat from the data stream when the threat filtering is performed. 24. The intrusion detection system of claim 23, comprising production rules executed by the circuit.   And a central intrusion detection device that receives tokens from a plurality of threat filtering circuits in the plurality of network processing devices, wherein the plurality of network processing devices are a plurality of different ones processed by the plurality of network processing devices. A plurality of different syntax elements of the data stream are identified, the central intrusion detection device generating a plurality of filters according to the plurality of different syntax elements and returning the filters to the different network processing devices The intrusion detection system according to claim 17 for distribution.   26. The intrusion detection system according to claim 25, wherein the central intrusion detection device generates the filter according to a network processing operation performed by a network processing device that transmits the token.   18. The intrusion detection system of claim 17, further comprising a recirculation buffer that reconstructs a plurality of fragmented packets from the data stream before the threat filtering circuit filters threats from the data stream. A direct execution parser that identifies syntax elements in the data stream;
A semantic processor comprising one or more semantic processing units that perform intrusion detection processing on the data stream in accordance with syntax elements identified by the direct execution parser.   29. The semantic of claim 28, further comprising a parser table comprising a plurality of sets of production rule codes indexed by combining a non-terminal symbol corresponding to the syntax element with a portion of the data stream. Processor.   And a generation rule table including a plurality of generation rules indexed by the generation rule code of the parser table, wherein at least some of the plurality of generation rules execute the intrusion detection process. 30. The semantic processor of claim 29, comprising a plurality of SPU entry point values indexing a plurality of microinstructions executed by the semantic processing unit.   The one or more semantic processing units compare a plurality of packets in the data stream with a first set of a priori ACL filters and then discard or store the plurality of packets according to the result of the comparison 30. The semantic processor of claim 28.   32. The semantic processor according to claim 31, wherein the one or more semantic processing units store the packet for a predetermined delay time while executing the intrusion detection processing.   The one or more semantic processing units generate a plurality of tokens from the plurality of syntax elements identified by the direct execution parser, and dynamically generate an access control list (ACL) corresponding to the tokens. 33. The semantic processor of claim 32, wherein the semantic processor is supplied to a threat analyzer that generates the same.   The semantic processor of claim 33, wherein the one or more semantic processing units discard packets that match (match) the dynamically generated access control list from the stored packets.   And further comprising a recirculation buffer used by the one or more semantic processing units to reconstruct a plurality of fragmented packets from the data stream, wherein the direct execution parser comprises the reconstructed plurality of 29. The semantic processor of claim 28, wherein a plurality of syntax elements are identified in the packet, and the one or more semantic processing units perform intrusion detection processing according to the identified plurality of syntax elements.   The direct execution parser identifies a plurality of SMTP (Simple Mail Transport Protocol) packets in the data stream, and sends a plurality of email elements from the plurality of SMTP packets to the one or more semantic processing units. 29. The semantic processor of claim 28, instructing to generate and use the extracted email element to generate a set of email threat filters that are later applied to the SMTP packet.   A PDA (PushDown Automaton) engine having a semantic table composed of a plurality of sections corresponding to a plurality of different PDA semantic situations, wherein at least some of the plurality of sections may be included in input data. Including one or more entries corresponding to a semantic element of a number of characters, the semantic table being indexed by combining a plurality of symbols identifying the different semantic situations into a plurality of segments of the input data PDA engine characterized by being made into.   38. The PDA engine of claim 37, further comprising a semantic status stamp that identifies a next PDA status according to a semantic entry in a current PDA semantic status that matches the matched symbol and a segment of input data.   39. The PDA engine of claim 38, further comprising a stack that pops a symbol for combining with the plurality of input data segments and pushes the next symbol identified by the semantic status stamp.   40. The PDA engine of claim 39, wherein the stack includes a plurality of non-terminal symbols that represent a number of previous semantic situations.   38. The semantic table converts between different PDA semantic situations according to the semantic element specified in the input data and independent of individual characters that may be included in the semantic element. PDA engine.   The semantic table has a content addressable memory (CAM), and the location of the semantic entry in the content addressable memory is input data used to specify the next semantic situation. 38. The PDA engine according to claim 37, which matches (matches) the semantic element in.   In addition, it includes a skip data map indexed by the content addressable memory, wherein the skip data map identifies an amount of input data and shifts to the PDA engine for comparison with the plurality of semantic entries. 43. A PDA engine according to claim 42 configured as described above.   38. A reconfigurable semantic processor further comprising one or more semantic processing units (“SPUs”) that perform further processing of the input data according to the semantic elements identified by the semantic table. PDA engine described in 1.   45. The PDA engine of claim 44, further comprising a semantic entry point map indexed by the semantic table to invoke a plurality of microinstructions executed by the one or more semantic processing units.

Images