News Column

Researchers Submit Patent Application, "Efficient Forwarding of Encrypted Tcp Retransmissions", for Approval

July 29, 2014



By a News Reporter-Staff News Editor at Information Technology Newsweekly -- From Washington, D.C., VerticalNews journalists report that a patent application by the inventor du Toit, Roelof Nico (Portersville, PA), filed on January 9, 2013, was made available online on July 17, 2014.

The patent's assignee is Netronome Systems, Inc.

News editors obtained the following quote from the background information supplied by the inventors: "A network device referred to as a transparent proxy may be used to intercept network traffic. In a typical example, a transparent proxy device intercepts TCP/IP network traffic communicated between a client device and a server device. The client device may seek to establish a TCP connection with a server device so that application layer payload can be transferred between the client and server devices across the TCP connection. To establish the TCP connection, the client device transmits a TCP SYN segment so as to engage in a conventional three-way SYN, ACK-SYN, ACK handshake with the server device, thereby establishing the TCP connection. The transparent proxy device, however, intercepts the TCP SYN segment, records information about the TCP connection, and then forwards the TCP SYN segment to the server device. In a similar manner the proxy device records the rest of the TCP three-way handshake between the client device and server device, with the purpose of possibly modifying future TCP segments on the TCP connection.

"Many times, the application layer payload that is communicated between the client device and the server device is encrypted. An SSL (Secure Sockets Layer) protocol processing layer is disposed above the TCP protocol processing layer and the application protocol processing layer in the TCP/IP stack of each of the client, proxy, and server devices. Accordingly, application layer data communicated out of the client device destined for the server device is encrypted by the SSL protocol processing layer as the information passes down the protocol processing stack in the client device for transmission out of the client device as link layer frames across the TCP connection. Similarly, the link layer frames are received into the proxy device and the information carried passes up the protocol processing stack of the proxy device. The SSL protocol processing layer decrypts the application layer payload. The application layer payload is, however, destined for the server device, so the proxy device passes the application layer payload back down its protocol processing stack for transmission across the second TCP connection to the server device. In contrast to the client device stack and server device stack, the proxy device protocol processing stack takes care not to modify the original boundaries of the different components on each protocol processing layer, unless required for proper functioning of the TCP control loop, which also implies that none of the headers or footers are stripped from any protocol layer, as would be the case when the server device stack or client device stack receives a link layer frame. As the information goes back down the protocol processing stack, the SSL layer encrypts the application layer payload. The information passes across the second TCP connection to the server device in a link layer frame. The frame is received onto the server device, and is processed up the protocol processing stack of the server device to the SSL layer, where the application layer payload is decrypted. The decrypted application layer payload is then made available to the application layer program executing on the server device.

"To enable these encryption and decryption operations in the SSL layers of the protocol processing stacks as described above, two SSL sessions are first established. The first SSL session is established between the client device and the proxy device. The establishing of this first SSL session allows the client device and the proxy device to exchange and agree upon the use of certain cryptographic parameters that the two devices will later use to encrypt and decrypt. Likewise, the second SSL session is established between the proxy device and the server device. The establishing of this second SSL session allows the proxy device and the server device to exchange and agree upon the use of certain cryptographic parameters that the two devices will later use to encrypt and decrypt.

"The cryptographic parameter sets used in the two SSL sessions are different, but in one example both SSL sessions use a stream cipher. In a stream cipher, the encryption of each successive byte of SSL payload depends on the state of an SSL encryption engine at the end of the encryption of the prior byte. Likewise, the decryption of each successive byte of SSL payload depends on the state of an SSL decryption engine at the end of the decryption of the prior byte.

