CN116918299A

CN116918299A - Managing playback windows in a multi-path connection between gateways

Info

Publication number: CN116918299A
Application number: CN202280016221.0A
Authority: CN
Inventors: A·K·沙玛; 王勇; S·巴塔查里亚; D·K·索兰基; S·雷; J·贝伦斯
Original assignee: VMware LLC
Current assignee: VMware LLC
Priority date: 2021-07-15
Filing date: 2022-03-29
Publication date: 2023-10-20

Abstract

Described herein are systems, methods, and software for managing playback windows in a multi-path connection between gateways. In one implementation, a first gateway may receive a packet directed to a second gateway and identify a path to the second gateway from a plurality of paths. Once identified, the first gateway may increment the sequence number associated with the path and encapsulate the packet with the unique identifier of the path in a header with the incremented sequence number. The first gateway transmits the encapsulated packet to the second gateway.

Description

Managing playback windows in a multi-path connection between gateways

RELATED APPLICATIONS

The benefits of foreign application serial No. 202141031947, entitled "manage playback windows in multipath connections between gateways (MANAGING REPLAY WINDOWS IN MULTIPATH CONNECTIONS BETWEEN GATEWAYS)" filed in india at 7 and 15 of 2021, and the benefits of U.S. patent application No. 17/492,723, entitled "manage playback windows in multipath connections between gateways (MANAGING REPLAY WINDOWS IN MULTIPATH CONNECTIONS BETWEEN GATEWAYS)" filed by VMware corporation at 10 and 04 of 2021, are claimed in accordance with 35u.s.c.119 (a) - (d), which are incorporated herein by reference in their entirety for all purposes.

Background

In computing networks, gateways are used to provide connectivity between different computing sites or data centers. These gateways may be used to implement network address translation, encapsulation, encryption, firewalls, and secure Virtual Private Network (VPN) tunnels based on security protocols such as internet protocol security (IPsec). The computer at each computing site may include a physical computing system, such as a desktop computing system, a server, etc., and may also include a virtual computing system, such as a virtual machine, container, etc.

In some implementations, the connection between two gateways may use multiple paths, where each of the paths may use a different combination of one or more forwarding devices (such as routers) to provide the connection. These different paths may provide different latency, bandwidth, packet loss rate, and other connection characteristics between gateways. However, while the characteristics of the connection may be improved by selecting and using different paths between the gateways, difficulties may arise in managing the secure connection between the gateways. For example, when multiple paths are used between gateways, the sequence numbers that prevent replay attacks and other attacks on the connection may be interrupted.

Disclosure of Invention

The technology disclosed herein manages playback windows associated with multipath connections between gateways. In one implementation, a method of operating a first gateway includes: a packet having a security protocol header is received from the second gateway and a unique path identifier, a sequence number associated with the unique path identifier, is identified in the security protocol header. The method further provides for determining whether the value of the sequence number is within a playback window and window update buffer associated with the unique path identifier. The packet is discarded or subjected to further ingress processing operations based at least in part on whether the value of the sequence number is within the playback window and the window update buffer associated with the unique path identifier. In some implementations, the security protocol header may include an IPsec protocol header.

Drawings

FIG. 1 illustrates a computing environment that manages playback windows associated with multipath connections between gateways according to an implementation.

Fig. 2 illustrates operations of a gateway to transmit packets across a secure multipath connection according to an implementation.

Fig. 3 illustrates operations of a gateway to receive packets via a secure multipath connection according to an implementation.

FIG. 4 illustrates a data structure for managing window sizes associated with different paths according to an implementation.

Fig. 5 illustrates an operational scenario for receiving a packet in a multipath connection according to an implementation.

Fig. 6 illustrates a gateway computing system for managing playback windows associated with multipath connections according to an implementation.

Detailed Description

Fig. 1 illustrates a computing environment 100 in which playback windows associated with multipath connections between gateways may be managed. Computing environment 100 includes data centers 110-111, where data centers 110-111 include computing nodes 130-131 and gateways 120-121, respectively. Gateways 120-121 communicate using paths 140-142, which paths 140-142 may each include one or more routers or gateways for coupling data centers 110-111. Gateway 120 provides operation ("OP") 200, described further below in fig. 2, and gateway 121 provides operation ("OP") 300, described below in fig. 3.

In data centers 110-111, computing nodes 130-131 are deployed to provide various applications to one or more organizations. The computing nodes 130-131 may comprise virtual computers, such as virtual machines, containers, etc., or may comprise physical computing systems, such as servers, desktop computers, or some other physical computer. Computing nodes 130-131 may provide end user desktops, web applications, data processing applications, or some other application or service.

