Enhancing ipsec performance and security against eavesdropping

This application claims the priority of US Provisional Patent Application No. 61/618359, entitled "Multiple Path IP Layer Security," filed by Xiangyang Zhang on March 30, 2012. By citation, the entire contents of the above provisional patent application are incorporated into this application.

Devices connected to the network are required to communicate via various networks. Depending on the device, security may be required even in such communication. Devices that are interconnected via a protected network (secure network) are security measures specific to the protected network so that communication over any network is provided with such security. Rely on. Also, these devices may be required to communicate over an unprotected network. For example, a host computer may communicate with other hosts, clients, networks, etc. over the Internet, which is partially, unevenly, and / or not protected at all. The security level of communication can only be the weakest level of security provided for communication at any point between the sender and the receiver. To maintain security for communications that pass through unprotected networks, network devices can use a variety of security protocols. For example, a source network device can have a secure connection and / or a secure connection with the destination network device if both the source network device and the destination network device are configured to use the same security protocol. Communication can be negotiated.

<p num="0003"><nplcit num="1"><text>Internet Engineering Task Force (IETF) document request for comment (RFC) 4301</text></nplcit><nplcit num="2"><text>IETF document draft-zhang-ipsecme-multi-path-ipsec-02</text></nplcit><nplcit num="3"><text>IETF document RFC 4302</text></nplcit><nplcit num="4"><text>IETF document RFC 4303</text></nplcit></p>

<p num="0004"> In one aspect, the disclosure includes a network element (NE), which is a memory device configured to store an instruction and a plurality of elements in a data flow by executing the instruction. It includes a processor configured to divide a first data packet into a plurality of first subflows and transmit the plurality of first subflows over a network to a second network element. Multiple first subflows are transmitted using a first Internet Protocol Security (IPsec) SA cluster that includes multiple Parallel Subsecurity Associations (Security Associations, SAs).</p><p num="0005"> In another aspect, the present disclosure uses Internet Key Exchange (IKE) or IKE version 2 (Internet Key Exchange version 2, IKEv2) between a network element and a second network element. Includes network elements with processors configured to create an IPsec SA cluster with multiple primary sub-SAs. The plurality of first sub-SAs are unidirectional. The plurality of first sub-SAs are configured to transmit a plurality of first data packets in a common direction.</p><p num="0006"> In another aspect, the present disclosure includes a method comprising setting up a plurality of IPsec SA subtunnels and clustering the plurality of IPsec SA subtunnels together to form an SA cluster.</p><p num="0007"> These and other features will be more clearly understood from the description of the detailed description of the invention below, along with the accompanying drawings and the description of the claims.</p><p num="0008"> In the following, for a more complete understanding of the present disclosure, a brief description will be given in connection with the accompanying drawings and a detailed description of the invention. Similar reference numerals represent similar parts.</p>

<figref num="1">It is the schematic which shows one Embodiment of the IPsec security architecture.</figref><figref num="2">It is a schematic diagram which shows another embodiment of the IPsec security architecture.</figref><figref num="3">It is a flow chart which shows one Embodiment of the method of creating an SA cluster.</figref><figref num="4">It is a flow diagram which shows one Embodiment of the method of selecting a sub SA for a data subflow.</figref><figref num="5">It is a flow diagram which shows one Embodiment of the method of receiving data through an SA cluster.</figref><figref num="6">It is a schematic diagram which shows one Embodiment of a network element.</figref>

IPsec is an Internet Protocol (Internet) that goes through a variety of networks, as described in the Internet Engineering Task Force (IETF) document RFC 4301 (Non-Patent Document 1), which is incorporated herein by reference. Protocol, IP) A suite of security protocols that includes a set of security protocols to protect communications. IPsec is an IP layer (eg, Open Systems Interconnection). Interconnection, OSI) Communication at the third layer and / or network layer of the reference model) can be protected. IPsec can be an end-to-end security scheme that protects data flow (eg, communication) between security gateways. IPsec can use a unidirectional SA pair to protect a data flow containing multiple data packets. For example, the local security gateway may use a first SA to protect the communication transmitted to the remote security gateway and a second SA to protect the communication received from the remote security gateway. IPsec may also allow SA bundles involving the nesting of SAs within SAs (eg, tunneling through tunnels). IPsec may be restricted to use SA pairs and / or SA bundle pairs. IPsec may sequentially transmit packets via the SA. In addition, each SA has a uniquely determined security parameter index (Security Parameter). Index, SPI) may be assigned. From this, the eavesdropping node can receive all packets passing through the tunnel protected by the SA by monitoring a single network node and use SPI to correlate the packets with each other. If an eavesdropping node breaks through SA security measures, the eavesdropping node may gain full access to the entire data flow.

