Ieee Standard For Interoperability of Internet Protocol Security

IEEE Standard for Interoperability
STANDARDS
of Internet Protocol Security (IPsec)
Utilized within Utility Control Systems
IEEE Power and Energy Society
Developed by the
Power System Communications and Cybersecurity
Committee
IEEE Std 2030.102.1™-2020
Authorized licensed use limited to: Univ of Calif Santa Barbara. Downloaded on May 21,2021 at 05:13:28 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 2030.102.1™-2020

Developed by the
Power System Communications and Cybersecurity Committee

of the
IEEE Power and Energy Society
Approved 3 December 2020
IEEE SA Standards Board
Abstract: Specific configuration requirements within the relevant Internet Engineering Task Force
(IETF) Request for Comments (RFC) for implementation of the Internet Protocol Security (IPsec)
protocol suite within a utility control system are identified in this standard. It is not intended to
be a comprehensive guide to implementing IPsec. Promoting interoperability between products
developed by different vendors is the primary goal in developing this standard. Configuration
parameters needed to support the establishment and sustained operation of an IPsec Virtual
Private Network (VPN) tunnel between two devices which have implemented IPsec conforming
to this standard are the focus of this standard. Minimizing configuration errors involving IPsec
implementations within utility control systems is a secondary goal of this standard. Product
agnosticism and applicability to any device (e.g., router, substation gateway, intelligent electronic
device, etc.) is the intent of this standard, within the utility control system as the end user deems
necessary for their unique system architecture.
Keywords: control systems, cyber security, encryption, ICS, IEEE 2030.102.1™, IPsec, Lemnos,
privacy, Virtual Private Network, VPN
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2021 by The Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 12 March 2021. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Oﬃce, owned by The Institute of Electrical and Electronics Engineers,
Incorporated.
PDF: ISBN 978-1-5044-7293-7 STD24553

Print: ISBN 978-1-5044-7294-4 STDPD24553
IEEE prohibits discrimination, harassment, and bullying.