"In the proxy device example, the proxy server may receive from the client device a link layer frame that in turn carries a TCP segment that in turn carries full or partial SSL records. The proxy server may process the TCP segment up its stack to the SSL layer where decryption of the payload of the SSL record occurs in accordance with the first SSL session. Thereafter, the SSL record payload is encrypted in accordance with the second SSL session and is sent back down the stack so that the TCP segment can be forwarded on its way to the server device. The result is that TCP segments sent from the proxy to the server device contains identical TCP sequence numbers in the TCP header, as well as equal TCP payload length, but the TCP payload in the segments might differ because the cryptographic parameter sets for the two SSL sessions might differ. The same holds true for segments sent from the server device to the client device. Consider the situation in which the server device does not receive the TCP segment. The server device will therefore not return an ACK segment to acknowledge receipt. Consequently, the proxy device will not forward the ACK segment back to the client device. If the client device does not receive acknowledgement that the original TCP segment was received, then in accordance with the TCP protocol the client device will retransmit to the TCP segment. In this scenario, the proxy device receives the retransmitted TCP segment and is to send to the server device a retransmission of the same TCP segment that was previously sent out by was not acknowledged. The TCP segment to be sent the second time to the server device is to contain TCP payload identical to that of the TCP segment previously sent but not acknowledged. To support such retransmission requirements in accordance with the TCP protocol, the proxy device stores a copy of all outgoing TCP payload. If the proxy device receives a TCP segment retransmit from the client device, then the proxy device can identify the corresponding outgoing TCP payload, and send a reconstructed TCP segment in a new frame out to the server device. The encrypted SSL payload carried in the reconstructed frame will be identical to the frame not received by the server device, even though the states of the decrypt and encrypt engines of the SSL layer in the proxy device have moved on in their sequences and are no longer in the correct states to regenerate the SSL encrypted content of the retransmit frame."

As a supplement to the background information on this patent application, VerticalNews correspondents also obtained the inventor's summary information for this patent application: "A network device, such as a transparent proxy device, receives TCP segments from a client via a first SSL session and transmits TCP segments to a server via a second SSL session. Both SSL sessions use a stream cipher. The TCP segments all are communicated through the network device via a flow of a single TCP connection. Once a TCP segment has been transmitted from the network device to the server, the TCP payload need no longer be stored on the network device. Substantial memory resources of the network device may therefore be conserved, because the network device may be required to handle many retransmit TCP segments at a given time. The transparent proxy device may handle a million flows at a given time. Rather than storing an unacknowledged TCP segment in the event that the unacknowledged TCP segment may later have to be retransmitted to the server, the network device uses the incoming retransmit TCP segment as received from the client to regenerate the retransmit TCP segment as it should be sent to the server. This method may be performed by a transparent proxy device as well as other types of network devices and appliances, and also may be embodied in software such as the network stack of an operating system.

"In one specific illustrative example, the network device stores a first data structure and a second data structure. The first data structure includes a number of entries for the flow of the TCP connection, where each entry includes: 1) a TCP sequence number (in TCP sequence space) for a start of an SSL payload, 2) a start byte position for the start of the SSL payload in SSL sequence space, and 3) a length of the SSL payload. There may be multiple entries in this first data structure for a given single TCP segment. The second data structure includes a number of entries for the flow of the TCP connection, wherein each entry includes: 1) a start byte position in SSL sequence space, 2) a decrypt engine state for that start byte position, and 3) an encrypt engine state for that start byte position.

"If the network device receives a retransmit TCP segment, then the network device uses the TCP sequence number in the TCP header of the retransmit TCP segment as received (from the client) to identify one of the entries in the first data structure. In one example, the entry identified is the entry whose TCP sequence number (for the start of an SSL payload) is the smallest, and yet is larger than the TCP sequence number from the TCP header. The identified entry indicates a start byte position for an SSL payload carried by the retransmit TCP segment as well as the length of that SSL payload. The start byte position of this identified entry of the first data structure is then used to identify an entry in the second data structure. In one example, the entry identified in the second data structure is the entry whose start byte position is the smallest, and yet is larger than the start byte position from the identified entry of the first data structure. The entry in the second data structure indicates a decrypt engine state and an encrypt engine state. The decrypt engine state is loaded into a decrypt engine of the network device, thereby initializing the decrypt engine. The state of the decrypt engine is then incremented a number of times to correspond to the start position of the SSL payload. The SSL payload of the received retransmit TCP segment is then decrypted, byte by byte, with the decrypt engine being incremented once after each byte is decrypted. The resulting unencrypted SSL payload is then re-encrypted. To re-encrypt the SSL payload, the encrypt engine state from the identified entry in the second data structure is loaded into an encrypt engine of the network device, thereby initializing the encrypt engine. The state of the encrypt engine is then incremented a number of times to correspond to the start position of the SSL payload. The unencrypted SSL payload (as output by the decrypt engine) is then encrypted, byte by byte, with the encrypt engine being incremented once after each byte is encrypted. The resulting re-encrypted SSL payload is then formed into an SSL record, and the SSL payload is passed down the stack of the network device, thereby forming a retransmit TCP segment. The retransmit TCP segment is transmitted via the second SSL session to the server.