Here, gateways 120-121 are employed in order to provide connectivity between compute nodes 130 in data center 110 and compute nodes 131 in data center 111. The gateways 120-121 may provide routing for the computing nodes 130-131, firewall operations, and security operations including encryption/decryption and encapsulation operations. Although only one gateway is shown in each data center, multiple gateways may exist for redundancy and/or increased bandwidth. In communication between gateways 120-121, multiple paths 140-142 are employed, each of which may include one or more routers or other packet forwarding or processing nodes (not shown) to couple the gateways. For paths 140-142, gateways 120-121 may be Virtual Private Network (VPN) tunnels to securely transfer data associated with computing nodes 130-131 across a plurality of different paths. To prevent replay attacks (where an attacker detects a data transmission and attempts to gain unauthorized access to the network through replay data transmission), gateways 120-121 may maintain multiple replay windows each associated with a different path. For example, gateway 121 may maintain a playback window for each of paths 140-142.

In the case of a VPN connection implementing internet protocol security (IPsec), the IPsec security header includes a 32-bit sequence number field. In this case, gateway 120 may use a set of bits in the sequence number field in the IPsec header to indicate the selected path of the packet (i.e., the unique identifier of the path) and the remaining bits of the sequence number associated with the path.

Once transmitted to gateway 121, gateway 121 may determine whether the value of the sequence number associated with the unique identifier of the path is within the playback window of the path and the window update buffer associated with the path. The playback window includes the current highest received sequence number of the path minus the playback window size, and the window update buffer includes a grant sequence number that is higher than the current highest received sequence number. The window update buffer may allow any sequence number above the current highest received sequence number value or may allow a limited range of sequence numbers above the highest received sequence number. If the value of the sequence number is below (i.e., less than) the playback window, the packet is discarded. However, if the value of the sequence number is within the replay window and window update buffers, the packet may be processed, where the process may include decrypting the packet and authenticating the packet using a hash or other information in the header of the IPsec packet. Once decrypted, the packet may be forwarded to the destination computing node. In some implementations, if the sequence number is above the window update buffer and the playback window, the packet may also be discarded.

In some implementations, gateways 120-121 may maintain one or more data structures corresponding to playback windows associated with different paths between gateways. The replay window corresponds to the maximum sequence number received in IPsec communication minus the window settings. For example, the highest sequence number received on path 140 may indicate a value of 500 and the window size may be set to 100. As a result, any packets received with a sequence number less than 401 may be discarded. Any packets having a sequence number between 401-500 may be processed (i.e., decrypted and authenticated), and any packets having a sequence number greater than 500 may be processed, and any packets having a sequence number greater than 500 may be used to update the playback window or shift the window to a higher value.

In some implementations, gateway 120 may be responsible for selecting an available path for communication when transmitting packets from gateway 120. For example, each of paths 140-142 may correspond to a different next-hop router (not shown), and gateway 120 may be required to select a next-hop router for communication. Upon receiving a packet from a computing node 130, gateway 120 may select a path based on flow or tuple information in the packet, where the flow information may include IP addressing, port information, protocols, and the like. Once selected, the packet may be encapsulated with a security header having a unique path identifier and sequence number and forwarded to gateway 121 using the selected path. In at least one example, the path may be selected by hashing the flow information from the packet, where, for example, the generated hash value or modulus thereof corresponds to the path identifier. Thus, once a path is selected for the flow information, any subsequent packets sharing the flow information may be transmitted using the same path. The path for the flow information may be selected by hashing, may be selected based on network or connection state information (latency, throughput, etc.), or may be selected in some other way. In some implementations, the flow information may be associated with a path identifier previously stored in a data structure that associates the flow identifier (e.g., tuple information) with the path identifier such that future packets sharing the same flow information will be forwarded to the destination gateway using the same path.

Fig. 2 illustrates a flow diagram of operations 200 that may be performed by gateway 120 to transmit a packet via one of a plurality of paths of a multi-path connection using a security protocol (e.g., IPsec), according to an implementation. Reference numerals identifying steps in the flow chart are referenced in parentheses in paragraphs that follow with further reference to the systems and elements of the computing environment 100 in fig. 1. Although shown using gateway 120, gateway 121 may perform similar operations when packets are communicated to gateway 121.

