Decoupled control and data plane synchronization for IPSEC geographic redundancy

Embodiments disclosed herein relate to systems and methods for separately managing control and data plan contexts for a secure connection during a standby node switchover scenario. Primary and standby nodes for a secure connection can both maintain a data plane context for a secure connection such as IPSec. In the event that the primary node becomes inactive, the standby node can immediately begin processing data plane traffic using the data plane context for the secure connection maintained at the standby node. Control plane information necessary for programming and activating a control plane context can be stored until needed. During a switchover, the standby node can retrieve the control plane information and activate the control plane context after it has begun processing the data plane traffic.

TECHNICAL FIELD

The present disclosure relates to systems and methods for controlling control plane and data plane traffic in a mobile network, and in particular systems and methods for decoupling control and data plane synchronization for Internet Protocol Security (IPsec) geographic redundancy.

BACKGROUND

Stateful geographic redundancy for network elements such as VPN gateways and ePDG, that terminate IPsec tunnels, requires synchronization of a large amount of long-lasting, per-tunnel state information between the active and standby nodes. During a network anomaly, for example, an active node may fail and the state of the user's session must be recovered at a standby node, which switches to an active role. When the standby node switches to an active role, it needs to program and activate various control and data-path functionalities as quickly as possible. For a security gateway with large number of active tunnels, this programming phase can be inefficient and can take several seconds, leading to extended packet losses from which applications might not be able to recover. In some existing recovery solutions, standby nodes may store both control plane and data plane information. During a network anomaly, both control plane and data plane functionality must be programmed and activated, leading to long recovery times. On the other hand, maintaining “live” session information for both control plane and plane at a standby node is resource intensive for processors and memory. Other recovery solutions employ a prioritization scheme that may recover certain prioritized sessions before recovering other, lower priority sessions, thus minimizing the impact of long recovery times. IPsec state synchronization techniques that are explicitly designed for and take advantage of cloud-native or control/data plane separation architectures to improve efficient recovery and minimize interruptions to user plane activity are lacking.

DETAILED DESCRIPTION

The present disclosure describes systems and methods for explicitly decoupling control-plane state synchronization from data-plane state synchronization. A subset of the state parameters synchronized between active and standby nodes are essential for data-path packet processing functions, i.e. encryption and decryption of packets, whereas the remainder of the state parameters are needed for control-plane functions such as rekeying of phase-1 and phase-2 tunnels, dead-peer detection, SPI assignment, Mobility and Multihoming Protocol (“MOBIKE”) support, etc. As tunnels are added on the active node, both data-plane and control-plane state information related to the tunnels can be synchronized to their respective standby locations in the network. Standby nodes will receive information related to the active tunnel control plane and active data plane from the active node. This information can be used by the standby node to replicate the tunnel that is at the active node. In some embodiments (e.g. cloud native applications), the control plane data can be stored in an external database.

In some embodiments only the data-plane component is programmed so that it can start processing packets as soon as a switchover is triggered. The information necessary to program and activate the control plane component is stored until the switchover is triggered. Programming can mean establishing a data channel that is immediately capable of processing data even though the data channel may not necessarily be actively processing data yet. Once the data-plane component is programmed at the standby node, the standby node is ready to process data associated with the active tunnel in the event the active node becomes unavailable.