Disclosed herein are methods and / or systems with enhanced protection for data traffic transmitted over unprotected networks. IPsec data protection can be enhanced by dividing the data flow into multiple subflows and transmitting the multiple subflows in parallel (eg, via multiple subtunnels and / or multiple transport communications). .. The sub SA may be set independently for each sub flow. Multiple sub-SAs may be combined to form an SA cluster. Each sub-SA may contain a uniquely defined SPI. Sub-SAs in an SA cluster may or may not use different network paths between the local security gateway and the remote security gateway. For this reason, the eavesdropping node cannot access all subflows by monitoring a single node in the middle of the network path, and cannot grasp the existence, number, or route of other network paths. .. In addition, since each sub SA can include an SPI that is uniquely determined, even an eavesdropping node that acquires packets from multiple subflows associates data packets with each other and determines that they are related to the same flow. I don't get it. In addition, parallel transmission of a plurality of subflows may make it possible to improve transmission efficiency beyond serial transmission. The SA cluster is detailed in the IETF document draft-zhang-ipsecme-multi-path-ipsec-02 (Non-Patent Document 2), which is incorporated in this application by reference.

Methods and / or systems can improve security services by distributing data traffic across multiple paths. For example, such distribution can increase the difficulty for an attacker to successfully intercept all packets, as different routes may be used. Even if the same route is used, it is difficult for an attacker / eavesdropper to determine that a set of SAs is part of a particular clustered SA, which is an intercepted packet. Can increase the difficulty of decrypting. Also, the choice of multiple paths can provide improved reliability (eg, in the event of a link failure). Also, the use of multiple SAs may offer additional options for optimized performance and optimized network control. These technologies can improve the security services provided by IPsec. SA clusters may offer the option of performing different cryptographic translations on different packets. Furthermore, SA clusters may offer the option of transmitting packets along different paths.

FIG. 1 is a schematic diagram showing an embodiment of the IPsec security architecture 100. The IPsec security architecture 100 includes hosts 150 and hosts 151, which may communicate via security gateways 110, 112 via routers 120 located on unprotected network 130. Hosts 150,151 may be connected to security gateways 100,112 via protected connections 143,144, respectively. Hosts 150,151 may wish to communicate over unprotected network 130. The security gateway 110 may configure a unidirectional SA 141 for transmission to the security gateway 112, for example using IKE and / or IKEv2. Similarly, security gateway 112 is a unidirectional SA for transmission to security gateway 110. 142 may be set, and as a result, SA pairs can be created. Host 150 may transmit data to host 151 by communicating with security gateway 110 over protected connection 143. The security gateway 110 may use the SA 141 to transmit communication to the security gateway 112 over the unprotected network 130 through the router 120. Such communication can then be routed to host 151 over the protected connection 144 to achieve end-to-end security for the transmitted communication. Host 151 may use SA 142 instead of SA 141 to carry data packets to host 152 in substantially the same manner.

A host, such as hosts 150,151, may be any device that communicates with other hosts over the network. For example, host 150 and / or host 151 may include a server, a client terminal, or a combination thereof. Hosts 150, 151 may be configured to perform data communication for the purpose of sharing resources in response to service requests, application hosting, and the like. As an example, host 150 may include a client terminal, host 151 may include a server, and host 151 may host an application and respond to application requests from host 150. In another example, hosts 150, 151 may each contain resources such as virtual machines (VMs), storage spaces, processing resources, etc., and dynamically relocate data, applications, etc. over a network connection. obtain.

Security gateways Security gateways such as 110,112 can be any network element located at the edge of a protected network. Element, NE) may be used. The protected network may include protected connections such as protected connections 143,144. Security gateways 110,112 may provide security for communications that pass through any device and / or protected network located within them. Security gateways 110,112 may prevent unauthorized access to the protected network (eg, as a firewall) and may implement security protocols for communication leaving the protected network. For example, if hosts 150 and 151 are located in a data center, respectively, then security gateways 110 and 112 are at the edge of the data center network so that all traffic leaving the protected network passes through gateway 110 and / or gateway 112. May be placed in. Security gateways 110 and 112 receive data from hosts 150 and 151, respectively, and have an IPsec SA over an unprotected network 130 (eg, the Internet). A communication session may be initiated by creating 141,142. Security gateways 110,112 may exchange security keys for the purpose of creating such SAs, eg, by using IKE and / or IKEv2.

