Asymmetric application identification detection on switches

Abstract

Embodiments of the present application relate to asymmetric application identification detection on a switch. A first ingress interface on the switch receives a first control packet for establishing a transmission control protocol TCP session and selects a first engine running on a first line card in the switch. A second ingress interface receives a second control packet and selects the same first engine. After the TCP session is established, data associated with the TCP session received through the first ingress interface or the second ingress interface will be forwarded to the first engine. The first ingress interface receives a third control packet and sends a notification to the selected first engine indicating the TCP session to be tracked. The first ingress interface or the second ingress interface receives a fourth packet having a payload associated with the TCP session and forwards a copy of the fourth packet to the selected first engine, thereby facilitating multiple engine instances to support application identification.

Description

Technical Field

[0001] The present disclosure generally relates to the field of data management. More specifically, the present disclosure relates to a method and system for asymmetric application identification detection on a switch. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An environment having entities and communications that facilitate asymmetric application identity detection according to one aspect of the present application is shown;

[0003] Figure 2A The invention shows the communication between a client, a switch and a server according to one aspect of the present application, including establishing a transmission control protocol (TCP) session for facilitating asymmetric application identification detection;

[0004] Figure 2B The invention shows the communication between a client, a switch and a server according to one aspect of the present application, including establishing a secure socket layer (SSL) protocol and sending data packets to facilitate asymmetric application identification detection;

[0005] Figure 3 A flow chart illustrating a method for facilitating asymmetric application identification detection according to one aspect of the present application is presented;

[0006] Figure 4A A flow chart illustrating a method for facilitating asymmetric application identification detection according to one aspect of the present application is presented;

[0007] Figure 4B A flow chart illustrating a method for facilitating asymmetric application identification detection according to one aspect of the present application is presented;

[0008] Figure 4C A flow chart illustrating a method for facilitating asymmetric application identification detection according to one aspect of the present application is presented;

[0009] Figure 5 A computer system for facilitating asymmetric application identification detection according to one aspect of the present application is shown; and

[0010] Figure 6 An apparatus for facilitating asymmetric application identification detection according to one aspect of the present application is shown.

[0011] In the drawings, like reference numerals refer to like drawing elements. DETAILED DESCRIPTION

[0012] The following description is presented to enable any person skilled in the art to make and use these aspects and examples, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed aspects will be clear to those skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of the present disclosure. Therefore, the aspects described herein are not limited to the aspects shown, but should be given the broadest scope consistent with the principles and features disclosed herein.

[0013] Identification of applications based on Transmission Control Protocol (TCP) Secure Sockets Layer (SSL) services can be important for gaining application visibility, even when the application data is encrypted. An intrusion detection system (IDS) / intrusion prevention system (IPS) engine can perform application identification by examining, for example, the first 5 to 7 packets of a session between a client and a server. In contrast, in a distributed hardware-based switching platform, services may not always be sent to the IDS / IPS engine. Instead, a copy of the new flow may be copied to the IDS / IPS engine at the ingress interface. This may present two challenges. First, copying all new flows to the IDS / IPS engine may result in a denial of service (DoS) type attack. Second, the IDS / IPS engine needs to see both sides of the service (e.g., client to server and server to client), and therefore requires copies of the service flows from multiple blades / line cards. Therefore, a scalable system requires multiple instances of the IPS / IDS engine.

[0014] The aspects of the present application provide a system that can run multiple instances of an IDS / IPS engine and can support large-scale application identification on a distributed hardware switching platform. A switch (i.e., each blade or line card in the switch) can use the time involved in establishing a standard TCP session (i.e., using three control packets in a three-way TCP handshake) to select one of N IDS / IPS engines to send a subsequent copy of a data packet with a payload associated with the established TCP session. The switch can include multiple blades or line cards with corresponding inlet and outlet interfaces. When a TCP session is established between a client and a server, the client inlet interface in the switch can select the same IDS / IPS engine as the server inlet interface, for example, in a distributed manner and based on a selection algorithm. After the TCP session is established, the sent data packet can be forwarded to the selected IDS / IPS engine through each of the client and server inlet interfaces, which can be run on a line card different from the line card associated with the client and server inlet interfaces.

[0015] Typically, an IDS / IPS engine can perform application identification for SSL-based services by inspecting the SSL protocol exchange between the client and the server, for example, by running a heuristic method on the initially encrypted application data. For TCP-SSL services, the SSL handshake can begin after the three-way TCP handshake is completed. That is, the system can first establish a TCP session before starting the SSL protocol exchange or starting the transmission of application data, as described below with respect to Figure 1 , Figure 2A and Figure 2B described.