In some embodiments, a switchover can be triggered by a network-anomaly. For example, a standby node can detect that the active node is no longer active by monitoring interfaces (e.g. BGP peering interfaces) connected to the standby node. The standby node can infer that the active node is no longer active based on the communication link with the active node. For example, if the activity on the link indicates that the active node is inactive, the standby node can infer that a network anomaly has occurred and begin the switchover process. The standby node can also detect that the active node is no longer active if it receives traffic that would otherwise be handled by the primary node. In some embodiments, the standby node can detect that the primary node is inactive by monitoring route weights managed by decentralized route optimization techniques. For example, an active primary node may report that its route cost is 5, while a standby node may report that its route cost is 10. In this first state, traffic is routed through the active primary node because its route cost is lower than the standby node. If the primary node is no longer active, its route cost may become 100. In this scenario, the standby node becomes the preferred route because its route cost is lower. In some embodiments, a switchover can be manually triggered (e.g. by direct communication via the EMS). After a switchover is triggered, the control-plane state can then be retrieved from the database and programmed on the standby control-node. Since the data-plane component was already programmed, data-packet processing can begin immediately and is not be delayed by the amount of time need to restore the control plane component. That is, control plane resources can be recovered at the standby node after the standby node begins processing data packets over the data-plane. Control plane information (e.g. encryption keys, transforms, and other information on how to decrypt control packets) may be compressed and/or stored during the standby state which also prevents control-plane resources from being wasted due to allocation and blocking before they are really used.

Also, as described in more detail below, the decoupled synchronization described herein fits naturally in a control/data plane split architecture where there might be one or more control plane nodes separate from one or more data-plane nodes. In such an architecture, all the standby data-plane nodes can always be kept ready by programming them with the cryptographic keys needed for IPsec operation. Thus, the switchover time is only limited by the routing convergence time as all elements of the distributed data plane would be ready to process the incoming IPsec packets. In addition, the stack and resources (e.g. storage and processing resources) on the control-plane node(s) can be engaged only when they are actually needed. The state information can be stored until then in a database. In some embodiments, the state information can, be stored on an external database.

One advantage of a decoupled synchronization approach is that it can naturally fit and scale to the needs of a control-plane/user-plane split architecture. In some embodiments, the separation of control plane and data plane information allows one control plane to be associated with more than one data plane. In deployments with one control-plane element and several data-plane elements, only data-plane state needs to be synchronized to the data-plane elements. In addition, since data-plane state and control-plane state is needed at different points of time during a network-anomaly triggered switchover between standby to active roles, resources can be conserved, and session restoration time can be improved. The control-plane state can be stored in an external database until the state is actually needed. In some embodiments, the control plane information is stored in a common database that is accessible to both the primary and standby nodes. In this example, the primary node may store the control plane information at the common database. In a switchover scenario, the standby database can retrieve the control plane information that was previously stored by the primary node in the common database. In another embodiment, the standby node is configured to receive the control plane information from the primary node and can store it either locally or in an external database. The external database may be any database that is accessible to the standby node.

FIG. 1is a system diagram showing a geo-redundant networked system, according to some embodiments. In this example, a secure connection is being established between network nodes (VePDG102and VePDG104) and a user over an untrusted WiFi network (WLAN108). The secure connection is used to bridge a connection over the untrusted connection with WLAN108. The geo-redundant networked system includes primary virtualized Evolved Packet Data Gateway (VePDG)102, standby VePDG104, packet data network gateway (PGW)106, wireless local area network (WLAN)108, other mobile network modules110, mobile device112, element management system (EMS)114, and geolink116. It should be understood that the example illustrated inFIG. 1using VePDG nodes is non-limiting. This system can also be implemented in any other system node that provides an IPSec connection or similar secure connection. For example, the primary and standby nodes can be VPN or enterprise VPN nodes that provide VPN functionality over IPsec tunnels. It should also be understood that the methods and systems described herein may apply to future generations of communications networks. For example, the methods and systems described herein can be applied to 5G cellular networks. In one such embodiment, the primary and standby nodes can comprise N3IWF nodes.

VePDG102is a gateway for voice and data traffic using untrusted (e.g. unencrypted) access (e.g. open WiFi or the equivalent). VePDG102connects to a mobile device112via SWu, which is a logical interface toward user equipment (UE). VePDG102communicates with an access network (e.g., WLAN108) through SWn. VePDG102is the primary node and remains active until such time its responsibilities need to be transferred to a backup node. This transfer can result from a failure or other error associated with VePDG102. It can also occur as the result of an instruction from an operator or the EMS114. VePDG102can track states of both the control plane and the data plane.

