Network Working Group D. McDonald
Request for Comments: 2367 C. Metz
Category: Informational B. Phan
July 1998
Network Working Group D. McDonald
Request for Comments: 2367 C. Metz
Category: Informational B. Phan
July 1998
PF_KEY Key Management API, Version 2
PF_密钥管理API，第2版
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
A generic key management API that can be used not only for IP Security [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of this API was implemented inside 4.4-Lite BSD as part of the U. S. Naval Research Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], a Photuris daemon, or a SKIP certificate discovery protocol daemon).
本文介绍了一种通用密钥管理API，它不仅可用于IP安全[Atk95a][Atk95b][Atk95c]，还可用于其他网络安全服务。此API的第1版是在4.4-Lite BSD中实现的，作为美国海军研究实验室可自由分发和可用的IPv6和IPsec实现[AMPMC96]的一部分。此处对其进行记录是为了方便其他可能也采用和使用API的人，从而提高密钥管理应用程序的可移植性（例如，手动密钥设置应用程序、ISAKMP守护程序、GKP守护程序[HM97a][HM97b]、Photuris守护程序或跳过证书发现协议守护程序）。
Table of Contents
目录
1 Introduction ............................................. 3
1.1 Terminology .............................................. 3
1.2 Conceptual Model ......................................... 4
1.3 PF_KEY Socket Definition ................................. 8
1.4 Overview of PF_KEY Messaging Behavior .................... 8
1.5 Common PF_KEY Operations ................................. 9
1.6 Differences Between PF_KEY and PF_ROUTE .................. 10
1.7 Name Space ............................................... 11
1.8 On Manual Keying ..........................................11
2 PF_KEY Message Format .................................... 11
2.1 Base Message Header Format ............................... 12
2.2 Alignment of Headers and Extension Headers ............... 14
2.3 Additional Message Fields ................................ 14
2.3.1 Association Extension .................................... 15
2.3.2 Lifetime Extension ....................................... 16
1 Introduction ............................................. 3
1.1 Terminology .............................................. 3
1.2 Conceptual Model ......................................... 4
1.3 PF_KEY Socket Definition ................................. 8
1.4 Overview of PF_KEY Messaging Behavior .................... 8
1.5 Common PF_KEY Operations ................................. 9
1.6 Differences Between PF_KEY and PF_ROUTE .................. 10
1.7 Name Space ............................................... 11
1.8 On Manual Keying ..........................................11
2 PF_KEY Message Format .................................... 11
2.1 Base Message Header Format ............................... 12
2.2 Alignment of Headers and Extension Headers ............... 14
2.3 Additional Message Fields ................................ 14
2.3.1 Association Extension .................................... 15
2.3.2 Lifetime Extension ....................................... 16
2.3.3 Address Extension ........................................ 18
2.3.4 Key Extension ............................................ 19
2.3.5 Identity Extension ....................................... 21
2.3.6 Sensitivity Extension .................................... 21
2.3.7 Proposal Extension ....................................... 22
2.3.8 Supported Algorithms Extension ........................... 25
2.3.9 SPI Range Extension ...................................... 26
2.4 Illustration of Message Layout ........................... 27
3 Symbolic Names ........................................... 30
3.1 Message Types ............................................ 31
3.1.1 SADB_GETSPI .............................................. 32
3.1.2 SADB_UPDATE .............................................. 33
3.1.3 SADB_ADD ................................................. 34
3.1.4 SADB_DELETE .............................................. 35
3.1.5 SADB_GET ................................................. 36
3.1.6 SADB_ACQUIRE ............................................. 36
3.1.7 SADB_REGISTER ............................................ 38
3.1.8 SADB_EXPIRE .............................................. 39
3.1.9 SADB_FLUSH ............................................... 40
3.1.10 SADB_DUMP ................................................ 40
3.2 Security Association Flags ............................... 41
3.3 Security Association States .............................. 41
3.4 Security Association Types ............................... 41
3.5 Algorithm Types .......................................... 42
3.6 Extension Header Values .................................. 43
3.7 Identity Extension Values ................................ 44
3.8 Sensitivity Extension Values ............................. 45
3.9 Proposal Extension Values ................................ 45
4 Future Directions ........................................ 45
5 Examples ................................................. 45
5.1 Simple IP Security Example ............................... 46
5.2 Proxy IP Security Example ................................ 47
5.3 OSPF Security Example .................................... 50
5.4 Miscellaneous ............................................ 50
6 Security Considerations .................................. 51
Acknowledgments ............,............................. 52
References ............................................... 52
Disclaimer ............................................... 54
Authors' Addresses ....................................... 54
A Promiscuous Send/Receive Extension ....................... 55
B Passive Change Message Extension ......................... 57
C Key Management Private Data Extension .................... 58
D Sample Header File ....................................... 59
E Change Log ............................................... 64
F Full Copyright Statement ................................. 68
2.3.3 Address Extension ........................................ 18
2.3.4 Key Extension ............................................ 19
2.3.5 Identity Extension ....................................... 21
2.3.6 Sensitivity Extension .................................... 21
2.3.7 Proposal Extension ....................................... 22
2.3.8 Supported Algorithms Extension ........................... 25
2.3.9 SPI Range Extension ...................................... 26
2.4 Illustration of Message Layout ........................... 27
3 Symbolic Names ........................................... 30
3.1 Message Types ............................................ 31
3.1.1 SADB_GETSPI .............................................. 32
3.1.2 SADB_UPDATE .............................................. 33
3.1.3 SADB_ADD ................................................. 34
3.1.4 SADB_DELETE .............................................. 35
3.1.5 SADB_GET ................................................. 36
3.1.6 SADB_ACQUIRE ............................................. 36
3.1.7 SADB_REGISTER ............................................ 38
3.1.8 SADB_EXPIRE .............................................. 39
3.1.9 SADB_FLUSH ............................................... 40
3.1.10 SADB_DUMP ................................................ 40
3.2 Security Association Flags ............................... 41
3.3 Security Association States .............................. 41
3.4 Security Association Types ............................... 41
3.5 Algorithm Types .......................................... 42
3.6 Extension Header Values .................................. 43
3.7 Identity Extension Values ................................ 44
3.8 Sensitivity Extension Values ............................. 45
3.9 Proposal Extension Values ................................ 45
4 Future Directions ........................................ 45
5 Examples ................................................. 45
5.1 Simple IP Security Example ............................... 46
5.2 Proxy IP Security Example ................................ 47
5.3 OSPF Security Example .................................... 50
5.4 Miscellaneous ............................................ 50
6 Security Considerations .................................. 51
Acknowledgments ............,............................. 52
References ............................................... 52
Disclaimer ............................................... 54
Authors' Addresses ....................................... 54
A Promiscuous Send/Receive Extension ....................... 55
B Passive Change Message Extension ......................... 57
C Key Management Private Data Extension .................... 58
D Sample Header File ....................................... 59
E Change Log ............................................... 64
F Full Copyright Statement ................................. 68
1 Introduction
1导言
PF_KEY is a new socket protocol family used by trusted privileged key management applications to communicate with an operating system's key management internals (referred to here as the "Key Engine" or the Security Association Database (SADB)). The Key Engine and its structures incorporate the required security attributes for a session and are instances of the "Security Association" (SA) concept described in [Atk95a]. The names PF_KEY and Key Engine thus refer to more than cryptographic keys and are retained for consistency with the traditional phrase, "Key Management".
PF_密钥是一个新的套接字协议系列，受信任的特权密钥管理应用程序使用它与操作系统的密钥管理内部（这里称为“密钥引擎”或安全关联数据库（SADB））通信。密钥引擎及其结构包含会话所需的安全属性，是[Atk95a]中描述的“安全关联”（SA）概念的实例。因此，PF_密钥和密钥引擎的名称所指的不仅仅是加密密钥，为了与传统短语“密钥管理”保持一致而保留。
PF_KEY is derived in part from the BSD routing socket, PF_ROUTE. [Skl91] This document describes Version 2 of PF_KEY. Version 1 was implemented in the first five alpha test versions of the NRL IPv6+IPsec Software Distribution for 4.4-Lite BSD UNIX and the Cisco ISAKMP/Oakley key management daemon. Version 2 extends and refines this interface. Theoretically, the messages defined in this document could be used in a non-socket context (e.g. between two directly communicating user-level processes), but this document will not discuss in detail such possibilities.
PF_密钥部分来自BSD路由套接字PF_ROUTE。[Skl91]本文件描述了PF_密钥的第2版。版本1是在4.4-Lite BSD UNIX和Cisco ISAKMP/Oakley密钥管理守护程序的NRL IPv6+IPsec软件发行版的前五个alpha测试版本中实现的。版本2扩展并细化了此接口。理论上，本文档中定义的消息可以在非套接字上下文中使用（例如，在两个直接通信的用户级进程之间），但本文档不会详细讨论这种可能性。
Security policy is deliberately omitted from this interface. PF_KEY is not a mechanism for tuning systemwide security policy, nor is it intended to enforce any sort of key management policy. The developers of PF_KEY believe that it is important to separate security mechanisms (such as PF_KEY) from security policies. This permits a single mechanism to more easily support multiple policies.
此接口中故意省略了安全策略。PF_密钥不是用于调整系统范围安全策略的机制，也不是用于强制执行任何类型的密钥管理策略。PF_密钥的开发人员认为，将安全机制（如PF_密钥）与安全策略分离是很重要的。这允许单个机制更容易地支持多个策略。
Even though this document is not intended to be an actual Internet standard, the words that are used to define the significance of particular features of this interface are usually capitalized. Some of these words, including MUST, MAY, and SHOULD, are detailed in [Bra97].
尽管本文件不打算成为实际的互联网标准，但用于定义此接口特定功能重要性的词语通常大写。[Bra97]详细介绍了其中的一些词语，包括必须、可能和应该。
- CONFORMANCE and COMPLIANCE
- 合规性和合规性
Conformance to this specification has the same meaning as compliance to this specification. In either case, the mandatory-to-implement, or MUST, items MUST be fully implemented as specified here. If any mandatory item is not implemented as specified here, that implementation is not conforming and not compliant with this specification.
符合本规范的含义与符合本规范的含义相同。在任何一种情况下，必须执行或必须执行的项目必须按照此处的规定完全执行。如果任何强制性项目未按此处规定实施，则该实施不符合本规范。
This specification also uses many terms that are commonly used in the context of network security. Other documents provide more definitions and background information on these [VK83, HA94, Atk95a]. Two terms deserve special mention:
本规范还使用了网络安全上下文中常用的许多术语。其他文件提供了更多的定义和背景信息[VK83、HA94、Atk95a]。有两个术语值得特别提及：
- (Encryption/Authentication) Algorithm
- （加密/认证）算法
For PF_KEY purposes, an algorithm, whether encryption or authentication, is the set of operations performed on a packet to complete authentication or encryption as indicated by the SA type. A PF_KEY algorithm MAY consist of more than one cryptographic algorithm. Another possibility is that the same basic cryptographic algorithm may be applied with different modes of operation or some other implementation difference. These differences, henceforth called _algorithm differentiators_, distinguish between different PF_KEY algorithms, and options to the same algorithm. Algorithm differentiators will often cause fundamentally different security properties.
出于PF_密钥的目的，算法（无论是加密还是身份验证）是对数据包执行的一组操作，以完成SA类型指示的身份验证或加密。PF_密钥算法可以由多个加密算法组成。另一种可能性是，相同的基本密码算法可应用于不同的操作模式或某些其他实现差异。这些差异，今后称为_算法微分器u，用于区分不同的PF _关键算法和同一算法的选项。算法差异通常会导致根本不同的安全属性。
For example, both DES and 3DES use the same cryptographic algorithm, but they are used differently and have different security properties. The triple-application of DES is considered an algorithm differentiator. There are therefore separate PF_KEY algorithms for DES and 3DES. Keyed-MD5 and HMAC-MD5 use the same hash function, but construct their message authentication codes differently. The use of HMAC is an algorithm differentiator. DES-ECB and DES-CBC are the same cryptographic algorithm, but use a different mode. Mode (e.g., chaining vs. code-book) is an algorithm differentiator. Blowfish with a 128-bit key, however, is similar to Blowfish with a 384-bit key, because the algorithm's workings are otherwise the same and therefore the key length is not an algorithm differentiator.
例如，DES和3DES都使用相同的加密算法，但它们的使用方式不同，并且具有不同的安全属性。DES的三重应用被认为是一种算法微分器。因此，DES和3DES有单独的PF_密钥算法。Keyed-MD5和HMAC-MD5使用相同的哈希函数，但构造它们的消息身份验证代码的方式不同。HMAC的使用是一种算法微分器。DES-ECB和DES-CBC是相同的加密算法，但使用不同的模式。模式（例如，链接与代码簿）是一种算法差异。但是，具有128位密钥的Blowfish与具有384位密钥的Blowfish类似，因为该算法的工作原理在其他方面是相同的，因此密钥长度不是算法的区分因素。
In terms of IP Security, a general rule of thumb is that whatever might be labeled the "encryption" part of an ESP transform is probably a PF_KEY encryption algorithm. Whatever might be labelled the "authentication" part of an AH or ESP transform is probably a PF_KEY authentication algorithm.
就IP安全而言，一般的经验法则是，ESP转换中可能被标记为“加密”的部分可能是PF_密钥加密算法。AH或ESP转换的“身份验证”部分可能是PF_密钥身份验证算法。
This section describes the conceptual model of an operating system that implements the PF_KEY key management application programming interface. This section is intended to provide background material useful to understand the rest of this document. Presentation of this conceptual model does not constrain a PF_KEY implementation to strictly adhere to the conceptual components discussed in this subsection.
本节描述实现PF_密钥管理应用程序编程接口的操作系统的概念模型。本节旨在提供有助于理解本文件其余部分的背景资料。此概念模型的表示并不限制PF_关键实现严格遵守本小节中讨论的概念组件。
Key management is most commonly implemented in whole or in part at the application layer. For example, the ISAKMP/Oakley, GKMP, and Photuris proposals for IPsec key management are all application-layer protocols. Manual keying is also done at the application layer. Even parts of the SKIP IP-layer keying proposal can be implemented at the application layer. Figure 1 shows the relationship between a Key Management daemon and PF_KEY. Key management daemons use PF_KEY to communicate with the Key Engine and use PF_INET (or PF_INET6 in the case of IPv6) to communicate, via the network, with a remote key management entity.
密钥管理通常在应用层全部或部分实现。例如，ISAKMP/Oakley、GKMP和Photuris建议的IPsec密钥管理都是应用层协议。手动键控也在应用层完成。甚至跳过IP层密钥方案的一部分也可以在应用层实现。图1显示了密钥管理守护程序和PF_密钥之间的关系。密钥管理守护进程使用PF_Key与密钥引擎通信，并使用PF_INET（或在IPv6情况下使用PF_INET6）通过网络与远程密钥管理实体通信。
The "Key Engine" or "Security Association Database (SADB)" is a logical entity in the kernel that stores, updates, and deletes Security Association data for various security protocols. There are logical interfaces within the kernel (e.g. getassocbyspi(), getassocbysocket()) that security protocols inside the kernel (e.g. IP Security, aka IPsec) use to request and obtain Security Associations.
“密钥引擎”或“安全关联数据库（SADB）”是内核中的逻辑实体，用于存储、更新和删除各种安全协议的安全关联数据。内核中有逻辑接口（例如getassocbyspi（）、getassocbysocket（）），内核中的安全协议（例如IP安全，又称IPsec）使用这些接口来请求和获取安全关联。
In the case of IPsec, if by policy a particular outbound packet needs processing, then the IPsec implementation requests an appropriate Security Association from the Key Engine via the kernel-internal interface. If the Key Engine has an appropriate SA, it allocates the SA to this session (marking it as used) and returns the SA to the IPsec implementation for use. If the Key Engine has no such SA but a key management application has previously indicated (via a PF_KEY SADB_REGISTER message) that it can obtain such SAs, then the Key Engine requests that such an SA be created (via a PF_KEY SADB_ACQUIRE message). When the key management daemon creates a new SA, it places it into the Key Engine for future use.
在IPsec的情况下，如果根据策略特定出站数据包需要处理，则IPsec实现通过内核内部接口从密钥引擎请求适当的安全关联。如果密钥引擎具有适当的SA，它会将SA分配给该会话（将其标记为已使用），并将SA返回给IPsec实现以供使用。如果密钥引擎没有这样的SA，但密钥管理应用程序先前（通过PF_密钥SADB_寄存器消息）指示它可以获得这样的SA，则密钥引擎请求创建这样的SA（通过PF_密钥SADB_获取消息）。当密钥管理守护进程创建一个新的SA时，它会将其放入密钥引擎以备将来使用。
+---------------+
|Key Mgmt Daemon|
+---------------+
| |
| |
| | Applications
======[PF_KEY]====[PF_INET]==========================
| | OS Kernel
+------------+ +-----------------+
| Key Engine | | TCP/IP, |
| or SADB |---| including IPsec |
+------------+ | |
+-----------------+
|
+-----------+
| Network |
| Interface |
+-----------+
+---------------+
|Key Mgmt Daemon|
+---------------+
| |
| |
| | Applications
======[PF_KEY]====[PF_INET]==========================
| | OS Kernel
+------------+ +-----------------+
| Key Engine | | TCP/IP, |
| or SADB |---| including IPsec |
+------------+ | |
+-----------------+
|
+-----------+
| Network |
| Interface |
+-----------+
Figure 1: Relationship of Key Mgmt to PF_KEY
图1：密钥管理与PF_密钥的关系
For performance reasons, some security protocols (e.g. IP Security) are usually implemented inside the operating system kernel. Other security protocols (e.g. OSPFv2 Cryptographic Authentication) are implemented in trusted privileged applications outside the kernel. Figure 2 shows a trusted, privileged routing daemon using PF_INET to communicate routing information with a remote routing daemon and using PF_KEY to request, obtain, and delete Security Associations used with a routing protocol.
出于性能原因，一些安全协议（如IP安全）通常在操作系统内核内实现。其他安全协议（如OSPFv2加密身份验证）在内核之外的受信任特权应用程序中实现。图2显示了一个受信任的特权路由守护进程，它使用PF_INET与远程路由守护进程通信路由信息，并使用PF_密钥请求、获取和删除路由协议使用的安全关联。
+---------------+
|Routing Daemon|
+---------------+
| |
| |
| | Applications
======[PF_KEY]====[PF_INET]==========================
| | OS Kernel
+------------+ +---------+
| Key Engine | | TCP/IP |
| or SADB |---| |
+------------+ +---------+
|
+-----------+
| Network |
| Interface |
+-----------+
+---------------+
|Routing Daemon|
+---------------+
| |
| |
| | Applications
======[PF_KEY]====[PF_INET]==========================
| | OS Kernel
+------------+ +---------+
| Key Engine | | TCP/IP |
| or SADB |---| |
+------------+ +---------+
|
+-----------+
| Network |
| Interface |
+-----------+
Figure 2: Relationship of Trusted Application to PF_KEY
图2：可信应用程序与PF_密钥的关系
When a trusted privileged application is using the Key Engine but implements the security protocol within itself, then operation varies slightly. In this case, the application needing an SA sends a PF_KEY SADB_ACQUIRE message down to the Key Engine, which then either returns an error or sends a similar SADB_ACQUIRE message up to one or more key management applications capable of creating such SAs. As before, the key management daemon stores the SA into the Key Engine. Then, the trusted privileged application uses an SADB_GET message to obtain the SA from the Key Engine.
当受信任的特权应用程序正在使用密钥引擎，但在其内部实现了安全协议时，操作会略有不同。在这种情况下，需要SA的应用程序向密钥引擎发送PF_KEY SADB_ACQUIRE消息，然后密钥引擎返回错误或向能够创建此类SA的一个或多个密钥管理应用程序发送类似的SADB_ACQUIRE消息。与前面一样，密钥管理守护进程将SA存储到密钥引擎中。然后，受信任的特权应用程序使用SADB_GET消息从密钥引擎获取SA。
In some implementations, policy may be implemented in user-space, even though the actual cryptographic processing takes place in the kernel. Such policy communication between the kernel mechanisms and the user-space policy MAY be implemented by PF_KEY extensions, or other such mechanism. This document does not specify such extensions. A PF_KEY implementation specified by the memo does NOT have to support configuring systemwide policy using PF_KEY.
在某些实现中，策略可以在用户空间中实现，即使实际的加密处理发生在内核中。内核机制和用户空间策略之间的这种策略通信可以通过pfu密钥扩展或其他这样的机制来实现。本文档未指定此类扩展。备忘录指定的PF_密钥实现不必支持使用PF_密钥配置系统范围策略。
Untrusted clients, for example a user's web browser or telnet client, do not need to use PF_KEY. Mechanisms not specified here are used by such untrusted client applications to request security services (e.g. IPsec) from an operating system. For security reasons, only trusted, privileged applications are permitted to open a PF_KEY socket.
不受信任的客户端，例如用户的web浏览器或telnet客户端，不需要使用PF_密钥。此处未指定的机制由此类不受信任的客户端应用程序用于从操作系统请求安全服务（如IPsec）。出于安全原因，仅允许受信任的特权应用程序打开PF_密钥套接字。
The PF_KEY protocol family (PF_KEY) symbol is defined in <sys/socket.h> in the same manner that other protocol families are defined. PF_KEY does not use any socket addresses. Applications using PF_KEY MUST NOT depend on the availability of a symbol named AF_KEY, but kernel implementations are encouraged to define that symbol for completeness.
PF_密钥协议族（PF_密钥）符号在<sys/socket.h>中的定义方式与其他协议族的定义方式相同。PF_键不使用任何套接字地址。使用PF_键的应用程序不能依赖于名为AF_键的符号的可用性，但为了完整性，鼓励内核实现定义该符号。
The key management socket is created as follows:
密钥管理套接字的创建如下所示：
#include <sys/types.h>
#include <sys/socket.h>
#include <net/pfkeyv2.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <net/pfkeyv2.h>
int s;
s = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
int s;
s = socket(PF_KEY, SOCK_RAW, PF_KEY_V2);
The PF_KEY domain currently supports only the SOCK_RAW socket type. The protocol field MUST be set to PF_KEY_V2, or else EPROTONOSUPPORT will be returned. Only a trusted, privileged process can create a PF_KEY socket. On conventional UNIX systems, a privileged process is a process with an effective userid of zero. On non-MLS proprietary operating systems, the notion of a "privileged process" is implementation-defined. On Compartmented Mode Workstations (CMWs) or other systems that claim to provide Multi-Level Security (MLS), a process MUST have the "key management privilege" in order to open a PF_KEY socket[DIA]. MLS systems that don't currently have such a specific privilege MUST add that special privilege and enforce it with PF_KEY in order to comply and conform with this specification. Some systems, most notably some popular personal computers, do not have the concept of an unprivileged user. These systems SHOULD take steps to restrict the programs allowed to access the PF_KEY API.
PF_密钥域当前仅支持SOCK_原始套接字类型。协议字段必须设置为PF_KEY_V2，否则将返回EPROTONOSUPPORT。只有受信任的特权进程才能创建PF_密钥套接字。在传统的UNIX系统上，特权进程是有效用户ID为零的进程。在非MLS专有操作系统上，“特权进程”的概念是实现定义的。在分区模式工作站（CMW）或声称提供多级安全（MLS）的其他系统上，进程必须具有“密钥管理权限”，才能打开PF_密钥套接字[DIA]。当前没有此类特定特权的MLS系统必须添加该特权，并使用PF_密钥强制执行该特权，以符合本规范。一些系统，尤其是一些流行的个人计算机，没有非特权用户的概念。这些系统应采取措施限制允许访问PF_密钥API的程序。
A process interacts with the key engine by sending and receiving messages using the PF_KEY socket. Security association information can be inserted into and retrieved from the kernel's security association table using a set of predefined messages. In the normal case, all properly-formed messages sent to the kernel are returned to all open PF_KEY sockets, including the sender. Improperly formed messages will result in errors, and an implementation MUST check for a properly formed message before returning it to the appropriate listeners. Unlike the routing socket, most errors are sent in reply messages, not the errno field when write() or send() fails. PF_KEY message delivery is not guaranteed, especially in cases where kernel or socket buffers are exhausted and messages are dropped.
进程通过使用PF_密钥套接字发送和接收消息来与密钥引擎交互。可以使用一组预定义的消息将安全关联信息插入到内核的安全关联表中并从中检索。在正常情况下，发送到内核的所有格式正确的消息都会返回到所有打开的PF_密钥套接字，包括发送方。格式不正确的消息将导致错误，实现必须在将消息返回到适当的侦听器之前检查格式是否正确。与路由套接字不同，当write（）或send（）失败时，大多数错误是在回复消息中发送的，而不是errno字段。PF_密钥消息传递不受保证，尤其是在内核或套接字缓冲区耗尽且消息被丢弃的情况下。
Some messages are generated by the operating system to indicate that actions need to be taken, and are not necessarily in response to any message sent down by the user. Such messages are not received by all PF_KEY sockets, but by sockets which have indicated that kernel-originated messages are to be received. These messages are special because of the expected frequency at which they will occur. Also, an implementation may further wish to restrict return messages from the kernel, in cases where not all PF_KEY sockets are in the same trust domain.
一些消息是由操作系统生成的，用于指示需要采取的操作，并且不一定响应用户发送的任何消息。这些消息不是由所有PF_密钥套接字接收的，而是由指示要接收源自内核的消息的套接字接收的。这些消息是特殊的，因为它们将以预期的频率出现。此外，在并非所有PF_密钥套接字都位于同一信任域的情况下，实现可能还希望限制来自内核的返回消息。
Many of the normal BSD socket calls have undefined behavior on PF_KEY sockets. These include: bind(), connect(), socketpair(), accept(), getpeername(), getsockname(), ioctl(), and listen().
许多正常的BSD套接字调用在PF_密钥套接字上具有未定义的行为。其中包括：bind（）、connect（）、socketpair（）、accept（）、getpeername（）、getsockname（）、ioctl（）和listen（）。
There are two basic ways to add a new Security Association into the kernel. The simplest is to send a single SADB_ADD message, containing all of the SA information, from the application into the kernel's Key Engine. This approach works particularly well with manual key management, which is required for IPsec, and other security protocols.
有两种基本方法可以将新的安全关联添加到内核中。最简单的方法是从应用程序向内核的密钥引擎发送一条包含所有SA信息的SADB_ADD消息。这种方法尤其适用于IPsec和其他安全协议所需的手动密钥管理。
The second approach to add a new Security Association into the kernel is for the application to first request a Security Parameters Index (SPI) value from the kernel using the SADB_GETSPI message and then send an SADB_UPDATE message with the complete Security Association data. This second approach works well with key management daemons when the SPI values need to be known before the entire Security Association data is known (e.g. so the SPI value can be indicated to the remote end of the key management session).
向内核添加新安全关联的第二种方法是，应用程序首先使用SADB_GETSPI消息从内核请求安全参数索引（SPI）值，然后发送包含完整安全关联数据的SADB_更新消息。当在知道整个安全关联数据之前需要知道SPI值（例如，这样SPI值可以指示给密钥管理会话的远程端）时，第二种方法适用于密钥管理守护进程。
An individual Security Association can be deleted using the SADB_DELETE message. Categories of SAs or the entire kernel SA table can be deleted using the SADB_FLUSH message.
可以使用SADB_DELETE消息删除单个安全关联。可以使用SADB_FLUSH消息删除SA类别或整个内核SA表。
The SADB_GET message is used by a trusted application-layer process (e.g. routed(8) or gated(8)) to retrieve an SA (e.g. RIP SA or OSPF SA) from the kernel's Key Engine.
受信任的应用层进程（例如路由（8）或选通（8））使用SADB_GET消息从内核的密钥引擎检索SA（例如RIP SA或OSPF SA）。
The kernel or an application-layer can use the SADB_ACQUIRE message to request that a Security Association be created by some application-layer key management process that has registered with the kernel via an SADB_REGISTER message. This ACQUIRE message will have a sequence number associated with it. This sequence number MUST be used by followup SADB_GETSPI, SADB_UPDATE, and SADB_ADD messages, in order to keep track of which request gets its keying material. The sequence number (described below) is similar to a transaction ID in a
内核或应用层可以使用SADB_ACQUIRE消息来请求由某个应用层密钥管理进程创建安全关联，该进程已通过SADB_REGISTER消息向内核注册。此获取消息将有一个与其关联的序列号。后续SADB_GETSPI、SADB_UPDATE和SADB_ADD消息必须使用此序列号，以便跟踪哪个请求获得其键控材料。序列号（如下所述）类似于数据库中的事务ID
remote procedure call.
远程过程调用。
The SADB_EXPIRE message is sent from the kernel to key management applications when the "soft lifetime" or "hard lifetime" of a Security Association has expired. Key management applications should use receipt of a soft lifetime SADB_EXPIRE message as a hint to negotiate a replacement SA so the replacement SA will be ready and in the kernel before it is needed.
当安全关联的“软生命周期”或“硬生命周期”过期时，SADB_EXPIRE消息从内核发送到密钥管理应用程序。密钥管理应用程序应该使用软生命周期SADB_EXPIRE消息的接收作为协商替换SA的提示，以便在需要替换SA之前将其准备好并放入内核中。
A SADB_DUMP message is also defined, but this is primarily intended for PF_KEY implementor debugging and is not used in ordinary operation of PF_KEY.
还定义了SADB_转储消息，但这主要用于PF_密钥实现程序调试，不用于PF_密钥的普通操作。
The following bullets are points of difference between the routing socket and PF_KEY. Programmers who are used to the routing socket semantics will find some differences in PF_KEY.
以下项目符号是路由套接字和PF_键之间的差异点。习惯于路由套接字语义的程序员会发现PF_键存在一些差异。
* PF_KEY message errors are usually returned in PF_KEY messages instead of causing write() operations to fail and returning the error number in errno. This means that other listeners on a PF_KEY socket can be aware that requests from another process failed, which can be useful for auditing purposes. This also means that applications that fail to read PF_KEY messages cannot do error checking.
* PF_KEY message错误通常在PF_KEY messages中返回，而不是导致write（）操作失败并在errno中返回错误号。这意味着PF_密钥套接字上的其他侦听器可以知道来自另一个进程的请求失败，这对于审计目的很有用。这也意味着无法读取PF_密钥消息的应用程序无法执行错误检查。
An implementation MAY return the errors EINVAL, ENOMEM, and ENOBUFS by causing write() operations to fail and returning the error number in errno. This is an optimization for common error cases in which it does not make sense for any other process to receive the error. An application MUST NOT depend on such errors being set by the write() call, but it SHOULD check for such errors, and handle them in an appropriate manner.
通过导致write（）操作失败并在errno中返回错误号，实现可能会返回错误EINVAL、ENOMEM和ENOBUFS。这是对常见错误情况的优化，在这种情况下，任何其他进程接收错误都没有意义。应用程序不能依赖于write（）调用设置的此类错误，但它应该检查此类错误，并以适当的方式处理它们。
* The entire message isn't always reflected in the reply. A SADB_ADD message is an example of this.
* 整个信息并不总是反映在回复中。SADB_添加消息就是一个例子。
* The PID is not set by the kernel. The process that originates the message MUST set the sadb_msg_pid to its own PID. If the kernel ORIGINATES a message, it MUST set the sadb_msg_pid to 0. A reply to an original message SHOULD have the pid of the original message. (E.g. the kernel's response to an SADB_ADD SHOULD have its pid set to the pid value of the original SADB_ADD message.)
* PID不是由内核设置的。发起消息的进程必须将sadb_msg_pid设置为自己的pid。如果内核生成消息，它必须将sadb_msg_pid设置为0。对原始邮件的回复应具有原始邮件的pid。（例如，内核对SADB_添加的响应应将其pid设置为原始SADB_添加消息的pid值。）
All PF_KEYv2 preprocessor symbols and structure definitions are defined as a result of including the header file <net/pfkeyv2.h>. There is exactly one exception to this rule: the symbol "PF_KEY" (two exceptions if "AF_KEY" is also counted), which is defined as a result of including the header file <sys/socket.h>. All PF_KEYv2 preprocessor symbols start with the prefix "SADB_" and all structure names start with "sadb_". There are exactly two exceptions to this rule: the symbol "PF_KEY_V2" and the symbol "PFKEYV2_REVISION".
所有PF_KEYv2预处理器符号和结构定义都是通过包含头文件<net/pfkeyv2.h>定义的。此规则只有一个例外：符号“PF_KEY”（如果“AF_KEY”也被计算在内，则有两个例外），这是由于包含头文件<sys/socket.h>而定义的。所有PF_KEYv2预处理器符号均以前缀“SADB_”开头，所有结构名称均以“SADB_”开头。这条规则有两个例外：符号“PF_KEY_V2”和符号“PFKEYV2_REVISION”。
The symbol "PFKEYV2_REVISION" is a date-encoded value not unlike certain values defined by POSIX and X/Open. The current value for PFKEYV2_REVISION is 199806L, where 1998 is the year and 06 is the month.
符号“PFKEYV2_修订版”是一个日期编码值，与POSIX和X/Open定义的某些值不同。PFKEYV2_修订版的当前值为199806L，其中1998为年份，06为月份。
Inclusion of the file <net/pfkeyv2.h> MUST NOT define symbols or structures in the PF_KEYv2 name space that are not described in this document without the explicit prior permission of the authors. Any symbols or structures in the PF_KEYv2 name space that are not described in this document MUST start with "SADB_X_" or "sadb_x_". An implementation that fails to obey these rules IS NOT COMPLIANT WITH THIS SPECIFICATION and MUST NOT make any claim to be. These rules also apply to any files that might be included as a result of including the file <net/pfkeyv2.h>. This rule provides implementors with some assurance that they will not encounter namespace-related surprises.
未经作者事先明确许可，包含文件<net/pfkeyv2.h>不得在PF_KEYv2名称空间中定义本文件中未描述的符号或结构。本文档中未描述的PF_KEYv2名称空间中的任何符号或结构必须以“SADB_X_uu”或“SADB_X_uu”开头。未能遵守这些规则的实现不符合本规范，不得声称符合本规范。这些规则也适用于由于包含文件<net/pfkeyv2.h>而可能包含的任何文件。此规则为实现者提供了一些保证，确保他们不会遇到与命名空间相关的意外情况。
Not unlike the 4.4-Lite BSD PF_ROUTE socket, this interface allows an application full-reign over the security associations in a kernel that implements PF_KEY. A PF_KEY implementation MUST have some sort of manual interface to PF_KEY, which SHOULD allow all of the functionality of the programmatic interface described here.
与4.4-Lite BSD PF_路由套接字不同，此接口允许应用程序完全控制实现PF_密钥的内核中的安全关联。PF_键实现必须具有某种指向PF_键的手动接口，该接口应允许此处描述的编程接口的所有功能。
PF_KEY messages consist of a base header followed by additional data fields, some of which may be optional. The format of the additional data is dependent on the type of message.
PF_键消息由一个基本标头和附加数据字段组成，其中一些字段可能是可选的。附加数据的格式取决于消息的类型。
PF_KEY messages currently do not mandate any specific ordering for non-network multi-octet fields. Unless otherwise specified (e.g. SPI values), fields MUST be in host-specific byte order.
PF_密钥消息目前不要求对非网络多八位组字段进行任何特定排序。除非另有规定（例如SPI值），否则字段必须按主机特定的字节顺序排列。
PF_KEY messages consist of the base message header followed by security association specific data whose types and lengths are specified by a generic type-length encoding.
PF_密钥消息由基本消息头和特定于安全关联的数据组成，这些数据的类型和长度由通用类型长度编码指定。
This base header is shown below, using POSIX types. The fields are arranged primarily for alignment, and where possible, for reasons of clarity.
下面使用POSIX类型显示了此基本标头。字段的排列主要是为了对齐，并且在可能的情况下，为了清晰起见。
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_msg_satype;
uint16_t sadb_msg_len;
uint16_t sadb_msg_reserved;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
};
/* sizeof(struct sadb_msg) == 16 */
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_msg_satype;
uint16_t sadb_msg_len;
uint16_t sadb_msg_reserved;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
};
/* sizeof(struct sadb_msg) == 16 */
sadb_msg_version The version field of this PF_KEY message. This MUST be set to PF_KEY_V2. If this is not set to PF_KEY_V2, the write() call MAY fail and return EINVAL. Otherwise, the behavior is undetermined, given that the application might not understand the formatting of the messages arriving from the kernel.
sadb_msg_version此PF_密钥消息的版本字段。这必须设置为PF_KEY_V2。如果未将其设置为PF_KEY_V2，则write（）调用可能会失败并返回EINVAL。否则，由于应用程序可能不理解来自内核的消息的格式，因此行为是不确定的。
sadb_msg_type Identifies the type of message. The valid message types are described later in this document.
sadb_msg_type标识消息的类型。本文档后面将介绍有效的消息类型。
sadb_msg_errno Should be set to zero by the sender. The responder stores the error code in this field if an error has occurred. This includes the case where the responder is in user space. (e.g. user-space negotiation fails, an errno can be returned.)
发送方应将sadb_msg_errno设置为零。如果发生错误，响应程序将在该字段中存储错误代码。这包括响应者在用户空间中的情况。（例如，用户空间协商失败，可以返回错误号。）
sadb_msg_satype Indicates the type of security association(s). Valid Security Association types are declared in the file <net/pfkeyv2.h>. The current set of Security Association types is enumerated later in this document.
sadb_msg_satype表示安全关联的类型。文件<net/pfkeyv2.h>中声明了有效的安全关联类型。本文档后面将枚举当前的一组安全关联类型。
sadb_msg_len Contains the total length, in 64-bit words, of all data in the PF_KEY message including the base header length and additional data after the base header, if any. This length includes any padding or extra space that might exist. Unless otherwise stated, all other length fields are also measured in 64-bit words.
sadb_msg_len包含PF_密钥消息中所有数据的总长度（64位字），包括基本头长度和基本头后的附加数据（如果有）。此长度包括可能存在的任何填充或额外空间。除非另有说明，否则所有其他长度字段也以64位字测量。
On user to kernel messages, this field MUST be verified against the length of the inbound message. EMSGSIZE MUST be returned if the verification fails. On kernel to user messages, a size mismatch is most likely the result of the user not providing a large enough buffer for the message. In these cases, the user application SHOULD drop the message, but it MAY try and extract what information it can out of the message.
对于用户到内核的消息，必须根据入站消息的长度验证此字段。如果验证失败，则必须返回EMSGSIZE。在内核到用户消息上，大小不匹配很可能是由于用户没有为消息提供足够大的缓冲区。在这些情况下，用户应用程序应该删除消息，但它可以尝试从消息中提取它可以提取的信息。
sadb_msg_reserved Reserved value. It MUST be zeroed by the sender. All fields labeled reserved later in the document have the same semantics as this field.
sadb_msg_保留值。发送方必须将其归零。文档中稍后标记为“保留”的所有字段与此字段具有相同的语义。
sadb_msg_seq Contains the sequence number of this message. This field, along with sadb_msg_pid, MUST be used to uniquely identify requests to a process. The sender is responsible for filling in this field. This responsibility also includes matching the sadb_msg_seq of a request (e.g. SADB_ACQUIRE).
sadb_msg_seq包含此消息的序列号。此字段以及sadb_msg_pid必须用于唯一标识对流程的请求。发件人负责填写此字段。该职责还包括匹配请求的sadb_msg_seq（例如sadb_ACQUIRE）。
This field is similar to a transaction ID in a remote procedure call implementation.
此字段类似于远程过程调用实现中的事务ID。
sadb_msg_pid Identifies the process which originated this message, or which process a message is bound for. For example, if process id 2112 sends an SADB_UPDATE message to the kernel, the process MUST set this field to 2112 and the kernel will set this field to 2112 in its reply to that SADB_UPDATE message. This field, along with sadb_msg_seq, can be used to uniquely identify requests to a process.
sadb_msg_pid标识生成此消息的进程，或消息绑定到哪个进程。例如，如果进程id 2112向内核发送SADB_更新消息，则进程必须将此字段设置为2112，内核将在其对该SADB_更新消息的回复中将此字段设置为2112。此字段以及sadb_msg_seq可用于唯一标识对流程的请求。
It is currently assumed that a 32-bit quantity will hold an operating system's process ID space.
目前假定32位的数量将保留操作系统的进程ID空间。
The base message header is a multiple of 64 bits and fields after it in memory will be 64 bit aligned if the base itself is 64 bit aligned. Some of the subsequent extension headers have 64 bit fields in them, and as a consequence need to be 64 bit aligned in an environment where 64 bit quantities need to be 64 bit aligned.
基本消息头是64位的倍数，如果基本消息头本身是64位对齐的，则内存中它后面的字段将是64位对齐的。一些后续扩展标头中有64位字段，因此在64位数量需要64位对齐的环境中需要64位对齐。
The basic unit of alignment and length in PF_KEY Version 2 is 64 bits. Therefore:
PF_密钥版本2中对齐和长度的基本单位为64位。因此：
* All extension headers, inclusive of the sadb_ext overlay fields, MUST be a multiple of 64 bits long.
* 所有扩展标题（包括sadb_ext覆盖字段）必须是64位长的倍数。
* All variable length data MUST be padded appropriately such that its length in a message is a multiple of 64 bits.
* 所有可变长度数据必须适当填充，以使其在消息中的长度为64位的倍数。
* All length fields are, unless otherwise specified, in units of 64 bits.
* 除非另有规定，否则所有长度字段均以64位为单位。
* Implementations may safely access quantities of between 8 and 64 bits directly within a message without risk of alignment faults.
* 实现可以安全地直接访问消息中8到64位的数量，而不会出现对齐错误的风险。
All PF_KEYv2 structures are packed and already have all intended padding. Implementations MUST NOT insert any extra fields, including hidden padding, into any structure in this document. This forbids implementations from "extending" or "enhancing" existing headers without changing the extension header type. As a guard against such insertion of silent padding, each structure in this document is labeled with its size in bytes. The size of these structures in an implementation MUST match the size listed.
所有PF_KEYv2结构都已打包，并且已经具有所有预期填充。实现不得在本文档的任何结构中插入任何额外字段，包括隐藏填充。这禁止实现在不更改扩展头类型的情况下“扩展”或“增强”现有头。为了防止插入静默填充，本文档中的每个结构都标有其大小（以字节为单位）。实现中这些结构的大小必须与列出的大小匹配。
The additional data following the base header consists of various length-type-values fields. The first 32-bits are of a constant form:
基本标头后面的附加数据由各种长度类型值字段组成。前32位为常数形式：
struct sadb_ext {
uint16_t sadb_ext_len;
uint16_t sadb_ext_type;
};
/* sizeof(struct sadb_ext) == 4 */
struct sadb_ext {
uint16_t sadb_ext_len;
uint16_t sadb_ext_type;
};
/* sizeof(struct sadb_ext) == 4 */
sadb_ext_len Length of the extension header in 64 bit words, inclusive.
扩展头的sadb_ext_len长度（包括64位字）。
sadb_ext_type The type of extension header that follows. Values for this field are detailed later. The value zero is reserved.
sadb_ext_type后面的扩展头类型。此字段的值将在后面详细说明。保留值0。
Types of extension headers include: Association, Lifetime(s), Address(s), Key(s), Identity(ies), Sensitivity, Proposal, and Supported. There MUST be only one instance of a extension type in a message. (e.g. Base, Key, Lifetime, Key is forbidden). An EINVAL will be returned if there are duplicate extensions within a message. Implementations MAY enforce ordering of extensions in the order presented in the EXTENSION HEADER VALUES section.
扩展头的类型包括：关联、生存期、地址、密钥、标识、敏感度、建议和支持。消息中只能有一个扩展类型实例。（例如：底座、钥匙、寿命、禁止使用钥匙）。如果消息中存在重复的扩展名，则将返回EINVAL。实现可以按照EXTENSION HEADER VALUES部分中显示的顺序强制执行扩展的顺序。
If an unknown extension type is encountered, it MUST be ignored. Applications using extension headers not specified in this document MUST be prepared to work around other system components not processing those headers. Likewise, if an application encounters an unknown extension from the kernel, it must be prepared to work around it. Also, a kernel that generates extra extension header types MUST NOT _depend_ on applications also understanding extra extension header types.
如果遇到未知的扩展类型，则必须忽略它。使用本文档中未指定的扩展标头的应用程序必须准备好绕过未处理这些标头的其他系统组件。同样，如果应用程序遇到来自内核的未知扩展，它必须准备好解决它。另外，生成额外扩展头类型的内核不能依赖于也理解额外扩展头类型的应用程序。
All extension definitions include these two fields (len and exttype) because they are instances of a generic extension (not unlike sockaddr_in and sockaddr_in6 are instances of a generic sockaddr). The sadb_ext header MUST NOT ever be present in a message without at least four bytes of extension header data following it, and, therefore, there is no problem with it being only four bytes long.
所有扩展定义都包含这两个字段（len和exttype），因为它们是泛型扩展的实例（与sockaddr_in和sockaddr_in6不同的是，它们是泛型sockaddr的实例）。sadb_ext头不能出现在消息中，后面至少有四个字节的扩展头数据，因此，它只有四个字节长没有问题。
All extensions documented in this section MUST be implemented by a PF_KEY implementation.
本节中记录的所有扩展必须由PF_密钥实现来实现。
The Association extension specifies data specific to a single security association. The only times this extension is not present is when control messages (e.g. SADB_FLUSH or SADB_REGISTER) are being passed and on the SADB_ACQUIRE message.
关联扩展指定特定于单个安全关联的数据。只有在传递控制消息（如SADB_刷新或SADB_寄存器）时，以及在SADB_获取消息上，此扩展不存在。
struct sadb_sa {
uint16_t sadb_sa_len;
uint16_t sadb_sa_exttype;
uint32_t sadb_sa_spi;
uint8_t sadb_sa_replay;
uint8_t sadb_sa_state;
uint8_t sadb_sa_auth;
uint8_t sadb_sa_encrypt;
uint32_t sadb_sa_flags;
};
struct sadb_sa {
uint16_t sadb_sa_len;
uint16_t sadb_sa_exttype;
uint32_t sadb_sa_spi;
uint8_t sadb_sa_replay;
uint8_t sadb_sa_state;
uint8_t sadb_sa_auth;
uint8_t sadb_sa_encrypt;
uint32_t sadb_sa_flags;
};
/* sizeof(struct sadb_sa) == 16 */
/* sizeof(struct sadb_sa) == 16 */
sadb_sa_spi The Security Parameters Index value for the security association. Although this is a 32-bit field, some types of security associations might have an SPI or key identifier that is less than 32-bits long. In this case, the smaller value shall be stored in the least significant bits of this field and the unneeded bits shall be zero. This field MUST be in network byte order.
sadb_sa_spi安全关联的安全参数索引值。尽管这是一个32位字段，但某些类型的安全关联可能具有长度小于32位的SPI或密钥标识符。在这种情况下，较小的值应存储在该字段的最低有效位，不需要的位应为零。此字段必须按网络字节顺序排列。
sadb_sa_replay The size of the replay window, if not zero. If zero, then no replay window is in use.
sadb_sa_replay回放窗口的大小（如果不是零）。如果为零，则不使用重播窗口。
sadb_sa_state The state of the security association. The currently defined states are described later in this document.
sadb_sa_州安全协会所在州。本文档后面将描述当前定义的状态。
sadb_sa_auth The authentication algorithm to be used with this security association. The valid authentication algorithms are described later in this document. A value of zero means that no authentication is used for this security association.
sadb_sa_验证要与此安全关联一起使用的身份验证算法。有效的身份验证算法将在本文档后面介绍。值为零表示此安全关联未使用身份验证。
sadb_sa_encrypt The encryption algorithm to be used with this security association. The valid encryption algorithms are described later in this document. A value of zero means that no encryption is used for this security association.
sadb_sa_加密要与此安全关联一起使用的加密算法。本文档后面将介绍有效的加密算法。值为零表示此安全关联未使用加密。
sadb_sa_flags A bitmap of options defined for the security association. The currently defined flags are described later in this document.
sadb_sa_标记为安全关联定义的选项位图。本文档后面将介绍当前定义的标志。
The kernel MUST check these values where appropriate. For example, IPsec AH with no authentication algorithm is probably an error.
内核必须在适当的地方检查这些值。例如，没有身份验证算法的IPsec AH可能是一个错误。
When used with some messages, the values in some fields in this header should be ignored.
与某些消息一起使用时，应忽略此标头中某些字段中的值。
The Lifetime extension specifies one or more lifetime variants for this security association. If no Lifetime extension is present the association has an infinite lifetime. An association SHOULD have a lifetime of some sort associated with it. Lifetime variants come in three varieties, HARD - indicating the hard-limit expiration, SOFT - indicating the soft-limit expiration, and CURRENT - indicating the current state of a given security association. The Lifetime
生存期扩展指定此安全关联的一个或多个生存期变体。如果不存在生存期扩展，则关联具有无限生存期。关联应该有某种类型的生命周期与之关联。生存期变量有三种，硬-表示硬限制到期，软-表示软限制到期，当前-表示给定安全关联的当前状态。一生
extension looks like:
扩展看起来像：
struct sadb_lifetime {
uint16_t sadb_lifetime_len;
uint16_t sadb_lifetime_exttype;
uint32_t sadb_lifetime_allocations;
uint64_t sadb_lifetime_bytes;
uint64_t sadb_lifetime_addtime;
uint64_t sadb_lifetime_usetime;
};
/* sizeof(struct sadb_lifetime) == 32 */
struct sadb_lifetime {
uint16_t sadb_lifetime_len;
uint16_t sadb_lifetime_exttype;
uint32_t sadb_lifetime_allocations;
uint64_t sadb_lifetime_bytes;
uint64_t sadb_lifetime_addtime;
uint64_t sadb_lifetime_usetime;
};
/* sizeof(struct sadb_lifetime) == 32 */
sadb_lifetime_allocations For CURRENT, the number of different connections, endpoints, or flows that the association has been allocated towards. For HARD and SOFT, the number of these the association may be allocated towards before it expires. The concept of a connection, flow, or endpoint is system specific.
sadb_lifetime_当前分配，关联已分配到的不同连接、端点或流的数量。对于硬的和软的，在关联到期之前可以分配给它们的数量。连接、流或端点的概念是特定于系统的。
sadb_lifetime_bytes For CURRENT, how many bytes have been processed using this security association. For HARD and SOFT, the number of bytes that may be processed using this security association before it expires.
sadb_lifetime_字节对于当前，使用此安全关联处理了多少字节。对于硬关联和软关联，在安全关联过期之前可以使用此安全关联处理的字节数。
sadb_lifetime_addtime For CURRENT, the time, in seconds, when the association was created. For HARD and SOFT, the number of seconds after the creation of the association until it expires.
sadb_lifetime_addtime For CURRENT，创建关联时的时间（以秒为单位）。对于硬关联和软关联，指创建关联后到过期的秒数。
For such time fields, it is assumed that 64-bits is sufficiently large to hold the POSIX time_t value. If this assumption is wrong, this field will have to be revisited.
对于此类时间字段，假设64位足够大，足以容纳POSIX time_t值。如果这个假设是错误的，这个领域将不得不重新审视。
sadb_lifetime_usetime For CURRENT, the time, in seconds, when association was first used. For HARD and SOFT, the number of seconds after the first use of the association until it expires.
sadb_lifetime_usetime For CURRENT，首次使用关联时的时间（以秒为单位）。对于硬关联和软关联，指首次使用关联后到过期的秒数。
The semantics of lifetimes are inclusive-OR, first-to-expire. This means that if values for bytes and time, or multiple times, are passed in, the first of these values to be reached will cause a lifetime expiration.
生命周期的语义是包含的，或者首先是过期的。这意味着，如果传入字节和时间的值，或多次传入，则要达到的第一个值将导致生存期过期。
The Address extension specifies one or more addresses that are associated with a security association. Address extensions for both source and destination MUST be present when an Association extension is present. The format of an Address extension is:
地址扩展指定一个或多个与安全关联关联的地址。当存在关联扩展时，源和目标的地址扩展都必须存在。地址扩展的格式为：
struct sadb_address {
uint16_t sadb_address_len;
uint16_t sadb_address_exttype;
uint8_t sadb_address_proto;
uint8_t sadb_address_prefixlen;
uint16_t sadb_address_reserved;
};
/* sizeof(struct sadb_address) == 8 */
struct sadb_address {
uint16_t sadb_address_len;
uint16_t sadb_address_exttype;
uint8_t sadb_address_proto;
uint8_t sadb_address_prefixlen;
uint16_t sadb_address_reserved;
};
/* sizeof(struct sadb_address) == 8 */
/* followed by some form of struct sockaddr */
/* followed by some form of struct sockaddr */
The sockaddr structure SHOULD conform to the sockaddr structure of the system implementing PF_KEY. If the system has an sa_len field, so SHOULD the sockaddrs in the message. If the system has NO sa_len field, the sockaddrs SHOULD NOT have an sa_len field. All non-address information in the sockaddrs, such as sin_zero for AF_INET sockaddrs, and sin6_flowinfo for AF_INET6 sockaddrs, MUST be zeroed out. The zeroing of ports (e.g. sin_port and sin6_port) MUST be done for all messages except for originating SADB_ACQUIRE messages, which SHOULD fill them in with ports from the relevant TCP or UDP session which generates the ACQUIRE message. If the ports are non-zero, then the sadb_address_proto field, normally zero, MUST be filled in with the transport protocol's number. If the sadb_address_prefixlen is non-zero, then the address has a prefix (often used in KM access control decisions), with length specified in sadb_address_prefixlen. These additional fields may be useful to KM applications.
sockaddr结构应符合实现PF_密钥的系统的sockaddr结构。如果系统有一个sau len字段，那么消息中的sockaddrs也应该有。如果系统没有sau len字段，则sockaddrs不应具有sau len字段。sockaddrs中的所有非地址信息，例如用于AF_INET sockaddrs的sinu zero和用于AF_INET6 sockaddrs的sin6_flowinfo，都必须归零。端口归零（例如sin_端口和sin6_端口）必须针对所有消息进行，但原始SADB_ACQUIRE消息除外，该消息应使用生成ACQUIRE消息的相关TCP或UDP会话的端口填充端口。如果端口不为零，则sadb_地址_协议字段（通常为零）必须填写传输协议的编号。如果sadb_地址_前缀为非零，则该地址具有前缀（通常用于KM访问控制决策），长度在sadb_地址_前缀中指定。这些附加字段可能对KM应用有用。
The SRC and DST addresses for a security association MUST be in the same protocol family and MUST always be present or absent together in a message. The PROXY address MAY be in a different protocol family, and for most security protocols, represents an actual originator of a packet. (For example, the inner-packets's source address in a tunnel.)
安全关联的SRC和DST地址必须在同一协议系列中，并且在消息中必须始终同时存在或不存在。代理地址可以在不同的协议族中，并且对于大多数安全协议，代表数据包的实际发起人。（例如，隧道中内部数据包的源地址。）
The SRC address MUST be a unicast or unspecified (e.g., INADDR_ANY) address. The DST address can be any valid destination address (unicast, multicast, or even broadcast). The PROXY address SHOULD be a unicast address (there are experimental security protocols where PROXY semantics may be different than described above).
SRC地址必须是单播或未指定（例如INADR_ANY）地址。DST地址可以是任何有效的目标地址（单播、多播甚至广播）。代理地址应该是单播地址（有实验性的安全协议，其中代理语义可能与上述不同）。
The Key extension specifies one or more keys that are associated with a security association. A Key extension will not always be present with messages, because of security risks. The format of a Key extension is:
密钥扩展指定一个或多个与安全关联关联的密钥。由于存在安全风险，密钥扩展并不总是与消息一起出现。密钥扩展名的格式为：
struct sadb_key {
uint16_t sadb_key_len;
uint16_t sadb_key_exttype;
uint16_t sadb_key_bits;
uint16_t sadb_key_reserved;
};
/* sizeof(struct sadb_key) == 8 */
struct sadb_key {
uint16_t sadb_key_len;
uint16_t sadb_key_exttype;
uint16_t sadb_key_bits;
uint16_t sadb_key_reserved;
};
/* sizeof(struct sadb_key) == 8 */
/* followed by the key data */
/* followed by the key data */
sadb_key_bits The length of the valid key data, in bits. A value of zero in sadb_key_bits MUST cause an error.
sadb_key_bits有效密钥数据的长度，以位为单位。sadb_密钥_位中的值为零必须导致错误。
The key extension comes in two varieties. The AUTH version is used with authentication keys (e.g. IPsec AH, OSPF MD5) and the ENCRYPT version is used with encryption keys (e.g. IPsec ESP). PF_KEY deals only with fully formed cryptographic keys, not with "raw key material". For example, when ISAKMP/Oakley is in use, the key management daemon is always responsible for transforming the result of the Diffie-Hellman computation into distinct fully formed keys PRIOR to sending those keys into the kernel via PF_KEY. This rule is made because PF_KEY is designed to support multiple security protocols (not just IP Security) and also multiple key management schemes including manual keying, which does not have the concept of "raw key material". A clean, protocol-independent interface is important for portability to different operating systems as well as for portability to different security protocols.
关键的扩展有两种类型。认证版本与认证密钥（如IPsec AH、OSPF MD5）一起使用，加密版本与加密密钥（如IPsec ESP）一起使用。PF_密钥只处理完全格式的加密密钥，而不处理“原始密钥材料”。例如，在使用ISAKMP/Oakley时，密钥管理守护进程始终负责将Diffie-Hellman计算的结果转换为不同的完全格式密钥，然后再通过PF_密钥将这些密钥发送到内核中。之所以制定此规则，是因为PF_密钥设计用于支持多种安全协议（不仅仅是IP安全）以及多种密钥管理方案，包括手动密钥，而手动密钥没有“原始密钥材料”的概念。干净、独立于协议的接口对于不同操作系统的可移植性以及不同安全协议的可移植性非常重要。
If an algorithm defines its key to include parity bits (e.g. DES) then the key used with PF_KEY MUST also include those parity bits. For example, this means that a single DES key is always a 64-bit quantity.
如果算法将其密钥定义为包含奇偶校验位（例如DES），则与PF_密钥一起使用的密钥也必须包含这些奇偶校验位。例如，这意味着单个DES密钥始终是64位数量。
When a particular security protocol only requires one authentication and/or one encryption key, the fully formed key is transmitted using the appropriate key extension. When a particular security protocol requires more than one key for the same function (e.g. Triple-DES using 2 or 3 keys, and asymmetric algorithms), then those two fully formed keys MUST be concatenated together in the order used for outbound packet processing. In the case of multiple keys, the algorithm MUST be able to determine the lengths of the individual
当特定安全协议仅需要一个身份验证和/或一个加密密钥时，使用适当的密钥扩展来传输完全形成的密钥。当一个特定的安全协议需要一个以上的密钥用于相同的功能时（例如，使用2或3个密钥的三重DES以及非对称算法），则必须按照用于出站数据包处理的顺序将这两个完全形成的密钥连接在一起。对于多个密钥，算法必须能够确定单个密钥的长度
keys based on the information provided. The total key length (when combined with knowledge of the algorithm in use) usually provides sufficient information to make this determination.
密钥基于提供的信息。总密钥长度（与使用的算法知识相结合时）通常提供足够的信息来进行此确定。
Keys are always passed through the PF_KEY interface in the order that they are used for outbound packet processing. For inbound processing, the correct order that keys are used might be different from this canonical concatenation order used with the PF_KEY interface. It is the responsibility of the implementation to use the keys in the correct order for both inbound and outbound processing.
密钥始终按照用于出站数据包处理的顺序通过PF_密钥接口。对于入站处理，键的正确使用顺序可能与PF_键接口使用的规范连接顺序不同。以正确的顺序使用密钥进行入站和出站处理是实现的责任。
For example, consider a pair of nodes communicating unicast using an ESP three-key Triple-DES Security Association. Both the outbound SA on the sender node, and the inbound SA on the receiver node will contain key-A, followed by key-B, followed by key-C in their respective ENCRYPT key extensions. The outbound SA will use key-A first, followed by key-B, then key-C when encrypting. The inbound SA will use key-C, followed by key-B, then key-A when decrypting. (NOTE: We are aware that 3DES is actually encrypt-decrypt-encrypt.) The canonical ordering of key-A, key-B, key-C is used for 3DES, and should be documented. The order of "encryption" is the canonical order for this example. [Sch96]
例如，考虑一对使用ESP三密钥三重DES安全关联进行单播通信的节点。发送方节点上的出站SA和接收方节点上的入站SA都将在各自的加密密钥扩展中包含key-A、key-B和key-C。出站SA在加密时将首先使用key-A，然后使用key-B，然后使用key-C。入站SA将在解密时使用key-C，后跟key-B，然后是key-A。（注意：我们知道3DES实际上是加密-解密-加密。）密钥A、密钥B、密钥C的规范顺序用于3DES，应予以记录。“加密”的顺序是本例的规范顺序。[Sch96]
The key data bits are arranged most-significant to least significant. For example, a 22-bit key would take up three octets, with the least significant two bits not containing key material. Five additional octets would then be used for padding to the next 64-bit boundary.
关键数据位排列为最高有效到最低有效。例如，一个22位的密钥将占用三个八位字节，最低有效的两位不包含密钥材料。然后，将使用五个额外的八位字节填充到下一个64位边界。
While not directly related to PF_KEY, there is a user interface issue regarding odd-digit hexadecimal representation of keys. Consider the example of the 16-bit number:
虽然与PF_键没有直接关系，但存在关于键的奇数十六进制表示的用户界面问题。考虑16位数字的例子：
0x123
0x123
That will require two octets of storage. In the absence of other information, however, unclear whether the value shown is stored as:
这将需要两个八位字节的存储。但是，在没有其他信息的情况下，不清楚显示的值是否存储为：
01 23 OR 12 30
01 23或12 30
It is the opinion of the authors that the former (0x123 == 0x0123) is the better way to interpret this ambiguity. Extra information (for example, specifying 0x0123 or 0x1230, or specifying that this is only a twelve-bit number) would solve this problem.
作者认为，前者（0x123==0x0123）是更好的解释这种歧义的方法。额外信息（例如，指定0x0123或0x1230，或指定这只是一个12位数字）将解决此问题。
The Identity extension contains endpoint identities. This information is used by key management to select the identity certificate that is used in negotiations. This information may also be provided by a kernel to network security aware applications to identify the remote entity, possibly for access control purposes. If this extension is not present, key management MUST assume that the addresses in the Address extension are the only identities for this Security Association. The Identity extension looks like:
标识扩展包含端点标识。密钥管理使用此信息选择协商中使用的身份证书。该信息还可由内核向网络安全感知应用程序提供，以识别远程实体，可能用于访问控制目的。如果不存在此扩展，则密钥管理必须假定地址扩展中的地址是此安全关联的唯一标识。标识扩展如下所示：
struct sadb_ident {
uint16_t sadb_ident_len;
uint16_t sadb_ident_exttype;
uint16_t sadb_ident_type;
uint16_t sadb_ident_reserved;
uint64_t sadb_ident_id;
};
/* sizeof(struct sadb_ident) == 16 */
struct sadb_ident {
uint16_t sadb_ident_len;
uint16_t sadb_ident_exttype;
uint16_t sadb_ident_type;
uint16_t sadb_ident_reserved;
uint64_t sadb_ident_id;
};
/* sizeof(struct sadb_ident) == 16 */
/* followed by the identity string, if present */
/* followed by the identity string, if present */
sadb_ident_type The type of identity information that follows. Currently defined identity types are described later in this document.
sadb_ident_type后面的标识信息类型。本文档后面将介绍当前定义的标识类型。
sadb_ident_id An identifier used to aid in the construction of an identity string if none is present. A POSIX user id value is one such identifier that will be used in this field. Use of this field is described later in this document.
sadb_ident_id如果不存在标识字符串，则用于帮助构造标识字符串的标识符。POSIX用户id值就是将在该字段中使用的标识符之一。本文档后面将介绍此字段的使用。
A C string containing a textual representation of the identity information optionally follows the sadb_ident extension. The format of this string is determined by the value in sadb_ident_type, and is described later in this document.
包含标识信息的文本表示的C字符串可选地遵循sadb_ident扩展名。此字符串的格式由sadb_ident_type中的值确定，本文档稍后将对此进行描述。
The Sensitivity extension contains security labeling information for a security association. If this extension is not present, no sensitivity-related data can be obtained from this security association. If this extension is present, then the need for explicit security labeling on the packet is obviated.
敏感度扩展包含安全关联的安全标签信息。如果不存在此扩展，则无法从此安全关联获取任何与敏感度相关的数据。如果存在此扩展，则无需在数据包上进行明确的安全标记。
struct sadb_sens {
uint16_t sadb_sens_len;
uint16_t sadb_sens_exttype;
struct sadb_sens {
uint16_t sadb_sens_len;
uint16_t sadb_sens_exttype;
uint32_t sadb_sens_dpd;
uint8_t sadb_sens_sens_level;
uint8_t sadb_sens_sens_len;
uint8_t sadb_sens_integ_level;
uint8_t sadb_sens_integ_len;
uint32_t sadb_sens_reserved;
};
/* sizeof(struct sadb_sens) == 16 */
uint32_t sadb_sens_dpd;
uint8_t sadb_sens_sens_level;
uint8_t sadb_sens_sens_len;
uint8_t sadb_sens_integ_level;
uint8_t sadb_sens_integ_len;
uint32_t sadb_sens_reserved;
};
/* sizeof(struct sadb_sens) == 16 */
/* followed by:
uint64_t sadb_sens_bitmap[sens_len];
uint64_t sadb_integ_bitmap[integ_len]; */
/* followed by:
uint64_t sadb_sens_bitmap[sens_len];
uint64_t sadb_integ_bitmap[integ_len]; */
sadb_sens_dpd Describes the protection domain, which allows interpretation of the levels and compartment bitmaps. sadb_sens_sens_level The sensitivity level. sadb_sens_sens_len The length, in 64 bit words, of the sensitivity bitmap. sadb_sens_integ_level The integrity level. sadb_sens_integ_len The length, in 64 bit words, of the integrity bitmap.
sadb_sens_dpd描述了保护域，它允许解释级别和隔间位图。sadb_sens_sens_level灵敏度水平。sadb_sens_sens_len灵敏度位图的长度（64位字）。sadb_sens_integ_level完整性级别。sadb_sens_integ_len完整位图的长度（64位字）。
This sensitivity extension is designed to support the Bell-LaPadula [BL74] security model used in compartmented-mode or multi-level secure systems, the Clark-Wilson [CW87] commercial security model, and/or the Biba integrity model [Biba77]. These formal models can be used to implement a wide variety of security policies. The definition of a particular security policy is outside the scope of this document. Each of the bitmaps MUST be padded to a 64-bit boundary if they are not implicitly 64-bit aligned.
该敏感度扩展旨在支持用于分隔模式或多级安全系统的Bell-LaPadula[BL74]安全模型、Clark Wilson[CW87]商业安全模型和/或Biba完整性模型[Biba77]。这些形式化模型可用于实现多种安全策略。特定安全策略的定义不在本文档的范围内。如果位图不是隐式64位对齐的，则必须将每个位图填充到64位边界。
The Proposal extension contains a "proposed situation" of algorithm preferences. It looks like:
建议扩展包含算法首选项的“建议情况”。它看起来像：
struct sadb_prop {
uint16_t sadb_prop_len;
uint16_t sadb_prop_exttype;
uint8_t sadb_prop_replay;
uint8_t sadb_prop_reserved[3];
};
/* sizeof(struct sadb_prop) == 8 */
struct sadb_prop {
uint16_t sadb_prop_len;
uint16_t sadb_prop_exttype;
uint8_t sadb_prop_replay;
uint8_t sadb_prop_reserved[3];
};
/* sizeof(struct sadb_prop) == 8 */
/* followed by:
struct sadb_comb sadb_combs[(sadb_prop_len *
sizeof(uint64_t) - sizeof(struct sadb_prop)) /
sizeof(struct sadb_comb)]; */
/* followed by:
struct sadb_comb sadb_combs[(sadb_prop_len *
sizeof(uint64_t) - sizeof(struct sadb_prop)) /
sizeof(struct sadb_comb)]; */
Following the header is a list of proposed parameter combinations in preferential order. The values in these fields have the same definition as the fields those values will move into if the combination is chosen.
标题后面是按优先顺序列出的建议参数组合。如果选择组合，这些字段中的值与这些值将移动到的字段具有相同的定义。
NOTE: Some algorithms in some security protocols will have variable IV lengths per algorithm. Variable length IVs are not supported by PF_KEY v2. If they were, however, proposed IV lengths would go in the Proposal Extension.
注意：某些安全协议中的某些算法每个算法具有可变的IV长度。PF_键v2不支持可变长度IVs。然而，如果他们是，提议的IV长度将在提案延期中使用。
These combinations look like:
这些组合看起来像：
struct sadb_comb {
uint8_t sadb_comb_auth;
uint8_t sadb_comb_encrypt;
uint16_t sadb_comb_flags;
uint16_t sadb_comb_auth_minbits;
uint16_t sadb_comb_auth_maxbits;
uint16_t sadb_comb_encrypt_minbits;
uint16_t sadb_comb_encrypt_maxbits;
uint32_t sadb_comb_reserved;
uint32_t sadb_comb_soft_allocations;
uint32_t sadb_comb_hard_allocations;
uint64_t sadb_comb_soft_bytes;
uint64_t sadb_comb_hard_bytes;
uint64_t sadb_comb_soft_addtime;
uint64_t sadb_comb_hard_addtime;
uint64_t sadb_comb_soft_usetime;
uint64_t sadb_comb_hard_usetime;
};
struct sadb_comb {
uint8_t sadb_comb_auth;
uint8_t sadb_comb_encrypt;
uint16_t sadb_comb_flags;
uint16_t sadb_comb_auth_minbits;
uint16_t sadb_comb_auth_maxbits;
uint16_t sadb_comb_encrypt_minbits;
uint16_t sadb_comb_encrypt_maxbits;
uint32_t sadb_comb_reserved;
uint32_t sadb_comb_soft_allocations;
uint32_t sadb_comb_hard_allocations;
uint64_t sadb_comb_soft_bytes;
uint64_t sadb_comb_hard_bytes;
uint64_t sadb_comb_soft_addtime;
uint64_t sadb_comb_hard_addtime;
uint64_t sadb_comb_soft_usetime;
uint64_t sadb_comb_hard_usetime;
};
/* sizeof(struct sadb_comb) == 72 */
/* sizeof(struct sadb_comb) == 72 */
sadb_comb_auth If this combination is accepted, this will be the value of sadb_sa_auth.
sadb_comb_auth如果接受此组合，这将是sadb_sa_auth的值。
sadb_comb_encrypt If this combination is accepted, this will be the value of sadb_sa_encrypt.
sadb_comb_encrypt如果接受此组合，则这将是sadb_sa_encrypt的值。
sadb_comb_auth_minbits;
sadb_comb_auth_maxbits;
The minimum and maximum acceptable authentication
key lengths, respectably, in bits. If sadb_comb_auth
is zero, both of these values MUST be zero. If
sadb_comb_auth is nonzero, both of these values MUST
be nonzero. If this combination is accepted, a value
between these (inclusive) will be stored in the
sadb_key_bits field of KEY_AUTH. The minimum MUST
NOT be greater than the maximum.
sadb_comb_auth_minbits;
sadb_comb_auth_maxbits;
The minimum and maximum acceptable authentication
key lengths, respectably, in bits. If sadb_comb_auth
is zero, both of these values MUST be zero. If
sadb_comb_auth is nonzero, both of these values MUST
be nonzero. If this combination is accepted, a value
between these (inclusive) will be stored in the
sadb_key_bits field of KEY_AUTH. The minimum MUST
NOT be greater than the maximum.
sadb_comb_encrypt_minbits;
sadb_comb_encrypt_maxbits;
The minimum and maximum acceptable encryption key
lengths, respectably, in bits. If sadb_comb_encrypt
is zero, both of these values MUST be zero. If
sadb_comb_encrypt is nonzero, both of these values
MUST be nonzero. If this combination is accepted, a
value between these (inclusive) will be stored in
the sadb_key_bits field of KEY_ENCRYPT. The minimum
MUST NOT be greater than the maximum.
sadb_comb_encrypt_minbits;
sadb_comb_encrypt_maxbits;
The minimum and maximum acceptable encryption key
lengths, respectably, in bits. If sadb_comb_encrypt
is zero, both of these values MUST be zero. If
sadb_comb_encrypt is nonzero, both of these values
MUST be nonzero. If this combination is accepted, a
value between these (inclusive) will be stored in
the sadb_key_bits field of KEY_ENCRYPT. The minimum
MUST NOT be greater than the maximum.
sadb_comb_soft_allocations sadb_comb_hard_allocations If this combination is accepted, these are proposed values of sadb_lifetime_allocations in the SOFT and HARD lifetimes, respectively.
sadb_comb_soft_分配sadb_comb_hard_分配如果接受此组合，则分别是软生命周期和硬生命周期中sadb_life_分配的建议值。
sadb_comb_soft_bytes sadb_comb_hard_bytes If this combination is accepted, these are proposed values of sadb_lifetime_bytes in the SOFT and HARD lifetimes, respectively.
sadb_comb_soft_字节sadb_comb_hard_字节如果接受此组合，则分别为软生命期和硬生命期中sadb_life_字节的建议值。
sadb_comb_soft_addtime sadb_comb_hard_addtime If this combination is accepted, these are proposed values of sadb_lifetime_addtime in the SOFT and HARD lifetimes, respectively.
sadb_comb_soft_addtime sadb_comb_hard_addtime如果接受此组合，则分别为软生命期和硬生命期中sadb_life_addtime的建议值。
sadb_comb_soft_usetime sadb_comb_hard_usetime If this combination is accepted, these are proposed values of sadb_lifetime_usetime in the SOFT and HARD lifetimes, respectively.
sadb_comb_soft_usetime sadb_comb_hard_usetime如果接受此组合，则分别为软寿命和硬寿命中sadb_life_usetime的建议值。
Each combination has an authentication and encryption algorithm, which may be 0, indicating none. A combination's flags are the same as the flags in the Association extension. The minimum and maximum key lengths (which are in bits) are derived from possible a priori policy decisions, along with basic properties of the algorithm. Lifetime attributes are also included in a combination, as some algorithms may know something about their lifetimes and can suggest lifetime limits.
每个组合都有一个身份验证和加密算法，该算法可能为0，表示无。组合的标志与关联扩展中的标志相同。最小和最大密钥长度（以位为单位）是根据可能的先验策略决策以及算法的基本属性得出的。生命周期属性也包含在组合中，因为一些算法可能知道一些关于其生命周期的信息，并且可以建议生命周期限制。
The Supported Algorithms extension contains a list of all algorithms supported by the system. This tells key management what algorithms it can negotiate. Available authentication algorithms are listed in the SUPPORTED_AUTH extension and available encryption algorithms are listed in the SUPPORTED_ENCRYPT extension. The format of these extensions is:
支持的算法扩展包含系统支持的所有算法的列表。这告诉密钥管理可以协商哪些算法。可用的身份验证算法列在支持的\u AUTH扩展中，可用的加密算法列在支持的\u ENCRYPT扩展中。这些扩展的格式为：
struct sadb_supported {
uint16_t sadb_supported_len;
uint16_t sadb_supported_exttype;
uint32_t sadb_supported_reserved;
};
/* sizeof(struct sadb_supported) == 8 */
struct sadb_supported {
uint16_t sadb_supported_len;
uint16_t sadb_supported_exttype;
uint32_t sadb_supported_reserved;
};
/* sizeof(struct sadb_supported) == 8 */
/* followed by:
struct sadb_alg sadb_algs[(sadb_supported_len *
sizeof(uint64_t) - sizeof(struct sadb_supported)) /
sizeof(struct sadb_alg)]; */
/* followed by:
struct sadb_alg sadb_algs[(sadb_supported_len *
sizeof(uint64_t) - sizeof(struct sadb_supported)) /
sizeof(struct sadb_alg)]; */
This header is followed by one or more algorithm descriptions. An algorithm description looks like:
此标题后面是一个或多个算法描述。算法描述如下所示：
struct sadb_alg {
uint8_t sadb_alg_id;
uint8_t sadb_alg_ivlen;
uint16_t sadb_alg_minbits;
uint16_t sadb_alg_maxbits;
uint16_t sadb_alg_reserved;
};
/* sizeof(struct sadb_alg) == 8 */
struct sadb_alg {
uint8_t sadb_alg_id;
uint8_t sadb_alg_ivlen;
uint16_t sadb_alg_minbits;
uint16_t sadb_alg_maxbits;
uint16_t sadb_alg_reserved;
};
/* sizeof(struct sadb_alg) == 8 */
sadb_alg_id The algorithm identification value for this algorithm. This is the value that is stored in sadb_sa_auth or sadb_sa_encrypt if this algorithm is selected.
sadb_alg_id此算法的算法标识值。这是存储在sadb_sa_auth或sadb_sa_encrypt（如果选择此算法）中的值。
sadb_alg_ivlen The length of the initialization vector to be used for the algorithm. If an IV is not needed, this value MUST be set to zero.
sadb_alg_ivlen用于算法的初始化向量的长度。如果不需要IV，则该值必须设置为零。
sadb_alg_minbits The minimum acceptable key length, in bits. A value of zero is invalid.
sadb_alg_minbits最小可接受密钥长度，以位为单位。零的值无效。
sadb_alg_maxbits The maximum acceptable key length, in bits. A value of zero is invalid. The minimum MUST NOT be greater than the maximum.
sadb_alg_maxbits可接受的最大密钥长度，以位为单位。零的值无效。最小值不得大于最大值。
One PF_KEY message, SADB_GETSPI, might need a range of acceptable SPI values. This extension performs such a function.
一条PF_键消息SADB_GETSPI可能需要一个可接受的SPI值范围。这个扩展执行这样的功能。
struct sadb_spirange {
uint16_t sadb_spirange_len;
uint16_t sadb_spirange_exttype;
uint32_t sadb_spirange_min;
uint32_t sadb_spirange_max;
uint32_t sadb_spirange_reserved;
};
/* sizeof(struct sadb_spirange) == 16 */
struct sadb_spirange {
uint16_t sadb_spirange_len;
uint16_t sadb_spirange_exttype;
uint32_t sadb_spirange_min;
uint32_t sadb_spirange_max;
uint32_t sadb_spirange_reserved;
};
/* sizeof(struct sadb_spirange) == 16 */
sadb_spirange_min The minimum acceptable SPI value.
sadb_spirange_最小值为可接受的最小SPI值。
sadb_spirange_max The maximum acceptable SPI value. The maximum MUST be greater than or equal to the minimum.
sadb_spirange_max为可接受的最大SPI值。最大值必须大于或等于最小值。
The following shows how the octets are laid out in a PF_KEY message. Optional fields are indicated as such.
以下显示了八位字节在PF_密钥消息中的布局。可选字段是这样指示的。
The base header is as follows:
基本标题如下所示：
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype |
+---------------+---------------+---------------+---------------+
| sadb_msg_len | sadb_msg_reserved |
+---------------+---------------+---------------+---------------+
| sadb_msg_seq |
+---------------+---------------+---------------+---------------+
| sadb_msg_pid |
+---------------+---------------+---------------+---------------+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| ...version | sadb_msg_type | sadb_msg_errno| ...msg_satype |
+---------------+---------------+---------------+---------------+
| sadb_msg_len | sadb_msg_reserved |
+---------------+---------------+---------------+---------------+
| sadb_msg_seq |
+---------------+---------------+---------------+---------------+
| sadb_msg_pid |
+---------------+---------------+---------------+---------------+
The base header may be followed by one or more of the following extension fields, depending on the values of various base header fields. The following fields are ordered such that if they appear, they SHOULD appear in the order presented below.
根据各种基本标头字段的值，基本标头后面可能会有一个或多个以下扩展字段。以下字段按顺序排列，如果它们出现，则应按下面显示的顺序出现。
An extension field MUST not be repeated. If there is a situation where an extension MUST be repeated, it should be brought to the attention of the authors.
扩展字段不能重复。如果出现必须重复扩展的情况，则应提请作者注意。
The Association extension
关联扩展
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| sadb_sa_len | sadb_sa_exttype |
+---------------+---------------+---------------+---------------+
| sadb_sa_spi |
+---------------+---------------+---------------+---------------+
| ...replay | sadb_sa_state | sadb_sa_auth |sadb_sa_encrypt|
+---------------+---------------+---------------+---------------+
| sadb_sa_flags |
+---------------+---------------+---------------+---------------+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| sadb_sa_len | sadb_sa_exttype |
+---------------+---------------+---------------+---------------+
| sadb_sa_spi |
+---------------+---------------+---------------+---------------+
| ...replay | sadb_sa_state | sadb_sa_auth |sadb_sa_encrypt|
+---------------+---------------+---------------+---------------+
| sadb_sa_flags |
+---------------+---------------+---------------+---------------+
The Lifetime extension
寿命延长
+---------------+---------------+---------------+---------------+
| sadb_lifetime_len | sadb_lifetime_exttype |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_allocations |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_lifetime_len | sadb_lifetime_exttype |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_allocations |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_lifetime_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_lifetime_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
The Address extension
地址分机
+---------------+---------------+---------------+---------------+
| sadb_address_len | sadb_address_exttype |
+---------------+---------------+---------------+---------------+
| _address_proto| ..._prefixlen | sadb_address_reserved |
+---------------+---------------+---------------+---------------+
> Some form of 64-bit aligned struct sockaddr goes here. <
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_address_len | sadb_address_exttype |
+---------------+---------------+---------------+---------------+
| _address_proto| ..._prefixlen | sadb_address_reserved |
+---------------+---------------+---------------+---------------+
> Some form of 64-bit aligned struct sockaddr goes here. <
+---------------+---------------+---------------+---------------+
The Key extension
键扩展
+---------------+---------------+---------------+---------------+
| sadb_key_len | sadb_key_exttype |
+---------------+---------------+---------------+---------------+
| sadb_key_bits | sadb_key_reserved |
+---------------+---------------+---------------+---------------+
> A key, padded to 64-bits, most significant bits to least. >
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_key_len | sadb_key_exttype |
+---------------+---------------+---------------+---------------+
| sadb_key_bits | sadb_key_reserved |
+---------------+---------------+---------------+---------------+
> A key, padded to 64-bits, most significant bits to least. >
+---------------+---------------+---------------+---------------+
The Identity extension
身份扩展
+---------------+---------------+---------------+---------------+
| sadb_ident_len | sadb_ident_exttype |
+---------------+---------------+---------------+---------------+
| sadb_ident_type | sadb_ident_reserved |
+---------------+---------------+---------------+---------------+
| sadb_ident_id |
| (64 bits) |
+---------------+---------------+---------------+---------------+
> A null-terminated C-string which MUST be padded out for >
< 64-bit alignment. <
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_ident_len | sadb_ident_exttype |
+---------------+---------------+---------------+---------------+
| sadb_ident_type | sadb_ident_reserved |
+---------------+---------------+---------------+---------------+
| sadb_ident_id |
| (64 bits) |
+---------------+---------------+---------------+---------------+
> A null-terminated C-string which MUST be padded out for >
< 64-bit alignment. <
+---------------+---------------+---------------+---------------+
The Sensitivity extension
灵敏度扩展
+---------------+---------------+---------------+---------------+
| sadb_sens_len | sadb_sens_exttype |
+---------------+---------------+---------------+---------------+
| sadb_sens_dpd |
+---------------+---------------+---------------+---------------+
| ...sens_level | ...sens_len |..._integ_level| ..integ_len |
+---------------+---------------+---------------+---------------+
| sadb_sens_reserved |
+---------------+---------------+---------------+---------------+
> The sensitivity bitmap, followed immediately by the <
< integrity bitmap, each is an array of uint64_t. >
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_sens_len | sadb_sens_exttype |
+---------------+---------------+---------------+---------------+
| sadb_sens_dpd |
+---------------+---------------+---------------+---------------+
| ...sens_level | ...sens_len |..._integ_level| ..integ_len |
+---------------+---------------+---------------+---------------+
| sadb_sens_reserved |
+---------------+---------------+---------------+---------------+
> The sensitivity bitmap, followed immediately by the <
< integrity bitmap, each is an array of uint64_t. >
+---------------+---------------+---------------+---------------+
The Proposal extension
延期的建议
+---------------+---------------+---------------+---------------+
| sadb_prop_len | sadb_prop_exttype |
+---------------+---------------+---------------+---------------+
|...prop_replay | sadb_prop_reserved |
+---------------+---------------+---------------+---------------+
> One or more combinations, specified as follows... <
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_prop_len | sadb_prop_exttype |
+---------------+---------------+---------------+---------------+
|...prop_replay | sadb_prop_reserved |
+---------------+---------------+---------------+---------------+
> One or more combinations, specified as follows... <
+---------------+---------------+---------------+---------------+
Combination
+---------------+---------------+---------------+---------------+
|sadb_comb_auth |sadb_comb_encr | sadb_comb_flags |
+---------------+---------------+---------------+---------------+
| sadb_comb_auth_minbits | sadb_comb_auth_maxbits |
+---------------+---------------+---------------+---------------+
| sadb_comb_encrypt_minbits | sadb_comb_encrypt_maxbits |
+---------------+---------------+---------------+---------------+
| sadb_comb_reserved |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_allocations |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_allocations |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
Combination
+---------------+---------------+---------------+---------------+
|sadb_comb_auth |sadb_comb_encr | sadb_comb_flags |
+---------------+---------------+---------------+---------------+
| sadb_comb_auth_minbits | sadb_comb_auth_maxbits |
+---------------+---------------+---------------+---------------+
| sadb_comb_encrypt_minbits | sadb_comb_encrypt_maxbits |
+---------------+---------------+---------------+---------------+
| sadb_comb_reserved |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_allocations |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_allocations |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_bytes |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_addtime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_soft_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
| sadb_comb_hard_usetime |
| (64 bits) |
+---------------+---------------+---------------+---------------+
The Supported Algorithms extension
支持的算法扩展
+---------------+---------------+---------------+---------------+
| sadb_supported_len | sadb_supported_exttype |
+---------------+---------------+---------------+---------------+
| sadb_supported_reserved |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_supported_len | sadb_supported_exttype |
+---------------+---------------+---------------+---------------+
| sadb_supported_reserved |
+---------------+---------------+---------------+---------------+
Followed by one or more Algorithm Descriptors
后跟一个或多个算法描述符
+---------------+---------------+---------------+---------------+
| sadb_alg_id | sadb_alg_ivlen| sadb_alg_minbits |
+---------------+---------------+---------------+---------------+
| sadb_alg_maxbits | sadb_alg_reserved |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_alg_id | sadb_alg_ivlen| sadb_alg_minbits |
+---------------+---------------+---------------+---------------+
| sadb_alg_maxbits | sadb_alg_reserved |
+---------------+---------------+---------------+---------------+
The SPI Range extension
SPI范围扩展
+---------------+---------------+---------------+---------------+
| sadb_spirange_len | sadb_spirange_exttype |
+---------------+---------------+---------------+---------------+
| sadb_spirange_min |
+---------------+---------------+---------------+---------------+
| sadb_spirange_max |
+---------------+---------------+---------------+---------------+
| sadb_spirange_reserved |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| sadb_spirange_len | sadb_spirange_exttype |
+---------------+---------------+---------------+---------------+
| sadb_spirange_min |
+---------------+---------------+---------------+---------------+
| sadb_spirange_max |
+---------------+---------------+---------------+---------------+
| sadb_spirange_reserved |
+---------------+---------------+---------------+---------------+
3 Symbolic Names
3个象征性名称
This section defines various symbols used with PF_KEY and the semantics associated with each symbol. Applications MUST use the symbolic names in order to be portable. The numeric definitions shown are for illustrative purposes, unless explicitly stated otherwise. The numeric definition MAY vary on other systems. The symbolic name MUST be kept the same for all conforming implementations.
本节定义了与PF_键一起使用的各种符号以及与每个符号相关联的语义。为了便于移植，应用程序必须使用符号名。除非另有明确说明，否则所示数字定义仅用于说明目的。数字定义可能因其他系统而异。对于所有一致性实现，符号名称必须保持相同。
The following message types are used with PF_KEY. These are defined in the file <net/pfkeyv2.h>.
以下消息类型与PF_键一起使用。这些在文件<net/pfkeyv2.h>中定义。
#define SADB_RESERVED 0 #define SADB_GETSPI 1 #define SADB_UPDATE 2 #define SADB_ADD 3 #define SADB_DELETE 4 #define SADB_GET 5 #define SADB_ACQUIRE 6 #define SADB_REGISTER 7 #define SADB_EXPIRE 8 #define SADB_FLUSH 9
#定义SADB_保留0#定义SADB_获取SPI 1#定义SADB_更新2#定义SADB_添加3#定义SADB_删除4#定义SADB_获取5#定义SADB_获取6#定义SADB_寄存器7#定义SADB_过期8#定义SADB#9
#define SADB_DUMP 10 /* not used normally */
#define SADB_DUMP 10 /* not used normally */
#define SADB_MAX 10
#定义SADB_最大值10
Each message has a behavior. A behavior is defined as where the initial message travels (e.g. user to kernel), and what subsequent actions are expected to take place. Contents of messages are illustrated as:
每个消息都有一个行为。行为定义为初始消息传播的位置（例如，用户到内核）以及预期将发生的后续操作。消息的内容如图所示：
<base, REQUIRED EXTENSION, REQ., (OPTIONAL EXT.,) (OPT)>
<基本，所需扩展，要求，（可选扩展）（可选）>
The SA extension is sometimes used only for its SPI field. If all other fields MUST be ignored, this is represented by "SA(*)".
SA扩展有时仅用于其SPI字段。如果必须忽略所有其他字段，则用“SA（*）表示。
The lifetime extensions are represented with one to three letters after the word "lifetime," representing (H)ARD, (S)OFT, and (C)URRENT.
寿命延长用“寿命”一词后的一到三个字母表示，表示（H）ARD、（S）OFT和（C）Current。
The address extensions are represented with one to three letters after the word "address," representing (S)RC, (D)ST, (P)ROXY.
地址扩展名在“address”一词后用一到三个字母表示，表示（S）RC，（D）ST，（P）ROXY。
NOTE: Some security association types do not use a source address for SA identification, where others do. This may cause EEXIST errors for some SA types where others do not report collisions. It is expected that application authors know enough about the underlying security association types to understand these differences.
注意：某些安全关联类型不使用源地址进行SA标识，而其他类型则使用源地址进行SA标识。这可能会导致某些SA类型的EEXIST错误，而其他SA类型不会报告冲突。希望应用程序作者对底层安全关联类型有足够的了解，以理解这些差异。
The key extensions are represented with one or two letters after the word "key," representing (A)UTH and (E)NCRYPT.
密钥扩展名在单词“key”后用一个或两个字母表示，表示（A）UTH和（E）NCRYPT。
The identity extensions are represented with one or two letters after the word "identity," representing (S)RC and (D)ST.
标识扩展在单词“identity”后用一个或两个字母表示，表示（S）RC和（D）ST。
In the case of an error, only the base header is returned.
在发生错误的情况下，只返回基本标头。
Note that any standard error could be returned for any message.
请注意，任何消息都可能返回任何标准错误。
Typically, they will be either one of the errors specifically listed in the description for a message or one of the following:
通常，它们将是消息描述中特别列出的错误之一或以下错误之一：
EINVAL Various message improprieties, including SPI ranges that are malformed. ENOMEM Needed memory was not available. ENOBUFS Needed memory was not available. EMSGSIZ The message exceeds the maximum length allowed.
EINVAL各种消息错误，包括格式错误的SPI范围。ENOMEM所需的内存不可用。ENOBUFS所需的内存不可用。EMSGSIZ消息超出了允许的最大长度。
The SADB_GETSPI message allows a process to obtain a unique SPI value for given security association type, source address, and destination address. This message followed by an SADB_UPDATE is one way to create a security association (SADB_ADD is the other method). The process specifies the type in the base header, the source and destination address in address extension. If the SADB_GETSPI message is in response to a kernel-generated SADB_ACQUIRE, the sadb_msg_seq MUST be the same as the SADB_ACQUIRE message. The application may also specify the SPI. This is done by having the kernel select within a range of SPI values by using the SPI range extension. To specify a single SPI value to be verified, the application sets the high and low values to be equal. Permitting range specification is important because the kernel can allocate an SPI value based on what it knows about SPI values already in use. The kernel returns the same message with the allocated SPI value stored in the spi field of an association extension. The allocate SPI (and destination address) refer to a LARVAL security association. An SADB_UPDATE message can later be used to add an entry with the requested SPI value.
SADB_GETSPI消息允许进程获取给定安全关联类型、源地址和目标地址的唯一SPI值。此消息后跟SADB_更新是创建安全关联的一种方法（SADB_添加是另一种方法）。该进程在基头中指定类型，在地址扩展中指定源地址和目标地址。如果SADB_GETSPI消息响应内核生成的SADB_ACQUIRE，则SADB_msg_seq必须与SADB_ACQUIRE消息相同。应用程序还可以指定SPI。这是通过使用SPI范围扩展让内核在SPI值的范围内进行选择来实现的。要指定要验证的单个SPI值，应用程序将高值和低值设置为相等。允许范围规范是很重要的，因为内核可以根据对已经使用的SPI值的了解来分配SPI值。内核返回与存储在关联扩展的SPI字段中的分配SPI值相同的消息。allocate SPI（和目标地址）指的是一个幼体安全关联。SADB_更新消息稍后可用于添加具有请求的SPI值的条目。
It is recommended that associations that are created with SADB_GETSPI SHOULD be automatically deleted within a fixed amount of time if they are not updated by an SADB_UPDATE message. This allows SA storage not to get cluttered with larval associations.
建议使用SADB_GETSPI创建的关联如果没有通过SADB_更新消息进行更新，应在固定时间内自动删除。这使得SA存储不会因幼虫关联而变得杂乱无章。
The message behavior of the SADB_GETSPI message is:
SADB_GETSPI消息的消息行为为：
Send an SADB_GETSPI message from a user process to the kernel.
从用户进程向内核发送SADB_GETSPI消息。
<base, address, SPI range>
<基址、地址、SPI范围>
The kernel returns the SADB_GETSPI message to all listening processes.
内核将SADB_GETSPI消息返回给所有侦听进程。
<base, SA(*), address(SD)>
<base, SA(*), address(SD)>
Errors:
错误：
EEXIST Requested SPI or SPI range is not available or already used.
EEXIST请求的SPI或SPI范围不可用或已使用。
The SADB_UPDATE message allows a process to update the information in an existing Security Association. Since SADB_GETSPI does not allow setting of certain parameters, this message is needed to fully form the SADB_SASTATE_LARVAL security association created with SADB_GETSPI. The format of the update message is a base header, followed by an association header and possibly by several extension headers. The kernel searches for the security association with the same type, spi, source address and destination address specified in the message and updates the Security Association information using the content of the SADB_UPDATE message.
SADB_更新消息允许进程更新现有安全关联中的信息。由于SADB_GETSPI不允许设置某些参数，因此需要此消息来完全形成使用SADB_GETSPI创建的SADB_SASTATE_幼虫安全关联。更新消息的格式是一个基本头，后面是一个关联头，可能还有几个扩展头。内核使用消息中指定的相同类型、spi、源地址和目标地址搜索安全关联，并使用SADB_更新消息的内容更新安全关联信息。
The kernel MAY disallow SADB_UPDATE to succeed unless the message is issued from the same socket that created the security association. Such enforcement significantly reduces the chance of accidental changes to an in-use security association. Malicious trusted parties could still issue an SADB_FLUSH or SADB_DELETE message, but deletion of associations is more easily detected and less likely to occur accidentally than an erroneous SADB_UPDATE. The counter argument to supporting this behavior involves the case where a user-space key management application fails and is restarted. The new instance of the application will not have the same socket as the creator of the security association.
内核可能不允许SADB_更新成功，除非消息是从创建安全关联的同一套接字发出的。这样的强制执行大大减少了对正在使用的安全关联进行意外更改的机会。恶意的受信任方仍可能发出SADB_刷新或SADB_删除消息，但删除关联比错误的SADB_更新更容易被检测到，也不太可能意外发生。支持此行为的反论点涉及用户空间密钥管理应用程序失败并重新启动的情况。应用程序的新实例将不具有与安全关联的创建者相同的套接字。
The kernel MUST sanity check all significant values submitted in an SADB_UPDATE message before changing the SA in its database and MUST return EINVAL if any of the values are invalid. Examples of checks that should be performed are DES key parity bits, key length checking, checks for keys known to be weak for the specified algorithm, and checks for flags or parameters known to be incompatible with the specified algorithm.
在更改其数据库中的SA之前，内核必须检查SADB_更新消息中提交的所有重要值，如果任何值无效，则必须返回EINVAL。应执行的检查示例包括DES密钥奇偶校验位、密钥长度检查、检查指定算法中已知较弱的密钥，以及检查已知与指定算法不兼容的标志或参数。
Only SADB_SASTATE_MATURE SAs may be submitted in an SADB_UPDATE message. If the original SA is an SADB_SASTATE_LARVAL SA, then any value in the SA may be changed except for the source address, destination address, and SPI. If the original SA is an SADB_SASTATE_DEAD SA, any attempt to perform an SADB_UPDATE on the SA
SADB_更新消息中只能提交SADB_SASTATE_成熟SA。如果原始SA是SADB_SASTATE_幼虫SA，则SA中的任何值都可以更改，但源地址、目标地址和SPI除外。如果原始SA是SADB_SASTATE_DEAD SA，则任何对SA执行SADB_更新的尝试
MUST return EINVAL. It is not valid for established keying or algorithm information to change without the SPI changing, which would require creation of a new SA rather than a change to an existing SA. Once keying and algorithm information is negotiated, address and identity information is fixed for the SA. Therefore, if the original SA is an SADB_SASTATE_MATURE or DYING SA, only the sadb_sa_state field in the SA header and lifetimes (hard, soft, and current) may be changed and any attempt to change other values MUST result in an error return of EINVAL.
必须返回EINVAL。在SPI未更改的情况下更改已建立的密钥或算法信息是无效的，这将需要创建新SA，而不是更改现有SA。一旦协商了密钥和算法信息，SA的地址和身份信息就固定了。因此，如果原始SA是SADB_SASTATE_成熟或死亡SA，则只能更改SA标头中的SADB_SA_状态字段和生存时间（硬、软和当前），并且任何更改其他值的尝试都必须导致返回EINVAL错误。
The message behavior of the SADB_UPDATE message is:
SADB_更新消息的消息行为为：
Send an SADB_UPDATE message from a user process to the kernel.
从用户进程向内核发送SADB_更新消息。
<base, SA, (lifetime(HSC),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
<base, SA, (lifetime(HSC),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
The kernel returns the SADB_UPDATE message to all listening processes.
内核将SADB_更新消息返回给所有侦听进程。
<base, SA, (lifetime(HSC),) address(SD), (address(P),)
(identity(SD),) (sensitivity)>
<base, SA, (lifetime(HSC),) address(SD), (address(P),)
(identity(SD),) (sensitivity)>
The keying material is not returned on the message from the kernel to listening sockets because listeners might not have the privileges to see such keying material.
从内核到侦听套接字的消息中不会返回键控材料，因为侦听器可能没有查看此类键控材料的权限。
Errors: ESRCH The security association to be updated was not found. EINVAL In addition to other possible causes, this error is returned if sanity checking on the SA values (such as the keys) fails. EACCES Insufficient privilege to update entry. The socket issuing the SADB_UPDATE is not creator of the entry to be updated.
错误：找不到要更新的安全关联。EINVAL除了其他可能的原因外，如果SA值（如键）的健全性检查失败，将返回此错误。EACCES权限不足，无法更新条目。发出SADB_更新的套接字不是要更新的条目的创建者。
The SADB_ADD message is nearly identical to the SADB_UPDATE message, except that it does not require a previous call to SADB_GETSPI. The SADB_ADD message is used in manual keying applications, and in other cases where the uniqueness of the SPI is known immediately.
SADB_ADD消息与SADB_UPDATE消息几乎相同，只是它不需要先前调用SADB_GETSPI。SADB_ADD消息用于手动键控应用程序，以及其他可以立即知道SPI唯一性的情况。
An SADB_ADD message is also used when negotiation is finished, and the second of a pair of associations is added. The SPI for this association was determined by the peer machine. The sadb_msg_seq
协商完成时还使用SADB_添加消息，并添加一对关联中的第二个。此关联的SPI由对等计算机确定。sadb_msg_seq
MUST be set to the value set in a kernel-generated SADB_ACQUIRE so that both associations in a pair are bound to the same ACQUIRE request.
必须设置为内核生成的SADB_ACQUIRE中设置的值，以便一对中的两个关联都绑定到同一个ACQUIRE请求。
The kernel MUST sanity check all used fields in the SA submitted in an SADB_ADD message before adding the SA to its database and MUST return EINVAL if any of the values are invalid.
在将SA添加到其数据库之前，内核必须检查SADB_ADD消息中提交的SA中所有已使用的字段，如果任何值无效，则必须返回EINVAL。
Only SADB_SASTATE_MATURE SAs may be submitted in an SADB_ADD message. SADB_SASTATE_LARVAL SAs are created by SADB_GETSPI and it is not sensible to add a new SA in the DYING or SADB_SASTATE_DEAD state. Therefore, the sadb_sa_state field of all submitted SAs MUST be SADB_SASTATE_MATURE and the kernel MUST return an error if this is not true.
只有SADB_SASTATE_成熟SA可以在SADB_添加消息中提交。SADB_SASTATE_幼虫SA由SADB_GETSPI创建，在死亡或SADB_SASTATE_死亡状态下添加新SA是不明智的。因此，所有提交的sa的sadb_sa_状态字段必须是sadb_SASTATE_成熟，如果不是这样，内核必须返回一个错误。
The message behavior of the SADB_ADD message is:
SADB_添加消息的消息行为为：
Send an SADB_ADD message from a user process to the kernel.
从用户进程向内核发送SADB_添加消息。
<base, SA, (lifetime(HS),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
<base, SA, (lifetime(HS),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
The kernel returns the SADB_ADD message to all listening processes.
内核将SADB_ADD消息返回给所有侦听进程。
<base, SA, (lifetime(HS),) address(SD), (identity(SD),)
(sensitivity)>
<base, SA, (lifetime(HS),) address(SD), (identity(SD),)
(sensitivity)>
The keying material is not returned on the message from the kernel to listening sockets because listeners may not have the privileges to see such keying material.
从内核到侦听套接字的消息中不会返回键控材料，因为侦听器可能没有查看此类键控材料的权限。
Errors:
错误：
EEXIST The security association that was to be added already exists. EINVAL In addition to other possible causes, this error is returned if sanity checking on the SA values (such as the keys) fails.
EEXIST要添加的安全关联已存在。EINVAL除了其他可能的原因外，如果SA值（如键）的健全性检查失败，将返回此错误。
The SADB_DELETE message causes the kernel to delete a Security Association from the key table. The delete message consists of the base header followed by the association, and the source and destination sockaddrs in the address extension. The kernel deletes the security association matching the type, spi, source address, and destination address in the message.
SADB_DELETE消息导致内核从密钥表中删除安全关联。delete消息包含后跟关联的基本头，以及地址扩展中的源和目标sockaddr。内核删除与消息中的类型、spi、源地址和目标地址匹配的安全关联。
The message behavior for SADB_DELETE is as follows:
SADB_DELETE的消息行为如下：
Send an SADB_DELETE message from a user process to the kernel.
从用户进程向内核发送SADB_DELETE消息。
<base, SA(*), address(SD)>
<base, SA(*), address(SD)>
The kernel returns the SADB_DELETE message to all listening processes.
内核将SADB_DELETE消息返回给所有侦听进程。
<base, SA(*), address(SD)>
<base, SA(*), address(SD)>
The SADB_GET message allows a process to retrieve a copy of a Security Association from the kernel's key table. The get message consists of the base header follows by the relevant extension fields. The Security Association matching the type, spi, source address, and destination address is returned.
SADB_GET消息允许进程从内核的密钥表中检索安全关联的副本。get消息由基本头和相关扩展字段组成。将返回与类型、spi、源地址和目标地址匹配的安全关联。
The message behavior of the SADB_GET message is:
SADB_GET消息的消息行为为：
Send an SADB_GET message from a user process to the kernel.
从用户进程向内核发送SADB_GET消息。
<base, SA(*), address(SD)>
<base, SA(*), address(SD)>
The kernel returns the SADB_GET message to the socket that sent the SADB_GET message.
内核将SADB_GET消息返回给发送SADB_GET消息的套接字。
<base, SA, (lifetime(HSC),) address(SD), (address(P),) key(AE),
(identity(SD),) (sensitivity)>
<base, SA, (lifetime(HSC),) address(SD), (address(P),) key(AE),
(identity(SD),) (sensitivity)>
Errors: ESRCH The sought security association was not found.
错误：找不到所寻求的安全关联。
The SADB_ACQUIRE message is typically sent only by the kernel to key socket listeners who have registered their key socket (see SADB_REGISTER message). SADB_ACQUIRE messages can be sent by application-level consumers of security associations (such as an OSPFv2 implementation that uses OSPF security). The SADB_ACQUIRE message is a base header along with an address extension, possibly an identity extension, and a proposal extension. The proposed situation contains a list of desirable algorithms that can be used if the algorithms in the base header are not available. The values for the fields in the base header and in the security association data which follows the base header indicate the properties of the Security Association that the listening process should attempt to acquire. If
SADB_ACQUIRE消息通常仅由内核发送给已注册密钥套接字的密钥套接字侦听器（请参阅SADB_REGISTER消息）。SADB_ACQUIRE消息可以由安全关联（例如使用OSPF安全性的OSPFv2实现）的应用程序级使用者发送。SADB_ACQUIRE消息是一个基本头，带有地址扩展、可能的标识扩展和建议扩展。提议的情况包含一个理想算法列表，如果基本报头中的算法不可用，则可以使用这些算法。基本标头中的字段值和基本标头后面的安全关联数据中的字段值指示侦听进程应尝试获取的安全关联的属性。如果
the message originates from the kernel (i.e. the sadb_msg_pid is 0), the sadb_msg_seq number MUST be used by a subsequent SADB_GETSPI and SADB_UPDATE, or subsequent SADB_ADD message to bind a security association to the request. This avoids the race condition of two TCP connections between two IP hosts that each require unique associations, and having one steal another's security association. The sadb_msg_errno and sadb_msg_state fields should be ignored by the listening process.
消息源于内核（即sadb_msg_pid为0），后续sadb_GETSPI和sadb_UPDATE或后续sadb_ADD消息必须使用sadb_msg_seq编号将安全关联绑定到请求。这避免了两个IP主机之间的两个TCP连接的竞争条件，每个IP主机都需要唯一的关联，并且一个主机窃取另一个主机的安全关联。侦听过程应忽略sadb_msg_errno和sadb_msg_state字段。
The SADB_ACQUIRE message is typically triggered by an outbound packet that needs security but for which there is no applicable Security Association existing in the key table. If the packet can be sufficiently protected by more than one algorithm or combination of options, the SADB_ACQUIRE message MUST order the preference of possibilities in the Proposal extension.
SADB_ACQUIRE消息通常由需要安全性但密钥表中不存在适用安全关联的出站数据包触发。如果数据包可以通过一个以上的算法或选项组合得到充分保护，则SADB_ACQUIRE消息必须在建议扩展中对可能性的偏好进行排序。
There are three messaging behaviors for SADB_ACQUIRE. The first is where the kernel needs a security association (e.g. for IPsec).
SADB_ACQUIRE有三种消息传递行为。第一个是内核需要安全关联的地方（例如，对于IPsec）。
The kernel sends an SADB_ACQUIRE message to registered sockets.
内核向注册的套接字发送SADB_ACQUIRE消息。
<base, address(SD), (address(P)), (identity(SD),) (sensitivity,)
proposal>
<base, address(SD), (address(P)), (identity(SD),) (sensitivity,)
proposal>
NOTE: The address(SD) extensions MUST have the port fields filled in with the port numbers of the session requiring keys if appropriate.
注意：地址（SD）扩展必须在端口字段中填入需要密钥的会话的端口号（如果适用）。
The second is when, for some reason, key management fails, it can send an ACQUIRE message with the same sadb_msg_seq as the initial ACQUIRE with a non-zero errno.
第二种情况是，由于某种原因，密钥管理失败时，它可以发送一条ACQUE消息，该消息的sadb_msg_seq与具有非零错误号的初始ACQUE消息的sadb_msg_seq相同。
Send an SADB_ACQUIRE to indicate key management failure.
发送SADB_ACQUIRE以指示密钥管理失败。
<base>
<base>
The third is where an application-layer consumer of security associations (e.g. an OSPFv2 or RIPv2 daemon) needs a security association.
第三种情况是，安全关联的应用层使用者（例如，OSPFv2或RIPv2守护进程）需要安全关联。
Send an SADB_ACQUIRE message from a user process to the kernel.
从用户进程向内核发送SADB_ACQUIRE消息。
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
The kernel returns an SADB_ACQUIRE message to registered sockets.
内核将SADB_ACQUIRE消息返回给注册的套接字。
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
<base, address(SD), (address(P),) (identity(SD),) (sensitivity,)
proposal>
The user-level consumer waits for an SADB_UPDATE or SADB_ADD message for its particular type, and then can use that association by using SADB_GET messages.
用户级使用者等待其特定类型的SADB_更新或SADB_添加消息，然后可以使用SADB_GET消息使用该关联。
Errors: EINVAL Invalid acquire request. EPROTONOSUPPORT No KM application has registered with the Key Engine as being able to obtain the requested SA type, so the requested SA cannot be acquired.
错误：EINVAL无效的获取请求。EPROTONOSUPPORT没有KM应用程序在密钥引擎中注册为能够获取请求的SA类型，因此无法获取请求的SA。
The SADB_REGISTER message allows an application to register its key socket as able to acquire new security associations for the kernel. SADB_REGISTER allows a socket to receive SADB_ACQUIRE messages for the type of security association specified in sadb_msg_satype. The application specifies the type of security association that it can acquire for the kernel in the type field of its register message. If an application can acquire multiple types of security association, it MUST register each type in a separate message. Only the base header is needed for the register message. Key management applications MAY register for a type not known to the kernel, because the consumer may be in user-space (e.g. OSPFv2 security).
SADB_REGISTER消息允许应用程序注册其密钥套接字，以获取内核的新安全关联。SADB_寄存器允许套接字接收SADB_msg_satype中指定的安全关联类型的SADB_ACQUIRE消息。应用程序在其寄存器消息的type字段中指定可以为内核获取的安全关联类型。如果应用程序可以获取多种类型的安全关联，则必须在单独的消息中注册每种类型。寄存器消息只需要基本头。密钥管理应用程序可能注册内核未知的类型，因为使用者可能在用户空间（例如OSPFv2安全性）。
The reply of the SADB_REGISTER message contains a supported algorithm extension. That field contains an array of supported algorithms, one per octet. This allows key management applications to know what algorithm are supported by the kernel.
SADB_寄存器消息的回复包含受支持的算法扩展。该字段包含一组受支持的算法，每八位字节一个。这允许密钥管理应用程序知道内核支持什么算法。
In an environment where algorithms can be dynamically loaded and unloaded, an asynchronous SADB_REGISTER reply MAY be generated. The list of supported algorithms MUST be a complete list, so the application can make note of omissions or additions.
在可以动态加载和卸载算法的环境中，可以生成异步SADB_寄存器应答。支持的算法列表必须是一个完整的列表，因此应用程序可以记录遗漏或添加。
The messaging behavior of the SADB_REGISTER message is:
SADB_寄存器消息的消息传递行为为：
Send an SADB_REGISTER message from a user process to the kernel.
从用户进程向内核发送SADB_寄存器消息。
<base>
<base>
The kernel returns an SADB_REGISTER message to registered sockets, with algorithm types supported by the kernel being indicated in the supported algorithms field.
内核向注册的套接字返回SADB_寄存器消息，在supported algorithms（支持的算法）字段中指示内核支持的算法类型。
NOTE: This message may arrive asynchronously due to an algorithm being loaded or unloaded into a dynamically linked kernel.
注意：由于算法被加载或卸载到动态链接的内核中，此消息可能会异步到达。
<base, supported>
<base，受支持>
The operating system kernel is responsible for tracking SA expirations for security protocols that are implemented inside the kernel. If the soft limit or hard limit of a Security Association has expired for a security protocol implemented inside the kernel, then the kernel MUST issue an SADB_EXPIRE message to all key socket listeners. If the soft limit or hard limit of a Security Association for a user-level security protocol has expired, the user-level protocol SHOULD issue an SADB_EXPIRE message.
操作系统内核负责跟踪内核内部实现的安全协议的SA过期。如果内核内部实现的安全协议的安全关联的软限制或硬限制已过期，那么内核必须向所有密钥套接字侦听器发出SADB_EXPIRE消息。如果用户级安全协议的安全关联的软限制或硬限制已过期，则用户级协议应发出SADB_EXPIRE消息。
The base header will contain the security association information followed by the source sockaddr, destination sockaddr, (and, if present, internal sockaddr,) (and, if present, one or both compartment bitmaps).
基本标头将包含安全关联信息，后跟源sockaddr、目标sockaddr（以及，如果存在，则为内部sockaddr），（如果存在，则为一个或两个隔间位图）。
The lifetime extension of an SADB_EXPIRE message is important to indicate which lifetime expired. If a HARD lifetime extension is included, it indicates that the HARD lifetime expired. This means the association MAY be deleted already from the SADB. If a SOFT lifetime extension is included, it indicates that the SOFT lifetime expired. The CURRENT lifetime extension will indicate the current status, and comparisons to the HARD or SOFT lifetime will indicate which limit was reached. HARD lifetimes MUST take precedence over SOFT lifetimes, meaning if the HARD and SOFT lifetimes are the same, the HARD lifetime will appear on the EXPIRE message. The pathological case of HARD lifetimes being shorter than SOFT lifetimes is handled such that the SOFT lifetime will never expire.
SADB_EXPIRE消息的生存期延长对于指示哪个生存期已过期很重要。如果包含硬生存期扩展，则表示硬生存期已过期。这意味着该关联可能已从SADB中删除。如果包含软生存期延长，则表示软生存期已过期。当前生存期延长将指示当前状态，与硬生存期或软生存期的比较将指示达到了哪个限制。硬生命周期必须优先于软生命周期，这意味着如果硬生命周期和软生命周期相同，则硬生命周期将出现在EXPIRE消息上。处理硬寿命短于软寿命的病态情况，使软寿命永远不会过期。
The messaging behavior of the SADB_EXPIRE message is:
SADB_EXPIRE消息的消息传递行为为：
The kernel sends an SADB_EXPIRE message to all listeners when the soft limit of a security association has been expired.
当安全关联的软限制过期时，内核向所有侦听器发送一条SADB_EXPIRE消息。
<base, SA, lifetime(C and one of HS), address(SD)>
<base, SA, lifetime(C and one of HS), address(SD)>
Note that the SADB_EXPIRE message is ONLY sent by the kernel to the KMd. It is a one-way informational message that does not have a reply.
注意，SADB_EXPIRE消息仅由内核发送到KMd。这是一条没有回复的单向信息性消息。
The SADB_FLUSH message causes the kernel to delete all entries in its key table for a certain sadb_msg_satype. Only the base header is required for a flush message. If sadb_msg_satype is filled in with a specific value, only associations of that type are deleted. If it is filled in with SADB_SATYPE_UNSPEC, ALL associations are deleted.
SADB_FLUSH消息会导致内核删除其密钥表中特定SADB_msg_satype的所有条目。刷新消息只需要基本标头。如果用特定值填充sadb_msg_satype，则仅删除该类型的关联。如果用SADB_SATYPE_unsec填写，则删除所有关联。
The messaging behavior for SADB_FLUSH is:
SADB_刷新的消息传递行为为：
Send an SADB_FLUSH message from a user process to the kernel.
从用户进程向内核发送SADB_FLUSH消息。
<base>
<base>
The kernel will return an SADB_FLUSH message to all listening sockets.
内核将向所有侦听套接字返回SADB_FLUSH消息。
<base>
<base>
The reply message happens only after the actual flushing of security associations has been attempted.
只有在尝试实际刷新安全关联之后，才会出现回复消息。
The SADB_DUMP message causes the kernel to dump the operating system's entire Key Table to the requesting key socket. As in SADB_FLUSH, if a sadb_msg_satype value is in the message, only associations of that type will be dumped. If SADB_SATYPE_UNSPEC is specified, all associations will be dumped. Each Security Association is returned in its own SADB_DUMP message. A SADB_DUMP message with a sadb_seq field of zero indicates the end of the dump transaction. The dump message is used for debugging purposes only and is not intended for production use.
SADB_DUMP消息导致内核将操作系统的整个密钥表转储到请求密钥套接字。与SADB_FLUSH中一样，如果消息中有SADB_msg_satype值，则仅转储该类型的关联。如果指定了SADB_SATYPE_unsec，则将转储所有关联。每个安全关联在其自己的SADB_转储消息中返回。SADB_转储消息的SADB_seq字段为零表示转储事务结束。转储消息仅用于调试目的，不用于生产用途。
Support for the dump message MAY be discontinued in future versions of PF_KEY. Key management applications MUST NOT depend on this message for basic operation.
在未来版本的PF_密钥中，可能会停止对转储消息的支持。密钥管理应用程序不得依赖此消息进行基本操作。
The messaging behavior for SADB_DUMP is:
SADB_转储的消息传递行为为：
Send an SADB_DUMP message from a user process to the kernel.
从用户进程向内核发送SADB_转储消息。
<base>
<base>
Several SADB_DUMP messages will return from the kernel to the sending socket.
几个SADB_转储消息将从内核返回到发送套接字。
<base, SA, (lifetime (HSC),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
<base, SA, (lifetime (HSC),) address(SD), (address(P),)
key(AE), (identity(SD),) (sensitivity)>
The Security Association's flags are a bitmask field. These flags also appear in a combination that is part of a PROPOSAL extension. The related symbolic definitions below should be used in order that applications will be portable:
安全关联的标志是位掩码字段。这些标志也以提案扩展的一部分的组合形式出现。应使用以下相关符号定义，以便应用程序可移植：
#define SADB_SAFLAGS_PFS 1 /* perfect forward secrecy */
#define SADB_SAFLAGS_PFS 1 /* perfect forward secrecy */
The SADB_SAFLAGS_PFS flag indicates to key management that this association should have perfect forward secrecy in its key. (In other words, any given session key cannot be determined by cryptanalysis of previous session keys or some master key.)
SADB_-SAFLAGS_-PFS标志向密钥管理表明，该关联在其密钥中应该具有完美的前向保密性。（换句话说，任何给定的会话密钥都不能通过对以前的会话密钥或某些主密钥进行密码分析来确定。）
The security association state field is an integer that describes the states of a security association. They are:
安全关联状态字段是描述安全关联状态的整数。他们是：
#define SADB_SASTATE_LARVAL 0 #define SADB_SASTATE_MATURE 1 #define SADB_SASTATE_DYING 2 #define SADB_SASTATE_DEAD 3
#定义SADB_SASTATE_幼虫0#定义SADB_SASTATE_成熟1#定义SADB_SASTATE_死亡2#定义SADB_SASTATE_死亡3
#define SADB_SASTATE_MAX 3
#定义SADB_SASTATE_MAX 3
A SADB_SASTATE_LARVAL security association is one that was created by the SADB_GETSPI message. A SADB_SASTATE_MATURE association is one that was updated with the SADB_UPDATE message or added with the SADB_ADD message. A DYING association is one whose soft lifetime has expired. A SADB_SASTATE_DEAD association is one whose hard lifetime has expired, but hasn't been reaped by system garbage collection. If a consumer of security associations has to extend an association beyond its normal lifetime (e.g. OSPF Security) it MUST only set the soft lifetime for an association.
SADB_SASTATE_幼虫安全关联是由SADB_GETSPI消息创建的关联。SADB_SASTATE_成熟关联是使用SADB_更新消息更新或添加SADB_添加消息的关联。垂死的社团是指软生命期已过的社团。SADB_SASTATE_DEAD关联是一个其艰难生存期已过期，但尚未通过系统垃圾收集获得的关联。如果安全关联的使用者必须将关联扩展到其正常生存期之外（例如OSPF安全），则必须仅为关联设置软生存期。
This defines the type of Security Association in this message. The symbolic names are always the same, even on different implementations. Applications SHOULD use the symbolic name in order to have maximum portability across different implementations. These are defined in the file <net/pfkeyv2.h>.
这定义了此消息中安全关联的类型。符号名称总是相同的，即使在不同的实现上也是如此。应用程序应该使用符号名，以便在不同的实现之间具有最大的可移植性。这些在文件<net/pfkeyv2.h>中定义。
#define SADB_SATYPE_UNSPEC 0
#定义SADB_SATYPE_UNSPEC 0
#define SADB_SATYPE_AH 2 /* RFC-1826 */
#define SADB_SATYPE_ESP 3 /* RFC-1827 */
#define SADB_SATYPE_AH 2 /* RFC-1826 */
#define SADB_SATYPE_ESP 3 /* RFC-1827 */
#define SADB_SATYPE_RSVP 5 /* RSVP Authentication */
#define SADB_SATYPE_OSPFV2 6 /* OSPFv2 Authentication */
#define SADB_SATYPE_RIPV2 7 /* RIPv2 Authentication */
#define SADB_SATYPE_MIP 8 /* Mobile IP Auth. */
#define SADB_SATYPE_RSVP 5 /* RSVP Authentication */
#define SADB_SATYPE_OSPFV2 6 /* OSPFv2 Authentication */
#define SADB_SATYPE_RIPV2 7 /* RIPv2 Authentication */
#define SADB_SATYPE_MIP 8 /* Mobile IP Auth. */
#define SADB_SATYPE_MAX 8
#定义SADB_SATYPE_MAX 8
SADB_SATYPE_UNSPEC is defined for completeness and means no specific type of security association. This type is never used with PF_KEY SAs.
SADB_SATYPE_UNSPEC是为完整性而定义的，表示没有特定类型的安全关联。此类型从不与PF_键SAs一起使用。
SADB_SATYPE_AH is for the IP Authentication Header [Atk95b].
SADB_SATYPE_AH用于IP身份验证头[Atk95b]。
SADB_SATYPE_ESP is for the IP Encapsulating Security Payload [Atk95c].
SADB_SATYPE_ESP用于IP封装安全负载[Atk95c]。
SADB_SATYPE_RSVP is for the RSVP Integrity Object.
SADB_SATYPE_RSVP用于RSVP完整性对象。
SADB_SATYPE_OSPFV2 is for OSPFv2 Cryptographic authentication [Moy98].
SADB_SATYPE_OSPFV2用于OSPFV2加密身份验证[Moy98]。
SADB_SATYPE_RIPV2 is for RIPv2 Cryptographic authentication [BA97].
SADB_SATYPE_RIPV2用于RIPV2加密身份验证[BA97]。
SADB_SATYPE_MIP is for Mobile IP's authentication extensions [Per97].
SADB_SATYPE_MIP用于移动IP的身份验证扩展[Per97]。
SADB_SATYPE_MAX is always set to the highest valid numeric value.
SADB_SATYPE_MAX始终设置为最高有效数值。
The algorithm type is interpreted in the context of the Security Association type defined above. The numeric value might vary between implementations, but the symbolic name MUST NOT vary between implementations. Applications should use the symbolic name in order to have maximum portability to various implementations.
算法类型在上面定义的安全关联类型的上下文中进行解释。数值可能因实现而异，但符号名称不得因实现而异。应用程序应该使用符号名，以便对各种实现具有最大的可移植性。
Some of the algorithm types defined below might not be standardized or might be deprecated in the future. To obtain an assignment for a symbolic name, contact the authors.
下面定义的某些算法类型可能没有标准化，或者将来可能会被弃用。要获得符号名称的分配，请与作者联系。
The symbols below are defined in <net/pfkeyv2.h>.
以下符号在<net/pfkeyv2.h>中定义。
/* Authentication algorithms */
#define SADB_AALG_NONE 0
#define SADB_AALG_MD5HMAC 2
#define SADB_AALG_SHA1HMAC 3
#define SADB_AALG_MAX 3
/* Authentication algorithms */
#define SADB_AALG_NONE 0
#define SADB_AALG_MD5HMAC 2
#define SADB_AALG_SHA1HMAC 3
#define SADB_AALG_MAX 3
/* Encryption algorithms */
#define SADB_EALG_NONE 0
#define SADB_EALG_DESCBC 2
#define SADB_EALG_3DESCBC 3
#define SADB_EALG_NULL 11
#define SADB_EALG_MAX 11
/* Encryption algorithms */
#define SADB_EALG_NONE 0
#define SADB_EALG_DESCBC 2
#define SADB_EALG_3DESCBC 3
#define SADB_EALG_NULL 11
#define SADB_EALG_MAX 11
The algorithm for SADB_AALG_MD5_HMAC is defined in [MG98a]. The algorithm for SADB_AALG_SHA1HMAC is defined in [MG98b]. The algorithm for SADB_EALG_DESCBC is defined in [MD98]. SADB_EALG_NULL is the NULL encryption algorithm, defined in [GK98]. The SADB_EALG_NONE value is not to be used in any security association except those which have no possible encryption algorithm in them (e.g. IPsec AH).
SADB_AALG_MD5_HMAC的算法在[MG98a]中定义。SADB_AALG_SHA1HMAC的算法在[MG98b]中定义。SADB_EALG_DESCBC的算法在[MD98]中定义。SADB_EALG_NULL是[GK98]中定义的空加密算法。SADB_EALG_NONE值不得用于任何安全关联中，除非其中没有可能的加密算法（例如IPsec AH）。
To briefly recap the extension header values:
要简要回顾扩展标题值，请执行以下操作：
#define SADB_EXT_RESERVED 0 #define SADB_EXT_SA 1 #define SADB_EXT_LIFETIME_CURRENT 2 #define SADB_EXT_LIFETIME_HARD 3 #define SADB_EXT_LIFETIME_SOFT 4 #define SADB_EXT_ADDRESS_SRC 5 #define SADB_EXT_ADDRESS_DST 6 #define SADB_EXT_ADDRESS_PROXY 7 #define SADB_EXT_KEY_AUTH 8 #define SADB_EXT_KEY_ENCRYPT 9 #define SADB_EXT_IDENTITY_SRC 10 #define SADB_EXT_IDENTITY_DST 11 #define SADB_EXT_SENSITIVITY 12 #define SADB_EXT_PROPOSAL 13 #define SADB_EXT_SUPPORTED_AUTH 14 #define SADB_EXT_SUPPORTED_ENCRYPT 15 #define SADB_EXT_SPIRANGE 16
#定义SAD B（U）单词单词的定义，定义，定义，定义，定义，定义，定义，定义，定义，定义。定义，定义，定义，定义，定义，目前2，定义，定义，定义，定义，定义。定义，定义，定义，定义，定义，B（U）单词单词单词单词单词单词（U）单词单词单词，定义，定义，定义，定义，定义，定义，定义，定义，定义，定义，B（U）单词单词（U）单词单词单词，单词单词，单词单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，_EXT_IDENTITY_SRC 10#定义SADB#u EXT#u IDENTITY#定义SADB#u EXT#u敏感度12#定义SADB#u EXT#u提案13#定义支持的SADB#u EXT#u AUTH 14#定义支持的SADB#u EXT u加密15#定义SADB#u EXT u SPIRANGE 16
#define SADB_EXT_MAX 16
#定义SADB_EXT_MAX 16
Each identity can have a certain type.
每个标识都可以有特定的类型。
#define SADB_IDENTTYPE_RESERVED 0 #define SADB_IDENTTYPE_PREFIX 1 #define SADB_IDENTTYPE_FQDN 2 #define SADB_IDENTTYPE_USERFQDN 3
#定义SADB_标识类型_保留0#定义SADB_标识类型_前缀1#定义SADB_标识类型_FQDN 2#定义SADB_标识类型_用户FQDN 3
#define SADB_IDENTTYPE_MAX 3
#定义SADB_identitype_MAX 3
The PREFIX identity string consists of a network address followed by a forward slash and a prefix length. The network address is in a printable numeric form appropriate for the protocol family. The prefix length is a decimal number greater than or equal to zero and less than the number of bits in the network address. It indicates the number of bits in the network address that are significant; all bits in the network address that are not significant MUST be set to zero. Note that implementations MUST parse the contents of the printable address into a binary form for comparison purposes because multiple printable strings are valid representations of the same address in many protocol families (for example, some allow leading zeros and some have letters that are case insensitive). Examples of PREFIX identities are "199.33.248.64/27" and "3ffe::1/128". If the source or destination identity is a PREFIX identity, the source or destination address for the SA (respectively) MUST be within that prefix. The sadb_ident_id field is zeroed for these identity types.
前缀标识字符串由网络地址、正斜杠和前缀长度组成。网络地址采用适合于协议系列的可打印数字形式。前缀长度是大于或等于零且小于网络地址中位数的十进制数。它表示网络地址中有效的位数；网络地址中所有不重要的位必须设置为零。请注意，为了便于比较，实现必须将可打印地址的内容解析为二进制形式，因为在许多协议族中，多个可打印字符串是同一地址的有效表示形式（例如，有些允许前导零，有些具有不区分大小写的字母）。前缀标识的示例有“199.33.248.64/27”和“3ffe:：1/128”。如果源或目标标识是前缀标识，则SA的源或目标地址（分别）必须在该前缀内。对于这些标识类型，sadb_ident_id字段为零。
The FQDN identity string contains a fully qualified domain name. An example FQDN identity is "ministry-of-truth.inner.net". The sadb_ident_id field is zeroed for these identity types.
FQDN标识字符串包含完全限定的域名。FQDN标识的一个示例是“真理部.inner.net”。对于这些标识类型，sadb_ident_id字段为零。
The UserFQDN identity consists of a text string in the format commonly used for Internet-standard electronic mail. The syntax is the text username, followed by the "@" character, followed in turn by the appropriate fully qualified domain name. This identity specifies both a username and an associated FQDN. There is no requirement that this string specify a mailbox valid for SMTP or other electronic mail use. This identity is useful with protocols supporting user-oriented keying. It is a convenient identity form because the DNS Security extensions can be used to distribute signed public key values by associating KEY and SIG records with an appropriate MB DNS record. An example UserFQDN identity is "julia@ministry-of-love.inner.net". The sadb_ident_id field is used to contain a POSIX user id in the absence of an identity string itself so that a user-level application can use the getpwuid{,_r}() routine to obtain a textual user login id. If a string is present, it SHOULD match the numeric value in the sadb_ident_id field. If it does not match, the string SHOULD override
UserFQDN标识由一个文本字符串组成，其格式通常用于Internet标准电子邮件。语法是文本用户名，后跟“@”字符，然后是相应的完全限定域名。此标识指定用户名和关联的FQDN。不要求此字符串指定可供SMTP或其他电子邮件使用的有效邮箱。此标识对于支持面向用户的键控的协议非常有用。它是一种方便的标识形式，因为DNS安全扩展可用于通过将密钥和SIG记录与适当的MB DNS记录关联来分发签名公钥值。UserFQDN标识的一个示例是“julia@ministry-《爱的力量》，内心网。sadb_ident_id字段用于在没有标识字符串的情况下包含POSIX用户id，以便用户级应用程序可以使用getpwuid{，_r}（）例程获取文本用户登录id。如果存在字符串，则该字符串应与sadb_ident_id字段中的数值相匹配。如果不匹配，则字符串应重写
the numeric value.
数值。
The only field currently defined in the sensitivity extension is the sadb_sens_dpd, which represents the data protection domain. The other data in the sensitivity extension is based off the sadb_sens_dpd value.
灵敏度扩展中当前定义的唯一字段是sadb_sens_dpd，它表示数据保护域。灵敏度扩展中的其他数据基于sadb_sens_dpd值。
The DP/DOI is defined to be the same as the "Labeled Domain Identifier Value" of the IP Security DOI specification [Pip98]. As noted in that specification, values in the range 0x80000000 to 0xffffffff (inclusive) are reserved for private use and values in the range 0x00000001 through 0x7fffffff are assigned by IANA. The all-zeros DP/DOI value is permanently reserved to mean that "no DP/DOI is in use".
DP/DOI定义为与IP安全DOI规范[Pip98]的“标记域标识符值”相同。如该规范所述，0x8000000到0xffffffff（含）范围内的值保留供私人使用，0x00000001到0x7fffffff范围内的值由IANA分配。全零DP/DOI值永久保留，表示“没有使用DP/DOI”。
These are already mentioned in the Algorithm Types and Security Association Flags sections.
这些已经在算法类型和安全关联标志部分中提到。
4 Future Directions
四个未来方向
While the current specification for the Sensitivity and Integrity Labels is believed to be general enough, if a case should arise that can't work with the current specification then this might cause a change in a future version of PF_KEY.
虽然灵敏度和完整性标签的当前规范被认为是足够通用的，但如果出现无法使用当前规范的情况，则这可能会导致PF_密钥的未来版本发生变化。
Similarly, PF_KEY might need extensions to work with other kinds of Security Associations in future. It is strongly desirable for such extensions to be made in a backwards-compatible manner should they be needed.
类似地，PF_密钥将来可能需要扩展才能与其他类型的安全关联一起工作。如果需要这种扩展，最好以向后兼容的方式进行。
When more experience is gained with certificate management, it is possible that the IDENTITY extension will have to be revisited to allow a finer grained selection of certificate identities.
当在证书管理方面获得更多经验时，可能必须重新访问标识扩展，以允许更细粒度地选择证书标识。
The following examples illustrate how PF_KEY is used. The first example is an IP Security example, where the consumer of the security associations is inside an operating system kernel. The second example is an OSPF Security example, which illustrates a user-level consumer of security associations. The third example covers things not mentioned by the first two examples. A real system may closely conform to one of these examples, or take parts of them. These examples are purely illustrative, and are not intended to mandate a
以下示例说明如何使用PF_键。第一个示例是IP安全示例，其中安全关联的使用者位于操作系统内核内。第二个示例是OSPF安全示例，它说明了安全关联的用户级使用者。第三个例子包括前两个例子没有提到的东西。一个真正的系统可能与这些例子中的一个非常相似，或者是其中的一部分。这些例子纯粹是说明性的，并不是为了强制要求
particular implementation method.
具体实现方法。
+---------------+ +-------------+
|Key Mgmt Daemon| | Application |
+---------------+ +-------------+
| | /
| | /
| | | Applications
======[PF_KEY]====[PF_INET]==========================
| | | OS Kernel
+------------+ +-----------------+
| Key Engine | | TCP/IP, |
| or SADB |---| including IPsec |
+------------+ | |
+-----------------+
+---------------+ +-------------+
|Key Mgmt Daemon| | Application |
+---------------+ +-------------+
| | /
| | /
| | | Applications
======[PF_KEY]====[PF_INET]==========================
| | | OS Kernel
+------------+ +-----------------+
| Key Engine | | TCP/IP, |
| or SADB |---| including IPsec |
+------------+ | |
+-----------------+
When the Key Management daemon (KMd) begins. It must tell PF_KEY that it is willing to accept message for the two IPsec services, AH and ESP. It does this by sending down two SADB_REGISTER messages.
当密钥管理守护程序（KMd）开始时。它必须告诉PF_KEY它愿意接受两个IPsec服务的消息，AH和ESP。它通过发送两个SADB_寄存器消息来实现这一点。
KMd->Kernel: SADB_REGISTER for ESP
Kernel->Registered: SADB_REGISTER for ESP, Supported Algorithms
KMd->Kernel: SADB_REGISTER for AH
Kernel->Registered: SADB_REGISTER for AH, Supported Algorithms
KMd->Kernel: SADB_REGISTER for ESP
Kernel->Registered: SADB_REGISTER for ESP, Supported Algorithms
KMd->Kernel: SADB_REGISTER for AH
Kernel->Registered: SADB_REGISTER for AH, Supported Algorithms
Each REGISTER message will cause a reply to go to all PF_KEY sockets registered for ESP and AH respectively (including the requester).
每个注册消息将导致回复分别发送到为ESP和AH注册的所有PF_密钥套接字（包括请求者）。
Assume that no security associations currently exist for IPsec to use. Consider when a network application begins transmitting data (e.g. a TCP SYN). Because of policy, or the application's request, the kernel IPsec module needs an AH security association for this data. Since there is not one present, the following message is generated:
假定当前不存在可供IPsec使用的安全关联。考虑网络应用程序何时开始传输数据（例如TCP SYN）。由于策略或应用程序的请求，内核IPsec模块需要此数据的AH安全关联。由于没有一个存在，因此生成以下消息：
Kernel->Registered: SADB_ACQUIRE for AH, addrs, ID, sens, proposals
内核->注册：SADB_获取AH、地址、ID、传感器、建议
The KMd reads the ACQUIRE message, especially the sadb_msg_seq number. Before it begins the negotiation, it sends down an SADB_GETSPI message with the sadb_msg_seq number equal to the one received in the ACQUIRE. The kernel returns the results of the GETSPI to all listening sockets.
KMd读取获取消息，尤其是sadb_msg_seq编号。在开始协商之前，它发送一条SADB_GETSPI消息，SADB_msg_seq编号等于在ACQUIRE中接收到的编号。内核将GETSPI的结果返回给所有侦听套接字。
KMd->Kernel: SADB_GETSPI for AH, addr, SPI range
Kernel->All: SADB_GETSPI for AH, assoc, addrs
KMd->Kernel: SADB_GETSPI for AH, addr, SPI range
Kernel->All: SADB_GETSPI for AH, assoc, addrs
The KMd may perform a second GETSPI operation if it needs both directions of IPsec SPI values. Now that the KMd has an SPI for at least one of the security associations, it begins negotiation. After deriving keying material, and negotiating other parameters, it sends down one (or more) SADB_UPDATE messages with the same value in sadb_msg_seq.
如果KMd需要IPsec SPI值的两个方向，则可以执行第二个GETSPI操作。既然KMd已经为至少一个安全协会提供了SPI，它就开始谈判。在导出键控材料并协商其他参数后，它发送一条（或多条）SADB_更新消息，该消息在SADB_msg_seq中具有相同的值。
If a KMd has any error at all during its negotiation, it can send down:
如果KMd在协商过程中有任何错误，它可以发送：
KMd->Kernel: SADB_ACQUIRE for AH, assoc (with an error)
Kernel->All: SADB_ACQUIRE for AH, assoc (same error)
KMd->Kernel: SADB_ACQUIRE for AH, assoc (with an error)
Kernel->All: SADB_ACQUIRE for AH, assoc (same error)
but if it succeeds, it can instead:
但如果成功，它可以：
KMd->Kernel: SADB_UPDATE for AH, assoc, addrs, keys,
<etc.>
Kernel->All: SADB_UPDATE for AH, assoc, addrs, <etc.>
KMd->Kernel: SADB_UPDATE for AH, assoc, addrs, keys,
<etc.>
Kernel->All: SADB_UPDATE for AH, assoc, addrs, <etc.>
The results of the UPDATE (minus the actual keys) are sent to all listening sockets. If only one SPI value was determined locally, the other SPI (since IPsec SAs are unidirectional) must be added with an SADB_ADD message.
更新结果（减去实际键）将发送到所有侦听套接字。如果本地仅确定了一个SPI值，则必须使用SADB_添加消息添加另一个SPI（因为IPsec SA是单向的）。
KMd->Kernel: SADB_ADD for AH, assoc, addrs, keys, <etc.>
Kernel->All: SADB_ADD for AH, assoc, addrs, <etc.>
KMd->Kernel: SADB_ADD for AH, assoc, addrs, keys, <etc.>
Kernel->All: SADB_ADD for AH, assoc, addrs, <etc.>
If one of the extensions passed down was a Lifetime extension, it is possible at some point an SADB_EXPIRE message will arrive when one of the lifetimes has expired.
如果传递的其中一个扩展是生存期扩展，则在某个时间点，当其中一个生存期过期时，可能会出现SADB_EXPIRE消息。
Kernel->All: SADB_EXPIRE for AH, assoc, addrs,
Hard or Soft, Current, <etc.>
Kernel->All: SADB_EXPIRE for AH, assoc, addrs,
Hard or Soft, Current, <etc.>
The KMd can use this as a clue to begin negotiation, or, if it has some say in policy, send an SADB_UPDATE down with a lifetime extension.
KMd可以以此作为开始谈判的线索，或者，如果它在政策上有发言权，可以发送一个SADB_更新，并延长其生命周期。
Many people are interested in using IP Security in a "proxy" or "firewall" configuration in which an intermediate system provides security services for "inside" hosts. In these environments, the intermediate systems can use PF_KEY to communicate with key management applications almost exactly as they would if they were the actual endpoints. The messaging behavior of PF_KEY in these cases is exactly the same as the previous example, but the address information is slightly different.
许多人对在“代理”或“防火墙”配置中使用IP安全感兴趣，在这种配置中，中间系统为“内部”主机提供安全服务。在这些环境中，中间系统可以使用PF_KEY与密钥管理应用程序进行通信，就像它们是实际的端点一样。在这些情况下，PF_KEY的消息传递行为与前面的示例完全相同，但地址信息略有不同。
Consider this case:
考虑这种情况：
A ========= B --------- C
A ========= B --------- C
Key: A "outside" host that implements IPsec B "firewall" that implements IPsec C "inside" host that does not implement IPsec
密钥：实现IPsec的“外部”主机B实现IPsec的“防火墙”C不实现IPsec的“内部”主机
=== IP_{A<->B} ESP [ IP_{A<->C} ULP ]
--- IP_{A<->C} ULP
=== IP_{A<->B} ESP [ IP_{A<->C} ULP ]
--- IP_{A<->C} ULP
A is a single system that wishes to communicate with the "inside" system C. B is a "firewall" between C and the outside world that will do ESP and tunneling on C's behalf. A discovers that it needs to send traffic to C via B through methods not described here (Use of the DNS' KX record might be one method for discovering this).
A是希望与“内部”系统C通信的单个系统。B是C与外部世界之间的“防火墙”，代表C执行ESP和隧道。A发现它需要通过此处未描述的方法通过B向C发送通信量（使用DNS的KX记录可能是发现这种情况的一种方法）。
For packets that flow from left to right, A and B need an IPsec Security Association with:
对于从左向右流动的数据包，A和B需要IPsec安全关联：
SA type of ESP tunnel-mode Source Identity that dominates A (e.g. A's address) Destination Identity that dominates B (e.g. B's address) Source Address of A Destination Address of B
SA ESP隧道模式源标识的一种类型，该标识支配A（例如A的地址）的目标标识，该标识支配B的目标地址的B（例如B的地址）源地址
For packets to flow from right to left, A and B need an IPsec Security Association with:
要使数据包从右向左流动，A和B需要IPsec安全关联：
SA type of ESP tunnel-mode Source Identity that dominates C Destination Identity that dominates A Source Address of B Destination Address of A Proxy Address of C
SA类型的ESP隧道模式源标识，控制C的源地址，控制B的源地址，控制C的代理地址的目标地址
For this second SA (for packets flowing from C towards A), node A MUST verify that the inner source address is dominated by the Source Identity for the SA used with those packets. If node A does not do this, an adversary could forge packets with an arbitrary Source Identity and defeat the packet origin protections provided by IPsec.
对于第二个SA（对于从C流向A的数据包），节点A必须验证内部源地址是否由与这些数据包一起使用的SA的源标识控制。如果节点A不这样做，对手可能伪造具有任意源标识的数据包，并破坏IPsec提供的数据包源保护。
Now consider a slightly more complex case:
现在考虑一个稍微复杂的例子：
A_1 --| |-- D_1
|--- B ====== C ---|
A_2 --| |-- D_2
A_1 --| |-- D_1
|--- B ====== C ---|
A_2 --| |-- D_2
Key:
A_n "inside" host on net 1 that does not do IPsec.
B "firewall" for net 1 that supports IPsec.
C "firewall" for net 2 that supports IPsec.
D_n "inside" host on net 2 that does not do IPsec.
=== IP_{B<->C} ESP [ IP_{A<->C} ULP ]
--- IP_{A<->C} ULP
Key:
A_n "inside" host on net 1 that does not do IPsec.
B "firewall" for net 1 that supports IPsec.
C "firewall" for net 2 that supports IPsec.
D_n "inside" host on net 2 that does not do IPsec.
=== IP_{B<->C} ESP [ IP_{A<->C} ULP ]
--- IP_{A<->C} ULP
For A_1 to send a packet to D_1, B and C need an SA with:
要使A_1向D_1发送数据包，B和C需要具有以下内容的SA：
SA Type of ESP Source Identity that dominates A_1 Destination Identity that dominates C Source Address of B Destination Address of C Proxy Address of A_1
SA类型的ESP源标识，支配A_1目的标识，支配B的C源地址B的C目的地址A_1的代理地址
For D_1 to send a packet to A_1, C and B need an SA with: SA Type of ESP Tunnel-mode Source Identity that dominates D_1 Destination Identity that dominates B Source Address of C Destination Address of B Proxy Address of D_1
要使D_1向a_1发送数据包，C和B需要一个SA：SA类型的ESP隧道模式源标识，该标识支配D_1的目标标识，该标识支配B源地址的C目标地址的B代理地址的D_1
Note that A_2 and D_2 could be substituted for A_1 and D_1 (respectively) here; the association of an SA with a particular pair of ends or group of those pairs is a policy decision on B and/or C and not necessarily a function of key management. The same check of the Source Identity against the inner source IP address MUST also be performed in this case for the same reason.
注意，这里A_2和D_2可以分别代替A_1和D_1；SA与特定端对或这些端对的组的关联是关于B和/或C的策略决策，不一定是密钥管理的功能。出于同样的原因，在这种情况下，还必须针对内部源IP地址执行相同的源标识检查。
For a more detailed discussion of the use of IP Security in complex cases, please see [Atk97].
有关在复杂情况下使用IP安全的更详细讨论，请参阅[Atk97]。
NOTE: The notion of identity domination might be unfamiliar. Let H represent some node. Let Hn represent H's fully qualified domain name. Let Ha represent the IP address of H. Let Hs represent the IP subnet containing Ha. Let Hd represent a fully qualified domain name that is a parent of the fully qualified domain name of H. Let M be a UserFQDN identity that whose right-hand part is Hn or Ha.
注：身份支配的概念可能并不熟悉。设H表示某个节点。让Hn表示H的完全限定域名。让Ha表示H的IP地址。让Hs表示包含Ha的IP子网。设Hd表示一个完全限定的域名，该域名是H的完全限定域名的父级。设M是一个UserFQDN标识，其右侧部分为Hn或Ha。
Any of M, Hn, Ha, Hs, and Hd is considered to dominate H in the example above. Hs dominates any node having an IP address within the IP address range represented by Hs. Hd dominates any node having a fully qualified domain name within underneath Hd.
在上面的例子中，M、Hn、Ha、Hs和Hd中的任何一个都被认为支配H。Hs控制任何IP地址在Hs表示的IP地址范围内的节点。Hd控制Hd中具有完全限定域名的任何节点。
+---------------+ +-------------+
|Key Mgmt Daemon| | OSPF daemon |
+---------------+ +-------------+
| | / / |
| /------|----+ / |
| / | +---+ | Applications
======[PF_KEY]====[PF_INET]===========[PF_ROUTE]================
| | | | OS Kernel
+------------+ +-----------------+ +---------+
| Key Engine | | TCP/IP, | | Routing |
| or SADB |---| including IPsec |--| Table |
+------------+ | | +---------+
+-----------------+
+---------------+ +-------------+
|Key Mgmt Daemon| | OSPF daemon |
+---------------+ +-------------+
| | / / |
| /------|----+ / |
| / | +---+ | Applications
======[PF_KEY]====[PF_INET]===========[PF_ROUTE]================
| | | | OS Kernel
+------------+ +-----------------+ +---------+
| Key Engine | | TCP/IP, | | Routing |
| or SADB |---| including IPsec |--| Table |
+------------+ | | +---------+
+-----------------+
As in the previous examples, the KMd registers itself with the Key Engine via PF_KEY. Even though the consumer of the security associations is in user-space, the PF_KEY and Key Engine implementation knows enough to store SAs and to relay messages.
与前面的示例一样，KMd通过PF_键向键引擎注册自身。即使安全关联的使用者在用户空间中，PF_密钥和密钥引擎实现也知道足够的信息来存储SA和中继消息。
When the OSPF daemon needs to communicate securely with its peers, it would perform an SADB_GET message and retrieve the appropriate association:
当OSPF守护进程需要与其对等方安全通信时，它将执行SADB_GET消息并检索适当的关联：
OSPFd->Kernel: SADB_GET of OSPF, assoc, addrs
Kernel->OSPFd: SADB_GET of OSPF, assoc, addrs, keys, <etc.>
OSPFd->Kernel: SADB_GET of OSPF, assoc, addrs
Kernel->OSPFd: SADB_GET of OSPF, assoc, addrs, keys, <etc.>
If this GET fails, the OSPFd may need to acquire a new security association. This interaction is as follows:
如果此GET失败，OSPFd可能需要获取新的安全关联。这种相互作用如下：
OSPFd->Kernel: SADB_ACQUIRE of OSPF, addrs, <ID, sens,>
proposal
Kernel->Registered: SADB_ACQUIRE of OSPF, <same as sent message>
OSPFd->Kernel: SADB_ACQUIRE of OSPF, addrs, <ID, sens,>
proposal
Kernel->Registered: SADB_ACQUIRE of OSPF, <same as sent message>
The KMd sees this and performs actions similar to the previous example. One difference, however, is that when the UPDATE message comes back, the OSPFd will then perform a GET of the updated SA to retrieve all of its parameters.
KMd看到了这一点，并执行与前一个示例类似的操作。然而，一个区别是，当更新消息返回时，OSPFd将执行更新SA的GET以检索其所有参数。
Some messages work well only in system maintenance programs, for debugging, or for auditing. In a system panic situation, such as a detected compromise, an SADB_FLUSH message should be issued for a particular SA type, or for ALL SA types.
有些消息只有在系统维护程序、调试程序或审核程序中才能正常工作。在系统死机情况下，如检测到泄露，应针对特定SA类型或所有SA类型发出SADB_刷新消息。
Program->Kernel: SADB_FLUSH for ALL
<Kernel then flushes all internal SAs>
Kernel->All: SADB_FLUSH for ALL
Program->Kernel: SADB_FLUSH for ALL
<Kernel then flushes all internal SAs>
Kernel->All: SADB_FLUSH for ALL
Some SAs may need to be explicitly deleted, either by a KMd, or by a system maintenance program.
某些SA可能需要通过KMd或系统维护程序明确删除。
Program->Kernel: SADB_DELETE for AH, association, addrs
Kernel->All: SADB_DELETE for AH, association, addrs
Program->Kernel: SADB_DELETE for AH, association, addrs
Kernel->All: SADB_DELETE for AH, association, addrs
Common usage of the SADB_DUMP message is discouraged. For debugging purposes, however, it can be quite useful. The output of a DUMP message should be read quickly, in order to avoid socket buffer overflows.
不鼓励常用SADB_转储消息。但是，出于调试目的，它可能非常有用。应该快速读取转储消息的输出，以避免套接字缓冲区溢出。
Program->Kernel: SADB_DUMP for ESP
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
<ad nauseam...>
Program->Kernel: SADB_DUMP for ESP
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
Kernel->Program: SADB_DUMP for ESP, association, <all fields>
<ad nauseam...>
6 Security Considerations
6安全考虑
This memo discusses a method for creating, reading, modifying, and deleting Security Associations from an operating system. Only trusted, privileged users and processes should be able to perform any of these operations. It is unclear whether this mechanism provides any security when used with operating systems not having the concept of a trusted, privileged user.
本备忘录讨论了从操作系统中创建、读取、修改和删除安全关联的方法。只有受信任的特权用户和进程才能执行这些操作。目前尚不清楚，当与不具有可信、特权用户概念的操作系统一起使用时，该机制是否提供任何安全性。
If an unprivileged user is able to perform any of these operations, then the operating system cannot actually provide the related security services. If an adversary knows the keys and algorithms in use, then cryptography cannot provide any form of protection.
如果非特权用户能够执行这些操作中的任何一项，那么操作系统实际上无法提供相关的安全服务。如果对手知道使用的密钥和算法，那么加密技术就无法提供任何形式的保护。
This mechanism is not a panacea, but it does provide an important operating system component that can be useful in creating a secure internetwork.
这种机制不是万能的，但它确实提供了一个重要的操作系统组件，可用于创建安全的互联网。
Users need to understand that the quality of the security provided by an implementation of this specification depends completely upon the overall security of the operating system, the correctness of the PF_KEY implementation, and upon the security and correctness of the applications that connect to PF_KEY. It is appropriate to use high assurance development techniques when implementing PF_KEY and the related security association components of the operating system.
用户需要了解，本规范实现所提供的安全性的质量完全取决于操作系统的整体安全性、PF_密钥实现的正确性以及连接到PF_密钥的应用程序的安全性和正确性。在实现PF_密钥和操作系统的相关安全关联组件时，使用高保证开发技术是合适的。
Acknowledgments
致谢
The authors of this document are listed primarily in alphabetical order. Randall Atkinson and Ron Lee provided useful feedback on earlier versions of this document.
本文件的作者主要按字母顺序列出。Randall Atkinson和Ron Lee就本文档的早期版本提供了有用的反馈。
At one time or other, all of the authors worked at the Center for High Assurance Computer Systems at the U.S. Naval Research Laboratory. This work was sponsored by the Information Security Program Office (PMW-161), U.S. Space and Naval Warfare Systems Command (SPAWAR) and the Computing Systems Technology Office, Defense Advanced Research Projects Agency (DARPA/CSTO). We really appreciate their sponsorship of our efforts and their continued support of PF_KEY development. Without that support, PF_KEY would not exist.
所有的作者都曾在美国海军研究实验室的高保证计算机系统中心工作过。这项工作由信息安全计划办公室（PMW-161）、美国空间和海战系统司令部（SPAWAR）以及国防高级研究计划局（DARPA/CSTO）计算系统技术办公室赞助。我们非常感谢他们对我们工作的支持，以及他们对PF_关键开发的持续支持。没有这种支持，PF_密钥将不存在。
The "CONFORMANCE and COMPLIANCE" wording was taken from [MSST98].
“合规性和合规性”的措辞取自[MSST98]。
Finally, the authors would like to thank those who sent in comments and questions on the various iterations of this document. This specification and implementations of it are discussed on the PF_KEY mailing list. If you would like to be added to this list, send a note to <pf_key-request@inner.net>.
最后，作者要感谢那些就本文档的各种迭代发送评论和问题的人。PF_密钥邮件列表中讨论了该规范及其实现。如果您希望被添加到此列表中，请向<pf_key-request@inner.net>.
References
工具书类
[AMPMC96] Randall J. Atkinson, Daniel L. McDonald, Bao G. Phan, Craig W. Metz, and Kenneth C. Chin, "Implementation of IPv6 in 4.4-Lite BSD", Proceedings of the 1996 USENIX Conference, San Diego, CA, January 1996, USENIX Association.
[AMPMC96]Randall J.Atkinson、Daniel L.McDonald、Bao G.Phan、Craig W.Metz和Kenneth C.Chin，“在4.4-Lite BSD中实现IPv6”，1996年USENIX会议记录，加利福尼亚州圣地亚哥，1996年1月，USENIX协会。
[Atk95a] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
[Atk95a]阿特金森，R.，“IP安全架构”，RFC 18251995年8月。
[Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[Atk95b]阿特金森，R.，“IP认证头”，RFC 18261995年8月。
[Atk95c] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[Atk95c]阿特金森，R.，“IP封装安全有效载荷”，RFC 1827，1995年8月。
[Atk97] Atkinson, R., "Key Exchange Delegation Record for the Domain Name System", RFC 2230, October 1997.
[Atk97]Atkinson，R.，“域名系统的密钥交换委托记录”，RFC 2230，1997年10月。
[BA97] Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[BA97]Baker，F.和R.Atkinson，“RIP-2 MD5认证”，RFC 2082，1997年1月。
[Biba77] K. J. Biba, "Integrity Considerations for Secure Computer Systems", MTR-3153, The MITRE Corporation, June 1975; ESD-TR-76-372, April 1977.
[Biba77]K.J.Biba，“安全计算机系统的完整性考虑”，MTR-3153，MITRE公司，1975年6月；ESD-TR-76-372，1977年4月。
[BL74] D. Elliot Bell and Leonard J. LaPadula, "Secure Computer Systems: Unified Exposition and Multics Interpretation", MTR 2997, The MITRE Corporation, April 1974. (AD/A 020 445)
[BL74]D.Elliot Bell和Leonard J.LaPadula，“安全计算机系统：统一展示和多CS解读”，MTR 2997，米特公司，1974年4月。（AD/A 020 445）
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[CW87] D. D. Clark and D. R. Wilson, "A Comparison of Commercial and Military Computer Security Policies", Proceedings of the 1987 Symposium on Security and Privacy, pp. 184-195, IEEE Computer Society, Washington, D.C., 1987.
[CW87]D.D.Clark和D.R.Wilson，“商用和军用计算机安全政策的比较”，《1987年安全和隐私研讨会论文集》，第184-195页，IEEE计算机学会，华盛顿特区，1987年。
[DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87.
[DIA]美国国防情报局（DIA），“隔间模式工作站规范”，技术报告DDS-2600-6243-87。
[GK98] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and Its Use with IPsec", Work in Progress.
[GK98]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，正在进行中。
[HM97a] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[HM97a]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）规范”，RFC 2093，1997年7月。
[HM97b] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[HM97b]Harney，H.和C.Muckenhirn，“组密钥管理协议（GKPP）体系结构”，RFC 2094，1997年7月。
[MD98] Madsen, C., and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", Work in Progress.
[MD98]Madsen，C.和N.Doraswamy，“具有显式IV的ESP DES-CBC密码算法”，正在进行中。
[MG98a] Madsen, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Work in Progress.
[MG98a]Madsen，C.和R.Glenn，“在ESP和AH中使用HMAC-MD5-96”，正在进行中。
[MG98b] Madsen, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", Work in Progress.
[MG98b]Madsen，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，正在进行中。
[MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Work in Progress.
[MSST98]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，工作正在进行中。
[Moy98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Moy98]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[Per97] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[Per97]Perkins，C.，“IP移动支持”，RFC 2002，1996年10月。
[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", Work in Progress.
[Pip98]Piper，D.，“ISAKMP解释的互联网IP安全域”，正在进行中。
[Sch96] Bruce Schneier, Applied Cryptography, p. 360, John Wiley & Sons, Inc., 1996.
[Sch96]Bruce Schneier，应用密码学，p。约翰·威利父子公司，1996年，第360页。
[Skl91] Keith Sklower, "A Tree-based Packet Routing Table for Berkeley UNIX", Proceedings of the Winter 1991 USENIX Conference, Dallas, TX, USENIX Association. 1991. pp. 93-103.
[Skl91]Keith Sklower，“伯克利UNIX基于树的数据包路由表”，1991年冬季USENIX会议论文集，德克萨斯州达拉斯，USENIX协会。1991第93-103页。
Disclaimer
免责声明
The views and specification here are those of the editors and are not necessarily those of their employers. The employers have not passed judgment on the merits, if any, of this work. The editors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
这里的观点和说明是编辑的观点和说明，不一定是他们的雇主的观点和说明。雇主还没有对这项工作的是非曲直作出判断。编辑及其雇主明确否认对正确或不正确实施或使用本规范产生的任何问题负责。
Authors' Addresses
作者地址
Daniel L. McDonald Sun Microsystems, Inc. 901 San Antonio Road, MS UMPK17-202 Palo Alto, CA 94303
Daniel L.McDonald Sun Microsystems，Inc.加利福尼亚州帕洛阿尔托市圣安东尼奥路901号UMPK17-202邮编94303
Phone: +1 650 786 6815
EMail: danmcd@eng.sun.com
Phone: +1 650 786 6815
EMail: danmcd@eng.sun.com
Craig Metz (for Code 5544) U.S. Naval Research Laboratory 4555 Overlook Ave. SW Washington, DC 20375
克雷格·梅茨（代码5544）美国海军研究实验室华盛顿西南俯瞰大道4555号，邮编20375
Phone: (DSN) 754-8590 EMail: cmetz@inner.net
电话：（DSN）754-8590电子邮件：cmetz@inner.net
Bao G. Phan U. S. Naval Research Laboratory
美国海军研究实验室
EMail: phan@itd.nrl.navy.mil
EMail: phan@itd.nrl.navy.mil
Appendix A: Promiscuous Send/Receive Message Type
附录A：杂乱发送/接收消息类型
A kernel supporting PF_KEY MAY implement the following extension for development and debugging purposes. If it does, it MUST implement the extension as specified here. An implementation MAY require an application to have additional privileges to perform promiscuous send and/or receive operations.
出于开发和调试目的，支持PF_键的内核可以实现以下扩展。如果是，它必须实现此处指定的扩展。实现可能需要应用程序具有额外的权限来执行杂乱的发送和/或接收操作。
The SADB_X_PROMISC message allows an application to send and receive messages in a "promiscuous mode." There are two forms of this message: control and data. The control form consists of only a message header. This message is used to toggle the promiscuous-receive function. A value of one in the sadb_msg_satype field enables promiscuous message reception for this socket, while a value of zero in that field disables it.
SADB_X_PROMISC消息允许应用程序以“混杂模式”发送和接收消息。此消息有两种形式：控制和数据。控件窗体只包含一个消息头。此消息用于切换混杂接收功能。sadb_msg_satype字段中的值为1时，此套接字将启用混杂消息接收，而该字段中的值为零时，将禁用此套接字。
The second form of this message is the data form. This is used to send or receive messages in their raw form. Messages in the data form consist of a message header followed by an entire new message. There will be two message headers in a row: one for the SADB_X_PROMISC message, and one for the payload message.
此消息的第二种形式是数据形式。这用于发送或接收原始形式的消息。数据表单中的消息由消息头和整个新消息组成。一行中将有两个消息头：一个用于SADB_X_PROMISC消息，另一个用于有效负载消息。
Data messages sent from the application are sent to either the PF_KEY socket of a single process identified by a nonzero sadb_msg_seq or to all PF_KEY sockets if sadb_msg_seq is zero. These messages are sent without any processing of their contents by the PF_KEY interface (including sanity checking). This promiscuous-send capability allows an application to send messages as if it were the kernel. This also allows it to send erroneous messages.
从应用程序发送的数据消息被发送到由非零sadb_msg_seq标识的单个进程的PF_密钥套接字，或者如果sadb_msg_seq为零，则发送到所有PF_密钥套接字。通过PF_键接口发送这些消息时，不会对其内容进行任何处理（包括健全性检查）。这种杂乱的发送功能允许应用程序发送消息，就像它是内核一样。这也允许它发送错误的消息。
If the promiscuous-receive function has been enabled, a copy of any message sent via PF_KEY by another application or by the kernel is sent to the promiscuous application. This is done before any processing of the message's contents by the PF_KEY interface (again, including sanity checking). This promiscuous-receive capability allows an application to receive all messages sent by other parties using PF_KEY.
如果启用了混杂接收功能，则会将另一个应用程序或内核通过PF_密钥发送的任何消息的副本发送到混杂应用程序。这是在PF_键接口对消息内容进行任何处理之前完成的（同样，包括健全性检查）。这种杂乱的接收功能允许应用程序使用PF_密钥接收其他方发送的所有消息。
The messaging behavior of the SADB_X_PROMISC message is:
SADB_X_PROMISC消息的消息传递行为为：
Send a control-form SADB_X_PROMISC message from a user process to the kernel.
从用户进程向内核发送控制表单SADB_X_PROMISC消息。
<base>
<base>
The kernel returns the SADB_X_PROMISC message to all listening processes.
内核将SADB_X_PROMISC消息返回给所有侦听进程。
<base>
<base>
Send a data-form SADB_X_PROMISC message from a user process to the kernel.
从用户进程向内核发送数据表单SADB_X_PROMISC消息。
<base, base(, others)>
<base, base(, others)>
The kernel sends the encapsulated message to the target process(s).
内核将封装的消息发送到目标进程。
<base(, others)>
<base(, others)>
If promiscuous-receive is enabled, the kernel will encapsulate and send copies of all messages sent via the PF_KEY interface.
如果启用了混杂接收，内核将封装并发送通过PF_密钥接口发送的所有消息的副本。
<base, base(, others)>
<base, base(, others)>
Errors: EPERM Additional privileges are required to perform the requested operations. ESRCH (Data form, sending) The target process in sadb_msg_seq does not exist or does not have an open PF_KEY Version 2 socket.
错误：执行请求的操作需要EPERM附加权限。ESRCH（数据表单，发送）sadb_msg_seq中的目标进程不存在或没有打开的PF_密钥版本2套接字。
Appendix B: Passive Change Message Type
附录B：被动变更消息类型
The SADB_X_PCHANGE message is a passive-side (aka. the "listener" or "receiver") counterpart to the SADB_ACQUIRE message. It is useful for when key management applications wish to more effectively handle incoming key management requests for passive-side sessions that deviate from systemwide default security services. If a passive session requests that only certain levels of security service be allowed, the SADB_X_PCHANGE message expresses this change to any registered PF_KEY sockets. Unlike SADB_ACQUIRE, this message is purely informational, and demands no other PF_KEY interaction.
SADB_X_PCHANGE消息是SADB_ACQUIRE消息的被动端（也称为“侦听器”或“接收器”）。当密钥管理应用程序希望更有效地处理来自被动端会话的传入密钥管理请求时，它非常有用，因为被动端会话偏离了系统范围的默认安全服务。如果被动会话请求只允许某些级别的安全服务，SADB_X_PCHANGE消息会将此更改表示为任何已注册的PF_密钥套接字。与SADB_ACQUIRE不同，此消息纯粹是信息性的，不需要其他PF_键交互。
The SADB_X_PCHANGE message is typically triggered by either a change in an endpoint's requested security services, or when an endpoint that made a special request disappears. In the former case, an SADB_X_PCHANGE looks like an SADB_ACQUIRE, complete with an sadb_proposal extension indicating the preferred algorithms, lifetimes, and other attributes. When a passive session either disappears, or reverts to a default behavior, an SADB_X_PCHANGE will be issued with _no_ sadb_proposal extension, indicating that the exception to systemwide default behavior has disappeared.
SADB_X_PCHANGE消息通常由端点请求的安全服务中的更改或发出特殊请求的端点消失时触发。在前一种情况下，SADB_X_PCHANGE看起来像SADB_ACQUIRE，带有一个SADB_建议扩展，指示首选算法、生存期和其他属性。当被动会话消失或恢复为默认行为时，SADB_X_PCHANGE将发出带有_no_uuusadb_建议扩展的SADB_更改，表示系统范围内默认行为的异常已消失。
There are two messaging behaviors for SADB_X_PCHANGE. The first is the kernel-originated case:
SADB_X_PCHANGE有两种消息传递行为。第一个是源于内核的情况：
The kernel sends an SADB_X_PCHANGE message to registered sockets.
内核向注册的套接字发送SADB_X_PCHANGE消息。
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
NOTE: The address(SD) extensions MUST have the port fields filled in with the port numbers of the session requiring keys if appropriate.
注意：地址（SD）扩展必须在端口字段中填入需要密钥的会话的端口号（如果适用）。
The second is for a user-level consumer of SAs.
第二个是SAs的用户级消费者。
Send an SADB_X_PCHANGE message from a user process to the kernel.
从用户进程向内核发送SADB_X_PCHANGE消息。
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
The kernel returns an SADB_X_PCHANGE message to registered sockets.
内核向注册的套接字返回SADB_X_PCHANGE消息。
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
<base, address(SD), (identity(SD),) (sensitivity,) (proposal)>
Appendix C: Key Management Private Data Extension
附录C：密钥管理专用数据扩展
The Key Management Private Data extension is attached to either an SADB_ADD or an SADB_UPDATE message. It attaches a single piece of arbitrary data to a security association. It may be useful for key managment applications that could use an SADB_DUMP or SADB_GET message to obtain additional state if it needs to restart or recover after a crash. The format of this extension is:
密钥管理专用数据扩展附加到SADB_添加或SADB_更新消息。它将单个任意数据附加到安全关联。如果密钥管理应用程序需要在崩溃后重新启动或恢复，则它可能对使用SADB_转储或SADB_GET消息获取附加状态的密钥管理应用程序有用。此扩展的格式为：
#define SADB_X_EXT_KMPRIVATE 17
#定义SADB_X_EXT_KMU 17
struct sadb_x_kmprivate {
uint16_t sadb_x_kmprivate_len;
uint16_t sadb_x_kmprivate_exttype;
uint32_t sadb_x_kmprivate_reserved;
};
/* sizeof(struct sadb_x_kmprivate) == 8 */
struct sadb_x_kmprivate {
uint16_t sadb_x_kmprivate_len;
uint16_t sadb_x_kmprivate_exttype;
uint32_t sadb_x_kmprivate_reserved;
};
/* sizeof(struct sadb_x_kmprivate) == 8 */
/* followed by arbitrary data */
/* followed by arbitrary data */
The data following the sadb_x_kmprivate extension can be anything. It will be stored with the actual security association in the kernel. Like all data, it must be padded to an eight byte boundary.
sadb_x_kmprivate扩展后面的数据可以是任何内容。它将与内核中的实际安全关联一起存储。与所有数据一样，它必须填充到8字节边界。
Appendix D: Sample Header File
附录D：示例头文件
/*
This file defines structures and symbols for the PF_KEY Version 2
key management interface. It was written at the U.S. Naval Research
Laboratory. This file is in the public domain. The authors ask that
you leave this credit intact on any copies of this file.
*/
#ifndef __PFKEY_V2_H
#define __PFKEY_V2_H 1
/*
This file defines structures and symbols for the PF_KEY Version 2
key management interface. It was written at the U.S. Naval Research
Laboratory. This file is in the public domain. The authors ask that
you leave this credit intact on any copies of this file.
*/
#ifndef __PFKEY_V2_H
#define __PFKEY_V2_H 1
#define PF_KEY_V2 2 #define PFKEYV2_REVISION 199806L
#定义PFKEYV2 2#定义PFKEYV2修订版199806L
#define SADB_RESERVED 0 #define SADB_GETSPI 1 #define SADB_UPDATE 2 #define SADB_ADD 3 #define SADB_DELETE 4 #define SADB_GET 5 #define SADB_ACQUIRE 6 #define SADB_REGISTER 7 #define SADB_EXPIRE 8 #define SADB_FLUSH 9 #define SADB_DUMP 10 #define SADB_X_PROMISC 11 #define SADB_X_PCHANGE 12 #define SADB_MAX 12
#定义SADB_保留0#定义SADB_获取SPI 1#定义SADB_更新2#定义SADB_添加3#定义SADB_删除4#定义SADB_获取5#定义SADB_获取6#定义SADB_寄存器7#定义SADB_过期8#定义SADB#刷新9#定义SADB#定义SADU转储10#定义SADU X获取12#
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_msg_satype;
uint16_t sadb_msg_len;
uint16_t sadb_msg_reserved;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
};
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_msg_satype;
uint16_t sadb_msg_len;
uint16_t sadb_msg_reserved;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
};
struct sadb_ext {
uint16_t sadb_ext_len;
uint16_t sadb_ext_type;
};
struct sadb_ext {
uint16_t sadb_ext_len;
uint16_t sadb_ext_type;
};
struct sadb_sa {
uint16_t sadb_sa_len;
uint16_t sadb_sa_exttype;
struct sadb_sa {
uint16_t sadb_sa_len;
uint16_t sadb_sa_exttype;
uint32_t sadb_sa_spi;
uint8_t sadb_sa_replay;
uint8_t sadb_sa_state;
uint8_t sadb_sa_auth;
uint8_t sadb_sa_encrypt;
uint32_t sadb_sa_flags;
};
uint32_t sadb_sa_spi;
uint8_t sadb_sa_replay;
uint8_t sadb_sa_state;
uint8_t sadb_sa_auth;
uint8_t sadb_sa_encrypt;
uint32_t sadb_sa_flags;
};
struct sadb_lifetime {
uint16_t sadb_lifetime_len;
uint16_t sadb_lifetime_exttype;
uint32_t sadb_lifetime_allocations;
uint64_t sadb_lifetime_bytes;
uint64_t sadb_lifetime_addtime;
uint64_t sadb_lifetime_usetime;
};
struct sadb_lifetime {
uint16_t sadb_lifetime_len;
uint16_t sadb_lifetime_exttype;
uint32_t sadb_lifetime_allocations;
uint64_t sadb_lifetime_bytes;
uint64_t sadb_lifetime_addtime;
uint64_t sadb_lifetime_usetime;
};
struct sadb_address {
uint16_t sadb_address_len;
uint16_t sadb_address_exttype;
uint8_t sadb_address_proto;
uint8_t sadb_address_prefixlen;
uint16_t sadb_address_reserved;
};
struct sadb_address {
uint16_t sadb_address_len;
uint16_t sadb_address_exttype;
uint8_t sadb_address_proto;
uint8_t sadb_address_prefixlen;
uint16_t sadb_address_reserved;
};
struct sadb_key {
uint16_t sadb_key_len;
uint16_t sadb_key_exttype;
uint16_t sadb_key_bits;
uint16_t sadb_key_reserved;
};
struct sadb_key {
uint16_t sadb_key_len;
uint16_t sadb_key_exttype;
uint16_t sadb_key_bits;
uint16_t sadb_key_reserved;
};
struct sadb_ident {
uint16_t sadb_ident_len;
uint16_t sadb_ident_exttype;
uint16_t sadb_ident_type;
uint16_t sadb_ident_reserved;
uint64_t sadb_ident_id;
};
struct sadb_ident {
uint16_t sadb_ident_len;
uint16_t sadb_ident_exttype;
uint16_t sadb_ident_type;
uint16_t sadb_ident_reserved;
uint64_t sadb_ident_id;
};
struct sadb_sens {
uint16_t sadb_sens_len;
uint16_t sadb_sens_exttype;
uint32_t sadb_sens_dpd;
uint8_t sadb_sens_sens_level;
uint8_t sadb_sens_sens_len;
uint8_t sadb_sens_integ_level;
uint8_t sadb_sens_integ_len;
struct sadb_sens {
uint16_t sadb_sens_len;
uint16_t sadb_sens_exttype;
uint32_t sadb_sens_dpd;
uint8_t sadb_sens_sens_level;
uint8_t sadb_sens_sens_len;
uint8_t sadb_sens_integ_level;
uint8_t sadb_sens_integ_len;
uint32_t sadb_sens_reserved;
};
uint32_t sadb_sens_reserved;
};
struct sadb_prop {
uint16_t sadb_prop_len;
uint16_t sadb_prop_exttype;
uint8_t sadb_prop_replay;
uint8_t sadb_prop_reserved[3];
};
struct sadb_prop {
uint16_t sadb_prop_len;
uint16_t sadb_prop_exttype;
uint8_t sadb_prop_replay;
uint8_t sadb_prop_reserved[3];
};
struct sadb_comb {
uint8_t sadb_comb_auth;
uint8_t sadb_comb_encrypt;
uint16_t sadb_comb_flags;
uint16_t sadb_comb_auth_minbits;
uint16_t sadb_comb_auth_maxbits;
uint16_t sadb_comb_encrypt_minbits;
uint16_t sadb_comb_encrypt_maxbits;
uint32_t sadb_comb_reserved;
uint32_t sadb_comb_soft_allocations;
uint32_t sadb_comb_hard_allocations;
uint64_t sadb_comb_soft_bytes;
uint64_t sadb_comb_hard_bytes;
uint64_t sadb_comb_soft_addtime;
uint64_t sadb_comb_hard_addtime;
uint64_t sadb_comb_soft_usetime;
uint64_t sadb_comb_hard_usetime;
};
struct sadb_comb {
uint8_t sadb_comb_auth;
uint8_t sadb_comb_encrypt;
uint16_t sadb_comb_flags;
uint16_t sadb_comb_auth_minbits;
uint16_t sadb_comb_auth_maxbits;
uint16_t sadb_comb_encrypt_minbits;
uint16_t sadb_comb_encrypt_maxbits;
uint32_t sadb_comb_reserved;
uint32_t sadb_comb_soft_allocations;
uint32_t sadb_comb_hard_allocations;
uint64_t sadb_comb_soft_bytes;
uint64_t sadb_comb_hard_bytes;
uint64_t sadb_comb_soft_addtime;
uint64_t sadb_comb_hard_addtime;
uint64_t sadb_comb_soft_usetime;
uint64_t sadb_comb_hard_usetime;
};
struct sadb_supported {
uint16_t sadb_supported_len;
uint16_t sadb_supported_exttype;
uint32_t sadb_supported_reserved;
};
struct sadb_supported {
uint16_t sadb_supported_len;
uint16_t sadb_supported_exttype;
uint32_t sadb_supported_reserved;
};
struct sadb_alg {
uint8_t sadb_alg_id;
uint8_t sadb_alg_ivlen;
uint16_t sadb_alg_minbits;
uint16_t sadb_alg_maxbits;
uint16_t sadb_alg_reserved;
};
struct sadb_alg {
uint8_t sadb_alg_id;
uint8_t sadb_alg_ivlen;
uint16_t sadb_alg_minbits;
uint16_t sadb_alg_maxbits;
uint16_t sadb_alg_reserved;
};
struct sadb_spirange {
uint16_t sadb_spirange_len;
uint16_t sadb_spirange_exttype;
uint32_t sadb_spirange_min;
uint32_t sadb_spirange_max;
struct sadb_spirange {
uint16_t sadb_spirange_len;
uint16_t sadb_spirange_exttype;
uint32_t sadb_spirange_min;
uint32_t sadb_spirange_max;
uint32_t sadb_spirange_reserved;
};
uint32_t sadb_spirange_reserved;
};
struct sadb_x_kmprivate {
uint16_t sadb_x_kmprivate_len;
uint16_t sadb_x_kmprivate_exttype;
uint32_t sadb_x_kmprivate_reserved;
};
struct sadb_x_kmprivate {
uint16_t sadb_x_kmprivate_len;
uint16_t sadb_x_kmprivate_exttype;
uint32_t sadb_x_kmprivate_reserved;
};
#define SADB_EXT_RESERVED 0 #define SADB_EXT_SA 1 #define SADB_EXT_LIFETIME_CURRENT 2 #define SADB_EXT_LIFETIME_HARD 3 #define SADB_EXT_LIFETIME_SOFT 4 #define SADB_EXT_ADDRESS_SRC 5 #define SADB_EXT_ADDRESS_DST 6 #define SADB_EXT_ADDRESS_PROXY 7 #define SADB_EXT_KEY_AUTH 8 #define SADB_EXT_KEY_ENCRYPT 9 #define SADB_EXT_IDENTITY_SRC 10 #define SADB_EXT_IDENTITY_DST 11 #define SADB_EXT_SENSITIVITY 12 #define SADB_EXT_PROPOSAL 13 #define SADB_EXT_SUPPORTED_AUTH 14 #define SADB_EXT_SUPPORTED_ENCRYPT 15 #define SADB_EXT_SPIRANGE 16 #define SADB_X_EXT_KMPRIVATE 17 #define SADB_EXT_MAX 17 #define SADB_SATYPE_UNSPEC 0 #define SADB_SATYPE_AH 2 #define SADB_SATYPE_ESP 3 #define SADB_SATYPE_RSVP 5 #define SADB_SATYPE_OSPFV2 6 #define SADB_SATYPE_RIPV2 7 #define SADB_SATYPE_MIP 8 #define SADB_SATYPE_MAX 8
#定义SAD B（U）单词单词的定义，定义，定义，定义，定义，定义，定义，定义，定义，定义。定义，定义，定义，定义，定义，目前2，定义，定义，定义，定义，定义。定义，定义，定义，定义，定义，B（U）单词单词单词单词单词单词（U）单词单词单词，定义，定义，定义，定义，定义，定义，定义，定义，定义，定义，B（U）单词单词（U）单词单词单词，单词单词，单词单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，单词，_EXT_IDENTITY_SRC 10#定义定义SAD B（UUUUUUUU U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U#定义SADB_SATYPE_RSVP5#定义SADB#U SATYPE_OSPFV2 6#定义SADB(U SATYPE)RIPV2 7#定义SADB(U SATYPE)MIP 8#定义SADB(U SATYPE)最大8
#define SADB_SASTATE_LARVAL 0 #define SADB_SASTATE_MATURE 1 #define SADB_SASTATE_DYING 2 #define SADB_SASTATE_DEAD 3 #define SADB_SASTATE_MAX 3
#定义SADB_SASTATE_幼虫0#定义SADB_SASTATE_成熟1#定义SADB_SASTATE_死亡2#定义SADB_SASTATE_死亡3#定义SADB_SASTATE_最大3
#define SADB_SAFLAGS_PFS 1
#定义SADB\u SAFLAGS\u PFS 1
#define SADB_AALG_NONE 0 #define SADB_AALG_MD5HMAC 2 #define SADB_AALG_SHA1HMAC 3
#定义SADB_AALG_NONE 0#定义SADB_AALG_MD5HMAC 2#定义SADB_AALG_SHA1HMAC 3
#define SADB_AALG_MAX 3
#定义SADB_AALG_最大值3
#define SADB_EALG_NONE 0 #define SADB_EALG_DESCBC 2 #define SADB_EALG_3DESCBC 3 #define SADB_EALG_NULL 11 #define SADB_EALG_MAX 11
#定义SADB_EALG_NONE 0#定义SADB_EALG_DESCBC 2#定义SADB_EALG_3DESCBC 3#定义SADB_EALG_NULL 11#定义SADB_EALG_MAX 11
#define SADB_IDENTTYPE_RESERVED 0 #define SADB_IDENTTYPE_PREFIX 1 #define SADB_IDENTTYPE_FQDN 2 #define SADB_IDENTTYPE_USERFQDN 3 #define SADB_IDENTTYPE_MAX 3
#定义SADB_IDENTTYPE_RESERVED 0#定义SADB_IDENTTYPE_PREFIX 1#定义SADB_IDENTTYPE_FQDN 2#定义SADB_IDENTTYPE_USERFQDN 3#定义SADB_IDENTTYPE_MAX 3
#define SADB_KEY_FLAGS_MAX 0
#endif /* __PFKEY_V2_H */
#define SADB_KEY_FLAGS_MAX 0
#endif /* __PFKEY_V2_H */
Appendix E: Change Log
附录E：变更日志
The following changes were made between 05 and 06:
在05至06年间进行了以下更改：
* Last change before becoming an informational RFC. Removed all Internet-Draft references. Also standardized citation strings. Now cite RFC 2119 for MUST, etc.
* 成为信息RFC之前的最后更改。已删除所有Internet草稿引用。还标准化了引用字符串。现在必须引用RFC2119等。
* New appendix on optional KM private data extension.
* 关于可选KM专用数据扩展的新附录。
* Fixed example to indicate the ACQUIRE messages with errno mean KM failure.
* 修复了指示带有errno mean KM故障的ACQUIRE消息的示例。
* Added SADB_EALG_NULL.
* 添加了SADB_EALG_NULL。
* Clarified proxy examples to match definition of PROXY address being the inner packet's source address. (Basically a sign-flip. The example still shows how to protect against policy vulnerabilities in tunnel endpoints.)
* 阐明了代理示例，以匹配作为内部数据包源地址的代理地址的定义。（基本上是一个符号翻转。该示例仍然显示了如何防止隧道端点中的策略漏洞。）
* Loosened definition of a destination address to include broadcast.
* 放宽了包含广播的目的地地址的定义。
* Recommended that LARVAL security associations have implicit short lifetimes.
* 建议幼虫安全性关联具有隐含的短寿命。
The following changes were made between 04 and 05:
在04年至05年期间进行了以下更改：
* New appendix on Passive Change message.
* 关于被动变更信息的新附录。
* New sadb_address_prefixlen field.
* 新的sadb_地址_前缀字段。
* Small clarifications on sadb_ident_id usage.
* 关于sadb_ident_id用法的小澄清。
* New PFKEYV2_REVISION value.
* 新的PFKEYV2_修订值。
* Small clarification on what a PROXY address is.
* 关于什么是代理地址的小说明。
* Corrected sadb_spirange_{min,max} language.
* 修正了sadb_spirange_{min，max}语言。
* In ADD messages that are in response to an ACQUIRE, the sadb_msg_seq MUST be the same as that of the originating ACQUIRE.
* 在响应采集的ADD消息中，sadb_msg_seq必须与原始采集的sadb_msg_seq相同。
* Corrected ACQUIRE message behavior, ACQUIRE message SHOULD send up PROXY addresses when it needs them.
* 更正了ACQUIRE消息行为，ACQUIRE消息应在需要代理地址时发送代理地址。
* Clarification on SADB_EXPIRE and user-level security protocols.
* 关于SADB_过期和用户级安全协议的澄清。
The following changes were made between 03 and 04:
在03至04年间进行了以下更改：
* Stronger language about manual keying.
* 关于手动键控的更强语言。
* PFKEYV2_REVISION, ala POSIX.
* PFKEYV2_修订版，阿拉巴马州POSIX。
* Put in language about sockaddr ports in ACQUIRE messages.
* 在ACQUIRE消息中输入关于sockaddr端口的语言。
* Mention of asymmetric algorithms.
* 提到不对称算法。
* New sadb_ident_id field for easier construction of USER_FQDN identity strings.
* 新的sadb_ident_id字段用于更轻松地构造用户FQDN标识字符串。
* Caveat about source addresses not always used for collision detection. (e.g. IPsec)
* 关于不总是用于冲突检测的源地址的警告。（例如IPsec）
The following changes were made between 02 and 03:
在02和03之间进行了以下更改：
* Formatting changes.
* 格式更改。
* Many editorial cleanups, rewordings, clarifications.
* 许多编辑清理、改写、澄清。
* Restrictions that prevent many strange and invalid cases.
* 阻止许多奇怪和无效案例的限制。
* Added definitions section.
* 增加了定义部分。
* Removed connection identity type (this will reappear when it is more clear what it should look like).
* 删除的连接标识类型（当更清楚它应该是什么样子时，将重新出现）。
* Removed 5.2.1 (Why involve the kernel?).
* 删除了5.2.1（为什么涉及内核？）。
* Removed INBOUND, OUTBOUND, and FORWARD flags; they can be computed from src, dst, and proxy and you had to anyway for sanity checking.
* 删除了入站、出站和转发标志；它们可以从src、dst和proxy中计算出来，并且您必须进行健全性检查。
* Removed REPLAY flag; sadb_sa_replay==0 means the same thing.
* 删除重播标志；sadb_sa_replay==0表示相同的事情。
* Renamed bit lengths to "bits" to avoid potential confusion.
* 将位长度重命名为“位”，以避免潜在的混淆。
* Explicitly listed lengths for structures.
* 明确列出结构的长度。
* Reworked identities to always use a string format.
* 修改标识以始终使用字符串格式。
* Removed requirements for support of shutdown() and SO_USELOOPBACK.
* 删除了支持shutdown（）和SO_uselopback的要求。
* 64 bit alignment and 64 bit lengths instead of 32 bit.
* 64位对齐和64位长度，而不是32位。
* time_t replaced with uint64 in lifetimes.
* 在生命周期中，时间不会被uint64替换。
* Inserted Appendix A (SADB_X_PROMISC) and Appendix B (SAMPLE HEADER FILE).
* 插入附录A（SADB_X_PROMISC）和附录B（示例头文件）。
* Explicit error if PF_KEY_V2 not set at socket() call.
* 如果在socket（）调用中未设置PF_KEY_V2，则出现显式错误。
* More text on SO_USELOOPBACK.
* 更多关于SO_使用环回的文本。
* Made fields names and symbol names more consistent.
* 使字段名称和符号名称更加一致。
* Explicit error if PF_KEY_V2 is not in sadb_msg_version field.
* 如果PF_KEY_V2不在sadb_msg_version字段中，则出现显式错误。
* Bytes lifetime field now a 64-bit quantity.
* 字节生存期字段现在为64位数量。
* Explicit len/exttype wording.
* 显式len/exttype措辞。
* Flattening out of extensions (LIFETIME_HARD, LIFETIME_SOFT, etc.)
* 扩展的扁平化（寿命硬、寿命软等）
* UI example (0x123 == 0x1230 or 0x0123).
* UI示例（0x123==0x1230或0x0123）。
* Cleaned up and fixed some message behavior examples.
* 清理并修复了一些消息行为示例。
The following changes were made between 01 and 02:
在01和02之间进行了以下更改：
* Mentioned that people COULD use these same messages between user progs. (Also mentioned why you still might want to use the actual socket.)
* 提到人们可以在用户程序之间使用这些相同的消息。（还提到了为什么您仍然希望使用实际的套接字。）
* Various wordsmithing changes.
* 各种文字制作的变化。
* Took out netkey/ directory, and make net/pfkeyv2.h
* 取出netkey/directory，并生成net/pfkeyv2.h
* Inserted PF_KEY_V2 proto argument per C. Metz.
* 根据C.Metz插入PF_KEY_V2原型参数。
* Mentioned other socket calls and how their PF_KEY behavior is undefined.
* 提到了其他套接字调用以及它们的PF_键行为是如何定义的。
* SADB_EXPIRE now communicates both hard and soft lifetime expires.
* SADB_EXPIRE现在通信硬生命周期和软生命周期到期。
* New "association" extension, even smaller base header.
* 新的“关联”扩展，甚至更小的基本标题。
* Lifetime extension improvements.
* 寿命延长改进。
* Length now first in extensions.
* 长度现在是扩展中的第一位。
* Errors can be sent from kernel to user, also.
* 错误也可以从内核发送到用户。
* Examples section inserted.
* 插入示例部分。
* Some bitfield cleanups, including STATE and SA_OPTIONS cleanup.
* 一些位字段清理，包括状态和SA_选项清理。
* Key splitting now only across auth algorithm and encryption algorithm. Thanks for B. Sommerfeld for clues here.
* 密钥拆分现在只跨身份验证算法和加密算法。感谢B.Sommerfeld在这里提供线索。
The following changes were made between 00 and 01:
在00和01之间进行了以下更改：
* Added this change log.
* 已添加此更改日志。
* Simplified TLV header syntax.
* 简化的TLV头语法。
* Splitting of algorithms. This may be controversial, but it allows PF_KEY to be used for more than just IPsec. It also allows some kinds of policies to be placed in the KMd easier.
* 算法的分裂。这可能会引起争议，但它允许PF_密钥不仅仅用于IPsec。它还允许在KMd中放置某些类型的策略。
* Added solid definitions and formats for certificate identities, multiple keys, etc.
* 为证书标识、多个密钥等添加了可靠的定义和格式。
* Specified how keys are to be layed out (most-to-least bits).
* 指定键的布局方式（从最高位到最低位）。
* Changed sequence number semantics to be like an RPC transaction ID number.
* 将序列号语义更改为类似于RPC事务ID号。
F. Full Copyright Statement
F.完整的版权声明
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。