Abstract:
Blind attacks on a protocol connection, such as a TCP connection, are prevented by inserting checksums computed during protocol connection establishment handshake into data sent through the connection and invalidating data sent through the connection that lacks the protocol setup information checksums. Reset attacks are prevented by invalidating reset requests unless a master checksum computed from the protocol setup information checksums is included with the reset request. Checksums computed from protocol setup information have improved robustness by including a random number with the protocol setup information.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates in general to the field of network communications, and more particularly to a system and method for securing network communications from blind attacks with checksum comparisons. 
     2. Description of the Related Art 
     The Transport Control Protocol (TCP) is a stream delivery service that allows segments of data to be sent between computing nodes over a network with the Internet Protocol (IP). TCP re-assembles segments at a receiving node by requesting re-transmission of lost packets from the sending node and re-arranging out-of-order data. TCP provides accurate delivery of a segment although some delays may occur during performance of re-transmission and ordered re-assembly function. Other types of protocols are available for use instead of TCP. Real-Time Transport Protocol (RTP) is typically used for time-sensitive data delivery, such as voice and video packet streaming. User Datagram Protocol (UDP) is typically used for request response interactions. 
     A host computing node (server) and client computing node establish a TCP connection with a three-way handshake. The client initiates the connection with a SYN sent to the server setting a segment&#39;s sequence number to a random value and including a checksum, hereinafter referred to as {c1}. The server responds with a SYN-ACK that includes an acknowledgement which increments the sequence number, with a random number for the server&#39;s sequence and a checksum, hereinafter referred to as {c2}. The client completes the handshake with an ACK that increments the sequence and acknowledgment numbers and includes a third checksum, hereinafter referred to as {c3}. The checksums of each handshake (i.e., syn, syn-ack and ack) are used verify the validity of the data at the node that receives the associated portion of the handshake. After a TCP connection is established, data is transferred and then the connection is closed. 
     During data transfers of an established TCP connection, hackers using malicious code sometimes attempt “blind” attacks with packet-spoofing techniques that cause data corruption and/or connection resets. Blind attacks rely on an attackers ability to guess or know the “five-tuple” of a TCP instance, i.e., the protocol, source address, source port, destination address and destination port. Of the five-tuple, the host IP address, well-known port and client IP address are generally accurately guessed; however, the ephemeral port of the client, the initial sequence, acknowledgement and timestamp fields of the TCP client are typically more difficult to guess and in addition are generally randomized Randomization of a source port number may be performed with an algorithm, however, source port randomization tends to fragment available ephemeral port range and increase the risk of connection-id collisions that lead to connection failures. Generally, port randomization tends to impact connection performance and makes debugging and sniffing for network investigation more difficult. Simplified port randomization techniques, such as with incremented port-ids, tend to fail in a hostile environment. Randomization of initial sequence, acknowledgement sequence and timestamp information tends to increase connection overhead, resulting in greater complexity and reduced performance. 
     SUMMARY OF THE INVENTION 
     Therefore, a need has arisen for a system and method which offers protection from blind attacks against a protocol connection between networked nodes. 
     In accordance with the present invention, a system and method are provided which substantially reduce the disadvantages and problems associated with previous methods and systems for protecting network protocol connections against blind attacks. Checksums computed from protocol setup information exchanged between network nodes during setup of a protocol connection are inserted in data communicated between the network nodes with the protocol connection in order to validate the data. 
     More specifically, first and second network nodes establish a TCP connection with a protocol connection module at each network node to perform a syn, syn-ack, ack TCP connection establishment handshake. A checksum storage module at each network node stores checksums associated with each of the syn, syn-ack and ack segments of the TCP connection handshake. In one embodiment, the syn, syn-ack and ack segment checksums are made more robust by a random number generator at each network node that includes a random number in the TCP option of the syn, syn-ack and ack segments that are used to compute the checksums. After the TCP connection is established, a data validation module at each network node inserts one of the syn, syn-ack and ack checksums with an identifier into data sent from the node through the TCP connection, such as the TCP option of data packets. The data validation module at a receiving network node invalidates data received that does not include one of the connection setup checksums and associated identifier by comparing any received checksum with checksum stored by the checksum storage module. In one embodiment, a master checksum computed from the setup checksum values is required with any reset received at a network node before the data validation module will allow a reset of the TCP connection. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention may be better, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element. 
         FIG. 1  depicts a block diagram of networks nodes interfaced through a TCP connection protected from blind attacks; 
         FIG. 2  depicts a flow diagram of a process for setting up a TCP connection with stored connection setup checksums; and 
         FIG. 3  depicts a flow diagram of a process for validating data received at a network node through a TCP connection protected from blind attacks. 
     
    
    
     DETAILED DESCRIPTION 
     A system and method provides protection from blind attacks against network protocol connections, such as a TCP connection established between first and second network nodes. Connection setup checksum values are stored at each network node and used in data communications made through the connection to indicate the validity of data transferred through the connection. The connection setup checksum values are made more robust by including random numbers in the connection setup segments that are used to establish the connection. Protection against reset attacks is provided by requiring a master checksum with any reset made at the connection. For example the master checksum is computed by the checksum algorithm applied to the connection setup checksums. 
     As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. 
     A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. 
     Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user&#39;s computer, partly on the user&#39;s computer, as a stand-alone software package, partly on the user&#39;s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user&#39;s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). 
     Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. 
     Referring now to  FIG. 1 , a block diagram depicts networks nodes  10  interfaced through a TCP connection protected from blind attacks. Network nodes are, for instance server computing systems that host information or client computing systems that interface with server computing systems to retrieve information. Each network node includes a processor  12  to process information, memory  14  to store information and a network interface card  16  to communicate with a network  18 , such as the Internet. For example, a first network node  10  acts as a client and includes a browser application executing on processor  12  that retrieves information into memory  14  through network interface card  16  using TCP/IP communications through network  18 . A second network node  10  acts as a host and includes a host application executing on processor  12  to send information from memory  14  through network interface card  16  to clients interfaced with network  18 . 
     Network nodes  10  establish protocol connections between each other with protocol connection modules  20  executing with processing and memory resources of the network node, such as processor  12  or processing resources within network interface card  16 . For example, protocol connection module  20  establishes a TCP connection using a conventional handshake in which a first network node sends a syn segment with a TCP packet header, a second network node sends a syn-ack segment with a TCP packet header in response to the syn segment, and the first network node sends an ack segment with a TCP packet header in response to the syn-ack segment. In order to protect the established TCP connection from blind attacks, each network node  10  also includes a checksum storage module  22 , a data validation module  24  and a random number generation module  26 . Modules  22 ,  24  and  26  are, for example, software or firmware instructions that execute on processing resources and memory of network nodes  10 , such as processor  12 , memory  14  or processing resources of network interface card  16 . 
     Checksum storage module  22  on each network node  10  of a TCP connection retrieves and stores the checksum of each connections setup packet sent during connection setup, such as the checksum c1 included in the syn segment packet, the checksum c2 included in the syn-ack segment packet and the checksum c3 included in the ack segment packet. Each checksum c1, c2 and c3 are computed and included in connection setup packets in order to verify that packets are accurately transmitted. In addition, master checksum cm is computed over (c1, c2, c3) locally at the end-points and stored. By storing the checksums c1, c2, c3 and cm for the duration of the TCP connection, checksum storage module  22  makes the checksums available for use in verifying that data packets sent through the connection are from a valid network node  10 . In addition, each checksum is stored in association with an identifier, such as the stamps 1, 2, and 3 respectively. 
     Random number generation module  26  generates random numbers for inclusion in the connection setup packets so that the checksums computed from the connection setup packets will be more robust and difficult to guess. For example, each of the syn, syn-ack and ack segment packets will have its own random number generated by random number generation module  26  as a 32-bit random number. 
                                               Kind =   Length = 8   Stamp = 0       TBD_IBM_KIND            &lt;32-bit random number to make check sum in SYN, SYN-ACK, ACK       packets more robust&gt;                    
