Patent ID: 12192238

While the disclosure is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the disclosure is not intended to be limited to the particular forms disclosed. Rather, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION

The herein disclosed embodiments take a different and more efficient approach to the above-noted, and other, issues with existing systems and methods. Disclosed embodiments do not use a tunnel, do not need connection tracking, and have a mechanism in place to efficiently recognize each connection of overlapping IP addresses as disclosed herein.

Currently, extensible multi-stream transport protocols have in built security (such as QUIC). This eliminates any need for having additional support of security protocols. These extensible multi-stream transport protocols also have multiplexing capabilities to send more bytes into the wire. This enables sending more packets into one extensible multi-stream transport protocol packet, unlike traditional tunneling protocols such as IPSec, and to encapsulate each connection packet with its header. Also, extensible multi-stream transport protocols are fast enough to track connections with minimal protocol and round trip time overhead.

As disclosed herein, instead of using TCP, disclosed embodiments rely on multi-stream transport protocols (e.g., QUIC protocols). Multi-stream transport protocol packets are authenticated and fully encrypted (except packet number and caller ID (CID)). These user-space protocols solve the above-mentioned problems with the herein disclosed solutions and methods implemented over a multi-stream transport protocol.

FIG.2is a schematic illustration of (a) the packet flow in the forward direction, (b) the high-level overall architecture, and (c) the packet flow in the reverse direction. As used herein MTM stands for Multi-Tenant Module. As shown, TCP packets130A,130B originating from enterprise users102A,102B are intercepted on a client device128where it is distinguished based on the metadata such as site-ID and Tenant-ID.

As indicated, a multi-stream transport protocol (MSTP) connection134is created between client device128and server-side device132. An MTM-Client module200intercepts the traffic from enterprise users102A,102B and determines the packet type. In some embodiments, there are two scenarios for transmitting packets: if the packet is a synchronize packet (SYN) packet (e.g., packet130B) or if the packet is the acknowledge (ACK)/data packet (e.g., packet130A). If the packet is a SYN packet (e.g., packet130B), then MTM-Client module200opens two streams136A,136B with consecutive stream IDs (e.g., first stream ID=y and second stream ID=y+1). Since the streams136A,136B are a client-initiated streams then they will always be even number bidirectional streams. Here, these two streams136A,136B work as a pair. The first stream136A of the pair only carries the 5-tuple and the metadata such as: site-id and tenant-id. The second stream136B carries the entire TCP packet. Upon receiving the MSTP traffic134packet, MTM-Server module300dismantles the packet into a stream138B. If MTM-Server module300encounters any streams carrying 5-tuple and metadata, it will search for the next stream ID (e.g., stream ID=y+1) for the payload in the packet and saves the 5-tuple to an in-memory cache database such as Redis or the like. This 5-tuple is given to policy engine110and upon successfully passing the policy check, TCP packet is extracted from stream and source NAT-ed from NAT module140to connect to the protected application142.

In the above example embodiment, description of typical authentication (e.g., SYN/SYN-ACK/ACK) is not provides as it is unchanged from typical situations and is not relevant here. Further, the above example is for situations where a MSTP connection between a client128and server132is already established.

As also shown schematically, if a packet is a data packet (e.g.,130A) then it means that connection (i.e., MSTP traffic134) is in established state and MTM-Client module200can find out the stream based on the 5-tuple and send the packet as a stream payload138A.

In some embodiments, in order to handle faster SYN timeout, MTM-Client module200starts a timer for every stream carrying a SYN packet (e.g., packet130B). If the SYN-ACK is not received even before the SYN timeout (i.e., a configurable timer), then MTM-Client module200sends the same SYN packet again. The receiver (e.g., MTM-Server module300on server132) will, of course, send a Reset (RST) packet on the duplicate packet or the receiver might send a SYN-ACK packet on the duplicate. In both the cases, MTM-Client module200will know quickly that connections are working or not. For example, if a SYN-ACK packet is not received upon sending3consecutive SYN packets, then the connection may be declared dead.

In some embodiments, MTM-Client module200has a known buffering capacity per stream. If an ACK packet is not received, then MTM-Client module200sends the ACK packet before TCP timeout on the enterprise user102A,102B side, this way, MSTP traffic134will be able to detect any packet loss before timeout occurs.

As will be apparent to those of ordinary skill in the art having the benefit of this disclosure, many benefits exist for the above-described stream pairs136A-B and144A-B. For example, unlike IPSec and other tunnels, data (which is a SYN packet136A,144A) in this case) is transmitted in the first packet along with the connection identification such as 5-tuple, site ID and tenant ID. Therefore, a connection establishment for every user-initiated client128connection is not required. In addition, after finding any stream in the pair, it becomes easy to find out the other. For example, if a stream with a 5-tuple is found then, the next immediate stream ID has the payload. This obviates the need for tracking connections.

