The TCP protocol, designed for a cooperative purpose, suffers from several vulnerabilities that can be exploited by unscrupulous clients in order to obtain a service better than that of other network clients or to make “denial of service” type attacks.
Among the methods enabling greater allocation of the sending throughput rate of a server, we can single out the known mechanisms of acknowledgement splitting (ACK splitting) and optimistic acknowledgement (optimistic ACK).
In the ACK splitting or acknowledgment splitting mechanism, when the client receives a data segment containing N bytes he replaces the acknowledgement that should correspond to the received segment with a set of M distinct acknowledgments (M≦N), each of the acknowledgements covering a portion of the received data segment.
By way of an illustration, we may cite the U.S. patent application 2006/0182025 (“TCP congestion control using multiple TCP ACKs”) which uses a technique of this kind in a combined wire-based and wireless environment in order to limit the effect of losses on the wireless section resulting in a limitation of the bit rate of the server which considers the losses to be a sign of a congestion of the network. This patent application describes a mobile client with a modified protocol layer enabling the generation of numerous acknowledgements instead of only one, at the detection of a retransmission of the server and within the limits of the reception capacities proper to the client.
This acknowledgement splitting mechanism however can be likened to an attack by the server. To ward off such attacks, mechanisms have been set up by the servers available in the market, which annihilate the effect sought by the solution described in this patent application: the first anti-attack solution (known as byte counting) consists in increasing the congestion window only proportionally to the portion of acknowledged data, the effect of which is to nullify the acknowledgement splitting principle. A second anti-attack solution which is simpler consists in increasing the value of the congestion window by one MSS (maximum segment size) at each valid acknowledgement (in correspondence with the transmitted data segment). This last-mentioned method is implemented for example in recent versions of the Linux core.
The optimistic acknowledgement mechanism (optimistic ACK), relies on the fact that the TCP protocol is based on the principle in which the time between the sending of a data segment and the reception of its acknowledgement corresponds to at least one RTT (round-trip time). Since the increase in the congestion window depends on the RTT (exponentially during the slow-start phase and linearly during the congestion-avoidance phase), the smaller the RTT the faster will be the transfers. Thus, it is possible for a client to simulate a shorter RTT time in sending acknowledgements by anticipation for data that has not yet been received by him (or even not yet been sent by the server). However, if an acknowledgement such as this arrives for a piece of data that has not yet been sent, this acknowledgement is generally ignored by the server.
The danger of this mechanism is that it spoils the principle of end-to-end reliability of the connection between the server and the client. This mechanism too is therefore likened to an attack which can be averted by simple and known precautions: if the TCP server randomly varies the size of the segments sent (in the region of a value equal to [MSS—a few bytes]), a TCP client can no longer anticipate the acknowledgement terminals for data not yet sent and the TCP server can easily reject the optimistic acknowledgements.
The U.S. patent application 2005/0060426 (“Early generation of acknowledgements for flow control”) presents a particular version of the optimistic acknowledgement mechanism (optimistic ACK).
This patent application presents a stream control module (such as a PEP or performance enhanced proxy module) located between the server and the client which anticipates the sending of TCP data segment acknowledgments once these data segments have been received by the stream control module. These segments are temporarily stored until reception of the real acknowledgement from the client, thus enabling retransmission in the event of error.
When the stream control module is used in a VPN gateway, it enables an automatic control link to be set up between the sending throughput rate of the server and the mean throughput of the WAN (wide area network) section and maintains a buffer storage on the gateway (in the event of a need to make retransmission on the WAN section in a manner that is entirely transparent for the server). Furthermore, when the buffer storage memory becomes full, a modification of the TCP window in the acknowledgment message is made in correlation with the available memory (this has the effect of diminishing the throughput rate of the server without lowering its congestion window.
In conclusion, the technique presented in the U.S. patent application 2005/0060426 is not capable of swiftly increasing the bandwidth consumed by TCP streams as described in the problem of the present invention (unexpected and major release of WAN bandwidth assigned to the passenger TCP streams of the tunnel). The prior-art PEP systems with optimistic acknowledgement require corresponding memory resources (because they are set up continuously) and modify the normal behavior of the TCP protocol according to the capacity of the buffer memory available.
In short, in their present modes of implementation, the above-mentioned prior-art mechanisms of acknowledgement splitting (ACK splitting) and optimistic acknowledgement (optimistic ACK) enable a greater allocation of the transmission bit rate of a server but are not low-cost solutions in terms of resources enabling the transmission bit rate of a server to be stimulated transparently for the server and the client (supporting the above-mentioned principles of TCP securization) while at the same time being adapted to the evolutive bandwidth in a network segment and more particularly in a VPN tunnel.
USPTO Backgrounds
USPTO Backgrounds