The random number is inserted in the TCP-option portion of each the three connection setup packets in the TCP three-way handshake. Including the random number ensures that a blind attacker cannot trivially compute the checksums of the TCP connection setup packets. The TCP 16 bit checksum computation includes TCP header information, TCP options information and some IP fields plus data as set forth in RFC 793, section 3.1, section “options.”
 
     
       
         
               
               
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 IP header + ext 
                 TCP headers + 
                 TCT DATA segment 
               
               
                   
                 headers 
                 options 
               
               
                   
                   
               
             
          
         
       
     
     Data validation module  24  on each network node  10  applies the checksums c1, c2, and c3 to provide the network nodes a way of validating that data packets received through a TCP connection do not originate from a blind attack. Data validation module  24  on a sending network node includes one the checksums in the packet identifier TCP option of data sent from the network node plus an identifier for the included checksum. For example, a data packet of the TCP connection includes the value c1 in the TCP option header with a stamp identifier indicating which checksum value is included. Data validation module  24  on the receiving network node extracts the checksum and stamp identifier from the TCP option header portion and confirms that the checksum value c1 stored by checksum storage module  22  and identified by the stamp identifier matches the checksum included in the data packet. 
                                                   Kind =   Length = 8   Stamp = 1, 2, 3, 4       TBD_IBM_KIND            &lt;Unused&gt;   &lt;One of 16-bit checksum from           {c1, c2, c3}&gt;                    