For more information, visit httpss://www.ieee.orgabout/corporate/governance/p9-26.html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers.
These notices and disclaimers, or a reference to this page (https://standards.ieee.org/ipr/disclaimers.html),
appear in all standards and may be found under the heading “Important Notices and Disclaimers Concerning
IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Documents
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating
Committees of the IEEE Standards Association (IEEE SA) Standards Board. IEEE develops its standards
through an accredited consensus development process, which brings together volunteers representing varied
viewpoints and interests to achieve the final product. IEEE Standards are documents developed by volunteers
with scientific, academic, and industry-based expertise in technical working groups. Volunteers are not
necessarily members of IEEE or IEEE SA, and participate without compensation from IEEE. While IEEE
administers the process and establishes rules to promote fairness in the consensus development process, IEEE
does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any
judgments contained in its standards.
IEEE does not warrant or represent the accuracy or completeness of the material contained in its standards,
and expressly disclaims all warranties (express, implied and statutory) not included in this or any other
document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness
for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness
of material. In addition, IEEE disclaims any and all conditions relating to results and workmanlike effort. In
addition, IEEE does not warrant or represent that the use of the material contained in its standards is free from
patent infringement. IEEE Standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE Standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments received
from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity, nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or
her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate,
seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: THE
NEED TO PROCURE SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE
UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND
REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
3
Copyright © 2021 IEEE. All rights reserved.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English version published by IEEE is the approved IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations
Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall
not be considered to be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars,
or educational courses, an individual presenting information on IEEE standards shall make it clear that the
presenter’s views should be considered the personal views of that individual rather than the formal position of
IEEE, IEEE SA, the Standards Committee, or the Working Group.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of
membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations, consulting
information, or advice pertaining to IEEE Standards documents.
Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is
important that any responses to comments and questions also receive the concurrence of a balance of interests.
For this reason, IEEE and the members of its Societies and Standards Coordinating Committees are not able to
provide an instant response to comments, or questions except in those cases where the matter has previously
been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would
like to participate in evaluating comments or in revisions to an IEEE standard is welcome to join the relevant
IEEE working group. You can indicate interest in a working group using the Interests tab in the Manage Profile
and Interests area of the IEEE SA myProject system. An IEEE Account is needed to access the application.
Comments on standards should be submitted using the Contact Us form.
Laws and regulations

Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with
the provisions of any IEEE Standards document does not constitute compliance to any applicable regulatory
requirements. Implementers of the standard are responsible for observing or referring to the applicable
regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in
compliance with applicable laws, and these documents may not be construed as doing so.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and
data ownership in the context of assessing and using the standards in compliance with applicable laws and
regulations.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under US and international copyright laws. They
are made available by IEEE and are adopted for a wide variety of both public and private uses. These include
4
both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the
promotion of engineering practices and methods. By making these documents available for use and adoption
by public authorities and private users, IEEE does not waive any rights in copyright to the documents.
Photocopies
Subject to payment of the appropriate licensing fees, IEEE will grant users a limited, non-exclusive license to
photocopy portions of any individual standard for company or organizational internal use or individual, non-
commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400; https://www.copyright
.com/. Permission to photocopy portions of any individual standard for educational classroom use can also be
obtained through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the
document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 years old
and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some
value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have
the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended through
the issuance of amendments, corrigenda, or errata, visit IEEE Xplore or contact IEEE. For more information
about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number and
year of approval to access the web page of the published standard. Errata links are located under the Additional
Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to periodically
check for errata.
Patents
IEEE Standards are developed in compliance with the IEEE SA Patent Policy.
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the
existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has
filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE
SA Website at https://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate
whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation
or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries
5
into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions
provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are
reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the
validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility.
Further information may be obtained from the IEEE Standards Association.
IMPORTANT NOTICE
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against
interference with or from other devices or networks. IEEE Standards development activities consider research
and information presented to the standards development group in developing any safety recommendations.
Other information about safety practices, changes in technology or technology implementation, or impact
by peripheral systems also may be pertinent to safety considerations during implementation of the standard.
Implementers and users of IEEE Standards documents are responsible for determining and complying with
all appropriate safety, security, environmental, health, and interference protection practices and all applicable
laws and regulations.
6
Participants
At the time this IEEE standard was submitted to the IEEE SA Standards Board for approval, the S3 Working
Group had the following membership:
James Bougie, Chair

Marc Lacroix, Vice Chair
Xiangyu Ding Colin Gordon Ralph Mackiewicz

Michael Dood Steven Kunsman Scott Morris
James Formea Jason Lombardo Craig Preuss
Yuri Luskind
The following members of the individual Standards Association balloting group voted on this standard.
Balloters may have voted for approval, disapproval, or abstention.
William Ackerman Edwin Goodwin Bansi Patel

Mihaela Albu Roman Graf Howard Penrose
Christopher Belcher Randall Groves R.K. Rannow
Wallace Binder Werner Hoelzl Charles Rogers
Demetrio Bucaneg Jr. Gary Hoffman Daniel Sabin
Paul Cardinal Anthony Johnson Thomas Schossig
Pin Chang Brian Johnson Robert Seitz
George Clark Innocent Kamwa Scott Sternfeld
Michael Dood Yuri Khersonsky David Tepen
Neal Dowling Jim Kulchisky James Van De Ligt
Thomas Dunmore II Marc Lacroix Benton Vandiver
Kenneth Fodero Jose Marrero John Vergis
James Formea Alexander Micallef Quintin Verzosa
Fredric Friend Sepehr Mogharei Jeffrey Wischkaemper
Jean-Sebastien Gagnon Jerry Murphy Kipp Yule
Lorraine Padden
When the IEEE SA Standards Board approved this standard on 3 December 2020, it had the following
membership:
Gary Hoffmann, Chair

Jon Walter Rosdahl, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Ted Burse David J. Law Mehmet Ulema

Doug Edwards Howard Li Lei Wang
J.Travis Griffith Dong Liu Sha Wei
Grace Gu Kevin Lu Philip B. Winston
Guido R. Hiertz Paul Nikolich Daidi Zhong
Joseph L. Koepfinger* Damir Novosel Jingyi Zhou
Dorothy Stanley
*Member Emeritus
7
Introduction
This introduction is not part of IEEE Std 2030.102.1–2020, IEEE Standard for Interoperability of Internet Protocol
Security (IPsec) Utilized within Utility Control Systems.
Interoperability is not a new concept in the context of cyber security. It is, however, a difficult and challenging
concept that poses a significant barrier to establishing and maintaining a secure posture for control systems
deployed within the electric utility sector. This standard represents a continuation of work that began under
the Lemnos Interoperable Security Project, which was a multiyear effort under the DOE Office of Electricity
Delivery and Energy Reliability's Cybersecurity for Energy Delivery Systems (CEDS) program in support
of the Roadmap to Secure Energy Delivery Systems. The Lemnos Project established a process to address
this challenge by selecting open standards, namely Internet Engineering Task Force (IETF) Request for
Comments (RFCs), and then developing profiles that detail specific configuration requirements within the
RFC. The intent of these profiles is to be product-agnostic and able to be applied modularly to any device
(e.g., router, substation gateway, intelligent electronic device) within the utility control system as the end user
deems necessary for their unique system architecture.
This standard identifies specific configuration requirements within the relevant Internet Engineering Task
Force (IETF) Request for Comments (RFCs) for implementation of the Internet Protocol Security (IPsec)
protocol suite as part of a utility control system. It has been developed relative to IPv4. It is not intended to be
a comprehensive guide to implementing IPsec.
8
Contents
1. Overview�� 10
1.1 Scope�� 10
1.2 Purpose�� 10
1.3 Word usage�� 10
2. Normative references�� 11
3. Configuration requirements for IPsec utilized within utility control systems�� 11

3.1 General�� 11
3.2 IPsec configuration profile�� 11
Annex A (normative) Table of compliance guidelines�� 14
Annex B (informative) NAT traversal and IPsec�� 16
Annex C (informative) Bibliography�� 18
9
1. Overview
1.1 Scope
This standard specifies requirements for interoperability of devices utilized within utility control systems,
which implement the Internet Protocol Security (IPsec) protocol suite within an IPv4 environment.
1.2 Purpose
The purpose of this document is to define a specific configuration profile for the Internet Protocol Security
(IPSec) protocol suite suitable for use within a utility control system. The primary goal in developing this
standard is to promote interoperability between products developed by different vendors. It focuses on those
configuration parameters needed to support the establishment and sustained operation of an IPSec Virtual
Private Network (VPN) tunnel between two devices that have implemented IPSec conforming to this standard.
A secondary goal of this standard is to help minimize configuration errors involving IPSec implementations
within utility control systems.
1.3 Word usage

The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard
and from which no deviation is permitted (shall equals is required to).1,2
The word should indicates that among several possibilities one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily
required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals
is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can
equals is able to).
1
The use of the word must is deprecated and cannot be used when stating mandatory requirements, must is used only to describe
unavoidable situations.
2
The use of will is deprecated and cannot be used when stating mandatory requirements, will is only used in statements of fact.
10
IEEE Std 2030.102.1-2020
IEEE Standard for Interoperability of Internet Protocol Security (IPsec) Utilized within Utility 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 Certificate and Certificate Revocation List (CRL)
Profile.
NIST SP 800-131A Rev 2, Transitions: Recommendation for Transitioning the Use of Cryptographic
Algorithms and Key Lengths.
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]3. 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-131A4
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.
3
The numbers in brackets correspond to those of the bibliography in Annex C.
4
Information on references can be found in Clause 2.
11
IEEE Std 2030.102.1-2020
Table 1—ISAKMP configuration parameters

