[要約] RFC 2367は、PF_KEY Key Management APIのバージョン2に関する仕様書です。このRFCの目的は、IPsecや他のセキュリティプロトコルのためのキーマネジメント機能を提供するためのAPIを定義することです。
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_KEYキー管理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.
Copyright（C）The Internet Society（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).
このドキュメントでは、IPセキュリティ[Atk95a] [Atk95b] [Atk95c]だけでなく、他のネットワークセキュリティサービスにも使用できる一般的なキー管理APIについて説明します。このAPIのバージョン1は、米国海軍研究所の自由に配布および使用可能なIPv6およびIPsec実装の一部として、4.4-Lite BSD内に実装されました[AMPMC96]。これは、APIを採用および使用する他の人のためにここに記載されているため、キー管理アプリケーション（たとえば、手動キーイングアプリケーション、ISAKMPデーモン、GKMPデーモン[HM97a] [HM97b]、Photurisデーモン）の移植性が向上します。 、またはSKIP証明書検出プロトコルデーモン）。
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
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_KEYは、オペレーティングシステムのキー管理内部（ここでは「キーエンジン」またはセキュリティアソシエーションデータベース（SADB）と呼ばれます）と通信するために信頼できる特権キー管理アプリケーションによって使用される新しいソケットプロトコルファミリです。キーエンジンとその構造は、セッションに必要なセキュリティ属性を組み込んでおり、[Atk95a]で説明されている "セキュリティアソシエーション"（SA）の概念のインスタンスです。したがって、PF_KEYおよびKey Engineという名前は暗号化キー以上のものを指し、従来のフレーズ「キー管理」との一貫性を保つために保持されています。
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_KEYの一部は、BSDルーティングソケットPF_ROUTEから派生しています。 [Skl91]このドキュメントでは、PF_KEYのバージョン2について説明します。バージョン1は、4.4-Lite BSD UNIXおよびCisco ISAKMP / Oakleyキー管理デーモン用のNRL IPv6 + IPsecソフトウェア配布の最初の5つのアルファテストバージョンで実装されました。バージョン2では、このインターフェースが拡張および改良されています。理論的には、このドキュメントで定義されているメッセージは、非ソケットコンテキスト（たとえば、直接通信する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_KEYは、システム全体のセキュリティポリシーを調整するためのメカニズムではありません。また、あらゆる種類のキー管理ポリシーを適用することも意図されていません。 PF_KEYの開発者は、セキュリティメカニズム（PF_KEYなど）をセキュリティポリシーから分離することが重要であると考えています。これにより、単一のメカニズムで複数のポリシーをより簡単にサポートできます。
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].
このドキュメントは実際のインターネット標準を意図したものではありませんが、このインターフェイスの特定の機能の重要性を定義するために使用される単語は通常、大文字で表記されています。 MUST、MAY、SHOULDを含むこれらの単語の一部は、[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]。 2つの用語は特別な言及に値します：
- (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_KEYの目的では、アルゴリズムは、暗号化か認証かに関係なく、SAタイプで示される認証または暗号化を完了するためにパケットに対して実行される一連の操作です。 PF_KEYアルゴリズムは、複数の暗号化アルゴリズムで構成される場合があります。別の可能性は、同じ基本的な暗号アルゴリズムが異なる動作モードまたは他のいくつかの実装の違いで適用される可能性があることです。これらの違いは、以後_algorithm differentiators_と呼ばれ、異なるPF_KEYアルゴリズムと同じアルゴリズムのオプションを区別します。アルゴリズムの差別化要因は、根本的に異なるセキュリティプロパティを引き起こすことがよくあります。
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_KEYアルゴリズムがあります。 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_KEY暗号化アルゴリズムです。 AHまたはESPトランスフォームの「認証」部分とラベル付けされているものは、おそらくPF_KEY認証アルゴリズムです。
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_KEYキー管理アプリケーションプログラミングインターフェイスを実装するオペレーティングシステムの概念モデルについて説明します。このセクションは、このドキュメントの残りの部分を理解するのに役立つ背景資料を提供することを目的としています。この概念モデルの提示は、PF_KEY実装がこのサブセクションで説明されている概念コンポーネントに厳密に従うことを強制するものではありません。
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.
キー管理は、アプリケーションレイヤーで全体的または部分的に実装されるのが最も一般的です。たとえば、IPsecキー管理に関するISAKMP / Oakley、GKMP、およびPhoturisの提案は、すべてアプリケーション層プロトコルです。手動キーイングもアプリケーション層で行われます。 SKIP IPレイヤキーイングの提案の一部でも、アプリケーションレイヤで実装できます。図1は、鍵管理デーモンとPF_KEYの関係を示しています。キー管理デーモンは、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実装は、カーネル内部インターフェイスを介して、キーエンジンに適切なセキュリティアソシエーションを要求します。 Key Engineに適切なSAがある場合、SAをこのセッションに割り当て（使用済みとしてマーク）、SAをIPsec実装に返して使用します。キーエンジンにそのようなSAはないが、キー管理アプリケーションが以前に（PF_KEY SADB_REGISTERメッセージを介して）そのようなSAを取得できることを示している場合、キーエンジンはそのようなSAの作成を（PF_KEY SADB_ACQUIREメッセージを介して）要求します。キー管理デーモンが新しいSAを作成すると、それは将来の使用のためにキーエンジンに配置されます。
+---------------+
|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_KEYの関係
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_KEYを使用してルーティングプロトコルで使用されるセキュリティアソシエーションを要求、取得、および削除する、信頼できる特権ルーティングデーモンを示しています。
+---------------+
|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_KEYの関係
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を作成できる1つ以上のキー管理アプリケーションに同様の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.
一部の実装では、実際の暗号処理はカーネルで行われますが、ポリシーはユーザー空間で実装できます。カーネルメカニズムとユーザー空間ポリシーの間のそのようなポリシー通信は、PF_KEY拡張または他のそのようなメカニズムによって実装される場合があります。このドキュメントでは、そのような拡張子を指定していません。メモで指定されたPF_KEY実装は、PF_KEYを使用したシステム全体のポリシーの構成をサポートする必要はありません。
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_KEYを使用する必要はありません。ここで指定されていないメカニズムは、そのような信頼されていないクライアントアプリケーションが、オペレーティングシステムにセキュリティサービス（IPsecなど）を要求するために使用されます。セキュリティ上の理由から、信頼できる特権アプリケーションのみがPF_KEYソケットを開くことができます。
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_KEYプロトコルファミリ（PF_KEY）シンボルは、他のプロトコルファミリが定義されているのと同じ方法で<sys / socket.h>に定義されています。 PF_KEYはソケットアドレスを使用しません。 PF_KEYを使用するアプリケーションは、AF_KEYという名前のシンボルの可用性に依存してはなりません（MUST）が、カーネルの実装では、完全性のためにそのシンボルを定義することをお勧めします。
The key management socket is created as follows:
キー管理ソケットは次のように作成されます。
#include <sys/types.h>
#include <sys/socket.h>
#include <net/pfkeyv2.h>
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_KEYドメインは現在、SOCK_RAWソケットタイプのみをサポートしています。プロトコルフィールドはPF_KEY_V2に設定する必要があります。そうしないと、EPROTONOSUPPORTが返されます。信頼できる特権プロセスだけがPF_KEYソケットを作成できます。従来のUNIXシステムでは、特権プロセスは、有効なユーザーIDがゼロのプロセスです。非MLS独自のオペレーティングシステムでは、「特権プロセス」の概念は実装定義です。マルチレベルセキュリティ（MLS）を提供すると主張するコンパートメントモードワークステーション（CMW）または他のシステムでは、PF_KEYソケット[DIA]を開くために、プロセスに「キー管理特権」が必要です。現在このような特定の特権を持たないMLSシステムは、この仕様に準拠および準拠するために、その特別な特権を追加し、PF_KEYを使用して強制する必要があります。一部のシステム、最も一般的な一部のパーソナルコンピュータには、非特権ユーザーの概念がありません。これらのシステムは、PF_KEY APIへのアクセスを許可されたプログラムを制限するための措置を講じるべきです（SHOULD）。
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_KEYソケットを使用してメッセージを送受信することにより、キーエンジンと対話します。セキュリティアソシエーション情報は、事前定義されたメッセージのセットを使用して、カーネルのセキュリティアソシエーションテーブルに挿入したり、そこから取得したりできます。通常の場合、カーネルに送信されるすべての適切な形式のメッセージは、送信者を含むすべての開いているPF_KEYソケットに返されます。不適切に形成されたメッセージはエラーになります。実装は、適切なリスナーに戻す前に、適切に形成されたメッセージを確認する必要があります。ルーティングソケットとは異なり、ほとんどのエラーは、write()またはsend()が失敗したときにerrnoフィールドではなく、応答メッセージで送信されます。 PF_KEYメッセージの配信は保証されていません。特に、カーネルバッファーまたはソケットバッファーが使い果たされ、メッセージがドロップされた場合は特にそうです。
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_KEYソケットによって受信されるのではなく、カーネルから発信されたメッセージが受信されることを示しているソケットによって受信されます。これらのメッセージは、予想される頻度で発生するため、特別です。また、実装は、すべてのPF_KEYソケットが同じ信頼ドメインにあるわけではない場合に、カーネルからの戻りメッセージをさらに制限したい場合があります。
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_KEYソケットで未定義の動作をします。これらには、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.
カーネルに新しいセキュリティアソシエーションを追加するには、2つの基本的な方法があります。最も簡単なのは、すべての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).
新しいセキュリティアソシエーションをカーネルに追加する2番目のアプローチは、アプリケーションが最初にSADB_GETSPIメッセージを使用してカーネルにセキュリティパラメータインデックス（SPI）値を要求し、次に完全なセキュリティアソシエーションデータを含むSADB_UPDATEメッセージを送信することです。この2番目のアプローチは、セキュリティアソシエーションデータ全体がわかる前に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メッセージを使用して、個々のセキュリティアソシエーションを削除できます。 SAのカテゴリまたはカーネルSAテーブル全体は、SADB_FLUSHメッセージを使用して削除できます。
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.
SADB_GETメッセージは、カーネルのキーエンジンからSA（RIP SAまたはOSPF SAなど）を取得するために、信頼されたアプリケーション層プロセス（たとえばrouted（8）またはgated（8））によって使用されます。
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 remote procedure call.
カーネルまたはアプリケーション層は、SADB_ACQUIREメッセージを使用して、SADB_REGISTERメッセージを介してカーネルに登録したアプリケーション層のキー管理プロセスによってセキュリティアソシエーションを作成するように要求できます。このACQUIREメッセージには、シーケンス番号が関連付けられています。このシーケンス番号は、どのリクエストがキー情報を取得したかを追跡するために、フォローアップSADB_GETSPI、SADB_UPDATE、およびSADB_ADDメッセージで使用する必要があります。シーケンス番号（以下で説明）は、リモートプロシージャコールのトランザクションIDに似ています。
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メッセージは、セキュリティアソシエーションの「ソフトライフタイム」または「ハードライフタイム」が期限切れになると、カーネルからキー管理アプリケーションに送信されます。鍵管理アプリケーションは、交換用SAをネゴシエートするヒントとして、ソフトライフタイムSADB_EXPIREメッセージの受信を使用して、交換用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_DUMPメッセージも定義されていますが、これは主にPF_KEYインプリメンターのデバッグを目的としており、PF_KEYの通常の操作では使用されません。
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_KEYの違いのポイントです。ルーティングソケットのセマンティクスに慣れているプログラマは、PF_KEYにいくつかの違いがあります。
* 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メッセージエラーは通常、write()操作を失敗させてエラー番号をerrnoに返す代わりに、PF_KEYメッセージで返されます。つまり、PF_KEYソケット上の他のリスナーは、別のプロセスからの要求が失敗したことを認識できるため、監査に役立ちます。これは、PF_KEYメッセージの読み取りに失敗したアプリケーションがエラーチェックを実行できないことも意味します。
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()コールによって設定されたそのようなエラーに依存してはいけません（MUST NOT）が、そのようなエラーをチェックし、適切な方法でそれらを処理する必要があります（SHOULD）。
* The entire message isn't always reflected in the reply. A SADB_ADD message is an example of this.
* メッセージ全体が常に返信に反映されるとは限りません。 SADB_ADDメッセージはこの例です。
* 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に設定しなければなりません（MUST）。元のメッセージへの応答には、元のメッセージのpidが必要です（SHOULD）。 （たとえば、SADB_ADDに対するカーネルの応答では、pidを元のSADB_ADDメッセージの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>をインクルードした結果として定義されています。このルールには1つの例外があります。記号「PF_KEY」（「AF_KEY」もカウントされる場合は2つの例外）です。これは、ヘッダーファイル<sys / socket.h>をインクルードした結果として定義されます。すべてのPF_KEYv2プリプロセッサシンボルはプレフィックス「SADB_」で始まり、すべての構造名は「sadb_」で始まります。このルールには、2つの例外があります。シンボル「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_REVISION」は、POSIXおよびX / Openで定義されている特定の値とは異なり、日付エンコードされた値です。 PFKEYV2_REVISIONの現在の値は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_」または「sadb_x_」で始まる必要があります。これらの規則に従わない実装は、この仕様に準拠していないため、いかなる要求も行わないでください。これらのルールは、<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_ROUTEソケットとは異なり、このインターフェイスでは、PF_KEYを実装するカーネル内のセキュリティアソシエーションを完全に統治するアプリケーションを使用できます。 PF_KEY実装には、PF_KEYへの何らかの手動インターフェースが必要です。これは、ここで説明するプログラムインターフェースのすべての機能を許可する必要があります（SHOULD）。
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_KEYメッセージは、ベースヘッダーとそれに続く追加のデータフィールドで構成されます。その一部はオプションである場合があります。追加データの形式は、メッセージのタイプによって異なります。
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_KEYメッセージは現在、非ネットワークマルチオクテットフィールドの特定の順序を要求していません。特に指定されていない限り（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_KEYメッセージは、基本メッセージヘッダーと、それに続くセキュリティアソシエーション固有のデータで構成されます。そのデータのタイプと長さは、一般的なタイプ-長さのエンコーディングで指定されます。
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 */
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_KEYメッセージのバージョンフィールド。これは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送信者がゼロに設定する必要があります。エラーが発生した場合、レスポンダはこのフィールドにエラーコードを格納します。これには、レスポンダがユーザー空間にいる場合も含まれます。 （たとえば、ユーザー空間のネゴシエーションが失敗した場合、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_KEYメッセージのすべてのデータの合計長が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_reserved予約済みの値。送信者はゼロに設定する必要があります。ドキュメントの後半で予約済みとラベル付けされたすべてのフィールドは、このフィールドと同じセマンティクスを持っています。
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_UPDATEメッセージをカーネルに送信する場合、プロセスはこのフィールドを2112に設定する必要があり、カーネルはそのSADB_UPDATEメッセージへの応答でこのフィールドを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_KEYバージョン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構造体はパックされており、意図したすべてのパディングがすでにあります。実装では、このドキュメントの構造に、隠しパディングを含む追加のフィールドを挿入してはなりません（MUST NOT）。これにより、拡張ヘッダーのタイプを変更せずに、既存のヘッダーを「拡張」または「拡張」する実装を禁止します。このようなサイレントパディングの挿入に対する保護策として、このドキュメントの各構造には、バイト単位のサイズでラベルが付けられています。実装におけるこれらの構造体のサイズは、リストされているサイズと一致する必要があります。
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 */
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後に続く拡張ヘッダーのタイプ。このフィールドの値については、後で詳しく説明します。値ゼロは予約されています。
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.
拡張ヘッダーのタイプには、アソシエーション、ライフタイム、アドレス、キー、アイデンティティ、感度、提案、およびサポートが含まれます。メッセージには、拡張タイプのインスタンスが1つだけ存在する必要があります。 （例：ベース、キー、ライフタイム、キーは禁止されています）。メッセージ内に拡張子が重複している場合、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.
すべての拡張定義にはこれらの2つのフィールド（lenとexttype）が含まれます。これらは一般的な拡張のインスタンスであるためです（sockaddr_inとsockaddr_in6は一般的なsockaddrのインスタンスです）。 sadb_extヘッダーは、それに続く少なくとも4バイトの拡張ヘッダーデータなしでメッセージ内に存在してはならないため（MUST）、したがって、4バイト長であるだけで問題はありません。
All extensions documented in this section MUST be implemented by a PF_KEY implementation.
このセクションに記載されているすべての拡張機能は、PF_KEY実装によって実装する必要があります。
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_FLUSHやSADB_REGISTERなど）が渡されているときと、SADB_ACQUIREメッセージ上だけです。
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 */
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_stateセキュリティアソシエーションの状態。現在定義されている状態については、このドキュメントの後半で説明します。
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_authこのセキュリティアソシエーションで使用される認証アルゴリズム。有効な認証アルゴリズムについては、このドキュメントの後半で説明します。値0は、このセキュリティアソシエーションに認証が使用されないことを意味します。
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_encryptこのセキュリティアソシエーションで使用される暗号化アルゴリズム。有効な暗号化アルゴリズムについては、このドキュメントの後半で説明します。値0は、このセキュリティアソシエーションに暗号化が使用されないことを意味します。
sadb_sa_flags A bitmap of options defined for the security association. The currently defined flags are described later in this document.
sadb_sa_flagsセキュリティアソシエーション用に定義されたオプションのビットマップ。現在定義されているフラグについては、このドキュメントの後半で説明します。
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:
Lifetime拡張機能は、このセキュリティアソシエーションの1つ以上のライフタイムバリアントを指定します。ライフタイムエクステンションが存在しない場合、関連付けのライフタイムは無限です。関連付けは、それに関連付けられたある種の存続期間を持つ必要があります（SHOULD）。ライフタイムバリアントには、ハード制限の有効期限を示すHARD、ソフト制限の有効期限を示すSOFT、および特定のセキュリティアソシエーションの現在の状態を示すCURRENTの3種類があります。 Lifetime拡張機能は次のようになります。
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_allocations CURRENTの場合、関連付けが割り当てられたさまざまな接続、エンドポイント、またはフローの数。 HARDおよびSOFTの場合、これらの数は、有効期限が切れる前に割り当てられます。接続、フロー、またはエンドポイントの概念はシステム固有です。
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_bytes CURRENTの場合、このセキュリティアソシエーションを使用して処理されたバイト数。 HARDおよびSOFTの場合、有効期限が切れる前にこのセキュリティアソシエーションを使用して処理できるバイト数。
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 CURRENTの場合、関連付けが作成された時間（秒単位）。 HARDおよびSOFTの場合、関連付けの作成後、期限が切れるまでの秒数。
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 CURRENTの場合、関連付けが最初に使用された時間（秒単位）。 HARDおよびSOFTの場合、関連付けが最初に使用されてから期限切れになるまでの秒数。
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.
ライフタイムのセマンティクスは、包括的ORで、最初に期限切れになります。つまり、バイトと時間、または複数回の値が渡された場合、これらの値の最初に到達すると、有効期限が切れます。
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:
アドレス拡張は、セキュリティアソシエーションに関連付けられている1つ以上のアドレスを指定します。アソシエーション拡張が存在する場合、送信元と宛先の両方のアドレス拡張が存在している必要があります。アドレス拡張の形式は次のとおりです。
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 */
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_KEYを実装するシステムのsockaddr構造に準拠する必要があります（SHOULD）。システムにsa_lenフィールドがある場合は、メッセージにsockaddrsを含める必要があります（SHOULD）。システムにsa_lenフィールドがない場合、sockaddrsにはsa_lenフィールドがあってはなりません（SHOULD NOT）。 AF_INET sockaddrsのsin_zeroやAF_INET6 sockaddrsのsin6_flowinfoなど、sockaddrsのすべての非アドレス情報は、ゼロに設定する必要があります。ポートのゼロ化（sin_portやsin6_portなど）は、発信元のSADB_ACQUIREメッセージを除くすべてのメッセージに対して実行する必要があります。SADB_ACQUIREメッセージは、ACQUIREメッセージを生成する関連するTCPまたはUDPセッションからのポートで埋める必要があります（SHOULD）。ポートがゼロ以外の場合、sadb_address_protoフィールド（通常はゼロ）にトランスポートプロトコルの番号を入力する必要があります。 sadb_address_prefixlenがゼロ以外の場合、アドレスには接頭辞があり（KMアクセス制御の決定でよく使用されます）、長さがsadb_address_prefixlenで指定されます。これらの追加フィールドは、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アドレスは、同じプロトコルファミリに属している必要があり、メッセージ内に常に存在するか存在しない必要があります。 PROXYアドレスは別のプロトコルファミリにある場合があり、ほとんどのセキュリティプロトコルでは、パケットの実際の発信元を表します。 （たとえば、トンネル内の内部パケットの送信元アドレス。）
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アドレスは、ユニキャストまたは未指定のアドレス（INADDR_ANYなど）である必要があります。 DSTアドレスは、任意の有効な宛先アドレス（ユニキャスト、マルチキャスト、またはブロードキャスト）にすることができます。 PROXYアドレスは、ユニキャストアドレスにする必要があります（PROXYセマンティクスが上記とは異なる場合がある実験的なセキュリティプロトコルがあります）。
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:
キー拡張は、セキュリティアソシエーションに関連付けられている1つ以上のキーを指定します。セキュリティ上のリスクがあるため、キー拡張は常にメッセージに存在するとは限りません。キー拡張の形式は次のとおりです。
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 */
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_key_bitsの値がゼロの場合、エラーが発生する必要があります。
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.
キー拡張には2つの種類があります。 AUTHバージョンは認証キー（IPsec AH、OSPF MD5など）で使用され、ENCRYPTバージョンは暗号化キー（IPsec ESPなど）で使用されます。 PF_KEYは、完全な形式の暗号鍵のみを扱い、「生の鍵素材」は扱いません。たとえば、ISAKMP / Oakleyを使用している場合、キー管理デーモンは常に、PF_KEYを介してカーネルにそれらのキーを送信する前に、Diffie-Hellman計算の結果を個別の完全に形成されたキーに変換する責任があります。このルールが作成されるのは、PF_KEYが複数のセキュリティプロトコル（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_KEYで使用されるキーにはそれらのパリティビットも含める必要があります。たとえば、これは単一の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 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.
特定のセキュリティプロトコルが1つの認証および/または1つの暗号化キーのみを必要とする場合、完全に形成されたキーは適切なキー拡張を使用して送信されます。特定のセキュリティプロトコルが同じ機能に複数のキーを必要とする場合（たとえば、2つまたは3つのキーを使用するTriple-DES、および非対称アルゴリズム）、これらの2つの完全に形成されたキーは、送信パケット処理に使用される順序で一緒に連結する必要があります。複数の鍵の場合、アルゴリズムは提供された情報に基づいて個々の鍵の長さを決定できなければなりません（MUST）。鍵の全長（使用中のアルゴリズムの知識と組み合わせた場合）は、通常、この決定を行うのに十分な情報を提供します。
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_KEYインターフェイスを介して渡されます。 Inbound処理の場合、キーが使用される正しい順序は、PF_KEYインターフェースで使用されるこの正規の連結順序とは異なる場合があります。インバウンド処理とアウトバウンド処理の両方で正しい順序でキーを使用するのは、実装の責任です。
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の3つのキーのTriple-DESセキュリティアソシエーションを使用してユニキャストを通信するノードのペアを考えます。送信側ノードのアウトバウンドSAと受信側ノードのインバウンドSAの両方に、それぞれのENCRYPTキー拡張にkey-A、key-B、key-Cの順に含まれます。アウトバウンドSAは、暗号化時に、最初にキーA、次にキーB、次にキーCを使用します。インバウンドSAは、復号化時にキーCを使用し、次にキーB、キーAを使用します。 （注：3DESは実際には暗号化-復号化-暗号化であることを認識しています。）key-A、key-B、key-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ビットのキーは3オクテットを占め、最下位の2ビットにはキーマテリアルが含まれていません。次に、5つの追加オクテットが次の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_KEYに直接関係はありませんが、キーの奇数桁の16進数表現に関するユーザーインターフェイスの問題があります。 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:
これには2オクテットのストレージが必要です。ただし、他の情報がない場合、表示される値が次のように保存されているかどうかは不明です。
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:
Identity拡張機能には、エンドポイントIDが含まれています。この情報は、ネゴシエーションで使用されるID証明書を選択するためにキー管理によって使用されます。この情報は、カーネルからネットワークセキュリティ対応アプリケーションに提供され、おそらくアクセス制御の目的で、リモートエンティティを識別します。この拡張が存在しない場合、キー管理は、アドレス拡張のアドレスがこのセキュリティアソシエーションの唯一のIDであると想定する必要があります。 Identity拡張機能は次のようになります。
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 */
sadb_ident_type The type of identity information that follows. Currently defined identity types are described later in this document.
sadb_ident_type後に続くID情報のタイプ。現在定義されているIDタイプについては、このドキュメントの後半で説明します。
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存在しない場合にID文字列の作成を支援するために使用される識別子。 POSIXユーザーID値は、このフィールドで使用されるそのような識別子の1つです。このフィールドの使用については、このドキュメントの後半で説明します。
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.
ID情報のテキスト表現を含む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;
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]; */
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:
Proposal拡張には、アルゴリズム設定の「提案された状況」が含まれています。それは次のようになります：
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)]; */
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があります。可変長IVはPF_KEY v2ではサポートされていません。ただし、提案された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;
};
/* 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_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_allocations sadb_comb_hard_allocationsこの組み合わせが受け入れられる場合、これらはそれぞれ、SOFTライフタイムとHARDライフタイムでのsadb_lifetime_allocationsの推奨値です。
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_bytes sadb_comb_hard_bytesこの組み合わせが受け入れられる場合、これらはそれぞれ、SOFTライフタイムとHARDライフタイムでのsadb_lifetime_bytesの推奨値です。
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この組み合わせが受け入れられる場合、これらはそれぞれ、SOFTライフタイムとHARDライフタイムでのsadb_lifetime_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この組み合わせが受け入れられる場合、これらはそれぞれ、SOFTライフタイムとHARDライフタイムでのsadb_lifetime_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の場合もあれば、何もないことを示します。組み合わせのフラグは、Association拡張機能のフラグと同じです。最小および最大のキーの長さ（ビット単位）は、アルゴリズムの基本的なプロパティと共に、可能な事前のポリシー決定から導出されます。一部のアルゴリズムは、ライフタイムについて何かを知っていて、ライフタイム制限を提案できるため、ライフタイム属性も組み合わせに含まれています。
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:
サポートされているアルゴリズム拡張には、システムでサポートされているすべてのアルゴリズムのリストが含まれています。これは、ネゴシエートできるアルゴリズムをキー管理に伝えます。使用可能な認証アルゴリズムはSUPPORTED_AUTH拡張機能にリストされ、使用可能な暗号化アルゴリズムはSUPPORTED_ENCRYPT拡張機能にリストされています。これらの拡張子の形式は次のとおりです。
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)]; */
This header is followed by one or more algorithm descriptions. An algorithm description looks like:
このヘッダーの後には、1つ以上のアルゴリズムの説明が続きます。アルゴリズムの説明は次のようになります。
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.
1つのPF_KEYメッセージ、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 */
sadb_spirange_min The minimum acceptable SPI value.
sadb_spirange_min許容される最小のSPI値。
sadb_spirange_max The maximum acceptable SPI value. The maximum MUST be greater than or equal to the minimum.
sadb_spirange_max最大許容SPI値。最大値は最小値以上でなければなりません（MUST）。
The following shows how the octets are laid out in a PF_KEY message. Optional fields are indicated as such.
以下は、オクテットがPF_KEYメッセージでどのように配置されるかを示しています。オプションのフィールドはそのように示されています。
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 |
+---------------+---------------+---------------+---------------+
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.
さまざまなベースヘッダーフィールドの値に応じて、ベースヘッダーの後に次の1つ以上の拡張フィールドが続く場合があります。以下のフィールドは、表示される場合、以下に示す順序で表示されるように順序付けられています。
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 |
+---------------+---------------+---------------+---------------+
The Lifetime extension
寿命延長
+---------------+---------------+---------------+---------------+
| sadb_lifetime_len | sadb_lifetime_exttype |
+---------------+---------------+---------------+---------------+
| sadb_lifetime_allocations |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| 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. <
+---------------+---------------+---------------+---------------+
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. >
+---------------+---------------+---------------+---------------+
The Identity extension
Identity拡張機能
+---------------+---------------+---------------+---------------+
| 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. >
+---------------+---------------+---------------+---------------+
The Proposal extension
プロポーザル拡張
+---------------+---------------+---------------+---------------+
| 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) |
+---------------+---------------+---------------+---------------+
+---------------+---------------+---------------+---------------+
| 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 |
+---------------+---------------+---------------+---------------+
Followed by one or more Algorithm Descriptors
1つ以上のアルゴリズム記述子が後に続きます
+---------------+---------------+---------------+---------------+
| 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 |
+---------------+---------------+---------------+---------------+
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_KEYで使用されるさまざまなシンボルと、各シンボルに関連付けられているセマンティクスを定義します。アプリケーションは、移植可能にするために記号名を使用する必要があります。示されている数値の定義は、特に明記されていない限り、例示を目的としています。数値の定義は他のシステムによって異なる場合があります。記号名は、準拠するすべての実装で同じに保つ必要があります。
The following message types are used with PF_KEY. These are defined in the file <net/pfkeyv2.h>.
次のメッセージタイプは、PF_KEYで使用されます。これらは<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
#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 /* not used normally */
#define SADB_MAX 10
#define SADB_MAX 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)>
<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.
存続期間の延長は、「lifetime」という単語の後に1文字から3文字で表され、（H）ARD、（S）OFT、および（C）URRENTを表します。
The address extensions are represented with one to three letters after the word "address," representing (S)RC, (D)ST, (P)ROXY.
アドレス拡張子は、「アドレス」という単語の後に1〜3文字で表され、（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タイプでEEXISTエラーが発生し、他のタイプでは衝突が報告されない場合があります。アプリケーションの作成者は、これらの違いを理解するために、基になるセキュリティアソシエーションタイプについて十分に理解していることが期待されます。
The key extensions are represented with one or two letters after the word "key," representing (A)UTH and (E)NCRYPT.
キーの拡張子は、「キー」という単語の後に1文字または2文字で表され、（A）UTHおよび（E）NCRYPTを表します。
The identity extensions are represented with one or two letters after the word "identity," representing (S)RC and (D)ST.
ID拡張子は、（S）RCおよび（D）STを表す「identity」という単語の後に1文字または2文字で表されます。
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:
通常、メッセージの説明に具体的にリストされているエラーの1つか、次のいずれかです。
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_UPDATEが後に続くこのメッセージは、セキュリティアソシエーションを作成する1つの方法です（SADB_ADDはもう1つの方法です）。プロセスは、ベースヘッダーのタイプ、アドレス拡張の送信元および宛先アドレスを指定します。 SADB_GETSPIメッセージがカーネルが生成したSADB_ACQUIREに応答する場合、sadb_msg_seqはSADB_ACQUIREメッセージと同じでなければなりません（MUST）。アプリケーションでSPIを指定することもできます。これは、SPI範囲拡張を使用して、SPI値の範囲内でカーネルを選択することによって行われます。検証する単一のSPI値を指定するために、アプリケーションは上限値と下限値を等しく設定します。カーネルはすでに使用中のSPI値について知っていることに基づいてSPI値を割り当てることができるため、範囲指定を許可することは重要です。カーネルは、関連付け拡張のspiフィールドに格納されている割り当てられたSPI値を使用して同じメッセージを返します。割り当てSPI（および宛先アドレス）は、LARVALセキュリティアソシエーションを参照します。 SADB_UPDATEメッセージを後で使用して、要求された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_UPDATEメッセージによって更新されない場合、一定の時間内に自動的に削除することをお勧めします。これにより、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> The kernel returns the SADB_GETSPI message to all listening processes.
<ベース、アドレス、SPI範囲>カーネルは、すべての待機プロセスにSADB_GETSPIメッセージを返します。
<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_UPDATEメッセージを使用すると、プロセスは既存のセキュリティアソシエーションの情報を更新できます。 SADB_GETSPIは特定のパラメータの設定を許可しないため、SADB_GETSPIで作成されたSADB_SASTATE_LARVALセキュリティアソシエーションを完全に形成するには、このメッセージが必要です。更新メッセージのフォーマットは、ベースヘッダーの後にアソシエーションヘッダーが続き、場合によってはいくつかの拡張ヘッダーが続きます。カーネルは、メッセージで指定された同じタイプ、spi、送信元アドレス、宛先アドレスを持つセキュリティアソシエーションを検索し、SADB_UPDATEメッセージの内容を使用してセキュリティアソシエーション情報を更新します。
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_UPDATEの成功を許可しない場合があります。このような強制により、使用中のセキュリティアソシエーションが誤って変更される可能性が大幅に減少します。悪意のある信頼できる当事者がSADB_FLUSHまたはSADB_DELETEメッセージを発行する可能性はありますが、関連付けの削除は、誤ったSADB_UPDATEよりも簡単に検出され、誤って発生する可能性が低くなります。この動作をサポートするための反論には、ユーザー空間のキー管理アプリケーションが失敗して再起動する場合が含まれます。アプリケーションの新しいインスタンスには、セキュリティアソシエーションの作成者と同じソケットはありません。
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_UPDATEメッセージで送信されたすべての重要な値を検証し、値が無効な場合はEINVALを返さなければなりません（MUST）。実行する必要があるチェックの例は、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 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.
SADB_SASTATE_MATURE SAのみがSADB_UPDATEメッセージで送信できます。元のSAがSADB_SASTATE_LARVAL SAである場合、送信元アドレス、宛先アドレス、およびSPIを除いて、SAのすべての値が変更される可能性があります。元のSAがSADB_SASTATE_DEAD SAである場合、SAでSADB_UPDATEを実行しようとすると、EINVALが返される必要があります。既存のSAを変更するのではなく、新しいSAを作成する必要があるSPIを変更せずに、確立されたキー情報またはアルゴリズム情報を変更することは無効です。キーイングおよびアルゴリズム情報がネゴシエートされると、アドレスとID情報がSAに対して修正されます。したがって、元のSAがSADB_SASTATE_MATUREまたはDYING SAである場合、SAヘッダーのサドバフィールドとライフタイム（ハード、ソフト、および現在）のみが変更される可能性があり、他の値を変更しようとすると、EINVALのエラーが返される必要があります。
The message behavior of the SADB_UPDATE message is:
SADB_UPDATEメッセージのメッセージ動作は次のとおりです。
Send an SADB_UPDATE message from a user process to the kernel.
SADB_UPDATEメッセージをユーザープロセスからカーネルに送信します。
<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_UPDATEメッセージを返します。
<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.
エラー：ESRCH更新するセキュリティアソシエーションが見つかりませんでした。 EINVAL他の考えられる原因に加えて、このエラーは、SA値（キーなど）の妥当性検査が失敗した場合に返されます。 EACCESエントリを更新するための十分な権限がありません。 SADB_UPDATEを発行するソケットは、更新されるエントリの作成者ではありません。
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_GETSPIを前に呼び出す必要がないことを除いて、SADB_UPDATEメッセージとほとんど同じです。 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 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_ADDメッセージは、ネゴシエーションが終了し、アソシエーションのペアの2番目が追加されたときにも使用されます。この関連付けのSPIは、ピアマシンによって決定されました。ペアの両方の関連付けが同じACQUIRE要求にバインドされるように、sadb_msg_seqはカーネルが生成したSADB_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_MATURE SAのみがSADB_ADDメッセージで送信できます。 SADB_SASTATE_LARVAL SAはSADB_GETSPIによって作成され、DYINGまたはSADB_SASTATE_DEAD状態で新しいSAを追加することは賢明ではありません。したがって、送信されたすべてのSAのsadb_sa_stateフィールドはSADB_SASTATE_MATUREである必要があり、これがtrueでない場合、カーネルはエラーを返す必要があります。
The message behavior of the SADB_ADD message is:
SADB_ADDメッセージのメッセージ動作は次のとおりです。
Send an SADB_ADD message from a user process to the kernel.
SADB_ADDメッセージをユーザープロセスからカーネルに送信します。
<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)>
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メッセージにより、カーネルはキーテーブルからセキュリティアソシエーションを削除します。削除メッセージは、ベースヘッダーとそれに続くアソシエーション、およびアドレス拡張の送信元と宛先の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)>
The kernel returns the SADB_DELETE message to all listening processes.
カーネルは、SADB_DELETEメッセージをすべての待機プロセスに返します。
<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)>
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)>
Errors: ESRCH The sought security association was not found.
エラー：ESRCH求められたセキュリティアソシエーションが見つかりませんでした。
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 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_ACQUIREメッセージは通常、カーネルによってのみ、キーソケットを登録したキーソケットリスナーに送信されます（SADB_REGISTERメッセージを参照）。 SADB_ACQUIREメッセージは、セキュリティアソシエーションのアプリケーションレベルのコンシューマ（OSPFセキュリティを使用するOSPFv2実装など）から送信できます。 SADB_ACQUIREメッセージは、アドレス拡張、場合によってはID拡張、および提案拡張と共にベースヘッダーになります。提案された状況には、ベースヘッダーのアルゴリズムが利用できない場合に使用できる望ましいアルゴリズムのリストが含まれています。ベースヘッダーと、ベースヘッダーに続くセキュリティアソシエーションデータのフィールドの値は、リスニングプロセスが取得しようとするセキュリティアソシエーションのプロパティを示します。メッセージがカーネルから発信された場合（つまり、sadb_msg_pidが0の場合）、後続のSADB_GETSPIとSADB_UPDATE、または後続のSADB_ADDメッセージで、セキュリティアソシエーションをリクエストにバインドするために、sadb_msg_seq番号を使用する必要があります。これにより、それぞれが一意の関連付けを必要とする2つのIPホスト間の2つのTCP接続の競合状態が回避され、一方が他方のセキュリティアソシエーションを盗むことになります。 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メッセージは提案拡張機能で可能性の優先順位を注文しなければなりません（MUST）。
There are three messaging behaviors for SADB_ACQUIRE. The first is where the kernel needs a security association (e.g. for IPsec).
SADB_ACQUIREには3つのメッセージング動作があります。 1つ目は、カーネルがセキュリティアソシエーションを必要とする場所です（IPsecなど）。
The kernel sends an SADB_ACQUIRE message to registered sockets.
カーネルは、SADB_ACQUIREメッセージを登録されたソケットに送信します。
<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.
注：address（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.
2つ目は、何らかの理由でキー管理が失敗した場合に、ゼロ以外のerrnoを持つ最初のACQUIREと同じsadb_msg_seqでACQUIREメッセージを送信できる場合です。
Send an SADB_ACQUIRE to indicate key management failure.
SADB_ACQUIREを送信して、鍵管理の失敗を示します。
<base>
<ベース>
The third is where an application-layer consumer of security associations (e.g. an OSPFv2 or RIPv2 daemon) needs a security association.
3つ目は、セキュリティアソシエーションのアプリケーション層コンシューマ（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>
The kernel returns an SADB_ACQUIRE message to registered sockets.
カーネルは、SADB_ACQUIREメッセージを登録されたソケットに返します。
<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_UPDATEまたはSADB_ADDメッセージを待ち、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要求されたSAタイプを取得できるKMアプリケーションにKMアプリケーションが登録されていないため、要求された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_REGISTERを使用すると、ソケットは、sadb_msg_satypeで指定されたセキュリティアソシエーションのタイプのSADB_ACQUIREメッセージを受信できます。アプリケーションは、登録メッセージのタイプフィールドで、カーネル用に取得できるセキュリティアソシエーションのタイプを指定します。アプリケーションが複数のタイプのセキュリティアソシエーションを取得できる場合は、各タイプを個別のメッセージに登録する必要があります。登録メッセージには、基本ヘッダーのみが必要です。キー管理アプリケーションは、コンシューマがユーザー空間にいる可能性があるため（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_REGISTERメッセージの応答には、サポートされているアルゴリズム拡張が含まれています。そのフィールドには、オクテットごとに1つ、サポートされているアルゴリズムの配列が含まれています。これにより、鍵管理アプリケーションはカーネルがサポートするアルゴリズムを知ることができます。
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_REGISTER応答が生成される場合があります。サポートされているアルゴリズムのリストは完全なリストでなければならないので、アプリケーションは省略または追加を記録できます。
The messaging behavior of the SADB_REGISTER message is:
SADB_REGISTERメッセージのメッセージング動作は次のとおりです。
Send an SADB_REGISTER message from a user process to the kernel.
ユーザープロセスからカーネルにSADB_REGISTERメッセージを送信します。
<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_REGISTERメッセージを登録済みソケットに返します。サポートされるアルゴリズムフィールドには、カーネルがサポートするアルゴリズムタイプが示されます。
NOTE: This message may arrive asynchronously due to an algorithm being loaded or unloaded into a dynamically linked kernel.
注：このメッセージは、動的にリンクされたカーネルにアルゴリズムがロードまたはアンロードされるため、非同期に到着する場合があります。
<base, supported>
<ベース、サポート>
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メッセージを発行する必要があります（SHOULD）。
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）（および存在する場合は、1つまたは両方のコンパートメントビットマップ）が含まれます。
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メッセージの存続期間の延長は、どの存続期間が満了したかを示すために重要です。 HARDライフタイム延長が含まれている場合は、HARDライフタイムが期限切れであることを示します。これは、関連付けがSADBからすでに削除されている可能性があることを意味します。 SOFTライフタイム延長が含まれている場合、それはSOFTライフタイムが期限切れであることを示します。 CURRENTライフタイム拡張は現在のステータスを示し、HARDまたはSOFTライフタイムとの比較はどの制限に達したかを示します。 HARDライフタイムはSOFTライフタイムよりも優先する必要があります。つまり、HARDとSOFTライフタイムが同じ場合、HARDライフタイムはEXPIREメッセージに表示されます。 HARDライフタイムがSOFTライフタイムよりも短いという病理学的なケースは、SOFTライフタイムが期限切れにならないように処理されます。
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)>
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_UNSPECが入力されている場合、すべての関連付けが削除されます。
The messaging behavior for SADB_FLUSH is:
SADB_FLUSHのメッセージング動作は次のとおりです。
Send an SADB_FLUSH message from a user process to the kernel.
SADB_FLUSHメッセージをユーザープロセスからカーネルに送信します。
<base>
<ベース>
The kernel will return an SADB_FLUSH message to all listening sockets.
カーネルは、すべての待機ソケットにSADB_FLUSHメッセージを返します。
<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_UNSPECを指定すると、すべての関連付けがダンプされます。各セキュリティアソシエーションは、独自のSADB_DUMPメッセージで返されます。 sadb_seqフィールドがゼロのSADB_DUMPメッセージは、ダンプトランザクションの終了を示します。ダンプメッセージはデバッグ目的でのみ使用され、実稼働での使用を目的としていません。
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_KEYの将来のバージョンで廃止される可能性があります。キー管理アプリケーションは、基本的な操作をこのメッセージに依存してはなりません（MUST NOT）。
The messaging behavior for SADB_DUMP is:
SADB_DUMPのメッセージング動作は次のとおりです。
Send an SADB_DUMP message from a user process to the kernel.
SADB_DUMPメッセージをユーザープロセスからカーネルに送信します。
<base>
<ベース>
Several SADB_DUMP messages will return from the kernel to the sending socket.
いくつかのSADB_DUMPメッセージがカーネルから送信ソケットに返されます。
<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:
セキュリティアソシエーションのフラグはビットマスクフィールドです。これらのフラグは、PROPOSAL拡張の一部である組み合わせでも表示されます。アプリケーションを移植可能にするために、以下の関連するシンボリック定義を使用する必要があります。
#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
#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
#define 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_LARVALセキュリティアソシエーションは、SADB_GETSPIメッセージによって作成されたものです。 SADB_SASTATE_MATURE関連付けは、SADB_UPDATEメッセージで更新されたか、SADB_ADDメッセージで追加された関連付けです。 DYINGアソシエーションは、ソフトライフタイムが期限切れになったアソシエーションです。 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>.
これは、このメッセージのセキュリティアソシエーションのタイプを定義します。実装が異なっていても、記号名は常に同じです。アプリケーションは、さまざまな実装間で最大の移植性を実現するために、シンボル名を使用する必要があります（SHOULD）。これらは<net / pfkeyv2.h>ファイルで定義されています。
#define SADB_SATYPE_UNSPEC 0
#define SADB_SATYPE_UNSPEC 0
#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_MAX 8
#define 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_KEY SAでは使用されません。
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
/* 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]で定義されているNULL暗号化アルゴリズムです。 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
#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_EXT_MAX 16
#define 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
#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
#define SADB_IDENTTYPE_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.
PREFIX識別文字列は、ネットワークアドレスとそれに続くスラッシュおよびプレフィックス長で構成されます。ネットワークアドレスは、プロトコルファミリに適した印刷可能な数値形式です。プレフィックス長は、ゼロ以上でネットワークアドレスのビット数未満の10進数です。重要なネットワークアドレスのビット数を示します。重要ではないネットワークアドレスのすべてのビットはゼロに設定する必要があります。複数の印刷可能な文字列が多くのプロトコルファミリで同じアドレスの有効な表現であるため、実装では、比較のために印刷可能なアドレスの内容をバイナリ形式に解析する必要があることに注意してください（たとえば、先行ゼロを許可するものや、大文字と小文字を区別しないものもある） 。 PREFIX IDの例は、「199.33.248.64/27」および「3ffe :: 1/128」です。送信元または宛先のIDがPREFIX IDの場合、SAの送信元または宛先のアドレスは（それぞれ）そのプレフィックス内にある必要があります。これらのIDタイプの場合、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 ID文字列には、完全修飾ドメイン名が含まれています。 FQDN IDの例は、「ministry-of-truth.inner.net」です。これらのIDタイプの場合、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 the numeric value.
UserFQDN IDは、インターネット標準の電子メールで一般的に使用される形式のテキスト文字列で構成されます。構文は、テキストのユーザー名の後に「@」文字が続き、その後に適切な完全修飾ドメイン名が続きます。このIDは、ユーザー名と関連するFQDNの両方を指定します。この文字列は、SMTPまたはその他の電子メールの使用に有効なメールボックスを指定する必要はありません。このIDは、ユーザー指向のキーイングをサポートするプロトコルで役立ちます。 DNSセキュリティ拡張機能を使用して、KEYおよびSIGレコードを適切なMB DNSレコードに関連付けることにより、署名された公開鍵の値を配布できるため、これは便利なIDフォームです。 UserFQDN IDの例は、「julia@ministry-of-love.inner.net」です。 sadb_ident_idフィールドは、ID文字列自体がない場合にPOSIXユーザーIDを格納するために使用されるため、ユーザーレベルのアプリケーションは、getpwuid {、_ r}()ルーチンを使用して、テキストのユーザーログインIDを取得できます。文字列が存在する場合は、sadb_ident_idフィールドの数値と一致する必要があります（SHOULD）。一致しない場合、文字列は数値をオーバーライドする必要があります（SHOULD）。
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]の「ラベル付きドメイン識別子の値」と同じになるように定義されています。その仕様に記載されているように、0x80000000から0xffffffffの範囲（両端を含む）の値は私用に予約されており、0x00000001から0x7fffffffの範囲の値はIANAによって割り当てられます。すべてゼロのDP / DOI値は、「DP / DOIが使用されていない」ことを意味するために永続的に予約されています。
These are already mentioned in the Algorithm Types and Security Association Flags sections.
これらについては、アルゴリズムの種類とセキュリティアソシエーションフラグのセクションで既に説明しています。
4 Future Directions
4今後の方向性
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_KEYの将来のバージョンで変更が生じる可能性があります。
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_KEYには、将来、他の種類のセキュリティアソシエーションと連携するための拡張機能が必要になる可能性があります。そのような拡張が必要な場合は、下位互換性のある方法で行うことが強く望まれます。
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.
証明書管理で経験を積むと、IDの拡張を再検討して、証明書IDをよりきめ細かく選択できるようになる可能性があります。
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 particular implementation method.
次の例は、PF_KEYの使用方法を示しています。最初の例はIPセキュリティの例で、セキュリティアソシエーションのコンシューマはオペレーティングシステムカーネル内にあります。 2番目の例はOSPFセキュリティの例で、セキュリティアソシエーションのユーザーレベルのコンシューマを示しています。 3番目の例は、最初の2つの例では言及されていないものをカバーしています。実際のシステムは、これらの例の1つに厳密に準拠している場合もあれば、その一部を使用している場合もあります。これらの例は純粋に説明のためのものであり、特定の実装方法を義務付けることを意図したものではありません。
+---------------+ +-------------+
|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）が開始したとき。 2つのIPsecサービス、AHとESPのメッセージを受け入れる用意があることをPF_KEYに通知する必要があります。これは、2つのSADB_REGISTERメッセージを送信することによって行われます。
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).
各REGISTERメッセージは、ESPおよびAH（リクエスターを含む）にそれぞれ登録されたすべてのPF_KEYソケットに応答を送ります。
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
カーネル->登録済み：AH、addrs、ID、sens、提案用のSADB_ACQUIRE
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はACQUIREメッセージ、特にsadb_msg_seq番号を読み取ります。ネゴシエーションを開始する前に、SAQUIBで受信したものと等しいsadb_msg_seq番号を含むSADB_GETSPIメッセージを送信します。カーネルは、GETSPIの結果をすべての待機ソケットに返します。
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値の両方向が必要な場合、2番目のGETSPI操作を実行することがあります。これで、KMdは少なくとも1つのセキュリティアソシエーションのSPIを持っているので、ネゴシエーションを開始します。キー生成情報を取得し、他のパラメーターをネゴシエートした後、sadb_msg_seqに同じ値を持つ1つ（または複数）のSADB_UPDATEメッセージを送信します。
If a KMd has any error at all during its negotiation, it can send down:
KMdのネゴシエーション中にエラーが発生した場合、KMdは以下を送信できます。
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.>
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.
UPDATEの結果（実際のキーを差し引いたもの）は、すべての待機ソケットに送信されます。 1つのSPI値のみがローカルで決定された場合、他のSPI（IPsec SAは単一方向であるため）をSADB_ADDメッセージで追加する必要があります。
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.
渡された拡張の1つが存続期間拡張であった場合、ある時点で、存続期間の1つが満了したときにSADB_EXPIREメッセージが到着する可能性があります。
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_UPDATEをライフタイム延長とともに送信します。
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
Key: A "outside" host that implements IPsec B "firewall" that implements IPsec C "inside" host that does not implement IPsec
キー：IPsecを実装する「外部」ホスト、IPsecを実装しない「内部」ホスト、IPsec Bを実装する「ファイアウォール」
=== 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レコードを使用することは、これを発見するための1つの方法かもしれません）。
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
Aを支配するESPトンネルモードの送信元IDのSAタイプ（例：Aのアドレス）Bを支配する宛先ID（例：Bのアドレス）Aの送信元アドレス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
ESPトンネルモードのSAタイプCを支配する送信元ID Bの送信元アドレスを支配する送信先ID Aの宛先アドレスAのプロキシアドレス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.
この2番目のSA（CからAに向かって流れるパケットの場合）では、ノードAは、内部ソースアドレスがそれらのパケットで使用されるSAのソースIDによって支配されていることを確認する必要があります。ノードAがこれを行わない場合、攻撃者は任意のソースIDを使用してパケットを偽造し、IPsecによって提供されるパケットの発信元保護を無効にする可能性があります。
Now consider a slightly more complex case:
次に、もう少し複雑なケースを考えます。
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
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 ASPを支配するESPソースアイデンティティのタイプBのCソースアドレスを支配する宛先ID Cの宛先アドレス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トンネルモードのソースID D_1を支配する宛先IDがBを支配する宛先ID Cの宛先アドレスBの宛先アドレス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アドレスに対するソースIDの同じチェックを実行する必要があります。
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の完全修飾ドメイン名を表すものとします。 HがHのIPアドレスを表すものとします。HsがHaを含むIPサブネットを表すものとします。 HdがHの完全修飾ドメイン名の親である完全修飾ドメイン名を表すとします。Mを、右側がHnまたはHaであるUserFQDN IDとします。
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は、Hsで表されるIPアドレス範囲内の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 |
+------------+ | | +---------+
+-----------------+
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_KEYを介して自身をキーエンジンに登録します。セキュリティアソシエーションのコンシューマはユーザー空間にありますが、PF_KEYおよびキーエンジンの実装は、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.>
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>
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はこれを確認し、前の例と同様のアクションを実行します。ただし、1つの違いは、UPDATEメッセージが返されると、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.
一部のメッセージは、システムメンテナンスプログラム、デバッグ、または監査でのみ有効です。侵害が検出されたなどのシステムパニック状況では、SADB_FLUSHメッセージが特定のSAタイプまたはすべてのSAタイプに対して発行されます。
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
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_DUMPメッセージの一般的な使用はお勧めしません。ただし、デバッグには非常に役立ちます。ソケットバッファのオーバーフローを回避するために、DUMPメッセージの出力をすばやく読み取る必要があります。
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_KEY実装の正確さ、およびPF_KEYに接続するアプリケーションのセキュリティと正確さに完全に依存することを理解する必要があります。オペレーティングシステムのPF_KEYおよび関連するセキュリティアソシエーションコンポーネントを実装する場合は、高保証の開発手法を使用することが適切です。
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_KEY開発への継続的な支援に本当に感謝しています。そのサポートがなければ、PF_KEYは存在しません。
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_KEYメーリングリストで説明されています。このリストに追加したい場合は、<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、「Implementation of IPv6 in 4.4-Lite BSD」、Proceedings of the 1996 USENIX Conference、San Diego、 CA、1996年1月、USENIX協会。
[Atk95a] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
[Atk95a] Atkinson、R。、「IP Security Architecture」、RFC 1825、1995年8月。
[Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[Atk95b] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[Atk95c] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[Atk95c] Atkinson、R。、「IP Encapsulating Security Payload」、RFC 1827、1995年8月。
[Atk97] Atkinson, R., "Key Exchange Delegation Record for the Domain Name System", RFC 2230, October 1997.
[Atk97] Atkinson、R。、「Key Name Delegation Record for the Domain Name System」、RFC 2230、1997年10月。
[BA97] Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[BA97]ベイカー、F。、およびR.アトキンソン、「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 Corporation、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.エリオットベルとレナードJ.ラパドゥラ、「セキュリティで保護されたコンピュータシステム：統一された博覧会とMulticsの解釈」、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.クラークおよびD. R.ウィルソン、「商用および軍事用コンピューターセキュリティポリシーの比較」、セキュリティとプライバシーに関する1987年シンポジウムの議事録、pp。184-195、IEEEコンピューター協会、ワシントン、ワシントンD.C.、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、「NULL暗号化アルゴリズムとIPsecでのその使用」、進行中。
[HM97a] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[HM97a] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）Specification」、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、「Group Key Management Protocol（GKMP）Architecture」、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 2328、1998年4月。
[Per97] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[Per97]パーキンス、C。、「IPモビリティサポート」、RFC 2002、1996年10月。
[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", Work in Progress.
[Pip98]パイパー、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、進行中の作業。
[Sch96] Bruce Schneier, Applied Cryptography, p. 360, John Wiley & Sons, Inc., 1996.
[Sch96] Bruce Schneier、Applied Cryptography、p。 360、John Wiley＆Sons、Inc.、1996年。
[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]キーススクロウアー、「バークレーUNIXのツリーベースのパケットルーティングテーブル」、1991年冬のUSENIX会議の議事録、テキサス州ダラス、USENIX協会。 1991. pp。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 San Antonio Road、MS UMPK17-202 Palo Alto、CA 94303
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 Overlook Ave. SWワシントンDC 20375
Phone: (DSN) 754-8590 EMail: cmetz@inner.net
電話：（DSN）754-8590メール：cmetz@inner.net
Bao G. Phan U. S. Naval Research Laboratory
バオG.ファンU. S.海軍研究所
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_KEYをサポートするカーネルは、開発とデバッグの目的で次の拡張機能を実装してもよい（MAY）。その場合は、ここで指定されている拡張機能を実装する必要があります。実装は、無差別送信および/または受信操作を実行するために、アプリケーションに追加の特権を必要とする場合があります。
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メッセージを使用すると、アプリケーションは「プロミスキャスモード」でメッセージを送受信できます。このメッセージには、制御とデータの2つの形式があります。制御フォームはメッセージヘッダーのみで構成されます。このメッセージは、無差別受信機能を切り替えるために使用されます。 sadb_msg_satypeフィールドの値が1の場合、このソケットの無差別メッセージ受信が有効になり、そのフィールドの値が0の場合、ソケットは無効になります。
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.
このメッセージの2番目の形式はデータ形式です。これは、生の形式でメッセージを送受信するために使用されます。データフォームのメッセージは、メッセージヘッダーとそれに続く完全な新しいメッセージで構成されます。行には2つのメッセージヘッダーがあります。1つはSADB_X_PROMISCメッセージ用で、もう1つはペイロードメッセージ用です。
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_KEYソケット、またはsadb_msg_seqがゼロの場合はすべてのPF_KEYソケットに送信されます。これらのメッセージは、PF_KEYインターフェースによる内容の処理なしに送信されます（正常性チェックを含む）。この無差別送信機能により、アプリケーションはカーネルのようにメッセージを送信できます。これにより、誤ったメッセージを送信することもできます。
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_KEYを介して送信されたメッセージのコピーが無差別アプリケーションに送信されます。これは、PF_KEYインターフェイスによるメッセージのコンテンツの処理の前に行われます（これも、正常性チェックを含みます）。この無差別受信機能により、アプリケーションは、PF_KEYを使用して他のパーティから送信されたすべてのメッセージを受信できます。
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>
<ベース>
The kernel returns the SADB_X_PROMISC message to all listening processes.
カーネルは、SADB_X_PROMISCメッセージをすべての待機プロセスに返します。
<base>
<ベース>
Send a data-form SADB_X_PROMISC message from a user process to the kernel.
データ形式のSADB_X_PROMISCメッセージをユーザープロセスからカーネルに送信します。
<base, base(, others)>
The kernel sends the encapsulated message to the target process(s).
カーネルは、カプセル化されたメッセージをターゲットプロセスに送信します。
<base(, others)>
If promiscuous-receive is enabled, the kernel will encapsulate and send copies of all messages sent via the PF_KEY interface.
無差別受信が有効な場合、カーネルはPF_KEYインターフェースを介して送信されたすべてのメッセージのコピーをカプセル化して送信します。
<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_KEYバージョン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_KEYソケットに示します。 SADB_ACQUIREとは異なり、このメッセージは単なる情報であり、他のPF_KEY対話を要求しません。
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_proposal拡張が付いています。パッシブセッションが消えるか、デフォルトの動作に戻ると、SADB_X_PCHANGEが_no_ sadb_proposal拡張付きで発行され、システム全体のデフォルトの動作に対する例外がなくなったことを示します。
There are two messaging behaviors for SADB_X_PCHANGE. The first is the kernel-originated case:
SADB_X_PCHANGEには2つのメッセージング動作があります。 1つ目は、カーネルに起因するケースです。
The kernel sends an SADB_X_PCHANGE message to registered sockets.
カーネルはSADB_X_PCHANGEメッセージを登録済みソケットに送信します。
<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.
注：address（SD）拡張には、必要に応じて、キーを必要とするセッションのポート番号が入力されたポートフィールドが必要です。
The second is for a user-level consumer of SAs.
2つ目は、SAのユーザーレベルのコンシューマー向けです。
Send an SADB_X_PCHANGE message from a user process to the kernel.
ユーザープロセスからカーネルにSADB_X_PCHANGEメッセージを送信します。
<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)>
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:
Key Management Private Data拡張機能は、SADB_ADDまたはSADB_UPDATEメッセージに添付されます。セキュリティアソシエーションに任意のデータを1つ添付します。これは、SADB_DUMPまたはSADB_GETメッセージを使用して、クラッシュ後に再起動または回復する必要がある場合に、追加の状態を取得できる主要な管理アプリケーションに役立つことがあります。この拡張子の形式は次のとおりです。
#define SADB_X_EXT_KMPRIVATE 17
#define SADB_X_EXT_KMPRIVATE 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 */
/* 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
#define PF_KEY_V2 2 #define PFKEYV2_REVISION 199806L
#define PF_KEY_V2 2 #define PFKEYV2_REVISION 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
#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 10＃define SADB_FLUSH 10DUdefine SADB_FLUSH 9DU SADB_X_PCHANGE 12 #define SADB_MAX 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_ext {
uint16_t sadb_ext_len;
uint16_t sadb_ext_type;
};
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_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_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_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;
};
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_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_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;
};
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
#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
#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
#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
#define SADB_SAFLAGS_PFS 1
#define SADB_SAFLAGS_PFS 1
#define SADB_AALG_NONE 0 #define SADB_AALG_MD5HMAC 2 #define SADB_AALG_SHA1HMAC 3
#define SADB_AALG_NONE 0 #define SADB_AALG_MD5HMAC 2 #define SADB_AALG_SHA1HMAC 3
#define SADB_AALG_MAX 3
#define SADB_AALG_MAX 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
#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
#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
#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
#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-Draftの参照をすべて削除しました。標準化された引用文字列。次に、MUSTなどについてRFC 2119を引用します。
* New appendix on optional KM private data extension.
* オプションのKMプライベートデータ拡張に関する新しい付録。
* Fixed example to indicate the ACQUIRE messages with errno mean KM failure.
* errnoのあるACQUIREメッセージがKMの失敗を意味するように修正された例。
* 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.)
* 内部パケットの送信元アドレスであるPROXYアドレスの定義と一致するようにプロキシの例を明確にしました。 （基本的にはサインフリップです。この例は、トンネルエンドポイントのポリシーの脆弱性から保護する方法を示しています。）
* Loosened definition of a destination address to include broadcast.
* ブロードキャストを含める宛先アドレスの定義を緩めました。
* Recommended that LARVAL security associations have implicit short lifetimes.
* LARVALセキュリティアソシエーションのライフタイムは暗黙的に短くすることをお勧めします。
The following changes were made between 04 and 05:
04と05の間で次の変更が行われました。
* New appendix on Passive Change message.
* パッシブ変更メッセージに関する新しい付録。
* New sadb_address_prefixlen field.
* 新しいsadb_address_prefixlenフィールド。
* Small clarifications on sadb_ident_id usage.
* sadb_ident_idの使用に関する小さな説明。
* New PFKEYV2_REVISION value.
* 新しいPFKEYV2_REVISION値。
* Small clarification on what a PROXY address is.
* PROXYアドレスとは何かに関する小さな説明。
* 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.
* ACQUIREに応答するADDメッセージでは、sadb_msg_seqは元のACQUIREのメッセージと同じである必要があります。
* Corrected ACQUIRE message behavior, ACQUIRE message SHOULD send up PROXY addresses when it needs them.
* ACQUIREメッセージの動作が修正されました。ACQUIREメッセージは、必要なときにプロキシアドレスを送信する必要があります（SHOULD）。
* Clarification on SADB_EXPIRE and user-level security protocols.
* SADB_EXPIREおよびユーザーレベルのセキュリティプロトコルに関する説明。
The following changes were made between 03 and 04:
03と04の間で次の変更が行われました。
* Stronger language about manual keying.
* 手動キーイングに関するより強力な表現。
* PFKEYV2_REVISION, ala POSIX.
* PFKEYV2_REVISION、ala 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.
* USER_FQDN ID文字列を簡単に作成するための新しいsadb_ident_idフィールド。
* 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).
* 接続IDタイプを削除しました（これは、それがどのように見えるべきかがより明確になったときに再表示されます）。
* 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.
* INBOUND、OUTBOUND、およびFORWARDフラグを削除しました。それらはsrc、dst、proxyから計算でき、とにかく健全性チェックを行わなければなりませんでした。
* Removed REPLAY flag; sadb_sa_replay==0 means the same thing.
* REPLAYフラグを削除しました。 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.
* 常に文字列形式を使用するようにIDを作り直しました。
* Removed requirements for support of shutdown() and SO_USELOOPBACK.
* shutdown()およびSO_USELOOPBACKのサポートの要件を削除しました。
* 64 bit alignment and 64 bit lengths instead of 32 bit.
* 32ビットではなく、64ビットアライメントと64ビット長。
* time_t replaced with uint64 in lifetimes.
* ライフタイムでtime_tが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.
* PF_KEY_V2がsocket()呼び出しで設定されていない場合の明示的なエラー。
* More text on SO_USELOOPBACK.
* SO_USELOOPBACKに関する詳細なテキスト。
* 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.)
* 拡張機能からの平坦化（LIFETIME_HARD、LIFETIME_SOFTなど）
* 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 /ディレクトリを取り出し、net / pfkeyv2.hを作成しました
* Inserted PF_KEY_V2 proto argument per C. Metz.
* C. MetzによるPF_KEY_V2 proto引数を挿入しました。
* Mentioned other socket calls and how their PF_KEY behavior is undefined.
* 他のソケット呼び出しとそれらのPF_KEY動作が未定義である方法について言及しました。
* 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.
* STATEおよびSA_OPTIONSのクリーンアップを含む、いくつかのビットフィールドのクリーンアップ。
* 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_KEYをIPsec以外にも使用できるようにします。また、ある種のポリシーをKMdに簡単に配置できます。
* Added solid definitions and formats for certificate identities, multiple keys, etc.
* 証明書のID、複数の鍵などの明確な定義と形式を追加しました。
* 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.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。