Transparent bridging of transmission control protocol (TCP) connections

A transparent TCP proxy device intercepts TCP connection requests received from a TCP client and destined for a TCP server as if acting as the TCP server in a handshake with the TCP client. Only after completing the handshake with the TCP client, the transparent TCP proxy participates in a handshake with the TCP server as if acting as the TCP client. After the handshake with the TCP server is complete, the transparent TCP proxy intercepts and translates subsequent TCP packets received from the TCP client and destined for the TCP server into a form expected by the TCP server including updating an acknowledgement number and TCP checksum; and intercepts and translates subsequent TCP packets received from the TCP server and destined for the TCP client into a form expected by the TCP client including updating an acknowledgement number and TCP checksum.

FIELD

Embodiments of the invention relate to the field of networking; and more specifically to transparently bridging Transmission Control Protocol (TCP) connections.

BACKGROUND

TCP, defined for example in RFC 793, is a widely used protocol of the Internet that allows for reliable and ordered delivery of data. For example web browsers commonly use TCP when connecting to origin servers on the Internet. The TCP segment (sometimes referred to as a TCP packet) includes a header that includes a number of fields including source port, destination port, sequence number, acknowledgement number, data offset, reserved, control bits, window, checksum, urgent pointer, options, padding, and a field for the data. The TCP segment is commonly encapsulated into an IP packet whose header includes a number of fields including among others source IP address, destination IP address, and options.

TCP uses sequence numbers to identify the order of data such that the data may be received out of order and reassembled. A client establishes a TCP connection with a server though a series of messages commonly referred to as a handshake. The handshake includes the client transmitting a TCP SYN message to the server which initiates a TCP connection to the server. The server responds with a TCP SYN-ACK message which acknowledges the TCP SYN message and sets an initial sequence number (ISN) to a value chosen by the server. The client responds with a TCP ACK message that acknowledges the TCP SYN-ACK message and includes an acknowledgement number that is the ISN incremented by one. After these three messages, the TCP connection between the client and the server is established. TCP packets also include a TCP checksum which is the ones' complement sum of certain fields in the TCP header.

A fairly common denial of service (DoS) attack is a SYN flood from one or more clients (which may be participating in a botnet) that causes a high rate of incomplete TCP connections. For example, a half-open connection is a connection where the client has sent SYN message, the server has responded with a SYN-ACK message, and the server is waiting for the client to respond with an ACK message. In a SYN flood attack, malicious client(s) typically send many SYN messages to a TCP server with no intention of ever responding to the SYN-ACK message with an ACK message. The server may maintain state for all half-open connections (e.g., waiting for the client to respond with a TCP ACK message to complete the handshake) and the SYN flood may consume all of the available memory for TCP on the server (an overflowing state table), which may lead to the server failing or denying service to legitimate clients, and it may create a high interrupt rate from the network interface card on the attacked server. Thus, these incomplete TCP connections consume resources on web servers both in CPU time and memory space.

One solution to the overflowing state table is to implement SYN cookies. A SYN cookie is a specifically chosen ISN by the server that allows the server to not maintain the state table but also allows the server to recreate the TCP session so the connection can be established and maintained. The SYN cookie may be based on a timestamp (such that the cookie is valid only for a certain period of time), a maximum segment size (MSS) value selected by the server, and a cryptographic hash computed over the server's IP address and port, the client's IP address and port, and the timestamp. For example, the SYN cookie may be a 32 bit value where the top 5 bits are equal to t mod 32, where t is a 32-bit time counter that increases every 64 seconds; the next 3 bits are an encoding of the MSS selected by the server; and the bottom 24 bits is the result of a cryptographic hash computed over the server's IP address and port, the client's IP address and port, and t. When the server receives an ACK from the client (which should be the SYN cookie value incremented by one), the server subtracts one and checks the value t against the current time to see whether the connection has expired, computes the cryptographic hash to determine whether it is a valid SYN cookie, and uses the MSS to reconstruct the SYN queue entry.

The use of TCP SYN cookies addresses the problem of the overflowing state table, but it does not address the problem of the high interrupt rate caused by incomplete TCP connections (e.g., caused by a SYN flood attack). The high interrupt rate causes the CPU load on the attacked machine to be increased which may starve it of CPU time for other legitimate purposes. For example, the CPU on the attacked machine is forced to perform calculations necessary for TCP connection establishment such as TCP checksumming. In a significant denial of service attack, the CPU starvation can be significant.

Some TCP servers (e.g., web servers, proxy servers, etc.) may be configured to accept TCP connections from only known and approved source IP addresses. For example, upon receiving a TCP SYN message from a TCP client, the TCP server may check whether the source IP address of the encapsulating IP packet is of a known and approved source IP address. If the source IP address is not known or approved, then the TCP server will not accept the TCP connection.

The entity controlling the TCP server may not control or manage the IP addresses of TCP clients. Thus, the entity controlling the TCP server may not necessarily know the IP addresses of TCP clients that it should accept connections from or know the IP addresses of TCP clients that it should not accept connections from. In addition, the IP addresses of TCP clients may and often change. In some instances, the entity controlling the TCP server may receive a list of IP addresses that it should accept connections from (a whitelist of IP addresses) and/or a list of IP addresses that it should not accept connections from (a blacklist of IP addresses). These IP addresses would be installed in the server or firewall in front of the server and used to accept or deny connections. The use of such a list is subject to a synchronization problem if the IP addresses of legitimate TCP clients are changed and the list is not updated accordingly. Also the list may be subject to abuse if the list of IP addresses is compromised such that malicious users could use that knowledge to spoof its source IP address such that they look like legitimate TCP clients.

SUMMARY

In one embodiment, a transparent TCP proxy device intercepts TCP connection requests received from a TCP client and destined for a TCP server as if acting as the TCP server in a handshake with the TCP client. Only after completing the handshake with the TCP client, the transparent TCP proxy participates in a handshake with the TCP server as if acting as the TCP client. After the handshake with the TCP server is complete, the transparent TCP proxy intercepts and translates subsequent TCP packets received from the TCP client and destined for the TCP server into a form expected by the TCP server including updating an acknowledgement number and TCP checksum; and intercepts and translates subsequent TCP packets received from the TCP server and destined for the TCP client into a form expected by the TCP client including updating an acknowledgement number and TCP checksum.