IPsec SAs such as SA 141,142 may operate in transport mode or tunnel mode. In transport mode, the payload of the data packet (eg, the actual data being transmitted) may be encrypted, while the header of the data packet containing the data packet routing information may be unencrypted. In tunnel mode, the entire data packet may be encrypted. The SA may also include data and / or algorithms to support Authentication Header (AH) and / or Encapsulating Security Payload (ESP) operations. AH may provide connectionless integrity and data source authentication for data flows. ESPs can provide data packet confidentiality (eg, encapsulation), data source authentication, connectionless integrity, anti-replay services, and flow confidentiality. SA 141 and 142 may each have unidirectionality. From this, SA 141,142 pairs may be required to exchange data packets between security gateways 110,112. In one embodiment, SA 141, 142 may each include an SA bundle. An SA bundle can contain two nested SAs (eg, a tunnel within a tunnel). For example, the SA bundle may include the AH SA within the ESP SA. IPsec security architecture 100 may be restricted to provide a single SA pair and / or a single SA pair bundle (eg, SA 141 and SA 142) for each protected communication between security gateways 110,112. .. Each SA may contain a separate SPI, which may be used as an index in the Security Association Database (SAD) and, in combination with the SA destination address, uniquely identifies the SA. It may be used to determine the encryption key and protocol associated with the SA.

The router 120 may be any NE or group of NEs located in the unprotected network 130. The router may receive the data packet from the security gateway 110 and forward the data packet to the security gateway 112 and vice versa. Router 120 may use Layer 2, Layer 2.5, and / or Layer 3 technology of the OSI reference model to route packets. Router 120 may make routing decisions based on the header of the data packet. If the data packet is encapsulated (for example, in the case of ESP), the routing 120 is based on the header of the encapsulated packet, unaware of the data stored in the header and / or payload of the data packet. You may make a routing decision. Router 120 may provide end-to-end connectivity between security gateway 110 and security gateway 112. Router 120 may provide a single network path for SA 141 and a single network path for SA 142. SA The network path for 141 may or may not be the same as the network path for SA 142.

The IPsec protocol suite specifies an example of the basic architecture 100 for IPsec-compliant systems. The IPsec protocol suite describes, for example, how a set of security services is provided for traffic in both IP version 4 (IPv4) and IP version 6 (IPv6) environments at the IP layer. It is a thing. As mentioned earlier, the IPsec protocol suite defines SA as the concept of IPsec. An SA (eg, SA 141,142) can define a simple connection that can provide security services to the traffic carried by the connection. Security services may be granted to the SA by the use of AH or ESP and may not be provided to a single SA by both. AH and ESP are incorporated in this application by reference in IETF Document RFC 4302 (Non-Patent Document 3) and RFC. Further described in 4303 (Non-Patent Document 4). If both AH and ESP protection are applied to the traffic stream, two SAs may be created and tuned to achieve protection via iterative application of security protocols (eg, nested SAs). .. Since one SA can be used to carry unicast traffic, a pair of SAs (eg, SA 141 and SA 142) can be established as point-to-point communication. Two SAs 141,142 may create one unicast IPsec tunnel between two security gateways 110,112. To distinguish between different SAs, an SPI that can contain 32-bit values may be used by the receiver to identify the SA to which the incoming data packet should be attached. The SPI assignment may be completed by the creator of the SA, which may be the receiver. On the sender side, additional destination IP address information may be used to resolve any SPI conflicts. In this way, the sender may select the appropriate SA under which the IP packet will be processed. In another embodiment, each security gateway 110,112 may assign a local SPI and retain knowledge of the other SPI, respectively. When transmitting the packet, each party (eg, gateway 110 or gateway 112, respectively) may use the SPI of the other party (eg, gateway 112 or gateway 110, respectively) in the data packet header.

Although FIG. 1 only shows that the SA is located between the security gateways 110, 112, hosts such as host 150 and / or host 151, in some embodiments, via the SA, such as gateway 110 and / or gateway 112. You may communicate directly with the gateway of. For example, a client terminal that acts as a host does not have to be located on a protected network. In that case, the client terminal may use the SA to communicate directly with the security gateway over the unprotected network 130.

