Source: http://www.google.com/patents/US7913294?dq=6,952,563
Timestamp: 2014-09-01 07:30:31
Document Index: 12950786

Matched Legal Cases: ['ART 800', 'ART 800', 'ART 800', 'ART 800', 'ART 800', 'ART 800', 'ART 800', 'ART 800']

Patent US7913294 - Network protocol processing for filtering packets - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsMethod and apparatus for network protocol filtering of a packet is described. An index to a table is obtained and stored to travel with the packet. The index is obtainable to access the table to obtain packet information. In particular, a method for inbound network address translation packet filtering...http://www.google.com/patents/US7913294?utm_source=gb-gplus-sharePatent US7913294 - Network protocol processing for filtering packetsAdvanced Patent SearchPublication numberUS7913294 B1Publication typeGrantApplication numberUS 10/603,416Publication dateMar 22, 2011Filing dateJun 24, 2003Priority dateJun 24, 2003Publication number10603416, 603416, US 7913294 B1, US 7913294B1, US-B1-7913294, US7913294 B1, US7913294B1InventorsThomas A. Maufer, Paul J. Gyugyi, Sameer Nanda, Paul J. SidenbladOriginal AssigneeNvidia CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (110), Non-Patent Citations (13), Referenced by (16), Classifications (34), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetNetwork protocol processing for filtering packetsUS 7913294 B1Abstract Method and apparatus for network protocol filtering of a packet is described. An index to a table is obtained and stored to travel with the packet. The index is obtainable to access the table to obtain packet information. In particular, a method for inbound network address translation packet filtering and a method for outbound packet filtering are described.
1. A method for network protocol filtering of a packet using an address resolution table that is cross-linked with a state table associating data structures with NAT address information and that is indexed with an address resolution table index (ART index), the packet having a Media Access Control (MAC) destination address, the method comprising:
obtaining packet information for the packet including the MAC destination address;
determining that the MAC destination address is included in an entry in the address resolution table;
obtaining the ART index associated with the MAC destination address from the entry in the address resolution table, wherein the ART index is an index into the state table for locating an entry in the state table associating data structures with NAT address information; and
storing the ART index and the packet information in a data structure associated with the state table associating data structures with NAT address information.
determining whether the packet is for a new connection; and
responsive to the packet not being for the new connection, determining whether the packet information is in the address resolution table.
3. The method, according to claim 2, wherein the packet type is a Transmission Control Protocol type.
4. The method, according to claim 1, wherein the packet type is a User Datagram Protocol type.
5. The method, according to claim 1, wherein the packet information is a five-tuple including source and destination addresses, source and destination ports, and a packet type identifier.
6. The method, according to claim 1, wherein the packet type is a Generic Routing Encapsulation type.
7. The method, according to claim 6, wherein the packet information is a five-tuple including source and destination addresses, an apportioned Generic Routing Encapsulation identifier, and a packet type identifier.
8. The method, according to claim 1, wherein the packet type is an Internet Protocol Security type.
9. The method, according to claim 8, wherein the packet information is a five-tuple including source and destination addresses, an apportioned security parameter string, and a packet type identifier.
10. A method for inbound network address translation packet filtering using an address resolution table that is cross-linked with a state table associating data structures with NAT address information and that is indexed with an address resolution table index (ART index), the packet having a Media Access Control (MAC) destination address, the method comprising:
obtaining a packet;
determining whether type of the packet is one of a Transmission Control Protocol, a User Datagram Protocol, a Generic Routing Encapsulation, an Internet Protocol Security and an Internet Control Message Protocol type;
if the type is the Transmission Control Protocol type, determining if the packet is an initial packet for a connection;
if the type is the Transmission Control Protocol type and the packet is for an existing connection or if the type is one of the User Datagram Protocol type, the Generic Routing Encapsulation type and the Internet Protocol Security type,
obtaining packet information from the packet including the MAC destination address;
determining that the MAC destination address is included in the address resolution table;
storing the ART index and the product information in the data structure associated with the state table associating data structures with NAT address information.
checking validity of layers of the packet;
checking Internet Protocol options for the packet; and
determining whether the packet is a fragment.
12. The method, according to claim 10, wherein the data structure is for a plurality of canonical frame headers.
13. The method, according to claim 10, wherein the state table is a connection table.
14. A method for outbound packet filtering using an address resolution table that is cross-linked with a state table associating data structures with NAT address information and that is indexed with an address resolution table index (ART index), the packet having a Media Access Control (MAC) destination address, the method comprising:
determining whether an incoming interface for the packet is running network address translation;
if the incoming interface is running the network address translation,
obtaining a first index from a data structure associated with the packet; and
obtaining packet information in a first table using the first index;
if the type is the Transmission Control Protocol type and the packet is for an existing connection or if the type is the User Datagram Protocol type,
obtaining the packet information from the packet including the MAC destination address,
determining that the MAC destination address is included in the address resolution table,
obtaining the ART index associated with the MAC destination address from the entry in the address resolution table, wherein the ART index is an index into the state table for locating an entry in the state table associating data structures with NAT address information, and
storing the ART index and the packet information in a data structure associated with the state table associating data structures with NAT address information;
if the type is the Internet Control Message Protocol type, determining whether the Internet Control Message Protocol type is on a list of Internet Control Message Protocol types;
if the type is not the Internet Control Message Protocol type,
determining if the outgoing interface is running the network address translation;
responsive to the outgoing interface running the network address translation,
obtaining the second index from the data structure; and
obtaining the packet information from the first table using the second index.
15. The method, according to claim 14, wherein the packet information is a five-tuple including source and destination addresses, source and destination ports, and a packet type identifier.
16. The method, according to claim 14, wherein the packet type is a Generic Routing Encapsulation type.
17. The method, according to claim 16, wherein the packet information is a five-tuple including source and destination addresses, an apportioned Generic Routing Encapsulation identifier, and a packet type identifier.
18. The method, according to claim 14, wherein the packet type is an Internet Protocol Security type.
19. The method, according to claim 18, wherein the packet information is a five-tuple including source and destination addresses, an apportioned security parameter string, and a packet type identifier.
20. The method, according to claim 14, further comprising:
21. The method, according to claim 14, wherein the data structure is for a plurality of canonical frame headers.
CROSS-REFERENCE TO RELATED APPLICATIONS This patent application is related to co-pending U.S. patent application entitled �METHOD AND APPARATUS FOR DEFLECTING FLOODING ATTACKS� by Thomas A. Maufer and Sameer Nanda, filed Dec. 31, 2002, application Ser. No. 10/334,656, assigned to the same assignee as this patent application, which is incorporated by reference as though fully set forth herein.
FIELD OF THE INVENTION One or more aspects of the invention generally relate to a network protocol processing and more particularly, to network protocol processing for filtering of packets.
BACKGROUND OF THE INVENTION The Internet remains a growing public network. Many companies rely on communication over the Internet using Internet Protocol (�IP�) to facilitate their business endeavors. For security in communication over the Internet, a computer may be configured to track and screen communications. This configuration is known as a �firewall,� and one or more of the actions of which may be referred to as �firewalling.�
Furthermore, to enhance firewalling security, encrypted information may be established for a connection. Examples of protocols for enhanced security on the Internet include Point-to-Point Tunneling Protocol (�PPTP�) and a set of protocols known collectively as Internet Protocol Security (�IPSec�). However, fragmentation of IP packets has been used to defeat firewalls, such as the so-called �ping-of-death,� �wedge� and �tiny fragment� attacks. IP version 4 (�IPv4�) supports header structures allowing fragmentation of IP packets. Notably, a fragmented packet (�fragment�) may be fragmented further, and there is no requirement that fragments arrive in order, or even that they arrive at all In many stateless firewalls, fragments are summarily process by dropping them. However, fragments are useful when an intermediate router has to forward a packet that is larger than the maximum transmission unit (�MTU�) of an outgoing interface (�OIF�). Thus, by dropping fragments, information may be lost. Examples of stateless firewalls may be found integrated in low-end home gateway routers. In higher-end standalone or integrated stateful firewalls, more states are added to verify authenticity of a fragment. This approach facilitates use of devices with significant embedded memory limitations, using less memory than a fragment buffering and reassembly approach.
SUMMARY OF THE INVENTION An aspect of the invention is a method for network protocol filtering of a packet. The method comprises: determining packet type for the packet; obtaining packet information for the packet; determining whether the packet information is in a table; responsive to the packet information being in the table, obtaining an index from the table; and storing the index in a data structure in association with the packet.
Another aspect of the invention is a method for inbound network address translation packet filtering. The method comprises: obtaining a packet; determining whether type of the packet is one of a Transmission Control Protocol and a User Datagram Protocol; if the type is the Transmission Control Protocol type, determining if the packet is an initial packet for a connection; if the type is the Transmission Control Protocol type and the packet is for an existing connection or if the type is the User Datagram Protocol type: obtaining packet information from the packet, determining whether the packet information is in a first table, obtaining a first index to a second table from the first table responsive to the packet information being in the first table, storing the first index in a data structure associated with the packet, obtaining a second index from the second table responsive to the first index, and storing the second index in the data structure; obtaining a third index from one of the first table and the second table, the third index to a third table; and storing the third index in the data structure.
Another aspect of the invention is a method for outbound packet filtering. The method comprises: obtaining a packet; determining whether an incoming interface for the packet is running network address translation; if the incoming interface is running the network address translation: obtaining a first index from a data structure associated with the packet, obtaining packet information in a table using the first index, checking whether the packet is the Transmission Control Protocol type, and checking for a Transmission Control Protocol state error of the packet responsive to the packet being the Transmission Control Protocol type; determining if the outgoing interface is running the network address translation; and responsive to the outgoing interface running the network address translation, obtaining a second index from the data structure, and obtaining the packet information from the table using the second index.
An aspect of the invention is a method for network address translation. The method comprises obtaining a packet for network address translation, the packet having a media access control header; determining if a network processing unit is in a pass-through mode responsive for the packet; and responsive to the network processing unit not being in the pass-through mode: obtaining a media access control source address from the media access control header is stored in an address resolution table, determining whether an incoming interface is running network address translation, and network address translation filtering the packet responsive to the incoming interface running the network address translation. The network address translation filtering includes obtaining an address resolution sable index from the packet.
BRIEF DESCRIPTION OF THE DRAWINGS Accompanying drawing(s) show exemplary embodiment(s) in, accordance with one or more aspects of the invention; however, the accompanying drawing(s) should not be taken to limit the invention to the embodiment(s) shown, but are for explanation and understanding only.
DETAILED DESCRIPTION OF THE DRAWINGS In the following description, numerous specific details are, set forth to provide a more thorough understanding of aspects of the invention as described with respect to exemplary embodiments herein. However, it will be apparent to one of skill in the art that one or more aspects of the invention may be practiced without one or more of these specific details. In other instances, well-known features have not been described for purposes of clarity.
FIGS. 2A-1, 2A-2, 2B-1, 2B-2, 2C and 2D-1 (singly and collectively �FIG. 2�) are respective flow diagrams of respective exemplary embodiments of portions of address translation flow 100 of FIG. 1. A packet 101 of a transmission is received. Multiple packets corresponding to multiple connections may be processed at a time for address translation flow 100 of FIG. 1, though for purposes of clarity processing of a single packet is described. This is consistent with how packets are received for a connection, namely, one packet at a time Notably, if a plurality of packets is received in a short span of time, such packets may be buffered as described below with respect to an NPU. Furthermore, FIG. 2 for the most part is described with respect to an address translator portion of an NPU, and accordingly receiving and transmitting is often done with reference to information going to and from, respectively, the address translator portion.
At 812, respective indices are generated using packet information obtained at 811. At 813, packet information, interface information and indices are stored in data structures. Examples of data structures are Connection Table (�CT�) 600, or if NAT is being used, NAT Table (�NT�) 700. Interface information is stored in Address Resolution Table (�ART�) 800. For example, an index generated from five-tuple information is stored in either CT 600 or NT 700 for cross-linking such tables, as described below in additional detail. For example, an index generated from an entry in ART 800, for example by hashing all or a portion of an entry of interface information, is stored in CT 600, or in NT 700 if NAT is being used, for cross-linking with ART 800, as described below in additional detail. Additionally, such an ART index may be stored in ART 800 to avoid recalculation of such an index, for example when updating an auxiliary Canonical Frame Header (�xCFH�) of packet 101 for broadcasting, as described below in additional detail. A CFH is a data structure, separate from packet 101, that travels with packet 101, where data for a CFH, is derived from packet 101, as described below in additional detail. Moreover, an ART index from such interface information is stored in Routing Table (�RT�) 900 for cross-linking with ART 800, as described below in additional detail.
If Pass-through Mode A is not invoked, then at 121 a determination is made as to whether multicast reception is active on an Incoming Interface (�IIF�) for a group of listeners of a multicast. If multicast reception, is not active, then packet 101 is sent to NPUsoft with an error condition, for example error condition 122.
At 123, a data link layer (�layer-2�) validity check is done. A layer-2 validity check determines whether a MAC source address is a multicast MAC address and whether there is a length error for a frame used for such a MAC address. Additionally, a layer-2 validity check may involve checking whether a report, which may be termed a �cracker report,� generated as a result of obtaining information at 107 indicated an error in an xCFH for packet 101. If at 123, packet 101 is found to be invalid as a result of a layer-2 validity check, then packet 101 is sent to NPUsoft with an error condition, for example error condition 124.
If IP protocol of packet 101 is supported, then at 127 it is determined whether an NPU is in Pass-through Mode B. Pass-through Mode B is a pass-through with firewall-only mode. This may be determined by accessing a data structure, such as a table, indicating whether firewalling-only has been activated for packet 101. If such an NPU is in Pass-through Mode B, a check is made at 153 of FIG. 2C to determine if packet 101 is a non-IP protocol packet. If, however, such an NPU is not in Pass-through Mode B, then other processing occurs, prior to checking whether packet 101 is a non-IP protocol packet.
Referring to FIG. 2, and in particular FIG. 2C, at 131, optionally a hash of interface information of packet 101 is done, otherwise a lookup is done by comparing MAC source addresses. If a hash is done, the result may be stored as an ART Index in an xCFH for data path flow with packet 101. Assuming a hash is not done, a check is made to determine if a MAC source address for a frame obtained from packet 101 is in an ART, such as ART 800 of FIG. 8. If a MAC source address for packet 101 is not in ART 800, for example if packet 101 is an initial packet of a connection, then packet 101 is sent to NPUsoft with an error condition, for example error condition 132, meaning, that ART entries need to be built for this packet 101. In addition to such an error message, optionally the hash of packet 101, if optionally done, may be sent to NPUsoft. NPUsoft may use packet 101 for bridge learning and optionally for IEEE 802 authorization. However, NPUsoft may determine that packet 101 is to be dropped. If, however, a MAC source address for packet 101 is in ART 800, then at 131 such MAC source address is looked up from ART 800.
If, at 139, either a multicast or broadcast frame is being used then at 141 a check for hardware support for multicast or broadcast frame replication is made responsive to frame type. If multicast or broadcast support is found to be lacking at 141, then packet 101 is sent to NPUsoft with an error condition, for example error condition 142. If such support in hardware exists, then at 143 a check is made to determine if expansioning or skipping for multicast or broadcast, depending on frame type, includes any disallowed outgoing interface (�OIF�) for a group of listeners. If one or more disallowed OIFs are included, then packet 101 is sent to NPUsoft with an error condition, for example error condition 144. Error condition 144 means that multicasting or broadcasting is not supported or that packet 101 is invalid with respect to multicasting or broadcasting. Accordingly, packet 101 may be dropped. If, however, no disallowed OIF is included as determined at 143, or no multicast nor broadcast frame is used as determined at 139, then at 145 a check is made to determine if the OIF equals the IIF for packet 101. Notably, steps 146 may be moved to a routing and bridging flow, as described below in additional detail. If the IIF and the OIF are equal, then an interface mask, such as interface mask 803 of FIG. 8, is for an IEEE 802.11 interface and then packet 101 is sent to NPUsoft with an error condition, for example error condition 147, for processing by NPUsoft or dropping. If, however, the IIF and the OIF are not equal, then at 148 a check for IP protocol type of the OIF is made. At 148, it is determined whether the IP protocol type is supported on the OIF. If the IP protocol type is not supported on the OIF, then packet 101 is sent to NPUsoft with an error condition, for example error condition 149, for processing by NPUsoft or dropping.
If the IP protocol type is supported on the OIF as determined at 148, then at 151 it is determined whether broadcasting or multicasting is invoked for the OIF. Notably, determining whether broadcasting or multicasting of packets being sent out via the OIF is permitted at 151 is optional here, and may be done in a routing and bridging flow as described below. If broadcasting or multicasting is not invoked for the OIF, then, packet 101 is sent to NPUsoft with an error condition, for example error condition 152, for processing by NPUsoft or dropping. If, however, broadcasting or multicasting is invoked for the OIF, responsive to frame type, or if an NPU is in Pass-through Mode B, a check is made at 153 to determine if packet 101 is anon-IP protocol packet.
Referring to FIG. 2, and in particular FIG. 2D-1, If packet 101 is of a non-IP protocol type at 153, then packet 101 sent without outbound filtering, where at 156 packet 101 is composed to produce composed packet 158 and processed further as previously described. If, however, packet 101 is not of a non-IP protocol type, then at 154 it is determined whether the OIF and the IIF are both trusted or both not trusted, for example by processing a trust bit for each through an XOR gate. If both are trusted or both are not trusted, then composition of packet 101 takes place as previously described. If, however, one of the IIF or the OIF is trusted and the other one of the OIF and the IIF is not trusted, then at 155 outbound filtering is done. After outbound filtering, packet 101 is composed at 156 as previously described.
Alternatively, with reference to FIG. 2D-2, an alternative compose packet flow 180A is shown. As much of compose packet flow 180A is the same as that of compose packet flow 180 of FIG. 2D-1, it is not repeated. If it is determined at 154 that the OIF and the IIF are not both trusted or untrusted, then at 201 it is determined whether packet 101 is an IP version six (�IPv6�) packet or IPv6 site boundary enforcement is active. If packet 101 is not an IPv6 packet or IPv6 site boundary enforcement is not active, then outbound filtering takes place at 155. Otherwise, at 202 a determination is made as to whether a site prefix in a destination address for IPv6 packet 101 is the same as the OIF's site prefix. If the two prefixes are not the same, packet 101 is sent to NPUsoft with an error condition or dropped at 203. Otherwise, packet 202 is sent to 155 for outbound filtering.
If a MAC destination address matches an interface for routing of packet 101, then at 303 a determination is made as to whether packet 101 contains a routable IP protocol, such as whether packet 101 is an IPv4 or IPv6 packet. If packet 101 does not contain a routable IP protocol, then packet 101 is sent to NPUsoft with an error condition, for example error condition 304, for processing by NPUsoft or dropping. If, however, packet 101 contains a routable IP protocol, such as IP version 4 (�IPv4�) or IP version 6 (�IPv6�), then at 306 a determination is made as to whether routing is supported in hardware. If routing is not supported in hardware, then packet 101 is sent to. NPUsoft with an error condition, for example error condition 307, for routing by NPUsoft as described below for example with respect to one or more of instantiations 314, 316 and 318.
FIG. 3C is a flow diagram of an exemplary embodiment of a bridging and routing flow 138C. Much of bridging and routing flow 138C is the same as previously described bridging and routing flows 138A and 138B, and thus is not repeated. Routing and bridging flow 138C is initiated at 301. At 354, layer-2 and layer-3 validity checks are done. If layer-2 or layer-3 is invalid, an error condition 355 is sent to NPUsoft. Otherwise, at 344 it is determined whether the frame is a broadcast frame. If the frame for packet 101 is a broadcast frame, then at 347 it is determined whether the Operating System (�OS�) is to process packet 101. If the OS is not to process packet 101, an error condition 349 is sent to NPUsoft. If, however, the OS is to process packet 101, then packet 101 is forwarded to, an IP stack of the host device.
FIG. 4A is a flow diagram of an exemplary embodiment of an inbound NAT filtering flow 137. Inbound NAT filtering flow 137 is initiated at 401. At 402, a check for hardware support for NAT is made. If no such support is available, then packet 101 is sent to NPUsoft with an error condition, for example error condition 403, for processing by NPUsoft as described below. If, however, NAT processing is supported in hardware, then at 404 a layer-3 validity check is done. Notably, if layer-2 validity checking is not done as part of NPU mode A flow 140, then layer-2 validity is also checked at 404. For clarity, it is assumed that only layer-3 validity is checked at 404, though both layer-2 and layer-3 validity may be checked at 404 where both need to be valid to pass or where if one is invalid, an error condition indicating which or both of layers -2 and -3 is invalid, is sent. If the layer-3 validity check comes back with an invalid condition, then packet 101 is sent to NPUsoft with an error condition, for example error condition 405, for processing or dropping by NPUsoft as an invalid packet. If layer-3 is valid, then at 406 an IP options check is done. If one or more IP options are unsupported or invalid, then packet 101 is sent to NPUsoft with an error condition, for example error condition 407, for processing by NPUsoft as having one or more unsupported or invalid IP options. If all IP options are supported and valid, then at 408 a check is made to determine if packet 101 is an IP fragment, namely, from a fragmented packet. If packet 101 is a fragment, then packet 101 is sent to NPUsoft with an error condition, for example error condition 409, for processing by NPUsoft. Notably, NPUsoft may employ �fragment absorption,� where received fragment packets are all collected and reassembled, where possible, before being forwarded, as described in below.
If packet 101 is not a fragment, then it is determined what type of, packet it is for further processing. If packet 101 is a TCP packet as found at 410, then at 411 it is determined if packet 101 is for a new connection. For example, if TCP state has synchronize (�SYN�) equal to one, then this is for a new connection. If packet 101 is for a new connection, then packet 101 is sent to NPUsoft with an error condition, for example error condition 412, for processing by NPUsoft. Thus, NPUsoft will use information from packet 101 to build an entry in CT 600 and NT 700 prior to returning packet 101 to address translation flow 100.
If, however, at 529, the IIF of packet 101 was not running NAT, then at 506 a layer-3 validity check is done. Notably, if layer-2 validity checking is not done as part of NPU mode A flow 140, then layer-2 validity is also checked at 506. For clarity, it is assumed that only layer-3 validity is checked at 506, though both layer-2 and layer-3 validity may be checked at 506 where both need to be valid to pass or where if one is invalid, an error condition indicating which or both of layers -2 and -3 is invalid is sent. If the layer-3 validity check comes back with an invalid condition, then packet 101 is sent to NPUsoft with an error condition, for example error condition 507, for processing or dropping by NPUsoft as an invalid packet. If layer-3 is valid, then at 508 an IP options check is done. If one or more IP options are unsupported or invalid, then packet 101 is sent to NPUsoft with an error condition, for example error condition 509, for processing by NPUsoft as having one or more unsupported or invalid IP options.
At 531, a check is made to determine or confirm (as it may have previously been determined at 510 that packet 101 is a TCP packet) as applicable, if packet 101 is a TCP packet and if packet 101 has a TCP state error. A TCP error results when state of a packet does not match the state of a connection associated with the packet. Notably, the check at 531 is inapplicable to UDP packets as they just flow through 531. Furthermore, TCP state tracking as described below, or a subset thereof, may be used for TCP state error check 513. If packet 101 is a TCP packet and has a TCP state error, then packet 101 is sent to NPUsoft with an error condition, for example error condition 515, for processing or dropping by NPUsoft. If however, at 531 either packet 101 is not a TCP packet or does not have a TCP state error, then processing of packet 101 proceeds at 532, as described below.
If packet 101 is not found to be a UDP packet at 513 but is found to be a GRE packet at 517, then at 518, CT 600 is accessed with a five-tuple from packet 101 to lookup an outbound five-tuple for packet 101. Recall, packet 101 may be a remote or local outbound packet to the NPU, and part of the five-tuple is a GRE Call ID. If the five-tuple for packet 101 is not in CT 600, then packet 101 is sent to NPUsoft with an error condition, for example error condition 519, for processing to build an entry in CT 600 prior to returning packet 101 to address translation flow 100, or for dropping by NPUsoft. If however, the five-tuple for packet 101 is in CT 600, then at 518 an NT Index, hashed from such a five-tuple, is obtained from CT 600 if present and is stored in an xCFH of packet 101. Processing of packet 101 proceeds at 532, as described below.
If packet 101 is not found to be a GRE packet at 517 but is found to be an IPSec packet at 520, then at 521, CT 600 is accessed with a five-tuple of packet 101 to lookup an outbound five-tuple for packet 101. Recall, packet 101 may be a remote or local outbound packet to the NPU, part of the five-tuple is an SPI. If the five-tuple for packet 101 is not in CT 600, then packet 101 is sent to NPUsoft with an error condition, for example error condition 522, for processing to build an entry in CT 600 prior to returning packet 101 to address translation flow 100, or for dropping by NPUsoft. If however, the five-tuple for packet 101 is in CT 600, then at 521 an NT Index, hashed from such a five-tuple, is obtained from CT 600 if present and is stored in an xCFH of packet 101. Processing of packet 101 proceeds at 532, as described below.
If packet 101 is not found to be an IPSec packet at 520 or an IMP packet at 523, then packet 101 is sent to NPUsoft with an error condition, for example error condition 524, for processing or dropping by NPUsoft. If packet 101 is not found to be an IPSec packet at 520 but is found to be an ICMP packet at 523, then at 525 a check is made to determine if packet 101 is on a list of supported ICMP packet types stored in memory, such as ICMPv4 and ICMPv6. If packet 101 type is not on the list of supported ICMP packet types, then packet 101 is sent, for example to NPUsoft, with an error condition, for example error condition 526, for allowing such a packet to pass through or to be dropped. Notably, if an ICMP packet type is not on the list, the default may be to drop the packet or to allow the packet to pass through the NPU, which outcome may be dependent on the type of ICMP packet. If packet 101 type is on the list of supported ICMP packet types, at 528 outbound filtering flow 155 returns to address translation flow 100.
From SYN-RCVD state 905, transitioning to SYN-RCVD-SYN-SENT state 906 occurs responsive to a sent SYN, and transitioning to SYN-RCVD-SYN ACK-SENT state 912 occurs responsive to a sent SYN-ACK.
From ESTABLISHED state 909, SYN-RCVD-SYN-ACK-SENT state 912 or SYN-SENT-SYN-ACK-RCVD state 913, transitioning to FIN-WAIT1 state 914 occurs responsive to a sent FIN. From ESTABLISHED state 909, SYN RCVD-SYN-ACK-SENT state 912 or SYN-SENT-SYN-ACK-RCVD state 913, transitioning to CLOSE-WAIT-FIN state 915 occurs responsive to a received FIN.
From FIN-WAIT1 state 914, transitioning to CLOSING-FIN state 917 occurs responsive to a received FIN; FIN-WAIT2 state 916 occurs responsive to a received ACK of a FIN, and transitioning to FIN-WAIT2-FIN state 921 occurs responsive to a received FIN and a received ACK of the FIN in the same packet.
From CLOSE-WAIT-FIN state 915, transitioning to CLOSING-FIN state 917 occurs responsive to a sent FIN; CLOSE-WAIT state 918 occurs responsive to a sent ACK of a FIN, and transitioning to LAST-ACK state 923 occurs responsive to a sent FIN and a sent ACK of the FIN in the same packet.
Input from MAC layer 1097 and output to MAC layer or host bus 1098 may be in a form compatible with one or more of Ethernet 10/100/1000 mega-bits-per-second (�Mbps) (�IEEE 802.3�) for local area network (�LAN�) connectivity, Home Phoneline Network Alliance (�HomePNA� or �HPNA�), wireless local area network (�WLAN�) (�IEEE 802.11�), and a digital signal processor (�DSP�) MAC layer, among others. Though a personal computer workstation embodiment is described herein, it should be understood that NPU 1070 may be used in other known devices for network connectivity, including, but not limited to, routers, switches, gateways, and the like. Furthermore, a host or local bus may be a Fast Peripheral Component Interconnect (�FPCI�) bus; however, other buses, whether directly accessed or coupled to a host bus, include, but are not limited to, Peripheral Component Interconnect (�PCI�), 3GIO, Video Electronic Standards Association (�VESA), VersaModule Eurocard (�VME�), Vestigial Side Band (�VSB�), Accelerated Graphics Port (�AGP), Intelligent I/O (�I2O�), Small Computer System Interface (�SCSI�), Fiber Channel, Universal Serial Bus (�USB�), IEEE 1394 (sometimes referred to as �Firewire,� �Link� and �Lynx�), Personal Computer Memory Card International Association (�PCMCIA�), and the like.
For purposes of clarity of explanation, processing of one frame through NPU 1070 pipeline will be described, though it should be understood that multiple frames may be pipeline-processed through NPU 1070. Lookup tables in memory 1052 may include state tables 600, 700, 800, and 900, as described above, as well as a list of supported. ICMP types 1071. Supported ICMP types may be loaded from a network driver program. Sequence processor 1020 on an inbound side may include a decapsulation module 1021, a validation module 1022 and a security module 1023A.
Bridging and routing module 1032 includes multicast expansioning. After a lookup in CT 600 or NT 700, a routing table lookup from memory 1052 is done for an Address Resolution Protocol (�ARP�) table 702 to convert an IP address for a packet into a physical address. Moreover, if more than one output MAC address is specified, then multicast expansioning is done. Notably, at, this point a packet may be output for use by a host computer user. Routing from address translator 1030 for a packet may be for sending such a packet.
Memory 1003 may store all or portions of one or more programs or data to implement processes in accordance with one or more aspects of the invention, including a network driver program 1007 having at least a portion of address translation flow 100. Network driver program 1007 may include NPUsoft programming. Additionally, those skilled in the art will appreciate that one or more aspects of the invention may be implemented in hardware, software, or a combination of hardware and software. Such implementations may include a number of processors independently executing various programs and dedicated hardware, such, as application specific integrated circuits (�ASICs�).
One or more aspects of the invention are implemented as program products for use with computer system 1000. Program(s) of the program product defines functions of embodiments in accordance with one or more aspects of the invention and can be contained on a variety of signal-bearing media, such as computer-readable media having code, which include, but are not limited to (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM or DVD-RAM disks readable by a CD-ROM drive or a DVD drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or read/writable CD or read/writable DVD); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct functions of one or more aspects of the invention represent embodiments of the invention.
An alternative embodiment tables indexed by hash function output values 11108 are depicted in FIG. 15B. So, if a connection 1111-3 is established and hashes to slot 2, and slot 2 is found to be occupied, an empty slot in tables indexed by hash function output values 11108 is found, which in this exemplary embodiment is slot 3. Instead of putting connection 1111-3 into slot 3 and pointing slot 2 to slot 3, as done in tables indexed by hash function output values 1110A, contents of slot 2 are moved to slot 3. Moving contents of slot 2 to slot 3, empties slot 2 for connection 1111-3, as shown. As connection 1111-3 hashed to slot 2, no other slot points to slot 2, and slot 1 now points to slot 3. Thus, there are two chains, namely, one of length two and one of length one. This reduces the length of a hash chain over that shown in FIG. 15A. Other advantages include improved performance with respect to length in which a hash chain has to be followed prior to arriving at a target connection, and reduced or eliminated of intermingling of hash chains. With respect to the last advantage, only one chain is needed to get to any of connections 1111 in tables indexed by hash function output values 11108, namely, a chain pointing to slot 1 with slot 1 point to slot 3, or a chain pointing to slot 2.
If a checksum for a fragment is valid at 1205 or is a first fragment received for a fragmented packet, then at 1204 such a fragment is buffered or otherwise stored, such as in memory 1013 or 1003. Accordingly, if IP information for this fragment matches that of a previously buffered fragment, then this newly, received fragment is buffered in association with a buffer stack for a fragmented packet already in process for reassembly. This may be a physical or a logical association in memory for association on a fragmented packet basis. FIG. 17 is a block diagram of an exemplary embodiment of a buffer stack 1230. If, however, IP information for this fragment does not match that of a previously buffered fragment, then such fragment is buffered at 1204 in newly reserved buffer space as reserved at 1202.
At 1209, a buffer stack is checked to determine if any fragments for a fragmented packet have as yet not been buffered. For example in buffer stack 1230, fragment 2 is as yet not buffered. The number of fragments a packet may have is indicated by fragment N for N a positive integer, and is dependent upon what protocol is being used, such as IPv4 or IPv6. If a fragment is missing, then at 1212 it is determined whether a buffer stack has timed out based on when time was started at 1203 for a first fragment for such a buffer stack. If a buffer stack has timed out, then at 1213 the buffer is cleared, meaning all fragments in such buffer are dropped. If, however, a buffer stack has not timed out, then at 1214 a set time interval is used as a wait period before checking again at 1209 as to whether any fragments are still missing. Such a wait period will depend on implementation and availability of memory. Also the number of fragments received to a destination is dependent upon likelihood of routing through an interface not able to handle full size packets.
If however, at 1209 no fragments for a fragmented packet are missing from a buffer stack, then at 1210 such fragments are assembled into a single packet, namely, a reassembled packet. At 1211, such a reassembled packet is re-inserted into the above-described process, such, as a packet 101 into packet interrogation flow 120 for further processing, including any firewalling. Thus, it should be appreciated that packet fragment assembly is done prior to screening, namely, in front of a firewall.
Accordingly, it is worth mentioning that if NAT is used, NAT need be done only once per packet. This is facilitated by, having NAT proximal to front end packet processing. Furthermore, it should be appreciated that by doing NAT, and implicit routing table lookup is done.
Additionally, it should be appreciated that if firewalling is used firewalling need be done only once per packet. This is facilitated by having firewalling proximal to back end packet processing.
While the foregoing describes exemplary embodiment(s) in accordance with one or more aspects of the invention, other and further embodiment(s) in accordance with the one or more aspects of the invention may be devised without departing from the scope thereof, which is determined by the claim(s) that follow and equivalents thereof. For example, it is not necessary to incorporate an NPU as described, as a software embodiment may be used. Furthermore, the NPU architecture described herein is not the only architecture that may be used. Additionally, rather than a personal computer, a firewall computing device may be used Claim(s) listing steps do not imply any order of the steps. Trademarks are the property of their respective owners.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5349679Aug 27, 1991Sep 20, 1994Fujitsu LimitedCommunication control unit for selecting a control mode of data communication and selectively bypassing an interprocessor interfaceUS5524250Dec 23, 1994Jun 4, 1996Silicon Graphics, Inc.Central processing unit for processing a plurality of threads using dedicated general purpose registers and masque register for providing access to the registersUS5630172Nov 13, 1995May 13, 1997Mitsubishi Denki Kabushiki KaishaData transfer control apparatus wherein an externally set value is compared to a transfer count with a comparison of the count values causing a transfer of bus use rightUS5630174Feb 3, 1995May 13, 1997Cirrus Logic, Inc.For use within a computer systemUS5742773Apr 18, 1996Apr 21, 1998Microsoft CorporationIn a computer systemUS5797028Sep 11, 1995Aug 18, 1998Advanced Micro Devices, Inc.Computer system having an improved digital and analog configurationUS5812800Sep 11, 1995Sep 22, 1998Advanced Micro Devices, Inc.Computer system which includes a local expansion bus and a dedicated real-time bus and including a multimedia memory for increased multi-media performanceUS5826027Oct 11, 1995Oct 20, 1998Citrix Systems, Inc.Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process systemUS5884025Feb 4, 1997Mar 16, 1999Sun Microsystems, Inc.System for packet filtering of data packet at a computer network interfaceUS5909546Mar 8, 1996Jun 1, 1999Mitsubishi Electric Information Technology Center America, Inc. (Ita)Network interface having support for allowing remote operations with reply that bypass host computer interactionUS5974496Jan 2, 1997Oct 26, 1999Ncr CorporationSystem for transferring diverse data objects between a mass storage device and a network via an internal bus on a network cardUS5987627Oct 27, 1992Nov 16, 1999Rawlings, Iii; Joseph H.Methods and apparatus for high-speed mass storage access in a computer systemUS6032253Nov 9, 1998Feb 29, 2000Cisco Technology, Inc.Data processor with multiple compare extension instructionUS6034963Oct 31, 1996Mar 7, 2000Iready CorporationMultiple network protocol encoder/decoder and data processorUS6047325Aug 24, 1998Apr 4, 2000Jain; LalitNetwork device for supporting construction of virtual local area networks on arbitrary local and wide area computer networksUS6055236Mar 17, 1999Apr 25, 20003Com CorporationMethod and system for locating network services with distributed network address translationUS6092124Apr 17, 1998Jul 18, 2000Nvidia CorporationMethod and apparatus for accelerating the rendering of imagesUS6094485Sep 18, 1997Jul 25, 2000Netscape Communications CorporationSSL step-upUS6097955Sep 12, 1997Aug 1, 2000Lucent Technologies, Inc.Apparatus and method for optimizing CPU usage in processing paging messages within a cellular communications systemUS6101170Sep 27, 1996Aug 8, 2000Cabletron Systems, Inc.Secure fast packet switch having improved memory utilizationUS6104696 *Jun 30, 1999Aug 15, 2000Broadcom CorporationMethod for sending packets between trunk ports of network switchesUS6141705Jun 12, 1998Oct 31, 2000Microsoft CorporationSystem for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when neededUS6157955Jun 15, 1998Dec 5, 2000Intel CorporationPacket processing system including a policy engine having a classification unitUS6189102May 27, 1998Feb 13, 20013Com CorporationMethod for authentication of network devices in a data-over cable systemUS6215907Jun 26, 1998Apr 10, 2001Fisher-Rosemont Systems, Inc.Recursive on-line wavelet data compression technique for use in data storage and communicationsUS6226680Apr 27, 1998May 1, 2001Alacritech, Inc.Intelligent network interface system method for protocol processingUS6266707 *Aug 17, 1998Jul 24, 2001International Business Machines CorporationSystem and method for IP network address translation and IP filtering with dynamic address resolutionUS6301669 *Nov 29, 2000Oct 9, 2001International Business Machines CorporationSystem and method for very fast IP packet filteringUS6304573Apr 3, 1997Oct 16, 2001At&T Corp.Method and apparatus for transmitting and receiving electronic voice messagesUS6327660Sep 18, 1998Dec 4, 2001Intel CorporationMethod for securing communications in a pre-boot environmentUS6343086Sep 9, 1997Jan 29, 2002Natural Microsystems CorporationGlobal packet-switched computer network telephony serverUS6345072Feb 22, 1999Feb 5, 2002Integrated Telecom Express, Inc.Universal DSL link interface between a DSL digital controller and a DSL codecUS6389419Oct 6, 1999May 14, 2002Cisco Technology, Inc.Storing and retrieving connection information using bidirectional hashing of connection identifiersUS6401117Mar 31, 1999Jun 4, 2002Intel CorporationPlatform permitting execution of multiple network infrastructure applicationsUS6421730Apr 1, 1999Jul 16, 2002Intel CorporationProgrammable system for processing a partitioned network infrastructureUS6424650Feb 9, 1999Jul 23, 20023Com CorporationNetwork address filter deviceUS6426943Apr 3, 1999Jul 30, 2002Top Layer Networks, Inc.Application-level data communication switching system and process for automatic detection of and quality of service adjustment for bulk data transfersUS6483804Mar 1, 1999Nov 19, 2002Sun Microsystems, Inc.Method and apparatus for dynamic packet batching with a high performance network interfaceUS6496867Aug 27, 1999Dec 17, 20023Com CorporationSystem and method to negotiate private network addresses for initiating tunneling associations through private and/or public networksUS6542935Jul 28, 1999Apr 1, 2003Sharp Laboratories Of America, Inc.Method for obtaining a second address free from association with multiple devicesUS6542992Jan 26, 1999Apr 1, 20033Com CorporationControl and coordination of encryption and compression between network entitiesUS6560196Nov 19, 1998May 6, 2003Cisco Technology, Inc.Method and apparatus for controlling the transmission of cells across a networkUS6611525Oct 7, 1999Aug 26, 20033Com CorporationApparatus for and method of learning MAC addresses in a LAN emulation networkUS6615357Jan 29, 1999Sep 2, 2003International Business Machines CorporationSystem and method for network address translation integration with IP securityUS6629150Jun 18, 1999Sep 30, 2003Intel CorporationPlatform and method for creating and using a digital containerUS6646999Jan 13, 2000Nov 11, 2003Fujitsu LimitedMobile packet communication systemUS6647428May 5, 2000Nov 11, 2003Luminous Networks, Inc.Architecture for transport of multiple services in connectionless packet-based communication networksUS6658463Feb 4, 2000Dec 2, 2003Hughes Electronics CorporationSatellite multicast performance enhancing multicast HTTP proxy system and methodUS6704794Mar 3, 2000Mar 9, 2004Nokia Intelligent Edge Routers Inc.Cell reassembly for packet based networksUS6714985Apr 28, 2000Mar 30, 2004Cisco Technology, Inc.Method and apparatus for efficiently reassembling fragments received at an intermediate station in a computer networkUS6735647Sep 5, 2002May 11, 2004International Business Machines CorporationData reordering mechanism for high performance networksUS6757746Feb 20, 2001Jun 29, 2004Alacritech, Inc.Obtaining a destination address so that a network interface device can write network data without headers directly into host memoryUS6768726Aug 6, 2002Jul 27, 2004Motorola, Inc.Method and apparatus for effecting a seamless handoff between IP connectionsUS6775293Jun 30, 2000Aug 10, 2004Alcatel Canada Inc.Method and apparatus for monitoring buffer contents in a data communication systemUS6779033Dec 28, 2000Aug 17, 2004Networks Associates Technology, Inc.System and method for transacting a validated application session in a networked computing environmentUS6781955Dec 29, 2000Aug 24, 2004Ericsson Inc.Calling service of a VoIP device in a VLAN environmentUS6785780Aug 31, 2000Aug 31, 2004Micron Technology, Inc.Distributed processor memory module and methodUS6789203Jun 26, 2000Sep 7, 2004Sun Microsystems, Inc.Method and apparatus for preventing a denial of service (DOS) attack by selectively throttling TCP/IP requestsUS6832261Feb 4, 2001Dec 14, 2004Cisco Technology, Inc.Method and apparatus for distributed resequencing and reassembly of subdivided packetsUS6879266Jul 14, 2000Apr 12, 2005Quickshift, Inc.Memory module including scalable embedded parallel data compression and decompression enginesUS6888835Jul 5, 2001May 3, 2005Roke Manor Research LimitedBuffer managementUS6904519Nov 29, 2000Jun 7, 2005Microsoft CorporationMethod and computer program product for offloading processing tasks from software to hardwareUS6907042Apr 19, 2000Jun 14, 2005Fujitsu LimitedPacket processing deviceUS6909714Sep 19, 2001Jun 21, 2005Qualcomm IncorporatedMethod and apparatus for determining configuration options negotiated for a communications link employing a network modelUS6912522Sep 11, 2001Jun 28, 2005Ablesoft, Inc.System, method and computer program product for optimization and acceleration of data transport and processingUS6944706Aug 2, 2002Sep 13, 2005Texas Instruments IncorporatedSystem and method for efficiently processing broadband network trafficUS6950862May 7, 2001Sep 27, 20053Com CorporationSystem and method for offloading a computational service on a point-to-point communication linkUS6957346Jun 15, 1999Oct 18, 2005Ssh Communications Security Ltd.Method and arrangement for providing security through network address translations using tunneling and compensationsUS7010727Jun 12, 2002Mar 7, 2006Nortel Networks LimitedMethod and system for negotiating compression techniques to be utilized in packet data communicationsUS7017175May 16, 2001Mar 21, 2006Opentv, Inc.Digital television application protocol for interactive televisionUS7027443Aug 23, 2001Apr 11, 2006Pmc-Sierra Ltd.Reassembly engines for multilink applicationsUS7043759Aug 16, 2001May 9, 2006Mazu Networks, Inc.Architecture to thwart denial of service attacksUS7050437Mar 16, 2001May 23, 2006International Business Machines CorporationWire speed reassembly of data framesUS7116640Dec 22, 2000Oct 3, 2006Mitchell Paul TasmanArchitecture and mechanism for forwarding layer interfacing for networksUS7136926Dec 31, 1998Nov 14, 2006Pmc-Sierrra Us, Inc.Method and apparatus for high-speed network rule processingUS7149222Dec 5, 2000Dec 12, 2006Converged Access, Inc.Integrated access point network deviceUS7158528Dec 14, 2001Jan 2, 2007Agere Systems Inc.Scheduler for a packet routing and switching systemUS7177310Mar 11, 2002Feb 13, 2007Hitachi, Ltd.Network connection apparatusUS7203170May 1, 2001Apr 10, 2007Integrated Device Technology, Inc.Network switch port with weighted random early discardUS7266604Mar 31, 2000Sep 4, 2007Microsoft CorporationProxy network address translationUS7274694 *Jan 9, 2003Sep 25, 2007Cisco Technology, Inc.Defining link aggregation across a stackUS20010000193 *Nov 29, 2000Apr 5, 2001Boden Edward B.System and method for very fast IP packet filteringUS20010032254May 29, 1998Oct 18, 2001Jeffrey C. HawkinsMethod and apparatus for wireless internet accessUS20010038642Mar 28, 2001Nov 8, 2001Interactive Silicon, Inc.System and method for performing scalable embedded parallel data decompressionUS20010042200Jan 5, 2001Nov 15, 2001International Business MachinesMethods and systems for defeating TCP SYN flooding attacksUS20010054131Mar 27, 2001Dec 20, 2001Alvarez Manuel J.System and method for perfoming scalable embedded parallel data compressionUS20020009083Jun 11, 2001Jan 24, 2002Broadcom CorporationGigabit switch with multicast handlingUS20020009136Mar 16, 2001Jan 24, 2002Heath Robert G.System employing data compression transparent mode with compression parameter negotiationUS20020035699Jul 23, 2001Mar 21, 2002Bluesocket, Inc.Method and system for enabling seamless roaming in a wireless networkUS20020046348Jul 10, 2001Apr 18, 2002Brustoloni Jose?Apos; C.Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel modeUS20020059451Aug 23, 2001May 16, 2002Yaron HavivSystem and method for highly scalable high-speed content-based filtering and load balancing in interconnected fabricsUS20020078242Dec 15, 2000Jun 20, 2002Nanjundiah ViswanathMethod of selectively compressing data packetsUS20020083344Jun 27, 2001Jun 27, 2002Vairavan Kannan P.Integrated intelligent inter/intra networking deviceUS20020089979Dec 14, 2001Jul 11, 2002Barbir AbdulkaderCommunication securityUS20020103916Sep 5, 2001Aug 1, 2002Benjie ChenThwarting connection-based denial of service attacksUS20020112076 *Jan 31, 2001Aug 15, 2002Rueda Jose AlejandroInternet protocol-based computer network serviceUS20020128986Feb 21, 2002Sep 12, 2002Peter StutzCommunication system for franking systemUS20020133534Jan 8, 2001Sep 19, 2002Jan ForslowExtranet workgroup formation across multiple mobile virtual private networksUS20020133598Mar 16, 2001Sep 19, 2002Strahm Frederick WilliamNetwork communicationUS20020136210Mar 21, 2001Sep 26, 2002International Business Machines CorporationSystem and method for virtual private network network address translation propagation over nested connections with coincident local endpointsUS20020138848Feb 1, 2002Sep 26, 2002Rachad AlaoService gateway for interactive televisionUS20020141389 *Jul 11, 2001Oct 3, 2002Fangman Richard E.System and method for routing IP packetsUS20020162026Feb 6, 2002Oct 31, 2002Michael NeumanApparatus and method for providing secure network communicationUS20020169885Feb 1, 2002Nov 14, 2002Rachad AlaoDigital television application protocol for interactive televisionUS20020172164May 18, 2001Nov 21, 2002Ching-Tsun ChouLink level retry schemeUS20030005103Jan 28, 2002Jan 2, 2003Narad Charles E.Cumulative status of arithmetic operationsUS20030131082 *Jan 7, 2003Jul 10, 2003Nec CorporationWireless lan system, an access point apparatus and a managing method of a wireless lan system, which can determine the system manager without making the process for the authentication troublesomeUS20040013112 *May 9, 2001Jan 22, 2004Packet Technologies Ltd.Dynamic packet filter utilizing session trackingUS20040017775 *May 2, 2003Jan 29, 2004Ntt Docomo, Inc.Packet transmission control apparatus, mobile node, control node, packet communication method, and packet communication systemUS20040117498 *Sep 29, 2003Jun 17, 2004Nec Infrontia CorporationPacket transmission system and packet reception system* Cited by examinerNon-Patent CitationsReference1"Diff-Hellman key exchange", Wikipedia, 2002.2Information Sciences Institute, University of Southern California, Marina del Rey, CA, USA, Sep. 1981; "Internet Protocol", RFC 791, Protocol Specification for the Defense Advanced Research Projects Agency (DARPA).3Internet Protocol, RFC 791, Darpa, Sep. 1981.4Ito, et al., "A Multiprocessor Approach for Meeting the Processing Requirements of OSI," IEEE Journal on Selected Areas in Communication vol. 11, No. 2, Feb. 1993.5Mason, Andrew, "Ciscopress.com IPSec Overview Part Four: Internet Key Exchange (IKE)" Feb. 22, 2002.6Mogul, et al., "Path MTU Discovery", pp. 1-19, RFC 1191, Stanford University, Nov. 1990.7Moskowitz, Robert, "RE: IPCOMP and IPSEC" Jun. 4, 1998.8Omondi, Amos R. et al., "Performance of a context cache for a multithreaded pipeline," Journal of Systems Architecture, Elsevier Science Publishers B.V., Dec. 1, 1998, vol. 45, No. 4 pp. 305-322.9Orda, et al., "Optimal Packet Fragmentation in Computer Networks", Israel Institute of Technology, Haifa, Israel, Mar. 1994.10RSA Laboratories, "PKCS #3: Diffie-Hellman Key Agreement Standard", RSA Laboratories Technical Note, Nov. 1, 1993.11Smith, Richard E., "Internet-Kryptographie," Addison Wesley Longman, Inc., XP002295926, 1998.12Stevens, W. Richard, TCP/IP Illustrated vol. 1, 1994, Addison Wesley, p. 1.c, 231,252.13US 6,447,647, 09/2002, Colby et al. (withdrawn)Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8316432 *Jul 17, 2008Nov 20, 2012Hangzhou H3C Technologies Co., Ltd.Method for implementing security-related processing on packet and network security deviceUS8446915 *Oct 17, 2011May 21, 2013Pantech Co., Ltd.Method of operating internet protocol address and subnet system using the sameUS8499340 *May 21, 2008Jul 30, 2013Telefonaktiebolaget L M Ericsson (Publ)IMS network identity managementUS8565229 *Jun 18, 2010Oct 22, 2013Schweitzer Engineering Laboratories IncSystems and methods for data packet transmissionUS8677474 *Jul 25, 2012Mar 18, 2014International Business Machines CorporationDetection of rogue client-agnostic NAT device tunnelsUS8683573 *Jun 27, 2011Mar 25, 2014International Business Machines CorporationDetection of rogue client-agnostic nat device tunnelsUS8763108 *Nov 25, 2008Jun 24, 2014Qualcomm IncorporatedFlow classification for encrypted and tunneled packet streamsUS20080301787 *May 21, 2008Dec 4, 2008Fredrik LindholmIms network identity managementUS20090144819 *Nov 25, 2008Jun 4, 2009Uppinder Singh BabbarFlow classification for encrypted and tunneled packet streamsUS20100132028 *Jul 17, 2008May 27, 2010Ju WangMethod for implementing security-related processing on packet and network security deviceUS20110010769 *Dec 22, 2006Jan 13, 2011Jaerredal UlfPreventing SpoofingUS20110310893 *Jun 18, 2010Dec 22, 2011Kasztenny Bogdan ZSystems and methods for data packet transmissionUS20120036268 *Oct 17, 2011Feb 9, 2012Pantech Co., Ltd.Method of operating internet protocol address and subnet system using the sameUS20120331543 *Jun 27, 2011Dec 27, 2012International Business Machines CorporationDetection of rogue client-agnostic nat device tunnelsUS20120331544 *Jul 25, 2012Dec 27, 2012International Business Machines CorporationDetection of rogue client-agnostic nat device tunnelsWO2013116536A1 *Jan 31, 2013Aug 8, 2013Gigamon LlcSystems and methods for packet filtering and switching* Cited by examinerClassifications U.S. Classification726/3, 709/230, 713/153, 370/392, 713/154, 726/2, 713/160, 370/395.31, 726/14, 709/238, 726/30, 726/6, 726/13, 726/1, 726/12, 370/395.32, 709/232, 713/152, 726/11, 370/395.54, 713/151, 370/389International ClassificationG06F15/173, H04L29/06, H04L12/56, G06F17/00Cooperative ClassificationH04L29/12367, H04L63/0227, H04L61/2514, H04L12/66European ClassificationH04L29/12A4A1B, H04L63/02B, H04L12/66, H04L61/25A1BLegal EventsDateCodeEventDescriptionJun 24, 2003ASAssignmentFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAUFER, THOMAS A.;GYUGYI, PAUL J.;NANDA, SAMEER;AND OTHERS;SIGNING DATES FROM 20030620 TO 20030623;REEL/FRAME:014238/0391Owner name: NVIDIA CORPORATION, CALIFORNIARotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google