Operation 200 on gateway 120 identifies (201) multiple paths from a first gateway to a second gateway and assigns a unique identifier value to each of the paths. The paths may be identified using Border Gateway Protocol (BGP) or some other switching protocol to identify different next-hop routers corresponding to the different paths. For each of these paths, in some examples, the unique identifier values may be sequentially assigned, where a first path may be assigned a unique identifier of one and a second path may be assigned a unique identifier of two. In alternative embodiments, the path identifiers may be randomly assigned or assigned in some other manner.

Once assigned, operation 200 further receives (202) a plurality of packets from one or more computers directed to the second gateway. For example, computing node 130 may generate packets that are received by gateway 120 and that need to be communicated to gateway 121 for eventual communication to computing node 131. For each packet of the plurality of packets, operation 200 selects (203) a path from among the available paths for transmitting the packet, increments a sequence number associated with the path, and encapsulates the packet with a security header that includes a unique identifier value associated with the path and the incremented sequence number associated with the path. Once encapsulated, operation 200 transmits (204) the encapsulated packet to a second gateway. In some implementations, gateway 120 may use equal cost multi-path (ECMP) routing to select a path when selecting a path from among the available paths. Alternatively, the path may be selected using a polling schedule, pseudo-randomly, or based on network path characteristics or state information associated with the network path, or may be selected in some other manner. The network path state information may include bandwidth, latency, throughput, or some other network state information. The network path state information may be calculated or determined locally by the sending gateway, such as by performing a network connectivity test (ping) on the intermediate router, by exchanging probe packets with the destination gateway 121, or by other known probing means. Alternatively, the network path state may be provided at least in part by other routers or network monitoring systems in the computing environment. In some examples, the path may be selected based on flow or tuple information (including source and destination IP addressing, source and destination ports, protocol, or some other information in packets from the compute node). The tuple information may be hashed to generate a hash value, which may itself correspond to the selected path identifier, or whose modulus may correspond to the selected path identifier.

Once the path identifier of a particular packet is selected, the path identifier may be associated with a flow identifier in a data structure, where the flow identifier may be a hash of a five-tuple (or other tuple) of the packet header. Once a path is identified with a flow identifier, future packets with the same flow identifier may use the same path by associating the path identifier with the packets of the flow by referencing the data structure.

As an illustrative example, a computing node of computing nodes 130 may generate packets that are received by gateway 120. In response to receiving the packet, gateway 120 may select a path from paths 140-142 to transmit the packet encapsulated with a security protocol header (e.g., IPsec header). The selection may be based on network state information, such as latency, availability, etc., may be selected pseudo-randomly, or may be selected by a polling schedule or by some other mechanism. Once the path is selected, gateway 120 may encapsulate the packet with a security header that includes a unique path identifier associated with the identified path and an incremented sequence number of the identified path. As a result, if gateway 120 selects path 140, the unique identifier of path 140 may be included in the header with the incremented sequence number of path 140. In the case of IPsec, the IPsec header includes a 32-bit sequence number. A portion of the sequence number (i.e., a certain number of 32 bits) may be assigned to a unique path identifier, while a second portion of the bits may be used to provide the sequence number associated with the path. Once the packet is encapsulated with the IPsec header, the encapsulated packet may be forwarded to gateway 121 via path 140. Gateway 121 may process the packet according to the operations described below with reference to fig. 3.

It should be noted that each path identifier thus has a corresponding sequence number that is incremented independently of the sequence numbers of the other paths. The sequence number of a particular path is incremented only when a packet with a corresponding path identifier is transmitted, and the sequence numbers of other paths are not affected by the transmission. Although shown as incrementing the sequence number in the previous example, gateway 120 may reduce or lower the sequence number associated with a particular path.

Fig. 3 illustrates a flow diagram of operations 300 showing an exemplary method for a gateway to receive a packet with a security protocol header via a multipath connection, according to an implementation. The steps of the flowchart are referenced in parentheses in the paragraphs that follow with reference to the systems and elements of the computing environment 100 shown in fig. 1. Although shown using gateway 121, gateway 120 may perform similar operations when a packet is received from another gateway.

As depicted, operation 300 includes receiving (301) a packet with a security protocol header from a second gateway. In response to receiving the packet, operation 300 identifies (302) a unique path identifier and a sequence number associated with the unique path identifier by parsing a security header of the received packet. Once the sequence number and the unique path identifier are identified, the receiving gateway determines (303) whether the sequence number is within a playback window uniquely associated with the path identifier or within a window update buffer for the path identifier. The playback window corresponds to the highest sequence number received with the unique path identifier minus the window size specified for the secure connection. For example, the highest sequence number received for path 140 may correspond to 500 and the window size may be 100. Thus, any packets received between 400-500 may be "inside" the playback window, while any packets having a sequence number of 400 or less may be smaller than the playback window (i.e., "outside" the playback window). Additionally, the window update buffer may indicate a higher sequence number than the current highest received sequence number allowed to be received. The window update buffer may be infinite or may be any range of values above the current highest received sequence number.