VePDG104is a gateway for voice and data traffic using untrusted (e.g. unencrypted) access (e.g. open WiFi or the equivalent). VePDG104connects to a mobile device112via SWu, which is a logical interface toward user equipment (UE). VePDG104communicates with an access network (e.g., WLAN108) through SWn. VePDG104is a secondary node and remains in standby until such time it needs to take over the responsibilities of an active node. This transfer can result from a failure or other error associated with a primary node. It can also occur as the result of an instruction from an operator or the EMS114. VePDG104can track states of both the control plane and the data plane.

In some embodiments, the states are associated per-geo node. They are effectively “active” (e.g., the node owns the current control and data plane user sessions) or “standby” (e.g., the node is told the current control and data plane sessions). The transition between states according to some embodiments is shown and described inFIG. 4and its accompanying text.

VePDG102and VePDG104can also communicate with PGW106via S2b, which is an interface toward PGW.

VePDG102and VePDG104can also communicate with other mobile network modules110via SWm, which is an interface toward 3GPP AAA server. Other mobile network modules can include a Charging Function (CGF)/Online Charging System (OCS)/Offline Charging System (OFCS) (for charging), a Policy and Charging Rules Function (PCRF) (for policy), and a Diameter Routing Agent (DRA) or Authentication, Authorization and Accounting (AAA) (for user authentication).

EMS114can be used to guarantee configuration consistency between the geo-graphically separate nodes. In some embodiments, this assures that the standby geo-node has all of the network connectivity and configuration necessary to take over the control and data plane sessions from the active geo-node. For example, network connectivity and configuration can include details about hostname, IP addresses, port numbers, and name spaces of local entities as well as external servers. In some embodiments, the consistency can be guaranteed by the operator via other mechanisms. For example, an operator can manually log in to the command line interface of the active and standby nodes to configure them identically.

Geolink116is a communication protocol between VePDG102and VePDG104to transfer and to synchronize state information. In some embodiments, Geolink116can comprise a proprietary communication protocol that simulates a replicated database. For example, the Geolink116can be implemented using a proprietary messaging mechanism that communicates information from one process to one or more processes. For example, the messaging mechanism can use a separate channel for each unique category of information. In an IPSec connection, two separate channels can be used to communicate information from an active geo-node to a standby geo-node: one for control plane information and one for data plane information.

FIG. 2is a system diagram showing a geo-redundant networked system, according to some embodiments. In this example, a secure connection is established between the network nodes (primary and standby) and an enterprise network that is accessible over the Internet. Since the Internet connection may be insecure, the secure connection is used to bridge the untrusted connection over the Internet. The geo-redundant networked system includes primary node202, standby node204, Enterprise Network206, Radio Access Network (RAN)208, other mobile network modules210, mobile device212, element management system (EMS)214, and geolink216. The RAN208could be any other access network. For example, RAN208could also be a WLAN connection. Primary node202and Standby node204can be any of an SAEGW, PGW, GDSN, or similar network node.

Primary node202is a gateway for communicating (via e.g. an SGi interface) with an enterprise network that is accessible over the Internet. Primary node102connects to a mobile device212via S1-U, which is a logical interface toward user equipment (UE). Primary node202also communicates with an access network (e.g., RAN208) S1-U. Primary node202remains active until such time its responsibilities need to be transferred to a backup or standby node. This transfer can result from a failure or other error associated with primary node202. Primary node202can track states of both the control plane and the data plane.

Standby node204is a gateway for communicating (via e.g. an SGi interface) with an enterprise network that is accessible over the Internet. Standby node104connects to a mobile device212via S1-U, which is a logical interface toward user equipment (UE). Standby node204communicates with an access network (e.g., RAN208) through S1-U. Standby node104is a secondary node and remains in standby until such time it needs to take over the responsibilities of an active node. This transfer can result from a failure or other error associated with a primary node. Standby node104can track states of both the control plane and the data plane. Primary node102and Standby node104can also communicate with an Enterprise Network206via SGi, which is an interface toward the Enterprise Network.