[0016] Thus, by taking advantage of the time spent during TCP session establishment (i.e., transmission, reception, and processing of three control packets) and taking advantage of the fact that the payload length of these three control packets is typically zero, the described aspects allow the client ingress interface and the server ingress interface of the switch to select the same IDS / IPS engine to forward subsequent data packets having a payload associated with the established TCP session to that engine. Furthermore, if the TCP session is not successfully established (i.e., the TCP handshake is unsuccessful), the system does not need to create any unnecessary inter-blade communications or states. Thus, the described aspects provide a system that can run multiple instances of an IDS / IPS engine (i.e., on different blades or line cards) and can support large-scale application identification by performing IDS / IPS engine selection during TCP session establishment and forwarding subsequent data packets to the selected IDS / IPS engine.

[0017] Environment to facilitate application identification

[0018] Figure 1An environment 100 with entities and communications that facilitate asymmetric application identity detection according to one aspect of the present application is shown. The environment 100 can be an Ethernet, InfiniBand, or other network, and can use corresponding communication protocols, such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. The environment 100 can include many switches and devices. The environment 100 can include: a distributed tunnel structure 110, which includes switches 112, 114, 116, 118, and 120; hosts 132, 134, 136, 138, 140, and 142; devices 150 and 152; and an authentication server 154. The structure 110 can be coupled to an external network 160 via a switch (e.g., a layer 3 router (not shown)). Alternatively, any switch in the architecture 110 can be coupled to the external network 160. The hosts 132-142 can be client computing devices, such as laptops, mobile phones, smart phones, tablet computers, desktop computers, and handheld devices, or processes running on networked devices. Devices 150 and 152 may be computing devices (e.g., servers, networking entities, and communication devices). Each switch may include multiple blades or line cards and may be directly coupled to and communicate with a server, or coupled to and communicate with a server via an external network 160. For example, switch 120 may include: blade_1 122; blade_2 124; blade_3 126; and blade_N 128. Switch 120 may be coupled to and communicate with server 152 (via communication or access 172), and may also communicate with server 150 via external network 160 (via communication or access 166 and 168). In some aspects, switch 120 may authenticate host 140 based on operations performed by authentication server 154. Authentication of host 140 may be based on an authentication process supported by an access layer (not shown), and may be port-based (e.g., IEEE 802.1X) or username / password-based authentication.

[0019] In the environment 100, the corresponding links in the structure 110 can be tunnels. The switches of the structure 110 can form a tunnel network. Examples of tunnels include, but are not limited to, Virtual Extensible Local Area Network (VXLAN), Generic Routing Encapsulation (GRE), Network Virtualization Using GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), and Internet Protocol Security (IPsec). A virtual private network (VPN), such as Ethernet VPN (EVPN), can be deployed on the structure 110. The structure 110 can also include an aggregation layer (not shown) having an aggregation switch, wherein the corresponding aggregation switch can aggregate services from one or more downstream access switches, and can also be coupled to an access layer (not shown) through the access switch, which can facilitate access to the host.

[0020] The host may communicate with one or more switches of the fabric 110, and the switches in the fabric 110 may communicate with one or more hosts. The host may establish a TCP session with the server by initiating a three-way TCP handshake with the server via the switches of the fabric 110. For example, the host 140 may send a first control packet to the server 152 via the switch 120 (via communication 160). The first ingress interface 162 on the switch 120 (e.g., blade_1 122) may receive the first control packet and select an IDS / IPS engine running on, for example, blade_3 126. The egress interface on the switch 120 (e.g., blade_2 124) may send the first control packet to the server 152 (via communication 172).

[0021] The server 152 may send a second control packet back to the host 140 via the switch 120 (via communication 172). The second ingress interface 170 (which is the same as the egress interface used to send the first control packet to the server 152) may receive the second control packet and select the same IDS / IPD engine running on blade_3 126. The egress interface 162 (which is the same as the first ingress interface used to receive the first control packet) may send the second control packet to the host 140 (via communication 160).