When the sequence number in the security protocol header of the received packet is less than (i.e., outside of) the playback window and window update buffer, the operation 300 discards (304) the packet without performing additional operations on the packet. However, when the sequence number in the received packet is "inside" the playback window or update window buffer, operation 300 initiates an ingress processing operation on the packet. Although not shown here, additional checks may be performed before accepting a packet for ingress, such as checking whether the packet was previously received. The inlet treatment operation may include: decrypting the packet using encryption parameters maintained by gateway 121, authenticating the packet based on a hash or other information in the packet's security header, or performing some other operation on the packet.

In some implementations, gateway 121 may determine when the sequence number in the received packet is higher than the current highest sequence number associated with the playback window for the unique path identifier. When the sequence number is higher from the received packet, gateway 121 may update the window for the path based on the new highest sequence number. The updated window may then be used to determine how to process the newly received packet on the path. In some implementations, gateway 121 may use the window update buffer to determine whether the sequence number associated with the unique path is too high to be acceptable. The window update buffer may allow any sequence number higher than the current highest received sequence number to be accepted or the packet may be discarded if the sequence number is higher than the window update buffer. For example, the current highest sequence number may be 500 and the window update buffer 20. If a packet with sequence number 550 is received, the packet may be discarded when the packet is "outside" the window update buffer and playback window. In other examples, the window update buffer may be infinite, allowing any packets that are not under the playback window to be accepted for processing.

It should be noted that incrementing the sequence number is only one example. It is of course possible to decrement the sequence number, in which case the sequence number 500 and the window size 100 would suggest that the window be from 500 to 599, and numbers greater than 599 would be "outside" the window. If a new packet arrives with a new lower sequence number (such as 499) (because the sequence number is decremented), the window is shifted down to start with the new sequence number and the window will extend from 499 to 598. The window update buffer may also be used to define a sequence number for an updateable playback window.

Although illustrated in the example of computing environment 100 using two gateways, each gateway 120-121 may be coupled to any number of other gateways. For each gateway connected, one or more separate data structures may be maintained to reflect the unique identifier and sequence number associated with the egress packet and the unique identifier and sequence number associated with the ingress packet. As an example, gateway 120 may maintain at least one data structure indicating a unique identifier associated with each of paths 140-142 and a sequence number of an egress packet directed to gateway 121. Further, gateway 120 may maintain at least one data structure indicating a unique identifier associated with each of paths 140-142 and a sequence number of an ingress packet received from gateway 121. The ingress unique path identifier and the egress unique path identifier may be different because they are assigned by the originating gateway.

In some implementations, gateways 120-121 may exchange communications to indicate to other gateways that they include a multipath sequence number function. If the other gateway does not include the multipath sequence number function, the unique path identifier may not be used in the security protocol header. However, if the other gateway does include a multipath sequence number function, a unique path identifier may be used to facilitate the multipath VPN connection. The communication may include a vendor identifier exchange defined by an internet standard. As an example, gateway 120 may indicate to gateway 121 that gateway 120 includes a multipath sequence number function, and gateway 121 may return an indication that gateway 121 also includes a multipath sequence number function. When the indication is received, the VPN communication may use the unique path identifier and the sequence number to identify the sequence number associated with the single path.

In some implementations, the sequence number may reach a size that can no longer be accommodated in the available bits of the sequence field of the security protocol header of the packet. As an example, when gateway 120 communicates with gateway 121 over path 140 for an IPsec packet, user-defined configuration or hardcoded parameters may assign some of the 32 bits of the sequence number field of the IPsec header of the IPsec packet to the path identifier and the remaining bits to the sequence number. For example, the user may configure the gateway to assign 24 bits for the serial number and 8 bits for the unique path identifier. When the 24 bits are exhausted and a new sequence number (i.e., sequence number 0 or 1) is received to restart the sequence, the receiving gateway 121 may generate a flip value indicating that the sequence number has been flipped and may indicate the number of times the sequence number has been flipped. Additionally, with flipping, the playback window size may be adjusted to account for packets with large sequence numbers and packets with low sequence numbers at the end of the 24 available bits. In some implementations, the rollover may be classified as an extended sequence number, where the extended sequence number is used to extend or rollover the sequence number associated with the unique path identifier. The rollover may be indicated using a flag in the header from the sending gateway, may be included in the authentication portion of the header of the packet, or some other indication to distinguish the rolled-over packet from a packet that is not rolled-over. The receiving gateway may then maintain a number of flips that may be used to validate packets received from the sending gateway or to distinguish between packets that do not have a flip indication.