FIG. 3is a diagram showing an active geo-node and a standby geo-node, according to some embodiments. In some embodiments, the active geo-node302can correspond to VePDG102and the standby geo-node312can correspond to VePDG104. In other embodiments, active geo-node302and standby geo-node312can correspond to primary node202and standby node204, respectively.

The active geo-node302includes an active control plane304and active data plane310. The active geo-node302communicates with standby geo-node312via a pathway defined by geo-server endpoint308, geo-link322, and geo-client endpoint318. Information sent over the pathway includes geo-redundancy control information (between geo-redundancy managers), user control data (from active database on active geo-node to standby database on standby geo-node), and user data plane state (from active database on active geo-node to active database on standby geo-node). The standby geo-node312may store any user control data received from the active geo-node302in control plane state database314. In some embodiments (not shown), control plane database may be external to the standby geo-node312.

FIG. 4is a flowchart showing a transition between active and standby states, according to some embodiments.

From a transitional perspective, the data planes on both the active and standby geo-nodes are both actually active from an operational perspective. In other words, the standby geo-node is as capable of handling user data as the active geo-node. In some embodiments, this is referred to as hot-staging of data resources. The control plane, on the other hand, transitions from “standby” to “state recovery”, and then from “state recovery” to “active”. During the transitions, control plane interruptions may occur. Not until the state is active does full control plane functionality recover.Geo Node: Standby→activeData plane: No transitionControl plane: Standby→state recovery→active

In some embodiments, when a node transitions from active to standby, user data is purged and starts fresh again (as if the standby geo-node were coming up for the first time). The old data is purged and then is synchronized with the active geo-redundant node to recover the current state data. Note that the data plane transitions to active (e.g., ready to handle data) while the control plane is in standby (e.g., control data is in a database).Geo Node: Active→standbyData plane: active→state purge→synchronization→activeControl plane: active→state purge→synchronization→standby

FIG. 5is a flowchart showing data plane and control plane state replication and switchover, according to some embodiments.

Referring to step502, a session is established on VePDG102. Referring to step504, data plane state is mirrored to VePDG104and necessary resources allocated and programmed (e.g., data-plane active state). For example, the resources include parameters such as IP address, Security Policy Indexes (SPIs), encryption and decryption algorithms and negotiated encryption and decryption keys for each IPsec session. In some embodiments, this process is repeated at a set time interval or upon receiving instruction to repeat the process.

Referring to step506, control plane state is sent to VePDG104and state information is stored in a database. In some embodiments, this process is repeated at a set time interval or upon receiving instruction to repeat the process. Referring to step508, VePDG102experiences failure. Referring to step510, Geo Manager or EMS detects failure and initiates VePDG104transition to active. In some embodiments, this transition to active occurs as soon as possible after the failure. In some embodiments, the transition duration depends on multiple factors (e.g., error detection, fault propagation), and in some embodiments is measured in seconds. Referring to step512, after VePDG104has been transitioned to active, packets arrive at VePDG104and are processed successfully (e.g., data-plane active).

Referring to step514, VePDG104control plane reads from the control plane database and rebuilds control plane state. From the control plane database, information about each IKE SA (security association) and IPSEC SA can be gathered. Information gathered can include remote IP address, SPIs used, encryption algorithms, time of last rekey, message sequence numbers, etc. Associations between IKE and IPSEC SA can also be built at this time. Rule lookup data-structures are also built at this time which can be very CPU intensive for a large number of tunnels. Note that no data-plane activity is required during this process and data flow is not interrupted. The control-plane rebuild process can introduce delay but will complete before the remote end to clears the tunnel due to timeout of control-plane messages. Referring to step516, VePDG104ensures control plane and data-plane consistency and transitions to Active.