Requirement Options Values
1–1. Security ESP (Encapsulating Security Payload)
1–2. Mode TUNNEL mode
1–3. Authentication HMAC for authentication and integrity
1–4. Version IKE Version 2
1–5. Key Exchange DH (Diffie-Hellman)
Table 2—IPsec configuration parameters

2–1 IKE Lifetype Seconds
2–2 IKE Lifetime 10 800 s
2–3 IPsec Lifetime 3600 s
2–4 Rekey Margin 540 s
2–5 Rekey Fuzz 100%
2–6 Keying Tries 3 (renegotiate keys 3 times)
2–7 Dead Peer Detection Action Restart
2–8 Dead Peer Detection Delay 60 s (dead peer detection time “hello” interval in seconds)
2–9 Dead Peer Detection Timeout 150 s; (dead peer detection time timeout interval in seconds)
2–10 Use PFS (perfect forward secrecy) For enhanced key exchange security (use DH with PFS)
Table 3—Required, recommended, and deprecated Phase 1 configuration parameters

Phase 1
Encryption Algorithms
3–1. AES 128 Required
3–2. AES 192 or 256 Recommended
3–3. DES Deprecated
Hash Algorithms
3–4. MD5 Deprecated
3–5. SHA1 Deprecated
3–6. SHA2_256 Required
3–7. SHA2_384 Recommended
Diffie-Hellman Groups
3–9. GROUP 2 (modp1024) Deprecated
3–10. GROUP 5 (modp1536) Deprecated
3–11. GROUP 14 (modp2048) Required
3–12. GROUP 15 (modp3072) Recommended
3–13. GROUP 19 (ecp256) Recommended
3–14. GROUP 20 (ecp384) Recommended
Peer Identity
3–15. IPv4 address Required
3–16. Fully-qualified domain name Recommended
Table continues
12
IEEE Std 2030.102.1-2020
Table 3—Required, recommended, and deprecated Phase