In one embodiment, a method in a transparent TCP proxy for transparent bridging of TCP connections includes intercepting a first TCP SYN packet sent from a TCP client and destined for a TCP server that initiates a TCP connection between the TCP client and the TCP server; transmitting a first TCP SYN-ACK packet to the TCP client as if the transparent TCP proxy is the TCP server in response to intercepting the first TCP SYN packet, where the first TCP SYN-ACK packet includes a first sequence number that is chosen by the transparent TCP proxy, where the first sequence number is a first initial sequence number (ISN); intercepting a first TCP ACK packet sent from the TCP client and destined for the TCP server in response to transmitting the first TCP SYN-ACK packet, where the first TCP ACK packet acknowledges receipt of the TCP client of the first TCP SYN-ACK packet; transmitting, in response to intercepting the first TCP ACK packet, a second TCP SYN packet to the TCP server as if the transparent TCP proxy is the TCP client, where the second TCP SYN packet is substantially the same as the first TCP SYN packet; intercepting a second TCP SYN-ACK packet sent from the TCP server and destined for the TCP client in response to transmitting the second TCP SYN packet to the TCP server, where the second TCP SYN-ACK packet includes a second sequence number that is chosen by the TCP server, where the second sequence number is a second ISN; transmitting a second TCP ACK packet to the TCP server as if the transparent TCP proxy is the TCP client in response to intercepting the second TCP SYN-ACK packet; calculating and storing a difference between the first ISN included in the first TCP SYN-ACK packet and the second ISN included in the second TCP SYN-ACK packet; intercepting a first data packet sent from the TCP client and destined for the TCP server, where the first data packet includes a first acknowledgement number based on the first sequence number, and where the first data packet includes a first TCP checksum; updating the first acknowledgement number to a second acknowledgement number using the difference between the first ISN and the second ISN so that the updated acknowledgement number is a value that is expected by the TCP server; calculating a second TCP checksum that uses the second acknowledgement number instead of the first acknowledgement number; transmitting a second data packet to the TCP server as if the transparent TCP proxy is the TCP client, where the second data packet includes the second acknowledgement number and the second TCP checksum; intercepting a third data packet sent from the TCP server and destined for the TCP client, where the third data packet includes a third TCP checksum and a third sequence number; updating the third sequence number to a fourth sequence number using the difference between the first sequence number and the second sequence number so that the fourth sequence number is a value that is expected by the TCP client; calculating a fourth TCP checksum that uses the fourth sequence number instead of the third sequence number; transmitting a fourth data packet to the TCP client as if the transparent TCP proxy is the TCP server, where the fourth data packet includes the fourth TCP checksum and the fourth sequence number; calculating and storing a difference between the first TCP checksum and the second TCP checksum; intercepting a fifth data packet transmitted from the TCP client and destined for the TCP server, where the fifth data packet includes a third acknowledgement number and a fifth TCP checksum; updating the third acknowledgement number to a fourth acknowledgement number using the difference between the first sequence number and the second sequence number so that the fourth acknowledgement number is a value that is expected by the TCP server; updating the fifth TCP checksum to a sixth TCP checksum using the difference between the first TCP checksum and the second TCP checksum; transmitting a sixth data packet to the TCP server as if the transparent TCP proxy is the TCP client, where the sixth data packet includes the fourth acknowledgement number and the sixth TCP checksum; calculating and storing a difference between the third TCP checksum and the fourth TCP checksum; intercepting a seventh data packet transmitted from the TCP server and destined for the TCP client, where the seventh data packet includes a seventh TCP checksum and a fifth sequence number; updating the fifth sequence number to a sixth sequence number using the difference between the first sequence number and the second sequence number so that the sixth sequence number is a value that is expected by the TCP client; updating the seventh TCP checksum to an eighth TCP checksum using the difference between the third TCP checksum and the fourth TCP checksum; and transmitting an eighth data packet to the TCP client as if the transparent TCP proxy is the TCP server, where the eighth data packet includes the eighth TCP checksum and the sixth sequence number.

In one embodiment, a TCP receiver receives a SYN segment from a TCP initiator that initiates a TCP handshake between the TCP initiator and a TCP server. A first value is extracted from a predefined portion of the SYN segment. A second value is computed using an authentication algorithm that includes at least using a cryptographic hash function that takes as input at least the source IP address of the encapsulating IP packet of the SYN segment and a shared secret between the TCP initiator and the TCP receiver. If the computed second value matches the extracted first value, then the TCP handshake is allowed to continue. If the computed second value does not match the extracted first value, then the TCP handshake is not allowed to continue.

DESCRIPTION OF EMBODIMENTS

Transparent Bridging of TCP Connections

A method and apparatus for transparent bridging of TCP connections is described. In one embodiment, a transparent TCP proxy sits between a TCP client and a TCP server that intercepts TCP packets and only passes fully established TCP connections to the TCP server. The transparent TCP proxy intercepts the initial SYN packet from the TCP client that initiates the TCP connection between the TCP client and the TCP server. The transparent TCP proxy replies to the SYN packet as if it was the TCP server with a SYN-ACK packet (e.g., the source IP address is an address of the TCP server). The SYN-ACK packet includes an initial sequence number (ISN) selected by the transparent TCP proxy. The selected ISN may be a SYN cookie. Only after intercepting an ACK packet from the TCP client that completes the handshake between the TCP client and the transparent TCP proxy, the transparent TCP proxy transmits a SYN packet to the TCP server that appears to be from the TCP client to initiate the TCP handshake between the transparent TCP proxy and the TCP server. The transparent TCP proxy and the TCP server complete the TCP handshake which includes the transparent TCP proxy intercepting a SYN-ACK packet with an ISN selected by the TCP server. The ISN selected by the transparent TCP proxy will most likely be different than the ISN selected by the TCP server. After the two handshakes are complete and both ends of the TCP connection are established, the transparent TCP proxy bridges the connections by intercepting and translating each additional TCP packet between the TCP client and the TCP server.

The transparent TCP proxy does not implement a TCP state machine in some embodiments. Thus, the transparent TCP proxy does not terminate the TCP connections. Instead, the transparent TCP proxy passes packets between the TCP client and the TCP server and updates the sequence number or acknowledgement number as appropriate and also updates the TCP checksum as appropriate.

TCP packets sent from the TCP client and destined for the TCP server that are intercepted by the transparent TCP proxy will include an acknowledgement number that is determined in part on the ISN selected by the transparent TCP proxy. The acknowledgement number is the value of the next sequence number the sender of the TCP packet is expected to receive. Since the ISN selected by the transparent TCP proxy is likely different than the ISN selected by the TCP server, the transparent TCP proxy updates the acknowledgement number in TCP packets it intercepts from the TCP client that are destined for the TCP server with an acknowledgement number that is determined in part on the ISN selected by the TCP server. For example, the transparent TCP proxy updates the acknowledgement number based on the difference between the ISN selected by the transparent TCP proxy and the ISN selected by the TCP server. The transparent TCP proxy does not need to modify the sequence number in ACKs intercepted from the TCP client and destined for the TCP server because these sequence numbers are not dependent on the ISN selected by the transparent TCP proxy.

TCP packets sent from the TCP server that are destined for the TCP client will include a sequence number that is determined in part on the ISN selected by the TCP server. Since the TCP client expects TCP packets with sequence numbers based on the ISN selected by the transparent TCP proxy, the transparent TCP proxy updates the sequence number in TCP packets it intercepts from the TCP server that are destined for the TCP client with a sequence number that is determined in part on the ISN selected by the transparent TCP proxy. For example, the transparent TCP proxy updates the sequence number based on the difference between the ISN selected by the transparent TCP proxy and the ISN selected by the TCP server. The transparent TCP proxy does not need to modify the acknowledgment number in ACKs intercepted from the TCP server and destined for the TCP client because these acknowledgement numbers are not dependent on the ISN selected by the TCP server.

TCP packets include a TCP checksum which is the ones' complement sum of certain fields in the TCP header. Modifying the acknowledgement number or the sequence number of the TCP header will change the TCP checksum. Ones' complement addition forms an Abelian Group and is thus associative and commutative. As a result, in one embodiment, the transparent TCP proxy recomputes the TCP checksum after changing the sequence number or acknowledgement number and computes the difference between the initial TCP checksum and the updated TCP checksum. The checksum difference is calculated for each side of the TCP connection (i.e., a TCP checksum difference is calculated between the TCP client and the transparent TCP proxy and a TCP checksum difference is calculated between the TCP server and the transparent TCP proxy). The TCP checksum difference can then be used to update the TCP checksum without requiring the checksum to be fully recalculated on each intercepted TCP packet.

FIG. 1illustrates an exemplary system for transparently bridging TCP connections according to one embodiment. The system illustrated inFIG. 1includes the TCP client110, the transparent TCP proxy120, and the TCP server130. The transparent TCP proxy120is situated between the TCP client110and the TCP server130and intercepts at least certain TCP packets as will be described. The TCP client110may be any client network application that is initiating a TCP connection with the TCP server. For example, the client network application may be an Internet browser executing on a client device or other any other application that implements TCP. The TCP server130may be a web server and may or may not be an origin server that maintains web pages. In a specific embodiment, the TCP server130may be a proxy server for one or more origin servers.

The transparent TCP proxy120intercepts TCP packets sent by the TCP client110destined for the TCP server130and intercepts TCP packets sent by the TCP server130destined for the TCP client110. AlthoughFIG. 1illustrates a single TCP server130being connected to the transparent TCP proxy120, in some embodiments the transparent TCP proxy120intercepts TCP packets between multiple TCP clients and multiple TCP servers.

