IEEE Std 2030.102.1-2020 pdf download

IEEE Std 2030.102.1-2020 pdf download.IEEE Standard for Interoperability of Internet Protocol Security (IPsec)Utilized within Utility Control Systems.
3. Configuration requirements for IPsec utilized within utility control
systems
3.1 General
The configuration parameters identified in this section shall be supported to be compliant with this standard. Those that are deemed “Required” are considered the absolute minimum requirements for the configuration parameters listed in the following tables, whereas those listed as “Recommended” are considered optional configuration parameters that should be supported. “Deprecated” parameters are those that are no longer supported and shall not be used as part of this standard. The defined profile outlines the minimum set of IPsec options to be supported by devices implementing this standard to establish and maintain Phase 1 and Phase 2 Internet Key Exchange (IKE) and IPsec security associations [B4]1. Table A. 1 should be used to list the supported parameters.
The configuration parameters contained within this section were influenced by the use case of the IPsec tunnel supporting critical utility control system traffic. They were chosen to support a balance of highest security and availability including requirements for the following:
Sustaining the IPsec tunnel
Fast recovery (i.e., re-establishment) from a failure of the IPsec tunnel
Alignment with recommendations outlined in NIST SP 800-13 1A
3.2 IPsec configuration profile
The configuration parameters identified in this section shall be supported to be compliant with this standard. These parameters are organized into Table 1 through Table 4.
Annex B
(informative)
NAT traversal and IPsec
The information contained within this annex outlines the challenges when an IPsec tunnel traverses a device implementing Network Address Translation (NAT) and one possible resolution. It is informative and, therefore, not required to be compliant to this standard; however, it may influence additional requirements by users of devices implementing iPsec.
B.1 Problem statement
The basic challenge encountered when NAT is introduced between the endpoints of an iPsec tunnel is that it changes information in the packet headers, which may lead to three significant problems, as follows:
Address Mismatch: NAT changes the 1P address of the internal device to that of an address assigned by the NAT device. The Internet Key Exchange (IKE) protocol utilized within IPsec embeds the sender’s IP address within the payload. Because of this, a NAT device causes a mismatch between this embedded address and the source address of the IKE packet (which has been replaced with the address of the NAT device). When these addresses do not match, the receiving device drops the packet.
checksums: Checksums utilized for packet verification create a problem because the checksum included in the TCP header is computed using the IP addresses of the sending and receiving devices. Checksums do not present a problem with normal NAT communications because the NAT device modifies the headers by inserting a new IP address and port in place of the sending device’s 1P address and port. With IPsec, however, the TCP header is encrypted using the Encapsulating Security Payload (ESP) protocol. When ESP encrypts the TCP header, a NAT device cannot change it, resulting in an invalid checksum and the receiving device rejecting the packet.
Port Address Translation (PAT: PAT is used to provide internal devices with access to an external network using the same external IP address, which is common with internet facing devices, due to lack of available external 1P addresses. Because the ESP protocol does not involve ports, a unique port cannot be assigned to the packet when the original source address is changed to the external address in the binding database. In this case, ESP cannot pass through the PAT device because the database binding cannot complete without the unique port assigned, leading to the inability to associate the inside host source of the packet.
B.2 Use case
Atypical use case as shown in Figure 8.1 involves one or more devices providing network translation services between the endpoints of a desired iPsec tunnel (in this case, between the outside interfaces of Firewall “A” and Firewall “C”). In this example. the actual JP address for the outside interface of Firewall “A” (in the Y.Y.Y.Y/24 network) is not known to Firewall “C” and is masquerading behind a NAT within Firewall “B” in the X.X.X.X!24 network.