## 5 Communication Dependability
### Cybersecurity for IEC61850 Multicast Communication in Wide-Area Applications
#### 5.2.2 Secured Communication Path  
In wide-area applications, R-SV/R-GOOSE communication can also be protected by securing the communication path (WAN). While the Group Encrypted Transport Virtual Private Network (GET VPN) is used to secure a private WAN, the IP security (IPsec) tunnel is used for a public WAN. For a private WAN (Figure 5), GET VPN [41] provides network level security by encrypting IP-multicast traffic (R-GOOSE/R-SV) transmitted between the edge routers. GET VPN is tunnel-less VPN based on GDOI [37] in which all the GMs (multicast tree routers) share a common security material, based on the group-IPsec [42] security paradigm. In traditional point-to-point IPsec VPN, two communication peers negotiate to establish a common IPsec Security Association (SA) that specifies the type of cryptographic algorithms and the security policies for an IPsec tunnel. Then, the Encapsulated Security Payload (ESP) protocol [42] provides symmetric encryption for data transmitted in the tunnel. However, tunnel-based encryption is not a scalable solution for securing IP-multicast traffic in a private WAN because so many IPsec tunnels and associated SAs are required between each of the multicast tree routers, i.e., FHR, intermediary WAN routers, and LHRs. GET VPN provides a highly scalable solution by introducing the concept of group-IPsec SA, which is a common cryptographic key and policy sharing between the group participants, i.e., multicast tree routers. GET VPN is tunnel-less VPN because there is no need to negotiate point-to-point IPsec tunnels between each of the two routers of the multicast tree. GETVPN uses GDOI and encrypts the communication between the multicast tree routers while keeping them synchronized. GET VPN security is based on the GDOI mechanism [37] that was explained in the previous section. GET VPN combines group-key protocol, based on GDOI, with IPsec encryption that is based on ESP to secure IP-multicast traffic (R-SV/R-GOOSE)between routers of the multicast tree in private WAN. Thus, one of the multicast routers (in Figure 5) acts as the GCKS that authenticates the other GMs (routers) via an ISAMP-based authentication method such as pre-shared key or certificate-based authentication. After successful authentication, the GMs register with the GCKS and acquire group-IPsec SA, which is necessary for secure communication within the group. When a GM registers with it, the GCKS sends the group-IPsec policy to the GM. After the GM confirms the handling of the received SA policy, the GCKS downloads security keys (KEK and TEK) to the GM. While TEK becomes the group-key for encrypting and decrypting IP-multicast communication between the GM routers, KEK encrypts and decrypts messages that are related to rekeying SA (new group-IPsec SA) and exchanged between GCKS and GMS as depicted in Figure 12.  
Thus, the GCKS and the GMs are part of any GET VPN architecture in a private WAN. The GCKS, Key Server (KS) for short, is the router responsible for managing the GET VPN control plane, i.e., group-IPsec SA (type of encryption protocols and their policies). The GMs are the routers responsible for handling the GET VPN data plane, i.e., the actual encryption and decryption of data. As was explained earlier, GDOI uses two security keys, KEK and TEK, which secure the control plane and data plane of the GET VPN, respectively. These keys have a defined lifetime which is determined based on the security policy of the network. While the KEK lifetime regulates the time before rekeying the SA, the TEK lifetime determines the lifetime of the group-IPsec SA. KS periodically refreshes the cryptographic keys (KEK and TEK) and policies and distributes updates to the GMs via rekeying, which is the process of pushing new security keys when the current SA keys are about to expire or if the SA policy changes on the KS. GET VPN supports two types [41] of rekeying messages: unicast rekey and multicast rekey.