Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing – Computer-to-computer handshaking
Reexamination Certificate
2001-02-20
2004-11-09
Barot, Bharat (Department: 2155)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
Computer-to-computer handshaking
C709S227000, C709S229000, C709S239000, C709S249000, C370S216000, C370S236000, C370S242000, C370S400000
Reexamination Certificate
active
06816910
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The field relates to limiting network connection resources. More particularly, the field relates to defending against denial of service attacks.
2. Description of Related Art
Two examples of widely used Transmission Control Protocol (TCP)-based protocols are hypertext transfer protocol (HTTP) and file transfer protocol (FTP). These two protocols are becoming more important for the exchange of information over the Internet and are affected by the “SYN flooding” type of denial-of-service attack. A denial-of-service attack on an Internet network by TCP “SYN flooding” hinders the signaling mechanism, called “handshaking,” that is used to establish TCP connections. When such an attack occurs, the affected network resources, such as an Internet server, are degraded in their ability to handle message traffic, resulting in a denial-of-service condition.
A client computer and a server computer can establish a virtual connection using Transmission Control Protocol/Internet Protocol (TCP/IP) via handshaking, such as three-way handshaking.
FIG. 1
shows an example of three-way handshaking
100
. The client sends a SYN packet message. The server sends back to the client a SYN-ACK packet, acknowledging the receipt of the first packet. The client then sends an ACK packet to the server, acknowledging receipt of the server's SYN-ACK packet. When the server receives the ACK packet, the handshaking process is complete and the communication connection is established. Thus, during the TCP/IP handshaking process, the server expects to receive two packets from the client (the SYN packet and the ACK packet) to establish a connection.
The “SYN flood” attack takes advantage of the TCP/IP handshaking process by sending numerous SYN packets with false (“spoofed”) return addresses to a communications port on a server.
FIG. 2
shows an example of a denial of service attack
200
. The server sends out a SYN-ACK message to each return address for each of these SYN packets. The SYN-ACK message is simply lost in the network. The server never receives any ACK messages back because there are no client systems at the spoofed return addresses. The server, therefore, keeps waiting in vain for an ACK message and may keep a queue entry allocated, for example, for several seconds. In sending out the SYN-ACK messages, the server uses up memory resources and queues a half-open connection for each spoofed SYN message. After a predetermined waiting period, the server times out waiting for a SYN message and closes the corresponding half-open connection. On many systems the time out values are on the order of approximately one second, so the server's connection request queue can be depleted relatively slowly. After the server has enough half-open connections to fill up its queue, the server will start to drop subsequent SYN messages, such that legitimate SYN connection requests start to be ignored. On certain systems, the allowable half-open connection queue space may be as little as eight connections.
Thus, SYN flooding attacks reduce (or eliminate) the ability of the targeted server system to respond to legitimate connection requests. An attacker can generally leisurely fill the server's connection request queue before earlier SYN messages reach a time out condition. The SYN flooding denial-of-service attack, if not dealt with properly, requires very little computation and bandwidth commitment from malicious users. Although SYN flooding requires an attacker to continuously flood a target system (otherwise within a few minutes the target will revert to normal operation), it is difficult to trace to the source of the SYN packets. Thus, the SYN flooding technique remains a viable attack.
Potential loss of revenue caused by preempting reliable TCP communications is enormous, and therefore adequate mechanisms for dealing with SYN flooding are needed. Current SYN flooding defense mechanisms seem to have greatly mitigated the problem by making it harder for an attacker to negatively affect service. The most popular approach uses a “brute force” technique. In this approach, the TCP “connection pending” data structure (implementing the connection request queue) is made sufficiently large that an average attacker, to be successful, would need to flood connection requests at a rate exceeding reasonable bandwidth capabilities. This solution, although sometimes very practical, requires large amounts of protected kernel memory and may slow down the server response time for looking up connections in the vast “connection pending” data structure. Other less popular techniques use one-way hash functions (with Internet “cookies”) to verify the authenticity of connection requests and therefore eliminate unnecessary memory allocation. Some of these latter techniques can introduce changes in the TCP signaling behavior and are therefore less favored. Firewall approaches actively monitor the TCP signaling traffic to detect possible attacks and inject ad-hoc signaling messages in the network to mitigate the denial-of-service attack. These approaches are awkward because they introduce additional administrative complexity, may introduce significant delays for legitimate connection establishment, or may expose the system to different, though arguably less severe, kinds of vulnerabilities.
No one mechanism seems to provide an optimal solution, and thus a careful protection approach is usually constructed by using a combination of techniques. What is needed is a solution that can complement or replace existing solutions.
SUMMARY OF THE INVENTION
Various embodiments include methods and apparatuses for limiting connection resources at one or more first network nodes.
One embodiment is a method. At a second network node, a handshake message is detected. A pending network connection is randomly selected. A message to end the randomly selected pending network connection is sent from the second node. Various embodiments can have one or more elements that can begin if a total of pending network connections exceeds a threshold.
Another embodiment is an apparatus. A packet sniffer component detects a handshake message. A random selection component is coupled to the packet sniffer. The random selection component randomly selects a pending network connection. A sending component is coupled to the random selection component. The sending component sends a message to end the randomly selected pending network connection. Various embodiments have one or more elements that can begin if a total of pending network connections exceeds a threshold.
Another apparatus embodiment further comprises one or more servers of the first network node.
REFERENCES:
patent: 5128871 (1992-07-01), Schmitz
patent: 5233604 (1993-08-01), Ahmadi et al.
patent: 5442750 (1995-08-01), Harriman, Jr. et al.
patent: 5970064 (1999-10-01), Clark et al.
patent: 6115745 (2000-09-01), Berstis et al.
patent: 6167025 (2000-12-01), Hsing et al.
patent: 6202084 (2001-03-01), Kumar et al.
patent: 6314093 (2001-11-01), Mann et al.
patent: 6314464 (2001-11-01), Murata et al.
patent: 6347339 (2002-02-01), Morris et al.
Barot Bharat
NetZentry, Inc.
Swernofsky Law Group PC
LandOfFree
Method and apparatus for limiting network connection resources does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for limiting network connection resources, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for limiting network connection resources will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3309162