[0022] The host 140 may send a third control packet to the server 152 via the switch 120 (via the communication 160). The first ingress interface 162 (e.g., blade_1 122) on the switch 120 may receive the third control packet, and the egress interface (e.g., blade_2 124) on the switch 120 may send the third control packet to the server 152 (via the communication 172). The first ingress interface 162 may also send a notification to the selected IDS / IPS engine on blade_3 126 indicating a TCP session to be tracked by the selected IDS / IPS engine, for example, by a deep packet inspection (DPI) module or component of the selected IDS / IPS engine. As described above, the host 140 may establish a TCP session with the server 152 (where the three control packets pass through the egress and ingress interfaces 170), and may also establish a TCP session with the server 154 (where the three control packets pass through the egress and ingress interfaces 164, which may be associated with, for example, blade_N 128).

[0023] After these three control packets are successfully transmitted and received, a new TCP session is established. Subsequently, the system can execute the SSL protocol through a series of four SSL control packets (as described below for Figure 2B , Figure 4B and Figure 4C As described above). When each of the four SSL control packets is received through the switch 120, the switch 120 may forward each SSL control packet to the selected IDS / IPS engine. Similarly, for any packet received through the switch 120 after the TCP session is established, the switch 120 may forward the corresponding packet to the selected IDS / IPS engine. That is, data associated with the TCP session received through the first ingress interface or the second interface after the TCP session is established may be forwarded to the selected IDS / IPS engine.

[0024] The system can perform engine selection by dynamically calculating or recalculating the engine selection based on any combination of fields or information in the header of the received packet, for example. Alternatively, the system can cache the engine selection after the first calculation and use the cached engine selection when determining where to forward subsequent data packets associated with the established TCP session.

[0025] Facilitates communication of application identity

[0026] Figure 2ACommunication 200 between a client 202, a switch 204, and a server 208 is shown, including establishing a TCP session for facilitating asymmetric application identification detection, according to one aspect of the present application. The switch 204 may include multiple blades or line cards (e.g., blade_1 205, blade_2 206, and blade_3 207), each of which may have an ingress interface and an egress interface. The client 202 may send a first control packet ("TCP SYN 210") to the switch 204. The first ingress interface (blade_1 205) of the switch 204 may receive the control packet 210 and perform a selection engine 211 operation to select an IDS / IPS engine running on blade_3 207. The egress interface (blade_2 206) on the switch 204 may send the first control packet (as "TCP SYN 212") to the server 208. The control packet 212 may indicate information including: a source of the client 202 to a destination of the server 208; the type of packet ("TCP first SYN"); a TCP sequence number of "100"; an ACK value of "0"; a length of "0"; an ingress interface of "blade_1 205"; and an egress interface of "blade_2 206".

[0027] The server 208 may send a second control packet ("TCP SYNACK 214") back to the client 202 via the switch 240. The second ingress interface (blade_2 206, which is the same egress interface used to send the first control packet 212 to the server 208) may receive the second control packet 214 and perform a selection engine 215 operation to select the same IDS / IPS engine running on blade_3 207. The control packet 214 may indicate information including: a source of server 208 to a destination of client 202; a type of packet ("TCP SYN-ACK"); a TCP sequence number of "200"; an ACK value of "101"; a length of "0"; an ingress interface of "blade_2 206"; and an egress interface of "blade_1 205". The first ingress interface (blade_1 205) may send the second control packet (as "TCP SYN ACK 216") to the client 202.

[0028] Client 202 may send a third control packet ("TCP ACK 218") to switch 204. The first ingress interface of switch 204 (blade_1 205) may receive third control packet 218 and perform action 221 to send a notification to the selected IDS / IPS engine running on blade_3 207 indicating that the TCP session has been established and will be tracked. The egress interface (blade_2 206) on switch 204 may send a third control packet (as "TCPACK 220") to server 208. Control packet 220 may indicate information including: a source of client 202 to a destination of server 208; the type of packet ("TCP First ACK"); a TCP sequence number of "101"; an ACK value of "201"; a length of "0"; an ingress interface of "blade_1 205"; and an egress interface of "blade_2 206". Communications may be as described below with respect to Figure 2B Continue as described.

[0029] Figure 2B Communications 230 between a client 202, a switch 204, and a server 208 are shown, including establishing an SSL protocol and sending data packets for facilitating asymmetric application identification detection, according to one aspect of the present application. Figure 2B The communication in Figure 2A 200 occurs after the communication in and may include four SSL control packets. The four SSL control packets may: specify the SSL or Transport Layer Security (TLS) version to be used; determine the cipher suite to be used; authenticate the identity of the server using the server's certificate; and generate a session key for encrypting messages transmitted between the client and the server when establishing the SSL protocol. Although communication 230 depicts the establishment of the SSL protocol, including transmitting or forwarding each of the four control packets to a previously selected IDS / IPS engine, any data packet having a packet associated with the established TCP session and received through the first ingress interface or the second ingress interface may be forwarded to the selected IDS / IPS engine through the corresponding ingress interface.