Fig. 4 illustrates a data structure 400 for managing window sizes associated with different paths, according to an implementation. The data structure 400 includes columns of path IDs 410, minimum sequence values 412, and maximum sequence values 414. The minimum sequence value 412 and the maximum sequence value 414 are used to demonstrate a playback window 420 for each of the paths 411-414. Although illustrated in three columns, the data structure may take many different forms. The data structure is used to indicate at least a unique identifier associated with the path, a maximum sequence number (with any required flip value) received with the path, or some other information associated with the window size.

As described herein, secure VPN communications between gateways may use multiple paths, each path including one or more routers, switches, and other networking devices to transfer packets between gateways. To support communications, each gateway may maintain information about the unique path identifiers and sequence numbers associated with each unique path identifier. In some implementations, when a packet is received at a first gateway from a second gateway, the first gateway may maintain a data structure indicating the unique path identifiers identified from the second gateway and the highest sequence numbers associated with each unique path identifier. From the highest sequence number, a window size may be applied to determine a playback window associated with the path. In some examples, the playback window may correspond to the highest sequence number packet received minus the window size. Thus, referring to path 411, the received maximum sequence value 414 is 200, and in the case of a window size of 100, the minimum sequence value must be 101 or higher.

When a packet having a unique path identifier is received, the sequence number in the packet is compared to a playback window for the unique path identifier that is independent of window sizes associated with other path identifiers. If the sequence number is less than the playback window of the unique path identifier, the packet is discarded. Otherwise, the gateway performs ingress processing operations on the packet, which may include decrypting or decapsulating the packet, validating the packet based on information in the header of the encapsulated packet, or providing some other operation related to the packet. In some examples, the gateway may use the new highest sequence number to modify the playback window when the sequence number in the received packet is higher than the highest sequence number associated with the path. Thus, if a packet is received for path 411 with sequence number 201, the playback window may be modified to increase the minimum grant sequence number. In some implementations, a window update buffer can be used to determine when a playback window should be updated. The window update buffer may be infinite or may include a defined number. For example, the window update buffer of path 411 may allow a packet to be processed when the value of the packet's sequence number is within 20 of the current highest maximum sequence number. Thus, a received packet with sequence number 210 may be processed and used to update the window, while in some examples, the packet of 230 may not be processed and may be discarded.

In some implementations, the sequence number may need to be flipped when bits are no longer available to increment the sequence number in the packet. For example, an IPsec packet includes 32 bits to indicate the sequence number associated with the packet. Here, a first portion of bits may be used to indicate a unique path identifier for a path between gateways, and a second portion of bits may be used to indicate a sequence number associated with the unique path. When the available sequence number bit has been reached, the rollover flag may be set, or may increment a rollover value indicating the number of times that the rollover associated with the unique path has occurred. For example, if 24 bits are available for a sequence number associated with a path, when the 24 bits are exhausted and a packet restarting the sequence number is received, a flag may be set in association with the unique path indicating a flip at the receiving gateway. The flag or value may be updated as many times as needed and may also be used to update the playback window to include the highest sequence number and flip the lowest sequence number. In one embodiment, a flag is set at a first rollover event or for a first packet associated with a rollover, and the flag is cleared at a subsequent event or packet.

While illustrated as maintaining a data structure for packets received from a second gateway, one or more data structures may also be used to store information associated with egress packets from a first gateway to a second gateway. In some examples, the first gateway may use a border gateway protocol or some other mechanism to identify a path from the first gateway to the second gateway. In some implementations, the first gateway can exchange routing protocols to identify a next hop and a routing path between the first gateway and the second gateway. As the individual paths are identified, a unique identifier may be assigned to each path, wherein in some examples each path may be assigned a unique identifier sequentially. When a packet having a security protocol header is transmitted from a first gateway to a second gateway, the first gateway may select a path identifier and increment a sequence number to be included in the security protocol header. The first gateway may maintain at least one data structure that associates the unique path identifier with a current sequence number of the path. Further, the gateway may maintain an association between a unique path identifier and a sequence number for each coupled gateway. Thus, a unique path identifier may be identified for a different path associated with each other gateway.

