Patent Description:
Traffic in a computer network can be analyzed to improve real-time decision-making for network operations, security techniques, or other considerations. Given the complexity and volume of traffic routed through many infrastructures, various types of network tools are often used to analyze the network traffic. These network tools typically analyze unencrypted or plaintext data, while other communications in the computer network are typically encrypted. In some cases, encrypted data transmitted from a first device in the network to a second device is intercepted by an inline network appliance, decrypted, and transmitted to a network tool for analysis. The tool returns an unencrypted communication to the network appliance, which generates an encrypted communication to transmit to the second device. The network appliance typically matches communications among the tool, client, and server based on each communication's "<NUM>-tuple," specifying source and destination ports, source and destination IP addresses, and protocol used by the communication. However, because the network tool uses a different IP address than the first device, the network appliance typically cannot associate the communication from the network tool with the communication from the first device based on the <NUM>-tuple. If the communication from the network tool is not matched to a communication from the first device, the network appliance cannot generate the encrypted communication to transmit to the second device.

"<NPL>, Retrieved from the Internet: http://www. infosecurityproductsguide. com/technology/ <NUM>/Netronome_Examining_SSL-encrypted_Communications. pdf, concerns network-based threats in SSL-encrypted communications and discloses the Netronome SSL Inspector software offering enterprise security appliances or applications access to the unencrypted plaintext of SSL flows.

A network appliance that operates inline to network communication between a client device and a server intercepts a data stream including one or more data packets transmitted between the client device and server and transmits the packets (or a copy of the packets) to an inline network tool. The network tool analyzes the data packets and returns one or more of the packets to the network appliance. Based on the proxy response, the network appliance transmits one or more data packets to the client or server. To associate the proxy response with the original data stream from the client or server, and therefore to correctly route the proxy response to an intended target, the network appliance appends a session identifier to the data packets transmitted to the proxy. The proxy response similarly includes the session identifier, and the network appliance associates the proxy response with the original data stream using the session identifier.

<FIG> illustrates an example environment <NUM> in which a network appliance operates. As shown in <FIG>, the environment <NUM> can include a client device <NUM>, a network appliance <NUM>, a proxy <NUM>, and a server <NUM>. Other embodiments of the environment <NUM> can include additional or different devices. For example, multiple clients <NUM> and/or multiple servers <NUM> can communicate in the environment <NUM> through the network appliance <NUM>, or multiple proxies <NUM> can receive and analyze data from the network appliance <NUM>. The client device <NUM>, network appliance <NUM>, proxy <NUM>, and server <NUM> may transmit data streams through various intermediate devices not shown in <FIG>, such as routers or network switches. Furthermore, data streams between the devices can be transmitted by wired or wireless connections over networks such as one or more local area networks (LANs), wide-area networks (WANs), metropolitan area networks (MANs), and/or the Internet.

The client device <NUM> communicates with the server <NUM>, transmitting data packets to or receiving data packets from the server <NUM> in a networked communication session. In some embodiments, the client device <NUM> is a device used by a user to request content from the server <NUM>, such as a laptop or desktop computer, mobile phone, or tablet. However, the client device <NUM> can additionally or alternatively be any of a variety of other computer devices such as another server or a node in the networked environment.

The server <NUM> similarly can transmit data packets to or receive data packets from the client device <NUM> in a networked communication session. In response to requests received from the client device <NUM>, the server <NUM> can serve content to the client device <NUM>. For example, the server <NUM> can be a web server configured to serve a requested webpage to the client <NUM>.

The proxy <NUM> is a network tool that can be configured to analyze data packets transmitted between the client <NUM> and server <NUM>, monitor traffic within the computer network, and/or attempt to block or stop the transmission of abnormal or malicious data packets. In some embodiments, the proxy <NUM> may analyze the data packets to determine whether the data packets comply with one or more policies. A policy can, for example, include heuristics or learned models that indicate whether a data packet is abnormal or malicious. Another example policy can determine whether a data packet complies with a network use guideline of an enterprise. If a data packet does not comply with the one or more policies, the proxy <NUM> may modify the packet or block its transmission. In some cases, the proxy device <NUM> effectively separates the client <NUM> and server <NUM>, removing or modifying data packets transmitted between the devices to perform tasks such as access control, web caching, and content filtering.