[0030] The client 202 may send a first SSL control packet ("SSL CLIENT HELLO 232") to the switch 204. The first ingress interface of the switch 204 (blade_1 205) may receive the first SSL control packet 232 and perform an action 235 to forward the packet 232 to the selected IDS / IPS engine running on blade_3 207. The egress interface (blade_2 206) on the switch 204 may send the first SSL control packet 232 (as "SSL CLIENT HELLO 234") to the server 208. The SSL control packet 234 may indicate information including: a source of the client 202 to a destination of the server 208; a type of packet ("SSL Client Hello"); a TCP sequence number of "101"; an ACK value of "201"; a length greater than "0"; an ingress interface of "blade_1 205"; and an egress interface of "blade_2 206".

[0031] After action 235, blade_3 207 may receive the first SSL control packet 232. blade_3 207 may manually or automatically generate three new control packets (e.g., IP and TCP packets representing a three-way TCP handshake), which may allow the selected IDS / IPS engine to proceed as if a TCP session had been successfully established with the selected IDS / IPS engine.

[0032] The server 208 may send a second SSL control packet ("SSLSERVERHELLO 236") back to the client 202 via the switch 240. The second ingress interface (blade_2 206) may receive the second SSL control packet 236 and may perform an action 237 to forward the control packet 236 to the selected IDS / IPS engine running on blade_3 207. The SSL control packet 236 may include ServerHello, a server certificate, and ServerHelloDone, and may also indicate: a source of server 208 to a destination of client 202; a type of packet ("SSL Server Hello"); a TCP sequence number of "201"; an ACK value of "1xx"; a length greater than "0"; an ingress interface of "blade_2 206"; and an egress interface of "blade_1 205". The first ingress interface (blade_1 205) may send the second SSL control packet 236 (as "SSL SERVER HELLO 238") to the client 202.

[0033] Subsequently, the client 202 may send a third SSL control packet ("SSL CLIENT KEY EXCH 240") to the switch 204, which is received on the first ingress interface (blade_1 205) of the switch 204. The first ingress interface on blade_1 205 may perform action 243 to forward the packet 240 to the selected IDS / IPS engine running on blade_3 207. The egress interface (blade_2 206) on the switch 204 may send a third SSL control packet 240 (as "SSL CLIENT KEY EXCH 242") to the server 208. The SSL control packet 242 may include a ClientKeyExchange, a ChangeCipherSpec, and a Finished indicator.

[0034] The server 208 may send a fourth SSL control packet ("SSLSERVER FINISHED 244") back to the client 202 via the switch 240, which is received on the second ingress interface (blade_2 206) of the switch 201. The SSL control packet 244 may include a ChangeCipherSpec and a Finished indicator. The second ingress interface (blade_2 206) may perform an action 245 to forward the packet 244 to the selected IDS / IPS engine running on blade_3 207. The first ingress interface (blade_1 205) may send the fourth SSL control packet 244 to the client 202 (as "SSL SERVER FINISHED 246").

[0035] Methods for facilitating application identification

[0036] Figure 3 A flowchart 300 is presented that illustrates a method for facilitating asymmetric application identity detection according to one aspect of the present application. During operation, the system receives a first control packet for establishing a transmission control protocol (TCP) session through a first ingress interface on a switch (operation 302). The system selects a first engine running on a first line card in the switch through the first ingress interface (operation 304). The system receives a second control packet for establishing a TCP session through a second ingress interface on the switch (operation 306). The system selects the same first engine running on the first line card through the second ingress interface, wherein data associated with the TCP session received through the first ingress interface or the second ingress interface after the TCP session is established will be forwarded to the selected first engine (operation 308).

[0037] The system receives a third control packet for establishing a TCP session through the first ingress interface (operation 310). The system sends a notification to the selected first engine through the first ingress interface, the notification indicating the TCP session to be tracked by the first engine (operation 312). The system receives a fourth packet having a payload associated with the TCP session through the first ingress interface or the second ingress interface (operation 314). The system forwards a copy of the fourth packet to the selected first engine through the first ingress interface or the second ingress interface, thereby facilitating multiple engine instances to support application identification (operation 316).

