Network Working Group D. Maughan
Request for Comments: 2408 National Security Agency
Category: Standards Track M. Schertler
Securify, Inc.
M. Schneider
National Security Agency
J. Turner
RABA Technologies, Inc.
November 1998
Network Working Group D. Maughan
Request for Comments: 2408 National Security Agency
Category: Standards Track M. Schertler
Securify, Inc.
M. Schneider
National Security Agency
J. Turner
RABA Technologies, Inc.
November 1998
Internet Security Association and Key Management Protocol (ISAKMP)
Internet安全关联和密钥管理协议（ISAKMP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment.
本备忘录描述了一种协议，该协议利用了在Internet环境中建立安全关联（SA）和加密密钥所必需的安全概念。对于一个不断发展的互联网来说，需要一个安全关联协议来协商、建立、修改和删除安全关联及其属性，其中将有许多安全机制和每个安全机制的几个选项。密钥管理协议必须是健壮的，以便处理整个互联网社区的公钥生成以及具有该需求的私有网络的私钥需求。Internet安全关联和密钥管理协议（ISAKMP）定义了验证通信对等方、创建和管理安全关联、密钥生成技术和威胁缓解（例如拒绝服务和重放攻击）的程序。所有这些都是在Internet环境中建立和维护安全通信（通过IP安全服务或任何其他安全协议）所必需的。
Table of Contents
目录
1 Introduction 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
1.4 Security Associations and Management . . . . . . . . . . . 7
1.4.1 Security Associations and Registration . . . . . . . . 7
1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
2 Terminology and Concepts 14
2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
2.4 Identifying Security Associations . . . . . . . . . . . . . 17
2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
3 ISAKMP Payloads 21
3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Security Association Payload . . . . . . . . . . . . . . . 27
3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
1 Introduction 4
1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5
1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6
1.4 Security Associations and Management . . . . . . . . . . . 7
1.4.1 Security Associations and Registration . . . . . . . . 7
1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8
1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8
1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9
1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9
1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10
1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10
1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11
1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12
1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12
1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12
1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13
1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13
1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13
2 Terminology and Concepts 14
2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14
2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16
2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16
2.4 Identifying Security Associations . . . . . . . . . . . . . 17
2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20
2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20
2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20
3 ISAKMP Payloads 21
3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21
3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Security Association Payload . . . . . . . . . . . . . . . 27
3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28
3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29
3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31
3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32
3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33
3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34
3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36
3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37
3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37
3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38
3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40
3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41
3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43
4 ISAKMP Exchanges 44
4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Security Association Establishment . . . . . . . . . . . . 46
4.2.1 Security Association Establishment Examples . . . . . 48
4.3 Security Association Modification . . . . . . . . . . . . . 50
4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
5 ISAKMP Payload Processing 58
5.1 General Message Processing . . . . . . . . . . . . . . . . 58
5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
5.4 Security Association Payload Processing . . . . . . . . . . 62
5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
5.8 Identification Payload Processing . . . . . . . . . . . . . 66
5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
5.10 Certificate Request Payload Processing . . . . . . . . . 67
5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
5.14 Notification Payload Processing . . . . . . . . . . . . . 71
5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
6 Conclusions 75
A ISAKMP Security Association Attributes 77
A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
B Defining a new Domain of Interpretation 79
B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
Security Considerations 81
IANA Considerations 81
Domain of Interpretation 81
Supported Security Protocols 82
4 ISAKMP Exchanges 44
4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45
4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Security Association Establishment . . . . . . . . . . . . 46
4.2.1 Security Association Establishment Examples . . . . . 48
4.3 Security Association Modification . . . . . . . . . . . . . 50
4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51
4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52
4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54
4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55
4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57
5 ISAKMP Payload Processing 58
5.1 General Message Processing . . . . . . . . . . . . . . . . 58
5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59
5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61
5.4 Security Association Payload Processing . . . . . . . . . . 62
5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63
5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64
5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65
5.8 Identification Payload Processing . . . . . . . . . . . . . 66
5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66
5.10 Certificate Request Payload Processing . . . . . . . . . 67
5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69
5.12 Signature Payload Processing . . . . . . . . . . . . . . 69
5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70
5.14 Notification Payload Processing . . . . . . . . . . . . . 71
5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73
6 Conclusions 75
A ISAKMP Security Association Attributes 77
A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77
A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77
A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77
A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78
A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78
A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78
A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78
B Defining a new Domain of Interpretation 79
B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80
B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80
B.4 Syntax for Specifying Security Services . . . . . . . . . . 80
B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80
B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80
Security Considerations 81
IANA Considerations 81
Domain of Interpretation 81
Supported Security Protocols 82
Acknowledgements 82 References 82 Authors' Addresses 85 Full Copyright Statement 86
确认82引用82作者地址85完整版权声明86
List of Figures
数字一览表
1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16
2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22
3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26
5 Security Association Payload . . . . . . . . . . . . . . . 27
6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28
7 Transform Payload Format . . . . . . . . . . . . . . . . . 30
8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31
9 Identification Payload Format . . . . . . . . . . . . . . . 32
10 Certificate Payload Format . . . . . . . . . . . . . . . . 33
11 Certificate Request Payload Format . . . . . . . . . . . . 34
12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36
13 Signature Payload Format . . . . . . . . . . . . . . . . . 37
14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38
15 Notification Payload Format . . . . . . . . . . . . . . . . 39
16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42
17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44
1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16
2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22
3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25
4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26
5 Security Association Payload . . . . . . . . . . . . . . . 27
6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28
7 Transform Payload Format . . . . . . . . . . . . . . . . . 30
8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31
9 Identification Payload Format . . . . . . . . . . . . . . . 32
10 Certificate Payload Format . . . . . . . . . . . . . . . . 33
11 Certificate Request Payload Format . . . . . . . . . . . . 34
12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36
13 Signature Payload Format . . . . . . . . . . . . . . . . . 37
14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38
15 Notification Payload Format . . . . . . . . . . . . . . . . 39
16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42
17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44
1 Introduction
1导言
This document describes an Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP combines the security concepts of authentication, key management, and security associations to establish the required security for government, commercial, and private communications on the Internet.
本文档描述了Internet安全关联和密钥管理协议（ISAKMP）。ISAKMP将身份验证、密钥管理和安全关联等安全概念结合起来，为政府、商业和私人互联网通信建立所需的安全性。
The Internet Security Association and Key Management Protocol (ISAKMP) defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SA). SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic. ISAKMP defines payloads for exchanging key generation and authentication data. These formats provide a consistent framework for transferring key and authentication data which is independent of the key generation technique, encryption algorithm and authentication mechanism.
Internet安全关联和密钥管理协议（ISAKMP）定义了建立、协商、修改和删除安全关联（SA）的过程和数据包格式。SA包含执行各种网络安全服务所需的所有信息，如IP层服务（如报头身份验证和有效负载封装）、传输或应用层服务或协商流量的自我保护。ISAKMP定义用于交换密钥生成和身份验证数据的有效负载。这些格式为传输密钥和身份验证数据提供了一个一致的框架，该框架独立于密钥生成技术、加密算法和身份验证机制。
ISAKMP is distinct from key exchange protocols in order to cleanly separate the details of security association management (and key management) from the details of key exchange. There may be many different key exchange protocols, each with different security properties. However, a common framework is required for agreeing to the format of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP serves as this common framework.
ISAKMP不同于密钥交换协议，以便将安全关联管理（和密钥管理）的细节与密钥交换的细节清晰地分开。可能有许多不同的密钥交换协议，每个协议具有不同的安全属性。但是，同意SA属性的格式以及协商、修改和删除SA需要一个通用框架。ISAKMP就是这个通用框架。
Separating the functionality into three parts adds complexity to the security analysis of a complete ISAKMP implementation. However, the separation is critical for interoperability between systems with differing security requirements, and should also simplify the analysis of further evolution of a ISAKMP server.
将功能分为三个部分增加了完整ISAKMP实现的安全性分析的复杂性。然而，这种分离对于具有不同安全需求的系统之间的互操作性至关重要，并且还应该简化对ISAKMP服务器进一步发展的分析。
ISAKMP is intended to support the negotiation of SAs for security protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF, etc.). By centralizing the management of the security associations, ISAKMP reduces the amount of duplicated functionality within each security protocol. ISAKMP can also reduce connection setup time, by negotiating a whole stack of services at once.
ISAKMP旨在支持SAs在网络堆栈的所有层（如IPSEC、TLS、TLSP、OSPF等）协商安全协议。通过集中管理安全关联，ISAKMP减少了每个安全协议中重复功能的数量。ISAKMP还可以通过一次协商整个服务堆栈来减少连接设置时间。
The remainder of section 1 establishes the motivation for security negotiation and outlines the major components of ISAKMP, i.e. Security Associations and Management, Authentication, Public Key Cryptography, and Miscellaneous items. Section 2 presents the terminology and concepts associated with ISAKMP. Section 3 describes the different ISAKMP payload formats. Section 4 describes how the payloads of ISAKMP are composed together as exchange types to establish security associations and perform key exchanges in an authenticated manner. Additionally, security association modification, deletion, and error notification are discussed. Section 5 describes the processing of each payload within the context of ISAKMP exchanges, including error handling and associated actions. The appendices provide the attribute values necessary for ISAKMP and requirement for defining a new Domain of Interpretation (DOI) within ISAKMP.
第1节的其余部分确定了安全协商的动机，并概述了ISAKMP的主要组成部分，即安全关联和管理、身份验证、公钥加密和杂项。第2节介绍了与ISAKMP相关的术语和概念。第3节描述了不同的ISAKMP有效负载格式。第4节描述了如何将ISAKMP的有效负载组合为交换类型，以建立安全关联并以经过身份验证的方式执行密钥交换。此外，还讨论了安全关联的修改、删除和错误通知。第5节描述了ISAKMP交换上下文中每个有效负载的处理，包括错误处理和相关操作。附录提供了ISAKMP所需的属性值以及在ISAKMP中定义新的解释域（DOI）的要求。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC-2119].
本文件中出现的关键词必须、不得、必需、应、不应、应、不应、建议、可能和可选时，应按照[RFC-2119]中的说明进行解释。
ISAKMP extends the assertion in [DOW92] that authentication and key exchanges must be combined for better security to include security association exchanges. The security services required for
ISAKMP扩展了[DOW92]中的断言，即必须将身份验证和密钥交换结合起来，以提高安全性，从而包括安全关联交换。所需的安全服务
communications depends on the individual network configurations and environments. Organizations are setting up Virtual Private Networks (VPN), also known as Intranets, that will require one set of security functions for communications within the VPN and possibly many different security functions for communications outside the VPN to support geographically separate organizational components, customers, suppliers, sub-contractors (with their own VPNs), government, and others. Departments within large organizations may require a number of security associations to separate and protect data (e.g. personnel data, company proprietary data, medical) on internal networks and other security associations to communicate within the same department. Nomadic users wanting to "phone home" represent another set of security requirements. These requirements must be tempered with bandwidth challenges. Smaller groups of people may meet their security requirements by setting up "Webs of Trust". ISAKMP exchanges provide these assorted networking communities the ability to present peers with the security functionality that the user supports in an authenticated and protected manner for agreement upon a common set of security attributes, i.e. an interoperable security association.
通信取决于各个网络配置和环境。各组织正在建立虚拟专用网络（VPN），也称为内部网，这将需要一组用于VPN内通信的安全功能，可能需要许多用于VPN外通信的不同安全功能，以支持地理上独立的组织组件、客户、供应商，分包商（拥有自己的VPN）、政府和其他方。大型组织内的部门可能要求多个安全协会分离和保护内部网络上的数据（如人员数据、公司专有数据、医疗数据），并要求其他安全协会在同一部门内进行通信。想要“打电话回家”的游牧用户代表了另一组安全要求。这些要求必须与带宽挑战相协调。较小的人群可以通过建立“信任网”来满足他们的安全要求。ISAKMP交换为这些分类网络社区提供了向对等方提供安全功能的能力，用户以经过身份验证和保护的方式支持这些功能，以便就一组通用的安全属性（即可互操作的安全关联）达成一致。
Security associations must support different encryption algorithms, authentication mechanisms, and key establishment algorithms for other security protocols, as well as IP Security. Security associations must also support host-oriented certificates for lower layer protocols and user- oriented certificates for higher level protocols. Algorithm and mechanism independence is required in applications such as e-mail, remote login, and file transfer, as well as in session oriented protocols, routing protocols, and link layer protocols. ISAKMP provides a common security association and key establishment protocol for this wide range of security protocols, applications, security requirements, and network environments.
安全关联必须支持其他安全协议以及IP安全的不同加密算法、身份验证机制和密钥建立算法。安全关联还必须支持低层协议的面向主机的证书和高层协议的面向用户的证书。在电子邮件、远程登录和文件传输等应用程序中，以及在面向会话的协议、路由协议和链路层协议中，都需要算法和机制独立性。ISAKMP为广泛的安全协议、应用程序、安全要求和网络环境提供了通用的安全关联和密钥建立协议。
ISAKMP is not bound to any specific cryptographic algorithm, key generation technique, or security mechanism. This flexibility is beneficial for a number of reasons. First, it supports the dynamic communications environment described above. Second, the independence from specific security mechanisms and algorithms provides a forward migration path to better mechanisms and algorithms. When improved security mechanisms are developed or new attacks against current encryption algorithms, authentication mechanisms and key exchanges are discovered, ISAKMP will allow the updating of the algorithms and mechanisms without having to develop a completely new KMP or patch the current one.
ISAKMP不受任何特定密码算法、密钥生成技术或安全机制的约束。这种灵活性有很多好处。首先，它支持上述动态通信环境。第二，独立于特定的安全机制和算法为更好的机制和算法提供了向前迁移的途径。当开发改进的安全机制或发现针对当前加密算法、身份验证机制和密钥交换的新攻击时，ISAKMP将允许更新算法和机制，而无需开发全新的KMP或修补当前的KMP。
ISAKMP has basic requirements for its authentication and key exchange components. These requirements guard against denial of service, replay / reflection, man-in-the-middle, and connection hijacking attacks. This is important because these are the types of attacks that are targeted against protocols. Complete Security Association (SA) support, which provides mechanism and algorithm independence, and protection from protocol threats are the strengths of ISAKMP.
ISAKMP对其身份验证和密钥交换组件有基本要求。这些要求可防止拒绝服务、重播/反射、中间人攻击和连接劫持攻击。这很重要，因为这些是针对协议的攻击类型。完整的安全关联（SA）支持，提供机制和算法独立性，并保护免受协议威胁是ISAKMP的优势。
A Security Association (SA) is a relationship between two or more entities that describes how the entities will utilize security services to communicate securely. This relationship is represented by a set of information that can be considered a contract between the entities. The information must be agreed upon and shared between all the entities. Sometimes the information alone is referred to as an SA, but this is just a physical instantiation of the existing relationship. The existence of this relationship, represented by the information, is what provides the agreed upon security information needed by entities to securely interoperate. All entities must adhere to the SA for secure communications to be possible. When accessing SA attributes, entities use a pointer or identifier refered to as the Security Parameter Index (SPI). [SEC-ARCH] provides details on IP Security Associations (SA) and Security Parameter Index (SPI) definitions.
安全关联（SA）是两个或多个实体之间的关系，描述实体将如何利用安全服务进行安全通信。这种关系由一组信息表示，这些信息可以被视为实体之间的契约。信息必须在所有实体之间达成一致并共享。有时信息本身被称为SA，但这只是现有关系的物理实例化。这种关系的存在（由信息表示）提供了实体安全互操作所需的商定安全信息。所有实体必须遵守SA，才能实现安全通信。当访问SA属性时，实体使用一个指针或标识符作为安全参数索引（SPI）。[SEC-ARCH]提供了有关IP安全关联（SA）和安全参数索引（SPI）定义的详细信息。
The SA attributes required and recommended for the IP Security (AH, ESP) are defined in [SEC-ARCH]. The attributes specified for an IP Security SA include, but are not limited to, authentication mechanism, cryptographic algorithm, algorithm mode, key length, and Initialization Vector (IV). Other protocols that provide algorithm and mechanism independent security MUST define their requirements for SA attributes. The separation of ISAKMP from a specific SA definition is important to ensure ISAKMP can es tablish SAs for all possible security protocols and applications.
[SEC-ARCH]中定义了IP安全（AH、ESP）所需和建议的SA属性。为IP安全SA指定的属性包括但不限于认证机制、加密算法、算法模式、密钥长度和初始化向量（IV）。提供独立于算法和机制的安全性的其他协议必须定义其对SA属性的要求。ISAKMP与特定SA定义的分离对于确保ISAKMP能够为所有可能的安全协议和应用程序建立SA非常重要。
NOTE: See [IPDOI] for a discussion of SA attributes that should be considered when defining a security protocol or application.
注意：有关定义安全协议或应用程序时应考虑的SA属性的讨论，请参见[IPDOI]。
In order to facilitate easy identification of specific attributes (e.g. a specific encryption algorithm) among different network entites the attributes must be assigned identifiers and these identifiers must be registered by a central authority. The Internet Assigned Numbers Authority (IANA) provides this function for the Internet.
为了便于在不同网络实体之间轻松识别特定属性（例如，特定加密算法），必须为属性分配标识符，并且这些标识符必须由中央机构注册。Internet分配号码管理局（IANA）为Internet提供此功能。
Security Association (SA) establishment MUST be part of the key management protocol defined for IP based networks. The SA concept is required to support security protocols in a diverse and dynamic networking environment. Just as authentication and key exchange must be linked to provide assurance that the key is established with the authenticated party [DOW92], SA establishment must be linked with the authentication and the key exchange protocol.
安全关联（SA）的建立必须是为基于IP的网络定义的密钥管理协议的一部分。SA概念需要支持多样化和动态网络环境中的安全协议。正如身份验证和密钥交换必须链接以保证密钥是与身份验证方建立的[DOW92]，SA建立必须与身份验证和密钥交换协议链接。
ISAKMP provides the protocol exchanges to establish a security association between negotiating entities followed by the establishment of a security association by these negotiating entities in behalf of some protocol (e.g. ESP/AH). First, an initial protocol exchange allows a basic set of security attributes to be agreed upon. This basic set provides protection for subsequent ISAKMP exchanges. It also indicates the authentication method and key exchange that will be performed as part of the ISAKMP protocol. If a basic set of security attributes is already in place between the negotiating server entities, the initial ISAKMP exchange may be skipped and the establishment of a security association can be done directly. After the basic set of security attributes has been agreed upon, initial identity authenticated, and required keys generated, the established SA can be used for subsequent communications by the entity that invoked ISAKMP. The basic set of SA attributes that MUST be implemented to provide ISAKMP interoperability are defined in Appendix A.
ISAKMP提供协议交换，以在谈判实体之间建立安全关联，然后由这些谈判实体代表某些协议（如ESP/AH）建立安全关联。首先，初始协议交换允许商定一组基本的安全属性。此基本集为后续ISAKMP交换提供保护。它还指示将作为ISAKMP协议的一部分执行的身份验证方法和密钥交换。如果协商服务器实体之间已经存在一组基本的安全属性，则可以跳过初始ISAKMP交换，直接建立安全关联。在商定基本的安全属性集、初始身份验证和生成所需密钥后，已建立的SA可用于调用ISAKMP的实体的后续通信。附录A中定义了为提供ISAKMP互操作性而必须实现的基本SA属性集。
A very important step in establishing secure network communications is authentication of the entity at the other end of the communication. Many authentication mechanisms are available. Authentication mechanisms fall into two catagories of strength - weak and strong. Sending cleartext keys or other unprotected authenticating information over a network is weak, due to the threat of reading them with a network sniffer. Additionally, sending one-way hashed poorly-chosen keys with low entropy is also weak, due to the threat of brute-force guessing attacks on the sniffed messages. While passwords can be used for establishing identity, they are not considered in this context because of recent statements from the Internet Architecture Board [IAB]. Digital signatures, such as the Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) signature, are public key based strong authentication mechanisms. When using public key digital signatures each entity requires a public key and a private key. Certificates are an essential part of a digital signature authentication mechanism. Certificates bind a specific entity's identity (be it host, network, user, or
建立安全网络通信的一个非常重要的步骤是对通信另一端的实体进行身份验证。有许多认证机制可用。认证机制分为两类：弱和强。通过网络发送明文密钥或其他不受保护的身份验证信息是很弱的，因为网络嗅探器可能会读取这些信息。此外，由于嗅探到的消息受到暴力猜测攻击的威胁，因此发送单向散列的低熵糟糕选择的密钥也很弱。虽然密码可用于建立身份，但由于互联网体系结构委员会[IAB]最近的声明，在这种情况下不考虑密码。数字签名，如数字签名标准（DSS）和Rivest-Shamir-Adleman（RSA）签名，是基于公钥的强身份验证机制。使用公钥数字签名时，每个实体都需要公钥和私钥。证书是数字签名认证机制的重要组成部分。证书绑定特定实体的身份（无论是主机、网络、用户还是服务器）
application) to its public keys and possibly other security-related information such as privileges, clearances, and compartments. Authentication based on digital signatures requires a trusted third party or certificate authority to create, sign and properly distribute certificates. For more detailed information on digital signatures, such as DSS and RSA, and certificates see [Schneier].
应用程序）的公钥和可能的其他安全相关信息，如特权、许可证和隔间。基于数字签名的身份验证要求可信的第三方或证书颁发机构创建、签署和正确分发证书。有关数字签名（如DSS和RSA）和证书的更多详细信息，请参阅[Schneier]。
Certificates require an infrastructure for generation, verification, revocation, management and distribution. The Internet Policy Registration Authority (IPRA) [RFC-1422] has been established to direct this infrastructure for the IETF. The IPRA certifies Policy Certification Authorities (PCA). PCAs control Certificate Authorities (CA) which certify users and subordinate entities. Current certificate related work includes the Domain Name System (DNS) Security Extensions [DNSSEC] which will provide signed entity keys in the DNS. The Public Key Infrastucture (PKIX) working group is specifying an Internet profile for X.509 certificates. There is also work going on in industry to develop X.500 Directory Services which would provide X.509 certificates to users. The U.S. Post Office is developing a (CA) hierarchy. The NIST Public Key Infrastructure Working Group has also been doing work in this area. The DOD Multi Level Information System Security Initiative (MISSI) program has begun deploying a certificate infrastructure for the U.S. Government. Alternatively, if no infrastructure exists, the PGP Web of Trust certificates can be used to provide user authentication and privacy in a community of users who know and trust each other.
证书需要用于生成、验证、吊销、管理和分发的基础结构。互联网政策注册局（IPRA）[RFC-1422]已成立，以指导IETF的基础设施。IPRA认证政策认证机构（PCA）。PCAs控制认证机构（CA），认证用户和下级实体。当前与证书相关的工作包括域名系统（DNS）安全扩展[DNSSEC]，它将在DNS中提供签名实体密钥。公钥基础设施（PKIX）工作组正在为X.509证书指定Internet配置文件。工业界也在努力开发X.500目录服务，为用户提供X.509证书。美国邮政局正在建立一个（CA）等级体系。NIST公钥基础设施工作组也在这方面开展工作。国防部多级信息系统安全倡议（MSI）计划已开始为美国政府部署证书基础设施。或者，如果不存在基础设施，则可以使用PGP信任证书网在相互了解和信任的用户社区中提供用户身份验证和隐私。
An entity's name is its identity and is bound to its public keys in certificates. The CA MUST define the naming semantics for the certificates it issues. See the UNINETT PCA Policy Statements [Berge] for an example of how a CA defines its naming policy. When the certificate is verified, the name is verified and that name will have meaning within the realm of that CA. An example is the DNS security extensions which make DNS servers CAs for the zones and nodes they serve. Resource records are provided for public keys and signatures on those keys. The names associated with the keys are IP addresses and domain names which have meaning to entities accessing the DNS for this information. A Web of Trust is another example. When webs of trust are set up, names are bound with the public keys. In PGP the name is usually the entity's e-mail address which has meaning to those, and only those, who understand e-mail. Another web of trust could use an entirely different naming scheme.
实体的名称是其标识，并绑定到证书中的公钥。CA必须为其颁发的证书定义命名语义。有关CA如何定义其命名策略的示例，请参见UNINETT PCA策略语句[Berge]。当证书被验证时，名称将被验证，并且该名称将在该CA的领域内具有意义。一个例子是DNS安全扩展，它使DNS服务器成为其服务的区域和节点的CA。为公钥和这些密钥上的签名提供资源记录。与密钥相关联的名称是IP地址和域名，它们对访问DNS以获取此信息的实体具有意义。信任网是另一个例子。当建立信任网时，名称将与公钥绑定。在PGP中，名称通常是实体的电子邮件地址，它对理解电子邮件的人具有意义，并且仅对理解电子邮件的人具有意义。另一个信任网络可以使用完全不同的命名方案。
Strong authentication MUST be provided on ISAKMP exchanges. Without being able to authenticate the entity at the other end, the Security Association (SA) and session key established are suspect. Without authentication you are unable to trust an entity's identification, which makes access control questionable. While encryption (e.g. ESP) and integrity (e.g. AH) will protect subsequent communications from passive eavesdroppers, without authentication it is possible that the SA and key may have been established with an adversary who performed an active man-in-the-middle attack and is now stealing all your personal data.
必须在ISAKMP交换上提供强身份验证。如果无法对另一端的实体进行身份验证，则建立的安全关联（SA）和会话密钥是可疑的。如果没有身份验证，您将无法信任实体的标识，这会使访问控制受到质疑。虽然加密（如ESP）和完整性（如AH）将保护后续通信不受被动窃听者的攻击，但在没有身份验证的情况下，SA和密钥可能是与执行主动中间人攻击的对手建立的，现在正在窃取您的所有个人数据。
A digital signature algorithm MUST be used within ISAKMP's authentication component. However, ISAKMP does not mandate a specific signature algorithm or certificate authority (CA). ISAKMP allows an entity initiating communications to indicate which CAs it supports. After selection of a CA, the protocol provides the messages required to support the actual authentication exchange. The protocol provides a facility for identification of different certificate authorities, certificate types (e.g. X.509, PKCS #7, PGP, DNS SIG and KEY records), and the exchange of the certificates identified.
必须在ISAKMP的身份验证组件中使用数字签名算法。但是，ISAKMP并不要求特定的签名算法或证书颁发机构（CA）。ISAKMP允许发起通信的实体指示其支持的CA。选择CA后，协议提供支持实际身份验证交换所需的消息。该协议提供了一种识别不同证书颁发机构、证书类型（如X.509、PKCS#7、PGP、DNS SIG和密钥记录）以及交换已识别证书的工具。
ISAKMP utilizes digital signatures, based on public key cryptography, for authentication. There are other strong authentication systems available, which could be specified as additional optional authentication mechanisms for ISAKMP. Some of these authentication systems rely on a trusted third party called a key distribution center (KDC) to distribute secret session keys. An example is Kerberos, where the trusted third party is the Kerberos server, which holds secret keys for all clients and servers within its network domain. A client's proof that it holds its secret key provides authenticaton to a server.
ISAKMP利用基于公钥加密的数字签名进行身份验证。还有其他可用的强身份验证系统，可以指定为ISAKMP的附加可选身份验证机制。其中一些身份验证系统依赖于一个称为密钥分发中心（KDC）的可信第三方来分发秘密会话密钥。例如Kerberos，其中受信任的第三方是Kerberos服务器，它为其网络域内的所有客户端和服务器持有密钥。客户机持有其密钥的证明为服务器提供了身份验证。
The ISAKMP specification does not specify the protocol for communicating with the trusted third parties (TTP) or certificate directory services. These protocols are defined by the TTP and directory service themselves and are outside the scope of this specification. The use of these additional services and protocols will be described in a Key Exchange specific document.
ISAKMP规范未指定与可信第三方（TTP）或证书目录服务通信的协议。这些协议由TTP和目录服务本身定义，不在本规范的范围内。这些附加服务和协议的使用将在密钥交换特定文档中描述。
Public key cryptography is the most flexible, scalable, and efficient way for users to obtain the shared secrets and session keys needed to support the large number of ways Internet users will interoperate. Many key generation algorithms, that have different properties, are
公钥密码术是用户获取共享秘密和会话密钥的最灵活、可扩展和最有效的方法，这些共享秘密和会话密钥是支持Internet用户进行大量互操作所需的。许多具有不同属性的密钥生成算法
available to users (see [DOW92], [ANSI], and [Oakley]). Properties of key exchange protocols include the key establishment method, authentication, symmetry, perfect forward secrecy, and back traffic protection.
可供用户使用（参见[DOW92]、[ANSI]和[Oakley]）。密钥交换协议的特性包括密钥建立方法、认证、对称性、完全前向保密性和后向流量保护。
NOTE: Cryptographic keys can protect information for a considerable length of time. However, this is based on the assumption that keys used for protection of communications are destroyed after use and not kept for any reason.
注意：加密密钥可以在相当长的时间内保护信息。然而，这是基于这样一种假设，即用于保护通信的钥匙在使用后会被销毁，并且由于任何原因不会被保存。
Key Establishment (Key Generation / Key Transport): The two common methods of using public key cryptography for key establishment are key transport and key generation. An example of key transport is the use of the RSA algorithm to encrypt a randomly generated session key (for encrypting subsequent communications) with the recipient's public key. The encrypted random key is then sent to the recipient, who decrypts it using his private key. At this point both sides have the same session key, however it was created based on input from only one side of the communications. The benefit of the key transport method is that it has less computational overhead than the following method. The Diffie-Hellman (D-H) algorithm illustrates key generation using public key cryptography. The D-H algorithm is begun by two users exchanging public information. Each user then mathematically combines the other's public information along with their own secret information to compute a shared secret value. This secret value can be used as a session key or as a key encryption key for encrypting a randomly generated session key. This method generates a session key based on public and secret information held by both users. The benefit of the D-H algorithm is that the key used for encrypting messages is based on information held by both users and the independence of keys from one key exchange to another provides perfect forward secrecy. Detailed descriptions of these algorithms can be found in [Schneier]. There are a number of variations on these two key generation schemes and these variations do not necessarily interoperate.
密钥建立（密钥生成/密钥传输）：使用公钥密码进行密钥建立的两种常用方法是密钥传输和密钥生成。密钥传输的一个例子是使用RSA算法用接收方的公钥加密随机生成的会话密钥（用于加密后续通信）。然后将加密的随机密钥发送给接收者，接收者使用他的私钥对其进行解密。此时，双方都有相同的会话密钥，但是它是根据通信的一方的输入创建的。密钥传输方法的优点是它比下面的方法具有更少的计算开销。Diffie-Hellman（D-H）算法说明了使用公钥加密技术生成密钥。D-H算法由两个用户交换公共信息开始。然后，每个用户将对方的公共信息与自己的秘密信息进行数学组合，以计算共享秘密值。该秘密值可用作会话密钥或密钥加密密钥，用于加密随机生成的会话密钥。该方法基于两个用户持有的公开和秘密信息生成会话密钥。D-H算法的好处是，用于加密消息的密钥基于用户双方持有的信息，并且密钥从一个密钥交换到另一个密钥交换的独立性提供了完美的前向保密性。有关这些算法的详细说明，请参见[Schneier]。这两种密钥生成方案有许多变体，这些变体不一定是互操作的。
Key Exchange Authentication: Key exchanges may be authenticated during the protocol or after protocol completion. Authentication of the key exchange during the protocol is provided when each party provides proof it has the secret session key before the end of the protocol. Proof can be provided by encrypting known data in the secret session key during the protocol echange. Authentication after the protocol must occur in subsequent commu nications. Authentication during the protocol is preferred so subsequent communications are not initiated if the secret session key is not established with the desired party.
密钥交换身份验证：密钥交换可以在协议期间或协议完成后进行身份验证。在协议结束前，当各方提供其拥有秘密会话密钥的证明时，就提供了协议期间密钥交换的身份验证。在协议更改期间，可以通过加密秘密会话密钥中的已知数据来提供证据。协议之后的身份验证必须在后续通信中进行。首选在协议期间进行身份验证，因此如果未与所需方建立秘密会话密钥，则不会启动后续通信。
Key Exchange Symmetry: A key exchange provides symmetry if either party can initiate the exchange and exchanged messages can cross in transit without affecting the key that is generated. This is desirable so that computation of the keys does not require either party to know who initated the exchange. While key exchange symmetry is desirable, symmetry in the entire key management protocol may provide a vulnerablity to reflection attacks.
密钥交换对称性：如果任何一方可以发起交换，并且交换的消息可以在传输过程中交叉而不影响生成的密钥，则密钥交换提供对称性。这是可取的，以便密钥的计算不需要任何一方知道是谁发起了交换。虽然密钥交换对称性是可取的，但整个密钥管理协议中的对称性可能会提供对反射攻击的脆弱性。
Perfect Forward Secrecy: As described in [DOW92], an authenticated key exchange protocol provides perfect forward secrecy if disclosure of longterm secret keying material does not compromise the secrecy of the exchanged keys from previous communications. The property of perfect forward secrecy does not apply to key exchange without authentication.
完全前向保密性：如[DOW92]所述，如果长期保密密钥材料的披露不会损害先前通信中交换密钥的保密性，则经过身份验证的密钥交换协议可提供完全前向保密性。完全前向保密的性质不适用于未经认证的密钥交换。
An authenticated key exchange MUST be supported by ISAKMP. Users SHOULD choose additional key establishment algorithms based on their requirements. ISAKMP does not specify a specific key exchange. However, [IKE] describes a proposal for using the Oakley key exchange [Oakley] in conjunction with ISAKMP. Requirements that should be evaluated when choosing a key establishment algorithm include establishment method (generation vs. transport), perfect forward secrecy, computational overhead, key escrow, and key strength. Based on user requirements, ISAKMP allows an entity initiating communications to indicate which key exchanges it supports. After selection of a key exchange, the protocol provides the messages required to support the actual key establishment.
ISAKMP必须支持经过身份验证的密钥交换。用户应根据自己的需求选择其他密钥建立算法。ISAKMP没有指定特定的密钥交换。然而，[IKE]描述了将Oakley密钥交换[Oakley]与ISAKMP结合使用的建议。选择密钥建立算法时应评估的要求包括建立方法（生成与传输）、完全前向保密性、计算开销、密钥托管和密钥强度。根据用户需求，ISAKMP允许发起通信的实体指示它支持哪些密钥交换。选择密钥交换后，协议提供支持实际密钥建立所需的消息。
Of the numerous security services available, protection against denial of service always seems to be one of the most difficult to address. A "cookie" or anti-clogging token (ACT) is aimed at protecting the computing resources from attack without spending excessive CPU resources to determine its authenticity. An exchange prior to CPU-intensive public key operations can thwart some denial of service attempts (e.g. simple flooding with bogus IP source addresses). Absolute protection against denial of service is impossible, but this anti-clogging token provides a technique for making it easier to handle. The use of an anti-clogging token was introduced by Karn and Simpson in [Karn].
在众多可用的安全服务中，防止拒绝服务似乎始终是最难解决的问题之一。“cookie”或反阻塞令牌（ACT）旨在保护计算资源免受攻击，而无需花费过多的CPU资源来确定其真实性。CPU密集型公钥操作之前的交换可以阻止某些拒绝服务尝试（例如，使用虚假IP源地址的简单泛洪）。绝对防止拒绝服务是不可能的，但这种防阻塞令牌提供了一种技术，使其更易于处理。Karn和Simpson在[Karn]中介绍了防堵塞令牌的使用。
It should be noted that in the exchanges shown in section 4, the anticlogging mechanism should be used in conjuction with a garbage-state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti-clogging only phase, as was done in [Karn].
应该注意的是，在第4节所示的交换中，反日志机制应该与垃圾状态收集机制结合使用；攻击者仍然可以使用具有虚假IP地址的数据包来淹没服务器，并导致创建状态。使用ISAKMP的协议应该采用这种积极的内存管理技术，而不是像[Karn]中所做的那样，只经过初始的抗阻塞阶段。
ISAKMP prevents connection hijacking by linking the authentication, key exchange and security association exchanges. This linking prevents an attacker from allowing the authentication to complete and then jumping in and impersonating one entity to the other during the key and security association exchanges.
ISAKMP通过链接身份验证、密钥交换和安全关联交换来防止连接劫持。此链接可防止攻击者允许身份验证完成，然后在密钥和安全关联交换期间跳入并模拟一个实体到另一个实体。
Man-in-the-Middle attacks include interception, insertion, deletion, and modification of messages, reflecting messages back at the sender, replaying old messages and redirecting messages. ISAKMP features prevent these types of attacks from being successful. The linking of the ISAKMP exchanges prevents the insertion of messages in the protocol exchange. The ISAKMP protocol state machine is defined so deleted messages will not cause a partial SA to be created, the state machine will clear all state and return to idle. The state machine also prevents reflection of a message from causing harm. The requirement for a new cookie with time variant material for each new SA establishment prevents attacks that involve replaying old messages. The ISAKMP strong authentication requirement prevents an SA from being established with anyone other than the intended party. Messages may be redirected to a different destination or modified but this will be detected and an SA will not be established. The ISAKMP specification defines where abnormal processing has occurred and recommends notifying the appropriate party of this abnormality.
中间人攻击包括拦截、插入、删除和修改消息、将消息反射回发件人、重放旧消息和重定向消息。ISAKMP功能阻止这些类型的攻击成功。ISAKMP交换的链接可防止在协议交换中插入消息。ISAKMP协议状态机的定义使删除的消息不会导致创建部分SA，状态机将清除所有状态并返回空闲状态。状态机还可以防止消息的反射造成损害。每个新SA机构都需要一个具有时变材料的新cookie，以防止涉及重放旧消息的攻击。ISAKMP强身份验证要求防止与目标方以外的任何人建立SA。消息可能会被重定向到其他目的地或被修改，但这将被检测到，并且不会建立SA。ISAKMP规范定义了异常处理发生的位置，并建议将此异常通知相关方。
It is expected that multicast communications will require the same security services as unicast communications and may introduce the need for additional security services. The issues of distributing SPIs for multicast traffic are presented in [SEC-ARCH]. Multicast security issues are also discussed in [RFC-1949] and [BC]. A future extension to ISAKMP will support multicast key distribution. For an introduction to the issues related to multicast security, consult the Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's research in this area.
预计多播通信将需要与单播通信相同的安全服务，并且可能需要额外的安全服务。[SEC-ARCH]中介绍了为多播流量分配SPI的问题。[RFC-1949]和[BC]中也讨论了多播安全问题。ISAKMP的未来扩展将支持多播密钥分发。有关多播安全相关问题的介绍，请参考互联网草案[RFC-2094]和[RFC-2093]，其中描述了斯巴达在该领域的研究。
2 Terminology and Concepts
2术语和概念
Security Protocol: A Security Protocol consists of an entity at a single point in the network stack, performing a security service for network communication. For example, IPSEC ESP and IPSEC AH are two different security protocols. TLS is another example. Security Protocols may perform more than one service, for example providing integrity and confidentiality in one module.
安全协议：安全协议由网络堆栈中单个点的实体组成，为网络通信执行安全服务。例如，IPSEC ESP和IPSEC AH是两种不同的安全协议。TLS是另一个例子。安全协议可以执行多个服务，例如在一个模块中提供完整性和机密性。
Protection Suite: A protection suite is a list of the security services that must be applied by various security protocols. For example, a protection suite may consist of DES encryption in IP ESP, and keyed MD5 in IP AH. All of the protections in a suite must be treated as a single unit. This is necessary because security services in different security protocols can have subtle interactions, and the effects of a suite must be analyzed and verified as a whole.
保护套件：保护套件是必须由各种安全协议应用的安全服务的列表。例如，保护套件可能包括IP ESP中的DES加密和IP AH中的密钥MD5。一套保护装置中的所有保护装置必须视为一个单独的装置。这是必要的，因为不同安全协议中的安全服务可能会有微妙的交互，并且必须从整体上分析和验证套件的效果。
Security Association (SA): A Security Association is a security-protocol- specific set of parameters that completely defines the services and mechanisms necessary to protect traffic at that security protocol location. These parameters can include algorithm identifiers, modes, cryptographic keys, etc. The SA is referred to by its associated security protocol (for example, "ISAKMP SA", "ESP SA", "TLS SA").
安全关联（SA）：安全关联是一组特定于安全协议的参数，完全定义了在该安全协议位置保护流量所需的服务和机制。这些参数可包括算法标识符、模式、加密密钥等。SA由其相关安全协议（例如，“ISAKMP SA”、“ESP SA”、“TLS SA”）引用。
ISAKMP SA: An SA used by the ISAKMP servers to protect their own traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs.
ISAKMP SA：ISAKMP服务器用于保护其自身流量的SA。第2.3节和第2.4节提供了有关ISAKMP SAs的更多详细信息。
Security Parameter Index (SPI): An identifier for a Security Assocation, relative to some security protocol. Each security protocol has its own "SPI-space". A (security protocol, SPI) pair may uniquely identify an SA. The uniqueness of the SPI is implementation dependent, but could be based per system, per protocol, or other options. Depending on the DOI, additional information (e.g. host address) may be necessary to identify an SA. The DOI will also determine which SPIs (i.e. initiator's or responder's) are sent during communication.
安全参数索引（SPI）：安全关联的标识符，相对于某些安全协议。每个安全协议都有自己的“SPI空间”。（安全协议，SPI）对可以唯一地标识SA。SPI的唯一性取决于实现，但可以基于每个系统、每个协议或其他选项。根据DOI，可能需要其他信息（例如主机地址）来识别SA。DOI还将确定在通信期间发送哪些SPI（即发起方或响应方）。
Domain of Interpretation: A Domain of Interpretation (DOI) defines payload formats, exchange types, and conventions for naming security-relevant information such as security policies or cryptographic algorithms and modes. A Domain of Interpretation (DOI) identifier is used to interpret the payloads of ISAKMP payloads. A system SHOULD support multiple Domains of Interpretation simultaneously. The concept of a DOI is based on previous work by
解释域：解释域（DOI）定义有效负载格式、交换类型和命名安全相关信息（如安全策略或加密算法和模式）的约定。解释域（DOI）标识符用于解释ISAKMP有效载荷的有效载荷。一个系统应该同时支持多个解释领域。内政部的概念是基于
the TSIG CIPSO Working Group, but extends beyond security label interpretation to include naming and interpretation of security services. A DOI defines:
TSIG CIPSO工作组，但超出了安全标签解释范围，包括安全服务的命名和解释。内政部定义：
o A "situation": the set of information that will be used to determine the required security services.
o “情况”：用于确定所需安全服务的一组信息。
o The set of security policies that must, and may, be supported.
o 必须支持且可能支持的一组安全策略。
o A syntax for the specification of proposed security services.
o 拟定安全服务规范的语法。
o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, security policy attributes, and certificate authorities.
o 一种命名安全相关信息的方案，包括加密算法、密钥交换算法、安全策略属性和证书颁发机构。
o The specific formats of the various payload contents.
o 各种有效负载内容的特定格式。
o Additional exchange types, if required.
o 其他交换类型（如果需要）。
The rules for the IETF IP Security DOI are presented in [IPDOI]. Specifications of the rules for customized DOIs will be presented in separate documents.
IETF IP安全DOI的规则见[IPDOI]。定制内政部的规则规范将在单独的文件中提出。
Situation: A situation contains all of the security-relevant information that a system considers necessary to decide the security services required to protect the session being negotiated. The situation may include addresses, security classifications, modes of operation (normal vs. emergency), etc.
情景：情景包含系统认为决定保护正在协商的会话所需的安全服务所必需的所有安全相关信息。情况可能包括地址、安全分类、操作模式（正常与紧急）等。
Proposal: A proposal is a list, in decreasing order of preference, of the protection suites that a system considers acceptable to protect traffic under a given situation.
建议：建议是系统认为在给定情况下可接受的保护流量的保护套件列表，按优先顺序递减。
Payload: ISAKMP defines several types of payloads, which are used to transfer information such as security association data, or key exchange data, in DOI-defined formats. A payload consists of a generic payload header and a string of octects that is opaque to ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and interpret these payloads. Multiple payloads can be sent in a single ISAKMP message. See section 3 for more details on the payload types, and [IPDOI] for the formats of the IETF IP Security DOI payloads.
有效载荷：ISAKMP定义了几种类型的有效载荷，用于以DOI定义的格式传输信息，如安全关联数据或密钥交换数据。有效负载由一个通用有效负载头和一个对ISAKMP不透明的八位字节字符串组成。ISAKMP使用特定于DOI的功能来合成和解释这些有效负载。在一条ISAKMP消息中可以发送多个有效负载。有关有效负载类型的更多详细信息，请参见第3节；IETF IP安全DOI有效负载的格式请参见[IPDOI]。
Exchange Type: An exchange type is a specification of the number of messages in an ISAKMP exchange, and the payload types that are contained in each of those messages. Each exchange type is designed to provide a particular set of security services, such as anonymity of the participants, perfect forward secrecy of the keying material, authentication of the participants, etc. Section 4.1 defines the
交换类型：交换类型是ISAKMP交换中的消息数量以及每个消息中包含的有效负载类型的规范。每种交换类型旨在提供一组特定的安全服务，如参与者的匿名性、密钥材料的完美前向保密性、参与者的身份验证等。第4.1节定义了
default set of ISAKMP exchange types. Other exchange types can be added to support additional key exchanges, if required.
ISAKMP交换类型的默认集。如果需要，可以添加其他交换类型以支持其他密钥交换。
Figure 1 is a high level view of the placement of ISAKMP within a system context in a network architecture. An important part of negotiating security services is to consider the entire "stack" of individual SAs as a unit. This is referred to as a "protection suite".
图1是网络体系结构中系统上下文中ISAKMP位置的高级视图。安全服务谈判的一个重要部分是把个人SAS的整个“栈”作为一个单元来考虑。这被称为“保护套件”。
+------------+ +--------+ +--------------+
! DOI ! ! ! ! Application !
! Definition ! <----> ! ISAKMP ! ! Process !
+------------+ --> ! ! !--------------!
+--------------+ ! +--------+ ! Appl Protocol!
! Key Exchange ! ! ^ ^ +--------------+
! Definition !<-- ! ! ^
+--------------+ ! ! !
! ! !
!----------------! ! !
v ! !
+-------+ v v
! API ! +---------------------------------------------+
+-------+ ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! Security ! <----> ! IP !
! Protocol ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
+------------+ +--------+ +--------------+
! DOI ! ! ! ! Application !
! Definition ! <----> ! ISAKMP ! ! Process !
+------------+ --> ! ! !--------------!
+--------------+ ! +--------+ ! Appl Protocol!
! Key Exchange ! ! ^ ^ +--------------+
! Definition !<-- ! ! ^
+--------------+ ! ! !
! ! !
!----------------! ! !
v ! !
+-------+ v v
! API ! +---------------------------------------------+
+-------+ ! Socket Layer !
! !---------------------------------------------!
v ! Transport Protocol (TCP / UDP) !
+----------+ !---------------------------------------------!
! Security ! <----> ! IP !
! Protocol ! !---------------------------------------------!
+----------+ ! Link Layer Protocol !
+---------------------------------------------+
Figure 1: ISAKMP Relationships
图1:ISAKMP关系
ISAKMP offers two "phases" of negotiation. In the first phase, two entities (e.g. ISAKMP servers) agree on how to protect further negotiation traffic between themselves, establishing an ISAKMP SA. This ISAKMP SA is then used to protect the negotiations for the Protocol SA being requested. Two entities (e.g. ISAKMP servers) can negotiate (and have active) multiple ISAKMP SAs.
ISAKMP提供了两个“阶段”的谈判。在第一阶段，两个实体（例如ISAKMP服务器）就如何保护它们之间的进一步协商流量达成一致，建立ISAKMP SA。然后，此ISAKMP SA用于保护所请求协议SA的协商。两个实体（如ISAKMP服务器）可以协商（并拥有活动的）多个ISAKMP SA。
The second phase of negotiation is used to establish security associations for other security protocols. This second phase can be used to establish many security associations. The security associations established by ISAKMP during this phase can be used by a security protocol to protect many message/data exchanges.
协商的第二阶段用于为其他安全协议建立安全关联。第二阶段可用于建立许多安全关联。安全协议可以使用ISAKMP在此阶段建立的安全关联来保护许多消息/数据交换。
While the two-phased approach has a higher start-up cost for most simple scenarios, there are several reasons that it is beneficial for most cases.
虽然两阶段方法在大多数简单情况下具有较高的启动成本，但有几个原因表明它在大多数情况下是有益的。
First, entities (e.g. ISAKMP servers) can amortize the cost of the first phase across several second phase negotiations. This allows multiple SAs to be established between peers over time without having to start over for each communication.
首先，实体（如ISAKMP服务器）可以在多个第二阶段谈判中分摊第一阶段的成本。这允许随着时间的推移在对等方之间建立多个SA，而无需为每次通信重新启动。
Second, security services negotiated during the first phase provide security properties for the second phase. For example, after the first phase of negotiation, the encryption provided by the ISAKMP SA can provide identity protection, potentially allowing the use of simpler second-phase exchanges. On the other hand, if the channel established during the first phase is not adequate to protect identities, then the second phase must negotiate adequate security mechanisms.
第二，在第一阶段协商的安全服务为第二阶段提供安全属性。例如，在第一阶段协商之后，ISAKMP SA提供的加密可以提供身份保护，可能允许使用更简单的第二阶段交换。另一方面，如果在第一阶段建立的通道不足以保护身份，那么第二阶段必须协商适当的安全机制。
Third, having an ISAKMP SA in place considerably reduces the cost of ISAKMP management activity - without the "trusted path" that an ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have to go through a complete re-authentication for each error notification or deletion of an SA.
第三，有一个ISAKMP SA可以大大降低ISAKMP管理活动的成本——如果没有ISAKMP SA提供的“受信任路径”，实体（例如ISAKMP服务器）必须对SA的每次错误通知或删除进行完整的重新身份验证。
Negotiation during each phase is accomplished using ISAKMP-defined exchanges (see section 4) or exchanges defined for a key exchange within a DOI.
每个阶段中的协商都是使用ISAKMP定义的交换（见第4节）或为DOI内的密钥交换定义的交换来完成的。
Note that security services may be applied differently in each negotiation phase. For example, different parties are being authenticated during each of the phases of negotiation. During the first phase, the parties being authenticated may be the ISAKMP servers/hosts, while during the second phase, users or application level programs are being authenticated.
请注意，在每个协商阶段，安全服务的应用可能会有所不同。例如，在谈判的每个阶段，不同的当事方都在接受身份验证。在第一阶段，被认证的各方可能是ISAKMP服务器/主机，而在第二阶段，用户或应用程序级程序正在被认证。
While bootstrapping secure channels between systems, ISAKMP cannot assume the existence of security services, and must provide some protections for itself. Therefore, ISAKMP considers an ISAKMP Security Association to be different than other types, and manages ISAKMP SAs itself, in their own name space. ISAKMP uses the two
在引导系统之间的安全通道时，ISAKMP不能假定存在安全服务，必须为自己提供一些保护。因此，ISAKMP认为ISAKMP安全关联不同于其他类型，并在其自己的名称空间中管理ISAKMP SA本身。ISAKMP使用两个
cookie fields in the ISAKMP header to identify ISAKMP SAs. The Message ID in the ISAKMP Header and the SPI field in the Proposal payload are used during SA establishment to identify the SA for other security protocols. The interpretation of these four fields is dependent on the operation taking place.
ISAKMP标头中的cookie字段，用于标识ISAKMP SA。在SA建立过程中，ISAKMP报头中的消息ID和提案有效负载中的SPI字段用于为其他安全协议标识SA。这四个字段的解释取决于正在进行的操作。
The following table shows the presence or absence of several fields during SA establishment. The following fields are necessary for various operations associated with SA establishment: cookies in the ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in the Proposal payload. An 'X' in the column means the value MUST be present. An 'NA' in the column means a value in the column is Not Applicable to the operation.
下表显示了SA建立期间是否存在多个字段。以下字段是与SA建立相关的各种操作所必需的：ISAKMP标头中的Cookie、ISAKMP标头消息ID字段和提案有效负载中的SPI字段。列中的“X”表示该值必须存在。列中的“NA”表示列中的值不适用于该操作。
# Operation I-Cookie R-Cookie Message ID SPI (1) Start ISAKMP SA negotiation X 0 0 0 (2) Respond ISAKMP SA negotiation X X 0 0 (3) Init other SA negotiation X X X X (4) Respond other SA negotiation X X X X (5) Other (KE, ID, etc.) X X X/0 NA (6) Security Protocol (ESP, AH) NA NA NA X
#操作I-Cookie R-Cookie消息ID SPI（1）启动ISAKMP SA协商X 0 0（2）响应ISAKMP SA协商X 0（3）初始化其他SA协商X X X（4）响应其他SA协商X X X（5）其他（KE、ID等）X X X/0 NA（6）安全协议（ESP、AH）NA X
In the first line (1) of the table, the initiator includes the Initiator Cookie field in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1.
在表的第一行（1）中，启动器使用第2.5.3节和第3.1节中概述的步骤在ISAKMP头中包含启动器Cookie字段。
In the second line (2) of the table, the responder includes the Initiator and Responder Cookie fields in the ISAKMP Header, using the procedures outlined in sections 2.5.3 and 3.1. Additional messages may be exchanged between ISAKMP peers, depending on the ISAKMP exchange type used during the phase 1 negotiation. Once the phase 1 exchange is completed, the Initiator and Responder cookies are included in the ISAKMP Header of all subsequent communications between the ISAKMP peers.
在表的第二行（2）中，响应程序使用第2.5.3节和第3.1节中概述的过程在ISAKMP头中包括启动器和响应程序Cookie字段。根据阶段1协商期间使用的ISAKMP交换类型，可以在ISAKMP对等方之间交换其他消息。一旦阶段1交换完成，发起方和响应方cookie将包含在ISAKMP对等方之间所有后续通信的ISAKMP头中。
During phase 1 negotiations, the initiator and responder cookies determine the ISAKMP SA. Therefore, the SPI field in the Proposal payload is redundant and MAY be set to 0 or it MAY contain the transmitting entity's cookie.
在第1阶段协商期间，发起方和响应方cookie确定ISAKMP SA。因此，提议有效载荷中的SPI字段是冗余的，可以设置为0，或者它可以包含发送实体的cookie。
In the third line (3) of the table, the initiator associates a Message ID with the Protocols contained in the SA Proposal. This Message ID and the initiator's SPI(s) to be associated with each protocol in the Proposal are sent to the responder. The SPI(s) will be used by the security protocols once the phase 2 negotiation is completed.
在表的第三行（3）中，启动器将消息ID与SA提案中包含的协议相关联。将此消息ID和要与提案中的每个协议关联的发起方SPI发送给响应方。一旦第2阶段协商完成，安全协议将使用SPI。
In the fourth line (4) of the table, the responder includes the same Message ID and the responder's SPI(s) to be associated with each protocol in the accepted Proposal. This information is returned to the initiator.
在表的第四行（4）中，响应者包括相同的消息ID和响应者的SPI，以与接受的提议中的每个协议相关联。此信息将返回给启动器。
In the fifth line (5) of the table, the initiator and responder use the Message ID field in the ISAKMP Header to keep track of the in-progress protocol negotiation. This is only applicable for a phase 2 exchange and the value MUST be 0 for a phase 1 exchange because the combined cookies identify the ISAKMP SA. The SPI field in the Proposal payload is not applicable because the Proposal payload is only used during the SA negotiation message exchange (steps 3 and 4).
在表的第五行（5）中，发起方和响应方使用ISAKMP头中的Message ID字段来跟踪正在进行的协议协商。这仅适用于阶段2交换，并且对于阶段1交换，该值必须为0，因为组合cookie标识ISAKMP SA。提案有效负载中的SPI字段不适用，因为提案有效负载仅在SA协商消息交换期间使用（步骤3和4）。
In the sixth line (6) of the table, the phase 2 negotiation is complete. The security protocols use the SPI(s) to determine which security services and mechanisms to apply to the communication between them. The SPI value shown in the sixth line (6) is not the SPI field in the Proposal payload, but the SPI field contained within the security protocol header.
在表的第六行（6）中，第2阶段协商已完成。安全协议使用SPI来确定应用于它们之间通信的安全服务和机制。第六行（6）中显示的SPI值不是提案有效负载中的SPI字段，而是包含在安全协议头中的SPI字段。
During the SA establishment, a SPI MUST be generated. ISAKMP is designed to handle variable sized SPIs. This is accomplished by using the SPI Size field within the Proposal payload during SA establishment. Handling of SPIs will be outlined by the DOI specification (e.g. [IPDOI]).
在SA建立期间，必须生成SPI。ISAKMP设计用于处理可变大小的SPI。这是通过在SA建立期间使用提案有效负载中的SPI大小字段来实现的。内政部规范（如[IPDOI]）将概述SPI的处理。
When a security association (SA) is initially established, one side assumes the role of initiator and the other the role of responder. Once the SA is established, both the original initiator and responder can initiate a phase 2 negotiation with the peer entity. Thus, ISAKMP SAs are bidirectional in nature.
最初建立安全关联（SA）时，一方担任发起方，另一方担任响应方。一旦SA建立，原始发起方和响应方都可以发起与对等实体的第2阶段协商。因此，ISAKMP SA本质上是双向的。
Additionally, ISAKMP allows both initiator and responder to have some control during the negotiation process. While ISAKMP is designed to allow an SA negotiation that includes multiple proposals, the initiator can maintain some control by only making one proposal in accordance with the initiator's local security policy. Once the initiator sends a proposal containing more than one proposal (which are sent in decreasing preference order), the initiator relinquishes control to the responder. Once the responder is controlling the SA establishment, the responder can make its policy take precedence over the initiator within the context of the multiple options offered by the initiator. This is accomplished by selecting the proposal best suited for the responder's local security policy and returning this selection to the initiator.
此外，ISAKMP允许发起方和响应方在协商过程中都有一些控制权。虽然ISAKMP旨在允许SA协商包括多个提案，但发起人可以根据发起人的本地安全策略仅提出一个提案来保持一定的控制。一旦发起方发送包含多个建议（按递减优先顺序发送）的建议，发起方将控制权让给响应方。一旦响应者控制SA建立，响应者可以在启动器提供的多个选项的上下文中使其策略优先于启动器。这是通过选择最适合响应者本地安全策略的方案并将此选择返回给发起人来实现的。
ISAKMP can be implemented over any transport protocol or over IP itself. Implementations MUST include send and receive capability for ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port 500 has been assigned to ISAKMP by the Internet Assigned Numbers Authority (IANA). Implementations MAY additionally support ISAKMP over other transport protocols or over IP itself.
ISAKMP可以通过任何传输协议或IP本身实现。实施必须包括使用端口500上的用户数据报协议（UDP）发送和接收ISAKMP的功能。互联网分配号码管理局（IANA）已将UDP端口500分配给ISAKMP。实现还可以通过其他传输协议或IP本身支持ISAKMP。
The existence of RESERVED fields within ISAKMP payloads are used strictly to preserve byte alignment. All RESERVED fields in the ISAKMP protocol MUST be set to zero (0) when a packet is issued. The receiver SHOULD check the RESERVED fields for a zero (0) value and discard the packet if other values are found.
ISAKMP有效负载中保留字段的存在严格用于保持字节对齐。发出数据包时，ISAKMP协议中的所有保留字段必须设置为零（0）。接收方应检查保留字段的零（0）值，如果发现其他值，则丢弃数据包。
The details of cookie generation are implementation dependent, but MUST satisfy these basic requirements (originally stated by Phil Karn in [Karn]):
cookie生成的细节取决于实现，但必须满足这些基本要求（最初由Phil Karn在[Karn]中陈述）：
1. The cookie must depend on the specific parties. This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and then using it to swamp the victim with Diffie-Hellman requests from randomly chosen IP addresses or ports.
1. cookie必须取决于特定的参与方。这可以防止攻击者使用真实IP地址和UDP端口获取cookie，然后使用它从随机选择的IP地址或端口向受害者发送Diffie Hellman请求。
2. It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity must use local secret information in the generation and subsequent verification of a cookie. It must not be possible to deduce this secret information from any particular cookie.
2. 发行实体以外的任何人不得生成该实体将接受的cookie。这意味着发布实体必须在cookie的生成和后续验证中使用本地机密信息。不能从任何特定的cookie推断出此机密信息。
3. The cookie generation function must be fast to thwart attacks intended to sabotage CPU resources.
3. cookie生成功能必须能够快速阻止旨在破坏CPU资源的攻击。
Karn's suggested method for creating the cookie is to perform a fast hash (e.g. MD5) over the IP Source and Destination Address, the UDP Source and Destination Ports and a locally generated secret random value. ISAKMP requires that the cookie be unique for each SA establishment to help prevent replay attacks, therefore, the date and time MUST be added to the information hashed. The generated cookies are placed in the ISAKMP Header (described in section 3.1) Initiator
Karn建议的创建cookie的方法是对IP源和目标地址、UDP源和目标端口以及本地生成的秘密随机值执行快速哈希（如MD5）。ISAKMP要求每个SA机构的cookie都是唯一的，以帮助防止重播攻击，因此，必须将日期和时间添加到哈希信息中。生成的cookie放在ISAKMP头（如第3.1节所述）启动器中
and Responder cookie fields. These fields are 8 octets in length, thus, requiring a generated cookie to be 8 octets. Notify and Delete messages (see sections 3.14, 3.15, and 4.8) are uni-directional transmissions and are done under the protection of an existing ISAKMP SA, thus, not requiring the generation of a new cookie. One exception to this is the transmission of a Notify message during a Phase 1 exchange, prior to completing the establishment of an SA. Sections 3.14 and 4.8 provide additional details.
和响应器cookie字段。这些字段的长度为8个八位字节，因此，要求生成的cookie为8个八位字节。通知和删除消息（见第3.14、3.15和4.8节）是单向传输，在现有ISAKMP SA的保护下完成，因此不需要生成新的cookie。例外情况之一是在完成SA建立之前，在阶段1交换期间传输Notify消息。第3.14节和第4.8节提供了附加细节。
3 ISAKMP Payloads
3 ISAKMP有效载荷
ISAKMP payloads provide modular building blocks for constructing ISAKMP messages. The presence and ordering of payloads in ISAKMP is defined by and dependent upon the Exchange Type Field located in the ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed in sections 3.4 through 3.15. The descriptions of the ISAKMP payloads, messages, and exchanges (see Section 4) are shown using network octet ordering.
ISAKMP有效负载提供用于构建ISAKMP消息的模块化构建块。ISAKMP中有效负载的存在和排序由位于ISAKMP头中的Exchange Type字段定义并取决于该字段（见图2）。第3.4节至第3.15节讨论了ISAKMP有效载荷类型。ISAKMP有效载荷、消息和交换的描述（见第4节）使用网络八位字节顺序显示。
An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, providing the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks.
ISAKMP消息具有固定的头格式，如图2所示，后跟可变数量的有效负载。固定头简化了解析，提供了协议解析软件的优点，该软件不那么复杂，更易于实现。固定标头包含协议维护状态、处理有效负载以及可能防止拒绝服务或重播攻击所需的信息。
The ISAKMP Header fields are defined as follows:
ISAKMP头字段定义如下：
o Initiator Cookie (8 octets) - Cookie of entity that initiated SA establishment, SA notification, or SA deletion.
o 启动器Cookie（8个八位字节）-启动SA建立、SA通知或SA删除的实体的Cookie。
o Responder Cookie (8 octets) - Cookie of entity that is responding to an SA establishment request, SA notification, or SA deletion.
o 响应者Cookie（8个八位字节）-响应SA建立请求、SA通知或SA删除的实体的Cookie。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ISAKMP Header Format
图2:ISAKMP头格式
o Next Payload (1 octet) - Indicates the type of the first payload in the message. The format for each payload is defined in sections 3.4 through 3.16. The processing for the payloads is defined in section 5.
o 下一个有效负载（1个八位字节）-指示消息中第一个有效负载的类型。第3.4节至第3.16节定义了每个有效载荷的格式。有效载荷的处理在第5节中定义。
Next Payload Type Value NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14 - 127 Private USE 128 - 255
下一个有效负载类型值NONE 0安全关联（SA）1提议（P）2转换（T）3密钥交换（KE）4标识（ID）5证书（CERT）6证书请求（CR）7散列（哈希）8签名（SIG）9临时（临时）10通知（N）11删除（D）12供应商ID（VID）13保留14-127私人使用128-255
o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Major Version to 0. Implementations SHOULD
o 主要版本（4位）-表示正在使用的ISAKMP协议的主要版本。基于此版本的ISAKMP Internet草稿的实现必须将主版本设置为1。基于以前版本的ISAKMP Internet草稿的实现必须将主版本设置为0。实现应该
never accept packets with a major version number larger than its own.
绝不接受主版本号大于其自身版本号的数据包。
o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical.
o 次要版本（4位）-表示正在使用的ISAKMP协议的次要版本。基于此版本的ISAKMP Internet草稿的实现必须将次要版本设置为0。基于以前版本的ISAKMP Internet草稿的实现必须将次要版本设置为1。如果主版本号相同，则实现永远不应接受次要版本号大于其自身版本号的数据包。
o Exchange Type (1 octet) - indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges.
o 交换类型（1个八位字节）-表示正在使用的交换类型。这规定了ISAKMP交换中的消息和有效负载顺序。
Exchange Type Value NONE 0 Base 1 Identity Protection 2 Authentication Only 3 Aggressive 4 Informational 5 ISAKMP Future Use 6 - 31 DOI Specific Use 32 - 239 Private Use 240 - 255
Exchange类型值无0基本1身份保护2身份验证仅3攻击性4信息性5 ISAKMP未来使用6-31 DOI特定使用32-239私人使用240-255
o Flags (1 octet) - indicates specific options that are set for the ISAKMP exchange. The flags listed below are specified in the Flags field beginning with the least significant bit, i.e the Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags field, and the Authentication Only bit is bit 2 of the Flags field. The remaining bits of the Flags field MUST be set to 0 prior to transmission.
o 标志（1个八位字节）-表示为ISAKMP交换设置的特定选项。下面列出的标志在标志字段中以最低有效位开始指定，即加密位为标志字段的位0，提交位为标志字段的位1，仅身份验证位为标志字段的位2。在传输之前，标志字段的剩余位必须设置为0。
-- E(ncryption Bit) (1 bit) - If set (1), all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie. It is RECOMMENDED that encryption of communications be done as soon as possible between the peers. For all ISAKMP exchanges described in section 4.1, the encryption SHOULD begin after both parties have exchanged Key Exchange payloads. If the E(ncryption Bit) is not set (0), the payloads are not encrypted.
--E（加密位）（1位）-如果设置为（1），则使用ISAKMP SA中标识的加密算法对报头后面的所有有效负载进行加密。ISAKMP SA标识符是启动器和响应程序cookie的组合。建议尽快对对等方之间的通信进行加密。对于第4.1节中描述的所有ISAKMP交换，加密应在双方交换密钥交换有效载荷后开始。如果未设置E（加密位）（0），则有效载荷未加密。
-- C(ommit Bit) (1 bit) - This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation. If set(1), the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the entity which set the Commit Bit. In this instance, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation. This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. The receipt and processing of the Informational Exchange indicates that the SA establishment was successful and either entity can now proceed with encrypted traffic communication. In addition to synchronizing key exchange, the Commit Bit can be used to protect against loss of transmissions over unreliable networks and guard against the need for multiple re-transmissions.
--C（ommit位）（1位）-此位用于向密钥交换同步发送信号。它用于确保在SA建立完成之前未收到加密材料。提交位可由参与SA建立的任何一方（随时）设置，并可在ISAKMP SA建立的两个阶段使用。但是，必须在第1阶段协商后重置该值。如果设置为（1），则未设置提交位的实体必须等待来自设置提交位的实体的包含通知有效负载（带有连接的通知消息）的信息交换。在本例中，信息交换的Message ID字段必须包含原始ISAKMP第2阶段SA协商的Message ID。这样做是为了确保与连接的Notify消息的信息交换可以与正确的阶段2 SA相关联。信息交换的接收和处理表明SA建立成功，任何实体现在都可以进行加密通信。除了同步密钥交换外，提交位还可用于防止不可靠网络上的传输丢失，并防止需要多次重新传输。
NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negotiation message following a Phase 1 exchange or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the received message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final message. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established.
注意：交换的最终消息始终可能丢失。在这种情况下，期望接收交换的最终消息的实体将在第1阶段交换后接收第2阶段SA协商消息，或在第2阶段交换后接收加密通信量。这种情况的处理不规范，但我们提出以下可能性。如果等待信息交换的实体可以验证接收到的消息（即阶段2 SA协商消息或加密流量），那么它们可以考虑SA被建立并继续处理。另一个选项是重新传输最后一条ISAKMP消息，以强制其他实体重新传输最后一条消息。这表明，实现可以考虑保留最后的消息（本地），直到他们确定SA被建立。
-- A(uthentication Only Bit) (1 bit) - This bit is intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption (e.g. "emergency mode"). Section 4.8 states that a Phase 2 Informational Exchange MUST be sent under the protection of an ISAKMP SA. This is the only exception to that policy. If the Authentication Only bit is set (1), only authentication security services will be applied to the entire Notify payload of the Informational Exchange and
--A（仅限身份验证位）（1位）-该位用于具有Notify有效载荷的信息交换，允许传输完整性检查信息，但不加密（例如“紧急模式”）。第4.8节规定，第2阶段信息交换必须在ISAKMP SA的保护下发送。这是该政策的唯一例外。如果设置了仅验证位（1），则仅验证安全服务将应用于信息交换的整个Notify有效负载，并且
the payload will not be encrypted.
有效负载将不会被加密。
o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0.
o 消息ID（4个八位字节）-在第2阶段协商期间用于标识协议状态的唯一消息标识符。该值由第2阶段协商的发起人随机生成。如果同时建立SA（即冲突），此字段的值可能会不同，因为它们是独立生成的，因此两个安全关联将朝着建立的方向发展。然而，不太可能有绝对同步的机构。在第1阶段协商期间，该值必须设置为0。
o Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message.
o 长度（4个八位字节）-以八位字节为单位的总消息长度（报头+有效负载）。加密可以扩展ISAKMP消息的大小。
Each ISAKMP payload defined in sections 3.4 through 3.16 begins with a generic header, shown in Figure 3, which provides a payload "chaining" capability and clearly defines the boundaries of a payload.
第3.4节至第3.16节中定义的每个ISAKMP有效载荷都以一个通用头开始，如图3所示，该头提供了有效载荷“链接”能力，并明确定义了有效载荷的边界。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Generic Payload Header
图3：通用有效负载头
The Generic Payload Header fields are defined as follows:
通用有效负载标头字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段提供“链接”功能。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
There are several instances within ISAKMP where it is necessary to represent Data Attributes. An example of this is the Security Association (SA) Attributes contained in the Transform payload
ISAKMP中有几个实例需要表示数据属性。转换负载中包含的安全关联（SA）属性就是一个例子
(described in section 3.6). These Data Attributes are not an ISAKMP payload, but are contained within ISAKMP payloads. The format of the Data Attributes provides the flexibility for representation of many different types of information. There can be multiple Data Attributes within a payload. The length of the Data Attributes will either be 4 octets or defined by the Attribute Length field. This is done using the Attribute Format bit described below. Specific information about the attributes for each domain will be described in a DOI document, e.g. IPSEC DOI [IPDOI].
（如第3.6节所述）。这些数据属性不是ISAKMP有效负载，而是包含在ISAKMP有效负载中。数据属性的格式为表示许多不同类型的信息提供了灵活性。一个有效负载中可以有多个数据属性。数据属性的长度将为4个八位字节或由属性长度字段定义。这是使用下面描述的属性格式位完成的。关于每个域的属性的具体信息将在DOI文档中描述，例如IPSEC DOI[IPDOI]。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AF=0 Attribute Value .
. AF=1 Not Transmitted .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! Attribute Type ! AF=0 Attribute Length !
!F! ! AF=1 Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AF=0 Attribute Value .
. AF=1 Not Transmitted .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Data Attributes
图4：数据属性
The Data Attributes fields are defined as follows:
数据属性字段定义如下：
o Attribute Type (2 octets) - Unique identifier for each type of attribute. These attributes are defined as part of the DOI-specific information.
o 属性类型（2个八位字节）-每种类型属性的唯一标识符。这些属性被定义为DOI特定信息的一部分。
The most significant bit, or Attribute Format (AF), indicates whether the data attributes follow the Type/Length/Value (TLV) format or a shortened Type/Value (TV) format. If the AF bit is a zero (0), then the Data Attributes are of the Type/Length/Value (TLV) form. If the AF bit is a one (1), then the Data Attributes are of the Type/Value form.
最高有效位或属性格式（AF）指示数据属性是遵循类型/长度/值（TLV）格式还是缩短类型/值（TV）格式。如果AF位为零（0），则数据属性为类型/长度/值（TLV）形式。如果AF位为一（1），则数据属性为类型/值形式。
o Attribute Length (2 octets) - Length in octets of the Attribute Value. When the AF bit is a one (1), the Attribute Value is only 2 octets and the Attribute Length field is not present.
o 属性长度（2个八位字节）-属性值的八位字节长度。当AF位为1时，属性值仅为2个八位字节，且属性长度字段不存在。
o Attribute Value (variable length) - Value of the attribute associated with the DOI-specific Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets.
o 属性值（可变长度）-与DOI特定属性类型关联的属性值。如果AF位为零（0），则该字段具有由属性长度字段定义的可变长度。如果AF位为1，则属性值的长度为2个八位字节。
The Security Association Payload is used to negotiate security attributes and to indicate the Domain of Interpretation (DOI) and Situation under which the negotiation is taking place. Figure 5 shows the format of the Security Association payload.
安全关联有效载荷用于协商安全属性，并指示解释域（DOI）和协商发生的情况。图5显示了安全关联负载的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Situation ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Situation ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Security Association Payload
图5：安全关联负载
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field MUST NOT contain the values for the Proposal or Transform payloads as they are considered part of the security association negotiation. For example, this field would contain the value "10" (Nonce payload) in the first message of a Base Exchange (see Section 4.4) and the value "0" in the first message of an Identity Protect Exchange (see Section 4.5).
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。此字段不得包含提案或转换有效载荷的值，因为它们被视为安全关联协商的一部分。例如，该字段将包含基本交换的第一条消息中的值“10”（非有效载荷）（参见第4.4节）和身份保护交换的第一条消息中的值“0”（参见第4.5节）。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the entire Security Association payload, including the SA payload, all Proposal payloads, and all Transform payloads associated with the proposed Security Association.
o 有效负载长度（2个八位字节）-整个安全关联有效负载的长度（以八位字节为单位），包括SA有效负载、所有建议有效负载以及与建议安全关联相关的所有转换有效负载。
o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this negotiation is taking place. The DOI is a 32-bit unsigned integer. A DOI value of 0 during a Phase 1 exchange specifies a Generic ISAKMP SA which can be used for any protocol during the Phase 2 exchange. The necessary SA Attributes are defined in A.4. A DOI value of 1 is assigned to the IPsec DOI [IPDOI]. All other DOI values are reserved to IANA for future use. IANA will not normally assign a DOI value without referencing some public specification, such as
o 解释域（4个八位字节）-确定进行协商的DOI（如第2.1节所述）。DOI是一个32位无符号整数。在第1阶段交换期间，DOI值为0指定了通用ISAKMP SA，该SA可在第2阶段交换期间用于任何协议。A.4中定义了必要的SA属性。将DOI值1分配给IPsec DOI[IPDOI]。所有其他DOI值保留给IANA供将来使用。IANA通常不会在不引用某些公共规范的情况下分配DOI值，例如
an Internet RFC. Other DOI's can be defined using the description in appendix B. This field MUST be present within the Security Association payload.
互联网RFC。可以使用附录B中的描述定义其他DOI。此字段必须存在于安全关联有效负载中。
o Situation (variable length) - A DOI-specific field that identifies the situation under which this negotiation is taking place. The Situation is used to make policy decisions regarding the security attributes being negotiated. Specifics for the IETF IP Security DOI Situation are detailed in [IPDOI]. This field MUST be present within the Security Association payload.
o 情境（可变长度）-一个DOI特定字段，用于标识谈判发生的情境。该情况用于就正在协商的安全属性做出决策。有关IETF IP安全DOI情况的详细信息，请参见[IPDOI]。此字段必须存在于安全关联有效负载中。
The Proposal Payload contains information used during Security Association negotiation. The proposal consists of security mechanisms, or transforms, to be used to secure the communications channel. Figure 6 shows the format of the Proposal Payload. A description of its use can be found in section 4.2.
提案有效负载包含安全关联协商期间使用的信息。该方案包括用于保护通信通道的安全机制或转换。图6显示了提案有效负载的格式。其使用说明见第4.2节。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (variable) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! SPI (variable) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Proposal Payload Format
图6：提案有效负载格式
The Proposal Payload fields are defined as follows:
建议书有效载荷字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "2" or "0". If there are additional Proposal payloads in the message, then this field will be 2. If the current Proposal payload is the last within the security association proposal, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。此字段只能包含值“2”或“0”。如果消息中有其他提案有效载荷，则此字段将为2。如果当前提案有效负载是安全关联提案中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the entire Proposal payload, including generic payload header, the Proposal payload, and all Transform payloads associated with this proposal. In the event there are multiple proposals with the same proposal number (see section 4.2), the Payload Length field
o 有效负载长度（2个八位字节）-整个提案有效负载的长度（以八位字节为单位），包括通用有效负载头、提案有效负载以及与此提案相关的所有变换有效负载。如果有多个提案具有相同的提案编号（见第4.2节），有效载荷长度字段
only applies to the current Proposal payload and not to all Proposal payloads.
仅适用于当前提案有效载荷，而不适用于所有提案有效载荷。
o Proposal # (1 octet) - Identifies the Proposal number for the current payload. A description of the use of this field is found in section 4.2.
o 方案#（1个八位字节）-标识当前有效负载的方案编号。第4.2节介绍了该字段的使用。
o Protocol-Id (1 octet) - Specifies the protocol identifier for the current negotiation. Examples might include IPSEC ESP, IPSEC AH, OSPF, TLS, etc.
o 协议Id（1个八位字节）-指定当前协商的协议标识符。示例可能包括IPSEC ESP、IPSEC AH、OSPF、TLS等。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. If the SPI Size is not a multiple of 4 octets it will have some impact on the SPI field and the alignment of all payloads in the message. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols.
o SPI大小（1个八位字节）-协议Id定义的SPI的八位字节长度。在ISAKMP的情况下，来自ISAKMP头的启动器和响应器cookie对是ISAKMP SPI，因此，SPI大小是不相关的，可能是从零（0）到十六（16）。如果SPI大小非零，则必须忽略SPI字段的内容。如果SPI大小不是4个八位字节的倍数，则会对SPI字段和消息中所有有效负载的对齐产生一些影响。解释域（DOI）将规定其他协议的SPI大小。
o # of Transforms (1 octet) - Specifies the number of transforms for the Proposal. Each of these is contained in a Transform payload.
o #变换数（1个八位字节）-指定方案的变换数。其中每一个都包含在转换有效负载中。
o SPI (variable) - The sending entity's SPI. In the event the SPI Size is not a multiple of 4 octets, there is no padding applied to the payload, however, it can be applied at the end of the message.
o SPI（变量）-发送实体的SPI。如果SPI大小不是4个八位字节的倍数，则不会对有效负载应用填充，但是可以在消息末尾应用填充。
The payload type for the Proposal Payload is two (2).
建议有效载荷的有效载荷类型为两（2）。
The Transform Payload contains information used during Security Association negotiation. The Transform payload consists of a specific security mechanism, or transforms, to be used to secure the communications channel. The Transform payload also contains the security association attributes associated with the specific transform. These SA attributes are DOI-specific. Figure 7 shows the format of the Transform Payload. A description of its use can be found in section 4.2.
转换有效负载包含安全关联协商期间使用的信息。转换有效载荷由用于保护通信信道的特定安全机制或转换组成。转换有效负载还包含与特定转换关联的安全关联属性。这些SA属性是特定于DOI的。图7显示了转换有效负载的格式。其使用说明见第4.2节。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform # ! Transform-Id ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ SA Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Transform # ! Transform-Id ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ SA Attributes ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Transform Payload Format
图7：转换有效负载格式
The Transform Payload fields are defined as follows:
变换有效载荷字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. This field MUST only contain the value "3" or "0". If there are additional Transform payloads in the proposal, then this field will be 3. If the current Transform payload is the last within the proposal, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。此字段只能包含值“3”或“0”。如果提案中有其他变换有效载荷，则该字段将为3。如果当前转换有效负载是提案中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header, Transform values, and all SA Attributes.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载头、转换值和所有SA属性。
o Transform # (1 octet) - Identifies the Transform number for the current payload. If there is more than one transform proposed for a specific protocol within the Proposal payload, then each Transform payload has a unique Transform number. A description of the use of this field is found in section 4.2.
o Transform#（1个八位字节）-标识当前有效负载的转换编号。如果在提议有效载荷内针对特定协议提议了多个转换，则每个转换有效载荷具有唯一的转换编号。第4.2节介绍了该字段的使用。
o Transform-Id (1 octet) - Specifies the Transform identifier for the protocol within the current proposal. These transforms are defined by the DOI and are dependent on the protocol being negotiated.
o 转换Id（1个八位字节）-指定当前方案中协议的转换标识符。这些转换由内政部定义，并取决于正在协商的协议。
o RESERVED2 (2 octets) - Unused, set to 0.
o RESERVED2（2个八位字节）-未使用，设置为0。
o SA Attributes (variable length) - This field contains the security association attributes as defined for the transform given in the Transform-Id field. The SA Attributes SHOULD be represented using the Data Attributes format described in section 3.3. If the SA Attributes are not aligned on 4-byte boundaries,
o SA属性（可变长度）-此字段包含为transform Id字段中给定的转换定义的安全关联属性。SA属性应使用第3.3节所述的数据属性格式表示。如果SA属性未在4字节边界上对齐，
then subsequent payloads will not be aligned and any padding will be added at the end of the message to make the message 4-octet aligned.
随后的有效载荷将不会对齐，并且将在消息末尾添加任何填充，以使消息4-octet对齐。
The payload type for the Transform Payload is three (3).
转换有效负载的有效负载类型为三（3）。
The Key Exchange Payload supports a variety of key exchange techniques. Example key exchanges are Oakley [Oakley], Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows the format of the Key Exchange payload.
密钥交换有效负载支持各种密钥交换技术。示例密钥交换包括Oakley[Oakley]、Diffie-Hellman、X9.42[ANSI]中描述的增强型Diffie-Hellman密钥交换以及PGP使用的基于RSA的密钥交换。图8显示了密钥交换有效负载的格式。
The Key Exchange Payload fields are defined as follows:
密钥交换有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the nextpayload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Exchange Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Key Exchange Payload Format
图8：密钥交换有效负载格式
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Key Exchange Data (variable length) - Data required to generate a session key. The interpretation of this data is specified by the DOI and the associated Key Exchange algorithm. This field may also contain pre-placed key indicators.
o 密钥交换数据（可变长度）-生成会话密钥所需的数据。该数据的解释由DOI和相关的密钥交换算法指定。此字段还可能包含预先放置的关键指示器。
The payload type for the Key Exchange Payload is four (4).
密钥交换有效负载的有效负载类型为四（4）。
The Identification Payload contains DOI-specific data used to exchange identification information. This information is used for determining the identities of communicating peers and may be used for determining authenticity of information. Figure 9 shows the format of the Identification Payload.
标识有效负载包含用于交换标识信息的DOI特定数据。该信息用于确定通信对等方的身份，并可用于确定信息的真实性。图9显示了标识有效负载的格式。
The Identification Payload fields are defined as follows:
标识有效载荷字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o ID Type (1 octet) - Specifies the type of Identification being used.
o ID类型（1个八位字节）-指定正在使用的标识类型。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! DOI Specific ID Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! DOI Specific ID Data !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Identification Payload Format
图9：识别有效载荷格式
This field is DOI-dependent.
此字段依赖于DOI。
o DOI Specific ID Data (3 octets) - Contains DOI specific Identification data. If unused, then this field MUST be set to 0.
o DOI特定的ID数据（3个八位字节）-包含DOI特定的标识数据。如果未使用，则此字段必须设置为0。
o Identification Data (variable length) - Contains identity information. The values for this field are DOI-specific and the format is specified by the ID Type field. Specific details for the IETF IP Security DOI Identification Data are detailed in [IPDOI].
o 标识数据（可变长度）-包含标识信息。此字段的值特定于DOI，格式由ID类型字段指定。IETF IP安全DOI标识数据的具体细节见[IPDOI]。
The payload type for the Identification Payload is five (5).
识别有效载荷的有效载荷类型为五（5）。
The Certificate Payload provides a means to transport certificates or other certificate-related information via ISAKMP and can appear in any ISAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate payload MUST be accepted at any point during an exchange. Figure 10 shows the format of the Certificate Payload.
证书有效负载提供了通过ISAKMP传输证书或其他证书相关信息的方法，可以出现在任何ISAKMP消息中。当适当的目录服务（如安全DNS[DNSSEC]）不可用于分发证书时，应将证书有效载荷包括在exchange中。在交换过程中的任何时候都必须接受证书有效负载。图10显示了证书有效负载的格式。
NOTE: Certificate types and formats are not generally bound to a DOI - it is expected that there will only be a few certificate types, and that most DOIs will accept all of these types.
注意：证书类型和格式通常不绑定到DOI-预计只有少数证书类型，并且大多数DOI将接受所有这些类型。
The Certificate Payload fields are defined as follows:
证书有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert Encoding ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Certificate Payload Format
图10：证书有效负载格式
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Certificate Encoding (1 octet) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field.
o 证书编码（1个八位字节）-此字段指示证书数据字段中包含的证书类型或证书相关信息。
Certificate Type Value NONE 0 PKCS #7 wrapped X.509 certificate 1 PGP Certificate 2 DNS Signed Key 3 X.509 Certificate - Signature 4 X.509 Certificate - Key Exchange 5 Kerberos Tokens 6 Certificate Revocation List (CRL) 7 Authority Revocation List (ARL) 8 SPKI Certificate 9 X.509 Certificate - Attribute 10 RESERVED 11 - 255
证书类型值无0 PKCS#7包装的X.509证书1 PGP证书2 DNS签名密钥3 X.509证书-签名4 X.509证书-密钥交换5 Kerberos令牌6证书吊销列表（CRL）7权限吊销列表（ARL）8 SPKI证书9 X.509证书-属性10保留11-255
o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
o 证书数据（可变长度）-证书数据的实际编码。证书的类型由证书编码字段指示。
The payload type for the Certificate Payload is six (6).
证书有效负载的有效负载类型为六（6）。
The Certificate Request Payload provides a means to request certificates via ISAKMP and can appear in any message. Certificate Request payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g. Secure DNS [DNSSEC]) is not available to distribute certificates. The Certificate Request payload MUST be accepted at any point during the exchange. The responder to the Certificate Request payload MUST send its certificate, if certificates are supported, based on the values contained in the payload. If multiple certificates are required, then multiple Certificate Request payloads SHOULD be transmitted. Figure 11 shows the format of the Certificate Request Payload.
证书请求有效负载提供了通过ISAKMP请求证书的方法，可以出现在任何消息中。当适当的目录服务（例如，安全DNS[DNSSEC]）不可用于分发证书时，应将证书请求有效负载包括在exchange中。在交换过程中的任何时候都必须接受证书请求有效负载。如果支持证书，则证书请求负载的响应者必须基于负载中包含的值发送其证书。如果需要多个证书，则应传输多个证书请求有效负载。图11显示了证书请求负载的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert. Type ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Cert. Type ! !
+-+-+-+-+-+-+-+-+ !
~ Certificate Authority ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Certificate Request Payload Format
图11：证书请求有效负载格式
The Certificate Payload fields are defined as follows:
证书有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Certificate Type (1 octet) - Contains an encoding of the type of certificate requested. Acceptable values are listed in section 3.9.
o 证书类型（1个八位字节）-包含所请求证书类型的编码。第3.9节列出了可接受值。
o Certificate Authority (variable length) - Contains an encoding of an acceptable certificate authority for the type of certificate requested. As an example, for an X.509 certificate this field would contain the Distinguished Name encoding of the Issuer Name of an X.509 certificate authority acceptable to the sender of this payload. This would be included to assist the responder in determining how much of the certificate chain would need to be sent in response to this request. If there is no specific certificate authority requested, this field SHOULD not be included.
o 证书颁发机构（可变长度）-包含所请求证书类型的可接受证书颁发机构的编码。例如，对于X.509证书，此字段将包含此有效负载的发送方可接受的X.509证书颁发机构的颁发者名称的可分辨名称编码。这将有助于响应者确定响应此请求需要发送多少证书链。如果没有请求特定的证书颁发机构，则不应包括此字段。
The payload type for the Certificate Request Payload is seven (7).
证书请求有效负载的有效负载类型为七（7）。
The Hash Payload contains data generated by the hash function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload may be used to verify the integrity of the data in an ISAKMP message or for authentication of the negotiating entities. Figure 12 shows the format of the Hash Payload.
散列有效负载包含散列函数（在SA建立交换期间选择）通过消息的某些部分和/或ISAKMP状态生成的数据。该有效载荷可用于验证ISAKMP消息中数据的完整性或用于协商实体的认证。图12显示了散列负载的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Hash Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Hash Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Hash Payload Format
图12：哈希有效负载格式
The Hash Payload fields are defined as follows:
哈希有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Hash Data (variable length) - Data that results from applying the hash routine to the ISAKMP message and/or state.
o 哈希数据（可变长度）-将哈希例程应用于ISAKMP消息和/或状态所产生的数据。
The Signature Payload contains data generated by the digital signature function (selected during the SA establishment exchange), over some part of the message and/or ISAKMP state. This payload is used to verify the integrity of the data in the ISAKMP message, and may be of use for non-repudiation services. Figure 13 shows the format of the Signature Payload.
签名有效负载包含数字签名功能（在SA建立交换期间选择）在消息的某些部分和/或ISAKMP状态上生成的数据。该有效载荷用于验证ISAKMP消息中数据的完整性，并可用于不可否认性服务。图13显示了签名有效负载的格式。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Signature Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Signature Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Signature Payload Format
图13：签名有效负载格式
The Signature Payload fields are defined as follows:
签名有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Signature Data (variable length) - Data that results from applying the digital signature function to the ISAKMP message and/or state.
o 签名数据（可变长度）-将数字签名功能应用于ISAKMP消息和/或状态所产生的数据。
The payload type for the Signature Payload is nine (9).
签名有效负载的有效负载类型为九（9）。
The Nonce Payload contains random data used to guarantee liveness during an exchange and protect against replay attacks. Figure 14 shows the format of the Nonce Payload. If nonces are used by a particular key exchange, the use of the Nonce payload will be dictated by the key exchange. The nonces may be transmitted as part of the key exchange data, or as a separate payload. However, this is defined by the key exchange, not by ISAKMP.
Nonce有效负载包含随机数据，用于保证交换期间的活跃性并防止重播攻击。图14显示了Nonce有效负载的格式。如果特定密钥交换使用Nonce，则Nonce有效负载的使用将由密钥交换决定。nonce可以作为密钥交换数据的一部分或作为单独的有效载荷来传输。但是，这是由密钥交换定义的，而不是由ISAKMP定义的。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Nonce Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Nonce Payload Format
图14：Nonce有效负载格式
The Nonce Payload fields are defined as follows:
Nonce有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Nonce Data (variable length) - Contains the random data generated by the transmitting entity.
o Nonce数据（可变长度）-包含传输实体生成的随机数据。
The payload type for the Nonce Payload is ten (10).
当前有效载荷的有效载荷类型为十（10）。
The Notification Payload can contain both ISAKMP and DOI-specific data and is used to transmit informational data, such as error conditions, to an ISAKMP peer. It is possible to send multiple Notification payloads in a single ISAKMP message. Figure 15 shows the format of the Notification Payload.
通知有效负载可以包含ISAKMP和DOI特定数据，并用于将信息数据（如错误条件）传输到ISAKMP对等方。可以在单个ISAKMP消息中发送多个通知有效负载。图15显示了通知负载的格式。
Notification which occurs during, or is concerned with, a Phase 1 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header. The Protocol Identifier, in this case, is ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP Header identifies the ISAKMP SA. If the notification takes place prior to the completed exchange of keying information, then the notification will be unprotected.
在第1阶段协商期间发生或与之相关的通知由ISAKMP标头中的启动器和响应程序cookie对标识。在本例中，协议标识符为ISAKMP，SPI值为0，因为ISAKMP头中的cookie对标识ISAKMP SA。如果通知发生在密钥信息交换完成之前，则通知将不受保护。
Notification which occurs during, or is concerned with, a Phase 2 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current negotiation. One example for this type of notification is to indicate why a proposal was rejected.
在第2阶段协商期间发生或与之相关的通知由ISAKMP头中的发起方和响应方cookie对以及与当前协商关联的消息ID和SPI标识。此类通知的一个示例是说明提案被拒绝的原因。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Notification Payload Format
图15：通知有效负载格式
The Notification Payload fields are defined as follows:
通知有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this notification is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B.
o 解释域（4个八位字节）-确定本通知发生的DOI（如第2.1节所述）。对于ISAKMP，该值为零（0），对于IPSEC DOI，该值为一（1）。其他DOI可使用附录B中的说明进行定义。
o Protocol-Id (1 octet) - Specifies the protocol identifier for the current notification. Examples might include ISAKMP, IPSEC ESP, IPSEC AH, OSPF, TLS, etc.
o 协议Id（1个八位字节）-指定当前通知的协议标识符。示例可能包括ISAKMP、IPSEC ESP、IPSEC AH、OSPF、TLS等。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the SPI Size is irrelevant and MAY be from zero (0) to sixteen (16). If the SPI Size is non-zero, the content of the SPI field MUST be ignored. The Domain of Interpretation (DOI) will dictate the SPI Size for other protocols.
o SPI大小（1个八位字节）-协议Id定义的SPI的八位字节长度。在ISAKMP的情况下，来自ISAKMP头的启动器和响应器cookie对是ISAKMP SPI，因此，SPI大小是不相关的，可能是从零（0）到十六（16）。如果SPI大小非零，则必须忽略SPI字段的内容。解释域（DOI）将规定其他协议的SPI大小。
o Notify Message Type (2 octets) - Specifies the type of notification message (see section 3.14.1). Additional text, if specified by the DOI, is placed in the Notification Data field.
o 通知消息类型（2个八位字节）-指定通知消息的类型（见第3.14.1节）。如果DOI指定了其他文本，则将其放置在通知数据字段中。
o SPI (variable length) - Security Parameter Index. The receiving entity's SPI. The use of the SPI field is described in section 2.4. The length of this field is determined by the SPI Size field and is not necessarily aligned to a 4 octet boundary.
o SPI（可变长度）-安全参数索引。接收实体的SPI。第2.4节描述了SPI字段的使用。该字段的长度由SPI大小字段确定，不一定与4个八位组的边界对齐。
o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are DOI-specific.
o 通知数据（可变长度）-除了通知消息类型外，还传输信息或错误数据。此字段的值特定于DOI。
The payload type for the Notification Payload is eleven (11).
通知有效负载的有效负载类型为十一（11）。
Notification information can be error messages specifying why an SA could not be established. It can also be status data that a process managing an SA database wishes to communicate with a peer process. For example, a secure front end or security gateway may use the Notify message to synchronize SA communication. The table below lists the Nofitication messages and their corresponding values. Values in the Private Use range are expected to be DOI-specific values.
通知信息可以是错误消息，指定无法建立SA的原因。它也可以是管理SA数据库的进程希望与对等进程通信的状态数据。例如，安全前端或安全网关可以使用通知消息来同步SA通信。下表列出了不适配信息及其相应的值。私有使用范围中的值应为DOI特定的值。
NOTIFY MESSAGES - ERROR TYPES
通知消息-错误类型
Errors Value INVALID-PAYLOAD-TYPE 1 DOI-NOT-SUPPORTED 2 SITUATION-NOT-SUPPORTED 3 INVALID-COOKIE 4 INVALID-MAJOR-VERSION 5 INVALID-MINOR-VERSION 6 INVALID-EXCHANGE-TYPE 7 INVALID-FLAGS 8 INVALID-MESSAGE-ID 9 INVALID-PROTOCOL-ID 10 INVALID-SPI 11
错误值无效有效载荷类型1 DOI不支持2情况不支持3无效COOKIE 4无效主要版本5无效次要版本6无效交换类型7无效标志8无效消息ID 9无效协议ID 10无效SPI 11
INVALID-TRANSFORM-ID 12 ATTRIBUTES-NOT-SUPPORTED 13 NO-PROPOSAL-CHOSEN 14 BAD-PROPOSAL-SYNTAX 15 PAYLOAD-MALFORMED 16 INVALID-KEY-INFORMATION 17 INVALID-ID-INFORMATION 18 INVALID-CERT-ENCODING 19 INVALID-CERTIFICATE 20 CERT-TYPE-UNSUPPORTED 21 INVALID-CERT-AUTHORITY 22 INVALID-HASH-INFORMATION 23 AUTHENTICATION-FAILED 24 INVALID-SIGNATURE 25 ADDRESS-NOTIFICATION 26 NOTIFY-SA-LIFETIME 27 CERTIFICATE-UNAVAILABLE 28 UNSUPPORTED-EXCHANGE-TYPE 29 UNEQUAL-PAYLOAD-LENGTHS 30 RESERVED (Future Use) 31 - 8191 Private Use 8192 - 16383
无效-转换-ID 12属性-不支持13不建议-选择14错误-建议-语法15有效载荷-格式错误16无效-密钥-信息17无效-ID-信息18无效-证书-编码19无效-证书20证书类型-不支持21无效-证书-授权22无效-哈希-信息23身份验证失败24无效-签名25ADDRESS-NOTIFICATION 26 NOTIFY-SA-LIFETIME 27 CERTIFICATE-UNAVAILABLE 28 UNSUPPORTED-EXCHANGE-TYPE 29不等有效负载长度30保留（未来使用）31-8191专用8192-16383
NOTIFY MESSAGES - STATUS TYPES Status Value CONNECTED 16384 RESERVED (Future Use) 16385 - 24575 DOI-specific codes 24576 - 32767 Private Use 32768 - 40959 RESERVED (Future Use) 40960 - 65535
通知消息-状态类型状态值已连接16384保留（未来使用）16385-24575 DOI特定代码24576-32767私人使用32768-40959保留（未来使用）40960-65535
The Delete Payload contains a protocol-specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 16 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload, however, each SPI MUST be for the same protocol. Mixing of Protocol Identifiers MUST NOT be performed with the Delete payload.
删除有效负载包含特定于协议的安全关联标识符，发送方已将该标识符从其安全关联数据库中删除，因此不再有效。图16显示了Delete有效负载的格式。可以在删除有效负载中发送多个SPI，但是，每个SPI必须用于相同的协议。协议标识符的混合不得与删除有效负载一起执行。
Deletion which is concerned with an ISAKMP SA will contain a Protocol-Id of ISAKMP and the SPIs are the initiator and responder cookies from the ISAKMP Header. Deletion which is concerned with a Protocol SA, such as ESP or AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s).
与ISAKMP SA相关的删除将包含ISAKMP的协议Id，SPI是来自ISAKMP标头的发起方和响应方cookie。与协议SA（如ESP或AH）相关的删除将包含该协议的协议Id（如ESP、AH），SPI是发送实体的SPI。
NOTE: The Delete Payload is not a request for the responder to delete an SA, but an advisory from the initiator to the responder. If the responder chooses to ignore the message, the next communication from the responder to the initiator, using that security association, will fail. A responder is not expected to acknowledge receipt of a Delete payload.
注意：删除有效负载不是响应者删除SA的请求，而是发起者向响应者发出的建议。如果响应者选择忽略该消息，则使用该安全关联从响应者到启动器的下一次通信将失败。响应者不需要确认收到删除有效负载。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Delete Payload Format
图16：删除有效负载格式
The Delete Payload fields are defined as follows:
删除有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Domain of Interpretation (4 octets) - Identifies the DOI (as described in Section 2.1) under which this deletion is taking place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is one (1). Other DOI's can be defined using the description in appendix B.
o 解释域（4个八位字节）-标识发生删除的DOI（如第2.1节所述）。对于ISAKMP，该值为零（0），对于IPSEC DOI，该值为一（1）。其他DOI可使用附录B中的说明进行定义。
o Protocol-Id (1 octet) - ISAKMP can establish security associations for various protocols, including ISAKMP and IPSEC. This field identifies which security association database to apply the delete request.
o 协议Id（1个八位字节）-ISAKMP可以为各种协议建立安全关联，包括ISAKMP和IPSEC。此字段标识要应用删除请求的安全关联数据库。
o SPI Size (1 octet) - Length in octets of the SPI as defined by the Protocol-Id. In the case of ISAKMP, the Initiator and Responder cookie pair is the ISAKMP SPI. In this case, the SPI Size would be 16 octets for each SPI being deleted.
o SPI大小（1个八位字节）-协议Id定义的SPI的八位字节长度。对于ISAKMP，发起方和响应方cookie对是ISAKMP SPI。在这种情况下，每删除一个SPI，SPI大小将为16个八位字节。
o # of SPIs (2 octets) - The number of SPIs contained in the Delete payload. The size of each SPI is defined by the SPI Size field.
o #SPI数量（2个八位字节）-删除有效负载中包含的SPI数量。每个SPI的大小由SPI大小字段定义。
o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. Values for this field are DOI and protocol specific. The length of this field is determined by the SPI Size and # of SPIs fields.
o 安全参数索引（可变长度）-标识要删除的特定安全关联。此字段的值是DOI和协议特定的。此字段的长度由SPI大小和SPIs字段的#决定。
The payload type for the Delete Payload is twelve (12).
删除有效负载的有效负载类型为十二（12）。
The Vendor ID Payload contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. This is not a general extension facility of ISAKMP. Figure 17 shows the format of the Vendor ID Payload.
供应商ID有效负载包含供应商定义的常量。供应商使用该常量来识别和识别其实现的远程实例。这种机制允许供应商在保持向后兼容性的同时试验新功能。这不是ISAKMP的一般扩展设施。图17显示了供应商ID有效负载的格式。
The Vendor ID payload is not an announcement from the sender that it will send private payload types. A vendor sending the Vendor ID MUST not make any assumptions about private payloads that it may send unless a Vendor ID is received as well. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to understand any Vendor ID payloads. An implementation is NOT REQUIRED to send any Vendor ID payload at all. If a private payload was sent without prior agreement to send it, a compliant implementation may reject a proposal with a notify message of type INVALID-PAYLOAD-TYPE.
供应商ID有效负载不是发送方发出的将发送私有有效负载类型的通知。发送供应商ID的供应商不得对其可能发送的私人有效载荷做出任何假设，除非同时收到供应商ID。可以发送多个供应商ID有效载荷。不需要实现来理解任何供应商ID有效负载。根本不需要实现来发送任何供应商ID有效负载。如果在未事先同意发送的情况下发送了私有有效负载，则符合要求的实现可能会拒绝带有类型为INVALID-payload-type的notify消息的建议。
If a Vendor ID payload is sent, it MUST be sent during the Phase 1 negotiation. Reception of a familiar Vendor ID payload in the Phase 1 negotiation allows an implementation to make use of Private USE payload numbers (128-255), described in section 3.1 for vendor specific extensions during Phase 2 negotiations. The definition of "familiar" is left to implementations to determine. Some vendors may wish to implement another vendor's extension prior to standardization. However, this practice SHOULD not be widespread and vendors should work towards standardization instead.
如果发送了供应商ID有效负载，则必须在第1阶段协商期间发送。在第1阶段谈判中接收到熟悉的供应商ID有效载荷，允许实施在第2阶段谈判期间使用第3.1节中描述的专用有效载荷编号（128-255）进行供应商特定扩展。“熟悉”的定义留给实现来确定。一些供应商可能希望在标准化之前实施另一个供应商的扩展。然而，这种做法不应广泛存在，供应商应努力实现标准化。
The vendor defined constant MUST be unique. The choice of hash and text to hash is left to the vendor to decide. As an example, vendors could generate their vendor id by taking a plain (non-keyed) hash of a string containing the product name, and the version of the product.
供应商定义的常量必须是唯一的。哈希和要哈希的文本的选择由供应商决定。例如，供应商可以通过对包含产品名称和产品版本的字符串进行普通（无键）散列来生成其供应商id。
A hash is used instead of a vendor registry to avoid local cryptographic policy problems with having a list of "approved" products, to keep away from maintaining a list of vendors, and to allow classified products to avoid having to appear on any list. For instance:
使用散列代替供应商注册，以避免在拥有“批准”产品列表时出现本地加密策略问题，避免维护供应商列表，并允许分类产品避免出现在任何列表上。例如：
"Example Company IPsec. Version 97.1"
“示例公司IPsec.Version 97.1”
(not including the quotes) has MD5 hash: 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may include all of the hash, or just a portion of it, as the payload length will bound the data. There are no security implications of this hash, so its choice is arbitrary.
（不包括引号）在使用MD5file时具有MD5哈希：48544f9b1fe662af98b9b39e50c01a5a。供应商可能会包含所有散列，或者只是其中的一部分，因为有效负载长度将绑定数据。此哈希没有安全含义，因此其选择是任意的。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Vendor ID (VID) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Vendor ID Payload Format
图17：供应商ID有效负载格式
The Vendor ID Payload fields are defined as follows:
供应商ID有效负载字段定义如下：
o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0.
o 下一个有效负载（1个八位字节）-消息中下一个有效负载的有效负载类型的标识符。如果当前有效负载是消息中的最后一个，则此字段将为0。
o RESERVED (1 octet) - Unused, set to 0.
o 保留（1个八位组）-未使用，设置为0。
o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header.
o 有效负载长度（2个八位字节）-当前有效负载的长度（以八位字节为单位），包括通用有效负载标头。
o Vendor ID (variable length) - Hash of the vendor string plus version (as described above).
o 供应商ID（可变长度）-供应商字符串加版本的哈希（如上所述）。
The payload type for the Vendor ID Payload is thirteen (13).
供应商ID有效负载的有效负载类型为十三（13）。
4 ISAKMP Exchanges
4 ISAKMP交换
ISAKMP supplies the basic syntax of a message exchange. The basic building blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA
ISAKMP提供消息交换的基本语法。ISAKMP消息的基本构建块是第3节中描述的有效负载类型。本节介绍SA的程序
establishment and SA modification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these additions.
建立和SA修改，然后是可用于初始互操作性的默认交换集。其他交换将根据DOI和密钥交换进行定义。[IPDOI]和[IKE]是如何实现这一目标的示例。附录B说明了完成这些添加的程序。
ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material. There are currently five default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers. Most exchanges will include all the basic payload types - SA, KE, ID, SIG - and may include others. The primary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOMMENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5.
ISAKMP允许创建用于建立安全关联和密钥材料的交换。目前为ISAKMP定义了五种默认的Exchange类型。第4.4节至第4.8节描述了这些交换。交换定义对等方之间通信期间ISAKMP消息的内容和顺序。大多数交换将包括所有基本的有效载荷类型——SA、KE、ID、SIG——并可能包括其他类型。交换类型之间的主要区别在于消息的顺序和每条消息内的有效负载顺序。虽然未强制要求对消息中的有效负载进行排序，但为了提高处理效率，建议将安全关联有效负载作为exchange中的第一个有效负载。第5节描述了交换中每个有效负载的处理。
Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has happened after each message exchange. None of the examples include any "optional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3).
第4.4节至第4.8节提供了一组默认的ISAKMP交换。这些交换为交换本身和交换的信息提供不同的安全保护。以下各节中的图表显示了每种交换类型的消息顺序以及每条消息中包含的有效负载，并提供了描述每次消息交换后发生的情况的基本注释。没有一个示例包括任何“可选有效负载”，如证书和证书请求。此外，没有一个示例包括初始交换ISAKMP头（包含启动器和响应程序cookie），这将提供防止阻塞的保护（参见第2.5.3节）。
The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI requirements, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols.
定义的交换并不意味着满足所有DOI和密钥交换协议要求。如果定义的交换符合内政部的要求，则可以按概述使用。如果定义的交换不符合内政部定义的安全要求，那么内政部必须指定新的交换类型和组成成功交换的有效有效负载序列，以及如何构建和解释这些有效负载。所有ISAKMP实现都必须实现信息交换，并且应该实现其他四种交换。然而，这取决于DOI和相关密钥交换协议的定义。
As discussed above, these exchange types can be used in either phase of negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation.
如上所述，这些交换类型可用于协商的任何阶段。但是，它们可能在每个阶段提供不同的安全属性。对于这些交换中的每一个，Cookie和SPI字段的组合将标识此交换是在协商的第一阶段还是第二阶段中使用。
The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated payloads:
以下符号用于描述ISAKMP交换类型，如下一节所示，以及消息格式和相关有效负载：
HDR is an ISAKMP header whose exchange type defines the payload orderings SA is an SA negotiation payload with one or more Proposal and Transform payloads. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one. KE is the key exchange payload. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, or x can be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), for the user initiator and responder, respectively. HASH is the hash payload. SIG is the signature payload. The data to sign is exchange-specific. AUTH is a generic authentication mechanism, such as HASH or SIG. NONCE is the nonce payload. '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted.
HDR是一个ISAKMP头，其交换类型定义了有效负载订购SA是一个具有一个或多个建议和转换有效负载的SA协商有效负载。发起人可以提供多个谈判方案；响应者必须只使用一个响应。KE是密钥交换有效负载。IDx是“x”的标识有效负载。对于ISAKMP启动器和响应程序，x可以分别为：“ii”或“ir”，对于用户启动器和响应程序，x可以分别为：“ui”、“ur”（当ISAKMP守护程序是代理协商程序时）。哈希是哈希有效负载。SIG是签名有效负载。要签名的数据是特定于exchange的。AUTH是一种通用的身份验证机制，如哈希或SIG。NONCE是NONCE有效负载。“*”表示ISAKMP标头之后的有效负载加密。此加密必须在ISAKMP标头之后立即开始，并且必须加密ISAKMP标头之后的所有有效负载。
=> signifies "initiator to responder" communication
<= signifies "responder to initiator" communication
=> signifies "initiator to responder" communication
<= signifies "responder to initiator" communication
The Security Association, Proposal, and Transform payloads are used to build ISAKMP messages for the negotiation and establishment of SAs. An SA establishment message consists of a single SA payload followed by at least one, and possibly many, Proposal payloads and at least one, and possibly many, Transform payloads associated with each Proposal payload. Because these payloads are considered together, the SA payload will point to any following payloads and not to the Proposal payload included with the SA payload. The SA Payload contains the DOI and Situation for the proposed SA. Each Proposal payload contains a Security Parameter Index (SPI) and ensures that the SPI is associated with the Protocol-Id in accordance with the Internet Security Architecture [SEC-ARCH]. Proposal payloads may or may not have the same SPI, as this is implementation dependent. Each
安全关联、建议和转换有效负载用于构建ISAKMP消息，以协商和建立SA。SA建立消息包括单个SA有效载荷，后跟至少一个（可能多个）建议有效载荷以及与每个建议有效载荷相关联的至少一个（可能多个）转换有效载荷。由于这些有效载荷一起考虑，SA有效载荷将指向任何以下有效载荷，而不是SA有效载荷中包含的建议有效载荷。SA有效载荷包含拟议SA的DOI和情况。每个提案有效载荷包含一个安全参数索引（SPI），并确保SPI与符合互联网安全体系结构[SEC-ARCH]的协议Id相关联。提案有效负载可能具有也可能不具有相同的SPI，因为这取决于实现。每个
Transform Payload contains the specific security mechanisms to be used for the designated protocol. It is expected that the Proposal and Transform payloads will be used only during SA establishment negotiation. The creation of payloads for security association negotiation and establishment described here in this section are applicable for all ISAKMP exchanges described later in sections 4.4 through 4.8. The examples shown in 4.2.1 contain only the SA, Proposal, and Transform payloads and do not contain other payloads that might exist for a given ISAKMP exchange.
Transform Payload包含用于指定协议的特定安全机制。预计提案和转换有效载荷将仅在SA建立谈判期间使用。本节所述的安全关联协商和建立有效载荷的创建适用于下文第4.4节至第4.8节所述的所有ISAKMP交换。4.2.1中所示的示例仅包含SA、建议和转换有效载荷，不包含给定ISAKMP交换可能存在的其他有效载荷。
The Proposal payload provides the initiating entity with the capability to present to the responding entity the security protocols and associated security mechanisms for use with the security association being negotiated. If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Proposal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. The use of the same Proposal number in multiple Proposal payloads provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads each with a monotonically increasing Proposal number. The different proposals MUST be presented in the initiator's preference order. The use of different Proposal numbers in multiple Proposal payloads provides a logical OR operation, i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one protocol. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload (if it exists). The existence of a Proposal payload implies the existence of one or more Transform payloads.
提案有效载荷为发起实体提供了向响应实体呈现安全协议和相关安全机制的能力，以便与正在协商的安全关联一起使用。如果SA建立协商针对由多个协议组成的组合保护套件，则必须有多个提案有效载荷，每个提案有效载荷具有相同的提案编号。这些提案必须视为一个单元，不得被具有不同提案编号的提案分开。在多个提案有效载荷中使用同一提案编号可提供逻辑“与”操作，即协议1和协议2。下面的第一个示例显示了ESP和AH保护套件。如果SA建立协商针对不同的保护套件，则必须有多个提案有效负载，每个提案有效负载的提案数量单调递增。不同的提案必须按照发起人的优先顺序提交。在多个提案有效载荷中使用不同的提案编号提供了逻辑OR操作，即提案1或提案2，其中每个提案可能有多个协议。下面的第二个示例显示AH和ESP保护套件，或者仅显示ESP保护套件。请注意，提案有效负载的下一个有效负载字段指向另一个提案有效负载（如果存在）。提案有效载荷的存在意味着一个或多个变换有效载荷的存在。
The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform payload allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with monotonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform number in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below
转换有效载荷为发起实体提供了向响应实体呈现给定协议的多个机制或转换的能力。提案有效负载确定了一个协议，正在为其协商服务和机制。转换有效载荷允许发起实体为所提议的协议呈现几个可能的受支持的转换。可能存在与特定提案有效载荷相关联的多个变换，每个变换在单独的变换有效载荷中标识。多个变换必须以发起者的偏好顺序单调递增的数字表示。接收实体必须为提案中的每个协议选择一个转换，或拒绝整个提案。在多个变换有效载荷中使用变换编号提供第二级或操作，即变换1或变换2或变换3。下面的示例1显示了ESP的两种可能转换和AH的一种转换。下面的例子2
shows one transform for AH AND one transform for ESP OR two transforms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals.
显示AH的一个变换和ESP的一个变换，或仅ESP的两个变换。请注意，变换有效负载的下一个有效负载字段指向另一个变换有效负载或0。提案有效载荷描述了不同的提案。
When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly. The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially.
当响应安全关联有效载荷时，响应者必须发送带有所选提议的安全关联有效载荷，该提议可能包括多个提议有效载荷及其关联的转换有效载荷。每个提案有效载荷必须包含与协议相关联的单个转换有效载荷。响应者应在提案有效载荷中保留提案#字段，并在所选提案的每个变换有效载荷中保留变换#字段。保留提案和转换编号应通过消除将响应者的选择与每个提供的选项进行比较的需要来加快发起人的协议处理。这些值使启动器能够直接快速地执行比较。发起方必须验证从响应方接收的安全关联有效负载是否与最初发送的建议之一匹配。
This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a single transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms proposed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange.
此示例显示了一个使用两种不同协议的组合保护套件的建议。第一个协议由提议者支持的两个变换组成。第二个协议是通过一个转换实现的。该方案的一个示例可能是：协议1为ESP，转换1为3DES，转换2为DES，协议2为AH，转换1为SHA。响应者必须从ESP建议的两种转换中进行选择。产生的保护套件将是（1）3DES和SHA或（2）DES和SHA，具体取决于响应者选择的ESP转换。注意：此示例是使用基本Exchange显示的。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Nonce ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SA Pay ! Domain of Interpretation (DOI) !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! Situation !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This second example shows a Proposal for two different protection suites. The SA Payload was omitted for space reasons. The first protection suite is presented with one transform for the first protocol and one transform for the second protocol. The second protection suite is presented with two transforms for a single protocol. An example for this proposal might be: Proposal 1 with Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder MUST select from the two different proposals. If the second Proposal is selected, the responder MUST select from the two transforms for ESP. The resulting protection suite will be either (1) MD5 AND 3DES OR the selection between (2) DES OR (3) 3DES.
第二个示例显示了两个不同保护套件的建议。由于空间原因，SA有效载荷被省略。第一个保护套件包括第一个协议的一个转换和第二个协议的一个转换。第二个保护套件针对单个协议提供了两个转换。该方案的一个示例可能是：方案1，协议1为AH，转换1为MD5，协议2为ESP，转换1为3DES。其次是方案2，协议1为ESP，转换1为DES，转换2为3DES。响应者必须从两个不同的方案中进行选择。如果选择了第二个方案，则响应者必须从ESP的两个转换中进行选择。生成的保护套件将是（1）MD5和3DES或（2）DES或（3）3DES之间的选择。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Association modification within ISAKMP is accomplished by creating a new SA and initiating communications using that new SA. Deletion of the old SA can be done anytime after the new SA is established. Deletion of the old SA is dependent on local security policy. Modification of SAs by using a "Create New SA followed by Delete Old SA" method is done to avoid potential vulnerabilities in synchronizing modification of existing SA attributes. The procedure for creating new SAs is outlined in section 4.2. The procedure for deleting SAs is outlined in section 5.15.
ISAKMP中的安全关联修改是通过创建新SA并使用新SA启动通信来完成的。在建立新SA后，可以随时删除旧SA。旧SA的删除取决于本地安全策略。使用“创建新SA，然后删除旧SA”方法修改SA，以避免在同步修改现有SA属性时出现潜在漏洞。第4.2节概述了创建新SA的程序。第5.15节概述了删除SA的程序。
Modification of an ISAKMP SA (phase 1 negotiation) follows the same procedure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3.
修改ISAKMP SA（第1阶段协商）的过程与创建ISAKMP SA的过程相同。两个SAs之间没有关系，启动器和响应程序cookie对应该不同，如第2.5.3节所述。
Modification of a Protocol SA (phase 2 negotiation) follows the same procedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Protocol SAs. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy.
协议SA的修改（第2阶段协商）遵循与创建协议SA相同的过程。新SA的创建受现有ISAKMP SA的保护。两个协议SAs之间没有关系。协议实现应开始将新创建的SA用于出站流量，并应继续支持旧SA上的传入流量，直到将其删除或在新创建的SA的保护下接收到流量。如本节前面所述，旧SA的删除取决于本地安全策略。
The Base Exchange is designed to allow the Key Exchange and Authentication related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange.
基本交换旨在允许密钥交换和认证相关信息一起传输。将密钥交换和身份验证相关信息合并到一条消息中，以不提供身份保护为代价减少了往返次数。未提供身份保护，因为身份是在建立公共共享秘密之前交换的，因此无法对身份进行加密。下图显示了每条消息中发送的可能有效负载的消息，以及基本Exchange示例的注释。
BASE EXCHANGE
基本交换
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation
(2) <= HDR; SA; NONCE
Basic SA agreed upon
(3) HDR; KE; =>
IDii; AUTH Key Generated (by responder)
Initiator Identity Verified by
Responder
(4) <= HDR; KE;
IDir; AUTH
Responder Identity Verified by
Initiator Key Generated (by
initiator) SA established
(2) <= HDR; SA; NONCE
Basic SA agreed upon
(3) HDR; KE; =>
IDii; AUTH Key Generated (by responder)
Initiator Identity Verified by
Responder
(4) <= HDR; KE;
IDir; AUTH
Responder Identity Verified by
Initiator Key Generated (by
initiator) SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
在第一条消息（1）中，发起方生成其认为足以保护给定情况下的通信量的建议。安全关联、建议和转换有效负载包含在安全关联有效负载中（用于表示）。还传输用于保证活动性和防止重放攻击的随机信息。认证机制应使用双方提供的随机信息提供参与交换的共享证据。
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第二条消息（2）中，响应者指示它已接受的与安全关联、建议和转换有效负载的保护套件。此外，还传输用于保证活动性和防止重播攻击的随机信息。认证机制应使用双方提供的随机信息提供参与交换的共享证据。如果未接受建议的保护套件，则本地安全策略将指示响应者的操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第三（3）和第四（4）条消息中，发起方和响应方分别交换用于获取公共共享秘密和标识信息的密钥材料。该信息在商定的认证功能的保护下传输。如果在这些消息期间发生错误，本地安全策略将指示操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the expense of two additional messages. Identities are exchanged under the protection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange.
身份保护交换旨在将密钥交换信息与身份和身份验证相关信息分离。将密钥交换与身份和身份验证相关信息分离，可以保护通信身份，但需要另外两条消息。身份在先前建立的公共共享秘密的保护下交换。下图显示了每条消息中发送的可能有效负载的消息，以及身份保护交换示例的注释。
IDENTITY PROTECTION EXCHANGE
身份保护交换
# Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA established
# Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes).
在第一条消息（1）中，发起方生成其认为足以保护给定情况下的通信量的建议。安全关联、建议和转换有效负载包含在安全关联有效负载中（用于表示）。
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第二条消息（2）中，响应者指示它已接受的与安全关联、建议和转换有效负载的保护套件。如果未接受建议的保护套件，则本地安全策略将指示响应者的操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第三（3）条和第四（4）条消息中，发起方和响应方分别交换密钥材料，用于获取公共共享秘密和随机信息，用于保证活动性和防止重放攻击。认证机制应使用双方提供的随机信息提供参与交换的共享证据。如果在这些消息期间发生错误，本地安全策略将指示操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
In the fifth (5) and sixth (6) messages, the initiator and responder, respectively, exchange identification information and the results of the agreed upon authentication function. This information is
在第五（5）条和第六（6）条消息中，发起方和响应方分别交换标识信息和约定的认证功能的结果。这个信息是
transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在公共共享秘密的保护下传输。如果在这些消息期间发生错误，本地安全策略将指示操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negotiated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authentication only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Authentication Only Exchange.
仅限身份验证的交换旨在仅允许传输与身份验证相关的信息。这种交换的好处是能够只执行身份验证，而不需要计算密钥的计算费用。在协商期间使用此交换，传输的任何信息都不会被加密。然而，信息可能在其他地方被加密。例如，如果在协商的第一阶段协商加密，并且在协商的第二阶段使用仅验证交换，则仅验证交换将由在第一阶段协商的ISAKMP SA加密。下图显示了每条消息中发送的可能有效负载的消息，以及仅验证交换示例的注释。
AUTHENTICATION ONLY EXCHANGE
仅身份验证交换
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon
Responder Identity
Verified by Initiator
(3) HDR; IDii; AUTH =>
Initiator Identity
Verified by Responder
SA established
# Initiator Direction Responder NOTE
(1) HDR; SA; NONCE => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA; NONCE;
IDir; AUTH
Basic SA agreed upon
Responder Identity
Verified by Initiator
(3) HDR; IDii; AUTH =>
Initiator Identity
Verified by Responder
SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange.
在第一条消息（1）中，发起方生成其认为足以保护给定情况下的通信量的建议。安全关联、建议和转换有效负载包含在安全关联有效负载中（用于表示）。还传输用于保证活动性和防止重放攻击的随机信息。认证机制应使用双方提供的随机信息提供参与交换的共享证据。
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to
在第二条消息（2）中，响应者指示它已接受的与安全关联、建议和转换有效负载的保护套件。同样，随机信息用于
guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
还传输保证活动性和防止重播攻击。认证机制应使用双方提供的随机信息提供参与交换的共享证据。此外，响应者发送识别信息。所有这些信息都是在商定的认证功能的保护下传输的。如果未接受建议的保护套件，则本地安全策略将指示响应者的操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
In the third message (3), the initiator transmits identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第三消息（3）中，发起方发送标识信息。该信息在商定的认证功能的保护下传输。如果在这些消息期间发生错误，本地安全策略将指示操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to establish all security relevant information in a single exchange. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Aggressive Exchange.
主动式交换旨在允许安全关联、密钥交换和与身份验证相关的有效载荷一起传输。将安全关联、密钥交换和身份验证相关信息合并到一条消息中，以不提供身份保护为代价减少了往返次数。未提供身份保护，因为身份是在建立公共共享秘密之前交换的，因此无法对身份进行加密。此外，激进的Exchange正试图在单个Exchange中建立所有安全相关信息。下图显示了每条消息中发送的可能有效负载的消息，以及主动式Exchange示例的注释。
AGGRESSIVE EXCHANGE
积极交换
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). There can be only one Proposal and one Transform offered (i.e. no choices) in order for the aggressive exchange to work. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks are also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the initiator transmits identification information.
在第一条消息（1）中，发起方生成其认为足以保护给定情况下的通信量的建议。安全关联、建议和转换有效负载包含在安全关联有效负载中（用于表示）。只有一个提议和一个转换（即没有选择）才能让积极的交换发挥作用。还传输用于获得公共共享秘密的密钥材料和用于保证活跃性和防止重播攻击的随机信息。认证机制应使用双方提供的随机信息提供参与交换的共享证据。此外，启动器发送标识信息。
In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Keying material used to arrive at a common shared secret and random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第二条消息（2）中，响应者指示它已接受的与安全关联、建议和转换有效负载的保护套件。还传输用于获得公共共享秘密和随机信息的密钥材料，这些信息用于保证活动性和防止重播攻击。认证机制应使用双方提供的随机信息提供参与交换的共享证据。此外，响应者发送识别信息。所有这些信息都是在商定的认证功能的保护下传输的。如果未接受建议的保护套件，则本地安全策略将指示响应者的操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange.
在第三（3）条消息中，发起方传输商定的认证功能的结果。此信息在公共共享机密的保护下传输。如果在这些消息期间发生错误，本地安全策略将指示操作。一种可能的操作是作为信息交换的一部分传输Notify有效负载。
The Informational Exchange is designed as a one-way transmittal of information that can be used for security association management. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange.
信息交换设计为单向信息传输，可用于安全关联管理。下图显示了每条消息中发送的可能有效负载的消息，以及信息交换示例的注释。
INFORMATIONAL EXCHANGE
信息交流
# Initiator Direction Responder NOTE
(1) HDR*; N/D => Error Notification or Deletion
# Initiator Direction Responder NOTE
(1) HDR*; N/D => Error Notification or Deletion
In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete payload.
在第一条消息（1）中，发起方或响应方发送ISAKMP Notify或Delete有效负载。
If the Informational Exchange occurs prior to the exchange of keying meterial during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA.
如果在ISAKMP第1阶段协商期间，信息交换发生在密钥交换之前，则不会为信息交换提供保护。交换密钥资料或建立ISAKMP SA后，必须在密钥资料或ISAKMP SA提供的保护下传输信息交换。
All exchanges are similar in that with the beginning of any exchange, cryptographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Message ID (MID) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informational Exchange will be processed correctly. The only exception to this is when the Commit Bit of the ISAKMP Header is set. When the Commit Bit is set, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation, rather than a new Message ID (MID). This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. For a description of the Commit Bit, see section 3.1.
所有交换的相似之处在于，在任何交换开始时，必须进行加密同步。信息交换是交换，而不是ISAKMP消息。因此，信息交换的消息ID（MID）的生成应该独立于其他正在进行的通信的IVs。这将确保对现有通信保持加密同步，并正确处理信息交换。唯一的例外是设置了ISAKMP头的提交位。设置提交位时，信息交换的消息ID字段必须包含原始ISAKMP第2阶段SA协商的消息ID，而不是新的消息ID（MID）。这样做是为了确保与连接的Notify消息的信息交换可以与正确的阶段2 SA相关联。有关提交位的描述，请参见第3.1节。
5 ISAKMP Payload Processing
5 ISAKMP有效负载处理
Section 3 describes the ISAKMP payloads. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI. This section describes the processing for each of the payloads. This section suggests the logging of events to a system audit file. This action is controlled by a system security policy and is, therefore, only a suggested action.
第3节介绍了ISAKMP有效载荷。这些有效载荷用于第4节所述的交换，并可用于为特定DOI定义的交换。本节描述每个有效载荷的处理。本节建议将事件记录到系统审核文件中。此操作由系统安全策略控制，因此，它只是建议的操作。
Every ISAKMP message has basic processing applied to insure protocol reliability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP Header are not the same, then the ISAKMP message MUST be rejected. The receiving entity (initiator or responder) MUST do the following:
每个ISAKMP消息都应用了基本的处理，以确保协议的可靠性，并最大限度地减少威胁，如拒绝服务和重播攻击。所有处理都应包括数据包长度检查，以确保收到的数据包至少与ISAKMP报头中给定的长度相同。如果ISAKMP消息长度和ISAKMP头的有效负载长度字段中的值不相同，则必须拒绝ISAKMP消息。接收实体（发起方或响应方）必须执行以下操作：
1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the appropriate system audit file.
1. 负载长度不等的事件可能会记录在相应的系统审核文件中。
2. An Informational Exchange with a Notification payload containing the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
2. 具有包含不等有效载荷长度消息类型的通知有效载荷的信息交换可被发送到发送实体。此操作由系统安全策略决定。
When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following:
传输ISAKMP消息时，传输实体（发起方或响应方）必须执行以下操作：
1. Set a timer and initialize a retry counter.
1. 设置计时器并初始化重试计数器。
NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff).
注意：实现不能使用固定计时器。相反，应根据测量的往返时间动态调整传输计时器值。此外，同一数据包的连续重传之间应间隔越来越长的时间间隔（例如，指数退避）。
2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented.
2. 如果计时器过期，则重新发送ISAKMP消息，并减少重试计数器。
3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file.
3. 如果重试计数器达到零（0），则可能会在相应的系统审核文件中记录“达到重试限制”事件。
4. The ISAKMP protocol machine clears all states and returns to IDLE.
4. ISAKMP协议机器清除所有状态并返回空闲状态。
When creating an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following:
创建ISAKMP消息时，传输实体（发起方或响应方）必须执行以下操作：
1. Create the respective cookie. See section 2.5.3 for details.
1. 创建相应的cookie。详见第2.5.3节。
2. Determine the relevant security characteristics of the session (i.e. DOI and situation).
2. 确定会话的相关安全特性（即DOI和情况）。
3. Construct an ISAKMP Header with fields as described in section 3.1.
3. 如第3.1节所述，使用字段构造ISAKMP标头。
4. Construct other ISAKMP payloads, depending on the exchange type.
4. 根据exchange类型构造其他ISAKMP有效负载。
5. Transmit the message to the destination host as described in section5.1.
5. 如第5.1节所述，将消息传输至目标主机。
When an ISAKMP message is received, the receiving entity (initiator or responder) MUST do the following:
收到ISAKMP消息时，接收实体（发起方或响应方）必须执行以下操作：
1. Verify the Initiator and Responder "cookies". If the cookie validation fails, the message is discarded and the following actions are taken:
1. 验证启动器和响应程序“cookies”。如果cookie验证失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID COOKIE, MAY be logged in the appropriate system audit file.
(a) 无效COOKIE事件可能记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效COOKIE消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
2. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken:
2. 检查下一个有效负载字段以确认其有效。如果下一个有效负载字段验证失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file.
(a) 下一有效负载无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效有效负载类型消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
3. Check the Major and Minor Version fields to confirm they are correct (see section 3.1). If the Version field validation fails, the message is discarded and the following actions are
3. 检查主要版本和次要版本字段，确认其正确性（见第3.1节）。如果版本字段验证失败，则丢弃该消息并执行以下操作
taken:
拿：
(a) The event, INVALID ISAKMP VERSION, MAY be logged in the appropriate system audit file.
(a) ISAKMP版本无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效主版本或无效次版本消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
4. Check the Exchange Type field to confirm it is valid. If the Exchange Type field validation fails, the message is discarded and the following actions are taken:
4. 检查“交换类型”字段以确认其有效性。如果Exchange类型字段验证失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID EXCHANGE TYPE, MAY be logged in the appropriate system audit file.
(a) 无效的EXCHANGE类型事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-EXCHANGE-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效交换类型消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
5. Check the Flags field to ensure it contains correct values. If the Flags field validation fails, the message is discarded and the following actions are taken:
5. 检查Flags字段以确保其包含正确的值。如果标志字段验证失败，则丢弃消息并采取以下操作：
(a) The event, INVALID FLAGS, MAY be logged in the appropriate systemaudit file.
(a) 无效标志事件可能会记录在相应的systemaudit文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-FLAGS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效标志消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
6. Check the Message ID field to ensure it contains correct values. If the Message ID validation fails, the message is discarded and the following actions are taken:
6. 检查消息ID字段以确保其包含正确的值。如果消息ID验证失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID MESSAGE ID, MAY be logged in the appropriate system audit file.
(a) 消息ID无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-MESSAGE-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效消息ID消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
7. Processing of the ISAKMP message continues using the value in the Next Payload field.
7. 使用下一个有效负载字段中的值继续处理ISAKMP消息。
When creating any of the ISAKMP Payloads described in sections 3.4 through 3.15 a Generic Payload Header is placed at the beginning of these payloads. When creating the Generic Payload Header, the transmitting entity (initiator or responder) MUST do the following:
当创建第3.4节至第3.15节中所述的任何ISAKMP有效载荷时，通用有效载荷标题放置在这些有效载荷的开头。创建通用有效负载标头时，传输实体（启动器或响应者）必须执行以下操作：
1. Place the value of the Next Payload in the Next Payload field. These values are described in section 3.1.
1. 将下一个有效负载的值放入下一个有效负载字段。第3.1节中描述了这些值。
2. Place the value zero (0) in the RESERVED field.
2. 将值零（0）放在保留字段中。
3. Place the length (in octets) of the payload in the Payload Length field.
3. 将有效负载的长度（以八位字节为单位）放入有效负载长度字段。
4. Construct the payloads as defined in the remainder of this section.
4. 按照本节剩余部分中的定义构造有效载荷。
When any of the ISAKMP Payloads are received, the receiving entity (initiator or responder) MUST do the following:
当收到任何ISAKMP有效载荷时，接收实体（启动器或响应者）必须执行以下操作：
1. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken:
1. 检查下一个有效负载字段以确认其有效。如果下一个有效负载字段验证失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file.
(a) 下一有效负载无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效有效负载类型消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
2. Verify the RESERVED field contains the value zero. If the value in the RESERVED field is not zero, the message is discarded and the following actions are taken:
2. 验证保留字段是否包含值零。如果保留字段中的值不为零，则丢弃该消息并执行以下操作：
(a) The event, INVALID RESERVED FIELD, MAY be logged in the appropriate system audit file.
(a) “无效保留字段”事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 可以向发送实体发送具有包含错误建议语法或无效负载格式错误消息类型的通知有效负载的信息交换。此操作由系统安全策略决定。
3. Process the remaining payloads as defined by the Next Payload field.
3. 处理下一个有效载荷字段定义的剩余有效载荷。
When creating a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following:
创建安全关联有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Domain of Interpretation for which this negotiation is being performed.
1. 确定正在进行协商的解释领域。
2. Determine the situation within the determined DOI for which this negotiation is being performed.
2. 确定正在执行此协商的已确定DOI内的情况。
3. Determine the proposal(s) and transform(s) within the situation. These are described, respectively, in sections 3.5 and 3.6.
3. 确定方案并在情况中进行转换。这些分别在第3.5节和第3.6节中描述。
4. Construct a Security Association payload.
4. 构造安全关联负载。
5. Transmit the message to the receiving entity as described in section 5.1.
5. 按照第5.1节所述，向接收实体发送消息。
When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到安全关联有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the message is discarded and the following actions are taken:
1. 确定是否支持解释域（DOI）。如果DOI确定失败，则丢弃消息并采取以下操作：
(a) The event, INVALID DOI, MAY be logged in the appropriate system audit file.
(a) 无效DOI事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含DOI-NOT-SUPPORTED消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
2. Determine if the given situation can be protected. If the Situation determination fails, the message is discarded and the following actions are taken:
2. 确定给定的情况是否可以得到保护。如果情况确定失败，则丢弃消息并采取以下操作：
(a) The event, INVALID SITUATION, MAY be logged in the appropriate system audit file.
(a) 无效情况事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 可以向发送实体发送具有包含情形不支持的消息类型的通知有效负载的信息交换。此操作由系统安全策略决定。
3. Process the remaining payloads (i.e. Proposal, Transform) of the Security Association Payload. If the Security Association
3. 处理安全关联有效负载的剩余有效负载（即建议、转换）。如果安全协会
Proposal (as described in sections 5.5 and 5.6) is not accepted, then the following actions are taken:
不接受建议书（如第5.5节和第5.6节所述），则采取以下措施：
(a) The event, INVALID PROPOSAL, MAY be logged in the appropriate system audit file.
(a) 无效提案事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the NO-PROPOSAL-CHOSEN message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含未选择的消息类型的通知有效载荷的信息交换可被发送到发送实体。此操作由系统安全策略决定。
When creating a Proposal Payload, the transmitting entity (initiator or responder) MUST do the following:
创建提案有效负载时，传输实体（发起人或响应人）必须执行以下操作：
1. Determine the Protocol for this proposal.
1. 确定此提案的方案。
2. Determine the number of proposals to be offered for this protocol and the number of transforms for each proposal. Transforms are described in section 3.6.
2. 确定为本协议提供的提案数量以及每个提案的转换数量。第3.6节描述了变换。
3. Generate a unique pseudo-random SPI.
3. 生成唯一的伪随机SPI。
4. Construct a Proposal payload.
4. 构建一个提案有效负载。
When a Proposal payload is received, the receiving entity (initiator or responder) MUST do the following:
收到提案有效负载时，接收实体（发起人或响应人）必须执行以下操作：
1. Determine if the Protocol is supported. If the Protocol-ID field is invalid, the payload is discarded and the following actions are taken:
1. 确定是否支持该协议。如果协议ID字段无效，则丢弃有效负载并采取以下操作：
(a) The event, INVALID PROTOCOL, MAY be logged in the appropriate system audit file.
(a) 协议无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-PROTOCOL-ID message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效协议ID消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
2. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following actions are taken:
2. 确定SPI是否有效。如果SPI无效，则丢弃有效负载并采取以下措施：
(a) The event, INVALID SPI, MAY be logged in the appropriate system audit file.
(a) 无效SPI事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-SPI message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含INVALID-SPI消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
3. Ensure the Proposals are presented according to the details given in section 3.5 and 4.2. If the proposals are not formed correctly, the following actions are taken:
3. 确保根据第3.5节和第4.2节给出的详细信息提交建议书。如果建议书格式不正确，将采取以下措施：
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are logged in the appropriate system audit file.
(a) 可能的事件、错误的建议语法、无效的建议都记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 可以向发送实体发送具有包含错误建议语法或无效负载格式错误消息类型的通知有效负载的信息交换。此操作由系统安全策略决定。
4. Process the Proposal and Transform payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1.
4. 处理提案并转换下一个有效载荷字段定义的有效载荷。第4.2.1节给出了处理这些有效载荷的示例。
When creating a Transform Payload, the transmitting entity (initiator or responder) MUST do the following:
创建转换有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Transform # for this transform.
1. 确定此变换的变换。
2. Determine the number of transforms to be offered for this proposal. Transforms are described in sections 3.6.
2. 确定要为此提案提供的转换数量。第3.6节描述了变换。
3. Construct a Transform payload.
3. 构造一个转换负载。
When a Transform payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到转换有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Transform is supported. If the Transform-ID field contains an unknown or unsupported value, then that Transform payload MUST be ignored and MUST NOT cause the generation of an INVALID TRANSFORM event. If the Transform-ID field is invalid, the payload is discarded and the following actions are taken:
1. 确定是否支持转换。如果Transform ID字段包含未知或不支持的值，则必须忽略该转换负载，并且不得导致生成无效转换事件。如果Transform ID字段无效，则丢弃有效负载并执行以下操作：
(a) The event, INVALID TRANSFORM, MAY be logged in the appropriate system audit file.
(a) 无效转换事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-TRANSFORM-ID message type MAY be sent
(b) 可能会发送包含无效转换ID消息类型的通知有效负载的信息交换
to the transmitting entity. This action is dictated by a system security policy.
发送到发送实体。此操作由系统安全策略决定。
2. Ensure the Transforms are presented according to the details given in section 3.6 and 4.2. If the transforms are not formed correctly, the following actions are taken:
2. 确保根据第3.6节和第4.2节中给出的详细信息呈现变换。如果变换的格式不正确，将采取以下操作：
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, INVALID ATTRIBUTES, are logged in the appropriate system audit file.
(a) 可能的事件、错误的建议语法、无效的转换、无效的属性都记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 可以向发送实体发送信息交换，该信息交换具有包含BAD-PROPOSITION-SYMBOL、payload-MARGORED或ATTRIBUTES-NOT-SUPPORED消息类型的通知有效载荷。此操作由系统安全策略决定。
3. Process the subsequent Transform and Proposal payloads as defined by the Next Payload field. Examples of processing these payloads are given in section 4.2.1.
3. 处理由下一个有效载荷字段定义的后续转换和建议有效载荷。第4.2.1节给出了处理这些有效载荷的示例。
When creating a Key Exchange Payload, the transmitting entity (initiator or responder) MUST do the following:
创建密钥交换有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Key Exchange to be used as defined by the DOI.
1. 根据DOI的定义确定要使用的密钥交换。
2. Determine the usage of the Key Exchange Data field as defined by the DOI.
2. 确定DOI定义的密钥交换数据字段的用法。
3. Construct a Key Exchange payload.
3. 构造密钥交换有效负载。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When a Key Exchange payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到密钥交换有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Key Exchange is supported. If the Key Exchange determination fails, the message is discarded and the following actions are taken:
1. 确定是否支持密钥交换。如果密钥交换确定失败，则丢弃该消息并采取以下操作：
(a) The event, INVALID KEY INFORMATION, MAY be logged in the appropriate system audit file.
(a) 无效密钥信息事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-KEY-INFORMATION message type MAY be
(b) 可能需要与包含无效密钥信息消息类型的通知负载进行信息交换
sent to the transmitting entity. This action is dictated by a system security policy.
发送到发送实体。此操作由系统安全策略决定。
When creating an Identification Payload, the transmitting entity (initiator or responder) MUST do the following:
创建标识有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Identification information to be used as defined by the DOI (and possibly the situation).
1. 根据内政部的定义确定要使用的识别信息（可能还有情况）。
2. Determine the usage of the Identification Data field as defined by the DOI.
2. 确定DOI定义的标识数据字段的用法。
3. Construct an Identification payload.
3. 构造一个识别有效载荷。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When an Identification payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到标识有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Identification Type is supported. This may be based on the DOI and Situation. If the Identification determination fails, the message is discarded and the following actions are taken:
1. 确定是否支持标识类型。这可能是基于内政部和情况。如果标识确定失败，则丢弃该消息并采取以下措施：
(a) The event, INVALID ID INFORMATION, MAY be logged in the appropriate system audit file.
(a) ID信息无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-ID-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效ID-INFORMATION消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
When creating a Certificate Payload, the transmitting entity (initiator or responder) MUST do the following:
创建证书有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Certificate Encoding to be used. This may be specified by the DOI.
1. 确定要使用的证书编码。这可能由内政部指定。
2. Ensure the existence of a certificate formatted as defined by the Certificate Encoding.
2. 确保存在由证书编码定义的格式的证书。
3. Construct a Certificate payload.
3. 构造一个证书有效负载。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When a Certificate payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到证书有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken:
1. 确定是否支持证书编码。如果不支持证书编码，则丢弃有效负载并采取以下操作：
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file.
(a) 无效证书类型的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效证书编码消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
2. Process the Certificate Data field. If the Certificate Data is invalid or improperly formatted, the payload is discarded and the following actions are taken:
2. 处理证书数据字段。如果证书数据无效或格式不正确，则丢弃有效负载并采取以下操作：
(a) The event, INVALID CERTIFICATE, MAY be logged in the appropriate system audit file.
(a) 无效证书事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-CERTIFICATE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效证书消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
When creating a Certificate Request Payload, the transmitting entity (initiator or responder) MUST do the following:
创建证书请求有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the type of Certificate Encoding to be requested. This may be specified by the DOI.
1. 确定要请求的证书编码的类型。这可能由内政部指定。
2. Determine the name of an acceptable Certificate Authority which is to be requested (if applicable).
2. 确定要请求的可接受证书颁发机构的名称（如果适用）。
3. Construct a Certificate Request payload.
3. 构造证书请求有效负载。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When a Certificate Request payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到证书请求有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Certificate Encoding is supported. If the Certificate Encoding is invalid, the payload is discarded and the following actions are taken:
1. 确定是否支持证书编码。如果证书编码无效，则丢弃有效负载并采取以下操作：
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the appropriate system audit file.
(a) 无效证书类型的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-CERT-ENCODING message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效证书编码消息类型的通知有效负载的信息交换可以发送到发送实体。此操作由系统安全策略决定。
If the Certificate Encoding is not supported, the payload is discarded and the following actions are taken:
如果不支持证书编码，则丢弃有效负载并采取以下操作：
(a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in the appropriate system audit file.
(a) 证书类型不受支持的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the CERT-TYPE-UNSUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含CERT-TYPE-UNSUPPORTED消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
2. Determine if the Certificate Authority is supported for the specified Certificate Encoding. If the Certificate Authority is invalid or improperly formatted, the payload is discarded and the following actions are taken:
2. 确定指定的证书编码是否支持证书颁发机构。如果证书颁发机构无效或格式不正确，则丢弃有效负载并采取以下操作：
(a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in the appropriate system audit file.
(a) 证书颁发机构无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-CERT-AUTHORITY message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 可以向发送实体发送具有包含无效证书授权消息类型的通知有效负载的信息交换。此操作由系统安全策略决定。
3. Process the Certificate Request. If a requested Certificate Type with the specified Certificate Authority is not available, then the payload is discarded and the following actions are taken:
3. 处理证书请求。如果请求的具有指定证书颁发机构的证书类型不可用，则丢弃有效负载并采取以下操作：
(a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the appropriate system audit file.
(a) 证书不可用事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the CERTIFICATE-UNAVAILABLE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含证书不可用消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
When creating a Hash Payload, the transmitting entity (initiator or responder) MUST do the following:
创建哈希有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Hash function to be used as defined by the SA negotiation.
1. 确定SA协商定义的要使用的哈希函数。
2. Determine the usage of the Hash Data field as defined by the DOI.
2. 确定DOI定义的哈希数据字段的用法。
3. Construct a Hash payload.
3. 构造一个散列负载。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When a Hash payload is received, the receiving entity (initiator or responder) MUST do the following:
收到哈希有效负载时，接收实体（启动器或响应者）必须执行以下操作：
1. Determine if the Hash is supported. If the Hash determination fails, the message is discarded and the following actions are taken:
1. 确定是否支持哈希。如果哈希确定失败，则丢弃消息并采取以下操作：
(a) The event, INVALID HASH INFORMATION, MAY be logged in the appropriate system audit file.
(a) 该事件（无效哈希信息）可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-HASH-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效散列信息消息类型的通知有效负载的信息交换可被发送到发送实体。此操作由系统安全策略决定。
2. Perform the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the Hash function fails, the message is discarded and the following actions are taken:
2. 执行DOI和/或密钥交换协议文档中概述的哈希函数。如果哈希函数失败，则丢弃消息并采取以下操作：
(a) The event, INVALID HASH VALUE, MAY be logged in the appropriate system audit file.
(a) 该事件（无效哈希值）可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含认证失败消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
When creating a Signature Payload, the transmitting entity (initiator or responder) MUST do the following:
创建签名有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the Signature function to be used as defined by the SA negotiation.
1. 确定SA协商定义的要使用的签名函数。
2. Determine the usage of the Signature Data field as defined by the DOI.
2. 确定DOI定义的签名数据字段的用法。
3. Construct a Signature payload.
3. 构造一个签名有效负载。
4. Transmit the message to the receiving entity as described in section 5.1.
4. 按照第5.1节所述，向接收实体发送消息。
When a Signature payload is received, the receiving entity (initiator or responder) MUST do the following:
收到签名有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Signature is supported. If the Signature determination fails, the message is discarded and the following actions are taken:
1. 确定是否支持签名。如果签名确定失败，则丢弃消息并采取以下操作：
(a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in the appropriate system audit file.
(a) 无效签名信息事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the INVALID-SIGNATURE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含无效签名消息类型的通知有效载荷的信息交换可以发送给发送实体。此操作由系统安全策略决定。
2. Perform the Signature function as outlined in the DOI and/or Key Exchange protocol documents. If the Signature function fails, the message is discarded and the following actions are taken:
2. 执行DOI和/或密钥交换协议文件中概述的签名功能。如果签名功能失败，则丢弃消息并采取以下操作：
(a) The event, INVALID SIGNATURE VALUE, MAY be logged in the appropriate system audit file.
(a) 签名值无效的事件可能会记录在相应的系统审核文件中。
(b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy.
(b) 具有包含认证失败消息类型的通知有效负载的信息交换可以发送给发送实体。此操作由系统安全策略决定。
When creating a Nonce Payload, the transmitting entity (initiator or responder) MUST do the following:
创建Nonce有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Create a unique random value to be used as a nonce.
1. 创建一个唯一的随机值用作nonce。
2. Construct a Nonce payload.
2. 构造一个Nonce有效负载。
3. Transmit the message to the receiving entity as described in section 5.1.
3. 按照第5.1节所述，向接收实体发送消息。
When a Nonce payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到Nonce有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. There are no specific procedures for handling Nonce payloads. The procedures are defined by the exchange types (and possibly the DOI and Key Exchange descriptions).
1. 没有处理临时有效载荷的具体程序。这些过程由交换类型（可能还有DOI和密钥交换描述）定义。
During communications it is possible that errors may occur. The Informational Exchange with a Notify Payload provides a controlled method of informing a peer entity that errors have occurred during protocol processing. It is RECOMMENDED that Notify Payloads be sent in a separate Informational Exchange rather than appending a Notify Payload to an existing exchange.
在通信过程中，可能会发生错误。与Notify有效负载的信息交换提供了一种受控方法，用于通知对等实体在协议处理过程中发生了错误。建议在单独的信息交换中发送Notify有效负载，而不是将Notify有效负载附加到现有交换。
When creating a Notification Payload, the transmitting entity (initiator or responder) MUST do the following:
创建通知有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the DOI for this Notification.
1. 确定此通知的DOI。
2. Determine the Protocol-ID for this Notification.
2. 确定此通知的协议ID。
3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 4 octet SPIs.
3. 根据协议ID字段确定SPI大小。此字段是必需的，因为不同的安全协议具有不同的SPI大小。例如，ISAKMP将发起方和响应方cookie对（16个八位组）组合为一个SPI，而ESP和AH有4个八位组SPI。
4. Determine the Notify Message Type based on the error or status message desired.
4. 根据所需的错误或状态消息确定通知消息类型。
5. Determine the SPI which is associated with this notification.
5. 确定与此通知关联的SPI。
6. Determine if additional Notification Data is to be included. This is additional information specified by the DOI.
6. 确定是否包含其他通知数据。这是内政部指定的附加信息。
7. Construct a Notification payload.
7. 构造一个通知负载。
8. Transmit the message to the receiving entity as described in section 5.1.
8. 按照第5.1节所述，向接收实体发送消息。
Because the Informational Exchange with a Notification payload is a unidirectional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing.
由于与通知有效负载的信息交换是单向消息，因此不会执行重传。当地安全政策将规定继续执行的程序。
However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity.
但是，我们建议接收实体将通知有效负载错误事件记录在适当的系统审核文件中。
If the Informational Exchange occurs prior to the exchange of keying material during an ISAKMP Phase 1 negotiation there will be no protection provided for the Informational Exchange. Once the keying material has been exchanged or the ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA.
如果信息交换发生在ISAKMP第1阶段协商期间交换密钥材料之前，则不会为信息交换提供任何保护。交换密钥资料或建立ISAKMP SA后，必须在密钥资料或ISAKMP SA提供的保护下传输信息交换。
When a Notification payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到通知有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Determine if the Informational Exchange has any protection applied to it by checking the Encryption Bit and the Authentication Only Bit in the ISAKMP Header. If the Encryption Bit is set, i.e. the Informational Exchange is encrypted, then the message MUST be decrypted using the (in-progress or completed) ISAKMP SA. Once the decryption is complete the processing can continue as described below. If the Authentication Only Bit is set, then the message MUST be authenticated using the (in-progress or completed) ISAKMP SA. Once the authentication is completed, the processing can continue as described below. If the Informational Exchange is not encrypted or authentication, the payload processing can continue as described below.
1. 通过检查ISAKMP标头中的加密位和仅验证位，确定信息交换是否对其应用了任何保护。如果设置了加密位，即信息交换已加密，则必须使用（正在进行或已完成）ISAKMP SA对消息进行解密。解密完成后，处理可以继续进行，如下所述。如果设置了仅身份验证位，则必须使用（正在进行或已完成）ISAKMP SA对消息进行身份验证。身份验证完成后，处理可以如下所述继续。如果信息交换未加密或未进行身份验证，则有效负载处理可以如下所述继续进行。
2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken:
2. 确定是否支持解释域（DOI）。如果DOI确定失败，则丢弃有效负载并采取以下措施：
(a) The event, INVALID DOI, MAY be logged in the appropriate system audit file.
(a) 无效DOI事件可能会记录在相应的系统审核文件中。
3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken:
3. 确定是否支持协议Id。如果协议Id确定失败，则丢弃有效负载并采取以下操作：
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file.
(a) 无效协议ID事件可能会记录在相应的系统审核文件中。
4. Determine if the SPI is valid. If the SPI is invalid, the payload is discarded and the following action is taken:
4. 确定SPI是否有效。如果SPI无效，则丢弃有效负载并采取以下措施：
(a) The event, INVALID SPI, MAY be logged in the appropriate system audit file.
(a) 无效SPI事件可能会记录在相应的系统审核文件中。
5. Determine if the Notify Message Type is valid. If the Notify Message Type is invalid, the payload is discarded and the following action is taken:
5. 确定通知消息类型是否有效。如果Notify消息类型无效，则丢弃有效负载并采取以下操作：
(a) The event, INVALID MESSAGE TYPE, MAY be logged in the appropriate system audit file.
(a) 无效消息类型的事件可能会记录在相应的系统审核文件中。
6. Process the Notification payload, including additional Notification Data, and take appropriate action, according to local security policy.
6. 根据本地安全策略，处理通知负载，包括其他通知数据，并采取适当的操作。
During communications it is possible that hosts may be compromised or that information may be intercepted during transmission. Determining whether this has occurred is not an easy task and is outside the scope of this memo. However, if it is discovered that transmissions are being compromised, then it is necessary to establish a new SA and delete the current SA.
在通信过程中，主机可能受到损害，或者信息可能在传输过程中被截获。确定是否发生了这种情况并非易事，不在本备忘录的范围之内。但是，如果发现传输被破坏，则有必要建立新SA并删除当前SA。
The Informational Exchange with a Delete Payload provides a controlled method of informing a peer entity that the transmitting entity has deleted the SA(s). Deletion of Security Associations MUST always be performed under the protection of an ISAKMP SA. The receiving entity SHOULD clean up its local SA database. However, upon receipt of a Delete message the SAs listed in the Security Parameter Index (SPI) field of the Delete payload cannot be used with the transmitting entity. The SA Establishment procedure must be invoked to re-establish secure communications.
与删除有效载荷的信息交换提供了通知对等实体发送实体已删除SA的受控方法。安全关联的删除必须始终在ISAKMP SA的保护下执行。接收实体应清理其本地SA数据库。但是，在收到删除消息后，删除有效负载的安全参数索引（SPI）字段中列出的SA不能与传输实体一起使用。必须调用SA建立过程来重新建立安全通信。
When creating a Delete Payload, the transmitting entity (initiator or responder) MUST do the following:
创建删除有效负载时，传输实体（发起方或响应方）必须执行以下操作：
1. Determine the DOI for this Deletion.
1. 确定此删除的DOI。
2. Determine the Protocol-ID for this Deletion.
2. 确定此删除的协议ID。
3. Determine the SPI size based on the Protocol-ID field. This field is necessary because different security protocols have different SPI sizes. For example, ISAKMP combines the Initiator and Responder cookie pair (16 octets) as a SPI, while ESP and AH have 4 octet SPIs.
3. 根据协议ID字段确定SPI大小。此字段是必需的，因为不同的安全协议具有不同的SPI大小。例如，ISAKMP将发起方和响应方cookie对（16个八位组）组合为一个SPI，而ESP和AH有4个八位组SPI。
4. Determine the # of SPIs to be deleted for this protocol.
4. 确定要为此协议删除的SPI的#。
5. Determine the SPI(s) which is (are) associated with this deletion.
5. 确定与此删除关联的SPI。
6. Construct a Delete payload.
6. 构造一个删除负载。
7. Transmit the message to the receiving entity as described in section 5.1.
7. 按照第5.1节所述，向接收实体发送消息。
Because the Informational Exchange with a Delete payload is a unidirectional message a retransmission will not be performed. The local security policy will dictate the procedures for continuing. However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in the appropriate system audit file by the receiving entity.
由于与删除有效负载的信息交换是单向消息，因此不会执行重传。当地安全政策将规定继续执行的程序。但是，我们建议接收实体在适当的系统审核文件中记录删除有效负载错误事件。
As described above, the Informational Exchange with a Delete payload MUST be transmitted under the protection provided by an ISAKMP SA.
如上所述，与删除有效负载的信息交换必须在ISAKMP SA提供的保护下传输。
When a Delete payload is received, the receiving entity (initiator or responder) MUST do the following:
当接收到删除有效负载时，接收实体（发起方或响应方）必须执行以下操作：
1. Because the Informational Exchange is protected by some security service (e.g. authentication for an Auth-Only SA, encryption for other exchanges), the message MUST have these security services applied using the ISAKMP SA. Once the security service processing is complete the processing can continue as described below. Any errors that occur during the security service processing will be evident when checking information in the Delete payload. The local security policy SHOULD dictate any action to be taken as a result of security service processing errors.
1. 由于信息交换受到某些安全服务的保护（例如，仅授权SA的身份验证、其他交换的加密），因此消息必须使用ISAKMP SA应用这些安全服务。安全服务处理完成后，可以按如下所述继续处理。在检查删除有效负载中的信息时，安全服务处理过程中发生的任何错误都会很明显。本地安全策略应规定由于安全服务处理错误而要采取的任何操作。
2. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the payload is discarded and the following action is taken:
2. 确定是否支持解释域（DOI）。如果DOI确定失败，则丢弃有效负载并采取以下措施：
(a) The event, INVALID DOI, MAY be logged in the appropriate system audit file.
(a) 无效DOI事件可能会记录在相应的系统审核文件中。
3. Determine if the Protocol-Id is supported. If the Protocol-Id determination fails, the payload is discarded and the following action is taken:
3. 确定是否支持协议Id。如果协议Id确定失败，则丢弃有效负载并采取以下操作：
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the appropriate system audit file.
(a) 无效协议ID事件可能会记录在相应的系统审核文件中。
4. Determine if the SPI is valid for each SPI included in the Delete payload. For each SPI that is invalid, the following action is taken:
4. 确定SPI对于删除有效负载中包含的每个SPI是否有效。对于每个无效的SPI，将采取以下措施：
(a) The event, INVALID SPI, MAY be logged in the appropriate system audit file.
(a) 无效SPI事件可能会记录在相应的系统审核文件中。
5. Process the Delete payload and take appropriate action, according to local security policy. As described above, one appropriate action SHOULD include cleaning up the local SA database.
5. 根据本地安全策略，处理删除有效负载并采取适当的操作。如上所述，一个适当的操作应该包括清理本地SA数据库。
6 Conclusions
6结论
The Internet Security Association and Key Management Protocol (ISAKMP) is a well designed protocol aimed at the Internet of the future. The massive growth of the Internet will lead to great diversity in network utilization, communications, security requirements, and security mechanisms. ISAKMP contains all the features that will be needed for this dynamic and expanding communications environment.
互联网安全协会和密钥管理协议（ISAKMP）是一个针对未来互联网的精心设计的协议。互联网的大规模增长将导致网络利用、通信、安全需求和安全机制的巨大差异。ISAKMP包含了这个动态且不断扩展的通信环境所需的所有功能。
ISAKMP's Security Association (SA) feature coupled with authentication and key establishment provides the security and flexibility that will be needed for future growth and diversity. This security diversity of multiple key exchange techniques, encryption algorithms, authentication mechanisms, security services, and security attributes will allow users to select the appropriate security for their network, communications, and security needs. The SA feature allows users to specify and negotiate security requirements with other users. An additional benefit of supporting multiple techniques in a single protocol is that as new techniques are developed they can easily be added to the protocol. This provides a path for the growth of Internet security services. ISAKMP supports both publicly or privately defined SAs, making it ideal for government, commercial, and private communications.
ISAKMP的安全关联（SA）功能与身份验证和密钥建立相结合，提供了未来增长和多样性所需的安全性和灵活性。多种密钥交换技术、加密算法、身份验证机制、安全服务和安全属性的这种安全多样性将允许用户为其网络、通信和安全需求选择适当的安全性。SA功能允许用户指定安全要求并与其他用户协商。在一个协议中支持多种技术的另一个好处是，随着新技术的开发，可以很容易地将它们添加到协议中。这为互联网安全服务的发展提供了一条道路。ISAKMP支持公共或私人定义的SA，使其成为政府、商业和私人通信的理想选择。
ISAKMP provides the ability to establish SAs for multiple security protocols and applications. These protocols and applications may be session-oriented or sessionless. Having one SA establishment protocol that supports multiple security protocols eliminates the need for multiple, nearly identical authentication, key exchange and SA establishment protocols when more than one security protocol is in use or desired. Just as IP has provided the common networking layer for the Internet, a common security establishment protocol is needed if security is to become a reality on the Internet. ISAKMP provides the common base that allows all other security protocols to interoperate.
ISAKMP提供了为多种安全协议和应用程序建立SAs的能力。这些协议和应用程序可以是面向会话的或无会话的。如果一个SA建立协议支持多个安全协议，则在使用或需要多个安全协议时，无需使用多个几乎相同的身份验证、密钥交换和SA建立协议。正如IP为Internet提供了公共网络层一样，如果要在Internet上实现安全，则需要一个公共安全建立协议。ISAKMP提供了允许所有其他安全协议互操作的公共基础。
ISAKMP follows good security design principles. It is not coupled to other insecure transport protocols, therefore it is not vulnerable or weakened by attacks on other protocols. Also, when more secure transport protocols are developed, ISAKMP can be easily migrated to them. ISAKMP also provides protection against protocol related attacks. This protection provides the assurance that the SAs and keys established are with the desired party and not with an attacker.
ISAKMP遵循良好的安全设计原则。它不与其他不安全的传输协议耦合，因此不会受到其他协议攻击的攻击或削弱。此外，当开发出更安全的传输协议时，ISAKMP可以很容易地迁移到这些协议中。ISAKMP还提供针对协议相关攻击的保护。此保护可确保所建立的SAs和密钥是由所需的一方而不是攻击者提供的。
ISAKMP also follows good protocol design principles. Protocol specific information only is in the protocol header, following the design principles of IPv6. The data transported by the protocol is separated into functional payloads. As the Internet grows and evolves, new payloads to support new security functionality can be added without modifying the entire protocol.
ISAKMP还遵循良好的协议设计原则。协议头中仅包含特定于协议的信息，遵循IPv6的设计原则。协议传输的数据被分离为功能有效载荷。随着互联网的发展和演变，可以添加新的有效负载来支持新的安全功能，而无需修改整个协议。
A ISAKMP Security Association Attributes
ISAKMP安全关联属性
As detailed in previous sections, ISAKMP is designed to provide a flexible and extensible framework for establishing and managing Security Associations and cryptographic keys. The framework provided by ISAKMP consists of header and payload definitions, exchange types for guiding message and payload exchanges, and general processing guidelines. ISAKMP does not define the mechanisms that will be used to establish and manage Security Associations and cryptographic keys in an authenticated and confidential manner. The definition of mechanisms and their application is the purview of individual Domains of Interpretation (DOIs).
如前几节所述，ISAKMP旨在为建立和管理安全关联和加密密钥提供灵活和可扩展的框架。ISAKMP提供的框架包括标头和有效负载定义、用于指导消息和有效负载交换的交换类型以及一般处理准则。ISAKMP未定义将用于以认证和保密方式建立和管理安全关联和加密密钥的机制。机制的定义及其应用是各个解释领域（DOI）的权限。
This section describes the ISAKMP values for the Internet IP Security DOI, supported security protocols, and identification values for ISAKMP Phase 1 negotiations. The Internet IP Security DOI is MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, in detail, the mechanisms and their application for establishing and managing Security Associations and cryptographic keys for IP Security.
本节介绍Internet IP安全DOI的ISAKMP值、支持的安全协议以及ISAKMP第1阶段协商的标识值。Internet IP安全DOI是实现IP安全的必需工具。[Oakley]和[IKE]详细描述了用于建立和管理IP安全的安全关联和加密密钥的机制及其应用。
As described in [IPDOI], the Internet IP Security DOI Assigned Number is one (1).
如[IPDOI]中所述，互联网IP安全DOI分配的编号为一（1）。
Values for supported security protocols are specified in the most recent "Assigned Numbers" RFC [STD-2]. Presented in the following table are the values for the security protocols supported by ISAKMP for the Internet IP Security DOI.
支持的安全协议的值在最新的“分配编号”RFC[STD-2]中指定。下表列出了ISAKMP为Internet IP安全DOI支持的安全协议的值。
Protocol Assigned Value RESERVED 0 ISAKMP 1
协议分配的保留值0 ISAKMP 1
All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other security protocols within that DOI will be numbered accordingly.
所有DOI必须保留协议ID为1的ISAKMP。该DOI内的所有其他安全协议将相应编号。
Security protocol values 2-15359 are reserved to IANA for future use. Values 15360-16383 are permanently reserved for private use amongst mutually consenting implementations. Such private use values are unlikely to be interoperable across different implementations.
安全协议值2-15359保留给IANA供将来使用。15360-16383的值永久保留，供双方同意的实现之间私人使用。这样的私有使用值不太可能跨不同的实现进行互操作。
The following table lists the assigned values for the Identification Type field found in the Identification payload during a generic Phase 1 exchange, which is not for a specific protocol.
下表列出了通用阶段1交换期间标识有效负载中标识类型字段的分配值，该字段不适用于特定协议。
ID Type Value ID_IPV4_ADDR 0 ID_IPV4_ADDR_SUBNET 1 ID_IPV6_ADDR 2 ID_IPV6_ADDR_SUBNET 3
ID类型值ID\ IPV4\地址0 ID\ IPV4\地址\子网1 ID\ IPV6\地址2 ID\ IPV6\地址\子网3
The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address.
ID_IPV4_ADDR类型指定一个四（4）个八位字节的IPV4地址。
The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, represented by two four (4) octet values. The first value is an IPv4 address. The second is an IPv4 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV4_ADDR_子网类型指定IPV4地址的范围，由两个四（4）个八位字节值表示。第一个值是IPv4地址。第二个是IPv4网络掩码。请注意，网络掩码中的1表示地址中的对应位是固定的，而0表示“通配符”位。
The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 address.
ID_IPV6_ADDR类型指定一个十六（16）个八位字节的IPV6地址。
The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is an IPv6 address. The second is an IPv6 network mask. Note that ones (1s) in the network mask indicate that the corresponding bit in the address is fixed, while zeros (0s) indicate a "wildcard" bit.
ID_IPV6_ADDR_子网类型指定一系列IPV6地址，由两个十六（16）个八位组值表示。第一个值是IPv6地址。第二个是IPv6网络掩码。请注意，网络掩码中的1表示地址中的对应位是固定的，而0表示“通配符”位。
B Defining a new Domain of Interpretation
定义一个新的解释领域
The Internet DOI may be sufficient to meet the security requirements of a large portion of the internet community. However, some groups may have a need to customize some aspect of a DOI, perhaps to add a different set of cryptographic algorithms, or perhaps because they want to make their security-relevant decisions based on something other than a host id or user id. Also, a particular group may have a need for a new exchange type, for example to support key management for multicast groups.
互联网DOI可能足以满足大部分互联网社区的安全要求。然而，一些组可能需要自定义DOI的某些方面，可能需要添加一组不同的加密算法，或者可能是因为他们希望根据主机id或用户id以外的内容做出与安全相关的决策。此外，特定组可能需要新的交换类型，例如，支持多播组的密钥管理。
This section discusses guidelines for defining a new DOI. The full specification for the Internet DOI can be found in [IPDOI].
本节讨论定义新DOI的指南。Internet DOI的完整规范可在[IPDOI]中找到。
Defining a new DOI is likely to be a time-consuming process. If at all possible, it is recommended that the designer begin with an existing DOI and customize only the parts that are unacceptable.
定义新的DOI可能是一个耗时的过程。如果可能，建议设计师从现有DOI开始，只定制不可接受的零件。
If a designer chooses to start from scratch, the following MUST be defined:
如果设计师选择从头开始，则必须定义以下内容：
o A "situation": the set of information that will be used to determine the required security services.
o “情况”：用于确定所需安全服务的一组信息。
o The set of security policies that must be supported.
o 必须支持的安全策略集。
o A scheme for naming security-relevant information, including encryption algorithms, key exchange algorithms, etc.
o 一种命名安全相关信息的方案，包括加密算法、密钥交换算法等。
o A syntax for the specification of proposed security services, attributes, and certificate authorities.
o 用于指定建议的安全服务、属性和证书颁发机构的语法。
o The specific formats of the various payload contents.
o 各种有效负载内容的特定格式。
o Additional exchange types, if required.
o 其他交换类型（如果需要）。
The situation is the basis for deciding how to protect a communications channel. It must contain all of the data that will be used to determine the types and strengths of protections applied in an SA. For example, a US Department of Defense DOI would probably use unpublished algorithms and have additional special attributes to negotiate. These additional security attributes would be included in the situation.
这种情况是决定如何保护通信信道的基础。它必须包含用于确定SA中应用的保护类型和强度的所有数据。例如，美国国防部内政部可能会使用未公布的算法，并具有额外的特殊属性进行谈判。这些额外的安全属性将包括在情况中。
Security policies define how various types of information must be categorized and protected. The DOI must define the set of security policies supported, because both parties in a negotiation must trust that the other party understands a situation, and will protect information appropriately, both in transit and in storage. In a corporate setting, for example, both parties in a negotiation must agree to the meaning of the term "proprietary information" before they can negotiate how to protect it.
安全策略定义了必须如何对各种类型的信息进行分类和保护。内政部必须定义所支持的安全策略集，因为谈判双方都必须相信另一方了解情况，并将适当地保护传输和存储中的信息。例如，在公司环境中，谈判双方必须同意“专有信息”一词的含义，然后才能就如何保护该信息进行谈判。
Note that including the required security policies in the DOI only specifies that the participating hosts understand and implement those policies in a full system context.
请注意，在DOI中包含所需的安全策略只指定参与的主机在完整的系统上下文中理解和实现这些策略。
Any DOI must define a consistent way to name cryptographic algorithms, certificate authorities, etc. This can usually be done by using IANA naming conventions, perhaps with some private extensions.
任何DOI都必须定义一种一致的方式来命名加密算法、证书颁发机构等。这通常可以通过使用IANA命名约定来完成，可能还有一些私有扩展。
In addition to simply specifying how to name entities, the DOI must also specify the format for complete proposals of how to protect traffic under a given situation.
除了简单地指定如何命名实体外，内政部还必须指定在给定情况下如何保护流量的完整提案的格式。
The DOI must specify the format of each of the payload types. For several of the payload types, ISAKMP has included fields that would have to be present across all DOI (such as a certificate authority in the certificate payload, or a key exchange identifier in the key exchange payload).
DOI必须指定每个有效负载类型的格式。对于几种有效负载类型，ISAKMP包含了必须在所有DOI中出现的字段（例如证书有效负载中的证书颁发机构，或密钥交换有效负载中的密钥交换标识符）。
If the basic exchange types are inadequate to meet the requirements within a DOI, a designer can define up to thirteen extra exchange types per DOI. The designer creates a new exchange type by choosing an unused exchange type value, and defining a sequence of messages composed of strings of the ISAKMP payload types.
如果基本交换类型不足以满足DOI内的要求，则设计者可以为每个DOI定义多达十三个额外的交换类型。设计器通过选择未使用的交换类型值并定义由ISAKMP有效负载类型字符串组成的消息序列来创建新的交换类型。
Note that any new exchange types must be rigorously analyzed for vulnerabilities. Since this is an expensive and imprecise undertaking, a new exchange type should only be created when absolutely necessary.
请注意，必须严格分析任何新的exchange类型的漏洞。由于这是一项昂贵且不精确的任务，因此只有在绝对必要时才应创建新的交换类型。
Security Considerations
安全考虑
Cryptographic analysis techniques are improving at a steady pace. The continuing improvement in processing power makes once computationally prohibitive cryptographic attacks more realistic. New cryptographic algorithms and public key generation techniques are also being developed at a steady pace. New security services and mechanisms are being developed at an accelerated pace. A consistent method of choosing from a variety of security services and mechanisms and to exchange attributes required by the mechanisms is important to security in the complex structure of the Internet. However, a system that locks itself into a single cryptographic algorithm, key exchange technique, or security mechanism will become increasingly vulnerable as time passes.
密码分析技术正在稳步改进。处理能力的不断提高使得曾经在计算上禁止的加密攻击变得更加现实。新的密码算法和公钥生成技术也在稳步发展。新的安全服务和机制正在加速发展。在复杂的互联网结构中，从各种安全服务和机制中进行选择并交换机制所需属性的一致方法对于安全性非常重要。然而，随着时间的推移，将自身锁定在单一密码算法、密钥交换技术或安全机制中的系统将变得越来越脆弱。
UDP is an unreliable datagram protocol and therefore its use in ISAKMP introduces a number of security considerations. Since UDP is unreliable, but a key management protocol must be reliable, the reliability is built into ISAKMP. While ISAKMP utilizes UDP as its transport mechanism, it doesn't rely on any UDP information (e.g. checksum, length) for its processing.
UDP是一种不可靠的数据报协议，因此它在ISAKMP中的使用引入了许多安全注意事项。由于UDP不可靠，但密钥管理协议必须可靠，因此ISAKMP中内置了可靠性。虽然ISAKMP使用UDP作为其传输机制，但其处理不依赖任何UDP信息（如校验和、长度）。
Another issue that must be considered in the development of ISAKMP is the effect of firewalls on the protocol. Many firewalls filter out all UDP packets, making reliance on UDP questionable in certain environments.
在开发ISAKMP时必须考虑的另一个问题是防火墙对协议的影响。许多防火墙过滤掉所有UDP数据包，使得在某些环境中对UDP的依赖成为问题。
A number of very important security considerations are presented in [SEC-ARCH]. One bears repeating. Once a private session key is created, it must be safely stored. Failure to properly protect the private key from access both internal and external to the system completely nullifies any protection provided by the IP Security services.
[SEC-ARCH]中介绍了一些非常重要的安全注意事项。一个值得重复。创建私有会话密钥后，必须将其安全存储。如果未能正确保护私钥，使其不受系统内部和外部访问的影响，则IP安全服务提供的任何保护将完全失效。
IANA Considerations
IANA考虑
This document contains many "magic" numbers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional numbers in each of these lists.
本文件包含许多由IANA维护的“神奇”数字。本节解释IANA在每个列表中分配额外编号时使用的标准。
Domain of Interpretation
解释领域
The Domain of Interpretation (DOI) is a 32-bit field which identifies the domain under which the security association negotiation is taking place. Requests for assignments of new DOIs must be accompanied by a standards-track RFC which describes the specific domain.
解释域（DOI）是一个32位字段，用于标识正在进行安全关联协商的域。分配新内政部的请求必须附有描述特定领域的标准跟踪RFC。
Supported Security Protocols
支持的安全协议
ISAKMP is designed to provide security association negotiation and key management for many security protocols. Requests for identifiers for additional security protocols must be accompanied by a standards-track RFC which describes the security protocol and its relationship to ISAKMP.
ISAKMP旨在为许多安全协议提供安全关联协商和密钥管理。对附加安全协议标识符的请求必须附有标准跟踪RFC，该RFC描述了安全协议及其与ISAKMP的关系。
Acknowledgements
致谢
Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided design assistance with the protocol and coordination for the [IKE] and [IPDOI] documents.
思科系统公司的Dan Harkins、Dave Carrel和Derrell Piper为[IKE]和[IPDOI]文档的协议和协调提供了设计协助。
Hilarie Orman, via the Oakley key exchange protocol, has significantly influenced the design of ISAKMP.
Hilarie Orman通过Oakley密钥交换协议对ISAKMP的设计产生了重大影响。
Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor provided significant input and review to this document.
Marsha Gross、Bill Kutz、Mike Oehler、Pete Sell和Ruth Taylor为本文件提供了重要的输入和审查。
Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with the ISAKMP prototype.
Scott Carlson将TIS DNSSEC原型移植到FreeBSD，以便与ISAKMP原型一起使用。
Jeff Turner and Steve Smalley contributed to the prototype development and integration with ESP and AH.
Jeff Turner和Steve Smalley为原型开发以及与ESP和AH的集成做出了贡献。
Mike Oehler and Pete Sell performed interoperability testing with other ISAKMP implementors.
Mike Oehler和Pete Sell与其他ISAKMP实现者进行了互操作性测试。
Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with LaTeX.
感谢斯巴达公司的Carl Muckenhirn对乳胶的帮助。
References
工具书类
[ANSI] ANSI, X9.42: Public Key Cryptography for the Financial Services Industry -- Establishment of Symmetric Algorithm Keys Using Diffie-Hellman, Working Draft, April 19, 1996.
[ANSI]ANSI，X9.42：金融服务业的公钥加密——使用Diffie Hellman建立对称算法密钥，工作草案，1996年4月19日。
[BC] Ballardie, A., and J. Crowcroft, Multicast-specific Security Threats and Countermeasures, Proceedings of 1995 ISOC Symposium on Networks & Distributed Systems Security, pp. 17-30, Internet Society, San Diego, CA, February 1995.
[BC]Ballardie，A.和J.Crowcroft，《特定于多播的安全威胁和对策》，1995年ISOC网络与分布式系统安全研讨会论文集，第17-30页，互联网协会，加利福尼亚州圣地亚哥，1995年2月。
[Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875, December 1995.
[Berge]Berge，N.，“联合国PCA政策声明”，RFC 18751995年12月。
[CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial and Military Computer Security Policies, Proceedings of the IEEE Symposium on Security & Privacy, Oakland, CA, 1987, pp. 184-193.
[CW87]Clark，D.D.和D.R.Wilson，《商用和军用计算机安全政策的比较》，IEEE安全与隐私研讨会论文集，加利福尼亚州奥克兰，1987年，第184-193页。
[DNSSEC] D. Eastlake III, Domain Name System Protocol Security Extensions, Work in Progress.
[DNSSEC]D.Eastlake III，域名系统协议安全扩展，正在进行中。
[DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and Authenticated Key Exchanges, Designs, Codes, and Cryptography, 2, 107-125, Kluwer Academic Publishers, 1992.
[DOW92]Diffie，W.，M.Wiener，P.Van Oorschot，《认证和认证密钥交换、设计、代码和密码学》，2，107-125，Kluwer学术出版社，1992年。
[IAB] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[IAB]Bellovin，S.，“IAB安全架构研讨会报告”，RFC 2316，1998年4月。
[IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[IPDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[IPDOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[Karn] Karn, P., and B. Simpson, Photuris: Session Key Management Protocol, Work in Progress.
[Karn]Karn，P.和B.Simpson，Photuris：会话密钥管理协议，正在进行的工作。
[Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August 10, 1994.
[Kent94]Steve Kent，IPSEC SMIB，电子邮件至ipsec@ans.net，一九九四年八月十日。
[Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC 2412, November 1998.
[Oakley]Orman，H.，“Oakley密钥确定协议”，RFC 2412，1998年11月。
[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC-1422]Kent，S.，“因特网电子邮件的隐私增强：第二部分：基于证书的密钥管理”，RFC 1422，1993年2月。
[RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC 1949, May 1996.
[RFC-1949]Ballardie，A.“可伸缩多播密钥分发”，RFC 1949，1996年5月。
[RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC-2093]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）规范”，RFC 2093，1997年7月。
[RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC-2094]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKP）体系结构”，RFC 2094，1997年7月。
[RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[Schneier] Bruce Schneier, Applied Cryptography - Protocols, Algorithms, and Source Code in C (Second Edition), John Wiley & Sons, Inc., 1996.
[Schneier]Bruce Schneier，应用密码学-C语言中的协议、算法和源代码（第二版），John Wiley&Sons，Inc.，1996年。
[SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[SEC-ARCH]Atkinson，R.和S.Kent，“互联网协议的安全架构”，RFC 2401，1998年11月。
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
Authors' Addresses
作者地址
Douglas Maughan National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000
道格拉斯·莫恩国家安全局收件人：马里兰州米德市萨维奇路R23 9800号，邮编：20755-6000
Phone: 301-688-0847 EMail:wdm@tycho.ncsc.mil
电话：301-688-0847电子邮件：wdm@tycho.ncsc.mil
Mark Schneider National Security Agency ATTN: R23 9800 Savage Road Ft. Meade, MD. 20755-6000
马克·施耐德国家安全局收件人：马里兰州米德市萨维奇路R23 9800号，邮编：20755-6000
Phone: 301-688-0851 EMail:mss@tycho.ncsc.mil
电话：301-688-0851电子邮件：mss@tycho.ncsc.mil
Mark Schertler Securify, Inc. 2415-B Charleston Road Mountain View, CA 94043
Mark Schertler Securify，Inc.加利福尼亚州查尔斯顿路山景城2415-B号，邮编94043
Phone: 650-934-9303 EMail:mjs@securify.com
电话：650-934-9303电子邮件：mjs@securify.com
Jeff Turner RABA Technologies, Inc. 10500 Little Patuxent Parkway Columbia, MD. 21044
Jeff Turner RABA Technologies，Inc.位于马里兰州哥伦比亚小帕塔克森特大道10500号，邮编：21044
Phone: 410-715-9399 EMail:jeff.turner@raba.com
电话：410-715-9399电子邮件：杰夫。turner@raba.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。