The proxy <NUM> can be located physically remote from the network appliance <NUM>. For example, the network appliance <NUM> can include a housing that physically encloses its components, while the proxy <NUM> has a separate housing that physically encloses its components and is remote from the appliance housing. The proxy <NUM> can communicate with the network appliance <NUM> by a wired or wireless connection.

The network appliance <NUM> intercepts data packets transmitted between the client device <NUM> and server <NUM> and routes the packets to the proxy <NUM> for analysis before passing the packets (as modified by the proxy <NUM>, if relevant) to their targeted destination. The network appliance <NUM> can be configured as a node in a computer network that can receive data packets from one or more other nodes in the network, such as the client device <NUM> and server <NUM>. The network appliance <NUM> can operate in an inline mode within a data path between a sending endpoint node (e.g., the client <NUM>) and a receiving endpoint node (e.g., the server <NUM>), receiving data packets from the sending endpoint node and forwarding at least some of the original data packets to the receiving endpoint node. The network appliance <NUM> can determine which data packets to forward to the endpoint node based on the analysis by the proxy <NUM>.

Data packets can be received and transmitted by the network appliance <NUM> at physical network ports of the appliance, and multiple network ports can be coupled to different nodes in the computer network. Embodiments of the network appliance <NUM> can be, for example, a monitoring platform that includes a chassis and interchangeable blades offering various functionalities, such as enhanced packet distributed and masking/filtering capabilities.

Messages between the client device <NUM> or server <NUM> and the network appliance <NUM>, each including one or more data packets, can be encrypted. In some embodiments, the network appliance <NUM> can establish a secure network connection with the client device <NUM> and exchange data with the client device <NUM> that is encrypted using a first private key. The network appliance <NUM> can similarly establish a secure network connection with the server <NUM> and exchange data with the server <NUM> that is encrypted using a second private key. The secure connections between the network appliance <NUM>, client <NUM>, and server <NUM> can be enabled by a protocol such as transport layer security (TLS) or secure sockets layer (SSL).

Data streams between the network appliance <NUM> and proxy <NUM> can be plaintext, unencrypted data. To communicate with the proxy <NUM>, the network appliance <NUM> can decrypt the data received from the client device <NUM> or server <NUM> using, respectively, the first private key and the second private key. The decrypted communications can be transmitted to the proxy <NUM> for analysis, and the proxy <NUM> can return similarly unencrypted communications to the network appliance <NUM> based on the proxy's analysis.

To match the data streams received from the proxy <NUM> to data streams received from the client <NUM> and server <NUM>, the network appliance <NUM> generates a session identifier that uniquely identifies the network communication session between the appliance <NUM> and client <NUM>, the communication session between the appliance <NUM> and server <NUM>, or both. The session identifier can, for example, identify the client <NUM>, the server <NUM>, both the client and server, the connection(s) between the network appliance <NUM> and either or both of client <NUM> or the server <NUM>, a security parameter used in the data stream between the network appliance <NUM> and the client device <NUM> or the server <NUM>, or other information about the client and/or server. In some embodiments, the network appliance <NUM> generates the session identifier by generating an encoded representation, such as a hash, of identifiers of the client <NUM>, server <NUM>, and/or communications between the devices. In other embodiments, the packet processor <NUM> generates the session identifier by generating a random string. The generated string can be mapped to information such as the identifier of the client <NUM>, the server <NUM>, or at least one of the communication sessions of the network appliance <NUM>.

<FIG> is a block diagram that illustrates one embodiment of the network appliance <NUM>. As shown in <FIG>, the network appliance <NUM> can include a packet processor <NUM>, a first network port 210A, a second network port 210B, a first tool port 215A, and a second tool port 215B.

