455
4. The GM verifies the IPsec policy. If the IPsec policy settings are acceptable, for example, the
security protocols and encryption algorithms are supported, the GM sends an acknowledge
message to the KS.
5. After the KS receives the acknowledge message, it sends KEK and TEK messages to the GM.
The GM uses the obtained IPsec policy and keys to encrypt and de-encrypt data.
A GM starts a GDOI registration timer when it initiates a registration to the KS. If the GM does not
successfully register with the KS before the timer expires, the current registration fails and the GM
re-registers to the KS. This timer is not configurable. After the registration succeeds, the GM updates
the timer according to the received rekey SA and IPsec SA lifetime.
Data protection
After registering to the KS, a GM uses the IPsec SAs to protect data that matches the IPsec policy.
GMs can protect unicast data and multicast data.
Group domain VPN supports two encapsulation modes: tunnel mode and transport mode. The KS
determines the encapsulation mode to be used and assigns it the GMs.
• Tunnel mode—Adds a security protocol header (AH or ESP header) before the original IP
packet, and then adds an IP header (the same as the original IP header) before the security
protocol header. Currently, group domain VPN does not support AH. Figure 153 shows the
format of an ESP-encaps
ulated IP packet.
Figure 153 Tunnel mode encapsulation of group domain VPN
• Transport mode—Inserts a security protocol header between the original IP header and the
payload data. No change is made to the original IP header.
Group domain VPN also supports protection of MPLS L3VPN data. For more information about
MPLS L3VPN, see HPE FlexNetwork MSR Router Series Comware 5 MPLS Configuration Guide.
Rekey
If rekey parameters are configured on the KS, the KS periodically unicasts or multicasts (the default
mode is multicast) rekey messages to registered GMs to update their IPsec SAs or rekey SAs. The
rekey messages are protected by the current rekey SA on the KS. GMs authenticate the rekey
messages by using the public key that it received from the KS during registration. If a GM does not
receive any rekey messages before its IPsec SA or rekey SA expires, the GM re-registers to the KS.
For more information about rekey messages, see GROUPKEY-PUSH in RFC 3547.
KS redundancy
As shown in Figure 154, a group of KSs are deployed to achieve high availability and load sharing.
One KS is the primary KS, and others are secondary KSs. The primary KS creates and maintains
keys, advertises keys and GM information to secondary KSs, and sends rekey messages to
registered GMs. The secondary KSs do not generate keys. All the primary and secondary KSs can
accept registrations from GMs to achieve load sharing. Each secondary KS sends information about
all registered GMs to the primary KS.
To Next Page
Loading...
Need help?
General