FIG. 2 is a schematic diagram showing another embodiment of the IPsec security architecture 200. Architecture 200 may include hosts 250,251, protected connections 243,244, security gateways 210,212, and routers 221,222, which are substantially the hosts 150,151, protected connections 143,144, security gateways 110,112, and routers 120, respectively. It may be the same. The security gateways 210,212 may communicate via the SA cluster 241 and the SA cluster 242.

Each SA cluster 241,242 may contain a plurality of parallel sub-SAs. The parallel sub-SA may be a plurality of unidirectional sub-SAs with the same source node (eg, security gateway 210) and the same destination node (eg, security gateway 212), each of which is the same. A portion of the data flow may be transported. For example, SA cluster 241 may include parallel sub SA 241a, 241b, and SA cluster 242 may include parallel sub SA 242a, 242b. SA clusters can differ from SA bundles where sub-SAs can be nested. However, in some embodiments, the sub-SA may include an SA bundle. Although only two sub-SAs are shown per SA cluster, SA clusters 241,242 may contain as many sub-SAs as desired for a particular communication. Sub SAs 241a and 241b may be similar to SA 141, respectively, and sub SAs 242a and 242b are SAs, respectively. It may be similar to 142. However, each sub-SA may only carry and / or encapsulate a portion of the data flow. For example, the security gateway 210 may wish to transmit a data flow containing a plurality of data packets to the security gateway 212 via the SA cluster 241. The security gateway 210 alternates packets between sub SAs 241a and 241b, sends more packets on sub SA 241a than sub SA 241b, divides the flow into separate data packet blocks, and divides the flow between sub SAs 241a and 241b. It is possible to alternate the blocks of. Each sub-SA may have a different SPI, so SA cluster 241 and / or SA cluster 242 may have multiple SPIs. Multiple sub-SAs in an SA cluster may use the same or different routes between security gates. For example, SA cluster 241 has a sub-SA 241a that uses a route through router 221 and a sub-SA that uses a route through router 222, respectively. 241b and may be included. As another example, SA cluster 242 may include sub-SA 242a and sub-SA 242b, both of which use a route through router 221.

Architecture 200 may allow data flows to be split and routed in unpredictable ways by eavesdropping nodes. Since each SA cluster can contain an unknown number of sub-SAs, the eavesdropping node cannot know the exact number of data packets involved in a particular data flow. Furthermore, since each SA cluster can contain multiple SPIs, the eavesdropping node cannot correlate any acquired data packets with each other and cannot determine that multiple data packets are related to the same data flow. In addition, one sub-SA may follow a different network path than another sub-SA, so an eavesdropping node cannot retrieve all of the flow's data packets by monitoring a single network node, and the rest. Unable to determine which other data packets should be monitored to get the data packets. As such, the use of SA cluster 241 and / or SA cluster 242 can add significant uncertainty to the eavesdropping and / or hacking process and thus enhance security on unprotected networks. Also, the ability to send data packets in a parallel sub-SA can optimize transmission. For example, if router 221 becomes congested, outgoing data packets may be moved from sub SA 241a to sub SA 241b without terminating the communication session. In addition, parallel transmission of data flow packets can increase the processing efficiency of the parallel processor compared to the serial processing of data flow packets required by Architecture 100. For example, SA lookup, sequence number generation, and / or anti-replay check may be performed in parallel if the data flow packets are transmitted in parallel.

Architecture 200 may use Abstract Syntax Notation one (ASN.1) to enable the creation and use of SA clusters. The following ASN.1 definition creates SA clusters (eg SA cluster 241 and / or SA cluster 242) based on the number of sub SAs (eg, sub SA 241a, 241b or sub SA 242a, 242b, respectively). It may be for selecting an appropriate sub-SA for sub-flow transmission.

Processing :: = SEQUENCE { extSeqNum BOOLEAN, --TRUE 64 bit counter, FALSE 32 bit seqOverflow BOOLEAN, --TRUE rekey, FALSE terminate &amp; audit fragCheck BOOLEAN, --TRUE stateful fragment checking, --FALSE no stateful fragment checking lifetime SALifetime, spi Manual SPI, algorithms ProcessingAlgs, tunnel TunnelOptions OPTIONAL, --if absent, use transport mode saCount INTEGER OPTIONAL, --if absent, use 1 selectSA SASelAlgoType OPTIONAL --ignored if saCount is 1, --if absent, use round-robin } SASelAlgoType :: = INTEGER { round-robin (0), random (1), others (2) }

