Source: http://www.google.com/patents/US8176545?dq=%22frederick+douglis%22
Timestamp: 2016-07-29 04:48:15
Document Index: 574359338

Matched Legal Cases: ['art 2', 'Application No. 02728953', 'Application No. 03757427', 'Application No. 03757427', 'Application No. 2002', 'Application No. 2004', 'Application No. 2004', 'Application No. 2008', 'Application No. 02728953', 'Application No. 03757427']

Patent US8176545 - Integrated policy checking system and method - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA system and method are provided for validating a security service associated with packets communicated on a network. A hash of a security service associated with packets communicated on a network is generated. In use, the security service associated with the packets is validated utilizing the hash....http://www.google.com/patents/US8176545?utm_source=gb-gplus-sharePatent US8176545 - Integrated policy checking system and methodAdvanced Patent SearchPublication numberUS8176545 B1Publication typeGrantApplication numberUS 10/741,972Publication dateMay 8, 2012Filing dateDec 19, 2003Priority dateDec 19, 2003Fee statusPaidPublication number10741972, 741972, US 8176545 B1, US 8176545B1, US-B1-8176545, US8176545 B1, US8176545B1InventorsDaniel Leo Greenfield, John Shigeto Minami, Robin Yasu UyeshiroOriginal AssigneeNvidia CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (251), Non-Patent Citations (105), Referenced by (2), Classifications (6), Legal Events (7) External Links: USPTO, USPTO Assignment, EspacenetIntegrated policy checking system and method
US 8176545 B1Abstract
A system and method are provided for validating a security service associated with packets communicated on a network. A hash of a security service associated with packets communicated on a network is generated. In use, the security service associated with the packets is validated utilizing the hash.
1. A method for validating a security service associated with packets communicated on a network, comprising:
receiving a packet at a transport offload engine;
decrypting and authenticating the packet utilizing the transport offload engine, the decrypting utilizing an Internet Protocol Security (IPSec) transformation;
calculating a hash of a security service based on the packet, utilizing the transport offload engine;
determining whether the packet is a SYN packet utilizing the transport offload engine;
in response to a determination that the packet is a SYN packet:
sending the SYN packet from the transport offload engine to a processor,
sending the IPSec transformation from the transport offload engine to the processor, and
sending the hash from the transport offload engine to the processor; performing IPSec policy checking of the SYN packet utilizing the processor;
determining that the SYN packet and a connection related to the SYN packet are allowed based on the IPSec policy checking, utilizing the processor;
in response to the determination that the SYN packet and the related connection are allowed, and prior to generating a SYN/ACK packet, generating a control block including the hash utilizing the transport offload engine, the control block for network socket management;
generating the SYN/ACK packet based on the SYN packet, utilizing the transport offload engine; and
sending the SYN/ACK packet utilizing the transport offload engine.
2. The method as recited in claim 1, wherein the security service includes at least one of: authentication, encryption, terms of use of authentication, and terms of use of encryption.
3. The method as recited in claim 2, wherein the security service includes at least one of a security association and an inner-Internet Protocol (IP) header.
4. The method as recited in claim 2, wherein the security service includes the IPSec transformation.
5. The method as recited in claim 1, wherein the hash is order-dependent.
6. The method as recited in claim 1, wherein the hash has a fixed length.
7. The method as recited in claim 1, wherein the hash is generated utilizing an XOR operation.
8. The method as recited in claim 1, wherein the hash is generated utilizing a random number.
9. The method as recited in claim 8, wherein the random number is unique to a security association and any descendents of the security association.
10. The method as recited in claim 1, wherein the hash that is generated for a first instance of the security service is the same as the hash that is generated for a subsequent instance of the security service.
11. The method as recited in claim 1, and further comprising determining whether the packet is a synchronize acknowledgement (SYN/ACK) packet.
12. The method as recited in claim 11, if it is determined that the packet is the SYN/ACK packet, further comprising retrieving another control block associated with the SYN/ACK packet, which includes another hash.
13. The method as recited in claim 12, wherein, if the another hash associated with the SYN/ACK packet matches the hash associated with the control block, further comprising accepting the SYN/ACK packet, and generating a handshake ACK packet.
14. The method as recited in claim 12, wherein, if the another hash associated with the SYN/ACK packet matches the hash associated with the control block, further comprising generating a handshake ACK packet.
15. The method as recited in claim 12, wherein, if the another hash associated with the SYN/ACK packet does not match the hash associated with the control block, further comprising rejecting the SYN/ACK packet.
16. The method as recited in claim 1, and further comprising determining whether the packet is neither a synchronize (SYN) packet nor a synchronize acknowledgement (SYN/ACK) packet.
17. The method as recited in claim 16, if it is determined that the packet is neither the SYN packet nor the SYN/ACK packet, further comprising retrieving another control block associated with the packet, which includes another hash.
18. The method as recited in claim 17, wherein, if the another hash associated with the packet matches the hash associated with the control block, further comprising accepting the packet.
19. The method as recited in claim 17, wherein, if the another hash associated with the packet does not match the hash associated with the control block, further comprising rejecting the packet.
20. The method as recited in claim 1, and further comprising requesting a client connection.
21. The method as recited in claim 20, and further comprising generating another synchronize (SYN) packet.
22. The method as recited in claim 21, and further comprising receiving another SYN/ACK packet in response to the another SYN packet.
23. The method as recited in claim 22, and further comprising calculating another hash associated with the another SYN/ACK packet.
24. The method as recited in claim 23, wherein, if the another hash associated with the another SYN/ACK packet matches the hash associated with the control block, further comprising accepting the another SYN/ACK packet, and generating a handshake ACK packet.
25. The method as recited in claim 23, wherein, if the another hash associated with the another SYN/ACK packet does not match the hash associated with the control block, further comprising rejecting the another SYN/ACK packet.
26. The method as recited in claim 1, wherein the security service is validated at a network protocol layer that resides above an IPSec protocol layer.
27. The method as recited in claim 1, wherein at least one of the decrypting and the authenticating is performed on the packet utilizing an ordered-list of IPSec transformations.
28. The method as recited in claim 1, wherein the IPSec transformation includes an IPSec transformation utilized to perform the decrypting and the authenticating on the packet.
29. The method as recited in claim 1, wherein the hash is calculated utilizing an order-dependent XOR checksum with rotate operation.
30. The method as recited in claim 1, wherein when an authenticated packet is received that does not have a matching hash, the transport offload engine generates an exception and limits Internet security association and key management protocol (ISAKMP) establishment with a source IP address associated with the authenticated packet.
31. The method as recited in claim 1, wherein the hash of the security service based on the packet is calculated utilizing a security association, an ordered list of security association handles, and a plurality of IP headers.
32. The method as recited in claim 31, wherein the hash of the security service is calculated by:
setting an initial hash value to 0;
calculating a first rotate-left value by performing a rotate-left operation on the initial hash value;
calculating a first random value utilizing a first of the plurality of IP headers and a first of the security association handles associated with the first of the plurality of IP headers;
calculating a first hash value by performing an XOR operation between the first rotate-left value and the first random value;
calculating a second rotate-left value by performing a rotate-left operation on the first hash value;
calculating a second random value utilizing a second of the plurality of IP headers and a second of the security association handles associated with the second of the plurality of IP headers;
calculating a second hash value by performing an XOR operation between the second rotate-left value and the second random value;
calculating a third rotate-left value by performing a rotate-left operation on the second hash value;
calculating a third random value utilizing an inner IP header of the plurality of IP headers and a third of the security association handles associated with the inner IP header of the plurality of IP headers;
calculating a third hash value by performing an XOR operation between the third rotate-left value and the third random value;
calculating a fourth rotate-left value by performing a rotate-left operation on the third hash value;
calculating a fourth random value utilizing a fourth of the plurality of the IP headers and a fourth of the security association handles associated with the fourth of the plurality of IP headers; and
calculating the hash by performing an XOR operation between the fourth rotate-left value and the fourth random value.
33. A transport offload engine sub-system, comprising:
a transport offload engine, which includes a tangible circuit, in communication with a hardware processor and a network, the transport offload engine for:
receiving a packet,
decrypting and authenticating the packet, the decrypting utilizing an Internet Protocol Security (IPSec) transformation,
calculating a hash of a security service based on the packet,
determining whether the packet is a SYN packet,
in response to a determination that the packet is a SYN packet, sending the SYN packet to a processor, sending the IPSec transformation to the processor, and sending the hash to the processor for performing IPSec policy checking of the SYN packet and determining that the SYN packet and a connection related to the SYN packet are allowed based on the IPSec policy checking, utilizing the processor,
in response to the determination that the SYN packet and the related connection are allowed, and prior to generating a SYN/ACK packet, generating a control block including the hash, the control block for network socket management,
generating the SYN/ACK packet based on the SYN packet, and
sending the SYN/ACK packet.
a transport offload engine in communication with the hardware processor and a network via a bus, the transport offload engine for:
sending the SYN packet from the transport offload engine to the processor,
sending the hash from the transport offload engine to the processor,
in response to a determination that the SYN packet and the related connection are allowed, and prior to generating a SYN/ACK packet, generating a control block including the hash, the control block for network socket management,
sending the SYN/ACK packet;
wherein the hardware processor is operable to:
perform IPSec policy checking of the SYN packet, and
determine that the SYN packet and a connection related to the SYN packet are allowed based on the IPSec policy checking.
35. A computer program product embodied on a non-transitory computer readable medium for validating a security service associated with packets communicated on a network, comprising:
computer code for receiving a packet at a transport offload engine;
computer code for decrypting and authenticating the packet utilizing the transport offload engine, the decrypting utilizing an Internet Protocol Security (IPSec) transformation;
computer code for calculating a hash of a security service based on the packet, utilizing the transport offload engine;
computer code for determining whether the packet is a SYN packet utilizing the transport offload engine;
computer code for, in response to a determination that the packet is a SYN packet:
sending the hash from the transport offload engine to the processor;
computer code for performing IPSec policy checking of the SYN packet utilizing the processor;
computer code for determining that the SYN packet and a connection related to the SYN packet are allowed based on the IPSec policy checking, utilizing the processor;
computer code for, in response to the determination that the SYN packet and the related connection are allowed, and prior to generating a SYN/ACK packet, generating a control block including the hash utilizing the transport offload engine, the control block for network socket management;
computer code for generating the SYN/ACK packet based on the SYN packet, utilizing the transport offload engine; and
computer code for sending the SYN/ACK packet utilizing the transport offload engine. Description
The present invention relates to network policy management, and more particularly to performing policy checking in an efficient manner.
IPsec (Internet Protocol Security) is a framework for a set of protocols for security at a network or packet processing layer of network communication. Earlier security approaches inserted security at the application layer of the communications model. IPsec is thus particularly useful for implementing virtual private networks and for remote user access through various connections to private networks.
One advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. IPsec provides two choices of security service. First provided is an authentication header (AH), which essentially allows authentication of the sender of data. Further provided is an encapsulating security payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is typically inserted into the packet in a header that follows the IP packet header.
In the context of the present description, a security association (SA) is defined as a relationship between two or more entities that describes how the entities utilize security services to communicate effectively. Physically, it may include a structure containing information on a set of agreements for communication including, for example, keys used for the decryption or authentication of packets. Moreover, a security parameter index (SPI) is combined with the destination IP and security protocol (AH or ESP) to uniquely specify an SA. Each AH and ESP header may, for example, contain a 32-bit SPI field.
Prior art FIG. 1 illustrates an exemplary framework 100 of IPSec layers and corresponding SAs in a packet, in accordance with the prior art. As shown, four (4) SAs are provided in the present exemplary framework 100. Of course, however, it should be noted that there could be as few as one and no theoretical limit (i.e. with iterated tunneling). Also note that there is an IP header separating the SAs.
The SAs are arbitrarily labeled A, B, C and D. Another packet may or may not use A, B, C or D, but instead use another SA, such as F (unillustrated). In use, each SA has a limited lifetime and a successor may be setup before it expires so that the successor can seamlessly replace it (without interrupting the connection). In the context of the present description, each generation of an SA is denoted by an associated index. For example, SA F5 would succeed F4, and so forth. It should be noted that the successor SA may have a completely different identity (SPI) and encryption/authentication keys with respect to any predecessor.
In the past, IPSec processing involving the foregoing framework 100 has typically been carried out utilizing a processor. However, such IPSec processing can be quite cumbersome for a processor, and further drain associated resources during use. Thus, there is a continuing need to integrate IPSec processing into transport offload engines.
Transport offload engines (TOE) are gaining popularity in high-speed systems for the purpose of optimizing throughput and lowering processor utilization. TOE components are often incorporated into one of various systems including printed circuit boards such as a network interface card (NIC), a host bus adapter (HBA), a motherboard; or in any other desired offloading context.
In recent years, the communication speed in networks has increased faster than processor speed. This increase has produced an input/output (I/O) bottleneck. The processor, which is designed primarily for computing and not for I/O, cannot typically keep up with the data flowing through networks. As a result, the data flow is processed at a rate slower than the speed of the network. TOE technology solves this problem by removing the burden from the processor (i.e. offloading processing) and/or I/O subsystem.
While a TOE may be used to offload a processor of IPSec-type processing, such processing is still quite expensive, even for the TOE. There is thus a need for more efficient techniques of performing IPSec-type processing in the context of a system equipped with a TOE.
In embodiment, the security service may include any of the following: authentication, encryption, terms of use of authentication, and/or terms of use of encryption. For example, the security service may include at least one security association (SA), an inner-Internet Protocol (IP) header, etc. More particularly, as an option, the security service may include at least one Internet Protocol Security (IPSec) transformation.
In another embodiment, the hash may be generated utilizing a transport offload engine. Optionally, the hash may be order-dependent, fixed in length, etc. Still yet, the hash may be generated utilizing an XOR operation, a random number, etc. Further, the hash that is generated for a first instance of the security service may be the same as the hash that is generated for a subsequent instance of the security service. Moreover, the security service may include a plurality of security associations and inner-IP headers, and the corresponding hashes may be generated utilizing the same random number.
In use from a server socket (i.e. connection) perspective, upon receipt of a packet, it is determined whether the packet is a synchronize (SYN) packet. If it is determined that the packet is a SYN packet; the SYN packet, an associated Internet Protocol Security (IPSec) transformation, and the hash may be sent from a transport offload engine to a processor.
Thus, it may be determined whether the SYN packet is accepted. If the SYN packet is accepted, a control block may be generated which includes the hash. A SYN acknowledgment (SYN/ACK) packet may then be generated.
In use from a client socket perspective, a client connection is initially requested. Next, a control block is generated which includes the hash. Still yet, a SYN packet may be generated. After waiting for a response, a SYN/ACK packet may be received in response to the SYN packet.
A hash associated with the packet is then calculated, and a control block (which includes the hash) associated with the SYN/ACK packet is retrieved. If the hash associated with the SYN/ACK packet matches the hash associated with the control block, the SYN/ACK packet is accepted. Still yet, if the hash associated with the SYN/ACK packet matches the hash associated with the control block, a handshake ACK packet may be generated. On the other hand, if the hash associated with the SYN/ACK packet does not match the hash associated with the control block, the SYN/ACK packet may be rejected.
Still yet, if it is determined that the packet received is neither a SYN packet nor a SYN/ACK packet, a control block (which includes the hash) associated with the packet may be retrieved, similar to before. If a hash associated with the packet matches the hash associated with the control block, the packet may be accepted. If not, the packet may be rejected.
To this end, IPSec processing may optionally be offloaded from the processor, utilizing the transport offload engine. Further, the security service may be validated at a network protocol layer that resides above an IPSec protocol layer, to facilitate processing.
Prior art FIG. 1 illustrates an exemplary framework of Internet protocol security (IPSec) layers and corresponding security associations (SAs) in a packet, in accordance with the prior art.
FIG. 4A illustrates an exemplary method for security service validation from a server socket (i.e. connection) perspective, in accordance with one embodiment.
FIG. 4B illustrates a continuation of the security service validation method of FIG. 4A for operation when a synchronize acknowledgment (SYN/ACK) packet is received.
FIG. 4C illustrates a continuation of the security service validation method of FIG. 4A for operation when neither a SYN packet nor a SYN/ACK packet is received.
FIG. 5 illustrates an exemplary method for security service validation from a client socket perspective, in accordance with one embodiment.
FIG. 6 illustrates an exemplary framework for generating a hash, in accordance with one embodiment.
Coupled to the network 202 are a local host 204 and a remote host 206 which are capable of communicating over the network 202. In the context of the present description, such hosts 204, 206 may include a web server, storage device or server, desktop computer, lap-top computer, hand-held computer, printer or any other type of hardware/software. It should be noted that each of the foregoing components as well as any other unillustrated devices may be interconnected by way of one or more networks.
As shown, the architecture 300 includes a plurality of components coupled via a bus 302. Included is at least one processor 304 for processing data. While the processor 304 may take any form, it may, in one embodiment, take the form of a central processing unit (CPU), a host processor, a chipset (i.e. a group of integrated circuits designed to work and sold as a unit for performing related functions, etc.), or any other desired processing device(s) capable of processing data.
Further included is processor system memory 306 which resides in communication with the processor 304 for storing the data. Such processor system memory 306 (e.g. a computer readable medium) may take the form of on-board or off-board random access memory (RAM), a hard disk drive, a removable storage drive (i.e., a floppy disk drive, a magnetic tape drive, a compact disk drive, etc.), and/or any other type of desired memory capable of storing data.
Further shown is a transport offload engine 312 in communication with the processor 304 and the network (see, for example, network 202 of FIG. 2). In one embodiment, the transport offload engine 312 may remain in communication with the processor 304 via the bus 302. Of course, however, the transport offload engine 312 may remain in communication with the processor 304 via any mechanism that provides communication therebetween. The transport offload engine 312 may include a transport (i.e. TCP/IP) offload engine (TOE), system, or any integrated circuit(s) that is capable of managing the data transmitted in the network.
While a single bus 302 is shown to provide communication among the foregoing components, it should be understood that any number of bus(es) (or other communicating mechanisms) may be used to provide communication among the components. Just by way of example, an additional bus may be used to provide communication between the processor 304 and processor system memory 306.
During operation, the transport offload engine 312, processor 304 and/or software works to validate a security service associated with packets communicated on a network. It should thus be noted that the present technology may be implemented in hardware, software, or both.
In the context of the present description, such security service may include any of the following: authentication, encryption, terms of use of authentication, terms of use of encryption and/or any service related to security. For example, the security service may include at least one security association (SA), an inner-Internet Protocol (IP) header, etc. Again, an SA may include a relationship between two or more entities that describes how the entities utilize a security service to communicate effectively. More information will be set forth regarding inner-IP headers during reference to FIG. 6. More particularly, as an option, the security service may include at least one Internet Protocol Security (IPSec) transformation.
To accomplish the aforementioned validation, a hash of the security service is generated by the transport offload engine 312, the processor 304, or any other mechanism (i.e. hardware and/or software). Thus, in use, the security service associated with the packets may be validated utilizing the hash.
To this end, security service validation may be carried out in an improved and/or more efficient manner. More information will now be set forth regarding one exemplary method by which the hash is generated and utilized in the foregoing manner.
FIGS. 4A-C illustrate an exemplary method 400 for security service validation from a server socket (i.e. connection) perspective, in accordance with one embodiment. As an option, the method 400 may be carried out in the context of the exemplary architecture 300 of FIG. 3. Of course, however, it should be noted that the method 400 may be implemented in any desired context. Moreover, while various functions may be attributed to exemplary components (i.e. like those set forth hereinabove), it is important to understand that the various functionality may be carried out by any desired entity.
As shown in FIG. 4A, a packet is received. See operation 402. In one embodiment, the packet may be received utilizing a transport offload engine (see, for example, transport offload engine 312 of FIG. 3). Next, in operation 404, the packet is decrypted and/or authenticated, utilizing the transport offload engine. Such decryption and/or authentication may be accomplished utilizing an ordered-list of Internet Protocol Security (IPSec) transformations.
More information regarding this IPSec and related processing may be found with reference to an application entitled “GIGABIT ETHERNET ADAPTER SUPPORTING THE ISCSI AND IPSEC PROTOCOLS” filed Jun. 5, 2003 under Ser. No. 10/456,871, which is incorporated herein by reference in its entirety.
Thereafter, continued operation varies depending on whether the incoming packet includes a synchronize (SYN) packet, a SYN acknowledgment (SYN/ACK), or neither. Specifically, in decision 406, it is determined whether the present packet is a SYN packet. This may be accomplished utilizing the transport offload engine or a processor (see, for example, processor 304 of FIG. 3).
In the context of the present description, a SYN packet may include any packet, signal, etc. that initiates the synchronization process necessary to establish a connection. Moreover, the SYN packet may include a header flag identifying the packet as a SYN packet. Such flag may thus be used in making the decision 406. As will soon become apparent, such SYN packet may be received from a remote TCP host. More information regarding similar operation from a client socket perspective will be set forth in greater detail during reference to FIG. 5.
If the present packet is a SYN packet per decision 406, the decrypted and/or authenticated SYN packet, the IPSec transformations, and the hash are sent from the transport offload engine to the processor. See operation 410. To this end, the processor is capable of performing further IPSec processing on the SYN packet. Specifically, the processor may perform IPSec policy checking at the TCP layer to determine whether the SYN packet (and the related connection) should be allowed.
If the IPSec policy checking is successful and the processor determines that the SYN packet (and the related connection) should be allowed (see decision 412), a control block is generated which includes the hash, utilizing the transport offload engine. Note operation 414. In the context of the present description, the control block may include any data structure including the hash and any other information capable of facilitating network socket management.
Optionally, the aforementioned hash may be order-dependent, fixed in length, etc. Still yet, the hash may be generated utilizing an XOR operation, a random number, etc. Such random number may further be unique to a security association, and any descendents of the security association. Further, the hash that is generated for a first instance of the security service may be the same as the hash that is generated for a subsequent instance of the security service. In any case, in the context of the present description, the hash may include any unique (or substantially unique) key associated with the security service (as defined herein). More information regarding one exemplary way in which the hash may be calculated will be set forth during reference to FIG. 6.
A SYN/ACK packet may then be generated and sent in response to the SYN packet, utilizing the transport offload engine. Note operation 416. Such SYN/ACK packet may serve as the second of three packets that, together, are capable of establishing a socket connection.
Returning to decision 406 of FIG. 4A, if the present packet is not a SYN packet, it is then determined whether the packet is a SYN/ACK packet in decision 408. If so, the process continues in FIG. 4B, as indicated.
With reference now to FIG. 4B, a control block (which includes the aforementioned hash) associated with the SYN/ACK packet may be retrieved. See operation 418. In particular, the control block associated with the connection corresponding with the SYN/ACK packet may be retrieved. To this end, a comparison of the hashes may be made by the transport offload engine, as indicated by decision 420.
As an option, an IPSec enable bit may be included in a control block associated with a socket connection. The IPSec enable bit may be used to indicate whether the associated connection should be IPSec protected or not. When a packet is received, a bit is tracked along with the packet to indicate whether the packet received included any IPSec protocols. In this manner, the IPSec bit tracked with the received packet may be compared to the IPSec enable bit in the control block associated with the received packet. If the two aforementioned bits do not match, then the packet may be rejected. A secondary measure of integrity is thus provided over and above that provided by the use of the hash.
Returning now to FIG. 4B, if the hash associated with the SYN/ACK packet matches the hash associated with the control block, the SYN/ACK packet may be accepted. See operation 424. In such case, a handshake ACK packet may be generated and sent over the network, thus completing the connection establishment process. Note operation 426. On the other hand, if the hash associated with the SYN/ACK packet does not match the hash associated with the control block (per decision 420), the SYN/ACK packet may be rejected. Note operation 422.
Returning again to FIG. 4A, if it is determined that the packet is neither a SYN packet nor a SYN/ACK packet (note operations 406 and 408), operation may continue per FIG. 4C. Specifically, a control block (which includes the hash) associated with the packet may be retrieved, similar to before. See operation 430. If a hash associated with the packet matches the hash associated with the control block (per decision 432), the packet may be accepted. See operation 436. If, not, the packet may be rejected, as indicated in operation 434.
Similar to before, an IPSec enable bit indicating whether IPSec protocols should be used on the socket connection may be extracted from the control block associated with the received packet at this point in time. The IPSec enable bit, is then compared to a bit which indicates whether the received packet included at least one IPSec protocol. Assuming that there is a match, operation may continue as follows. Otherwise, a failed match may terminate further operation.
FIG. 5 illustrates an exemplary method 500 for security service validation from a client socket (i.e. connection) perspective, in accordance with one embodiment. As an option, the method 500 may be carried out in the context of the exemplary architecture 500 of FIG. 3 and, in combination with the server method 400 of FIGS. 4A-4C Of course, however, it should be noted that the method 500 may be implemented in any desired, sole context. Moreover, while various functions may be attributed to exemplary components (i.e. like those set forth hereinabove), it is important to understand that the various functionality may be carried out by any desired entity.
As shown, a client connection is initially requested, as indicated in operation 502. This may be accomplished in any desired manner. Just by way of example, a processor (see, for example, processor 304 of FIG. 3) may initiate the connection establishment process. Next, IPSec processing is performed in operation 504. Specifically, at least one IPSec policy is consulted or used for calculating a hash in a manner similar, if not identical, to that described hereinabove.
Next, in operation 506, a control block is generated which includes the hash, utilizing the transport offload engine. Still yet, in operation 508, a SYN packet may be generated and transmitted to a remote TCP host.
At this point, the present method 500 waits for a SYN/ACK packet response in operation 509, assuming that the hash is legitimate. After waiting for a response, the SYN/ACK packet may be received in operation 510.
A hash associated with the packet is then calculated in operation 512 during the course of either a decryption and/or authentication of the packet, similar to that disclosed during reference to operation 404 of FIG. 4A. Since, from the client perspective, many different packet types may be received after generating the SYN packet in operation 508, it is determined in decision 516 whether the packet received in operation 510 is a SYN/ACK packet. If the packet is indeed a SYN/ACK packet per decision 516, a control block (which includes the earlier calculated hash) associated with the connection of the SYN/ACK packet is retrieved. Note operation 520.
Another comparison operation is then made in decision 516. If the hash associated with the SYN/ACK packet matches the hash associated with the control block, the SYN/ACK packet is accepted. See operation 520. Moreover, a handshake ACK may be generated and transmitted in response to the SYN/ACK packet, as indicated in operation 522. Subsequent incoming packets after the handshake ACK is transmitted are processed in accordance to FIGS. 4A-C. If, however, the hash associated with the SYN/ACK packet does not match the hash associated with the control block, the SYN/ACK packet is rejected in operation 518.
To this end, IPSec processing may optionally be offloaded from the processor, utilizing the transport offload engine. Further, the security service may be validated at a network protocol layer that resides above the IPSec protocol layer, to facilitate processing. More information will now be set forth regarding one exemplary technique by which the aforementioned hashes may be calculated.
FIG. 6 illustrates an exemplary framework 600 involved in generating a hash, in accordance with one embodiment. As an option, the framework 600 may be used in the context of the disclosure of the previous figures. For example, the framework 600 may be used in the context of operations 404 of FIG. 4A, and operations 504 and 512 of FIG. 5.
Of course, however, it should be noted that the framework 500 may be implemented in any desired context. Most importantly, the exemplary framework 500 is set forth for illustrative purposes only, and should not be considered as limiting in any manner.
In use, a function is applied to a plurality of security associations (SAs) and inner-IP headers. Such function, in one embodiment, may include an order-dependent XOR checksum with rotate operation. Note Equation (s) #1.
H′=ROL(H)XOR RAND[x] Equation(s) #1
As shown, RAND[x] includes a random value stored in the SA for SA handle ‘x’, where a handle includes an identifier that references a particular SA. There is also a special case denoted by ‘RAND[IP]’ where IP denotes the encounter of any inner-IP header instead of an SA handle, and is stored separately. Moreover, ROL is a rotate-left operator. H′ includes the new hash value, while H includes the old hash value (initially set to 0).
Thus, to apply to an ordered list of SA handles and IP headers {s, t, IP, u}, where ‘IP’ denotes the encounter of an inner IP header, the operations of Equation (s) #2 would be carried out.
H′=ROL(H)XOR RAND[s]
H″=ROL(H′)XOR RAND[t]
H′″=ROL(H″)XOR RAND[IP]
H″″=ROL(H′″)XOR RAND[u] Equation(s) #2
By this design, an attacker cannot successfully use the same SA handle as the host it is trying to spoof without knowing the hash for that SA-handle. Therefore, an attacker may use a different SA handle, and this results in another random hash value.
Thus, in the present embodiment, it is still possible for an attacker to use a brute force attack. The number of tries needed to randomly collide with a given hash with probability � is ln(2)*(232) for a 32-bit hash. To protect against this, an exception may be generated by the transport offload engine when there is an authenticated packet that does not have a matching hash. This may be used as a strong indicator of an attack.
It is improbable that a corrupted TCP/IP packet would pass TCP checksum, IP checksum, and authentication; but then fail the hash test. In this case, the best course of action may be to deny or limit further Internet security association and key management protocol (ISAKMP) establishment with the attacker source IP address. The attacker thus has a very high probability of being identified because the hash used would be the attacker's hash, which has a probability of at most (216)/(232)=1/(216) of colliding with another hash. This assumes at most 216 SAs are supported on the receive side. If more SAs are to be supported, the number of bits for the hash should be increased.
To further increase confidence, subsequent attempts by the attacker again have only a 1/(216) chance of colliding, therefore after ‘p’ attempts there is only a 1/(216)p chance of ambiguous identity. Since on the order of 216 attempts are needed to successfully spoof the connection, it can be assured that the attacker can be identified and further ISAKMP negotiations with him/her halted until all existing SAs have retired (that is, until the system is outside the scope of this attack).
Thus, the aforementioned function yields one number H, the hash. As mentioned earlier, this hash may be compared against pre-calculated stored values in a connection management database/data structure which may be re-calculated as part of establishing a connection (based on an actual IPSec policy database, etc.). Each packet may thus be accepted or rejected based on a similar comparison.
In one embodiment, the aforementioned function may ensure that only packets with the following SAs and IP headers of Table #1 are acceptable (in order).
(Ai, Bj, IP, Ck, Dl) for all i, j, k, l
Thus, a packet may be rejected if the associated SAs are in the wrong order. Note Table #2.
(B1, A0, IP, C3, D2)
Further, a packet may be rejected if the packet has too few or too many SAs. Note Table #3.
(A1, B3, IP, C2)
Still yet, a packet may be rejected if the packet has a wrong SA(s). Note Table #4.
(A0, F5, IP, C3, D2)
Still yet, a packet may be rejected if the packet has too many or too few IP headers. Note Table #5.
(A0, B5, IP, C3, D2, IP)
Still yet, a packet may be rejected if the packet has IP headers in the wrong position. Note Table #6.
(A0, B5, C3, IP, D2)
Thus, a one-time-pad may be applied so that each current and future Ak (where k=0 . . . x) maps to one fixed (randomly chosen) value, which may be subsequently used as a substitute, at least in part, for resource-intensive conventional IPSec processing.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS212889Nov 1, 1877Mar 4, 1879 Improvement in road-enginesUS4807111Jun 19, 1987Feb 21, 1989International Business Machines CorporationDynamic queueing methodUS4839851Jul 13, 1987Jun 13, 1989Idaho Research Foundation, Inc.Programmable data path deviceUS4965716Mar 11, 1988Oct 23, 1990International Business Machines CorporationFast access priority queue for managing multiple messages at a communications node or managing multiple programs in a multiprogrammed data processorUS4991133Oct 7, 1988Feb 5, 1991International Business Machines Corp.Specialized communications processor for layered protocolsUS5012489Nov 7, 1988Apr 30, 1991Hayes Microcomputer Products, Inc.Method for sending a plurality of data channels over a single communications lineUS5056058Mar 5, 1990Oct 8, 1991Hitachi, Ltd.Communication protocol for predicting communication frame type in high-speed processing systemUS5058110May 3, 1989Oct 15, 1991Ultra Network TechnologiesProtocol processorUS5161193Jun 29, 1990Nov 3, 1992Digital Equipment CorporationPipelined cryptography processor and method for its use in communication networksUS5163131Sep 8, 1989Nov 10, 1992Auspex Systems, Inc.Parallel i/o network file server architectureUS5307413Jul 19, 1991Apr 26, 1994Process Software CorporationMethod and apparatus for adding data compression and other services in a computer networkUS5426694Oct 8, 1993Jun 20, 1995Excel, Inc.Telecommunication switch having programmable network protocols and communications servicesUS5430727May 19, 1994Jul 4, 1995Digital Equipment CorporationMultiple protocol routingUS5440551Jan 4, 1994Aug 8, 1995Nec CorporationMultimedia packet communication systemUS5442637Oct 15, 1992Aug 15, 1995At&T Corp.Reducing the complexities of the transmission control protocol for a high-speed networking environmentUS5448558Apr 5, 1994Sep 5, 1995International Business Machines CorporationMethod and apparatus for managing packet FIFOSUS5455599Apr 4, 1995Oct 3, 1995Taligent Inc.Object-oriented graphic systemUS5485460Aug 19, 1994Jan 16, 1996Microsoft CorporationSystem and method for running multiple incompatible network protocol stacksUS5495480Jun 21, 1994Feb 27, 1996Nec CorporationPacket transmission system having timer for circuit disconnectionUS5499353Jun 20, 1995Mar 12, 1996Ast Research, Inc.Cache address strobe control logic for stimulated bus cycle initiationUS5513324Mar 7, 1994Apr 30, 1996Echelon Systems CorporationMethod and apparatus using network variables in a multi-node networkUS5519704Apr 21, 1994May 21, 1996Cisco Systems, Inc.Reliable transport protocol for internetwork routingUS5544357May 26, 1995Aug 6, 1996Paracom CorporationDatabase acceleratorUS5546453Jun 7, 1995Aug 13, 1996Excel, Inc.Telecommunication switch having programmable network protocols and communications servicesUS5566170Dec 29, 1994Oct 15, 1996Storage Technology CorporationMethod and apparatus for accelerated packet forwardingUS5577105Mar 11, 1994Nov 19, 1996U.S. Robotics, Inc.Telephone call routing and switching techniques for data communicationsUS5577172Aug 31, 1994Nov 19, 1996Lasermaster CorporationHigh-capacity protocol for packet-based networksUS5577237Jan 23, 1995Nov 19, 1996Tandem Computers, IncorporatedProtocol timer and method of using sameUS5581686Jun 6, 1995Dec 3, 1996Microsoft CorporationMethod and system for in-place interaction with contained objectsUS5596702Apr 16, 1993Jan 21, 1997International Business Machines CorporationMethod and system for dynamically sharing user interface displays among a plurality of application programUS5598410Dec 29, 1994Jan 28, 1997Storage Technology CorporationMethod and apparatus for accelerated packet processingUS5619650Sep 21, 1995Apr 8, 1997International Business Machines CorporationNetwork processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the messageUS5621434Aug 11, 1993Apr 15, 1997Object Technology Licensing Corp.Cursor manipulation system and methodUS5625678May 24, 1995Apr 29, 1997Microsoft CorporationMethod and system for allowing switched voice and data communication among multiple application programsUS5625825Oct 21, 1993Apr 29, 1997Lsi Logic CorporationRandom number generating apparatus for an interface unit of a carrier sense with multiple access and collision detect (CSMA/CD) ethernet data networkUS5634015Oct 4, 1994May 27, 1997Ibm CorporationGeneric high bandwidth adapter providing data communications between diverse communication networks and computer systemUS5636371Jun 7, 1995Jun 3, 1997Bull Hn Information Systems Inc.Virtual network mechanism to access well known port application programs running on a single host systemUS5640394Jan 16, 1996Jun 17, 1997Microsoft CorporationSystem and method for running multiple incompatible network protocol stacksUS5650941Dec 29, 1995Jul 22, 1997Intel CorporationComputer architecture for creating and manipulating displayable objectsUS5663951Jun 6, 1995Sep 2, 1997Intel CorporationDelayed transmission of data packets over networksUS5664162Nov 3, 1994Sep 2, 1997Cirrus Logic, Inc.Graphics accelerator with dual memory controllersUS5666362Jul 25, 1995Sep 9, 19973Com CorporationMethod and apparatus for asynchronous PPP and synchronous PPP conversionUS5675507Apr 28, 1995Oct 7, 1997Bobo, Ii; Charles R.Message storage and delivery systemUS5678060Oct 28, 1994Oct 14, 1997Hitachi, Ltd.System for executing high speed communication protocol processing by predicting protocol header of next frame utilizing successive analysis of protocol header until successful header retrievalUS5680605Feb 7, 1995Oct 21, 1997Torres; Robert J.Method and apparatus for searching a large volume of data with a pointer-based device in a data processing systemUS5687314Jun 9, 1992Nov 11, 1997Tele Digital Development, Inc.Method and apparatus for assisting data bus transfer protocolUS5696899Nov 18, 1992Dec 9, 1997Canon Kabushiki KaishaMethod and apparatus for adaptively determining the format of data packets carried on a local area networkUS5699350Oct 6, 1995Dec 16, 1997Canon Kabushiki KaishaReconfiguration of protocol stacks and/or frame type assignments in a network interface deviceUS5701316Aug 31, 1995Dec 23, 1997Unisys CorporationMethod for generating an internet protocol suite checksum in a single macro instructionUS5717691 *Oct 30, 1995Feb 10, 1998Nec Usa, Inc.Multimedia network interface for asynchronous transfer mode communication systemUS5727149Dec 21, 1995Mar 10, 1998Hitachi, Ltd.Network interface apparatus and data transmission control method thereofUS5734852Mar 8, 1996Mar 31, 1998Object Technology Licensing Corp.Method and apparatus for displaying hardware dependent graphics in an object-oriented operating systemUS5734865Jun 27, 1995Mar 31, 1998Bull Hn Information Systems Inc.Virtual local area network well-known port routing mechanism for mult--emulators in an open system environmentUS5748905Aug 30, 1996May 5, 1998Fujitsu Network Communications, Inc.Frame classification using classification keysUS5754540Jul 18, 1995May 19, 1998Macronix International Co., Ltd.Expandable integrated circuit multiport repeater controller with multiple media independent interfaces and mixed media connectionsUS5754556Jul 18, 1996May 19, 1998Teradyne, Inc.Semiconductor memory tester with hardware acceleratorsUS5761281Jul 30, 1996Jun 2, 19983Com CorporationTelephone call routing and switching techniques for data communicationsUS5778178Aug 5, 1996Jul 7, 1998Arunachalam; LakshmiMethod and apparatus for enabling real-time bi-directional transactions on a networkUS5790546Dec 4, 1995Aug 4, 1998Cabletron Systems, Inc.Method of transmitting data packets in a packet switched communications networkUS5790676Sep 23, 1997Aug 4, 1998Hughes Electronics CorporationRadio port controller in a wireless personal communications systemUS5802287Aug 3, 1995Sep 1, 1998Lsi Logic CorporationSingle chip universal protocol multi-function ATM network interfaceUS5802306Oct 31, 1995Sep 1, 1998International Business Machines CorporationSupporting multiple client-server sessions from a protocol stack associated with a single physical adapter through use of a plurality of logical adaptersUS5805816Jan 28, 1997Sep 8, 1998Compaq Computer Corp.Network packet switch using shared memory for repeating and bridging packets at media rateUS5809235Mar 8, 1996Sep 15, 1998International Business Machines CorporationObject oriented network event management frameworkUS5815516Apr 5, 1996Sep 29, 1998International Business Machines CorporationMethod and apparatus for producing transmission control protocol checksums using internet protocol fragmentationUS5818935Mar 10, 1997Oct 6, 1998Maa; Chia-YiuInternet enhanced video systemUS5826032Feb 12, 1996Oct 20, 1998University Of Southern CaliforniaMethod and network interface logic for providing embedded checksumsUS5828880Jul 6, 1995Oct 27, 1998Sun Microsystems, Inc.Pipeline system and method for multiprocessor applications in which each of a plurality of threads execute all steps of a process characterized by normal and parallel steps on a respective datumUS5854750Sep 3, 1996Dec 29, 1998Insession, Inc.System and method for processing transactions in an environment containing a number of object oriented applicationsUS5870549Oct 6, 1997Feb 9, 1999Bobo, Ii; Charles R.Systems and methods for storing, delivering, and managing messagesUS5870622Oct 10, 1997Feb 9, 1999Advanced Micro Devices, Inc.Computer system and method for transferring commands and data to a dedicated multimedia engineUS5872919May 7, 1997Feb 16, 1999Advanced Micro Devices, Inc.Computer communication network having a packet processor with an execution unit which is variably configured from a programmable state machine and logicUS5877764Oct 23, 1992Mar 2, 1999International Business Machines CorporationGraphical user interface for managing text i/o between a user and a parallel programUS5894557Mar 29, 1996Apr 13, 1999International Business Machines CorporationFlexible point-to-point protocol frameworkUS5909546Mar 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 interactionUS5918051Jul 19, 1995Jun 29, 1999Ricoh Company, Ltd.Object-oriented communication system with support for multiple remote machine typesUS5920732Jul 1, 1996Jul 6, 1999Apple Computer, Inc.System for preallocating additional larger buffer sizes in accordance with packet sizes of discarded packets that can't be stored in existing preallocated buffer sizesUS5923892Oct 27, 1997Jul 13, 1999Levy; Paul S.Host processor and coprocessor arrangement for processing platform-independent codeUS5935268Jun 3, 1997Aug 10, 1999Bay Networks, Inc.Method and apparatus for generating an error detection code for a modified data packet derived from an original data packetUS5937169Oct 29, 1997Aug 10, 19993Com CorporationOffload of TCP segmentation to a smart adapterUS5941988Jan 27, 1997Aug 24, 1999International Business Machines CorporationSession and transport layer proxies via TCP glueUS5943481May 7, 1997Aug 24, 1999Advanced Micro Devices, Inc.Computer communication network having a packet processor with subsystems that are variably configured for flexible protocol handlingUS5946487Jun 10, 1996Aug 31, 1999Lsi Logic CorporationObject-oriented multi-media architectureUS5966534Jun 27, 1997Oct 12, 1999Cooke; Laurence H.Method for compiling high level programming languages into an integrated processor with reconfigurable logicUS5968161Feb 7, 1997Oct 19, 1999Altera CorporationFPGA based configurable CPU additionally including second programmable section for implementation of custom hardware supportUS5974518Apr 10, 1997Oct 26, 1999Milgo Solutions, Inc.Smart buffer size adaptation apparatus and methodUS5991299Sep 11, 1997Nov 23, 19993Com CorporationHigh speed header translation processingUS5999974Aug 29, 1997Dec 7, 1999International Business Machines CorporationInternet protocol assists for high performance LAN connectionsUS6014699Aug 29, 1997Jan 11, 2000International Business Machines CorporationInternet protocol assists for high performance LAN connectionsUS6016511Sep 12, 1997Jan 18, 2000Motorola Inc.Apparatus and method for interfacing protocol application data frame operation requests with a data frame input/output deviceUS6034963Oct 31, 1996Mar 7, 2000Iready CorporationMultiple network protocol encoder/decoder and data processorUS6046980Nov 24, 1997Apr 4, 2000Packeteer, Inc.System for managing flow bandwidth utilization at network, transport and application layers in store and forward networkUS6049857Jul 23, 1998Apr 11, 2000Sun Microsystems, Inc.Apparatus and method for translating addresses utilizing an ATU implemented within a network interface cardUS6061368Nov 5, 1997May 9, 2000Xylan CorporationCustom circuitry for adaptive hardware routing engineUS6061742Oct 10, 1997May 9, 2000Nortel Networks CorporationComputer network adaptorUS6067407Jun 30, 1995May 23, 2000Canon Information Systems, Inc.Remote diagnosis of network device over a local area networkUS6076115Apr 24, 1997Jun 13, 2000Xaqti CorporationMedia access control receiver and network management systemUS6078736Aug 28, 1997Jun 20, 2000Xilinx, Inc.Method of designing FPGAs for dynamically reconfigurable computingUS6081846May 8, 1997Jun 27, 2000Microsoft CorporationMethod and computer program product for reducing intra-system data copying during network packet processingUS6092110Oct 23, 1997Jul 18, 2000At&T Wireless Svcs. Inc.Apparatus for filtering packets using a dedicated processorUS6092229Oct 9, 1996Jul 18, 2000Lsi Logic CorporationSingle chip systems using general purpose processorsUS6098188Jun 30, 1995Aug 1, 2000Lucent Technologies Inc.Packet framerUS6101543Oct 25, 1996Aug 8, 2000Digital Equipment CorporationPseudo network adapter for frame capture, encapsulation and encryptionUS6122670Oct 30, 1997Sep 19, 2000Tsi Telsys, Inc.Apparatus and method for constructing data for transmission within a reliable communication protocol by performing portions of the protocol suite concurrentlyUS6141705Jun 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 neededUS6151625Apr 30, 1999Nov 21, 2000Schneider Automation Inc.Internet web interface including programmable logic controller for controlling output devices based on status of input devicesUS6157955Jun 15, 1998Dec 5, 2000Intel CorporationPacket processing system including a policy engine having a classification unitUS6172980Sep 11, 1997Jan 9, 20013Com CorporationMultiple protocol supportUS6172990Nov 12, 1997Jan 9, 2001Xaqti CorporationMedia access control micro-RISC stream processor and method for implementing the sameUS6173333Jul 17, 1998Jan 9, 2001Interprophet CorporationTCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocolsUS6182228Aug 17, 1998Jan 30, 2001International Business Machines CorporationSystem and method for very fast IP packet filteringUS6185619Nov 7, 1997Feb 6, 2001Genuity Inc.Method and apparatus for balancing the process load on network servers according to network and serve based policiesUS6208651Jun 9, 1998Mar 27, 2001Cornell Research Foundation, Inc.Method and system for masking the overhead of protocol layeringUS6212560May 8, 1998Apr 3, 2001Compaq Computer CorporationDynamic proxy serverUS6226680Apr 27, 1998May 1, 2001Alacritech, Inc.Intelligent network interface system method for protocol processingUS6230193Oct 31, 1996May 8, 20013Com CorporationMethod and apparatus supporting network communicationsUS6233626Oct 6, 1998May 15, 2001Schneider Automation Inc.System for a modular terminal input/output interface for communicating messaging application layer over encoded ethernet to transport layerUS6247060Nov 12, 1999Jun 12, 2001Alacritech, Inc.Passing a communication control block from host to a local device such that a message is processed on the deviceUS6247068Aug 21, 1997Jun 12, 2001Advanced Micro Devices Inc.Winsock-data link library transcoderUS6253321 *Jun 19, 1998Jun 26, 2001Ssh Communications Security Ltd.Method and arrangement for implementing IPSEC policy management using filter codeUS6272639Jul 31, 1998Aug 7, 2001Micron Technology, Inc.Mixed enclave operation in a computer networkUS6327625Nov 30, 1999Dec 4, 20013Com CorporationFIFO-based network interface supporting out-of-order processingUS6330248Dec 5, 1997Dec 11, 2001Advanced Micro Devices, Inc.Arrangement for transmitting data packets from a media access controller across multiple physical linksUS6330659Nov 6, 1997Dec 11, 2001Iready CorporationHardware accelerator for an object-oriented programming languageUS6334153Dec 26, 2000Dec 25, 2001Alacritech, Inc.Passing a communication control block from host to a local device such that a message is processed on the deviceUS6341129Apr 3, 1998Jan 22, 2002Alteon Networks, Inc.TCP resegmentationUS6345301Mar 30, 1999Feb 5, 2002Unisys CorporationSplit data path distributed network protocolUS6347347Dec 17, 1999Feb 12, 20023Com CorporationMulticast direct memory access storing selected ones of data segments into a first-in-first-out buffer and a memory simultaneously when enabled by a processorUS6370599Sep 7, 2000Apr 9, 2002Microsoft CorporationSystem for ascertaining task off-load capabilities of a device and enabling selected capabilities and when needed selectively and dynamically requesting the device to perform the taskUS6389479Aug 28, 1998May 14, 2002Alacritech, Inc.Intelligent network interface device and system for accelerated communicationUS6389537Apr 23, 1999May 14, 2002Intel CorporationPlatform and method for assuring integrity of trusted agent communicationsUS6393487Mar 12, 2001May 21, 2002Alacritech, Inc.Passing a communication control block to a local device such that a message is processed on the deviceUS6397316Jul 24, 1997May 28, 2002Intel CorporationSystem for reducing bus overhead for communication with a network interfaceUS6427169Jul 30, 1999Jul 30, 2002Intel CorporationParsing a packet headerUS6427171Feb 28, 2000Jul 30, 2002Alacritech, Inc.Protocol processing stack for use with intelligent network interface deviceUS6427173Dec 15, 1999Jul 30, 2002Alacritech, Inc.Intelligent network interfaced device and system for accelerated communicationUS6430628Dec 8, 1998Aug 6, 2002Intel CorporationMethod and apparatus for reducing direct memory access transfers using smart coalescingUS6434620Aug 27, 1999Aug 13, 2002Alacritech, Inc.TCP/IP offload network interface deviceUS6460080Oct 31, 2001Oct 1, 2002Intel CorporationCredit based flow control scheme over virtual interface architecture for system area networksUS6470415Oct 13, 1999Oct 22, 2002Alacritech, Inc.Queue system involving SRAM head, SRAM tail and DRAM bodyUS6530061Dec 23, 1999Mar 4, 2003Intel CorporationMethod and apparatus for offloading checksumUS6591302Mar 6, 2002Jul 8, 2003Alacritech, Inc.Fast-path apparatus for receiving data corresponding to a TCP connectionUS6609225Dec 21, 2000Aug 19, 2003Cisco Technology, Inc.Method and apparatus for generating and checking cyclic redundancy code (CRC) values using a multi-byte CRC generator on a variable number of bytesUS6629141Jul 2, 2002Sep 30, 2003Intel CorporationStoring a frame headerUS6658480Mar 9, 2001Dec 2, 2003Alacritech, Inc.Intelligent network interface system and method for accelerated protocol processingUS6687758Mar 7, 2001Feb 3, 2004Alacritech, Inc.Port aggregation for network connections that are offloaded to network interface devicesUS6697868Jul 29, 2002Feb 24, 2004Alacritech, Inc.Protocol processing stack for use with intelligent network interface deviceUS6751665Feb 19, 2003Jun 15, 2004Alacritech, Inc.Providing window updates from a computer to a network interface deviceUS6757746Feb 20, 2001Jun 29, 2004Alacritech, Inc.Obtaining a destination address so that a network interface device can write network data without headers directly into host memoryUS6789147 *Dec 19, 2001Sep 7, 2004Cavium NetworksInterface for a security coprocessorUS6807581Sep 29, 2000Oct 19, 2004Alacritech, Inc.Intelligent network storage interface systemUS6820117Oct 18, 1999Nov 16, 2004Sun Microsystems, Inc.Bandwidth managementUS6882624Oct 4, 2000Apr 19, 2005Nokia Networks OyCongestion and overload control in a packet switched networkUS6915426 *Jul 21, 2000Jul 5, 2005Networks Associates Technology, Inc.System and method for enabling authentication at different authentication strength-performance levelsUS6938092Aug 27, 2002Aug 30, 2005Alacritech, Inc.TCP offload device that load balances and fails-over between aggregated ports having different MAC addressesUS6941386Nov 12, 2003Sep 6, 2005Alacritech, Inc.Protocol processing stack for use with intelligent network interface deviceUS6965941Dec 17, 2001Nov 15, 2005Alacritech, Inc.Transmit fast-path processing on TCP/IP offload network interface deviceUS6996070Dec 5, 2003Feb 7, 2006Alacritech, Inc.TCP/IP offload device with reduced sequential processingUS7013482Jul 7, 2000Mar 14, 2006802 Systems LlcMethods for packet filtering including packet invalidation if packet validity determination not timely madeUS7042898Mar 9, 2001May 9, 2006Alacritech, Inc.Reducing delays associated with inserting a checksum into a network messageUS7340549Feb 14, 2006Mar 4, 2008Crossroads Systems, Inc.Storage router and method for providing virtual local storageUS20010021949May 14, 2001Sep 13, 2001Alacritech, Inc.Network interface device employing a DMA command queueUS20010023460Dec 26, 2000Sep 20, 2001Alacritech Inc.Passing a communication control block from host to a local device such that a message is processed on the deviceUS20010027496Mar 12, 2001Oct 4, 2001Alacritech, Inc.Passing a communication control block to a local device such that a message is processed on the deviceUS20010036196Mar 9, 2001Nov 1, 2001Blightman Stephen E. J.Reducing delays associated with inserting a checksum into a network messageUS20010037397Mar 9, 2001Nov 1, 2001Boucher Laurence B.Intelligent network interface system and method for accelerated protocol processingUS20010037406Mar 9, 2001Nov 1, 2001Philbrick Clive M.Intelligent network storage interface systemUS20010047433Feb 20, 2001Nov 29, 2001Alacritech, Inc.Obtaining a destination address so that a network interface device can write network data without headers directly into host memoryUS20020055993Oct 31, 2001May 9, 2002Shah Hemal V.Credit based flow control scheme over virtual interface architecture for system area networksUS20020085562Dec 12, 2001Jul 4, 2002International Business Machines CorporationIP headers for remote direct memory access and upper level protocol framingUS20020087732Dec 17, 2001Jul 4, 2002Alacritech, Inc.Transmit fast-path processing on TCP/IP offload network interface deviceUS20020091844Oct 2, 2001Jul 11, 2002Alacritech, Inc.Network interface device that fast-path processes solicited session layer read commandsUS20020095519Feb 26, 2002Jul 18, 2002Alacritech, Inc.TCP/IP offload device with fast-path TCP ACK generating and transmitting mechanismUS20020120899Jul 23, 2001Aug 29, 2002Gahan Richard A.Calculation and transmission of error check codesUS20020147839Mar 6, 2002Oct 10, 2002Boucher Laurence B.Fast-path apparatus for receiving data corresponding to a TCP connectionUS20020156927Mar 12, 2002Oct 24, 2002Alacritech, Inc.TCP/IP offload network interface deviceUS20020161919May 6, 2002Oct 31, 2002Boucher Laurence B.Fast-path processing for receiving data on TCP connection offload devicesUS20020163888Mar 7, 2002Nov 7, 2002Ron GrinfeldTCP transmission accelerationUS20030005142Jul 2, 2002Jan 2, 2003Uri ElzurStoring a frame headerUS20030005143Jul 2, 2002Jan 2, 2003Uri ElzurStoring a frame headerUS20030014544Feb 15, 2001Jan 16, 2003BanderacomInfiniband TM work queue to TCP/IP translationUS20030014624 *Feb 26, 2002Jan 16, 2003Andes Networks, Inc.Non-proxy internet communicationUS20030016669Jul 12, 2001Jan 23, 2003International Business Machines CorporationFull transmission control protocol off-loadUS20030031172May 30, 2002Feb 13, 2003Ron GrinfeldTCP receiver accelerationUS20030037237 *Apr 9, 2001Feb 20, 2003Jean-Paul AbgrallSystems and methods for computer device authenticationUS20030046330Sep 4, 2001Mar 6, 2003Hayes John W.Selective offloading of protocol processingUS20030046418Aug 31, 2001Mar 6, 2003Jignesh RavalMethod and system for verifying the hardware implementation of TCP/IPUS20030056009Sep 6, 2002Mar 20, 2003Siliquent Technologies Inc.Efficient IP datagram reassemblyUS20030058870Sep 6, 2002Mar 27, 2003Siliquent Technologies Inc.ISCSI receiver implementationUS20030061505Aug 30, 2002Mar 27, 2003Todd SperrySystems and methods for implementing host-based security in a computer networkUS20030066011Apr 11, 2002Apr 3, 2003Siliquent Technologies Ltd.Out-of-order calculation of error detection codesUS20030079033Jul 29, 2002Apr 24, 2003Alacritech, Inc.Protocol processing stack for use with intelligent network interface deviceUS20030081600 *Oct 30, 2001May 1, 2003Blaker David M.Methods, systems and computer program products for packet ordering for parallel packet transform processingUS20030084185Oct 30, 2001May 1, 2003Microsoft CorporationApparatus and method for scaling TCP off load buffer requirements by segment sizeUS20030095567Nov 20, 2001May 22, 2003Lo Man KukReal time protocol packet handlerUS20030108033Jan 15, 2001Jun 12, 2003V. RaisanenEmulating of information flowUS20030115350Dec 14, 2001Jun 19, 2003Silverback Systems, Inc.System and method for efficient handling of network dataUS20030115417Feb 14, 2002Jun 19, 2003Corrigan Brian E.Methods and apparatus for loading CRC values into a CRC cache in a storage controllerUS20030128704Aug 28, 2002Jul 10, 2003Shay MizrachiTCP/IP reorderingUS20030140124Aug 27, 2002Jul 24, 2003Alacritech, Inc.TCP offload device that load balances and fails-over between aggregated ports having different MAC addressesUS20030145101Jul 8, 2002Jul 31, 2003Stuart MitchellReduction of resource usage in TCP/IP implementationUS20030145270Jan 31, 2002Jul 31, 2003Holt Keith W.Method for using CRC as metadata to protect against drive anomaly errors in a storage arrayUS20030161327 *Feb 25, 2002Aug 28, 2003Zvi VlodavskyDistributing tasks in data communicationsUS20030167346Mar 7, 2001Sep 4, 2003Alacritech, Inc.Port aggregation for network connections that are offloaded to network interface devicesUS20030200284Apr 14, 2003Oct 23, 2003Alacritech, Inc.Freeing transmit memory on a network interface device prior to receiving an acknowledgement that transmit data has been received by a remote deviceUS20040003126Nov 7, 2001Jan 1, 2004Alacritech, Inc.TCP/IP offload network interface deviceUS20040054813Sep 17, 2002Mar 18, 2004Alacritech, Inc.TCP offload network interface deviceUS20040062246Jun 19, 2003Apr 1, 2004Alacritech, Inc.High performance network interfaceUS20040064578Sep 27, 2002Apr 1, 2004Alacritech, Inc.Fast-path apparatus for receiving data corresponding to a TCP connectionUS20040064589Sep 27, 2002Apr 1, 2004Alacritech, Inc.Fast-path apparatus for receiving data corresponding to a TCP connectionUS20040064590Sep 30, 2002Apr 1, 2004Alacritech, Inc.Intelligent network storage interface systemUS20040073703Sep 27, 2002Apr 15, 2004Alacritech, Inc.Fast-path apparatus for receiving data corresponding a TCP connectionUS20040078462Feb 19, 2003Apr 22, 2004Philbrick Clive M.Providing window updates from a computer to a network interface deviceUS20040088262Nov 6, 2002May 6, 2004Alacritech, Inc.Enabling an enhanced function of an electronic deviceUS20040100952Oct 3, 2003May 27, 2004Boucher Laurence B.Method and apparatus for dynamic packet batching with a high performance network interfaceUS20040111535Nov 28, 2003Jun 10, 2004Boucher Laurence B.Intelligent network interface system and method for accelerated protocol processingUS20040117509Nov 12, 2003Jun 17, 2004Alacritech, Inc.Protocol processing stack for use with intelligent network interface deviceUS20040158640Apr 30, 2003Aug 12, 2004Philbrick Clive M.Transferring control of a TCP connection between devicesUS20040158793Feb 12, 2003Aug 12, 2004Alacritech, Inc.Network interface device for error detection using partical CRCS of variable length message portionsUS20040240435Jun 29, 2004Dec 2, 2004Alacritech, Inc.Obtaining a destination address so that a network interface device can write network data without headers directly into host memoryUS20050122986Dec 5, 2003Jun 9, 2005Alacritech, Inc.TCP/IP offload device with reduced sequential processingUS20050141561Dec 30, 2004Jun 30, 2005Craft Peter K.Protocol stack that offloads a TCP connection from a host computer to a network interface deviceUS20050160139Jan 4, 2005Jul 21, 2005Boucher Laurence B.Network interface device that can transfer control of a TCP connection to a host CPUUS20050175003Jan 11, 2005Aug 11, 2005Craft Peter K.Protocol stack that offloads a TCP connection from a host computer to a network interface deviceUS20050182841Aug 11, 2003Aug 18, 2005Alacritech, Inc.Generating a hash for a TCP/IP offload deviceUS20050198198Jan 28, 2005Sep 8, 2005Craft Peter K.Protocol stack that offloads a TCP connection from a host computer to a network interface deviceUS20050204058Aug 4, 2003Sep 15, 2005Philbrick Clive M.Method and apparatus for data re-assembly with a high performance network interfaceUS20050278459Jan 20, 2005Dec 15, 2005Boucher Laurence BNetwork interface device that can offload data transfer processing for a TCP connection from a host CPUUS20060010238Aug 30, 2005Jan 12, 2006Alacritech, Inc.Port aggregation for network connections that are offloaded to network interface devicesUS20070062245Aug 29, 2006Mar 22, 2007Daimlerchrysler AgDeforming tool and process for manufactureUS20070253430Dec 20, 2006Nov 1, 2007Minami John SGigabit Ethernet AdapterAU723724B2 Title not availableAU734115B2 Title not availableAU4435999A Title not availableAU4595297A Title not availableAU7364898A Title not availableCA2265692CSep 26, 1997Aug 7, 2001Iready CorporationMultiple network protocol encoder/decoder and data processorCA2287413A1Apr 30, 1998Nov 12, 1998John Shigeto MinamiHardware accelerator for an object-oriented programming languageCA2328829A1Jun 10, 1999Dec 16, 1999Michael Ward JohnsonTcp/ip/ppp modemCN1237295ASep 26, 1997Dec 1, 1999艾瑞迪公司Multiple network protocol encoder/decoder and data processorCN1266512CJun 10, 2004Jul 26, 2006三星电子株式会社F-theta lens and laser scanning unit including the sameCN1305681CNov 18, 1999Mar 21, 2007西尔弗布鲁克研究有限公司Printing system with compact transfer rollerJP2000235536A Title not availableJPH0322159A Title not availableJPH03273350A Title not availableJPH05183603A Title not availableJPH06309251A Title not availableTW447205B Title not availableTW448407B Title not availableWO1998035480A1Feb 11, 1998Aug 13, 1998Xaqti CorporationMedia access control micro-risc stream processor and method for implementing the sameWO2002027519A1Sep 24, 2001Apr 4, 2002Alacritech, Inc.Intelligent network storage interface system and devices* Cited by examinerNon-Patent CitationsReference1"Less-Numerical Algorithms", Ch. 20 p. 888-895.2"Storage Networking Industry Association" iSCSI Building Blocks for IP Storage Networking, www.ipstorage.org.38802-3:2000 ISO/IEC Information Technology, http://www.computer.org/cspress/CATALOG/st01118.htm.4Abbot, Mark B., and Peterson, Larry L., "Increasing Network Throughput by Integrating Protocol Layers" IEEE 1993.5Abbot, Mark B.; Peterson, Larry L., "Increasing Network Trhoguhput by Integrating Protocol Layers" IEEE 1993.6Advisory Action from U.S. Appl. No. 11/614,046, dated Mar. 5, 2010.7Agrawal et al. "Architecture and Design of the Mars Hardware Accelerator", ACM 1987, pp. 101-107.8Ames, Richard, "Building an Embedded Web Server from Scratch" Circuit Cellar INK Feb. 1998.9Banks, David and Prudence, Michael, "A High-Performance Network Architecture for a PA-RISC Workstation" IEEE Journal vol. II, No. 22 Feb. 1993.10Blumrich, Matthias A.; Dubnicku, Cezary; Felton, Edward W.; Li, Kai, "Protected, User-level DMA for the SHRIMP Network Interface" IEEE 1996.11Bonjour, Dominique; de Hauteclocque, Gaelle; le Moal, Jacques, "Design and Application of ATM LAN/WAN Adapters" IEEE 1998.12Camarda, P.; Pipio, F.; Piscitelli, G.; "Performance evaluating of TCP/IP implementations in end systems" IEE Proc-Computer Digital Tech. vol. 146 No. 1 Jan. 1999.13Case, "Implementing the Java Virtual Machine", Microprocessor Report, Mar. 1996.14Chandrammenon, Grish P.; Varghese, George, "Trading Packet Headers for Packet Processing" IEEE 1996.15Chesson, Greg, "Proceedings of the Summer 1987 USENIX Conference" USENIX Association Jun. 8-12, 1987.16Chesson, Greg, "The Protocol Engine Project" Technology Focus Sep. 1987.17Chiswell, Dave "Implementation Challenges for 155Mbit ATM Adapters" ISBN# 0-7803-2636-9.18Clark, David D.; Jacobson, Van; Romkey, John; Salwen, Howard, "An Analysis of TCP Processing Overhead" IEEE Jun. 1989.19Clark, David D.; Romkey, John; Salwen, Howard, "An Analysis of TCP Processing Overhead" IEEE 1988.20Dalton, Chris; Watson, Greg; Banks, David; Calamvokis, Costas; Edwards, Aled; Lumley, John, "Afterburner: A Network-independent card provides architectural support for high-performance protocols" IEEE Jul. 1993.21Dittia, Zubin D.; Parulkar, Guru M.; Jr., Jerome R. Cox, "The APIC Approach to High Performance Network Interface Design: Protect4ed DMA and Other Techniques" IEEE 1997.22Doumenis, Gr. A.; Reisis, D.I.; Stassinopoulos, G.I., "Efficient Implementation of the SAR Sublayer and the ATM Layer in High-Speed Broadband ISDN Data Terminal Adapters" IEEE 1993.23Doumenis, Gr.A., Konstantoulakis, G.E., Reisis, D.I.and Stassinopoulos, G.1. "A Personal Computer Hosted Terminal Adapter for the Broadband Integrated Services Digital Network and Applications" National Technical University of Athens, Greece.24Druschel, Peter; Abbot, Mark B.; Pagels, Michael A.; Peterson, Larry L., "Network Subsystem Design" IEEE Network Jul. 1993.25Eady Product Data Sheet, Internet Tuner.26Eady, Fred, "Embedded Internet Part 2: TCP/IP and a 16-Bit Compiler" Embedded PC Jun. 1999.27Examination Report from European Application No. 02728953, dated Jan. 29, 2009.28Examination Report from European Application No. 03757427, dated Apr. 14, 2010.29Examination Report from European Application No. 03757427, dated Nov. 17, 2008.30Feldmeier, David C.; McAuley, Anthony J.; Smith, Jonathan M., Bakin, Deborah S.; Marcus, William S.; Raleigh, Thomas M., "Protocol Boosters" IEEE 1998.31Final Office Action from U.S. Appl. No. 11/614,046, dated Nov. 6, 2009.32G. Chesson and L. Green, "XTP Protocol Engine VLSI for Real-Time LANS" EFOC/LAN Jun. 29-Jul. 1, 1968.33Goloi, W.K.; Behr, P. "An IPC Protocol and Its Hardware Realization for A High-Speed Distributed Multicomputer System" IEEE 1981.34Goto, H. et al. "Desktop All-in-One, Color Moving-Picture Videophone," The Hitachi Hyoron, 1992, vol. 74, No. 9, pp. 9-15.35Gupta, Pankaj; McKeown, Nick, "Algorithms for Packet Classification" IEEE Network Mar./Apr. 2001.36Huange, Jau-Hsiung; Chen, Chi-Wen, "On Performance Measurments of TCP/IP and its Device Driver" IEEE 1992.37INCITS: Development work conducted in t10-I/O Interface-Lower Level Sep. 30, 2002 Weber, Ralph O.38International Search Report from International Application No. PCT/US02/12889, dated Feb. 20, 2003.39International Search Report from International Application No. PCT/US03/18049, dated Oct. 8, 2003.40iReady Product Data Sheet, Internet Tuner.41Ivanov-Loshkanov, V.S.; Sevast'yanov, S.F., Semenov, M.N., "Network Microprocessor Adapter" Avtmatika i Vyshislitel'naya Tekhnika vol. 17 No. 5 pp. 25-28, 1983.42Johnson et al. , "Internet Tuner", New Media News, http://www.newmedianews.com/020197/ts.sub-inettuner.html, Jan. 1997.43Johnson et al. , "Internet Tuner", New Media News, http://www.newmedianews.com/020197/ts.sub—inettuner.html, Jan. 1997.44Jolitz, William Frederick, "High-Speed Networking: Header prediction and forward-error correction for very high-speed data transfer" Dr. Dobbs Journal, Aug. 1992.45Kanakia, Hermant; Cheriton, David R., "The VMP Network Adapter Board (NAB) High Performance Network Communication for Multiprocessors" ACM 1988.46Kelly, T. "Cheap Internet Hardware that Fits in Everything" ZDNet, www.zdnet.co.uk/news/1998/77/ns-5998.html.47Kelly, T., "Cheap Internet Hardware that Fits in Everything", ZDNet, http://www.zdnet.co.uk/news/1998/44/ns-5998.html, Nov. 1998.48Kim, Chan; Jun, Jong-Jun; Park, Yeong-Ho; Lee, Kyu-Ho; Kim, Hyup-Jong, "Design and Implementation of a High-Speed ATM Host Interface Controller" Electronics and Telecommunications Research Institute, Korea.49Kitadeya et al. "Matsushita Launches WebTV Internet Connection Terminal" www.mei.co.jp/corp/news/official.data.dir/en981112-1/en981112-1html.50Kitadeya et al., "Matsushita Launches Web TV Internet Connection Terminal", http://www.mei.co.jp/corp/news/official.data/data.dir/en981112-1/en981112-1.html, Nov. 1998.51Korablum, Deborah F., "Protocol Implementation and Other Performance Issues for Local and Metropolitan Area Networks" EEE 1988.52Laskman, T.V.; Madhow, U., "Performance Analysis of Window-based Flow Control using TCP/IP:Effect of High Bandwidth Delay Products and Random Loss" High Performance Networking V. 1994 IFIP.53Legg, John, "Choosing and implementing an embedded TCP/IP Stack" Electronic Product Design Jan. 1999.54Luijten, Ronald P., "An OC-12 ATM Switch Adapter Chipset" 1998 IEEE.55Maly, K.; Khanna, K.; Kukkamala, R.; Overstreet C.M.; Yerraballi, R.; Foundriat, E.C.; Madan, B., "Parallel TCP/IP for Multiprocessor Workstations" High Performance Networking, IV, 1993 IFIP.56Mansour, Mohammad; Kayssi, Ayman, "FPGA-Based Internet Protocol Version 6 Router" IEEE 1998.57Marcus, William S.; Hadzic, Ilija; McAuley, Anthony J.; Smith, Jonathan M., "Protocol Boosters: Applying Programmability to Network Infrastructures" IEEE Communications Magazine Oct. 1998.58Meleis, Hanafy E.; Serpanos, Dimitrios, N., "Designing Communication Subsystems for High-Speed Networks" IEEE Network Jul. 1992.59Mitsubishi, Mitsubishi Denki Giho, 1993, vol. 67, No. 7, pp. 44-47 and 96.60Moldeklev, Kjersti; Klovning, Espen; Kure, Oivind, "The effect of end system hardware and software on TCP/IP throughput performance over a local ATM Network".61Mora, F.; Sebastia, A., "Electronic Design of a High Performance Interfacce to the SCI Network" IEEE 1998.62Muller, Raimund, "LON-das universelle Netzwerk" Electronik 22/1991.63Muller, Raimund, "LON—das universelle Netzwerk" Electronik 22/1991.64Muller, Raimund, LON-das universelle Netzwerk Elektronik 22-1991.65Nagata, Takahiko; Hosoda, Yamashita, Hiroyuki, "High-Performance TCP/IP/ATM Communication Board" NTT Information and Communication Systems Laboratories 1998.66Nagata, Takahiko; Hosoda, Yasuhiro; Yamahsita, Hiroyuki, "High-Performance TCP/IP/ATM Communication Boards:Driving Force for Various Multimedia Services" vol. 9 No. 6 Nov. 1997.67Neufeld, Gerald W.; Ito, Mabo Robert; Goldberg, Murray; McCutcheon, Mark J.; Ritchie, Stuart, "Paralleel Host Interface for an ATM Network" IEEE Network Jul. 1993.68New Media News, www. newmedianews.com/02197/ts-inettuner.html.69New Media News, www. newmedianews.com/02197/ts—inettuner.html.70Nielson, Dr. Michael J.K., "TURBOchannel" IEEE 1991.71Non-Final Office Action from U.S. Appl. No. 10/131,118, dated Jun. 29, 2011.72Non-Final Office Action from U.S. Appl. No. 11/614,046, dated Apr. 6, 2009.73Non-Final Office Action from U.S. Appl. No. 11/614,046, dated May 25, 2010.74Notice for Preliminary Rejection from Japanese Application No. 2002-584131, dated Feb. 2, 2007.75Notice of Final Rejection from Japanese Application 2002-584131, dated Jan. 29, 2008.76Notice of Final Rejection from Japanese Application No. 2004-512013, dated May 26, 2009.77Notice of Reasons for Rejection from Japanese Application No. 2004-512013, dated Sep. 9, 2008.78Notice of Reasons for Rejection from Japanese Application No. 2008-139758, dated Apr. 12, 2011.79Orphanos, George; Birbas, Alexios; Petrellis, Nikos; Mountzouris, Ioannis; Malataras, Andreas, "Compensating for Moderate Effective Throughput at the Desktop" IEEE Communication Magazine Apr. 2000.80Preston, David "Internet Protocols Migrate to Silicon for Networking Devices" Electronic Design Apr. 14, 1997.81Preston, David J., "Internet Protocols Migrate to Silicon for Networking Devices" Electronic Design Apr. 14, 1997.82Ramakrishnan, K.K., "Performance Considerations in Designing Network Interfaces" IEEE Journal1993.83Rang, Michael; Tantawy, Ahmed, "A Design Methodology for Protocol Processors" IEEE 1995.84Raz, "Real Time Program Language Accelerator", WO 98/21655, May 1998.85Rutsche, Erich, "The Architecture of a Gb/s Multimedia Protocol Adapter" ACM SIGCOMM Computer Communication Review.86Shivam, Piyush; Wyckoff, Pete; Panda, Dhabaleswar, "EMP: Zero-copy OS-bypass NIC-driven Gigabit Ethernet" SC2001 Nov. 2001, Denver CO, USA.87Siegel, Martin; Williams, Mark; Robler, Georg, "Overcoming Bottlenecks in High-Speed Transport Systems" IEEE 1991.88Smith, Jonathon M.; Traw, C. Brendan S., "Giving Applications Access to Gb/s Networking" IEEE Network Jul. 1993.89Steenkiste, Peter, "A High-Speed Network Interface for Distributed-Memory Systems: Architecture and Applications" ACM Transactions on Computer Systems, vol. 15, No. 1 Feb. 1997.90Steenkiste, Peter, "A Systematic Approach to Host Interface Design for High-Speed Networks" IEEE Mar. 1994.91Steenkiste, Peter, "Design, Implementation, and evaluation of a Single-copy Protocol Stack" Software-Practice and Experience, vol. 28, Jun. 1998.92Steenkiste, Peter, "Design, Implementation, and evaluation of a Single-copy Protocol Stack" Software—Practice and Experience, vol. 28, Jun. 1998.93Stevens, Richard W., "TCP/IP Illustrated Volume" Addison-Wesley Professional Computing Series.94Supplementary European Search Report from European Application No. 02728953, dated Jun. 16, 2008.95Supplementary European Search Report from European Application No. 03757427, dated Aug. 13, 2008.96Toyoshima, Kan; Shirakawa, Kazuhiro; Hayashi, Kazuhiro, "Programmable ATM Adapter: Rapid Prototyping of Cell Processing Equipment for ATM Network" IEEE 1997.97Traw, C. Brendan S.; Smith, Jonathan M., "Hardware/Software Organization of a High-Performance ATM Host Interface" IEEE 1993.98Varada, S.; Yang, Y.; Evans, D., "Data and Buffer Management in ATM Systems" TranSwitch Corporation.99Wayner, "Sun Gambles on Java Chops", Bytes, Nov. 1996.100Wittie, Larry D., Ma, Fanyuan, "A TCP/IP Communication Subsystem in Micros" IEEE 1987.101Womack, Lucas; Mraz, Ronald; Mendelson, Abraham, "A Study of Virtual Memory MTU Reassembly wishing the PowerPC Architecture" IEEE 1997.102Wright, Maury "Intelligent Ethernet Boards" EDN Jun. 23, 1988.103Wright, Maury, "Low-Cost Control LANs Add Automation to Homes, Autos, and Offices" EDN Jul. 20, 1992.104Wright, Maury, Low-Cost Control LANs Add Automation to Homes, Autos, and Offices EDN-Technology Jul. 20, 1992.105Yocum, Kenneth G.; Chase, Jeffrey S.; Gallatin, Andrew J.; Lebeck, Alvin R., Cut-Through Delivery in Trapeze: An Exercise in Low-Latency Messaging IEEE 1997.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8984635 *Jan 6, 2014Mar 17, 2015Cloudflare, Inc.Authenticating the identity of initiators of TCP connectionsUS9357002 *Apr 8, 2013May 31, 2016Google Inc.Mitigation of optimistic acknowledgement attacks in a computer protocol* Cited by examinerClassifications U.S. Classification726/14, 726/13International ClassificationH04L29/06Cooperative ClassificationH04L63/164, H04L69/22, H04L63/123Legal EventsDateCodeEventDescriptionDec 19, 2003ASAssignmentOwner name: IREADY CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GREENFIELD, DANIEL L.;MINAMI, JOHN SHIGETO;UYESHIRO, ROBIN YASU;REEL/FRAME:014838/0580Effective date: 20031219Mar 11, 2004ASAssignmentOwner name: LANZA TECHVENTURE, COLLATERAL AGENT, CALIFORNIAFree format text: SECURITY AGREEEMENT;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:014409/0910Effective date: 20040311Mar 15, 2004ASAssignmentOwner name: LANZA TECHVENTURE AS COLLETERAL AGENT, CALIFORNIAFree format text: SECURITY INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:014428/0212Effective date: 20040311Apr 23, 2004ASAssignmentOwner name: IREADY CORPORATION, CALIFORNIAFree format text: TERMINATION OF SECURITY INTEREST IN PATENTS;ASSIGNOR:LANZA TECHVENTURE, AS COLLATERAL AGENT;REEL/FRAME:014556/0307Effective date: 20040415May 4, 2004ASAssignmentOwner name: NVIDIA CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015320/0112Effective date: 20040421May 20, 2004ASAssignmentOwner name: NVIDIA CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IREADY CORPORATION;REEL/FRAME:015377/0829Effective date: 20040421Oct 27, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services