Fig. 5 illustrates an operational scenario 500 of receiving a packet in a multipath connection according to an implementation. The operational scenario 500 includes a received packet 510, operations 520-524, and a window 530. The received packet 510 further includes a path identifier ("ID") 512, a sequence number 514, and other packet data 516.

Gateway receiver 121 receives packet 510 from gateway 120, where packet 510 includes a security header, such as an IPsec header for providing encrypted and secure communications between two computing systems or networks. When a packet is received, operation 520 is performed, wherein a unique path identifier and sequence number are read from a secure header of the packet. In some implementations, the security protocol is IPsec and the first portion (e.g., the first 8 bits) of the IPsec sequence number field contains the unique path identifier 512 and the second portion (e.g., the remaining 24 bits) contains the sequence number 514. The sending gateway writes the unique path identifier in the security header. For each unique path identifier, the sending gateway may maintain a sequence number indicating the sequence of packets from the sending gateway to the receiving gateway.

After the unique path and sequence number are identified in the packet 510, an operation 521 is performed to compare the sequence number from the packet with the playback window 530 associated with the path. The replay window is maintained, for example, by path-sequence number table 527, by the gateway based on the highest sequence number received on the path, and may be defined by an administrator of the network in some examples. For example, the playback window may allow packets with sequence numbers up to 64 smaller than the highest sequence number received to be received. Here, when sequence number 514 is less than the playback window of the path, operation 522 is performed in which the packet is discarded (i.e., deleted, overwritten) or not further processed. Conversely, if the sequence number 514 is not less than the window, then operation 523 for processing the packet according to the VPN protocol is performed. Processing of the packet may include decrypting the packet, performing authentication on the packet using information in the security protocol header, or performing some other security operation before forwarding the packet to the destination computer. The destination computer may comprise a virtual computer (such as a virtual machine, container, etc.) or a physical computer (such as a desktop computer, server, or some other physical computer).

In addition to processing packets that are not smaller than the window, the receiving gateway may also determine whether the received sequence number is greater than the current highest sequence number associated with the window. If the sequence number from packet 510 is greater than the highest sequence number of current playback window 530, operation 524 may be used to increment the window based on the newly identified highest sequence number and may update table 527. In some implementations, the sequence number received in the packet may be higher than the current highest sequence number associated with the playback window, but exceeds a threshold for incrementing the window (window update buffer). For example, the current highest sequence number may be 100 and a packet with sequence number 115 may be received. If the window update buffer is ten, in some examples, the packet may or may not be used to update the playback window. In other examples, the window update buffer may not have a limit that allows the highest received sequence number received to update the playback window.

In some implementations, the sequence number may deplete the number of bits available in the security protocol header. To accommodate this condition, the receiving gateway may monitor the sequence number for a flip and set a flag to indicate that the sequence number has been flipped and/or the number of times the sequence number has been flipped. In addition, the playback window may be updated to include both sequence numbers with higher values and sequence numbers with lower values to accommodate flipping. In some implementations, the rollover may be used as part of packet authentication, where the authentication portion of the packet may be used to indicate a rollover of sequence numbers to distinguish a rollover packet from a non-rollover packet.

Fig. 6 illustrates a gateway computing system 600 that manages playback windows associated with multipath connections according to an implementation. Computing system 600 is representative of any one or more computing systems by which the various operating architectures, processes, scenarios, and sequences for a gateway disclosed herein may be implemented. Computing system 600 is an example of gateways 120-121 of fig. 1, but other examples may exist. Computing system 600 includes a storage system 645, a processing system 650, and a communication interface 660. The processing system 650 is operatively linked to the communication interface 660 and the storage system 645. Computing system 600 may also include other components, such as a battery and a housing, which are not shown for clarity.

Communication interface 660 includes components that communicate via communication links, such as a network card, a port, radio Frequency (RF), processing circuitry and software, or some other communication device. The communication interface 660 may be configured to communicate over a metallic link, a wireless link, or an optical link. The communication interface 660 may be configured to use Time Division Multiplexing (TDM), internet Protocol (IP), ethernet, optical network, wireless protocol, communication signaling, or some other communication format, including combinations thereof. The communication interface 660 may be configured to communicate with other gateways using a VPN, and may further communicate with one or more computers (such as a host computing system, a desktop computing system, or some other computing system).