"Further details and embodiments and methods are described in the detailed description below. This summary does not purport to define the invention. The invention is defined by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

"The accompanying drawings, where like numerals indicate like components, illustrate embodiments of the invention.

"FIG. 1 is a diagram of a system that includes a novel transparent proxy device in accordance with one novel aspect.

"FIG. 2 is a diagram that shows the TCP connection formed between the client device of FIG. 1 and the server device, with the proxy device intercepting frames on the TCP connection.

"FIG. 3 is a diagram that shows the TCP connection and the stacks in the proxy, client and servers devices in more detail.

"FIG. 4 is a diagram that shows messaging passing back and forth between the proxy device and the client device and the server device in an operational example of the system of FIG. 1.

"FIG. 5 is a diagram that shows how an amount of application layer payload is carried in packets as each protocol processing layer of a stack adds a header onto the packet passed to it by the preceding protocol processing layer.

"FIG. 6 is a diagram that illustrates how the boundaries of SSL record payload on the SSL layer do not align with TCP segment boundaries on the TCP layer.

"FIG. 7 illustrates the overall SSL layer payload of the encrypted HTTP POST message that carries the email body in the example of FIG. 4.

"FIG. 8 is a conceptual diagram of how the proxy device encrypts one byte of the SSL payload.

"FIG. 9 is a conceptual diagram of how the proxy device decrypts one byte of the SSL payload.

"FIG. 10 is diagram of a first data structure usable to determine, for the TCP sequence number of the start of an SSL payload (in TCP sequence space): 1) the corresponding start byte position of the SSL payload (in SSL sequence space), and 2) the length of the SSL payload.

"FIG. 11 is a diagram of a second data structure usable to determine, for each of several start byte positions (in SSL sequence space): 1) the corresponding decrypt engine state, and 2) the corresponding encrypt engine state.

"FIG. 12 includes FIG. 12A and FIG. 12B which together are a flowchart of a method in which a retransmit TCP segment is regenerated by the proxy device rather than the retransmit TCP segment having been stored on the proxy device.

"FIG. 13 is a diagram that shows two TCP segments being communicated through the proxy device in the method of FIG. 12.

"FIG. 14 is a diagram of one of the TCP segments communicated through the proxy device in the method of FIG. 12.

"FIG. 15 is a diagram that shows how the proxy device does not return an ACK for one of the TCP segments output by the client device in the method of FIG. 12.

"FIG. 16 is a diagram that shows how the client device retransmits a TCP segment for which no ACK was received in the method of FIG. 12.

"FIG. 17 is a diagram that illustrates the proxy device determining a decrypt engine state and an encrypt engine state in the method of FIG. 12.

"FIG. 18 is a diagram that illustrates how the proxy device generates a retransmit TCP segment to be retransmitted to the server device in the method of FIG. 12.

"FIG. 19 is a diagram of one example of the network device (also referred to as a network appliance) that performs the method of FIG. 12."

For additional information on this patent application, see: du Toit, Roelof Nico. Efficient Forwarding of Encrypted Tcp Retransmissions. Filed January 9, 2013 and posted July 17, 2014. Patent URL: http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=390&p=8&f=G&l=50&d=PG01&S1=20140710.PD.&OS=PD/20140710&RS=PD/20140710

Keywords for this news article include: Information Technology, Information and Cryptography, Information and Data Architecture, Information and Data Encoding and Encryption, Netronome Systems, Netronome Systems Inc.

Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC


For more stories covering the world of technology, please see HispanicBusiness' Tech Channel



Source: Information Technology Newsweekly


Story Tools






HispanicBusiness.com Facebook Linkedin Twitter RSS Feed Email Alerts & Newsletters