The transparent TCP proxy120intercepts and replies to TCP connection attempts to the TCP server130(e.g., a SYN packet sent from the TCP client110) without passing those connection attempts to the TCP server130until the TCP connection is fully established. The transparent TCP proxy120will only establish a TCP connection with the TCP server130on behalf of the TCP client110only after the TCP client110has established a TCP connection with the transparent TCP proxy120. To say it another way, if the TCP client110does not complete the handshake with the transparent TCP proxy120(e.g., it does not transmit an ACK packet in response to the SYN-ACK packet transmitted by the transparent TCP proxy120), then the transparent TCP proxy120will not establish a TCP connection on behalf of the TCP client110with the TCP server130. Since connection attempts are not passed to the TCP server130until after the TCP client110has fully established a TCP connection with the transparent TCP proxy120, the transparent TCP proxy120protects the TCP server130against an attack consisting of incomplete TCP connections (e.g., a SYN flood attack), which reduces the high interrupt rate of the TCP server130that may otherwise have been experienced during such an attack.

The transparent TCP proxy120includes the TCP bridging module140that bridges an established TCP connection with the TCP client110and an established TCP connection with the TCP server130. At an operation1, the TCP bridging module140of the transparent TCP proxy120intercepts a SYN packet160transmitted from the TCP client110that is destined for the TCP server130at an interface coupling the TCP client110and the transparent TCP proxy120. The SYN packet160is transmitted by the TCP client110to request a TCP connection to the TCP server130.

After intercepting the SYN packet160, the TCP bridging module140responds to the request by transmitting a SYN-ACK packet162to the TCP client110in operation2that appears to be from the TCP server130(it includes as its source IP address the IP address of the TCP server130which was the destination IP address in the SYN packet of operation1). To say it another way, the TCP bridging module140transmits the SYN-ACK packet162to the TCP client110as if it is the TCP server130. Thus it appears to the TCP client110as if the TCP server130transmitted the SYN-ACK packet162. The SYN-ACK packet162includes an ISN selected by the TCP bridging module140.

For each bridged TCP connection, the transparent TCP proxy120stores a set of TCP connection parameters150In an embodiment where the TCP bridging module140selects the ISN to be a SYN cookie, the TCP bridging module140stores information154about the SYN cookie for verifying the cookie in the TCP connection parameters150. For example, the SYN cookie information may indicate the cryptographic hash function used when generating the SYN cookie. The SYN cookie be a 32 bit value where the top 5 bits are equal to t mod 32, where t is a 32-bit time counter that increases every 64 seconds; the next 3 bits are an encoding of the MSS selected by the transparent TCP proxy120; and the final 24 bits is the result of a cryptographic hash over the IP address and port of the TCP server130, the IP address and port of the TCP client110, and a current timestamp. Alternatively, the SYN cookie may be a 32 bit value where the top 5 bits are equal to t mod 32, where t is a 32-bit time counter that increases every 64 seconds; the next 3 bits are an encoding of the MSS selected by the transparent TCP proxy120; and the final 24 bits is the result of a cryptographic hash over the IP address and port of the transparent TCP proxy120, the IP address and port of the TCP client110, and a current timestamp.

At operation3, the TCP bridging module140intercepts an ACK packet164transmitted from the TCP client110and destined for the TCP server130in response to the SYN-ACK packet162. The ACK packet164includes an acknowledgement number that is determined in part on the ISN selected by the TCP bridging module140and included in the SYN-ACK packet162. For example, according to the TCP protocol, the acknowledgement number in the ACK packet164will be the ISN included in the SYN-ACK packet162incremented by one. Assuming that the ACK packet164is valid, the handshake will be complete between the TCP client110and the transparent TCP proxy120. At this point the TCP client110assumes that it has established a TCP connection with the TCP server130.

In one embodiment, if a SYN cookie was used as the ISN transmitted to the TCP client110in the SYN-ACK packet162, the TCP bridging module140decrements the acknowledgement number by one and verifies that the SYN cookie is valid. For example, the TCP bridging module14performs the same cryptographic hash using a current timestamp t to determine whether the values match. If the values match, the SYN cookie is valid. If the values do not match, then the SYN cookie is not valid and the TCP bridging module140will not process the TCP connection request further.

If the TCP client110was participating in a SYN flood attack or other attack that relied on incomplete TCP connections, it would normally not respond to the SYN-ACK packet162by transmitting the ACK packet164. If the TCP client110did not respond to the SYN-ACK packet162with a valid ACK packet, then the transparent TCP proxy120will not transmit any SYN packets to the TCP server130on behalf of the TCP client110for the TCP connection.

However, as illustrated inFIG. 1, because the TCP client110transmitted the ACK packet164, and assuming that the ACK packet164is valid, the TCP bridging module140will initiate a TCP connection with the TCP server130on behalf of the TCP client110. Thus, since the transparent TCP proxy120intercepts connection attempts (SYN packets) and does not transmit them to the TCP server130until a TCP client has fully established a TCP connection with the transparent TCP proxy120(which is an indication that it is a legitimate request and not part of a SYN flood attack), the transparent TCP proxy120protects the TCP server130against an attack that includes incomplete TCP connections, which reduces the high interrupt rate of the TCP server130may otherwise have been experienced during such an attack (e.g., the TCP server130may avoid performing unnecessary computation such as TCP checksumming).

At operation4, the TCP bridging module140transmits a SYN packet166to the TCP server130to request a TCP connection on behalf of the TCP client110. The SYN packet166includes as its source IP address the source IP address of the TCP client110. Thus the TCP bridging module140transmits the SYN packet166to the TCP server130as if it is the TCP client110. The SYN packet160and the SYN packet166are identical or substantially identical.

At operation5, the TCP bridging module140intercepts a SYN-ACK packet168sent from the TCP server130and destined for the TCP client110at an interface coupling the transparent TCP proxy120and the TCP server130. In one embodiment, the TCP bridging module140does not transmit the SYN-ACK packet168to the TCP client110(in other words, intercepting the SYN-ACK packet168prevents that packet from being received at the TCP client110).

The intercepted SYN-ACK packet168includes an ISN selected by the TCP server130. It is likely that the ISN selected by the TCP bridging module140and transmitted in the SYN-ACK packet162will be different than the ISN selected by the TCP server130and transmitted in the SYN-ACK packet168. Because subsequent acknowledgement numbers or sequence numbers (depending on the direction of the TCP connection) depend in part on the ISN, the transparent TCP proxy translates the numbers as appropriate which will be described in greater detail later herein. In order to translate the acknowledgement or sequence numbers, the TCP bridging module140stores the difference between the ISN selected by the TCP bridging module140and included in the SYN-ACK packet162and the ISN selected by the TCP server130and included in the SYN-ACK packet168(the ISN difference152stored in the TCP connection parameters150). The TCP bridging module140may compute the difference between the ISNs after receiving the SYN-ACK packet168.

After intercepting the SYN-ACK packet168, at operation6the TCP bridging module140transmits an ACK packet170to the TCP server130. The ACK packet170includes as its source IP address the source IP address of the TCP client110. Thus the TCP bridging module140transmits the ACK packet170to the TCP server130as if it is the TCP client110. The ACK packet170includes an acknowledgement number that is determined in part on the ISN selected by the TCP server130and included in the SYN-ACK packet168. For example, according to the TCP protocol, the acknowledgement number in the ACK packet170will be one more than the ISN included in the SYN-ACK packet168.

After transmitting the ACK packet170to the TCP server130, a TCP connection is considered to be established between the TCP bridging module140and the TCP server130. Thus a first TCP connection is established between the TCP client110and the TCP bridging module140and a second TCP connection is established between the TCP bridging module140and the TCP server130. After the handshakes are complete, the data transfer portion of the TCP connection commences.