In addition, policy engine110has information about 5-tuple along with the data with 0-RTT, to run policies on the packets. Furthermore, a single MSTP134packet can have multiple stream pairs which alleviates bandwidth limitations, which is one of the major problems with IPSec. Also, the number of bytes transmitted in a stream is controlled by the streams' flow and congestion control.

In addition, every stream has offset to reorder the packets, which makes packet re-ordering more resilient than TCP. Further, there are several stream pairs (e.g.,136A-B,144A-B) in the packet, which means several packets are inside one single MSTP packet134. This reduces the protocol overhead compared to every tunnel packet bears with its IPSec and TCP header. Every MSTP packet134bears a short header, which can be as small as 2 bytes (e.g., if CID length is omitted) to 4 bytes. Which is much less than the 64 bytes (Standard) for IPSec and 20-40 bytes of TCP. Likewise, IPSec and other tunnel methods track the connection to represent the state of the tunnel, which is CPU-expensive, while if the MSTP connection134between client128and server132is down, it can re-establish based on Zero Round Trip Time Resumption (0-RTT). Other advantages also exist.

Table I below provides exemplary algorithm code for MTM-Client module200packet handling.

TABLE 1MTM-Client Module Handling1function (packet)25Tuple = Calculate5Tuple(packet)3stream_id = 5Tuple4if Packet to transmit then5if pkt is SYN then6x, x + 1 = Open_bi_directional_stream(stream_id)7hash_table_save(5Tuple, state)8start_timer_for_resend(syn)9connection_state = SYN_SENT10else11find_stream_id(5Tuple)12send_msg_on_stream( )13start_timer_for_resend(nek)14else if Packet is recieved then15if pkt to SYN-ACK then16Connection_state = SYN-ACK17if pkt = hash_table_find(stream_id) then18send_to_user(pkt)19else20drop packet21return

On the server132side, upon receiving a MSTP packet134, each MSTP packet is dismantled into streams138A,138B. If a stream contains 5-tuple then this 5-tuple is send to policy engine110to run policy on it. As described herein, the next immediate stream (e.g., stream ID=x+1 or stream ID=y+1) will contain the payload which is buffered, until a go-ahead comes from policy. If a policy denies the connection for this 5-tuple then a stream close message is sent and MTM-Client module200will know to close the corresponding TCP connection on the user-client128side. MTM-Server module300also saves the 5-tuple and metadata in-memory cache to be served to other components later. A packet extracted from the MSTP stream134is given to NAT module140to perform source NAT and the TCP packet is sent to the protected applications142.

For received traffic, a packet is sent over the same stream136B,144B it came from. This is because MTM-Client module200will know immediately that this is the reply for the TCP packet sent earlier.

Table II below provides exemplary algorithm code for MTM-Server module300packet handling.

TABLE IIMTM-Server Module Handling1function (packet)2if packet is recieved then3if packet-is-SYN then45tuple, metadata = get_info(stream x)5if authenticate(pkt) then6pkt = get_packet(stream x + 1)7save_redis(5Tuple, metadata)8if policy_run(5-tuple) then9handover_to_nat_module(pkt)10else11send FIN on stream12else13if is_authenticated(pkt) then14pkt = get_packet(stream x + 1)15if policy_run(5-tuple) then16handover_to_nat_module(pkt)17else18send FIN on stream19else if Packet is to transmit then20stream_id = get_stream_id(5-tuple)21send_pkt_in_stream(pkt)22return

As will be apparent to those of ordinary skill in the art having the benefit of this disclosure, other advantages and benefits of the above-disclosed systems and methods also exist. For example, the above disclosed use of MSTP also eradicates some of the problems inherent in TCP, such as every MSTP packet (e.g.,136A-B,144A-B) (and even re-transmitted ones) has a packet number which eliminates any ambiguity. Likewise, there is no Head-of-Line blocking problems as MSTP is on UDP and UDP does not wait for any retransmission to keep the received packets hostage until all packets are arrived. Additionally, there is better congestion and flow control because MSTP provides per-stream congestion and flow control, which is why the bandwidth utilization in situations with no packet loss and few packet loss, is very high. This solves the problem of bandwidth utilization inherent in IP Sec.

Although various embodiments have been shown and described, the present disclosure is not so limited and will be understood to include all such modifications and variations are would be apparent to one skilled in the art.