The network ports <NUM> are communicatively coupled to the client <NUM> and server <NUM> to receive data from or transmit data to the client <NUM> and server <NUM>. For example, the network port 210A is communicatively coupled to the client <NUM>, while the network port 210B is communicatively to the server <NUM>. In some embodiments, the network ports <NUM> can be physical ports in a housing containing the network appliance <NUM>. In other embodiments, the network ports <NUM> represent virtual ports that may be combined as part of one or more physical ports. For example, the network port 210A and the network port 210B may be part of a single physical port in the housing of the network appliance <NUM>. Similarly, the network ports <NUM> can be aggregates of multiple physical ports. For example, each port <NUM> shown in <FIG> can represent a group of physical ports used as a single packet transmission channel through link aggregation.

The tool ports <NUM> can receive data from or output data to one or more network tools, such as the proxy <NUM>. Like the network ports <NUM>, the tool ports <NUM> can be physical ports in the network appliance <NUM> housing, virtual ports, or a combination of physical and virtual ports. In some embodiments, each tool port <NUM> is configured to receive data from a tool or output data to a tool. For example, <FIG> shows that the tool port 215A outputs data to a tool while the tool port 215B receives data from the tool.

The packet processor <NUM> routes data packets between the network ports <NUM> and/or tools ports <NUM>. The packet processor <NUM> can have a hardware processor such as a central processing unit or a microprocessor, and can include or be coupled to a memory that stores computer program instructions executable by the hardware processor. In some embodiments, the packet processor <NUM> applies a packet routing rule stored in the memory to determine how to handle a data packet received at the network appliance <NUM>. The rule can cause the packet processor <NUM> to forward a data packet to a specified location, such as a specified tool port <NUM> or network port <NUM>. In some cases, the rule can also cause the packet processor <NUM> to process a data packet in a specified manner, such as aggregating the data packet with another data packet, removing the data packet from the network traffic, or modifying the packet (e.g., by adding a header to the packet, removing a header, or removing a payload).

The packet processor <NUM> associates data streams transmitted to the proxy <NUM> with data streams received from the proxy <NUM> using a session identifier. The session identifier can be stored in the memory. When transmitting one or more packets to the proxy <NUM>, the packet processor <NUM> appends a header to the message that includes the session identifier. The proxy <NUM> applies the header to any messages the proxy transmits to the network appliance <NUM>, and the packet processor <NUM> can extract the session identifier from the header of any message received from the proxy <NUM>. By extracting the session identifier from the header of any message received from the proxy <NUM>, the packet processor <NUM> can associate the received message with the message transmitted to the proxy <NUM>.

<FIG> show a process for correlating data streams transmitted between a client <NUM> and a server <NUM>, according to one embodiment. As shown in <FIG>, the process can include interactions between the client <NUM>, the network appliance <NUM>, the proxy <NUM>, and the server <NUM>. Other embodiments can include additional, fewer, or different steps, and the steps can be performed in different orders. Furthermore, although references are made to specific communications protocols, other embodiments of the process can use different protocols for communication between the devices.

Referring to <FIG>, the client device <NUM> initiates <NUM> a first transmission control protocol (TCP) connection to the network appliance <NUM>. For example, the client <NUM> and network appliance <NUM> complete a three-way handshake (3WHS) that establishes a first network connection between the client and appliance. The network appliance <NUM> similarly initiates <NUM> a second TCP connection to the proxy <NUM>. After establishing the first and second TCP connections, the client device <NUM> establishes <NUM> an HTTP connection with the network appliance <NUM> over the first TCP connection, and the network appliance <NUM> establishes <NUM> an HTTP connection with the proxy <NUM> over the second TCP connection.

The proxy <NUM> can initiate <NUM> a third TCP connection from the proxy to the network appliance <NUM>, using, for example, the 3WHS procedure. The proxy <NUM> can also return a response to the network appliance <NUM> approving <NUM> the second HTTP connection. The network appliance <NUM> returns a response to the client <NUM> approving <NUM> the first HTTP connection.