The TCP bridging module140intercepts the data packet172transmitted from the TCP client110and destined for the TCP server130at operation7. The data packet172may include a request for a web page, for example. The data packet172is referred to as a data packet because it is sent over the established TCP connection, however it also includes the ACK control bit set and includes an acknowledgment number (each segment sent after the connection is established includes a set ACK control bit). The data packet172includes an acknowledgement number that is derived in part on the ISN selected by the TCP bridging module140and included in the SYN-ACK packet162.

At operation8, the TCP bridging module translates the data packet172into a form that is expected by the TCP server130. For example, since the value of the acknowledgement number included in the data packet172will not be a value expected by the TCP server130(since it is based in part on the ISN selected by the TCP bridging module140and not based in part on the ISN selected by the TCP server130), the TCP bridging module140updates the acknowledgement number based on the difference between the ISNs (the ISN difference152) in operation8.1. For example, if the ISN selected by the TCP bridging module140is 100 and the ISN selected by the TCP server130is 500, then the TCP bridging module140will add400to the acknowledgement number included in the data packet172.

Changing the acknowledgement number will also affect the TCP checksum, which is included in the data packet172(TCP checksums are typically included in each TCP packet). At operation8.2, the TCP bridging module140recomputes the TCP checksum with the updated acknowledgement number instead of the original acknowledgement number included in the data packet172. The TCP checksum may be recomputed according to the TCP protocol (e.g., according to RFC 793). At operation8.3, the TCP bridging module140determines and stores the difference between the TCP checksum included in the data packet172and the updated TCP checksum. This difference is referred herein as the client TCP checksum difference156(stored as part of the TCP connection parameters150). It should be understood that operation8.3may be performed prior, during, or after operation9, discussed below.

After translating the data packet172, at operation9, the TCP bridging module140transmits a translated data packet174to the TCP server130. The translated data packet174includes as its source IP address the source IP address of the TCP client110, includes the updated acknowledgement number, and includes the updated TCP checksum. Other than the updated acknowledgement number and the updated TCP checksum, the translated data packet174is substantially the same as the data packet172. Therefore, from the perspective of the TCP server130, the translated data packet174appears to be a packet sent from the TCP client110.

At operation10, the TCP bridging module140intercepts a data packet176transmitted from the TCP server130and destined for the TCP client110(e.g., sent in response to the translated data packet174). The data packet176includes a sequence number that is based at least in part on the ISN selected by the TCP server130.

At operation11, the TCP bridging module translates the data packet176into a form that is expected by the TCP client110. Since the value of the sequence number in the data packet176will not be a value expected by the TCP client110(since it is based in part on the ISN selected by the TCP server130and not based on the ISN selected by the TCP bridging module140), the TCP bridging module140updates the sequence number of the data packet176based on the difference between the ISNs (the ISN difference152) in operation11.1. For example, if the ISN selected by the TCP bridging module140is 100 and the ISN selected by the TCP server130is 500, then the TCP bridging module140will subtract 400 from the sequence number included in the data packet176.

Changing the sequence number will also affect the TCP checksum, which is included in the data packet176. At operation11.2, the TCP bridging module140recomputes the TCP checksum with the updated sequence number instead of the original sequence number included in the data packet176. The TCP checksum may be recomputed according to the TCP protocol (e.g., according to RFC 793). At operation11.3, the TCP bridging module140determines and stores the difference between the TCP checksum included in the data packet176and the updated TCP checksum. This difference is referred herein as the server TCP checksum difference158(stored as part of the TCP connection parameters150). The client TCP checksum difference and the server TCP checksum difference may be different. It should be understood that operation11.3may be performed prior, during, or after operation12, discussed below.

At operation12, the TCP bridging module140transmits a translated data packet178to the TCP client110. The translated data packet178includes as its source IP address the source IP address of the TCP server130, includes the updated sequence number, and includes the updated TCP checksum. Other than the updated sequence number and the updated TCP checksum, the translated data packet178is substantially the same as the data packet176. Therefore, from the perspective of the TCP client110, the translated data packet178appears to be a packet sent from the TCP server130.

At operation13, the TCP bridging module140intercepts a data packet180transmitted from the TCP client110and destined for the TCP server130. The data packet180is part of the same TCP connection. The data packet180includes an acknowledgement number that is derived in part on the ISN selected by the TCP bridging module140and included in the SYN-data packet162.

At operation14, the TCP bridging module140translates the data packet180into a form that is expected by the TCP server130. The TCP bridging module140updates the acknowledgement number based on the difference between the ISNs (the ISN difference152) in operation14.1. Since changing the acknowledgement number will also affect the TCP checksum, at operation14.2the TCP bridging module140updates the TCP checksum using the client TCP checksum difference156(e.g., a single 16 bit addition of the client TCP checksum difference156with the checksum value in the data packet180). Although in some embodiments the TCP bridging module140may recompute the TCP checksum, since the TCP checksum is the ones' complement sum of certain fields in the header that forms an Abelian Group over the 16 bit numbers in the header, it is both associative and commutative and therefore a single 16 bit addition may be used to update the TCP checksum after once calculating the TCP checksum difference. A single 16 bit addition is faster and less processor intensive than recomputing the TCP checksum.

After translating the data packet, at operation15the TCP bridging module140transmits the translated data packet182to the TCP server130. The translated data packet182includes as its source IP address the source IP address of the TCP client110, includes the updated acknowledgement number, and includes the updated TCP checksum. Other than the updated acknowledgement number and the updated TCP checksum, the translated data packet182is substantially the same as the data packet180.

At operation16, the TCP bridging module140intercepts a data packet184transmitted from the TCP server130and destined for the TCP client110(e.g., sent in response to the translated data packet182). The data packet184includes a sequence number that is based at least in part on the ISN selected by the TCP server130.

At operation17, the TCP bridging module140translates the data packet184into a form that is expected by the TCP client110. The TCP bridging module140updates the sequence number of the data packet184based on the difference between the ISNs (the ISN difference152) in operation17.1. Since changing the sequence number will also affect the TCP checksum, at operation17.2the TCP bridging module140updates the TCP checksum using the server TCP checksum difference158(e.g., a single 16 bit addition of the client TCP checksum difference158with the checksum value in the data packet184).

After translating the data packet, at operation18the TCP bridging module140transmits the translated data packet186to the TCP client110. The translated data packet186includes as its source IP address the source IP address of the TCP server130, includes the updated sequence number, and includes the updated TCP checksum. Other than the updated sequence number and the updated TCP checksum, the translated data packet186is substantially the same as the data packet184.

The TCP bridging module140will intercept subsequent TCP packets sent between the TCP client110and the TCP server130and translate them as appropriate by updating the acknowledgement number or sequence number (depending on the direction of the packet) and updating the TCP checksum. The types of TCP packets that may need translating include TCP FIN packets and other TCP packets where the ACK control bit is set. In this manner, the TCP bridging module140transparently bridges TCP packets between the TCP client110and the TCP server130.

The transparent TCP proxy120may also implement other rules such as IP address based access control lists to drop packets that are known to be undesirable and/or examine other parts of the IP header or TCP header to detect potentially malicious behavior (e.g., examining for a reduction in the TCP window size which may be indicative of a slow-read attack, filtering based on TCP port, etc.).

FIGS. 2A-2Bare flow diagrams that illustrates exemplary operations for transparently bridging TCP connections according to one embodiment. The operations ofFIGS. 2A-2Bwill be described with respect to the exemplary embodiment ofFIG. 1. However, it should be understood that the operations ofFIG. 2A-2Bcan be performed by embodiments other than those discussed with reference toFIG. 1, and the embodiments discussed with reference toFIG. 1can perform operations different than those discussed with reference toFIG. 2A-2B.

At operation210, the transparent TCP proxy120intercepts a first TCP SYN packet sent from the TCP client110and destined for the TCP server130. This SYN packet is transmitted by the TCP client110to initiate a TCP connection to the TCP server130. The transparent TCP proxy120intercepts the SYN packet which prevents it from being received from the TCP server130(as described in greater detail later herein, the transparent TCP proxy120will transmit a substantially similar SYN packet to the TCP server130on behalf of the TCP client110only if the TCP client110completes the TCP handshake with the transparent TCP proxy120). Flow moves from operation210to operation212.