In one definition, the extSeqNum, seqOverflow, and fragCheck attributes can be logical values (for example, they can contain true or false values) and the entity creating the SA cluster is a 64-bit counter. Or a 32-bit counter, whether to rekey or terminate the key to the cluster if the sequence number overflows, and whether or not to perform a stateful check on flow fragmentation, respectively. Can be set to indicate whether it should be set. The lifetime attribute may indicate the lifetime of the SA cluster and / or a particular sub-SA, where the lifetime is without the SA cluster and / or sub-SA receiving and / or transmitting data. It can be the time you can be active. SA clusters may be configured to not time out. The spi attribute may be used by the administrator to manually set the SPI value and may be ignored if the SPI value is automatically generated. The algorithms attribute may indicate other processing algorithms used to create and / or use SA clusters and / or sub-SAs. The tunnel attribute can be used to indicate whether the SA cluster and / or sub-SA use tunnel mode and / or transport mode and any options associated with tunnel mode. The saCount attribute may be a variable and may be set to an integer or other value indicating the number of sub-SAs created for the SA cluster. The selectSA attribute may be a variable and may be set to an integer or other value corresponding to SASelAlgoType. The selectSA may be used by the sender to select a subSA for the transmission of a particular subflow. SASelAlgoType can be a variable and may be set to an integer or other value to indicate a particular selection algorithm. For example, SASelAlgoType is Lau A value of "0" for the undrobin selection algorithm, a value of "1" for the random selection algorithm, other selection algorithms (eg, user-defined, SA path delay-based allocation), and service quality guaranteed SA paths. It may be set to another value indicating (based allocation). Round robin may be a selection algorithm that assigns equal parts of the data flow to each sub SA.

Data confidentiality can protect transmitted data from passive attacks such as eavesdropping. In an IPsec implementation (eg, Architecture 100), all IP datagrams may be transmitted within an IPsec tunnel and may be provided with protection by one SA. To improve confidential security services, a set of SAs (eg, Sub SA 241a, Sub SA 241b, Sub SA 242a, and / or Sub SA 242b) may be used to protect traffic. Multiple tunnels may be set up between two entities and then clustered together to form a single clustered tunnel (eg, SA cluster 241 and / or SA cluster 242). One IP packet can still be protected by a single SA. The sending entity may split the traffic into all these sub-SAs. The receiving entity can multiplex traffic from multiple IPsec tunnels. Tunnels clustered together may be referred to as subtunnels. The SA for the subtunnel may be referred to as the subSA. IP traffic that can be protected within a clustered tunnel may be split into all subtunnels. The term SA cluster may be used to describe a combination of SAs whose traffic must be processed to meet a security policy. Physical paths can be different because multiple subtunnels are set up in the same flow of traffic between two protected entities. The processing order of these clustered SAs can be a local issue as all these SAs may or may not be nested in the SA.

Note that SA clustering may be performed by the sender and that the receiving entity may be aware of the existence of the SA cluster at the IP layer. For example, traffic multiplexing can be performed by upper layer processes and directly by IPsec processes, as the receiver cannot have a mechanism to correlate SA cluster traffic through multiple subSAs at the IP layer. Absent. However, the upper layer process may use other methods of collecting multiplexed traffic (eg, correlating sequence numbers associated with the upper layer process with each other).

Sub-SAs may have their own soft and hard lifetime if negotiated through IKE negotiations. However, it does not have to have a lifetime for the SA cluster. Architecture 200 cannot change the sustainability of each sub-SA. If one sub-SA becomes invalid (eg, due to a timeout), such sub-SA cannot be used for further packet processing. If an SA cluster no longer holds a valid sub-SA, it may be disabled.

FIG. 3 is a flow chart showing an embodiment of the method 300 for creating an SA cluster. In method 300, a NE such as security gateway 210 and / or security gateway 212 may receive a request (eg, from host 240) in step 310 and establish an SA with another NE such as security gateway 212. At step 312, method 300 may search for a security policy for the SA. The security policy may be stored on a security policy database (SPD) that may be located on the NE and / or may be accessed by other NEs such as the management NE. The security policy may be used to determine the processing parameters and / or cryptographic key material that will be associated with the SA. At step 314, method 300 may check the security policy to determine if the saCount variable is present. Method 300 may proceed to step 316 if the saCount variable is not present and to step 320 if the SACount variable is present.