The processing system 650 includes a microprocessor and other circuitry that retrieves and executes operating software from the storage system 645. Storage system 645 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. The storage system 645 may be implemented as a single storage device, but may also be implemented across multiple storage devices or subsystems. The storage system 645 may include additional elements, such as a controller that reads operating software from the storage system. Examples of storage media include random access memory, read only memory, magnetic disk, optical disk, and flash memory, any combination or variation thereof, or any other type of storage media. In some implementations, the storage medium may be a non-transitory storage medium. In some examples, at least a portion of the storage medium may be transitory. In no case is the storage medium a propagated signal.

The processing system 650 is typically mounted on a circuit board that also holds a storage system. The operational software of the storage system 645 includes computer programs, firmware, or some other form of machine readable program instructions. The operating software of the storage system 645 includes an export operation 615 and an import operation 617. The operating software on the storage system 645 may also include utilities, drivers, network interfaces, applications, or some other type of software. When read and executed by processing system 650, the operating software on storage system 645 directs operation of computing system 600 as described herein. In some implementations, the compression process 615 may provide the operations 200 and 300 described in fig. 2 and 3.

In at least one implementation, the egress operation 615 directs the processing system 650 to receive packets from the computer to be transmitted over the internet to the second gateway. In response to receiving the packet, the egress operation 615 directs the processing system 650 to select a path to the second gateway from a plurality of paths, wherein each path may include one or more routers or other network elements. Once selected, computing system 600 increments the sequence number associated with the path and encapsulates the packet with a security protocol header that indicates the unique identifier value associated with the selected path and the incremented sequence number for the path. After encapsulation, egress operation 615 directs processing system 650 to communicate the encapsulated packet to the second gateway.

In some implementations, the gateway computing system 600 may maintain one or more data structures that may associate the unique path identifier of the second gateway with the sequence number of the corresponding path. Gateway computing system 600 may further maintain information for one or more additional gateways, including a path identifier for a path to each additional gateway and a sequence number associated with each path.

In addition to providing egress operations 615 for the egress VPN packet, ingress operation 617 directs processing system 650 to receive the VPN packet from the second gateway. In response to receiving the packet, ingress operation 617 directs processing system 650 to identify a unique path identifier and a sequence number associated with the unique path identifier in a security protocol header. Once identified, the portal operation 617 determines if the sequence number is less than the playback window associated with the unique path identifier. In some implementations, the ingress operation 617 may maintain a replay window associated with a different path from the second gateway. The playback window is based on the highest sequence number received for the unique identifier minus the specified window size (e.g., 100 sequence numbers smaller than the highest sequence number received). If the sequence number in the received packet is less than the playback window, then ingress operation 617 discards the packet. However, if the sequence number in the received packet is not less than or within the playback window, then ingress operation 617 may process the packet to enter, where the processing may include decrypting the packet, authenticating the packet using information in the header, forwarding the decapsulated packet to the destination computer, or providing some other operation.

In at least one implementation, the ingress operation 617 may determine whether the sequence number value in the packet is inside or greater than the playback window (i.e., above the maximum sequence number previously received for the unique path identifier). If the sequence number is higher than the current playback window, then entry operation 617 may determine if the value of the sequence number is within the window update buffer, and may update the playback window when the value is in the window update buffer. In some examples, the window update buffer may allow any value greater than the received current maximum sequence number. However, in some examples, the buffer may be a range of values.

In some implementations, the sequence number and unique path identifier may be placed in a sequence number bit portion of an IPsec header, where a first portion of the bits may be assigned to provide the unique identifier and a second portion may be assigned to provide a sequence number associated with the unique identifier. The unique identifiers for the respective paths between the gateways may be assigned by the sending gateway, where the sending gateway may identify the respective paths to the destination gateway and assign a unique identifier to each path. In some examples, the gateway computing system 600 may inform the second gateway that the computing system 600 includes a multipath sequence number function. If both gateways include functionality, the gateway may use the operations described herein. In some examples, when the gateways have determined that they all include a multipath sequence number function, the gateway may use a discovery mechanism or gateway exchange to identify next hop information and identify different available paths to the destination gateway. For each identified path, the gateway may identify a unique identifier and assign the unique identifier to the path. Once communication is required, a path may be selected randomly, based on network state information, or based on some other mechanism, and the packet may be transmitted using the unique identifier of the path and the sequence number of the path.

The description and drawings included depict specific implementations to teach those skilled in the art how to make and use the best mode. Some conventional aspects have been simplified or omitted in order to teach the inventive principles. Those skilled in the art will appreciate variations of these implementations that fall within the scope of the invention. Those skilled in the art will also appreciate that the features described above can be combined in different ways to form multiple embodiments. Therefore, the present invention is not limited to the specific implementations described above, but is only limited by the claims and the equivalents thereof.