At operation212, the transparent TCP proxy120transmits a first TCP SYN-ACK packet to the TCP client110as if the transparent TCP proxy is the TCP server130in response to intercepting the first TCP SYN packet. For example, the first TCP SYN-ACK packet includes as its source IP address the source IP address of the TCP server130(which is the destination IP address of the first TCP SYN packet). The first TCP SYN-ACK packet includes as its sequence number a value chosen by the transparent TCP proxy, which is referred to in the description ofFIG. 2as the first ISN. In one embodiment, the first ISN is a SYN cookie. The use of a SYN cookie allows the transparent TCP proxy120to not maintain a state table for this attempted TCP connection. The first TCP SYN-ACK packet also includes the other required information of a SYN-ACK packet as defined by the TCP protocol. Flow moves from operation212to operation214.

At operation214, the transparent TCP proxy120intercepts a first TCP ACK packet that is transmitted from the TCP client110that is destined for the TCP server130. The first TCP ACK packet acknowledges receipt of the first TCP SYN-ACK packet. The first TCP ACK packet includes an acknowledgement number that is based on the ISN included in the first TCP SYN-ACK packet (e.g., the acknowledgement number is one more than the ISN included in the first TCP SYN-ACK packet). If the transparent TCP proxy120transmitted a SYN cookie as the ISN, then the transparent TCP proxy120verifies the validity of the SYN cookie (after it decrements the acknowledgement number) before continuing. It should be noted that if the TCP client110does not transmit the TCP ACK packet or in embodiments where a SYN cookie is used the TCP ACK packet does not include a valid acknowledgement number based on the SYN cookie, the transparent TCP proxy120does not complete the handshake and no SYN packets for the TCP connection will be transmitted to the TCP server130, which protects the TCP server130against an attack that uses incomplete TCP connections (e.g., a SYN flood attack) thereby reducing the high interrupt rate of the TCP server130that may otherwise have been experienced during such an attack. Flow moves from operation214to operation216.

At operation216, the transparent TCP proxy120transmits, in response to intercepting the first TCP ACK packet, a second TCP SYN packet to the TCP server130as if the transparent TCP proxy120is the TCP client110. For example, the second TCP SYN packet includes as its source IP address the source IP address of the TCP client110. The second TCP SYN packet is substantially the same as the first TCP SYN packet. Flow then moves to operation218.

At operation218, the transparent TCP proxy120intercepts a second TCP SYN-ACK packet transmitted from the TCP server130that is destined for the TCP client110. The second TCP SYN-ACK packet includes an ISN that is chosen by the TCP server130. The ISN chosen by the TCP server130may be a SYN cookie. The ISN chosen by the TCP server130included in the second TCP SYN-ACK packet is likely different than the ISN chosen by the transparent TCP proxy120and included in the first TCP SYN-ACK packet. Flow moves from operation218to operation220.

At operation220, the transparent TCP proxy120transmits a second TCP ACK packet to the TCP server130as if the transparent TCP proxy120is the TCP client110. For example, the second TCP ACK packet includes as its source IP address the source IP address of the TCP client110. The second TCP ACK packet includes an acknowledgement number that is based on the ISN included in the second TCP SYN-ACK packet (e.g., the acknowledgement number is one more than the ISN included in the second TCP SYN-ACK packet). Flow then moves to operation222.

At operation222, the transparent TCP proxy120calculates and stores a difference between the ISN selected by the transparent TCP proxy120and included in the first TCP SYN-ACK packet and the ISN selected by the TCP server130and included in the second TCP SYN-ACK packet. The difference between these ISNs is used to translate the sequence number or acknowledgement number in subsequent TCP packets. Flow then moves to operation224, which begins the data transfer portion of the TCP connection.

At operation224, the transparent TCP proxy120intercepts a first data packet transmitted from the TCP client110and destined for the TCP server130. The data packet includes an acknowledgement number that is based on the ISN included in the first TCP SYN-ACK packet (e.g., it may be one more than the ISN included in the first TCP SYN-ACK packet). Like other TCP packets, the first data packet also includes a TCP checksum. Flow moves from operation224to operation226.

Since the acknowledgement number included in the first data packet is based on the ISN included in the first TCP SYN-ACK packet which is chosen by the transparent TCP proxy120, the transparent TCP proxy120updates that acknowledgement number to a value that is expected by the TCP server130(e.g., based on the ISN included in the second TCP SYN-ACK packet). Therefore, at operation226, the transparent TCP proxy120updates the acknowledgement number to a value using the difference between the ISN selected by the transparent TCP proxy120and included in the first TCP SYN-ACK packet and the ISN selected by the TCP server130and included in the second TCP SYN-ACK packet such that the updated acknowledgement number is a value expected by the TCP server130. By way of example, if the ISN included in the first TCP SYN-ACK packet is 1000 and the ISN included in the second TCP SYN-ACK packet is 500, the transparent TCP proxy120will subtract 500 from the acknowledgement number included in the first data packet. Flow then moves to operation228.

Changing the acknowledgement number affects the TCP checksum of the TCP packet. Therefore, at operation228, the transparent TCP proxy120calculates an updated TCP checksum that takes into account the updated acknowledgement number. The calculation of the TCP checksum may be according to the TCP protocol (e.g., the TCP checksum is the 16 bit ones' complement of the ones' complement sum of all 16 bit words in the header and text).

Flow then moves to operation230where the transparent TCP proxy120calculates and stores the difference between the TCP checksum included in the first data packet and the updated TCP checksum (the client TCP checksum difference). The client TCP checksum difference is a 16 bit value. The client TCP checksum difference may be used when updating the TCP checksum of subsequent TCP packets the transparent TCP proxy120intercepts from the TCP client110that are destined for the TCP server130during the TCP connection. Flow moves from operation230to operation232.

At operation232, the transparent TCP proxy120transmits a second data packet to the TCP server130as if the transparent TCP proxy120is the TCP client110(e.g., the source IP address of the second data packet is the source IP address of the TCP client110). The second data packet includes the updated acknowledgement number and the updated TCP checksum. Besides the updated acknowledgement number and the updated TCP checksum, the second data is substantially similar as the first data packet. Flow then moves to operation234.

At operation234, the transparent TCP proxy120intercepts a third data packet transmitted from the TCP server130and destined for the TCP client110. The third data packet is transmitted in response to the second data packet and includes a TCP checksum and a sequence number that is based in part on the ISN selected by the TCP server130. Flow then moves to operation236.

At operation236, the transparent TCP proxy120updates the sequence number to a value using the difference between the ISN selected by the transparent TCP proxy120and included in the first TCP SYN-ACK packet and the ISN selected by the TCP server130and included in the second TCP SYN-ACK packet such that the updated sequence number is a value expected by the TCP client110. By way of example, if the ISN included in the first TCP SYN-ACK packet is 1000 and the ISN included in the second TCP SYN-ACK packet is 500, the transparent TCP proxy120will add500to the sequence number included in the third data packet. Flow then moves to operation238.

Since changing the sequence number will also affect the TCP checksum, the transparent TCP proxy120calculates an updated TCP checksum that takes into account the updated sequence number at operation238. The calculation of the TCP checksum may be according to the TCP protocol (e.g., the TCP checksum is the 16 bit ones' complement of the ones' complement sum of all 16 bit words in the header and text). Flow then moves to operation240where the transparent TCP proxy120calculates and stores the difference between the TCP checksum included in the third data packet and the updated TCP checksum (the server TCP checksum difference). The server TCP checksum difference is a 16 bit value. The server TCP checksum difference may be used when updating the TCP checksum of subsequent TCP packets the transparent TCP proxy120intercepts from the TCP server130that are destined for the TCP client110during the TCP connection. Flow moves from operation240to operation242.