[0038] Figure 4A A flowchart 400 is presented that illustrates a method for facilitating asymmetric application identity detection according to one aspect of the present application. During operation, the system receives a first control packet for establishing a transmission control protocol (TCP) session through a first ingress interface on a switch (operation 402). The system selects a first engine running on a first line card in the switch through the first ingress interface (operation 404). The system receives a second control packet for establishing a TCP session through a second ingress interface on the switch (operation 406). The system selects the same first engine running on the first line card through the second ingress interface, wherein data associated with the TCP session received through the first ingress interface or the second ingress interface after the TCP session is established will be forwarded to the selected first engine (operation 408). The system receives a third control packet for establishing a TCP session through the first ingress interface (operation 410). The system sends a notification to the selected first engine through the first ingress interface, the notification indicating a TCP session to be tracked by the first engine (operation 412).

[0039] If the length of the payload of the third data packet is greater than zero (decision 414), the system forwards a copy of the third data packet to the selected first engine (operation 416), and if the length of the payload of the third control packet is zero (decision 414), the system treats the flow associated with the third control packet as an active flow through the first ingress interface (operation 418). Figure 4B Continue from label A of .

[0040] Figure 4BA flowchart 420 is presented illustrating a method for facilitating asymmetric application identification detection according to one aspect of the present application. The system receives, through a first ingress interface, a fourth packet having a payload associated with a TCP session, wherein the fourth packet includes a first SSL control packet (operation 422). The system forwards a copy of the fourth packet to a selected first engine through the first ingress interface (operation 424). The system receives, through the selected first engine, the fourth packet (operation 426). The system generates, through the selected first engine, three new control packets, which allow the selected first engine to proceed as if the TCP session was successfully established for the selected first engine (operation 428).

[0041] The system receives a fifth packet having a payload associated with the TCP session through the second ingress interface, wherein the fifth packet includes a second SSL control packet (operation 430). The system forwards a copy of the fifth packet to the selected first engine through the second ingress interface (operation 432). The system receives the fifth packet through the selected first engine (operation 434), and operates at Figure 4C Continue at label B of .