1 configuration parameters (continued)
Phase 1
3–17. Certificate Recommended only if certificate revocation is
supported as defined in IETF RFC 5280
NAT Traversal
3–18. IETF RFC 3947/3948-compliant Recommended
*Annex B outlines the challenge of a IPsec tunnel traversing a device implementing Network Address Translation (NAT )
Table 4—Required, recommended, and deprecated Phase 2 configuration parameters

Phase 2
Encryption Algorithms
4–1. AES 128 Required
4–2. AES 192 or 256 Recommended
4–3. DES Deprecated
4–4. 3DES Deprecated
Hash Algorithms
4–5. MD5 Deprecated
4–6. SHA1 Deprecated
4–7. SHA2_256 Required
NAT Traversal
IETF RFC 3947/3948-compliant
4–10. Recommended
NAT-T*
*Annex B outlines the challenge of a IPsec tunnel traversing a device implementing Network Address Translation (NAT )
13
IEEE Std 2030.102.1-2020
Annex A
(normative)
Table of compliance guidelines

The table of compliance is a tool intended for specification and procurement purposes. Its objective is to be a
template that describes the required functions from this standard that need to be implemented on the IED under
procurement. Once fulfilled by the procurer and sent to the potential supplier, it shall be completed with the
implementation details of the proposed hardware.
It is then be sent back to the requester for analysis of technical implementations and correctness of requirements
fulfilment.
The column headings used in Table A.1 are as follows:
Requirement number: IEEE Std 2030.102.1 references.
Requirement title: Description of the chapter that is found in the document.
Status: Variable field containing one of the three possible values [Compliant/Non-compliant/Alternative].
Comment: Variable field containing additional information provided by supplier to procurer, such as choice
of technology, implementation performances, limits, etc.
Table A.1—Table of compliance

Req. Requirement title Status Comment
number
1–1 Security
1–2 Mode
1–3 Authentication
1–4 Version
1–5 Key Exchange
2–1 IKE Lifetype
2–2 IKE Lifetime
2–3 IPSec Lifetime
2–4 Rekey Margin
2–5 Rekey Fuzz
2–6 Keying Tries
2–7 Dead Peer Detection Action
2–8 Dead Peer Detection Delay
2–9 Dead Peer Detection Timeout
2–10 Use PFS (perfect forward secrecy)
Phase 1 Encryption Algorithm
3–1 AES 128
3–2 AES 192 or 256
3–3 DES
Phase 1 Hash Algorithm
3–4 MD5
Table continues
14
IEEE Std 2030.102.1-2020
Table A.1—Table of compliance (continued)

Req. Requirement title Status Comment
number
3–5 SHA1
3–6 SHA2_256
3–7 SHA2_384
3–8 SHA2_512
Phase 1 Diﬃe-Hellman Groups
3–9 GROUP 2 (modp1024)
3–10 GROUP 5 (modp1536)
3–11 GROUP 14 (modp2048)
3–12 GROUP 15 (modp3072)
3–13 GROUP 19 (ecp256)
3–14 GROUP 20 (ecp384)
Phase 1 Peer Identity
3–15 IPv4 address
3–16 Fully-qualified domain name
3–17 Certificate
Phase 1 NAT Traversal
3–18 RFC 3947/3948-compliant
Phase 2 Encryption Algorithms
4–1 AES 128
4–2 AES 192 or 256
4–3 DES
4–4 3DES
Phase 2 Hash Algorithm
4–5 MD5
4–6 SHA1
4–7 SHA2_256
4–8 SHA2_384
4–9 SHA2_512
Phase 2 NAT Traversal
4–10 RFC 3947/3948-compliant NAT-T
15
IEEE Std 2030.102.1-2020
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 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 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 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.
— 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 IP 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
A typical use case as shown in Figure B.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 IP 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.
16
IEEE Std 2030.102.1-2020
Figure B.1—NAT traversal use case
B.3 Resolution
The solution to the problem outlined in the preceding use case is the implementation of NAT-T along with
IPsec. NAT-T, defined in IETF RFC 3947 and IETF RFC 3948, addresses the problems encountered in using
IPsec with NAT. It performs two tasks, as follows:
a) Detects if both ends support NAT-T