At operation242, the transparent TCP proxy120transmits a fourth data packet to the TCP client110as if the transparent TCP proxy120is the TCP server130(e.g., the source IP address of the fourth data packet is the source IP address of the TCP server130). The fourth data packet includes the updated sequence number and the updated TCP checksum. Besides the updated sequence number and the updated TCP checksum, the fourth data packet is substantially similar as the third data packet. Flow moves from operation242to operation244.

At operation244, the transparent TCP proxy120intercepts a fifth data packet transmitted from the TCP client110and destined for the TCP server130. The fifth data packet includes an acknowledgement number that is based in part on the ISN selected by the transparent TCP proxy120and included in the first TCP SYN-ACK packet transmitted to the TCP client110. Flow then moves to operation246.

At operation246, the transparent TCP proxy120updates the acknowledgement number of the fifth data packet to a value that is expected by the TCP server130(e.g., based on the ISN included in the second TCP SYN-ACK packet) using the difference between the ISN selected by the transparent TCP proxy120and included in the first TCP SYN-ACK packet and the ISN selected by the TCP server130and included in the second TCP SYN-ACK packet. Flow then moves to operation248.

At operation248, the transparent TCP proxy120updates the TCP checksum of the fifth data packet using the client TCP checksum difference (e.g., using 16 bit addition). Since the TCP checksum is the ones' complement sum of certain fields in the header, which forms an Abelian Group over the 16 bit numbers in the header, it is both associative and commutative and therefore a single 16 bit addition may be used to update the TCP checksum after once calculating the TCP checksum difference. A single 16 bit addition is faster and less processor intensive than recomputing the TCP checksum. Thus instead of recomputing the TCP checksum in its entirety to account for the updated acknowledgement number, a single 16 bit addition may be used to update the TCP checksum. However, in alternative embodiments, the TCP checksum may be updated by recomputing the TCP checksum. Flow then moves to operation250.

At operation250, the transparent TCP proxy120transmits a sixth data packet to the TCP server130as if the transparent TCP proxy120is the TCP client110(e.g., the source IP address of the sixth data packet is the source IP address of the TCP client110). The sixth data packet includes the updated acknowledgement number and the updated TCP checksum. Besides the updated acknowledgement number and the updated TCP checksum, the sixth data packet is substantially similar as the fifth data packet. Flow then moves to operation252.

At operation252, the transparent TCP proxy120intercepts a seventh data packet transmitted from the TCP server130that is destined for the TCP client110. The seventh data packet includes a sequence number that is based in part on the ISN selected by the TCP server130. Flow then moves to operation254.

At operation254, the transparent TCP proxy120updates the sequence number of the seventh data packet to a value that is expected by the TCP client110(e.g., based on the ISN included in the first TCP SYN-ACK packet) using the difference between the ISN included in the first TCP SYN-ACK packet and the ISN included in the second TCP SYN-ACK packet. Flow then moves to operation255.

At operation256, the transparent TCP proxy120updates the TCP checksum of the seventh data packet using the server TCP checksum difference (e.g., using 16 bit addition). Thus instead of recomputing the TCP checksum in its entirety to account for the updated sequence number, a single 16 bit addition may be used to update the TCP checksum. In an alternative embodiment, the TCP checksum may be updated by recomputing the TCP checksum with the updated sequence number. Flow then moves to operation258.

At operation258, the transparent TCP proxy120transmits an eighth data packet to the TCP client110as if the transparent TCP proxy120is the TCP server130(e.g., the source IP address of the eighth data packet is the source IP address of the TCP server130). The eighth data packet includes the updated sequence number and the updated TCP checksum. Besides the updated sequence number and the updated TCP checksum, the eighth data packet is substantially similar as the seventh data packet.

The transparent TCP proxy120will intercept and translate any subsequent TCP packets transmitted from the TCP client110that are destined for the TCP server130(in the TCP connection) by updating the acknowledgement number using the ISN difference and updating the TCP checksum using the client TCP checksum difference. The transparent TCP proxy120will also intercept and translate any subsequent TCP packets transmitted from the TCP server130that are destined for the TCP client110(in the TCP connection) by updating the sequence number using the ISN difference and updating the TCP checksum using the server TCP checksum difference.

Thus, using the techniques described above the transparent TCP proxy120protects the TCP server130against attacks using incomplete TCP connections (e.g., SYN flood attacks) and reduces the high interrupt rate of the TCP server130that may otherwise have been experienced during such attacks.

The transparent TCP proxy may be implemented in hardware (e.g., using an application-specific integrated circuit (ASIC)) and/or software. The transparent TCP proxy may be implemented in a network adapter card with one or more processors performing the above described operations.