The network appliance <NUM> can initiate <NUM> a fourth TCP connection between the appliance and the server <NUM>. By communicating with the client <NUM> over the first TCP connection and the server <NUM> over the fourth TCP connection, the network appliance <NUM> can effectively isolate the client from the server. For example, the network appliance <NUM> can intercept data streams from the server <NUM> and analyze them before serving them to the client <NUM>. The network appliance <NUM> therefore can effectively simulate the role of the server <NUM> to the client <NUM> and the role of the client to the server.

To act as the server to the client <NUM>, the network appliance generates <NUM> a trusted security certificate. The security certificate authenticates an identity of the network appliance <NUM>, and can be signed by a trusted certificate signing authority. Using the generated certificate, the network appliance <NUM> and client <NUM> execute <NUM> a handshake to establish encrypted data streams between the devices. For example, the network appliance <NUM> and client <NUM> execute an SSL handshake in which the client <NUM> validates the certificate generated by the appliance and the appliance <NUM> and client <NUM> generate a first encryption key for encrypting data streams between the devices.

The client <NUM> can transmit <NUM> an encrypted data stream over the first network connection between the client and the network appliance <NUM>. For example, the client <NUM> can transmit a request for content from the server <NUM>. In response to receiving the first data stream, the network appliance <NUM> generates <NUM> a session identifier that uniquely identifies the network communication session(s) among the client <NUM>, the appliance <NUM>, and the server <NUM>.

The network appliance <NUM> decrypts <NUM> the data stream received from the client and transmits <NUM> the decrypted data stream to the proxy <NUM>. A header containing the session identifier is appended to the decrypted data stream.

When the proxy <NUM> receives the decrypted data stream, the proxy can generate <NUM> a proxy response to the data stream. The proxy response can be generated based on analysis of the data stream received from the client, and can include, for example, removing or modifying one or more data packets in the data stream received from the client or passing through all data packets without modification. The proxy <NUM> transmits <NUM> the proxy response to the network appliance <NUM>, appending a header to the proxy response that includes the session identifier.

Using the session identifier extracted from the proxy response, the network appliance <NUM> associates <NUM> the proxy response to the data stream received from the client <NUM>. Associating the proxy response to the client data stream enables the network appliance <NUM> to match the data streams and pass the client data stream to the server <NUM> based on any modifications applied by the proxy <NUM>. For example, if the client <NUM> requested to access a webpage and the proxy <NUM> approves the access to the webpage, the network appliance <NUM> determines that the client request can be passed to the server <NUM> in response to the approval from the proxy <NUM>.

Based on the proxy response, the network appliance <NUM> generates <NUM> a data stream to transmit to the server <NUM>. The data stream can be generated <NUM> based on the data stream from the client and/or the proxy response. For example, if the proxy <NUM> modified or removed data packets from the client data stream, the network appliance <NUM> can generate a data stream to the server that includes the modified set of data packets. The network appliance <NUM> can also re-encrypt data using the second encryption key, before transmitting <NUM> the second data stream to the server <NUM> over the fourth TCP connection.

In response to associating the proxy response with the data stream received from the client, the network appliance <NUM> executes <NUM> a handshake with the server <NUM> to establish an encrypted communication session over the fourth TCP connection, between the network appliance <NUM> and the server <NUM>. Like the handshake between the client <NUM> and network appliance <NUM>, the network appliance <NUM> and server <NUM> can execute, for example, an SSL handshake in which the network appliance <NUM> and the server <NUM> generate a second encryption key for encrypting communications between the devices.

The server <NUM> receives the second data stream from the network appliance <NUM> and generates <NUM> a server response to the second data stream. For example, if the second data stream includes a request for content such as a webpage, the server <NUM> can generate a response including the requested content. The server transmits <NUM> the response to the network appliance <NUM> over the fourth TCP connection.

The network appliance <NUM> receives the server response and decrypts <NUM> using the second encryption key. The decrypted server response is appended to a header including the session identifier and transmitted <NUM> to the proxy <NUM> for analysis. The proxy <NUM> returns <NUM> a response to the network appliance <NUM>, with the session identifier in the header of the response.

