IPSec Cluster
In the LTE scenario, traffic from a base station is transmitted between an insecure transport network and a secure core network. An IPSec gateway needs to be deployed on the border of the core network to protect traffic, and traffic is transmitted through the IPSec tunnel established between the base station and IPSec gateway. The problem is that there are too many base stations in the LTE scenario, and each base station carries heavy traffic with the 4G service development.
One IPSec gateway has limited performance and cannot transmit traffic from all base stations. Therefore, multiple IPSec gateways need to be deployed to provide sufficient bandwidth for VPN traffic on the IPSec tunnels. The numbers of access users on base stations are variable, so some IPSec gateways may be overweighted and fail to establish new IPSec tunnels, and some IPSec gateways are not fully used. The IPSec cluster addresses this problem.
An IPSec cluster is a group of associated IPSec gateways and the IPSec cluster is equivalent to a virtual device. Base stations negotiate with the IPSec cluster for establishing IPSec tunnels, and they do not need to know the IPSec gateway with which they establish IPSec tunnels. The IPSec cluster can select one gateway to respond to IPSec negotiation requests from the base stations based on the load.
Figure 1 shows a typical application of the IPSec cluster.
The device can function as the IPSec responder to perform negotiation with a base station that acts as an IPSec initiator.
The implementation of the IPSec cluster requires the support for VRRP, IPSec, IKEv2 redirection, IPSec route injection, and remote disaster recovery.
VRRP
VRRP is responsible for selecting the master gateway in the IPSec cluster.
IKEv2 redirection
An IPSec cluster corresponds to an IKEv2 redirection group, and IKEv2 advertises a virtual server IP address. The VRRP virtual IP address (VIP) is set to the external server IP address of an IKEv2 redirection group, and the VRRP group and IKEv2 redirection group are associated.
An IPSec cluster contains the master gateway and other member gateways. The master gateway is responsible for managing members, and member gateways periodically send load information to the master gateway. The master gateway calculates the IPSec gateway with the minimum load based on the load of all member gateways.
IKEv2 redirection, as defined by RFC 5685, allows the device to redirect IPSec tunnel requests in IKE_SA_INIT and IKE_AUTH phases.
IPSec route injection
IPSec route injection ensures that traffic is correctly routed to IPSec tunnels.
Remote disaster recovery
A base station can initiate tunnel negotiation to multiple IPSec clusters, and the remote IPSec cluster is used to implement disaster recovery.
The device provides VRRP and IPSec route injection, and remote disaster recovery is implemented on a base station and is not described in detail here. The following describes the implementation of IKEv2 redirection.
IKEv2 SA negotiation is completed in the initial exchange. This initial exchange includes the IKE_SA_INIT exchange to negotiate the IKE SA and the IKE_AUTH exchange to negotiate a pair of child SAs. IKEv2 redirection can be implemented in the IKE_SA_INIT or IKE_AUTH exchange phase.
Redirection in the IKE_SA_INIT Exchange Phase
- A base station sends an IKE_SA_INIT request packet to the IKEv2 redirection group (sent to the master gateway). If the base station supports IKEv2, the IKE_SA_INIT request packet carries the REDIRECT_SUPPORTED notification message. This packet also carries a nonce value as in a normal IKE_SA_INIT request packet.
- The master gateway calculates the load and finds out the gateway with the minimum load. The master gateway sends an IKE_SA_INIT response packet to the base station, carrying the REDIRECT notification message. This notification message contains the new IPSec gateway address (if the master gateway has the minimum load, redirection does not occur) and the nonce value obtained from the IKE_SA_INIT request packet.
- After receiving the IKE_SA_INIT response packet from the master gateway, the base station checks whether the received nonce value is the one carried in its own IKE_SA_INIT request packet. If not, the base station discards the response packet and waits for the next one. If so, the base station sends an IKE_SA_INIT request packet that carries the REDIRECTED_FROM notification message to the new IPSec gateway.
- The new IPSec gateway responds to the base station's IKE negotiation request normally and completes IKE SA and child SA negotiation with the base station.
Redirection in the IKE_AUTH Exchange Phase
- A base station sends an IKE_SA_INIT request packet to the IKEv2 redirection group (sent to the master gateway). If the base station supports IKEv2, the IKE_SA_INIT request packet carries the REDIRECT_SUPPORTED notification message.
- The master gateway calculates the load and finds out the gateway with the minimum load. The master gateway and base station complete the IKE_SA_INIT exchange and establish the IKE SA. The IKE_AUTH response packet carries the REDIRECT notification message, which contains the new IPSec gateway address (if the master gateway has the minimum load, redirection does not occur).
The base station receives the IKE_AUTH response packet from the original IPSec gateway. The base station receives the authentication payload before redirection payload, authenticates the master gateway, sends the deletion message, and deletes the established IKE SA. IPSec redirection is then performed since the master gateway has been authenticated.
In the IKEv2 redirection scenario, the FW does not support EAP authentication.
- The base station sends an IKE_SA_INIT request packet that carries the REDIRECTED_FROM notification message to the new IPSec gateway.
- The new IPSec gateway responds to the base station's IKE negotiation request normally and completes IKE SA and child SA negotiation with the base station.