Claims

1. A method of operating a first gateway, comprising:

receiving a first packet having a first security protocol header from a second gateway;

identifying a first path identifier and a first sequence number from the first security protocol header;

determining whether to drop the first packet or subject the packet to ingress processing based at least in part on whether the value of the first sequence number is within a first playback window and window update buffer associated with the first path identifier;

receiving a second packet having a second security protocol header from the second gateway;

identifying a second path identifier and a second sequence number from the second security protocol header, wherein the second path identifier is different from the first path identifier;

Determining whether to drop the second packet or subject the packet to ingress processing based at least in part on whether the value of the second sequence number is within a second playback window associated with the second path identifier and the window update buffer; and

wherein the second playback window associated with the second path identifier is independent of the first playback window associated with the first path identifier.

2. The method of claim 1, wherein the ingress processing operation comprises decrypting the first packet and authenticating the first packet.

3. The method of claim 1, wherein the sequence number is incremented, and wherein the method further comprises:

determining that the first sequence number is greater than a highest sequence number associated with the first playback window and in the window update buffer; and

in response to determining that the first sequence number is greater than a highest sequence number associated with the first playback window and in the window update buffer, the first playback window is updated based on the first sequence number without updating the second playback window.

4. The method of claim 1, wherein the first security protocol header comprises a first internet protocol security header, and wherein the second security protocol header comprises a second internet protocol security header.

5. The method of claim 1, further comprising:

identifying a plurality of paths from the first gateway to a third gateway;

assigning a unique identifier value to each of the plurality of paths;

receiving a plurality of packets from one or more computers directed to the third gateway;

for each of the plurality of packets:

selecting a path of the plurality of paths to transmit the packet;

incrementing a sequence number associated with the path;

encapsulating the packet with an internet protocol security header indicating a unique identifier value associated with the path and an incremented sequence number of the path; and

the encapsulated packet is transmitted to the third gateway.

6. The method of claim 5, wherein selecting the path of the plurality of paths comprises selecting a path using pseudo-random selection or selecting a path based on network state information.

7. The method of claim 1, further comprising: one or more communications are exchanged with the second gateway to determine that the second gateway includes a multipath sequence number function.

8. The method of claim 1, further comprising: the playback window is determined based on a highest sequence number received in association with the unique path identifier prior to the first packet.

9. A computing device, comprising:

a storage system;

a processing system operatively coupled to the storage system; and

program instructions stored on the storage system that, when executed by the processing system, direct the computing device to:

10. The computing device of claim 9, wherein the ingress processing operation comprises decrypting the first packet and authenticating the first packet.

11. The computing device of claim 9, wherein the sequence number is incremented, and wherein the program instructions further direct the computing device to:

12. The computing device of claim 9, wherein the first security protocol header comprises a first internet protocol security header, and wherein the second security protocol header comprises a second internet protocol security header.

13. The computing device of claim 9, wherein the program instructions further direct the computing device to:

Identifying a plurality of paths from the first gateway to a third gateway;

assigning a unique identifier value to each of the plurality of paths;

for each of the plurality of packets:

selecting a path of the plurality of paths to transmit the packet;

incrementing a sequence number associated with the path;

the encapsulated packet is transmitted to the third gateway.

14. The computing device of claim 13, wherein selecting the path of the plurality of paths comprises selecting a path using pseudo-random selection or selecting a path based on network state information.

15. The computing device of claim 9, wherein the program instructions further direct the computing device to exchange one or more communications with the second gateway to determine that the second gateway includes a multipath sequence number function.

16. The computing device of claim 9, wherein determining whether the sequence number is less than a playback window associated with the unique path identifier determines whether the sequence number is less than a playback window associated with the unique path identifier based at least on a flip value associated with the unique path identifier.

17. A system, comprising:

a first gateway; and

a second gateway configured to:

receiving a first packet having a first security protocol header from the first gateway;

receiving a second packet from the first gateway with a second security protocol header;

determining whether to drop the second packet or subject the packet to ingress processing based at least in part on whether the value of the second sequence number is within a second playback window and window update buffer associated with the second path identifier; and

18. The system of claim 17, wherein the ingress processing operation comprises decrypting the first packet and authenticating the first packet.

19. The system of claim 17, wherein the first security protocol header comprises a first internet protocol security header, and wherein the second security protocol header comprises a second internet protocol security header.

20. The system of claim 17, wherein the first gateway is further configured to:

the first packet and the second packet are transmitted to the second gateway.