## 5 Communication Dependability
### Cybersecurity for IEC61850 Multicast Communication in Wide-Area Applications
#### 5.2.2 Secured Communication Path
While KS sends separate copies of the rekey message to each GM in the unicast model, KS sends only one copy of the message with the multicast address (to the registered GMs) in the multicast rekey model. In GET VPN, the multicast routers secure the network traffic, containing R-SV/R-GOOSE, by combining the group-key (TEK) with a computer networking technique called IPsec Tunnel Mode with Address Preservation [41]. This technique uses IPsec encryption and encapsulation mechanisms. However, a copy of the original IP header is preserved rather than replacing it with a new IP header (i.e., tunnel endpoints IP addresses) as would have occurred in the traditional IPsec Tunnel mode [42]. The ESP protocol then encrypts  
Figure 12: GDOI components (GCKS and GMs) in GET VPN architecture. IP packets using the router's TEK as shown in Figure 13. It should be noted that although this address-preservation technique seems similar to the IPsec Transport mode [42], the underlying operation mode is the IPsec Tunnel mode, which can overcome many of the fragmentation and reassembly limitations [41] that there are in the IPsec Transport mode. In GET VPN, the address-preservation technique enables seamless integration and routing of encrypted IP-multicast traffic to the core network (private WAN) because it uses the original IP header. Therefore, the underlying multicast infrastructure and routing protocols (PIM and IGMP) can be used for transmitting encrypted IP-multicast traffic. Figure 13 shows that GET VPN provides network level security for non-secured R-SV/R-GOOSE messages. GET VPN can also be used for secured R-SV/R-GOOSE messages to provide an extra layer of security. Figure 14 illustrates the sending of secured R-SV/R-GOOSE messages over GET VPN. This is known as the Defense-in-Depth security approach because it provides different layers of security. This approach presents both end-to-end security (by IEC61850 session layer protocol) and point-to-point security (via GET VPN). Consequently, R-SV/R-GOOSE messages are secured two times: once by IED's TEK and once by the Router's TEK. Figure 14 depicts multicast communication of secured R-SV/R-GOOSE from Substation 1 to Substation 2 and 3. The IP-multicast sender contacts local KDC and receives the IED's TEK (AK, EK, or both) needed for creating secured R-SV/R-GOOSE messages (see Section 5.2.1). Then, these secured messages are sent to FHR, which is a GM router in GET VPN architecture. The FHR and other GM routers were authenticated by the KS router. Moreover, every GM router selects its operation mode (encryption or decryption) and uses its associated security key (Router's TEK) based on the policies received from the KS router during GDOI registration. Therefore, FHR encrypts secured R-SV/R-GOOSE messages with the Router's TEK. These encrypted messages are ordinarily forwarded by multicast tree routers, since the original IP header has been preserved, until they reach their destinations, i.e., LHRs that are other GM routers within the GET VPN architecture. The LHRs have also received Router's TEK from KS, and they know their operation mode. Thus, LHRs decrypt secured R-SV/R-GOOSE messages using the Router's TEK and send them to the concerned IP-multicast receivers in the substations. These IP-multicast receivers have already contacted KDC, and they have the IED's TEK, which is required for decrypting/verifying the secured SV/R-GOOSE messages. GET VPN cannot work without KS because it is the KS that defines and maintains all the security keys and policies centrally. In order to ensure reliable operation of GET VPN with no single-point-of-failure, a system can be designed with redundant KS. GET VPN supports use of multiple KSs with Cooperative (COOP) KSs [41]. In a COOP KSs scenario, a list of all the KSs and their registration order are configured on each GM router by the network administrator. If connection to the first KS fails or if the data are not  
Figure 13: Securing R-SV/R-GOOSE messages by IPsec Tunnel Mode with Address Preservation.