If the checksum value extracted from the data packet matches the associated checksum value for the stamp identifier stored at the receiving network node, then the data is valid. If the checksum is not included or does not match, the data is considered invalid, such as might be sent as part of a blind attack.
 
     In addition, data validation module  20  at each network node  10  computes a master checksum by applying the checksum algorithm to the three checksum values c1, c2 and c3. The syn packet checksum is stored with the stamp identifier  1 , the syn-ack packet checksum is stored with the stamp identifier  2 , the ack packet checksum is stored with the stamp identifier  3  and the master checksum cm is stored with the stamp identifier  4 . As set forth above, during data transfer the sender network node  10  includes with the data one of checksum c1, c2 or c3 and its associated identifier stamp so that the receiver network node can match the include checksum by the stamp identifier to the values stored at the network node during the connection setup. By accepting only those data packets that have a matching checksum c1, c2 or c3, the receiving node avoids “corruption” blind attacks that attempt to send invalid data. Thus, blind attackers must guess checksum values stored during connection setup in order to execute corruption attack, a task made difficult by including a random number with the connection setup information used to calculate the checksums. The master checksum value is not sent through the protocol connection unless a reset segment is required. By withholding the master checksum until a reset packet is sent, the network nodes  10  avoid connection reset blind attacks. Blind attackers attempting to send a reset packet will have to guess all three checksums and apply the three connection setup checksums to the appropriate checksum algorithm in order to have a reset packet accepted as valid. 
     Referring now to  FIG. 2 , a flow diagram depicts a process for setting up a TCP connection with stored connection setup checksums. The process begins at step  28  with a connect setup packet sent from a first network node host to a second network node host, such as a syn connection packet with TCP options header value populated by a 32-bit random number and a syn checksum calculated with the header including the random number. At step  30 , the second network host responds to the syn connection packet with a syn-ack connection packet with TCP options header value populated by a 32-bit random number and a syn-ack checksum calculated with the header and the random number. At step  34 , the first network host responds to the syn-ack connection package with an ack connection packet with TCP options header value populated by a 32-bit random number and an ack checksum calculated with the header and the random number. At step  34 , a master checksum is calculated from the syn, syn-ack and ack checksums by applying the connection checksum values to the checksum algorithm. At step  36 , the four checksum values are stored at the network node for use over the duration of the protocol connection. 
     Referring now to  FIG. 3 , a flow diagram depicts a process for validating data received at a network node through a TCP connection protected from blind attacks. The process begins at step  38  by inserting one of the four stored checksums in a packet to be sent over the TCP connection along with the stamp identifier for the inserted checksum. The master checksum is only included to validate a connection reset packet. At step  40 , the packet is sent through the TCP connection to a receiving node. At step  42 , the receiving node extracts the checksum and stamp identifier from the packet. At step  44 , the checksum and identifier from the packet are compared with the checksum and associated identifier stored at the receiving node to determine if a match exists. If the received and stored checksums as associated by the stamp identifier do not match each other, the process continues to step  48  where the packet is discarded and protective measures for a suspected attack may be taken. If at step  46  the received and stored checksums match, the process continues to step  50  where the packet is validated. At step  52 , the checksum is checked if it is a master checksum and, if so, at step  54  the TCP connection is reset. Although the example embodiment details operations with a TCP connection, other types of protocol connections may be supported with appropriate modifications, such as UDP and RTP connections. 
     Although the present invention has been described in detail, it should be understood that various changes, substitutions and alterations can be made hereto without departing from the spirit and scope of the invention as defined by the appended claims.