In step 316, the saCount variable does not exist, which can mean that a single SA (eg, SA 141) is specified by the security policy. From this, method 300 may create an SA and proceed to step 318 to terminate the operation, for example by using IKE and / or IKEv2.

At step 320, the saCount variable is present, which can mean that SA clustering is specified in the security policy. The value of the saCount variable may indicate the number of sub-SAs in the SA cluster. If the value of the saCount variable is not greater than or equal to 1, method 300 proceeds to step 322 and may return an error as the cluster requires at least one sub-SA. If the value of saCount is greater than or equal to 1, method 300 may proceed to step 324. At step 324, the method may create a count variable and set the value of the count variable to be equal to the value of the saCount variable. At step 326, method 300 may create a sub-SA (eg, by using IKE and / or IKEv2). At step 328, the value of the count variable can be decremented by 1. At step 330, method 300 may determine if the value of the count variable is greater than zero. If the value of the count variable remains greater than zero, method 300 may return to step 326 and create additional SAs as indicated by the value of the count variable. If the value of the count variable reaches zero in step 330, method 300 may proceed to step 318 to end the operation. In this way, sub-SAs may be created based on the security policy and added to the SA cluster.

As mentioned earlier, an SA cluster setup may include multiple sub-SA setups. Subtunnels may be configured independently. After setup, subtunnels can be added one by one to the cluster. The exact way to add a sub-SA to an SA cluster can be a local issue. All cooperating subtunnels may contain different SPI values. There is no limit to how many subtunnels are used for one clustered tunnel. Both the sending and receiving entities may agree on the SA cluster specification before any IPsec traffic is sent through any of the subtunnels. A new sub-SA can be set up and join an SA cluster even after traffic begins to flow into the clustered tunnel. Even if the subtunnels are independent, they may share one sequence number source. Each IPsec packet carried within a clustered tunnel may have a uniquely defined sequence number.

All subtunnels may be set up independently. Traffic through different subtunnels may use the same route. Also, the traffic may use different routes based on the routing policy, for example, by using multiple routes of equal cost. If the SA cluster contains only one sub-SA, the SA cluster is fully interoperable with the IPsec implementation under architecture 100 if the device designed for architecture 100 does not support the SA cluster. It may be.

FIG. 4 is a flow diagram illustrating an embodiment of Method 400 for selecting a sub SA for a data subflow. At step 410, outgoing packets may be received, for example, by security gateway 210 and / or security gateway 212. At step 412, method 400 may query the SPD to find an SPD entry that matches the flow to which the packet from step 410 belongs. At step 414, method 400 may determine if the saCount value stored in the SPD entry is greater than 1. The method may proceed to step 418 if the saCount value is not greater than 1 and to step 416 if the saCount value is greater than 1. At step 418, method 400 may query the SA database (SAD) using the SA's SPI and flow information to find data for SA encapsulation and / or transmission. If the count value is less than or equal to 1, then only one SA may be present and no SA selection may be required. If the count value is greater than 1, in step 416, method 400 may select a sub-SA for the sub-flow according to a sub-SA selection algorithm (eg, selectSA and / or SASelAlgoType). Once the sub-SA is selected, the method can proceed to step 418 and query the SAD using the SPI of the selected sub-SA. In this method, flow data packets may be distributed between sub-SAs by using a selection algorithm. As mentioned earlier, the selection algorithm may alternate packets between sub-SAs for both efficiency and security reasons of data traffic.

As mentioned above, the sending entity may split and / or alter IPsec traffic through multiple subtunnels. If the SA cluster is selected for traffic processing based on the security policy settings, one sub-SA may be selected for outbound IPsec processing of the specified packet. The local implementation can determine which SA should be applied to the specified IP packet. Other processing procedures related to Architecture 100 may remain unchanged, except that the sequence number can be shared by all sub-SAs. The local implementation in the sending entity may choose any method for retrieving the sequence number of the packet and may be independent of the choice of sub-SA. In an alternative embodiment, each sub-SA may generate its own sequence number and may not require sharing of the sequence number between the sub-SAs.