[0042] Figure 4C A flowchart 440 is presented showing a method for facilitating asymmetric application identification detection according to one aspect of the present application. The system receives a sixth packet having a payload associated with a TCP session through a first ingress interface, wherein the sixth packet includes a third SSL control packet (operation 442). The system forwards a copy of the sixth packet to the selected first engine through the first ingress interface (operation 444). The system receives the sixth packet through the selected first engine (operation 446). The system receives a seventh packet having a payload associated with the TCP session through a second ingress interface, wherein the seventh packet includes a fourth SSL control packet (operation 448). The system forwards a copy of the seventh packet to the selected first engine through the second ingress interface (operation 450). The system receives the seventh packet through the selected first engine (operation 452). After establishing the TCP session, the system receives an additional packet having a payload associated with the TCP session through the first ingress interface or the second ingress interface (operation 454). The system forwards a copy of the additional packet to the selected first engine through the first ingress interface or the second ingress interface, thereby facilitating multiple engine instances to support application identification (operation 456). Note that although operations 454 and 456 are depicted as occurring after the SSL protocol, operations 454 and 456 may occur after a TCP session is established (e.g., as described above in Figure 4A The TCP session may occur at any time after the operations for establishing a TCP session described in flowchart 400.

[0043] Computer systems and equipment

[0044] Figure 5 A computer system 500 is shown that facilitates asymmetric application identification detection according to one aspect of the present application. The computer system 500 includes a processor 502, a volatile memory 506, and a storage device 508. The volatile memory 506 may include, for example, a random access memory (RAM) that functions as a managed memory and may be used to store one or more memory pools. The storage device 508 may include persistent storage that may be managed or accessed via the processor 502. In addition, the computer system 500 may be coupled to peripheral input / output (I / O) user devices 510, such as a display device 511, a keyboard 512, and a pointing device 514. The storage device 508 may store an operating system 516, a content processing system 518, and data 534.

[0045] The content processing system 518 may include instructions that, when executed by the computer system 500, may cause the computer system 500 or the processor 502 to perform the methods and / or processes described in the present disclosure. Specifically, the content processing system 518 may include instructions for receiving and transmitting control packets and data packets (communication module 520).

[0046] The content processing system 518 may also include instructions for receiving a first control packet for establishing a transmission control protocol (TCP) session through a first ingress interface on the switch (first interface management module 522). The content processing system 518 may include instructions for selecting a first engine running on a first line card in the switch through the first ingress interface (engine selection module 524). The content processing system 518 may include instructions for receiving a second control packet for establishing a TCP session through a second ingress interface on the switch (second interface management module 526). The content processing system 518 may also include instructions for selecting the same first engine running on the first line card through the second ingress interface, wherein data associated with the TCP session received through the first ingress interface or the second ingress interface after the TCP session is established will be forwarded to the selected first engine (engine selection module 524). The content processing system 518 may include instructions for receiving a third control packet for establishing a TCP session through the first ingress interface (first interface management module 522). The content processing system 518 may include instructions for sending a notification to the selected first engine through the first ingress interface, the notification indicating a TCP session to be tracked by the first engine (session notification module 528). The content processing system 518 may also include instructions for receiving, via the first ingress interface or the second ingress interface, a fourth packet having a payload associated with the TCP session (communication module 520, first interface management module 522, or second interface management module 526). The content processing system 518 may include instructions for forwarding, via the first ingress interface or the second ingress interface, a copy of the fourth packet to the selected first engine, thereby facilitating multiple engine instances to support application identification (packet forwarding module 530).

[0047] The content processing system 518 may further include instructions for receiving a fourth packet through the selected first engine after the first ingress interface forwards a copy of the fourth packet to the selected first engine (communication module 520 and packet forwarding module 530), and instructions for generating three new control packets through the selected first engine, which allows the selected first engine to proceed as if a TCP session was successfully established for the selected first engine (automatic TCP control packet generation module 532).

[0048] Data 534 may include any data required as input or generated as output by the methods and / or processes described in this disclosure. Specifically, data 534 may store at least: packets; control packets; TCP control packets; SSL control packets; identifiers of switches, ingress interfaces, or egress interfaces; indicators of whether a TCP session has been successfully established; selected engines; selected IDS / IPS engines; payload; TCP sequence numbers; acknowledgment numbers; length; length values ​​of zero or greater; notifications; such as about three TCP control packets ( Figure 2A ) or four SSL control packets ( Figure 2B ); indicators of active flows; header information; new control packets; and automatically generated control packets.

[0049] Figure 6 An apparatus 600 for facilitating asymmetric application identification detection according to one aspect of the present application is shown. The apparatus 600 may include a plurality of units or devices that may communicate with each other via wired, wireless, quantum optical or electrical communication channels. The apparatus 600 may be implemented using one or more integrated circuits and may include, for example, Figure 6 In addition, the apparatus 600 may be integrated into a computer system, or implemented as one or more separate devices capable of communicating with other computer systems and / or devices. The apparatus 600 may also be a computer system configured to perform the operations described herein (including the operations described herein). Figure 1 , Figure 2A , Figure 2B , Figure 3 , Figure 4A , Figure 4B and Figure 4C )'s logical switch.

[0050] The apparatus 600 may also include a non-volatile storage system or a memory management unit. The apparatus 600 may include modules or units 602-614, which are configured to perform operations similar to Figure 5 The functions or operations of the modules 520-532 of the computer system 500 include: a communication unit 602; a first interface management unit 604; an engine selection unit 606; a second interface management unit 608; a session notification unit 610; a packet forwarding unit 612; and an automatic TCP control packet generation unit 614.

[0051] In general, the disclosed aspects provide a system that facilitates detecting spikes in memory usage in a computer system. In one aspect, during operation, the system receives a first control packet for establishing a transmission control protocol (TCP) session through a first ingress interface on a switch. The system selects a first engine running on a first line card in the switch through the first ingress interface. The system receives a second control packet for establishing a TCP session through a second ingress interface on the switch. The system selects the same first engine running on the first line card through the second ingress interface, wherein data associated with the TCP session received through the first ingress interface or the second ingress interface after the TCP session is established will be forwarded to the selected first engine. The system receives a third control packet for establishing a TCP session through the first ingress interface. The system sends a notification to the selected first engine through the first ingress interface, the notification indicating a TCP session to be tracked by the first engine. The system receives a fourth packet having a payload associated with the TCP session through the first ingress interface or the second ingress interface. The system forwards a copy of the fourth packet to the selected first engine through the first ingress interface or the second ingress interface, thereby facilitating multiple engine instances to support application identification.