Using the session identifier extracted from the proxy response, the network appliance <NUM> associates <NUM> the proxy response with the original data stream received from the client <NUM> and identifies the proxy response as a response to the client data stream. The network appliance <NUM> generates a response based on the proxy response, and transmits <NUM> the generated response to the client <NUM>.

<FIG> is a simplified functional diagram of one example network appliance <NUM>. The embodiment comprises three network ports <NUM> a-c and two instrument ports <NUM> a-b. Each network port <NUM> a-c comprises a network in port <NUM> a-c and a network out port <NUM> a-c. Each instrument port <NUM> a-b comprises an instrument in port <NUM> a-b and an instrument out port <NUM> a-b. Referring to <FIG>, a first network port <NUM> a comprises a first network in port <NUM> a and a first network out port <NUM> a. A second network port <NUM> b comprises a second network in port <NUM> b and a second network out port <NUM> b, and a third network port <NUM> c comprises a third network in port <NUM> c and a third network out port <NUM> c. Further, a first instrument port <NUM> a comprises a first instrument in port <NUM> a and a first instrument out port <NUM> a, and a second instrument port <NUM> b comprises a second instrument in port <NUM> b and a second instrument out port <NUM> b. In operation, a network port is linked to and in communication with a set of terminals in the packet-switching network. The source addresses of the ingress packets originated from these terminals and received at the network in port of the network port are the terminal addresses of these terminals. The embodiment analyzes each ingress packet that the network in port of each network port receives. Further, the embodiment updates address Table <NUM> to include the source address of each ingress packet received at each network port and associate that network port with that source address, which is also the terminal address of a terminal that is linked to that network port. The terminal addresses associated with each network port are removed from address table <NUM> according to a predetermined strategy.

The ingress packets are directed from each network in port <NUM> a-c to the corresponding circuit switch inputs of circuit switch <NUM>. In <FIG>, the circuit switch inputs of circuit switch <NUM> are shown on the left side of the circuit switch block and the circuit switch outputs of circuit switch <NUM> are shown on the right side of the circuit switch block. Circuit switch <NUM> is an example implementation of a mux-switch. A mux-switch comprises a plurality of mux-switch inputs and a plurality of mux-switch outputs. The functions of the mux-switch include but are not limited to, aggregating the packet traffic from multiple mux-switch inputs to a mux-switch output, or directing the packet traffic from a mux-switch input to a mux-switch output, or broadcasting the packet traffic from a mux-switch input to multiple mux-switch outputs, or a combination thereof. The circuit switch input of circuit switch <NUM> is a mux-switch input. The circuit switch output of circuit switch <NUM> is a mux-switch output. The mux-switch may be manually controlled or program controlled so that, for example, the packet traffic pattern in the mux switch is reconfigurable.

Circuit switch <NUM> functions as a circuit cross connect switch, in which circuit switch <NUM> directs the packet traffic from a circuit switch input to a circuit switch output. Optionally, circuit switch <NUM> aggregates the packet traffic from multiple circuit switch inputs to a circuit switch output, or circuit switch <NUM> directs the packet traffic from a circuit switch input to one circuit switch output, or circuit switch <NUM> multicasts the packet traffic from a circuit switch input to multiple circuit switch outputs, or circuit switch <NUM> aggregates the packet traffic from multiple circuit switch inputs and multicasts the aggregated packet traffic to multiple circuit switch outputs, or a combination thereof. The circuit switch <NUM> shown in <FIG> comprises five circuit switch outputs <NUM> a-e. The packet traffic from at least one of the circuit switch outputs <NUM> a-e is directed to a first instrument out port <NUM> a. The packet traffic from the other circuit switch outputs <NUM> a-e may be directed to other instrument out ports, for example, a second instrument out port <NUM> b, or directed to the inputs <NUM> a-e of packet switch fabric <NUM>. Direct packet traffic from circuit switch <NUM> to packet switch fabric <NUM> is optional, and the second instrument out port <NUM> b is optional. The packet traffic from instrument in ports, for example, first instrument in port <NUM> a and second instrument in port <NUM> b, are directed to the inputs of packet switch fabric <NUM>. Second instrument in port <NUM> b is optional.