FIG. 5 is a flow chart showing an embodiment of the method 500 for receiving data via the SA cluster. Anti-replay is a feature of IPsec and may be used to prevent a receiving NE from processing the same packet multiple times. When a single SA is used, the packets may be received in order and the receiving NE discards the newly received packet with a sequence number lower than the sequence number of the last received packet. Can be allowed. If SA clusters are used, packets may be sent in parallel. For this reason, data packets cannot be received in order when shared sequence numbers are used. Method 500 may be used to implement anti-replay functionality when using SA clusters through the use of anti-replay bitmaps.

At step 510, the received packet may be received, for example, by the security gateway 210 and / or the security gateway 212. At step 512, the method may determine whether anti-replay is used by the SA, for example by querying the SPD using SPI. If anti-replay is not used for SA, method 500 may proceed to step 514 to process the packet. If anti-replay is used, method 500 may proceed to step 516. At step 516, method 500 may obtain the sequence number of the data packet and compare that sequence number with the anti-replay bitmap. For example, the anti-replay bitmap is set to a corresponding value (eg, a value "0", a value "1", or a combination thereof, respectively, to indicate whether or not a packet corresponding to the sequence number has been received. May include all available sequence numbers with). At step 518, method 500 may determine if the sequence number is set in the replay bitmap. If the sequence number is set (eg, to the value "1"), the method determines that a packet with that sequence number has already been received and can proceed to step 520 to discard the packet. If the sequence number is not set (eg, to the value "1"), the method may determine that no packet with that sequence number has been received and proceed to step 522. At step 522, the method updates the anti-replay bitmap (eg, by setting the corresponding value to the value "0") to indicate that the packet associated with that sequence number is being received. obtain. Method 500 can then proceed to step 514 to process the packet.

As mentioned earlier, the selection of the receiving sub-SA may be done in a process similar to the selection of a single SA, both of which may be based on SPI and IP address information. Other aspects may remain unchanged, except for changes to the processing of sequence numbers. The use of multiple subtunnels can cause the delivery order of IPsec packets to be out of order for a protected communication channel between two entities. As a workaround, the sequence number in the IPsec header of the data packet can be used when the receiving entity needs to maintain the transmission order. When anti-replay is enabled, all subtunnels may use one shared anti-replay bitmap on the receiving entity. Anti-replay checks may be completed for SA clusters instead of specific sub-SAs.

Multipath solutions introduce the problem of out-of-order delivery, but this out-of-order problem can also occur in a single SA. The reordering process is similar to TCP reordering and / or IP reassembly, with aggregate nodes and / or end hosts (eg, hosts 240 and / or hosts) based on the topology of a particular network. It may be completed in 241).

Figure 6 shows Security Gateway 110, Security Gateway 112, Security Gateway 210, and / or Security Gateway 212, Host 140, Host 141, Host 240, and / or Host 241, and / or Router 120, Router 221, and / or. FIG. 5 is a schematic diagram illustrating an embodiment of a network element (NE) 600 that may include a router 222. Those skilled in the art will recognize that the term NE includes a wide range of devices for which NE 600 is just one example. NE 600 is described for the purpose of clarity of description and does not imply limiting the use of the present disclosure to a particular NE embodiment or class of embodiments. Data from at least some of the features / methods described herein, eg, method 300 for creating SA clusters, method 400 for selecting sub-SAs for subflows, and / or SA clusters. How to receive 500, NE It may be implemented as a whole or part of a network device or component such as 600. For example, the features / methods of the present disclosure may be implemented using hardware, firmware, and / or software installed to run on the hardware. The NE 600 may be any device that carries frames over the network, such as switches, routers, bridges, servers, clients, and so on. As shown in FIG. 6, the NE 600 may include a transceiver (Tx / Rx) 610 which can be a transmitter, a receiver, or a combination thereof. The Tx / Rx 610 may be connected to multiple downstream ports 620 for sending and / or receiving frames from other nodes, and the Tx / Rx 610 may send and / or send frames from other nodes. Alternatively, it may be connected to a plurality of upstream ports 650 for receiving. Processor 630 is Tx / Rx to process the frame and / or to determine which node to send the frame to. May be connected to 610. The processor 630 may include one or more multi-core processors and / or a memory device 632 that may function as a data storage, buffer, etc. The processor 630 may be implemented as a general purpose processor or may be part of one or more application specific integrated circuits (ASICs) and / or digital signal processors (DSPs). Good. Downstream port 620 and / or upstream port 650 may include electrical and / or optical transmit and / or receive components. The NE 600 may or may not be a routing component that makes routing decisions.