[0052] In another variation of this aspect, the switch operates in a distributed tunnel fabric, the first ingress interface is associated with a client interacting with the distributed tunnel fabric, and the second ingress interface is associated with a server operating in the distributed tunnel fabric.

[0053] In further variations, the first engine and the plurality of engine instances each include an intrusion detection system / intrusion prevention system (IDS / IDS) module or component.

[0054] In further variations, establishing the TCP session includes successfully transmitting and receiving the first control packet, the second control packet, and the third control packet, and also includes performing a successful three-way TCP handshake.

[0055] In further variations, sending the notification indicating the TCP session is in response to receiving a third control packet at the first ingress interface.

[0056] In another variation, in response to determining that the length of the payload of the third control packet is greater than zero, the system forwards a copy of the third packet to the selected first engine. In response to determining that the length of the payload of the third control packet is zero, the system treats a flow associated with the third control packet as an active flow through the first ingress interface.

[0057] In further variations, header information in the fourth packet associates the fourth packet with the established TCP session.

[0058] In another variation, the fourth packet is an SSL packet and includes a ClientHello packet.

[0059] In another variation, after the first ingress interface forwards a copy of the fourth packet to the selected first engine, the system receives the fourth packet by the selected first engine. The system generates three new control packets by the selected first engine, which allows the selected first engine to proceed as if the TCP session was successfully established for the selected first engine.

[0060] In a further variation, generating three new control packets is based on header information from the fourth packet.

[0061] The data structures and codes described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium that can store code and / or data for use with a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tapes, CDs (compact disks), DVDs (digital versatile disks or digital video disks), or other media capable of storing computer-readable media now known or later developed.

[0062] The methods and processes described in the detailed description section may be embodied as code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on a computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and code and stored in the computer-readable storage medium.

[0063] In addition, the above methods and processes may be included in a hardware device or apparatus. For example, the hardware device or apparatus may include, but is not limited to, an application specific integrated circuit (ASIC) chip, a field programmable gate array (FPGA), a dedicated or shared processor that executes a specific software program or code at a specific time, and other programmable logic devices now known or developed later. When the hardware device or apparatus is activated, the hardware module executes the methods and processes included therein.

[0064] The foregoing descriptions of various aspects are presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be clear to those skilled in the art. In addition, the above disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A computer-implemented method comprising: receiving a first control packet for establishing a Transmission Control Protocol (TCP) session through a first ingress interface on the switch; selecting, through the first ingress interface, a first engine running on a first line card in the switch; receiving, via a second ingress interface on the switch, a second control packet for establishing the TCP session; selecting the same first engine running on the first line card through the second ingress interface, wherein after establishing the TCP session, data associated with the TCP session received through the first ingress interface or the second ingress interface will be forwarded to the selected first engine; receiving, through the first ingress interface, a third control packet for establishing the TCP session; sending a notification to the selected first engine via the first ingress interface, the notification indicating the TCP session to be tracked by the first engine; receiving, via the first ingress interface or the second ingress interface, a fourth packet having a payload associated with the TCP session; as well as forwarding a copy of the fourth packet to the selected first engine via the first ingress interface or the second ingress interface, This facilitates multiple engine instances to support application identity. wherein the switch operates in a distributed tunnel structure, wherein the first ingress interface is associated with a client interacting with the distributed tunnel structure, wherein the second ingress interface is associated with a server operating in the distributed tunnel structure, and The first engine and the multiple engine instances each include an intrusion detection system / intrusion prevention system IDS / IPS module or component.

2. The method according to claim 1, Wherein establishing the TCP session includes successfully transmitting and receiving the first control packet, the second control packet and the third control packet, and also includes performing a successful three-way TCP handshake.

3. The method according to claim 1, Wherein sending the notification indicating the TCP session is in response to receiving the third control packet by the first ingress interface.

4. The method according to claim 1, further comprising: responsive to determining that the length of the payload of the third control packet is greater than zero, forwarding a copy of the third control packet to the selected first engine; as well as In response to determining that the length of the payload of the third control packet is zero, treating a flow associated with the third control packet as an active flow through the first ingress interface.

5. The method according to claim 1, The header information in the fourth packet associates the fourth packet with the established TCP session.

6. The method according to claim 1, The fourth packet is an SSL packet and includes a ClientHello packet.

7. The method according to claim 1, further comprising: receiving, by the selected first engine, the fourth packet after the first ingress interface forwards the copy of the fourth packet to the selected first engine; as well as Three new control packets are generated by the selected first engine, which allows the selected first engine to proceed as if the TCP session was successfully established for the selected first engine.