In a specific embodiment, the TCP server130is itself a proxy server for one or more origin servers which may be owned by different entities. The proxy server may provide service(s) for the domains for which the origin servers belong including protecting against Internet-based threats (e.g., proactively stopping botnets, cleaning viruses, trojans, and worms, etc.), providing performance services for customers (e.g., acting as a node in a content delivery network (CDN) and dynamically caching customer's files closer to visitors, page acceleration, content optimization services, etc.), image loading optimization (e.g., deferred image loading and/or auto-resizing), and/or other services. In such an embodiment, the TCP server130may receive TCP packets from TCP clients as a result of a Domain Name System (DNS) request for a domain returning an IP address of the TCP server130.

Authenticating Initiators of TCP Connections

A method and apparatus for authenticating the identity of the initiator of a TCP connection is described. In one embodiment of the invention, when initiating a TCP connection, the TCP initiator generates a TCP SYN segment where a predefined portion of the TCP segment includes a value computed using an authentication algorithm that includes at least the use of a cryptographic hash function that takes as input at least a source of the source IP address of an encapsulating IP packet of the TCP SYN segment and a shared secret between the TCP initiator and the TCP receiver. This computed value is sometimes referred herein as the “initiator authentication value.” Upon receipt of the TCP SYN segment, the TCP receiver uses the same authentication algorithm including the same cryptographic hash function that takes as input at least the source IP address of the encapsulating IP packet and the shared secret between the TCP initiator and the TCP receiver to compute a value that is sometimes referred herein as the “receiver authentication value.” The TCP receiver compares the receiver authentication value with the initiator authentication value included in the predefined portion of the TCP SYN segment. If the values are the same, the TCP handshake is allowed to continue. If the values are different, the TCP connection is denied.

In one embodiment, the predefined portion of the TCP segment used to store the result of the authentication algorithm (the initiator authentication value) is the TCP sequence number field. In another embodiment, the predefined portion of the TCP segment used to store the result of the authentication algorithm (the initiator authentication value) is a TCP options field.

In one embodiment, part of the predefined portion of the TCP segment can be reserved such that the TCP initiator sets that part of the predefined portion to a random value and computes the initiator authentication value using the authentication algorithm with the cryptographic hash function further taking as input that random value, with the result stored in the remaining part of the predefined portion of the TCP segment. By way of a specific example if the predefined portion is the TCP sequence number field, the first 8 bits may be reserved for a random value and the remaining 24 bits may be used to store the cryptographic hash value on that random value, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver. Upon receipt of the TCP SYN segment, the TCP receiver extracts the reserved part of the predefined portion and uses the same authentication algorithm as the TCP initiator to compute a value using the extracted part of the predefined portion, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver. The TCP receiver compares the result of its computed value with the remaining part of the predefined portion of the TCP segment (the part other than the part reserved for the random value). If the values are the same, the TCP handshake will be allowed to continue. If the values are different, the TCP receiver denies the connection.

The TCP receiver may be a TCP receiver for many TCP initiators. In one embodiment, the TCP receiver has a unique shared secret for each TCP initiator. In another embodiment, the same shared secret is used for multiple TCP initiators and the TCP receiver. For example, in embodiments where the TCP initiator is one of multiple nodes in a content delivery network or other distributed network, the same shared secret may be used for each of those nodes and the TCP receiver. Assuming that the shared secret is not compromised, the use of the cryptographic hash function described herein authenticates, with a very high probability, whether the TCP initiator is authorized to initiate a TCP connection with the TCP server.

FIG. 3illustrates a series of messages and operations for authenticating the identity of the initiator of a TCP connection according to one embodiment. As illustrated inFIG. 3, the TCP initiator310is initiating a TCP connection and transmits a TCP SYN message that is received by the TCP receiver320. The TCP initiator310may be any device that executes an application that initiates a TCP connection. The TCP receiver320may be a TCP server that terminates the TCP connection (e.g., a web server that may or may not be an origin server) or may be a device that receives and analyzes TCP messages from TCP initiators that are destined to a TCP server (e.g., a firewall, a proxy, etc.). In a specific embodiment, the TCP initiator310is a proxy server (e.g., a transparent TCP proxy as previously described herein) and the TCP receiver320is a web server or firewall in front of a web server.

The TCP initiator310initiates a TCP connection by generating and transmitting a TCP SYN segment which starts the TCP handshake with a TCP server. The TCP initiator310uses the authentication algorithm325to include information in the generated TCP SYN segment that allows the TCP receiver320to determine, with a very high probability, whether the TCP initiator310is authorized to initiate a TCP connection with the TCP server. The authentication algorithm325includes at least the use of a cryptographic hash function that at least takes as input the source IP address of the IP packet that will encapsulate the TCP SYN segment, and a shared secret between the TCP initiator310and the TCP receiver320. The cryptographic hash function is a hash function that produces a value (sometimes referred to as a hash value or hashed value) that bears seemingly no resemblance to the input and any change to the input will, with very high probability, change the value. Also, while the hashed value is relatively easy to compute, it is nearly impossible to derive the original input from the hashed value itself. By way of example, the cryptographic hash function may be the MD4, MD5, SHA-1, SHA-2, SHA-3, RIPEMD, PANAMA, WHIRLPOOL, or other cryptographic hash function.

At operation340, the TCP initiator310generates340a TCP SYN segment. As part of generating the TCP SYN segment, at operation350, the TCP initiator310executes the authentication algorithm325to compute a value (the initiator authentication value) that includes at least the use of a cryptographic hash function that takes as input at least a source IP address of the IP packet that will encapsulate the TCP SYN segment and a shared secret between the TCP initiator310and the TCP receiver320(as illustrated inFIG. 3, the shared secret330).

The shared secret may be created and distributed to the TCP initiator310and/or the TCP receiver320in any number of ways. For example, the shared secret may be distributed through an API or other means (e.g., email, text message, installed locally, etc.). The shared secret may be unique to the pair of the TCP initiator310and the TCP receiver320or may be common to a group of TCP initiators including the TCP initiator310and the TCP receiver320. For example, in embodiments where the TCP initiator310is one of multiple nodes in a content delivery network or other distributed network, the same shared secret may be used for each of those nodes and the TCP receiver320.

The TCP initiator310stores the computed value in a predefined portion of the TCP SYN segment at operation355. In one embodiment, the predefined portion is the TCP sequence number field. Thus in this embodiment, the TCP initiator310sets the TCP sequence number as the value computed in operation350(the “initiator authentication value”). By way of a specific example and assuming that the sequence number is 32 bits, the TCP sequence number is set as the result of a cryptographic hash function over the source IP address of the encapsulating IP packet and the shared secret. In another embodiment, the predefined portion is a TCP options field.

The TCP initiator310transmits the SYN segment360which will be received by the TCP receiver320. The SYN segment360is encapsulated into an IP packet. The SYN segment360includes the computed value using at least the hash of the source IP address of the encapsulating IP packet and the shared secret330. The shared secret330is not included in the SYN segment360.

The TCP receiver320receives the SYN segment360and at operation365executes the same authentication algorithm325that uses a cryptographic hash function on at least the source IP address of the encapsulating IP packet and the shared secret330to compute a value (the receiver authentication value). The TCP receiver320then compares the computed value (the receiver authentication value) with the value in the predefined portion (the initiator authentication value) at operation370. If the values match, then the TCP handshake continues at operation375. For example, if the TCP receiver320is the TCP server (e.g., if it is a web server that will terminate the TCP connection), the TCP receiver320may transmit a TCP ACK segment and receive a TCP SYN-ACK segment in response to establish the TCP connection. As another example, if the TCP receiver320is not the TCP server (e.g., if it is not terminating the TCP connection), the TCP receiver320may transmit the TCP SYN message360to the TCP server to continue the TCP handshake if the values match. If the values do not match, then the TCP handshake is discontinued at operation380. For example, the TCP receiver320drops the TCP SYN segment.

FIG. 4illustrates a series of messages and operations for authenticating the identity of the initiator of a TCP connection according to another embodiment. As illustrated inFIG. 4, the TCP initiator410is initiating a TCP connection and transmits a TCP SYN message that is received by the TCP receiver420. The TCP initiator410may be any device that executes an application that initiates a TCP connection. The TCP receiver420may be a TCP server that terminates the TCP connection or may be a device that receives and analyzes TCP SYN messages from TCP initiators that are destined to a TCP server (e.g., a firewall, a proxy, etc.). The TCP receiver420may be a web server and may or may not be an origin server that maintains web pages. In a specific embodiment, the TCP initiator410is a proxy server (e.g., a transparent TCP proxy as previously described herein) and the TCP receiver420is a web server or firewall in front of a web server.

The embodiment illustrated inFIG. 4is an enhancement to the embodiment illustrated inFIG. 3where a part of the predefined portion of the TCP segment is reserved such that the TCP initiator410sets that part to a random value and computes the initiator authentication value using the authentication algorithm with the cryptographic hash function further taking as input that random value, with the result stored in the remaining part of the predefined portion of the TCP segment. By way of a specific example if the predefined portion is the TCP sequence number field, the first 8 bits may be reserved for a random value and the remaining 24 bits may be used to store the cryptographic hash value on that random value, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver. Upon receipt of the TCP SYN segment, the TCP receiver420extracts the reserved part of the predefined portion and uses the same authentication algorithm as the TCP initiator410to compute a value using the extracted part of the predefined portion, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver.

The TCP receiver420compares the result of its computed value (the receiver authentication value) with the remaining portion of the predefined portion of the TCP segment that contains the initiator authentication value (the part other than the part reserved for the random value). If the values are the same, then the TCP handshake is allowed to continue. If the values are different, then the TCP handshake is not allowed to continue (e.g., the TCP receiver drops the TCP SYN segment). TCP receiver420continues with the TCP handshake. If the values are different, the TCP server420denies the connection.

The TCP initiator410initiates a TCP connection by beginning a TCP handshake by generating and transmitting a TCP SYN segment. The TCP initiator410uses the authentication algorithm425to include information in the generated TCP SYN segment that allows the TCP receiver420to determine, with a very high probability, whether the TCP initiator410is authorized to initiate a TCP connection with the TCP server. The authentication algorithm425includes at least the use of a cryptographic hash function that at least takes as input the source IP address of the IP packet that will encapsulate the TCP SYN segment, a shared secret between the TCP initiator410and the TCP receiver420, and a random value. The cryptographic hash function may be similar to the cryptographic hash function described with reference toFIG. 3.

At operation440, the TCP initiator410generates440a TCP SYN segment. As part of generating the TCP SYN segment, the TCP initiator310executes the authentication algorithm425that includes generating a random number or receiving a random number at operation450. The random number may be generated using any number of random number generation algorithms. By way of example, the random number may be generated using a pseudorandom number generator (PRNG), a cryptographically secure pseudorandom number generator (CSPRNG), or a hardware random number generator. The random number may also be received from a random number server.

The authentication algorithm425also includes computing a value (the initiator authentication value) using at least a cryptographic hash function that takes as input at least the random number, a source IP address of the IP packet that will encapsulate the TCP SYN segment, and a shared secret between the TCP initiator410and the TCP receiver420(as illustrated inFIG. 4, the shared secret430). The shared secret may be created and distributed to the TCP initiator410and/or the TCP receiver420in a similar way as described with reference toFIG. 3.

The TCP initiator410stores the computed value in a part of the predefined portion of the TCP SYN segment and stores the random number in another part of the predefined portion of the TCP SYN segment at operation455. In one embodiment, the predefined portion is the TCP sequence number field. By way of a specific example if the predefined portion is the TCP sequence number field, the first 8 bits may be reserved for the random value and the remaining 24 bits may be used to store the cryptographic hash value on that random value, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver. In another embodiment, the predefined portion is a TCP options field where a portion of the field stores the random number and another portion stores the computed value.

The TCP initiator410transmits the SYN segment465that is received by the TCP receiver420. The SYN segment465includes the computed value (the initiator authentication value) using at least the hash of the random number, source IP address of the encapsulating IP packet and the shared secret430. The SYN segment465also includes the random number. The shared secret430is not included in the SYN segment365.

The TCP receiver420receives the SYN segment465and at operation470executes the same authentication algorithm425to compute a value (the receiver authentication value) using at least a cryptographic hash function on at least the random number, source IP address of the encapsulating IP packet, and the shared secret430. The TCP receiver420then compares the computed value (the receiver authentication value) with the value included in the other part of the predefined portion (other than the reserved part) that includes the initiator authentication value at operation475. If the values match, then the TCP handshake continues at operation380. For example, if the TCP receiver420is the TCP server (e.g., if it is a web server that will terminate the TCP connection), the TCP receiver420may transmit a TCP ACK segment and receive a TCP SYN-ACK segment in response to establish the TCP connection. As another example, if the TCP receiver420is not the TCP server (e.g., if it is not terminating the TCP connection), the TCP receiver420may transmit the TCP SYN message465to the TCP server to continue the TCP handshake if the values match. If the values do not match, then the TCP handshake is discontinued at operation385. For example, the TCP receiver420drops the TCP SYN segment.

FIG. 5is a flow diagram that illustrates exemplary operations for authenticating the identity of the initiator of a TCP connection according to one embodiment. The operations ofFIG. 5may be performed by a TCP initiator that is initiating a TCP connection with a TCP server.

At operation510, the TCP initiator generates a TCP SYN segment to initiate a TCP connection. As part of generating the TCP SYN segment, the TCP initiator performs operations515and520. At operation515, the TCP initiator computes a first value (the initiator authentication value) using an authentication algorithm that includes at least using a cryptographic hash function that takes as input at least a source IP address of the IP packet that will encapsulate the TCP SYN segment and a shared secret between the TCP initiator and the TCP receiver. The cryptographic hash function may be similar to the cryptographic hash functions previously described herein. The shared secret between the TCP initiator and the TCP receiver may also be generated and/or distributed to the TCP initiator and the TCP receiver as previously described herein. In one embodiment, the first value is a cryptographic hash value produced by the cryptographic hash function or a portion of the cryptographic hash value produced by the cryptographic hash function. Flow moves from operation515to operation520.

At operation520, the TCP initiator stores the computed first value in a predefined portion of the SYN segment. In one embodiment, the predefined portion of the SYN segment is a TCP sequence number field. In another embodiment, the predefined portion of the SYN segment is a TCP options field. The TCP initiator does not store the shared secret in the SYN segment.

In one embodiment, the cryptographic hash function also takes as input a second value, which may be a random value that may be generated or received as previously described herein. In such an embodiment, the TCP initiator stores the second value in another predefined portion of the SYN segment. By way of a specific example, if the predefined portion is the TCP sequence number, the first 8 bits of the sequence number is reserved for the second value and the remaining 24 bits is used to store the cryptographic hash value on that random value, the source IP address of the encapsulating IP packet, and the shared secret between the TCP initiator and the TCP receiver. Flow moves from operation520to operation525.

At operation525, the TCP initiator transmits the generated TCP SYN segment, which will be received by the TCP receiver that will use the same authentication algorithm to authenticate the identity of the TCP initiator and authorize the TCP connection. For example, the TCP receiver will compute a third value using the same authentication algorithm that includes at least using the same cryptographic hash function over the source IP address of the encapsulating IP packet and the shared secret between the TCP initiator and the TCP receiver. If a second value (e.g., random number) is also used as part of computing the first value (the initiator authentication value), the TCP receiver will further use the second value when computing the third value (the receiver authentication value).

FIG. 6is a flow diagram that illustrates exemplary operations for authenticating the identity of the initiator of a TCP connection according to one embodiment. The operations ofFIG. 6may be performed by a TCP receiver that receives TCP connection requests from TCP initiators.

At operation610, the TCP receiver receives a TCP SYN segment from a TCP initiator that initiates a TCP handshake. After receiving the TCP SYN segment, the TCP receiver executes an authentication algorithm to determine whether the TCP SYN segment is received from a client that is authorized to initiate a TCP connection with the TCP server.

Flow then moves to operation615where the TCP receiver extracts a first value from a predefined portion of the TCP SYN segment. The first value is used by the TCP receiver to determine whether the TCP SYN segment is being transmitted from an authorized TCP initiator. The predefined portion is defined according to the authentication algorithm. In one embodiment, the predefined portion is the TCP sequence number field. In another embodiment, the predefined portion is a TCP options field. The TCP SYN segment does not include the shared secret between the TCP initiator and the TCP receiver. Flow then moves to operation620.

At operation620, the TCP receiver computes a second value using the authentication algorithm that includes at least a cryptographic hash function that takes as input at least a source IP address of the encapsulating IP packet and a shared secret between the TCP initiator and the TCP receiver. The cryptographic hash function should be the same cryptographic hash function used by the TCP initiator (if the TCP initiator is an authorized TCP initiator). Flow moves from operation620to operation625.

In an embodiment where the TCP initiator further computes the first value based on a third value (e.g., the cryptographic hash function is over the source IP address, the shared secret, and a random number), the TCP receiver also extracts the third value from another predefined portion of the SYN segment (which may or may not be a different portion of the same field as the extracted first value) and computes the second value using the extracted third value (e.g., the server computes a hash over the source IP address, the shared secret, and the random number).

At operation625, the TCP receiver determines whether the computed second value matches the extracted first value. A match indicates with a very high probability that the TCP initiator knows the shared secret and is thus authorized to initiate a TCP connection with the TCP receiver. If the values do not match, then this is an indication that the TCP connection is being requested from an unauthorized TCP initiator.

If the values match, then flow moves to operation630where the TCP handshake continues. For example, if the TCP receiver is the TCP server (e.g., if it is a web server that will terminate the TCP connection), the TCP receiver may transmit a TCP ACK segment and receive a TCP SYN-ACK segment in response to establish the TCP connection. As another example, if the TCP receiver is not the TCP server (e.g., if it is not terminating the TCP connection), the TCP receiver may transmit the TCP SYN message to the TCP server to continue the TCP handshake if the values match.

If the values do not match, then flow moves to operation635where the TCP receiver discontinues the TCP handshake. For example, the TCP receiver320drops the TCP SYN segment.

As illustrated inFIG. 7, the computing device700, which is a form of a data processing system, includes the bus(es)750which is coupled with the processing system720, power supply725, memory730, and the nonvolatile memory740(e.g., a hard drive, flash memory, Phase-Change Memory (PCM), etc.). The bus(es)750may be connected to each other through various bridges, controllers, and/or adapters as is well known in the art. The processing system720may retrieve instruction(s) from the memory730and/or the nonvolatile memory740, and execute the instructions to perform operations described herein. The bus750interconnects the above components together and also interconnects those components to the display controller & display device770, Input/Output devices780(e.g., NIC (Network Interface Card), a cursor control (e.g., mouse, touchscreen, touchpad, etc.), a keyboard, etc.), and the wireless transceiver(s)790(e.g., Bluetooth, WiFi, Infrared, etc.). One or more of the components of the computing device700may be optional (e.g., the display controller and display device770, I/O devices780, the wireless transceiver(s)790, etc.). In one embodiment, the TCP client110, transparent TCP proxy120, the TCP server130, the TCP initiator310, and/or the TCP receiver320can take the form of the computing device700.