By programming and / or loading executable instructions into the NE 600, at least one of the processor 630, downstream port 620, Tx / Rx 610, memory 632, and / or upstream port 650 has been modified. NE to a particular machine or device, eg, a multi-core transfer architecture, with new features suggested by the disclosure Note that the 600 will be partially modified. It is a fundamental matter in the fields of electrical engineering and software engineering that the functionality that can be implemented by loading executable software into a computer can be converted into hardware embodiments by known design rules. Typically, the decision to implement as software or as hardware considers the design stability and quantity of the units produced, rather than any problems caused by the conversion from the software domain to the hardware domain. It is done. In general, hardware implementation changes are more expensive than software design changes, so frequently changed designs are preferably implemented as software. In general, for large-scale production, hardware implementation can be cheaper than software implementation, so designs that are determined to be mass-produced are preferably implemented as hardware, eg, ASICs. Designs are often developed in software form, tested, and then transformed by known design rules into a uniform wiring circuit implementation of application-specific integrated circuits with software instructions as hardwires. Will be done. Just as a machine controlled by a new ASIC is a particular machine or device, a computer that has programmed and / or loaded executable instructions can also be considered a particular machine or device.

At least one embodiment is disclosed, and variations, combinations, and / or modifications of (s) embodiments made by persons of ordinary skill in the art, and / or features of the embodiment (s). , Within the scope of this disclosure. Modifications that result from the combination, integration, and / or omission of features of the embodiments are also within the scope of this disclosure. Where a range or limitation of numbers is explicitly indicated, such an explicit range or limitation includes a repeating range or limitation of size that falls within the clearly indicated range or limitation (eg, about). It should be understood that 1 to about 10 includes 2, 3, 4, etc., and exceeding 0.10 includes 0.11, 0.12, 0.13, etc.). For example, when the numerical range of the lower limit R1 and the upper limit R2 is disclosed, strictly speaking, all the numerical values within the range are disclosed. More specifically, the numbers in the range R = R1 + k * (Ru-R1) are clearly disclosed. Where k is a variable in the range of 1 percent to 100 percent in 1 percent increments, i.e. k is 1 percent, 2 percent, 3 percent, 4 percent, 5 percent, ..., 70. Percentage, 71%, 72%, ..., 95%, 96%, 97%, 98%, 99%, or 100%. In addition, any numerical range defined by the two numbers R as described above is also explicitly disclosed. The use of the word "about" means ± 10% of the number that follows, unless otherwise stated. The use of the word "optionally" for any element in a claim means that the element is required or not required, and both options are patent claims. It is within the range. Comprise, include, have The use of broader words such as and having should be understood to include narrower words such as consisting, essentially of, and complemented substantially of. .. Therefore, the scope of protection is not limited by the contents described above, but is defined by the appended claims and includes all equivalents of the subject matter of the claims. Each and all claims are incorporated as further disclosure herein, and the claims are also embodiments of the present disclosure. The description of the disclosed reference does not acknowledge that it is prior art, in particular any reference having an issue date after the priority date of the present application. The disclosures of all patents, patent applications, and publications cited in this disclosure are disclosed by reference as they provide an exemplary, procedural, or other detailed supplement to this disclosure. It is used for.

Although some embodiments are provided in this disclosure, it is understood that the disclosed systems and methods may be implemented in many other specific embodiments without departing from the spirit or scope of this disclosure. Will be done. This example is intended for illustration only and is not intended to be limiting, the intent of which is not limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or some features may be omitted or not implemented.

Moreover, the techniques, systems and methods described and exemplified as various embodiments individually or separately are combined with other systems, modules, techniques or methods without departing from the scope of the present disclosure. Or may be integrated. Other elements that are connected to each other, directly connected to each other, or shown or described to communicate are any interfaces, devices, whether electrical, mechanical, or otherwise. Alternatively, they may be indirectly connected or communicated via intermediate components. Other examples of alterations, substitutions, and substitutions are identifiable by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

100 IPsec Security Architecture 110,112,210,212 Security gateway 120,221,222 router 130 networks 141,142 Unidirectional Security Association 143,144,243,244 Protected connection 150,151,250,251 host 241,242 Security Association Cluster 241a, 241b, 242a, 242b Parallel Subsecurity Association 600 network elements 610 transceiver 620 downstream port 630 processor 632 memory 650 upstream port