IEEE Std 2030.102.1-2020 pdf download – IEEE Standard for Interoperability of Internet Protocol Security (IPsec) Utlized within Utlity Control Systems.
2. Normative references The following referenced documents are indispensable for the application of this document (i.e., they shall be understood and used, so each referenced document is cited in text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. IETF RFC 3947, Negotiation of NAT-Traversal in the IKE. IETF RFC 3948, UDP Encapsulation of IPSec ESP Packets. IETF RFC 5280, Internet X.509 Public Key Infrastructure Certifcate and Certifcate Revocation List (CRL) Profle. NIST SP 800-131A Rev 2, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. 3. Confguration 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] 3 .
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 signifcant problems, as follows: — Address Mismatch: NAT changes the IP 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 verifcation 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 modifes the headers by inserting a new IP address and port in place of the sending device’s IP 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.