8. The method according to claim 7, The generating of the three new control packets is based on header information from the fourth packet.

9. A computer system comprising: processor; as well as a memory coupled to the processor and storing instructions which, when executed by the processor, cause the processor to perform a method comprising: receiving a first control packet for establishing a Transmission Control Protocol (TCP) session through a first ingress interface on the switch; selecting, through the first ingress interface, a first engine running on a first line card in the switch; receiving, via a second ingress interface on the switch, a second control packet for establishing the TCP session; selecting the same first engine running on the first line card through the second ingress interface, wherein after establishing the TCP session, data associated with the TCP session received through the first ingress interface or the second ingress interface will be forwarded to the selected first engine; receiving, through the first ingress interface, a third control packet for establishing the TCP session; sending a notification to the selected first engine via the first ingress interface, the notification indicating the TCP session to be tracked by the first engine; receiving, via the first ingress interface or the second ingress interface, a fourth packet having a payload associated with the TCP session; and forwarding a copy of the fourth packet to the selected first engine via the first ingress interface or the second ingress interface, This facilitates multiple engine instances to support application identity. wherein the switch operates in a distributed tunnel structure, wherein the first ingress interface is associated with a client interacting with the distributed tunnel structure, wherein the second ingress interface is associated with a server operating in the distributed tunnel structure, and The first engine and the multiple engine instances each include an intrusion detection system / intrusion prevention system IDS / IPS module or component.

10. The computer system according to claim 9, Wherein establishing the TCP session includes successfully transmitting and receiving the first control packet, the second control packet and the third control packet, and also includes performing a successful three-way TCP handshake.

11. The computer system according to claim 9, Wherein sending the notification indicating the TCP session is in response to receiving the third control packet by the first ingress interface.

12. The computer system of claim 9, wherein the method further comprises: responsive to determining that the length of the payload of the third control packet is greater than zero, forwarding a copy of the third control packet to the selected first engine; as well as In response to determining that the length of the payload of the third control packet is zero, treating a flow associated with the third control packet as an active flow through the first ingress interface.

13. The computer system according to claim 9, The header information in the fourth packet associates the fourth packet with the established TCP session.

14. The computer system of claim 9, wherein the method further comprises: receiving, by the selected first engine, the fourth packet after the first ingress interface forwards the copy of the fourth packet to the selected first engine; as well as Three new control packets are generated by the selected first engine, which allows the selected first engine to proceed as if the TCP session was successfully established for the selected first engine.

15. A non-transitory computer-readable storage medium storing instructions, which, when executed by a computer, cause the computer to perform a method, the method comprising: receiving a first control packet for establishing a Transmission Control Protocol (TCP) session through a first ingress interface on the switch; selecting, through the first ingress interface, a first engine running on a first line card in the switch; receiving, via a second ingress interface on the switch, a second control packet for establishing the TCP session; selecting the same first engine running on the first line card through the second ingress interface, wherein after establishing the TCP session, data associated with the TCP session received through the first ingress interface or the second ingress interface will be forwarded to the selected first engine; receiving, through the first ingress interface, a third control packet for establishing the TCP session; sending a notification to the selected first engine via the first ingress interface, the notification indicating the TCP session to be tracked by the first engine; receiving, via the first ingress interface or the second ingress interface, a fourth packet having a payload associated with the TCP session; as well as forwarding a copy of the fourth packet to the selected first engine via the first ingress interface or the second ingress interface, This facilitates multiple engine instances to support application identity. wherein the switch operates in a distributed tunnel structure, wherein the first ingress interface is associated with a client interacting with the distributed tunnel structure, wherein the second ingress interface is associated with a server operating in the distributed tunnel structure, and The first engine and the multiple engine instances each include an intrusion detection system / intrusion prevention system IDS / IPS module or component.

16. The storage medium according to claim 15, wherein the method further comprises: responsive to determining that the length of the payload of the third control packet is greater than zero, forwarding a copy of the third control packet to the selected first engine; in response to determining that the length of the payload of the third control packet is zero, treating a flow associated with the third control packet as an active flow through the first ingress interface; receiving, by the selected first engine, the fourth packet after the first ingress interface forwards the copy of the fourth packet to the selected first engine; as well as Three new control packets are generated by the selected first engine, which allows the selected first engine to proceed as if the TCP session was successfully established for the selected first engine.

Images