Packet switch fabric <NUM> examines the destination address of each packet it receives from its inputs <NUM> a-e; and looks up the identity of the network port that is associated with the destination address of the packet in address table <NUM>. If the destination address of the packet is in address table <NUM>, packet switch fabric <NUM> routes the packet to the network out port of the network port that is associated with the destination address in address table <NUM> through one of its outputs <NUM> a-c; otherwise, packet switch fabric <NUM> broadcasts the packet to the network out ports of a predetermined selection of network ports. This predetermined selection may include no network port, or at least one network port, or all network ports.

<FIG> shows an example deployment of the network appliance <NUM> in a network environment <NUM> in accordance with some embodiments. The Internet 1004is coupled via routers <NUM> a-b and firewalls <NUM> a-b to two switches <NUM> aand <NUM> b. Switch <NUM> a is coupled to servers <NUM> a-b and IP phones 1014a-c. Switch <NUM> b is coupled to servers <NUM> c-e. A sniffer <NUM>, an IDS 1018and a forensic recorder <NUM> (collectively, "non-pass through instruments") are coupled to the device <NUM>. As illustrated in <FIG>, there is a reduction on the number of non-pass through instruments in this deployment as compared to a conventional configuration (in which there may be one or more non-pass through instruments between router <NUM> a and firewall <NUM> a, one or more non-pass through instruments between firewall <NUM> a and switch <NUM> a, one or more non-pass through instruments between router <NUM> b and firewall 1068b, and firewall <NUM> b and switch <NUM> b) because the same non-pass through instruments can now access information anywhere in the network environment <NUM> through the device <NUM>. The user has complete flexibility to channel whatever traffic to whatever instrument or groups of non-pass through instruments, using the any-to-any, any-to-many and many-to-one capability of the system in accordance with the different embodiments described herein. For example, all the conversations of the IP phones <NUM> a-c can be easily configured to be sent to an IDS <NUM>. It is also possible that traffic inside a particular IP phone <NUM> a-c connection can be sent to a sniffer <NUM>, and Intrusion Detection System <NUM> and a forensic recorder <NUM> simultaneously via the one-to-many function. The packet processing features of the device 100described herein allow the device <NUM> to process the packets based on a unified model to address any network monitoring requirements.

In some embodiments, when using the network appliance <NUM>, one or more non-pass through instruments (such as IDS, sniffer, forensic recorder, etc.) may be connected to instrument port(s), and one or more pass through instruments <NUM> (e.g., IPS) may be connected to other instrument port(s) (e.g., inline port(s)). Such configuration allows non-pass through instrument(s) and pass through instrument(s) to simultaneously monitor the network traffic. Each non-pass through instrument is in listening mode (i.e., it receives packets intended to be communicated between two nodes), and each pass through instrument is in pass-thru mode (i.e., it receives packets intended to be communicated between two nodes, processes them, and then pass the packets downstream towards the intended recipient node). In some cases, by having both an IDS and an IPS connected to the network appliance <NUM>, the appliance <NUM> can compare whether the IDS or the IPS sees more threats, and/or can have a redundant protection such that if the IPS misses any threat, the IDS may pick it up.

Claim 1:
A method comprising:
storing, at an inline network appliance, a session identifier that uniquely identifies a network communication session between a first device and the inline network appliance;
receiving, at the inline network appliance, a first communication from the first device in the network communication session, wherein the data received from the first device is encrypted using a first encryption key;
receiving, at the inline network appliance, from a proxy tool, a second communication that includes a header specifying the session identifier and that includes data generated by the proxy tool by modifying data from the first communication;
associating, by the inline network appliance, the first communication with the second communication by using the session identifier; and
transmitting an encrypted representation of the data generated by the proxy tool from the inline network appliance to a second device based on the association between the first communication and the second communication, wherein transmitting the encrypted representation of the data to the second device comprises encrypting the data generated by the proxy tool using a second encryption key.