b) Detects NAT devices along the transmission path (NAT-Discovery)
NAT-T adds a UDP header that encapsulates the ESP packet only in cases where a NAT device is detected. If no
NAT device is detected, no UDP encapsulation is done. This UDP header provides a mechanism that supports
PAT by inserting the sender’s original IP address into a NAT-OA (Original Address) payload, thus eliminating
the problem of the embedded source address not matching the packet's source address. The presence of the
NAT-OA payload allows the receiving device to validate the checksum based on the sender's original source
and destination IP addresses and ports.
17
IEEE Std 2030.102.1-2020
Annex C
(informative)
Bibliography
Bibliographical references are resources that provide additional or helpful material but do not need to be
understood or used to implement this standard. Reference to these resources is made for informational use
only.
[B1] IETF RFC 4301, Security Architecture for the Internet Protocol.5
[B2] IETF RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2).
[B3] FIPS PUB 140-3 Security Requirements for Cryptographic Modules.6
[B4] IANA Internet Key Exchange Version 2 (IKEv2) Parameters.7
5
IETF documents (i.e., RFCs) are available for download at https://www.rfc-editor.org/rfc-index.html.
6
FIPS publications are available from the National Technical Information Service, U. S. Department of Commerce (https://csrc.nist.gov/
publications/fips).
7
Available at: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml.
18
RAISING THE
WORLD’S
STANDARDS
Connect with us on:
Twitter: twitter.com/ieeesa
Facebook: facebook.com/ieeesa
LinkedIn: linkedin.com/groups/1791118
Beyond Standards blog: beyondstandards.ieee.org
YouTube: youtube.com/ieeesa
standards.ieee.org
Phone: +1 732 981 0060

Ieee Standard For Interoperability of Internet Protocol Security

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ieee Standard For Interoperability of Internet Protocol Security

Uploaded by

Copyright:

Available Formats

IEEE Standard for Interoperability

IEEE Power and Energy Society

IEEE Std 2030.102.1™-2020

IEEE Standard for Interoperability

Power System Communications and Cybersecurity Committee

Approved 3 December 2020

IEEE SA Standards Board

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2021 by The Institute of Electrical and Electronics Engineers, Inc.

PDF: ISBN 978-1-5044-7293-7 STD24553

IEEE prohibits discrimination, harassment, and bullying.

Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Comments on standards should be submitted using the Contact Us form.

Laws and regulations

Updating of IEEE Standards documents

James Bougie, Chair

Xiangyu Ding Colin Gordon Ralph Mackiewicz

William Ackerman Edwin Goodwin Bansi Patel

Gary Hoffmann, Chair

Ted Burse David J. Law Mehmet Ulema

3. Configuration requirements for IPsec utilized within utility control systems�������������������������������������������� 11

1.3 Word usage

IETF RFC 3947, Negotiation of NAT-Traversal in the IKE.

IETF RFC 3948, UDP Encapsulation of IPSec ESP Packets.

3. Configuration requirements for IPsec utilized within utility control

— Sustaining the IPsec tunnel

3.2 IPsec configuration profile

Table 1—ISAKMP configuration parameters

Table 2—IPsec configuration parameters

Table 3—Required, recommended, and deprecated Phase 1 configuration parameters

Table 3—Required, recommended, and deprecated Phase

Table 4—Required, recommended, and deprecated Phase 2 configuration parameters

Table of compliance guidelines

The column headings used in Table A.1 are as follows:

Requirement number: IEEE Std 2030.102.1 references.

Requirement title: Description of the chapter that is found in the document.

Table A.1—Table of compliance

Table A.1—Table of compliance (continued)

NAT traversal and IPsec

B.1 Problem statement

B.2 Use case

Figure B.1—NAT traversal use case

a) Detects if both ends support NAT-T

[B3] FIPS PUB 140-3 Security Requirements for Cryptographic Modules.6

[B4] IANA Internet Key Exchange Version 2 (IKEv2) Parameters.7

You might also like

3. Configuration requirements for IPsec utilized within utility control systems�� 11