[要約] RFC 2401は、インターネットプロトコルのセキュリティアーキテクチャに関する標準化文書であり、IP通信のセキュリティを確保するためのガイドラインを提供しています。目的は、データの機密性、完全性、認証、およびアクセス制御を確保し、ネットワーク上の通信を保護することです。
Network Working Group S. Kent
Request for Comments: 2401 BBN Corp
Obsoletes: 1825 R. Atkinson
Category: Standards Track @Home Network
November 1998
Security Architecture for the Internet Protocol
インターネットプロトコルのセキュリティアーキテクチャ
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Table of Contents
目次
1. Introduction........................................................3
1.1 Summary of Contents of Document..................................3
1.2 Audience.........................................................3
1.3 Related Documents................................................4
2. Design Objectives...................................................4
2.1 Goals/Objectives/Requirements/Problem Description................4
2.2 Caveats and Assumptions..........................................5
3. System Overview.....................................................5
3.1 What IPsec Does..................................................6
3.2 How IPsec Works..................................................6
3.3 Where IPsec May Be Implemented...................................7
4. Security Associations...............................................8
4.1 Definition and Scope.............................................8
4.2 Security Association Functionality..............................10
4.3 Combining Security Associations.................................11
4.4 Security Association Databases..................................13
4.4.1 The Security Policy Database (SPD).........................14
4.4.2 Selectors..................................................17
4.4.3 Security Association Database (SAD)........................21
4.5 Basic Combinations of Security Associations.....................24
4.6 SA and Key Management...........................................26
4.6.1 Manual Techniques..........................................27
4.6.2 Automated SA and Key Management............................27
4.6.3 Locating a Security Gateway................................28
4.7 Security Associations and Multicast.............................29
5. IP Traffic Processing..............................................30
5.1 Outbound IP Traffic Processing..................................30
5.1.1 Selecting and Using an SA or SA Bundle.....................30
5.1.2 Header Construction for Tunnel Mode........................31
5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31
5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32
5.2 Processing Inbound IP Traffic...................................33
5.2.1 Selecting and Using an SA or SA Bundle.....................33
5.2.2 Handling of AH and ESP tunnels.............................34
6. ICMP Processing (relevant to IPsec)................................35
6.1 PMTU/DF Processing..............................................36
6.1.1 DF Bit.....................................................36
6.1.2 Path MTU Discovery (PMTU)..................................36
6.1.2.1 Propagation of PMTU...................................36
6.1.2.2 Calculation of PMTU...................................37
6.1.2.3 Granularity of PMTU Processing........................37
6.1.2.4 PMTU Aging............................................38
7. Auditing...........................................................39
8. Use in Systems Supporting Information Flow Security................39
8.1 Relationship Between Security Associations and Data Sensitivity.40
8.2 Sensitivity Consistency Checking................................40
8.3 Additional MLS Attributes for Security Association Databases....41
8.4 Additional Inbound Processing Steps for MLS Networking..........41
8.5 Additional Outbound Processing Steps for MLS Networking.........41
8.6 Additional MLS Processing for Security Gateways.................42
9. Performance Issues.................................................42
10. Conformance Requirements..........................................43
11. Security Considerations...........................................43
12. Differences from RFC 1825.........................................43
Acknowledgements......................................................44
Appendix A -- Glossary................................................45
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48
B.1 DF bit..........................................................48
B.2 Fragmentation...................................................48
B.3 Path MTU Discovery..............................................52
B.3.1 Identifying the Originating Host(s)........................53
B.3.2 Calculation of PMTU........................................55
B.3.3 Granularity of Maintaining PMTU Data.......................56
B.3.4 Per Socket Maintenance of PMTU Data........................57
B.3.5 Delivery of PMTU Data to the Transport Layer...............57
B.3.6 Aging of PMTU Data.........................................57
Appendix C -- Sequence Space Window Code Example......................58
Appendix D -- Categorization of ICMP messages.........................60
References............................................................63
Disclaimer............................................................64
Author Information....................................................65
Full Copyright Statement..............................................66
This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality. Additional RFCs (see Section 1.3 for pointers to other documents) define the protocols in (a), (c), and (d).
このメモは、IPsec準拠システムの基本アーキテクチャを指定しています。アーキテクチャの目標は、IPv4環境とIPv6環境の両方で、IP層のトラフィックにさまざまなセキュリティサービスを提供することです。このドキュメントでは、そのようなシステムの目的、それらのコンポーネント、およびそれらが相互に、またIP環境にどのように適合するかについて説明します。また、IPsecプロトコルによって提供されるセキュリティサービス、およびこれらのサービスをIP環境で使用する方法についても説明します。このドキュメントでは、IPsecアーキテクチャのすべての側面を取り上げているわけではありません。以降のドキュメントでは、NAT環境でのIPsecの使用やIPマルチキャストのより完全なサポートなど、より高度な性質の追加のアーキテクチャの詳細について説明します。 IPsecセキュリティアーキテクチャの次の基本的なコンポーネントは、それらの基盤となる必要な機能の観点から説明されています。追加のRFC（他のドキュメントへのポインタについてはセクション1.3を参照）は、（a）、（c）、および（d）でプロトコルを定義します。
a. Security Protocols -- Authentication Header (AH) and Encapsulating Security Payload (ESP) b. Security Associations -- what they are and how they work, how they are managed, associated processing c. Key Management -- manual and automatic (The Internet Key Exchange (IKE)) d. Algorithms for authentication and encryption
a。セキュリティプロトコル-認証ヘッダー（AH）およびカプセル化セキュリティペイロード（ESP）b。セキュリティアソシエーション-それらとは何か、どのように機能するか、どのように管理されるか、関連する処理c。キー管理-手動および自動（インターネットキーエクスチェンジ（IKE））d。認証と暗号化のアルゴリズム
This document is not an overall Security Architecture for the Internet; it addresses security only at the IP layer, provided through the use of a combination of cryptographic and protocol security mechanisms.
このドキュメントは、インターネットの全体的なセキュリティアーキテクチャではありません。暗号化とプロトコルのセキュリティメカニズムの組み合わせを使用して提供されるIP層でのみセキュリティに対処します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、RFC 2119 [Bra97]に記載されているとおりに解釈されます。
The target audience for this document includes implementers of this IP security technology and others interested in gaining a general background understanding of this system. In particular, prospective users of this technology (end users or system administrators) are part of the target audience. A glossary is provided as an appendix to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol, related networking technology, and general security terms and concepts.
このドキュメントの対象読者には、このIPセキュリティテクノロジーの実装者や、このシステムの一般的な背景を理解することに関心のある他の人が含まれます。特に、このテクノロジの見込みユーザー（エンドユーザーまたはシステム管理者）は、対象読者の一部です。用語集は、背景/語彙のギャップを埋めるのに役立つ付録として提供されています。このドキュメントは、読者がインターネットプロトコル、関連するネットワークテクノロジー、および一般的なセキュリティの用語と概念に精通していることを前提としています。
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their inter-relationship. They include RFCs on the following topics:
上記のように、他のドキュメントはIPsecのコンポーネントのいくつかとそれらの相互関係の詳細な定義を提供します。以下のトピックに関するRFCが含まれています。
a. "IP Security Document Roadmap" [TDG97] -- a document providing guidelines for specifications describing encryption and authentication algorithms used in this system. b. security protocols -- RFCs describing the Authentication Header (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b] protocols. c. algorithms for authentication and encryption -- a separate RFC for each algorithm. d. automatic key management -- RFCs on "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination Protocol" [Orm97], and "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98].
a。 「IPセキュリティドキュメントロードマップ」[TDG97]-このシステムで使用される暗号化および認証アルゴリズムを説明する仕様のガイドラインを提供するドキュメント。 b。セキュリティプロトコル-認証ヘッダー（AH）[KA98a]およびカプセル化セキュリティペイロード（ESP）[KA98b]プロトコルを説明するRFC。 c。認証と暗号化のアルゴリズム-各アルゴリズムの個別のRFC。 d。自動キー管理-「インターネットキーエクスチェンジ（IKE）」[HC98]、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）」[MSST97]、「The OAKLEYキー決定プロトコル」[Orm97]、および「 ISAKMPのインターネットIPセキュリティ解釈ドメイン」[Pip98]。
IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, protection against replays (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection for IP and/or upper layer protocols.
IPsecは、IPv4とIPv6に相互運用可能な高品質の暗号ベースのセキュリティを提供するように設計されています。提供される一連のセキュリティサービスには、アクセス制御、コネクションレス整合性、データ発信元認証、リプレイからの保護（部分的なシーケンス整合性の形式）、機密性（暗号化）、および制限されたトラフィックフローの機密性が含まれます。これらのサービスはIP層で提供され、IPおよび/または上位層プロトコルの保護を提供します。
These objectives are met through the use of two traffic security protocols, the Authentication Header (AH) and the Encapsulating Security Payload (ESP), and through the use of cryptographic key management procedures and protocols. The set of IPsec protocols employed in any context, and the ways in which they are employed, will be determined by the security and system requirements of users, applications, and/or sites/organizations.
これらの目的は、認証ヘッダー（AH）とカプセル化セキュリティペイロード（ESP）の2つのトラフィックセキュリティプロトコルの使用、および暗号化キー管理手順とプロトコルの使用によって満たされます。あらゆるコンテキストで使用されるIPsecプロトコルのセット、およびそれらが使用される方法は、ユーザー、アプリケーション、および/またはサイト/組織のセキュリティおよびシステム要件によって決定されます。
When these mechanisms are correctly implemented and deployed, they ought not to adversely affect users, hosts, and other Internet components that do not employ these security mechanisms for protection of their traffic. These mechanisms also are designed to be algorithm-independent. This modularity permits selection of different sets of algorithms without affecting the other parts of the implementation. For example, different user communities may select different sets of algorithms (creating cliques) if required.
これらのメカニズムが正しく実装および展開されていれば、トラフィックを保護するためにこれらのセキュリティメカニズムを採用していないユーザー、ホスト、およびその他のインターネットコンポーネントに悪影響を与えるべきではありません。これらのメカニズムは、アルゴリズムに依存しないようにも設計されています。このモジュール性により、実装の他の部分に影響を与えることなく、アルゴリズムの異なるセットを選択できます。たとえば、必要に応じて、さまざまなユーザーコミュニティがさまざまなアルゴリズムのセット（クリークを作成）を選択できます。
A standard set of default algorithms is specified to facilitate interoperability in the global Internet. The use of these algorithms, in conjunction with IPsec traffic protection and key management protocols, is intended to permit system and application developers to deploy high quality, Internet layer, cryptographic security technology.
グローバルインターネットでの相互運用性を促進するために、デフォルトのアルゴリズムの標準セットが指定されています。これらのアルゴリズムをIPsecトラフィック保護およびキー管理プロトコルと組み合わせて使用すると、システムおよびアプリケーションの開発者が高品質のインターネットレイヤーの暗号化セキュリティテクノロジーを展開できるようになります。
The suite of IPsec protocols and associated default algorithms are designed to provide high quality security for Internet traffic. However, the security offered by use of these protocols ultimately depends on the quality of the their implementation, which is outside the scope of this set of standards. Moreover, the security of a computer system or network is a function of many factors, including personnel, physical, procedural, compromising emanations, and computer security practices. Thus IPsec is only one part of an overall system security architecture.
IPsecプロトコルのスイートと関連するデフォルトのアルゴリズムは、インターネットトラフィックに高品質のセキュリティを提供するように設計されています。ただし、これらのプロトコルの使用によって提供されるセキュリティは、最終的には実装の品質に依存します。これは、この一連の標準の範囲外です。さらに、コンピューターシステムまたはネットワークのセキュリティは、人員、物理的、手続き的、妥協的な発散、コンピューターのセキュリティ慣行など、多くの要因の関数です。したがって、IPsecはシステムセキュリティアーキテクチャ全体の一部にすぎません。
Finally, the security afforded by the use of IPsec is critically dependent on many aspects of the operating environment in which the IPsec implementation executes. For example, defects in OS security, poor quality of random number sources, sloppy system management protocols and practices, etc. can all degrade the security provided by IPsec. As above, none of these environmental attributes are within the scope of this or other IPsec standards.
最後に、IPsecの使用によって提供されるセキュリティは、IPsec実装が実行されるオペレーティング環境の多くの側面に大きく依存しています。たとえば、OSセキュリティの欠陥、乱数ソースの質の悪さ、ずさんなシステム管理プロトコルとプラクティスなどはすべて、IPsecによって提供されるセキュリティを低下させる可能性があります。上記のように、これらの環境属性はいずれも、このまたは他のIPsec標準の範囲内にありません。
This section provides a high level description of how IPsec works, the components of the system, and how they fit together to provide the security services noted above. The goal of this description is to enable the reader to "picture" the overall process/system, see how it fits into the IP environment, and to provide context for later sections of this document, which describe each of the components in more detail.
このセクションでは、IPsecの仕組み、システムのコンポーネント、およびそれらがどのように組み合わされて上記のセキュリティサービスを提供するかについて、概要を説明します。この説明の目的は、読者がプロセス/システム全体を「描写」し、それがIP環境にどのように適合するかを確認し、各コンポーネントをより詳細に説明するこのドキュメントの後半のセクションにコンテキストを提供することです。
An IPsec implementation operates in a host or a security gateway environment, affording protection to IP traffic. The protection offered is based on requirements defined by a Security Policy Database (SPD) established and maintained by a user or system administrator, or by an application operating within constraints established by either of the above. In general, packets are selected for one of three processing modes based on IP and transport layer header information (Selectors, Section 4.4.2) matched against entries in the database (SPD). Each packet is either afforded IPsec security services, discarded, or allowed to bypass IPsec, based on the applicable database policies identified by the Selectors.
IPsec実装はホストまたはセキュリティゲートウェイ環境で動作し、IPトラフィックを保護します。提供される保護は、ユーザーまたはシステム管理者によって確立および維持されるセキュリティポリシーデータベース（SPD）、または上記のいずれかによって確立された制約内で動作するアプリケーションによって定義される要件に基づいています。一般に、パケットは、データベース（SPD）のエントリと照合されるIPおよびトランスポート層ヘッダー情報（セレクター、セクション4.4.2）に基づいて、3つの処理モードのいずれかで選択されます。各パケットは、セレクターによって識別された該当するデータベースポリシーに基づいて、IPsecセキュリティサービスが提供されるか、破棄されるか、IPsecをバイパスすることが許可されます。
IPsec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. IPsec can be used to protect one or more "paths" between a pair of hosts, between a pair of security gateways, or between a security gateway and a host. (The term "security gateway" is used throughout the IPsec documents to refer to an intermediate system that implements IPsec protocols. For example, a router or a firewall implementing IPsec is a security gateway.)
IPsecは、システムが必要なセキュリティプロトコルを選択し、サービスに使用するアルゴリズムを決定し、要求されたサービスを提供するために必要な暗号化キーを配置できるようにすることで、IP層でセキュリティサービスを提供します。 IPsecは、ホストのペア間、セキュリティゲートウェイのペア間、またはセキュリティゲートウェイとホスト間の1つ以上の「パス」を保護するために使用できます。 （「セキュリティゲートウェイ」という用語は、IPsecドキュメント全体で使用され、IPsecプロトコルを実装する中間システムを指します。たとえば、IPsecを実装するルーターまたはファイアウォールは、セキュリティゲートウェイです。）
The set of security services that IPsec can provide includes access control, connectionless integrity, data origin authentication, rejection of replayed packets (a form of partial sequence integrity), confidentiality (encryption), and limited traffic flow confidentiality. Because these services are provided at the IP layer, they can be used by any higher layer protocol, e.g., TCP, UDP, ICMP, BGP, etc.
IPsecが提供できる一連のセキュリティサービスには、アクセス制御、コネクションレスの整合性、データ発信元認証、再生されたパケットの拒否（部分的なシーケンスの整合性の形式）、機密性（暗号化）、および制限されたトラフィックフローの機密性が含まれます。これらのサービスはIP層で提供されるため、TCP、UDP、ICMP、BGPなどの上位層プロトコルで使用できます。
The IPsec DOI also supports negotiation of IP compression [SMPT98], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
IPsec DOIはIP圧縮[SMPT98]のネゴシエーションもサポートします。これは、IPsec内で暗号化が使用されている場合、下位のプロトコルレイヤーによる効果的な圧縮を妨げるという観察に動機付けられています。
IPsec uses two protocols to provide traffic security -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in more detail in their respective RFCs [KA98a, KA98b].
IPsecは2つのプロトコルを使用してトラフィックのセキュリティを提供します-認証ヘッダー（AH）とカプセル化セキュリティペイロード（ESP）。どちらのプロトコルも、それぞれのRFC [KA98a、KA98b]で詳細に説明されています。
o The IP Authentication Header (AH) [KA98a] provides connectionless integrity, data origin authentication, and an optional anti-replay service. o The Encapsulating Security Payload (ESP) protocol [KA98b] may provide confidentiality (encryption), and limited traffic flow confidentiality. It also may provide connectionless integrity, data origin authentication, and an anti-replay service. (One or the other set of these security services must be applied whenever ESP is invoked.) o Both AH and ESP are vehicles for access control, based on the distribution of cryptographic keys and the management of traffic flows relative to these security protocols.
o IP認証ヘッダー（AH）[KA98a]は、コネクションレスの整合性、データ発信元認証、およびオプションのアンチリプレイサービスを提供します。 oカプセル化セキュリティペイロード（ESP）プロトコル[KA98b]は、機密性（暗号化）と制限されたトラフィックフローの機密性を提供します。また、コネクションレスな整合性、データ発信元認証、およびリプレイ防止サービスも提供します。 （これらのセキュリティサービスのいずれかまたは他のセットは、ESPが呼び出されるたびに適用する必要があります。）o AHとESPは両方とも、暗号化キーの配布とこれらのセキュリティプロトコルに関連するトラフィックフローの管理に基づくアクセス制御の手段です。
These protocols may be applied alone or in combination with each other to provide a desired set of security services in IPv4 and IPv6. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode the protocols provide protection primarily for upper layer protocols; in tunnel mode, the protocols are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.
これらのプロトコルは、IPv4およびIPv6で必要な一連のセキュリティサービスを提供するために、単独で、または相互に組み合わせて適用できます。各プロトコルは、トランスポートモードとトンネルモードの2つの使用モードをサポートしています。トランスポートモードでは、プロトコルは主に上位層プロトコルを保護します。トンネルモードでは、プロトコルはトンネルIPパケットに適用されます。 2つのモードの違いについては、セクション4で説明します。
IPsec allows the user (or system administrator) to control the granularity at which a security service is offered. For example, one can create a single encrypted tunnel to carry all the traffic between two security gateways or a separate encrypted tunnel can be created for each TCP connection between each pair of hosts communicating across these gateways. IPsec management must incorporate facilities for specifying:
IPsecを使用すると、ユーザー（またはシステム管理者）は、セキュリティサービスを提供する細かさを制御できます。たとえば、2つのセキュリティゲートウェイ間のすべてのトラフィックを伝送する単一の暗号化トンネルを作成したり、これらのゲートウェイを介して通信するホストの各ペア間のTCP接続ごとに個別の暗号化トンネルを作成したりできます。 IPsec管理には、以下を指定する機能を組み込む必要があります。
o which security services to use and in what combinations o the granularity at which a given security protection should be applied o the algorithms used to effect cryptographic-based security
o 使用するセキュリティサービスと、特定のセキュリティ保護を適用する必要がある粒度の組み合わせo暗号化ベースのセキュリティに影響を与えるために使用されるアルゴリズム
Because these security services use shared secret values (cryptographic keys), IPsec relies on a separate set of mechanisms for putting these keys in place. (The keys are used for authentication/integrity and encryption services.) This document requires support for both manual and automatic distribution of keys. It specifies a specific public-key based approach (IKE -- [MSST97, Orm97, HC98]) for automatic key management, but other automated key distribution techniques MAY be used. For example, KDC-based systems such as Kerberos and other public-key systems such as SKIP could be employed.
これらのセキュリティサービスは共有シークレット値（暗号化キー）を使用するため、IPsecはこれらのキーを配置するための別個のメカニズムセットに依存しています。 （キーは、認証/整合性および暗号化サービスに使用されます。）このドキュメントでは、キーの手動配布と自動配布の両方のサポートが必要です。自動鍵管理のための特定の公開鍵ベースのアプローチ（IKE-[MSST97、Orm97、HC98]）を指定していますが、他の自動鍵配布手法を使用することもできます（MAY）。たとえば、KerberosなどのKDCベースのシステムや、SKIPなどの他の公開鍵システムを使用できます。
There are several ways in which IPsec may be implemented in a host or in conjunction with a router or firewall (to create a security gateway). Several common examples are provided below:
IPsecをホストに実装したり、ルーターやファイアウォール（セキュリティゲートウェイを作成するため）と組み合わせたりするには、いくつかの方法があります。いくつかの一般的な例を以下に示します。
a. Integration of IPsec into the native IP implementation. This requires access to the IP source code and is applicable to both hosts and security gateways.
a。 IPsecのネイティブIP実装への統合。これにはIPソースコードへのアクセスが必要で、ホストとセキュリティゲートウェイの両方に適用できます。
b. "Bump-in-the-stack" (BITS) implementations, where IPsec is implemented "underneath" an existing implementation of an IP protocol stack, between the native IP and the local network drivers. Source code access for the IP stack is not required in this context, making this implementation approach appropriate for use with legacy systems. This approach, when it is adopted, is usually employed in hosts.
b。 「Bump-in-the-stack」（BITS）実装。IPsecは、ネイティブIPとローカルネットワークドライバーの間で、IPプロトコルスタックの既存の実装の「下」に実装されます。このコンテキストでは、IPスタックのソースコードアクセスは必要ないため、この実装アプローチはレガシーシステムでの使用に適しています。このアプローチが採用されると、通常はホストで使用されます。
c. The use of an outboard crypto processor is a common design feature of network security systems used by the military, and of some commercial systems as well. It is sometimes referred to as a "Bump-in-the-wire" (BITW) implementation. Such implementations may be designed to serve either a host or a gateway (or both). Usually the BITW device is IP addressable. When supporting a single host, it may be quite analogous to a BITS implementation, but in supporting a router or firewall, it must operate like a security gateway.
c。船外の暗号化プロセッサの使用は、軍隊が使用するネットワークセキュリティシステムおよび一部の商用システムの一般的な設計機能です。これは、「Bump-in-the-wire」（BITW）実装と呼ばれることもあります。このような実装は、ホストまたはゲートウェイ（あるいはその両方）にサービスを提供するように設計できます。通常、BITWデバイスはIPアドレス指定可能です。単一のホストをサポートする場合、それはBITS実装に非常に類似している可能性がありますが、ルーターまたはファイアウォールのサポートでは、セキュリティゲートウェイのように動作する必要があります。
This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques.
このセクションでは、すべてのIPv6実装と、AH、ESP、またはその両方を実装するIPv4実装のセキュリティアソシエーション管理要件を定義します。 「セキュリティアソシエーション」（SA）の概念は、IPsecの基本です。 AHとESPはどちらもSAを利用しており、IKEの主な機能はセキュリティアソシエーションの確立と保守です。 AHまたはESPのすべての実装は、以下で説明するセキュリティアソシエーションの概念をサポートする必要があります。このセクションの残りの部分では、セキュリティアソシエーション管理のさまざまな側面について説明し、SAポリシー管理、トラフィック処理、およびSA管理技術に必要な特性を定義します。
A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required.
セキュリティアソシエーション（SA）は、それによって運ばれるトラフィックにセキュリティサービスを提供するシンプレックス "接続"です。セキュリティサービスは、AHまたはESPのいずれかを使用してSAに提供されますが、両方には提供されません。 AH保護とESP保護の両方がトラフィックストリームに適用される場合、2つ（またはそれ以上）のSAが作成され、トラフィックストリームを保護します。 2つのホスト間、または2つのセキュリティゲートウェイ間の一般的な双方向通信を保護するには、2つのセキュリティアソシエーション（各方向に1つ）が必要です。
A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well.
セキュリティアソシエーションは、セキュリティパラメータインデックス（SPI）、IP宛先アドレス、およびセキュリティプロトコル（AHまたはESP）識別子で構成されるトリプルによって一意に識別されます。原則として、宛先アドレスは、ユニキャストアドレス、IPブロードキャストアドレス、またはマルチキャストグループアドレスです。ただし、IPsec SA管理メカニズムは現在、ユニキャストSAに対してのみ定義されています。したがって、以下の説明では、SAはポイントツーポイント通信のコンテキストで説明されますが、この概念はポイントツーマルチポイントの場合にも適用できます。
As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [KA98a].
上記のように、トランスポートモードとトンネルモードの2種類のSAが定義されています。トランスポートモードSAは、2つのホスト間のセキュリティアソシエーションです。 IPv4では、トランスポートモードのセキュリティプロトコルヘッダーは、IPヘッダーとオプションの直後で、上位層のプロトコル（TCPやUDPなど）の前に表示されます。 IPv6では、セキュリティプロトコルヘッダーはベースIPヘッダーと拡張の後に表示されますが、宛先オプションの前後、および上位層プロトコルの前に表示される場合があります。 ESPの場合、トランスポートモードSAは、これらの上位層プロトコルにのみセキュリティサービスを提供し、IPヘッダーやESPヘッダーの前の拡張ヘッダーには提供しません。 AHの場合、保護はIPヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプション（IPv4ヘッダー、IPv6ホップバイホップ拡張ヘッダー、またはIPv6宛先拡張ヘッダーに含まれる）にも拡張されます。 。 AHによって提供されるカバレッジの詳細については、AH仕様[KA98a]を参照してください。
A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways.
トンネルモードSAは、本質的にIPトンネルに適用されるSAです。セキュリティアソシエーションのいずれかの端がセキュリティゲートウェイである場合は常に、SAはトンネルモードでなければなりません。したがって、2つのセキュリティゲートウェイ間のSAは、常にトンネルモードSAであり、ホストとセキュリティゲートウェイ間のSAも同様です。トラフィックの宛先がセキュリティゲートウェイ（SNMPコマンドなど）の場合、セキュリティゲートウェイがホストとして機能し、トランスポートモードが許可されることに注意してください。ただし、その場合、セキュリティゲートウェイはゲートウェイとして機能しません。つまり、トラフィックを通過させません。 2つのホストは、それらの間にトンネルモードSAを確立してもよい（MAY）。セキュリティゲートウェイがトンネルSAである（トランジットトラフィック）SAの要件は、IPsecパケットの断片化と再構成に関する潜在的な問題を回避する必要があるため、および複数のパス（たとえば、異なるセキュリティゲートウェイ経由）がある場合に発生します。 ）セキュリティゲートウェイの背後にある同じ宛先に存在します。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.
トンネルモードSAの場合、IPsec処理の宛先を指定する「外部」IPヘッダーと、パケットの（明らかに）最終的な宛先を指定する「内部」IPヘッダーがあります。セキュリティプロトコルヘッダーは、外部IPヘッダーの後、内部IPヘッダーの前に表示されます。 AHがトンネルモードで使用されている場合、外部IPヘッダーの一部が保護され（上記のように）、すべてのトンネルIPパケットが保護されます（つまり、すべての内部IPヘッダーが保護され、上位層プロトコルも保護されます）。 。 ESPが採用されている場合、保護はトンネル化されたパケットにのみ提供され、外部ヘッダーには提供されません。
In summary, a) A host MUST support both transport and tunnel mode. b) A security gateway is required to support only tunnel mode. If it supports transport mode, that should be used only when the security gateway is acting as a host, e.g., for network management.
要約すると、a）ホストはトランスポートモードとトンネルモードの両方をサポートする必要があります。 b）トンネルモードのみをサポートするには、セキュリティゲートウェイが必要です。トランスポートモードをサポートしている場合は、セキュリティゲートウェイがホストとして機能している場合（ネットワーク管理など）にのみ使用してください。
The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and on the election of optional services within the protocol. For example, AH provides data origin authentication and connectionless integrity for IP datagrams (hereafter referred to as just "authentication"). The "precision" of the authentication service is a function of the granularity of the security association with which AH is employed, as discussed in Section 4.4.2, "Selectors".
SAが提供するセキュリティサービスのセットは、選択したセキュリティプロトコル、SAモード、SAのエンドポイント、およびプロトコル内のオプションサービスの選択によって異なります。たとえば、AHはIPデータグラムのデータ発信元認証とコネクションレス整合性を提供します（以下、単に「認証」と呼びます）。認証サービスの「精度」は、セクション4.4.2「セレクタ」で説明されているように、AHが使用されるセキュリティアソシエーションの粒度の関数です。
AH also offers an anti-replay (partial sequence integrity) service at the discretion of the receiver, to help counter denial of service attacks. AH is an appropriate protocol to employ when confidentiality is not required (or is not permitted, e.g , due to government restrictions on use of encryption). AH also provides authentication for selected portions of the IP header, which may be necessary in some contexts. For example, if the integrity of an IPv4 option or IPv6 extension header must be protected en route between sender and receiver, AH can provide this service (except for the non-predictable but mutable parts of the IP header.)
AHは、サービス拒否攻撃に対抗するために、受信側の裁量でアンチリプレイ（部分シーケンス整合性）サービスも提供します。 AHは、機密性が要求されない（または、暗号化の使用に関する政府の制限のために許可されていない）場合に使用する適切なプロトコルです。 AHは、IPヘッダーの選択された部分の認証も提供します。これは、状況によっては必要になる場合があります。たとえば、IPv4オプションまたはIPv6拡張ヘッダーの整合性を送信者と受信者の間の途中で保護する必要がある場合、AHはこのサービスを提供できます（IPヘッダーの予測できないが変更可能な部分を除く）。
ESP optionally provides confidentiality for traffic. (The strength of the confidentiality service depends in part, on the encryption algorithm employed.) ESP also may optionally provide authentication (as defined above). If authentication is negotiated for an ESP SA, the receiver also may elect to enforce an anti-replay service with the same features as the AH anti-replay service. The scope of the authentication offered by ESP is narrower than for AH, i.e., the IP header(s) "outside" the ESP header is(are) not protected. If only the upper layer protocols need to be authenticated, then ESP authentication is an appropriate choice and is more space efficient than use of AH encapsulating ESP. Note that although both confidentiality and authentication are optional, they cannot both be omitted. At least one of them MUST be selected.
ESPはオプションでトラフィックの機密性を提供します。 （機密性サービスの強度は、使用される暗号化アルゴリズムに部分的に依存します。）ESPは、オプションで認証を提供することもできます（上記で定義）。 ESP SAの認証がネゴシエートされた場合、受信者は、AHアンチリプレイサービスと同じ機能を備えたアンチリプレイサービスを実施することも選択できます。 ESPによって提供される認証の範囲は、AHの場合よりも狭く、つまり、ESPヘッダーの「外部」にあるIPヘッダーは保護されません。上位層プロトコルのみを認証する必要がある場合、ESP認証は適切な選択であり、AHカプセル化ESPを使用するよりもスペース効率が高くなります。機密性と認証はどちらもオプションですが、両方を省略することはできません。それらの少なくとも1つを選択する必要があります。
If confidentiality service is selected, then an ESP (tunnel mode) SA between two security gateways can offer partial traffic flow confidentiality. The use of tunnel mode allows the inner IP headers to be encrypted, concealing the identities of the (ultimate) traffic source and destination. Moreover, ESP payload padding also can be invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones which are carrying traffic from many subscribers.
機密性サービスが選択されている場合、2つのセキュリティゲートウェイ間のESP（トンネルモード）SAは、部分的なトラフィックフローの機密性を提供できます。トンネルモードを使用すると、内部IPヘッダーを暗号化して、（最終的な）トラフィックの送信元と宛先のIDを隠すことができます。さらに、ESPペイロードパディングを呼び出して、パケットのサイズを非表示にして、トラフィックの外部特性をさらに隠すこともできます。モバイルユーザーにダイヤルアップコンテキストで動的IPアドレスが割り当てられ、企業ファイアウォール（セキュリティゲートウェイとして機能）への（トンネルモード）ESP SAを確立すると、同様のトラフィックフロー機密性サービスが提供されます。細かい粒度のSAは、多くのサブスクライバーからのトラフィックを運ぶ粗い粒度のSAよりも、一般にトラフィック分析に対して脆弱であることに注意してください。
The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.)
個別のSAを介して送信されるIPデータグラムは、AHまたはESPのいずれか1つだけで保護されますが、両方では保護されません。場合によっては、セキュリティポリシーによって、単一のSAでは達成できない特定のトラフィックフローに対してサービスの組み合わせが必要になることがあります。このような場合、必要なセキュリティポリシーを実装するには、複数のSAを採用する必要があります。 「セキュリティアソシエーションバンドル」または「SAバンドル」という用語は、セキュリティポリシーを満たすためにトラフィックを処理する必要がある一連のSAに適用されます。シーケンスの順序は、ポリシーによって定義されます。 （バンドルを構成するSAは異なるエンドポイントで終端する場合があることに注意してください。たとえば、1つのSAがモバイルホストとセキュリティゲートウェイの間で拡張され、2番目のネストされたSAがゲートウェイの背後のホストまで拡張される場合があります。）
Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling.
セキュリティアソシエーションは、トランスポート隣接と反復トンネリングの2つの方法でバンドルに組み合わせることができます。
o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination.
o トランスポート隣接とは、トンネリングを呼び出さずに、同じIPデータグラムに複数のセキュリティプロトコルを適用することを指します。 AHとESPを組み合わせるこのアプローチでは、1レベルの組み合わせのみが可能です。さらにネストすると、処理は（最終的な）宛先の1つのIPsecインスタンスで実行されるため、追加の利点はありません（各プロトコルで十分に強力なアルゴリズムを使用すると想定）。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -----Security Association 1 (ESP transport)------- |
| |
-------Security Association 2 (AH transport)----------
o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec site along the path. No special treatment is expected for ISAKMP traffic at intermediate security gateways other than what can be specified through appropriate SPD entries (See Case 3 in Section 4.5)
o 反復トンネリングとは、IPトンネリングによって影響を受けるセキュリティプロトコルの複数の層のアプリケーションを指します。このアプローチでは、各トンネルがパスに沿った異なるIPsecサイトで開始または終了できるため、複数レベルのネストが可能になります。適切なSPDエントリで指定できるもの以外の中間セキュリティゲートウェイでのISAKMPトラフィックには特別な処理は期待されていません（セクション4.5のケース3を参照）
There are 3 basic cases of iterated tunneling -- support is required only for cases 2 and 3.:
反復トンネリングには3つの基本的なケースがあります-サポートはケース2と3にのみ必要です：
1. both endpoints for the SAs are the same -- The inner and outer tunnels could each be either AH or ESP, though it is unlikely that Host 1 would specify both to be the same, i.e., AH inside of AH or ESP inside of ESP.
1. SAの両方のエンドポイントは同じです-内部トンネルと外部トンネルはそれぞれAHまたはESPのいずれかですが、ホスト1が両方を同じと指定することはほとんどありません（つまり、AHの内部のAHまたはESPの内部のESP）。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
2. one endpoint of the SAs is the same -- The inner and uter tunnels could each be either AH or ESP.
2. SAの1つのエンドポイントは同じです。内部トンネルと子宮トンネルは、それぞれAHまたはESPのいずれかです。
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
3. neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
3. どちらのエンドポイントも同じではありません。内部トンネルと外部トンネルはそれぞれAHまたはESPのいずれかです。
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
These two approaches also can be combined, e.g., an SA bundle could be constructed from one tunnel mode SA and one or two transport mode SAs, applied in sequence. (See Section 4.5 "Basic Combinations of Security Associations.") Note that nested tunnels can also occur where neither the source nor the destination endpoints of any of the tunnels are the same. In that case, there would be no host or security gateway with a bundle corresponding to the nested tunnels.
これらの2つのアプローチを組み合わせることもできます。たとえば、SAバンドルは、1つのトンネルモードSAと1つまたは2つのトランスポートモードSAを順に適用して構成できます。 （セクション4.5「セキュリティアソシエーションの基本的な組み合わせ」を参照してください。）ネストされたトンネルは、いずれのトンネルのソースエンドポイントも宛先エンドポイントも同じでない場合にも発生する可能性があることに注意してください。その場合、ネストされたトンネルに対応するバンドルを持つホストまたはセキュリティゲートウェイはありません。
For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5.
トランスポートモードSAの場合、適切なセキュリティプロトコルの順序は1つだけです。 AHは、上位層プロトコルとIPヘッダー（の一部）の両方に適用されます。したがって、AHがESPと共にトランスポートモードで使用される場合、AHはESPが出現する前に、IPの後の最初のヘッダーとして出現する必要があります（SHOULD）。そのコンテキストでは、AHはESPの暗号テキスト出力に適用されます。対照的に、トンネルモードSAの場合、AHとESPのさまざまな順序の使用を想像できます。準拠するIPsec実装でサポートする必要があるSAバンドルタイプの必須セットについては、セクション4.5で説明しています。
Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model.
IPsec実装でのIPトラフィックの処理に関連する詳細の多くは、主にローカルな問題であり、標準化の対象ではありません。ただし、相互運用性を確保し、IPsecの生産的な使用に不可欠な最小限の管理機能を提供するために、処理の一部の外部側面を標準化する必要があります。このセクションでは、これらの相互運用性と機能の目標をサポートするために、セキュリティアソシエーションに関連するIPトラフィックを処理するための一般的なモデルについて説明します。以下に説明するモデルは公称です。準拠した実装は、このモデルの詳細と一致する必要はありませんが、そのような実装の外部動作は、このモデルの外部から観察可能な特性にマッピングできる必要があります。
There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle).
このモデルには、セキュリティポリシーデータベースとセキュリティアソシエーションデータベースという2つの名目上のデータベースがあります。前者は、ホスト、セキュリティゲートウェイ、またはBITSまたはBITW IPsec実装から受信または送信されるすべてのIPトラフィックの処理を決定するポリシーを指定します。後者のデータベースには、各（アクティブな）セキュリティアソシエーションに関連付けられているパラメータが含まれています。このセクションでは、セレクタ、つまり、セキュリティポリシーデータベースがトラフィックをポリシー（SA（またはSAバンドル））にマップするためにセキュリティポリシーデータベースで使用される一連のIPおよび上位層プロトコルフィールド値の概念も定義します。
Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface.
IPsecが有効になっている各インターフェイスには、セレクターとして使用される多くのフィールドの方向性があるため、名目上別々のインバウンドデータベースとアウトバウンドデータベース（SADおよびSPD）が必要です。通常、ホストまたはセキュリティゲートウェイ（SG）の場合、このようなインターフェイスは1つだけです。 SGには常に少なくとも2つのインターフェイスがありますが、企業ネットへの「内部」インターフェイスは通常IPsecが有効になっていないため、SADの1つのペアとSPDの1つのペアのみが必要になることに注意してください。一方、ホストに複数のインターフェイスがある場合、またはSGに複数の外部インターフェイスがある場合は、インターフェイスごとに個別のSADとSPDのペアが必要になる場合があります。
Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway.
結局、セキュリティアソシエーションは、IPsec環境でセキュリティポリシーを実施するために使用される管理構造です。したがって、SA処理の重要な要素は、IPデータグラムにどのサービスをどのような方法で提供するかを指定する、基礎となるセキュリティポリシーデータベース（SPD）です。データベースの形式とそのインターフェースは、この仕様の範囲外です。ただし、このセクションでは、ユーザーまたはシステム管理者がホストで送受信されるトラフィックまたはセキュリティゲートウェイを通過するトラフィックにIPsecを適用する方法を制御できるようにするために、提供する必要がある特定の最小限の管理機能を指定します。
The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface.
SPDは、非IPsecトラフィックを含むすべてのトラフィック（INBOUNDおよびOUTBOUND）の処理中に参照する必要があります。これをサポートするために、SPDはインバウンドとアウトバウンドのトラフィックに異なるエントリを必要とします。これは個別のSPD（インバウンドとアウトバウンド）と考えることができます。さらに、名目上は個別のSPDを各IPsec対応インターフェースに提供する必要があります。
An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc.
SPDは、IPsec保護が提供されているトラフィックと、IPsecのバイパスが許可されているトラフィックを区別する必要があります。これは、送信者によって適用されるIPsec保護と、受信者に存在する必要があるIPsec保護に適用されます。アウトバウンドまたはインバウンドのデータグラムでは、破棄、IPsecのバイパス、IPsecの適用の3つの処理を選択できます。最初の選択肢は、ホストを出たり、セキュリティゲートウェイを通過したり、アプリケーションに配信したりできないトラフィックを指します。 2番目の選択肢は、追加のIPsec保護なしで通過を許可されるトラフィックを指します。 3番目の選択肢は、IPsec保護を提供するトラフィックを指します。そのようなトラフィックに対して、SPDは、提供されるセキュリティサービス、使用されるプロトコル、使用されるアルゴリズムなどを指定する必要があります。
For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a single UDP or TCP connection will tend to match a single SPD entry, this requirement will not impose an unreasonably detailed level of SPD specification. The selectors are analogous to what are found in a stateless firewall or filtering router and which are currently manageable this way.
すべてのIPsec実装には、ユーザーまたはシステム管理者がSPDを管理できるようにする管理インターフェイスが必要です。具体的には、すべての着信パケットまたは発信パケットはIPsecによる処理の対象であり、SPDはそれぞれの場合に実行するアクションを指定する必要があります。したがって、管理インターフェースは、ユーザー（またはシステム管理者）がシステムに出入りするすべてのパケットにパケットごとに適用するセキュリティ処理を指定できるようにする必要があります。 （ソケットインターフェースを使用するホストIPsec実装では、SPDをパケットごとに参照する必要はないかもしれませんが、効果は同じです。）SPDの管理インターフェースは、セクション4.4.2で定義されたセレクタは、これらのエントリの（合計）順序をサポートする必要があります。さまざまなセレクターフィールドでワイルドカードを使用することにより、単一のUDPまたはTCP接続のすべてのパケットが単一のSPDエントリと一致する傾向があるため、この要件は不当に詳細なレベルのSPD仕様を課すことはありません。セレクターは、ステートレスファイアウォールまたはフィルタリングルーターにあるものと類似しており、現在この方法で管理できます。
In host systems, applications MAY be allowed to select what security processing is to be applied to the traffic they generate and consume. (Means of signalling such requests to the IPsec implementation are outside the scope of this standard.) However, the system administrator MUST be able to specify whether or not a user or application can override (default) system policies. Note that application specified policies may satisfy system requirements, so that the system may not need to do additional IPsec processing beyond that needed to meet an application's requirements. The form of the management interface is not specified by this document and may differ for hosts vs. security gateways, and within hosts the interface may differ for socket-based vs. BITS implementations. However, this document does specify a standard set of SPD elements that all IPsec implementations MUST support.
ホストシステムでは、アプリケーションは、生成して消費するトラフィックに適用するセキュリティ処理を選択できます。 （そのような要求をIPsec実装に通知する手段は、この標準の範囲外です。）ただし、システム管理者は、ユーザーまたはアプリケーションが（デフォルトの）システムポリシーを上書きできるかどうかを指定できる必要があります。アプリケーション指定のポリシーはシステム要件を満たす場合があるため、システムはアプリケーションの要件を満たすために必要なものを超える追加のIPsec処理を行う必要がない場合があることに注意してください。管理インターフェイスの形式はこのドキュメントでは指定されておらず、ホストとセキュリティゲートウェイでは異なる場合があり、ホスト内では、インターフェイスがソケットベースとBITSの実装で異なる場合があります。ただし、このドキュメントでは、すべてのIPsec実装がサポートする必要があるSPD要素の標準セットを指定しています。
The SPD contains an ordered list of policy entries. Each policy entry is keyed by one or more selectors that define the set of IP traffic encompassed by this policy entry. (The required selector types are defined in Section 4.4.2.) These define the granularity of policies or SAs. Each entry includes an indication of whether traffic matching this policy will be bypassed, discarded, or subject to IPsec processing. If IPsec processing is to be applied, the entry includes an SA (or SA bundle) specification, listing the IPsec protocols, modes, and algorithms to be employed, including any nesting requirements. For example, an entry may call for all matching traffic to be protected by ESP in transport mode using 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode using HMAC/SHA-1. For each selector, the policy entry specifies how to derive the corresponding values for a new Security Association Database (SAD, see Section 4.4.3) entry from those in the SPD and the packet (Note that at present, ranges are only supported for IP addresses; but wildcarding can be expressed for all selectors):
SPDには、ポリシーエントリの順序付きリストが含まれています。各ポリシーエントリは、このポリシーエントリに含まれるIPトラフィックのセットを定義する1つ以上のセレクターによってキー設定されます。 （必要なセレクタータイプはセクション4.4.2で定義されています。）これらは、ポリシーまたはSAの粒度を定義します。各エントリには、このポリシーに一致するトラフィックがバイパスされるか、破棄されるか、またはIPsec処理の対象となるかが示されます。 IPsec処理を適用する場合、エントリにはSA（またはSAバンドル）仕様が含まれ、使用するIPsecプロトコル、モード、およびアルゴリズム（ネスト要件を含む）がリストされます。たとえば、エントリは、HMAC / SHA-1を使用するトンネルモードのAH内にネストされた明示的なIVを使用する3DES-CBCを使用するトランスポートモードのESPによって保護されるすべての一致するトラフィックを要求する場合があります。各セレクターのポリシーエントリは、SPDおよびパケット内の値から新しいセキュリティアソシエーションデータベース（SAD、セクション4.4.3を参照）エントリに対応する値を取得する方法を指定します（現在のところ、範囲はIPでのみサポートされています）アドレス;ただし、ワイルドカードはすべてのセレクターで表現できます）：
a. use the value in the packet itself -- This will limit use of the SA to those packets which have this packet's value for the selector even if the selector for the policy entry has a range of allowed values or a wildcard for this selector. b. use the value associated with the policy entry -- If this were to be just a single value, then there would be no difference between (b) and (a). However, if the allowed values for the selector are a range (for IP addresses) or wildcard, then in the case of a range,(b) would enable use of the SA by any packet with a selector value within the range not just by packets with the selector value of the packet that triggered the creation of the SA. In the case of a wildcard, (b) would allow use of the SA by packets with any value for this selector.
a。パケット自体の値を使用する-これにより、ポリシーエントリのセレクターに許可された値の範囲またはこのセレクターのワイルドカードがある場合でも、SAの使用が、セレクターにこのパケットの値を持つパケットに制限されます。 b。ポリシーエントリに関連付けられた値を使用します-これが単一の値である場合、（b）と（a）の間に違いはありません。ただし、セレクターに許可された値が範囲（IPアドレスの場合）またはワイルドカードである場合、範囲の場合、（b）は、セレクター値が範囲内にあるパケットだけでなく、 SAの作成をトリガーしたパケットのセレクター値を持つパケット。ワイルドカードの場合、（b）は、このセレクターの任意の値を持つパケットによるSAの使用を許可します。
For example, suppose there is an SPD entry where the allowed value for source address is any of a range of hosts (192.168.2.1 to 192.168.2.10). And suppose that a packet is to be sent that has a source address of 192.168.2.3. The value to be used for the SA could be any of the sample values below depending on what the policy entry for this selector says is the source of the selector value:
たとえば、送信元アドレスの許容値がホストの範囲（192.168.2.1〜192.168.2.10）のいずれかであるSPDエントリがあるとします。また、送信元アドレスが192.168.2.3のパケットが送信されるとします。 SAに使用される値は、このセレクターのポリシーエントリがセレクター値のソースであると言う内容に応じて、以下のサンプル値のいずれかになります。
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)
Note that if the SPD entry had an allowed value of wildcard for the source address, then the SAD selector value could be wildcard (any host). Case (a) can be used to prohibit sharing, even among packets that match the same SPD entry.
SPDエントリの送信元アドレスにワイルドカードを使用できる場合、SADセレクターの値はワイルドカード（任意のホスト）になる可能性があることに注意してください。ケース（a）は、同じSPDエントリに一致するパケット間でも、共有を禁止するために使用できます。
As described below in Section 4.4.3, selectors may include "wildcard" entries and hence the selectors for two entries may overlap. (This is analogous to the overlap that arises with ACLs or filter entries in routers or packet filtering firewalls.) Thus, to ensure consistent, predictable processing, SPD entries MUST be ordered and the SPD MUST always be searched in the same order, so that the first matching entry is consistently selected. (This requirement is necessary as the effect of processing traffic against SPD entries must be deterministic, but there is no way to canonicalize SPD entries given the use of wildcards for some selectors.) More detail on matching of packets against SPD entries is provided in Section 5.
以下のセクション4.4.3で説明するように、セレクタには「ワイルドカード」エントリが含まれる場合があり、2つのエントリのセレクタが重複する場合があります。 （これは、ルーターまたはパケットフィルタリングファイアウォールのACLまたはフィルターエントリで発生するオーバーラップに類似しています。）したがって、一貫性のある予測可能な処理を保証するには、SPDエントリを順序付けし、SPDを常に同じ順序で検索する必要があります。最初に一致したエントリが一貫して選択されます。 （SPDエントリに対するトラフィック処理の効果は確定的でなければならないため、この要件は必要ですが、一部のセレクターでワイルドカードを使用する場合、SPDエントリを正規化する方法はありません。）SPDエントリに対するパケットのマッチングの詳細については、セクションで説明します。 5。
Note that if ESP is specified, either (but not both) authentication or encryption can be omitted. So it MUST be possible to configure the SPD value for the authentication or encryption algorithms to be "NULL". However, at least one of these services MUST be selected, i.e., it MUST NOT be possible to configure both of them as "NULL".
ESPが指定されている場合、認証または暗号化のいずれか（両方ではない）を省略できることに注意してください。したがって、認証または暗号化アルゴリズムのSPD値を「NULL」に設定できるようにする必要があります。ただし、これらのサービスの少なくとも1つを選択する必要があります。つまり、両方のサービスを「NULL」として構成することはできません。
The SPD can be used to map traffic to specific SAs or SA bundles. Thus it can function both as the reference database for security policy and as the map to existing SAs (or SA bundles). (To accommodate the bypass and discard policies cited above, the SPD also MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively.
SPDを使用して、トラフィックを特定のSAまたはSAバンドルにマップできます。したがって、セキュリティポリシーの参照データベースとしても、既存のSA（またはSAバンドル）へのマップとしても機能できます。 （上記のバイパスポリシーと破棄ポリシーに対応するために、SPDは、それ自体がIPsec処理ではない場合でも、これらの機能にトラフィックをマッピングする手段を提供する必要があります。）SPDの動作方法は、インバウンドとインバウンドで異なります。 。送信トラフィック。また、ホストゲートウェイとセキュリティゲートウェイ、BITS、およびBITWの実装によって異なる場合があります。セクション5.1と5.2は、それぞれアウトバウンド処理とインバウンド処理でのSPDの使用について説明しています。
Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA.
セキュリティポリシーでは、特定の順序で特定のトラフィックセットに複数のSAを適用する必要があるため、SPDのポリシーエントリは、存在する場合、これらの順序付け要件を維持する必要があります。したがって、IPsec実装は、アウトバウンドまたはインバウンドのパケットを一連のSAで処理する必要があると判断できる必要があります。概念的には、アウトバウンド処理の場合、アクティブなSAがあるSPDエントリーからの（SADへの）リンクを想像できます。各エントリーは、単一のSAまたはSAバンドルを構成するSAの順序付きリストのいずれかで構成されます。パケットがSPDエントリと照合され、トラフィックの伝送に使用できる既存のSAまたはSAバンドルがある場合、パケットの処理はリストのSAまたはSAバンドルエントリによって制御されます。複数のIPsec SAが適用される着信IPsecパケットの場合、宛先アドレス、IPsecプロトコル、およびSPIに基づくルックアップは、単一のSAを識別する必要があります。
The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway.
SPDは、セキュリティゲートウェイの背後にあるエンティティとの間のセキュリティおよびキー管理トラフィック（ISAKMPなど）を含む、IPsecシステムを介したすべてのトラフィックのフローを制御するために使用されます。これは、SPDでISAKMPトラフィックを明示的に考慮する必要があることを意味します。それ以外の場合は破棄されます。セキュリティゲートウェイは、暗号化されたパケットの通過をさまざまな方法で禁止できます。たとえば、ESPパケットのSPDにDISCARDエントリを設定したり、プロキシキー交換を提供したりできます。後者の場合、トラフィックは内部でセキュリティゲートウェイのキー管理モジュールにルーティングされます。
An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW implementation, the transport layer protocol, source/destination ports, and Name (if present) may be "OPAQUE", i.e., inaccessible because of encryption or fragmentation. Note also that both Source and Destination addresses should either be IPv4 or IPv6.
SAのトラフィックのセットを定義するために使用されるセレクターに応じて、SA（またはSAバンドル）は細粒度または粗粒度になる場合があります。たとえば、2つのホスト間のすべてのトラフィックが単一のSAを介して伝送され、統一されたセキュリティサービスセットが提供されます。または、使用するアプリケーション（次のプロトコルおよびポートフィールドで定義）に応じて、ホストのペア間のトラフィックが複数のSAに分散し、異なるSAによって異なるセキュリティサービスが提供される場合があります。同様に、セキュリティゲートウェイのペア間のすべてのトラフィックを単一のSAで伝送することも、通信するホストペアごとに1つのSAを割り当てることもできます。 SAの細分性の制御を容易にするために、SA管理では次のセレクタパラメータをサポートする必要があります。カプセル化セキュリティゲートウェイまたはBITW実装など、ESPヘッダー付きのパケットを受信する場合、トランスポート層プロトコル、送信元/宛先ポート、および名前（存在する場合）は「OPAQUE」、つまり暗号化または断片化のためにアクセスできません。また、送信元アドレスと宛先アドレスはどちらもIPv4またはIPv6のいずれかでなければなりません。
- Destination IP Address (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), a range of addresses (high and low values (inclusive), address + mask, or a wildcard address. The last three are used to support more than one destination system sharing the same SA (e.g., behind a security gateway). Note that this selector is conceptually different from the "Destination IP Address" field in the <Destination IP Address, IPsec Protocol, SPI> tuple used to uniquely identify an SA. When a tunneled packet arrives at the tunnel endpoint, its SPI/Destination address/Protocol are used to look up the SA for this packet in the SAD. This destination address comes from the encapsulating IP header. Once the packet has been processed according to the tunnel SA and has come out of the tunnel, its selectors are "looked up" in the Inbound SPD. The Inbound SPD has a selector called destination address. This IP destination address is the one in the inner (encapsulated) IP header. In the case of a transport'd packet, there will be only one IP header and this ambiguity does not exist. [REQUIRED for all implementations]
- 宛先IPアドレス（IPv4またはIPv6）：これは、単一のIPアドレス（ユニキャスト、エニーキャスト、ブロードキャスト（IPv4のみ）、またはマルチキャストグループ）、アドレスの範囲（高い値と低い値（含む））、アドレス+マスク、またはワイルドカードアドレス。最後の3つは、同じSAを共有する複数の宛先システム（たとえば、セキュリティゲートウェイの背後）をサポートするために使用されます。このセレクタは、<宛先IPアドレスの[宛先IPアドレス]フィールドとは概念的に異なることに注意してください。 、IPsecプロトコル、SPI> SAを一意に識別するために使用されるタプル。トンネル化されたパケットがトンネルエンドポイントに到着すると、そのSPI /宛先アドレス/プロトコルは、SADでこのパケットのSAを検索するために使用されます。この宛先アドレスは、カプセル化IPヘッダー。パケットがトンネルSAに従って処理され、トンネルから出てくると、そのセレクターは受信SPDで「検索」されます。受信SPDには、宛先アドレスと呼ばれるセレクターがあります。このIP宛先アドレスインナーのものです（カプセル化された）IPヘッダー。トランスポートされたパケットの場合、IPヘッダーは1つしかなく、このあいまいさはありません。 [すべての実装に必要]
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are used to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations]
- 送信元IPアドレス（IPv4またはIPv6）：これは、単一のIPアドレス（ユニキャスト、エニーキャスト、ブロードキャスト（IPv4のみ）、またはマルチキャストグループ）、アドレスの範囲（高い値と低い値を含む）、アドレス+マスク、またはワイルドカードアドレス。最後の3つは、同じSAを共有する複数のソースシステムをサポートするために使用されます（たとえば、セキュリティゲートウェイの背後またはマルチホームホスト内）。 [すべての実装に必要]
- Name: There are 2 cases (Note that these name forms are supported in the IPsec DOI.) 1. User ID a. a fully qualified user name string (DNS), e.g., mozart@foo.bar.com b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent. 2. System name (host, security gateway, etc.) a. a fully qualified DNS name, e.g., foo.bar.com b. X.500 distinguished name c. X.500 general name
- 名前：2つのケースがあります（これらの名前形式はIPsec DOIでサポートされていることに注意してください）。1.ユーザーID a。完全修飾ユーザー名文字列（DNS）（例：mozart@foo.bar.com）b。 X.500識別名。たとえば、C = US、SP = MA、O = GTEインターネットワーキング、CN = Stephen T. Kent。 2.システム名（ホスト、セキュリティゲートウェイなど）完全修飾DNS名（例：foo.bar.com）b。 X.500識別名c。 X.500の一般名
NOTE: One of the possible values of this selector is "OPAQUE".
注：このセレクターの可能な値の1つは「OPAQUE」です。
[REQUIRED for the following cases. Note that support for name forms other than addresses is not required for manually keyed SAs. o User ID - native host implementations - BITW and BITS implementations acting as HOSTS with only one user - security gateway implementations for INBOUND processing. o System names -- all implementations]
【以下の場合に必要です。手動でキーを付けたSAでは、アドレス以外の名前形式のサポートは必要ないことに注意してください。 oユーザーID-ネイティブホスト実装-ユーザーが1人だけのホストとして機能するBITWおよびBITS実装-INBOUND処理用のセキュリティゲートウェイ実装。 oシステム名-すべての実装]
- Data sensitivity level: (IPSO/CIPSO labels) [REQUIRED for all systems providing information flow security as per Section 8, OPTIONAL for all other systems.]
- データ機密性レベル：（IPSO / CIPSOラベル）[セクション8に従って情報フローのセキュリティを提供するすべてのシステムに必要です。他のすべてのシステムではオプションです。]
- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations]
- トランスポート層プロトコル：IPv4「プロトコル」またはIPv6「次のヘッダー」フィールドから取得されます。これは、個別のプロトコル番号である場合があります。これらのパケットフィールドには、ルーティングヘッダー、AH、ESP、フラグメンテーションヘッダー、宛先オプション、ホップバイホップオプションなどのIP拡張ヘッダーが存在するため、トランスポートプロトコルが含まれていない場合があります。トランスポートプロトコルは、 ESPヘッダーのあるパケットを受信した場合に使用できるため、「OPAQUE」の値をサポートする必要があります（SHOULD）。 [すべての実装に必要]
NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque.
注：トランスポートプロトコルを見つけるには、システムがパケットヘッダーをチェインして、「プロトコル」または「次のヘッダー」フィールドをチェックして、トランスポートプロトコルとして認識されるか、オンになっていないフィールドに到達するまでチェックする必要があります。拡張ヘッダーのリスト、またはトランスポートプロトコルを不透明にするESPヘッダーが見つかるまで。
- Source and Destination (e.g., TCP/UDP) Ports: These may be individual UDP or TCP port values or a wildcard port. (The use of the Next Protocol field and the Source and/or Destination Port fields (in conjunction with the Source and/or Destination Address fields), as an SA selector is sometimes referred to as "session-oriented keying."). Note that the source and destination ports may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported.
- 送信元および宛先（TCP / UDPなど）のポート：これらは、個別のUDPまたはTCPポート値、またはワイルドカードポートです。 （SAセレクターは「セッション指向のキーイング」と呼ばれることもあるので、（次のプロトコル）フィールドと（送信元および/または宛先ポート）フィールドとともに（送信元および/または宛先アドレスフィールドと組み合わせて）を使用します）。 ESPヘッダーを持つパケットを受信した場合、送信元ポートと宛先ポートが使用できない場合があることに注意してください。したがって、「OPAQUE」の値をサポートする必要があります。
The following table summarizes the relationship between the "Next Header" value in the packet and SPD and the derived Port Selector value for the SPD and SAD.
次の表は、パケットとSPDの「次のヘッダー」値と、SPDとSADの派生ポートセレクター値の関係をまとめたものです。
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
If the packet has been fragmented, then the port information may not be available in the current fragment. If so, discard the fragment. An ICMP PMTU should be sent for the first fragment, which will have the port information. [MAY be supported]
パケットがフラグメント化されている場合、ポート情報は現在のフラグメントで使用できない場合があります。その場合、フラグメントを破棄します。 ICMP PMTUは、ポート情報を持つ最初のフラグメントに送信する必要があります。 [サポートされる可能性があります]
The IPsec implementation context determines how selectors are used. For example, a host implementation integrated into the stack may make use of a socket interface. When a new connection is established the SPD can be consulted and an SA (or SA bundle) bound to the socket. Thus traffic sent via that socket need not result in additional lookups to the SPD/SAD. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD/SAD lookup based on the selectors. The allowable values for the selector fields differ between the traffic flow, the security association, and the security policy.
IPsec実装コンテキストは、セレクターの使用方法を決定します。たとえば、スタックに統合されたホストの実装では、ソケットインターフェイスを利用できます。新しい接続が確立されると、SPDが参照され、SA（またはSAバンドル）がソケットにバインドされます。したがって、そのソケットを介して送信されるトラフィックは、SPD / SADへの追加のルックアップをもたらす必要はありません。対照的に、BITS、BITW、またはセキュリティゲートウェイの実装では、各パケットを調べ、セレクターに基づいてSPD / SADルックアップを実行する必要があります。セレクタフィールドの許容値は、トラフィックフロー、セキュリティアソシエーション、およびセキュリティポリシーによって異なります。
The following table summarizes the kinds of entries that one needs to be able to express in the SPD and SAD. It shows how they relate to the fields in data traffic being subjected to IPsec screening. (Note: the "wild" or "wildcard" entry for src and dst addresses includes a mask, range, etc.)
次の表は、SPDおよびSADで表現できるようにする必要があるエントリの種類をまとめたものです。 IPsecスクリーニングの対象となるデータトラフィックのフィールドとの関係を示しています。 （注：srcおよびdstアドレスの「ワイルド」または「ワイルドカード」エントリには、マスク、範囲などが含まれます。）
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE" because the traffic value is encrypted.
* トラフィック値が暗号化されているため、これらのフィールドのSADおよびSPDエントリは「OPAQUE」になる可能性があります。
NOTE: In principle, one could have selectors and/or selector values in the SPD which cannot be negotiated for an SA or SA bundle. Examples might include selector values used to select traffic for discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications.
注：原則として、SPDにSAまたはSAバンドルについてネゴシエートできないセレクターおよび/またはセレクター値を含めることができます。例としては、リストの項目ごとに個別のSAが作成される、破棄または列挙されたリストのトラフィックを選択するために使用されるセレクター値が含まれる場合があります。現時点では、これはこのドキュメントの将来のバージョンに残され、必要なセレクターとセレクター値のリストはSPDとSADで同じです。ただし、ネゴシエーションできないセレクター値の使用をサポートする管理インターフェースがあっても、ユーザーがこれらのセレクター値でSAを作成していると誤解させない限り、許容されます。たとえば、このインターフェースでは、ユーザーが列挙された値のリストを指定できる場合がありますが、リストの各アイテムに対して個別のポリシーとSAが作成されます。ベンダーは、顧客が明確で簡潔なポリシー仕様を指定しやすくするために、このようなインターフェースをサポートする場合があります。
In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation.
各IPsec実装には、名目上のセキュリティアソシエーションデータベースがあり、各エントリは1つのSAに関連付けられたパラメーターを定義します。各SAはSADにエントリを持っています。 Outbound処理の場合、エントリーはSPDのエントリーによってポイントされます。 SPDエントリがパケットに適切なSAを現在指していない場合、実装は適切なSA（またはSAバンドル）を作成し、SPDエントリをSADエントリにリンクします（セクション5.1.1を参照）。 Inbound処理の場合、SADの各エントリには、宛先IPアドレス、IPsecプロトコルタイプ、およびSPIによってインデックスが付けられます。次のパラメータは、SADの各エントリに関連付けられています。この説明は、MIBであると主張するのではなく、IPsec実装でSAをサポートするために必要な最小限のデータ項目の仕様のみです。
For inbound processing: The following packet fields are used to look up the SA in the SAD:
Inbound処理の場合：次のパケットフィールドを使用して、SADでSAを検索します。
o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations]
o 外部ヘッダーの宛先IPアドレス：IPv4またはIPv6宛先アドレス。 [すべての実装に必須] o IPsecプロトコル：AHまたはESP。このデータベースでSA検索のインデックスとして使用されます。このSAのトラフィックに適用されるIPsecプロトコルを指定します。 [すべての実装に必須] o SPI：同じ宛先で終了し、同じIPsecプロトコルを使用する異なるSAを区別するために使用される32ビット値。 [すべての実装に必要]
For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". Note that for an ESP SA, the encryption algorithm or the authentication algorithm could be "NULL". However they MUST not both be "NULL".
セクション4.4.2で定義された各セレクターについて、SADのSAエントリには、SAの作成時にネゴシエートされた1つまたは複数の値が含まれている必要があります。送信者の場合、これらの値は、特定のSAが送信パケットでの使用に適しているかどうかを判断するために使用されます。これは、使用できる既存のSAがあるかどうかを確認するチェックの一部です。受信側の場合、これらの値を使用して、インバウンドパケットのセレクター値がSAのセレクター値（したがって、一致するポリシーの値）と間接的に一致することを確認します。受信者にとって、これはSAがこのパケットに適切であったことを確認することの一部です。 （ICMPメッセージのルールについては、セクション6を参照してください。）これらのフィールドは、セクション4.4.2「セレクタ」で説明されているように、特定の値、範囲、ワイルドカード、または「OPAQUE」の形式にすることができます。 ESP SAの場合、暗号化アルゴリズムまたは認証アルゴリズムは「NULL」になる可能性があることに注意してください。ただし、両方を「NULL」にすることはできません。
The following SAD fields are used in doing IPsec processing:
次のSADフィールドは、IPsec処理の実行に使用されます。
o Sequence Number Counter: a 32-bit value used to generate the Sequence Number field in AH or ESP headers. [REQUIRED for all implementations, but used only for outbound traffic.] o Sequence Counter Overflow: a flag indicating whether overflow of the Sequence Number Counter should generate an auditable event and prevent transmission of additional packets on the SA. [REQUIRED for all implementations, but used only for outbound traffic.] o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. [REQUIRED for all implementations but used only for inbound traffic. NOTE: If anti-replay has been disabled by the receiver, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is not used.] o AH Authentication algorithm, keys, etc. [REQUIRED for AH implementations] o ESP Encryption algorithm, keys, IV mode, IV, etc. [REQUIRED for ESP implementations] o ESP authentication algorithm, keys, etc. If the authentication service is not selected, this field will be null. [REQUIRED for ESP implementations] o Lifetime of this Security Association: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both, the first lifetime to expire taking precedence. A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations]
o シーケンス番号カウンター：AHまたはESPヘッダーのシーケンス番号フィールドを生成するために使用される32ビット値。 [すべての実装で必須ですが、送信トラフィックでのみ使用されます。] oシーケンスカウンターオーバーフロー：シーケンス番号カウンターのオーバーフローが監査可能なイベントを生成し、SAでの追加パケットの送信を防ぐかどうかを示すフラグ。 [すべての実装で必要ですが、アウトバウンドトラフィックにのみ使用されます。] oアンチリプレイウィンドウ：32ビットのカウンターとビットマップ（または同等のもの）が、インバウンドAHまたはESPパケットがリプレイかどうかを判断するために使用されます。 [すべての実装に必要ですが、受信トラフィックにのみ使用されます。注：アンチリプレイがレシーバーによって無効にされている場合、たとえば手動でキーイングされたSAの場合、アンチリプレイウィンドウは使用されません。] o AH認証アルゴリズム、キーなど[AH実装に必須] o ESP暗号化アルゴリズム、キー、IVモード、IVなど。[ESP実装に必要] o ESP認証アルゴリズム、キーなど。認証サービスが選択されていない場合、このフィールドはnullになります。 [ESP実装に必須] oこのセキュリティアソシエーションの存続期間：SAを新しいSA（および新しいSPI）で置き換えるか終了するまでの時間間隔と、これらのアクションのどれが発生するかを示します。これは、時間またはバイトカウントとして、あるいは両方の同時使用として表現できます。準拠した実装は、両方のタイプのライフタイムをサポートする必要があり、両方の同時使用をサポートする必要があります。時間を使用し、IKEがSAの確立にX.509証明書を使用する場合、SAの有効期間は、証明書の有効期間と、SAのIKE交換で使用されるCRLのNextIssueDateによって制約される必要があります。イニシエーターとレスポンダーの両方が、この方法でSAライフタイムを制限する責任があります。 [すべての実装に必要]
NOTE: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is: (a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations SHOULD be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way. (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns the implementation to initiate action such as setting up a replacement SA and a hard lifetime when the current SA ends. (c) If the entire packet does not get delivered during the SAs lifetime, the packet SHOULD be discarded.
注：SAの有効期限が切れたときにキーの更新を処理する方法の詳細は、ローカルの問題です。ただし、合理的なアプローチの1つは次のとおりです。（a）バイトカウントを使用する場合、実装はIPsecアルゴリズムが適用されるバイト数をカウントする必要があります（SHOULD）。 ESPの場合、これは暗号化アルゴリズム（Null暗号化を含む）であり、AHの場合、これは認証アルゴリズムです。これには、パッドバイトなどが含まれます。たとえば、パケット損失が原因で、またはSAの各端の実装が処理を行っていないため、実装のSAの端にあるカウンターが非同期になることを処理できるはずです（SHOULD）。同じ方法。 （b）2種類のライフタイムがあるべきです-交換SAのセットアップなどのアクションを開始するように実装に警告するソフトライフタイムと、現在のSAが終了したときのハードライフタイム。 （c）SAの有効期間中にパケット全体が配信されない場合、パケットは破棄されるべきです（SHOULD）。
o IPsec protocol mode: tunnel, transport or wildcard. Indicates which mode of AH or ESP is applied to traffic on this SA. Note that if this field is "wildcard" at the sending end of the SA, then the application has to specify the mode to the IPsec implementation. This use of wildcard allows the same SA to be used for either tunnel or transport mode traffic on a per packet basis, e.g., by different sockets. The receiver does not need to know the mode in order to properly process the packet's IPsec headers.
o IPsecプロトコルモード：トンネル、トランスポート、またはワイルドカード。このSAのトラフィックに適用されるAHまたはESPのモードを示します。このフィールドがSAの送信側で「ワイルドカード」である場合、アプリケーションはモードをIPsec実装に指定する必要があることに注意してください。このワイルドカードの使用により、同じSAをトンネルごと、またはトランスポートモードのトラフィックごとに、たとえば異なるソケットによって、パケットごとに使用できます。受信者は、パケットのIPsecヘッダーを適切に処理するためにモードを知る必要はありません。
[REQUIRED as follows, unless implicitly defined by context: - host implementations must support all modes - gateway implementations must support tunnel mode]
[コンテキストによって暗黙的に定義されていない限り、次のように必須：-ホスト実装はすべてのモードをサポートする必要がある-ゲートウェイ実装はトンネルモードをサポートする必要がある]
NOTE: The use of wildcard for the protocol mode of an inbound SA may add complexity to the situation in the receiver (host only). Since the packets on such an SA could be delivered in either tunnel or transport mode, the security of an incoming packet could depend in part on which mode had been used to deliver it. If, as a result, an application cared about the SA mode of a given packet, then the application would need a mechanism to obtain this mode information.
注：受信SAのプロトコルモードにワイルドカードを使用すると、受信側の状況が複雑になる場合があります（ホストのみ）。そのようなSA上のパケットはトンネルモードまたはトランスポートモードのいずれかで配信される可能性があるため、着信パケットのセキュリティは、その配信に使用されたモードに部分的に依存する可能性があります。その結果、アプリケーションが特定のパケットのSAモードを考慮した場合、アプリケーションはこのモード情報を取得するメカニズムを必要とします。
o Path MTU: any observed path MTU and aging variables. See Section 6.1.2.4 [REQUIRED for all implementations but used only for outbound traffic]
o パスMTU：観測されたパスMTUおよびエージング変数。セクション6.1.2.4を参照してください[すべての実装に必須ですが、送信トラフィックにのみ使用されます]
This section describes four examples of combinations of security associations that MUST be supported by compliant IPsec hosts or security gateways. Additional combinations of AH and/or ESP in tunnel and/or transport modes MAY be supported at the discretion of the implementor. Compliant implementations MUST be capable of generating these four combinations and on receipt, of processing them, but SHOULD be able to receive and process any combination. The diagrams and text below describe the basic cases. The legend for the diagrams is:
このセクションでは、準拠するIPsecホストまたはセキュリティゲートウェイでサポートする必要があるセキュリティアソシエーションの組み合わせの4つの例について説明します。トンネルおよび/またはトランスポートモードでのAHおよび/またはESPの追加の組み合わせは、実装者の裁量でサポートされる場合があります。準拠した実装は、これらの4つの組み合わせを生成し、受信時にそれらを処理できなければならない（MUST）が、任意の組み合わせを受信して処理できる必要がある（SHOULD）。以下の図とテキストは、基本的なケースを説明しています。図の凡例は次のとおりです。
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel.
注：以下のセキュリティ結合は、AHまたはESPのいずれかです。モード（トンネルとトランスポート）は、エンドポイントの性質によって決まります。ホスト間SAの場合、モードはトランスポートまたはトンネルのいずれかです。
Case 1. The case of providing end-to-end security between 2 hosts across the Internet (or an Intranet).
ケース1.インターネット（またはイントラネット）を介して2つのホスト間でエンドツーエンドのセキュリティを提供するケース。
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the hosts. So the headers in a packet between H1 and H2 could look like any of the following:
ホストはトランスポートモードまたはトンネルモードのいずれかを選択できることに注意してください。したがって、H1とH2の間のパケットのヘッダーは、次のようになります。
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet.
一般的なネストをサポートする必要はありませんが、トランスポートモードでは、AHとESPの両方をパケットに適用できることに注意してください。この場合、SA確立手順では、最初にESP、次にAHがパケットに適用されることを確認する必要があります。
Case 2. This case illustrates simple virtual private networks support.
ケース2。このケースは、単純な仮想プライベートネットワークのサポートを示しています。
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Only tunnel mode is required here. So the headers in a packet between SG1 and SG2 could look like either of the following:
ここではトンネルモードのみが必要です。したがって、SG1とSG2の間のパケットのヘッダーは、次のいずれかのようになります。
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Case 3. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it.
ケース3。このケースは、ケース1と2を組み合わせて、送信ホストと受信ホストの間にエンドツーエンドのセキュリティを追加します。ホストまたはセキュリティゲートウェイに新しい要件を課すことはありません。ただし、セキュリティゲートウェイがその背後にあるホストのIPsecトラフィック（ISAKMPトラフィックを含む）を渡すように構成可能である必要があります。
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Case 4. This covers the situation where a remote host (H1) uses the Internet to reach an organization's firewall (SG2) and to then gain access to some server or other machine (H2). The remote host could be a mobile host (H1) dialing up to a local PPP/ARA server (not shown) on the Internet and then crossing the Internet to the home organization's firewall (SG2), etc. The details of support for this case, (how H1 locates SG2, authenticates it, and verifies its authorization to represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway".
ケース4。これは、リモートホスト（H1）がインターネットを使用して組織のファイアウォール（SG2）に到達し、サーバーまたは他のマシン（H2）にアクセスする状況をカバーします。リモートホストは、インターネット上のローカルPPP / ARAサーバー（図には表示されていません）にダイヤルアップし、インターネットをホーム組織のファイアウォール（SG2）などに接続するモバイルホスト（H1）です。このケースのサポートの詳細、（H1がSG2を見つけて認証し、H2を表すための承認を検証する方法）については、4.6.3項「セキュリティゲートウェイの検索」で説明します。
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
Only tunnel mode is required between H1 and SG2. So the choices for the SA between H1 and SG2 would be one of the ones in case 2. The choices for the SA between H1 and H2 would be one of the ones in case 1.
H1とSG2の間にはトンネルモードのみが必要です。したがって、H1とSG2の間のSAの選択肢は、ケース2の選択肢の1つになります。H1とH2の間のSAの選択肢は、ケース1の選択肢の1つになります。
Note that in this case, the sender MUST apply the transport header before the tunnel header. Therefore the management interface to the IPsec implementation MUST support configuration of the SPD and SAD to ensure this ordering of IPsec header application.
この場合、送信者はトンネルヘッダーの前にトランスポートヘッダーを適用する必要があることに注意してください。したがって、IPsec実装への管理インターフェイスは、IPsecヘッダーアプリケーションのこの順序を保証するために、SPDおよびSADの構成をサポートする必要があります。
As noted above, support for additional combinations of AH and ESP is optional. Use of other, optional combinations may adversely affect interoperability.
上記のように、AHとESPの追加の組み合わせのサポートはオプションです。他のオプションの組み合わせを使用すると、相互運用性に悪影響を及ぼす可能性があります。
IPsec mandates support for both manual and automated SA and cryptographic key management. The IPsec protocols, AH and ESP, are largely independent of the associated SA management techniques, although the techniques involved do affect some of the security services offered by the protocols. For example, the optional anti-replay services available for AH and ESP require automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. (See also a discussion of this issue in Section 4.7.) In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the authentication algorithm (or with a key management protocol that creates such secrets) are shared among multiple possible sources.
IPsecは、手動と自動の両方のSAおよび暗号化キー管理のサポートを義務付けています。 IPsecプロトコルであるAHおよびESPは、関連するSA管理技術とはほとんど関係ありませんが、関連する技術は、プロトコルによって提供されるセキュリティサービスの一部に影響を与えます。たとえば、AHおよびESPで利用できるオプションのアンチリプレイサービスには、自動化されたSA管理が必要です。さらに、IPsecで使用される鍵配布の細分性は、提供される認証の細分性を決定します。 （セクション4.7のこの問題の説明も参照してください。）一般に、AHおよびESPでのデータ発信元認証は、認証アルゴリズム（またはそのような秘密を作成する鍵管理プロトコル）で使用される秘密が共有される範囲によって制限されます。複数の可能なソースの間で。
The following text describes the minimum requirements for both types of SA management.
次のテキストでは、両方のタイプのSA管理の最小要件について説明します。
The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist.
管理の最も単純な形式は手動管理です。手動管理では、他のシステムとの安全な通信に関連するキー関連情報とセキュリティアソシエーション管理データを使用して、各システムを手動で構成します。手動の手法は、静的な小規模環境では実用的ですが、拡張性が不十分です。たとえば、企業は複数のサイトのセキュリティゲートウェイでIPsecを使用して仮想プライベートネットワーク（VPN）を作成できます。サイトの数が少なく、すべてのサイトが単一の管理ドメインの管理下にあるため、これは手動管理手法の実行可能なコンテキストになる可能性があります。この場合、セキュリティゲートウェイは、手動で設定されたキーを使用して、組織内の他のサイトとの間のトラフィックを選択的に保護し、他の宛先のトラフィックは保護しない可能性があります。また、選択された通信のみを保護する必要がある場合にも適しています。少数のホストまたはゲートウェイ、あるいはその両方の組織内で完全にIPsecを使用する場合にも、同様の議論が当てはまる可能性があります。手動管理手法では、静的に構成された対称鍵を使用することがよくありますが、他のオプションも存在します。
Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.)
IPsecの広範な展開と使用には、インターネット標準のスケーラブルな自動化されたSA管理プロトコルが必要です。このようなサポートは、AHおよびESPのリプレイ防止機能の使用を容易にし、SAのオンデマンド作成に対応するために必要です（たとえば、ユーザー指向およびセッション指向のキーイングなど）。 （SAを「再キーイング」するという概念は、実際には新しいSPIで新しいSAを作成することを意味し、プロセスは一般に自動化されたSA /キー管理プロトコルの使用を意味することに注意してください。）
The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed.
IPsecで使用するために選択されたデフォルトの自動鍵管理プロトコルは、IPsec解釈ドメイン[Pip98]でのIKE [MSST97、Orm97、HC98]です。他の自動化されたSA管理プロトコルが使用される場合があります。
When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because:
自動化されたSA /キー管理プロトコルが採用されている場合、このプロトコルからの出力を使用して、たとえば単一のESP SAの複数のキーを生成できます。これは次の理由で発生する可能性があります。
o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed
o 暗号化アルゴリズムは複数のキーを使用します（例：トリプルDES）o認証アルゴリズムは複数のキーを使用しますo暗号化アルゴリズムと認証アルゴリズムの両方が使用されます
The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high-order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm.
キー管理システムは、キーごとに個別のビット文字列を提供するか、すべてのビットを抽出する1つのビット文字列を生成します。ビットの単一の文字列が提供される場合、ビットの文字列を必要なキーにマップするシステムの部分がSAの両端で同じようにマッピングされるように注意する必要があります。 SAの両端のIPsec実装が同じキーに同じビットを使用し、システムのどの部分がビットの文字列を個別のキーに分割するかに関係なく、暗号化キーは最初から取得する必要があります。 （左端の上位）ビットと認証キーは、残りのビットから取得する必要があります。各キーのビット数は、関連するアルゴリズム仕様RFCで定義されています。複数の暗号化キーまたは複数の認証キーの場合、アルゴリズムの仕様では、アルゴリズムに提供される単一のビット文字列から選択される順序を指定する必要があります。
This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter.
このセクションでは、ホストが関連するセキュリティゲートウェイの存在について学習する方法、およびホストがこれらのセキュリティゲートウェイに接続した後、これらが正しいセキュリティゲートウェイであることをホストが認識する方法に関する問題について説明します。必要な情報が格納される場所の詳細は、ローカルの問題です。
Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues:
リモートホスト（H1）がインターネットを使用してサーバーまたは他のマシン（H2）にアクセスしていて、H1のトラフィックが通過する必要があるセキュリティゲートウェイ（SG2）（ファイアウォールなど）がある状況を考えます。この状況の例は、インターネットを経由してホーム組織のファイアウォール（SG2）に移動するモバイルホスト（Road Warrior）です。 （セクション4.5のセキュリティアソシエーションの基本的な組み合わせのケース4を参照してください。）この状況では、いくつかの問題が発生します。
1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2?
1. H1は、セキュリティゲートウェイSG2の存在をどのようにして知る/学ぶのですか？ 2. SG2をどのように認証し、SG2を認証したら、SG2がH2を表すことを承認されていることをどのように確認しますか？ 3. SG2はどのようにしてH1を認証し、H1がH2に連絡することを許可されていることを確認しますか？ 4. H1は、H2への代替パスを提供するバックアップゲートウェイをどのようにして認識/学習しますか？
To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure:
これらの問題に対処するには、ホストまたはセキュリティゲートウェイに、ユーザー/管理者がセキュリティゲートウェイのアドレスを、その使用を必要とする宛先アドレスのセットに対して構成できるようにする管理インターフェイスが必要です。これには、以下を構成する機能が含まれます。
o the requisite information for locating and authenticating the security gateway and verifying its authorization to represent the destination host. o the requisite information for locating and authenticating any backup gateways and verifying their authorization to represent the destination host.
o セキュリティゲートウェイを見つけて認証し、宛先ホストを表すための承認を確認するために必要な情報。 oバックアップゲートウェイを見つけて認証し、宛先ホストを表すための承認を確認するために必要な情報。
It is assumed that the SPD is also configured with policy information that covers any other IPsec requirements for the path to the security gateway and the destination host.
SPDには、セキュリティゲートウェイと宛先ホストへのパスに関する他のIPsec要件をカバーするポリシー情報も設定されていることを前提としています。
This document does not address the issue of how to automate the discovery/verification of security gateways.
このドキュメントでは、セキュリティゲートウェイの検出/検証を自動化する方法の問題は扱いません。
The receiver-orientation of the Security Association implies that, in the case of unicast traffic, the destination system will normally select the SPI value. By having the destination select the SPI value, there is no potential for manually configured Security Associations to conflict with automatically configured (e.g., via a key management protocol) Security Associations or for Security Associations from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems per multicast group. So some system or person will need to coordinate among all multicast groups to select an SPI or SPIs on behalf of each multicast group and then communicate the group's IPsec information to all of the legitimate members of that multicast group via mechanisms not defined here.
セキュリティアソシエーションの受信者指向は、ユニキャストトラフィックの場合、宛先システムが通常SPI値を選択することを意味します。宛先にSPI値を選択させることにより、手動で構成されたセキュリティアソシエーションが、自動で構成された（たとえば、キー管理プロトコルを介して）セキュリティアソシエーションと競合したり、複数のソースからのセキュリティアソシエーションが競合したりする可能性はありません。マルチキャストトラフィックの場合、マルチキャストグループごとに複数の宛先システムがあります。そのため、一部のシステムまたは人は、すべてのマルチキャストグループ間で調整して、各マルチキャストグループに代わってSPIを選択し、ここで定義されていないメカニズムを介して、グループのIPsec情報をそのマルチキャストグループの正当なメンバー全員に伝達する必要があります。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence Security Parameter Index) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed. In such circumstances, the receiver knows only that the message came from a system possessing the key for that multicast group. In such circumstances, a receiver generally will not be able to authenticate which system sent the multicast traffic. Specifications for other, more general multicast cases are deferred to later IPsec documents.
対称キー暗号化または認証アルゴリズムが採用されている場合、マルチキャストグループへの複数の送信者は、そのグループへのすべてのトラフィックに対して単一のセキュリティアソシエーション（したがってセキュリティパラメータインデックス）を使用する必要があります（SHOULD）。このような状況では、受信者は、メッセージがそのマルチキャストグループのキーを所有するシステムから送信されたことを知っているだけです。このような状況では、受信者は通常、どのシステムがマルチキャストトラフィックを送信したかを認証できません。その他のより一般的なマルチキャストケースの仕様は、後のIPsecドキュメントに委ねられます。
At the time this specification was published, automated protocols for multicast key distribution were not considered adequately mature for standardization. For multicast groups having relatively few members, manual key distribution or multiple use of existing unicast key distribution algorithms such as modified Diffie-Hellman appears feasible. For very large groups, new scalable techniques will be needed. An example of current work in this area is the Group Key Management Protocol (GKMP) [HM97].
この仕様が公開された時点では、マルチキャストキー配布用の自動化プロトコルは、標準化に十分成熟しているとは見なされていませんでした。メンバーが比較的少ないマルチキャストグループの場合、手動のキー配布、または変更されたDiffie-Hellmanなどの既存のユニキャストキー配布アルゴリズムの複数使用が実現可能と思われます。非常に大規模なグループの場合、新しいスケーラブルな技術が必要になります。この領域での現在の作業の例は、グループキー管理プロトコル（GKMP）[HM97]です。
As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", the SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is found in the SPD that matches the packet (for either inbound or outbound traffic), the packet MUST be discarded.
セクション4.4.1「セキュリティポリシーデータベース（SPD）」で述べたように、非IPsecトラフィックを含むすべてのトラフィック（INBOUNDおよびOUTBOUND）の処理中にSPDを調べる必要があります。 （インバウンドまたはアウトバウンドのいずれかのトラフィックの）パケットに一致するポリシーがSPDで見つからない場合は、パケットを破棄する必要があります。
NOTE: All of the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix in RFC 791) and generate their output in canonical network byte order. IP packets are also transmitted in network byte order.
注：IPsecで使用されるすべての暗号化アルゴリズムは、標準ネットワークバイトオーダーでの入力を想定し（RFC 791の付録を参照）、標準ネットワークバイトオーダーで出力を生成します。 IPパケットもネットワークバイトオーダーで送信されます。
In a security gateway or BITW implementation (and in many BITS implementations), each outbound packet is compared against the SPD to determine what processing is required for the packet. If the packet is to be discarded, this is an auditable event. If the traffic is allowed to bypass IPsec processing, the packet continues through "normal" processing for the environment in which the IPsec processing is taking place. If IPsec processing is required, the packet is either mapped to an existing SA (or SA bundle), or a new SA (or SA bundle) is created for the packet. Since a packet's selectors might match multiple policies or multiple extant SAs and since the SPD is ordered, but the SAD is not, IPsec MUST:
セキュリティゲートウェイまたはBITW実装（および多くのBITS実装）では、各送信パケットがSPDと比較され、パケットに必要な処理が決定されます。パケットが破棄される場合、これは監査可能なイベントです。トラフィックがIPsec処理のバイパスを許可されている場合、パケットはIPsec処理が行われている環境の「通常の」処理を続行します。 IPsec処理が必要な場合、パケットは既存のSA（またはSAバンドル）にマッピングされるか、パケット用に新しいSA（またはSAバンドル）が作成されます。パケットのセレクターは複数のポリシーまたは複数の現存するSAに一致する可能性があり、SPDは順序付けされているがSADは順序付けされていないため、IPsecは次の条件を満たす必要があります。
1. Match the packet's selector fields against the outbound policies in the SPD to locate the first appropriate policy, which will point to zero or more SA bundles in the SAD.
1. パケットのセレクターフィールドをSPDの送信ポリシーと照合して、SADの0個以上のSAバンドルを指す最初の適切なポリシーを見つけます。
2. Match the packet's selector fields against those in the SA bundles found in (1) to locate the first SA bundle that matches. If no SAs were found or none match, create an appropriate SA bundle and link the SPD entry to the SAD entry. If no key management entity is found, drop the packet.
2. パケットのセレクタフィールドを、（1）で見つかったSAバンドルのフィールドと照合して、一致する最初のSAバンドルを見つけます。 SAが見つからないか、一致するものがない場合は、適切なSAバンドルを作成し、SPDエントリをSADエントリにリンクします。キー管理エンティティが見つからない場合は、パケットをドロップします。
3. Use the SA bundle found/created in (2) to do the required IPsec processing, e.g., authenticate and encrypt.
3. （2）で見つかった/作成されたSAバンドルを使用して、必要なIPsec処理（認証や暗号化など）を実行します。
In a host IPsec implementation based on sockets, the SPD will be consulted whenever a new socket is created, to determine what, if any, IPsec processing will be applied to the traffic that will flow on that socket.
ソケットに基づくホストIPsec実装では、新しいソケットが作成されるたびにSPDが参照され、そのソケットで流れるトラフィックに適用されるIPsec処理がある場合は、その決定が行われます。
NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event.
注：準拠した実装では、NULL暗号化とNULL認証アルゴリズムの両方を使用するESP SAのインスタンス化を許可してはなりません（MUST NOT）。そのようなSAをネゴシエートする試みは監査可能なイベントです。
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels. This includes how to construct the encapsulating (outer) IP header, how to handle fields in the inner IP header, and what other actions should be taken. The general idea is modeled after the one used in RFC 2003, "IP Encapsulation with IP":
このセクションでは、AHおよびESPトンネルの内部および外部IPヘッダー、拡張ヘッダー、オプションの処理について説明します。これには、カプセル化（外部）IPヘッダーを構成する方法、内部IPヘッダーのフィールドを処理する方法、およびその他の必要なアクションが含まれます。一般的な考え方は、RFC 2003で使用されている「IPによるIPカプセル化」をモデルにしています。
o The outer IP header Source Address and Destination Address identify the "endpoints" of the tunnel (the encapsulator and decapsulator). The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, (from the perspective of this tunnel), respectively. (see footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.) o The inner IP header is not changed except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel. o If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header.
o 外部IPヘッダーの送信元アドレスと宛先アドレスは、トンネルの「エンドポイント」（カプセル化装置とカプセル化解除装置）を識別します。内部IPヘッダーの送信元アドレスと宛先アドレスは、（このトンネルの観点から）データグラムの元の送信者と受信者をそれぞれ識別します。 （カプセル化ソースIPアドレスの詳細については、5.1.2.1の表の後の脚注3を参照してください。）o内部IPヘッダーは、以下に示すようにTTLを減らす以外は変更されず、トンネル出口ポイントへの配信中は変更されません。 。 oトンネルを介してカプセル化されたデータグラムを配信している間、内部ヘッダーのIPオプションまたは拡張ヘッダーは変更されません。 o必要に応じて、IP認証ヘッダーなどの他のプロトコルヘッダーを外部IPヘッダーと内部IPヘッダーの間に挿入できます。
The tables in the following sub-sections show the handling for the different header/option fields (constructed = the value in the outer field is constructed independently of the value in the inner).
次のサブセクションの表は、さまざまなヘッダー/オプションフィールドの処理を示しています（構築済み=外部フィールドの値は内部の値とは無関係に構築されます）。
<-- How Outer Hdr Relates to Inner Hdr -->
Outer Hdr at Inner Hdr at
IPv4 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 4 (1) no change
header length constructed no change
TOS copied from inner hdr (5) no change
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragmt offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP, routing hdr no change
checksum constructed constructed (2)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
1. The IP version in the encapsulating header can be different from the value in the inner header.
1. カプセル化ヘッダーのIPバージョンは、内部ヘッダーの値と異なる場合があります。
2. The TTL in the inner header is decremented by the encapsulator prior to forwarding and by the decapsulator if it forwards the packet. (The checksum changes when the TTL changes.)
2. 内部ヘッダーのTTLは、転送前にカプセル化装置によって減らされ、パケットを転送する場合はカプセル化解除装置によって減らされます。 （TTLが変わるとチェックサムも変わります。）
Note: The decrementing of the TTL is one of the usual actions that takes place when forwarding a packet. Packets originating from the same node as the encapsulator do not have their TTL's decremented, as the sending node is originating the packet rather than forwarding it.
注：TTLの減少は、パケットを転送するときに行われる通常のアクションの1つです。送信ノードがパケットを転送するのではなく発信しているため、カプセル化装置と同じノードから発信されたパケットのTTLは減少しません。
3. src and dest addresses depend on the SA, which is used to determine the dest address which in turn determines which src address (net interface) is used to forward the packet.
3. srcおよびdestアドレスはSAに依存します。SAは、destアドレスを決定するために使用されます。SAは、パケットの転送に使用されるsrcアドレス（ネットインターフェイス）を決定します。
NOTE: In principle, the encapsulating IP source address can be any of the encapsulator's interface addresses or even an address different from any of the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as the address is reachable through the encapsulator from the environment into which the packet is sent. This does not cause a problem because IPsec does not currently have any INBOUND processing requirement that involves the Source Address of the encapsulating IP header. So while the receiving tunnel endpoint looks at the Destination Address in the encapsulating IP header, it only looks at the Source Address in the inner (encapsulated) IP header.
注：原則として、カプセル化IP送信元アドレスは、アドレスが到達可能である限り、カプセル化装置のインターフェースアドレスのいずれか、またはカプセル化装置のIPアドレスとは異なるアドレス（たとえば、NATボックスとして機能している場合）にすることができます。パケットが送信される環境からのカプセル化装置。現在、IPsecにはカプセル化IPヘッダーの送信元アドレスを含むINBOUND処理要件がないため、問題は発生しません。したがって、受信トンネルエンドポイントはカプセル化IPヘッダーの宛先アドレスを確認しますが、内部（カプセル化）IPヘッダーの送信元アドレスのみを確認します。
4. configuration determines whether to copy from the inner header (IPv4 only), clear or set the DF.
4. 構成は、内部ヘッダーからコピーするか（IPv4のみ）、DFをクリアまたは設定するかを決定します。
5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner Hdr is IPv6 (Protocol = 41), map the Class to TOS.
5. 内部HdrがIPv4（プロトコル= 4）の場合、TOSをコピーします。内部HdrがIPv6（プロトコル= 41）の場合、クラスをTOSにマップします。
See previous section 5.1.2 for notes 1-5 indicated by (footnote number).
（脚注番号）で示される注1〜5については、前のセクション5.1.2を参照してください。
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
class copied or configured (6) no change
flow id copied or configured no change
len constructed no change
next header AH,ESP,routing hdr no change
hop limit constructed (2) decrement (2)
src address constructed (3) no change
dest address constructed (3) no change
Extension headers never copied no change
6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class.
6. 内部HdrがIPv6（次のヘッダー= 41）の場合、クラスをコピーします。内部HdrがIPv4（次のヘッダー= 4）の場合、TOSをクラスにマップします。
Prior to performing AH or ESP processing, any IP fragments are reassembled. Each inbound IP datagram to which IPsec processing will be applied is identified by the appearance of the AH or ESP values in the IP Next Protocol field (or of AH or ESP as an extension header in the IPv6 context).
AHまたはESP処理を実行する前に、IPフラグメントが再構成されます。 IPsec処理が適用される各受信IPデータグラムは、IP Next ProtocolフィールドのAHまたはESP値（またはIPv6コンテキストの拡張ヘッダーとしてのAHまたはESP）の出現によって識別されます。
Note: Appendix C contains sample code for a bitmask check for a 32 packet window that can be used for implementing anti-replay service.
注：付録Cには、アンチリプレイサービスの実装に使用できる32パケットウィンドウのビットマスクチェックのサンプルコードが含まれています。
Mapping the IP datagram to the appropriate SA is simplified because of the presence of the SPI in the AH or ESP header. Note that the selector checks are made on the inner headers not the outer (tunnel) headers. The steps followed are:
AHまたはESPヘッダーにSPIが存在するため、IPデータグラムの適切なSAへのマッピングは単純化されています。セレクターチェックは、外部（トンネル）ヘッダーではなく、内部ヘッダーに対して行われることに注意してください。続くステップは：
1. Use the packet's destination address (outer IP header), IPsec protocol, and SPI to look up the SA in the SAD. If the SA lookup fails, drop the packet and log/report the error.
1. パケットの宛先アドレス（外部IPヘッダー）、IPsecプロトコル、およびSPIを使用して、SADでSAを検索します。 SAルックアップが失敗した場合は、パケットをドロップし、エラーを記録または報告します。
2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's (Inner Header if tunneled) selectors to the selectors in the SA. Local policy determines the specificity of the SA selectors (single value, list, range, wildcard). In general, a packet's source address MUST match the SA selector value. However, an ICMP packet received on a tunnel mode SA may have a source address other than that bound to the SA and thus such packets should be permitted as exceptions to this check. For an ICMP packet, the selectors from the enclosed problem packet (the source and destination addresses and ports should be swapped) should be checked against the selectors for the SA. Note that some or all of these selectors may be inaccessible because of limitations on how many bits of the problem packet the ICMP packet is allowed to carry or due to encryption. See Section 6.
2. （1）にあるSAを使用して、認証や復号化などのIPsec処理を実行します。この手順には、パケットの（トンネリングされている場合は内部ヘッダー）セレクターをSAのセレクターと照合することが含まれます。ローカルポリシーは、SAセレクターの特定性（単一の値、リスト、範囲、ワイルドカード）を決定します。一般に、パケットの送信元アドレスはSAセレクターの値と一致する必要があります。ただし、トンネルモードSAで受信したICMPパケットは、SAにバインドされたもの以外の送信元アドレスを持っている可能性があるため、このようなパケットはこのチェックの例外として許可する必要があります。 ICMPパケットの場合、囲まれた問題のパケットからのセレクター（送信元と宛先のアドレスとポートを交換する必要があります）を、SAのセレクターに対してチェックする必要があります。これらのセレクターの一部またはすべては、ICMPパケットが運ぶことを許可されている問題のあるパケットのビット数に制限があるため、または暗号化のため、アクセスできない場合があることに注意してください。セクション6を参照してください。
Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application.
このシステムにないトランスポートプロトコルヘッダーまたはIPヘッダーが検出されるまで、すべてのIPsecヘッダーに対して（1）および（2）を実行します。使用されたSAとその適用順序を追跡します。
3. Find an incoming policy in the SPD that matches the packet. This could be done, for example, by use of backpointers from the SAs to the SPD or by matching the packet's selectors (Inner Header if tunneled) against those of the policy entries in the SPD.
3. パケットに一致するSPDで着信ポリシーを検索します。これは、たとえば、SAからSPDへのバックポインターを使用するか、パケットのセレクター（トンネリングされている場合は内部ヘッダー）をSPDのポリシーエントリのセレクターと照合することで実行できます。
4. Check whether the required IPsec processing has been applied, i.e., verify that the SA's found in (1) and (2) match the kind and order of SAs required by the policy found in (3).
4. 必要なIPsec処理が適用されているかどうかを確認します。つまり、（1）と（2）で見つかったSAが、（3）で見つかったポリシーで必要なSAの種類と順序と一致していることを確認します。
NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds.
注：正しい「一致」ポリシーは、必ずしも最初に見つかった受信ポリシーとは限りません。 （4）のチェックが失敗した場合、すべてのポリシーエントリがチェックされるまで、またはチェックが成功するまで、手順（3）および（4）が繰り返されます。
At the end of these steps, pass the resulting packet to the Transport Layer or forward the packet. Note that any IPsec headers processed in these steps may have been removed, but that this information, i.e., what SAs were used and the order of their application, may be needed for subsequent IPsec or firewall processing.
これらの手順の最後に、結果のパケットをトランスポート層に渡すか、パケットを転送します。これらの手順で処理されたIPsecヘッダーは削除されている可能性がありますが、この情報（つまり、使用されたSAとそのアプリケーションの順序）は、後続のIPsecまたはファイアウォール処理で必要になる場合があります。
Note that in the case of a security gateway, if forwarding causes a packet to exit via an IPsec-enabled interface, then additional IPsec processing may be applied.
セキュリティゲートウェイの場合、転送によってIPsec対応のインターフェイスを介してパケットが終了する場合、追加のIPsec処理が適用される可能性があることに注意してください。
The handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels should be performed as described in the tables in Section 5.1.
内部および外部IPヘッダー、拡張ヘッダー、およびAHトンネルとESPトンネルのオプションの処理は、セクション5.1の表の説明に従って実行する必要があります。
The focus of this section is on the handling of ICMP error messages. Other ICMP traffic, e.g., Echo/Reply, should be treated like other traffic and can be protected on an end-to-end basis using SAs in the usual fashion.
このセクションの焦点は、ICMPエラーメッセージの処理にあります。 Echo / Replyなどの他のICMPトラフィックは、他のトラフィックと同様に処理する必要があり、通常の方法でSAを使用してエンドツーエンドで保護できます。
An ICMP error message protected by AH or ESP and generated by a router SHOULD be processed and forwarded in a tunnel mode SA. Local policy determines whether or not it is subjected to source address checks by the router at the destination end of the tunnel. Note that if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail. An ICMP message protected by AH or ESP and generated by a router MUST NOT be forwarded on a transport mode SA (unless the SA has been established to the router acting as a host, e.g., a Telnet connection used to manage a router). An ICMP message generated by a host SHOULD be checked against the source IP address selectors bound to the SA in which the message arrives. Note that even if the source of an ICMP error message is authenticated, the returned IP header could be invalid. Accordingly, the selector values in the IP header SHOULD also be checked to be sure that they are consistent with the selectors for the SA over which the ICMP message was received.
AHまたはESPによって保護され、ルーターによって生成されたICMPエラーメッセージは、トンネルモードSAで処理および転送される必要があります（SHOULD）。ローカルポリシーは、トンネルの宛先側のルーターによる送信元アドレスチェックの対象かどうかを決定します。トンネルの発信側のルーターが別のルーターからICMPエラーメッセージを転送している場合、送信元アドレスのチェックは失敗することに注意してください。 AHまたはESPで保護され、ルーターで生成されたICMPメッセージは、トランスポートモードSAで転送してはなりません（SAがホストとして機能するルーターに確立されていない場合（ルーターの管理に使用されるTelnet接続など））。ホストによって生成されたICMPメッセージは、メッセージが到着するSAにバインドされたソースIPアドレスセレクターに対してチェックする必要があります（SHOULD）。 ICMPエラーメッセージの送信元が認証された場合でも、返されたIPヘッダーが無効になる可能性があることに注意してください。したがって、IPヘッダーのセレクター値も確認して、ICMPメッセージが受信されたSAのセレクターと一致していることを確認してください。
The table in Appendix D characterize ICMP messages as being either host generated, router generated, both, unknown/unassigned. ICMP messages falling into the last two categories should be handled as determined by the receiver's policy.
付録Dの表は、ICMPメッセージをホスト生成、ルーター生成、不明/未割り当てのいずれかとして示しています。最後の2つのカテゴリに分類されるICMPメッセージは、受信者のポリシーで決定されたとおりに処理する必要があります。
An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial of service. This suggests that, in general, it would be desirable to ignore such messages. However, it is expected that many routers (vs. security gateways) will not implement IPsec for transit traffic and thus strict adherence to this rule would cause many ICMP messages to be discarded. The result is that some critical IP functions would be lost, e.g., redirection and PMTU processing. Thus it MUST be possible to configure an IPsec implementation to accept or reject (router) ICMP traffic as per local security policy.
AHまたはESPで保護されていないICMPメッセージは認証されておらず、その処理または転送、あるいはその両方によってサービス拒否が発生する可能性があります。これは、一般に、そのようなメッセージを無視することが望ましいことを示唆しています。ただし、多くのルーター（対セキュリティゲートウェイ）は通過トラフィックにIPsecを実装しないことが予想されるため、このルールを厳密に遵守すると、多くのICMPメッセージが破棄されます。その結果、一部の重要なIP機能（リダイレクトやPMTU処理など）が失われます。したがって、ローカルセキュリティポリシーに従って（ルーター）ICMPトラフィックを受け入れるか拒否するようにIPsec実装を構成できる必要があります。
The remainder of this section addresses how PMTU processing MUST be performed at hosts and security gateways. It addresses processing of both authenticated and unauthenticated ICMP PMTU messages. However, as noted above, unauthenticated ICMP messages MAY be discarded based on local policy.
このセクションの残りの部分では、ホストとセキュリティゲートウェイでPMTU処理を実行する方法について説明します。認証済みおよび未認証の両方のICMP PMTUメッセージの処理を扱います。ただし、上記のように、認証されていないICMPメッセージはローカルポリシーに基づいて破棄される場合があります。
In cases where a system (host or gateway) adds an encapsulating header (ESP tunnel or AH tunnel), it MUST support the option of copying the DF bit from the original packet to the encapsulating header (and processing ICMP PMTU messages). This means that it MUST be possible to configure the system's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface. (See Appendix B for rationale.)
システム（ホストまたはゲートウェイ）がカプセル化ヘッダー（ESPトンネルまたはAHトンネル）を追加する場合、元のパケットからカプセル化ヘッダーにDFビットをコピーする（およびICMP PMTUメッセージを処理する）オプションをサポートする必要があります。これは、インターフェイスごとにシステムによるDFビットの処理（設定、クリア、カプセル化されたヘッダーからのコピー）を構成できる必要があることを意味します。 （根拠については、付録Bを参照してください。）
This section discusses IPsec handling for Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for:
このセクションでは、Path MTU DiscoveryメッセージのIPsec処理について説明します。 ICMP PMTUは、ここでICMPメッセージを参照するために使用されます。
IPv4 (RFC 792): - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero
IPv4（RFC 792）：-タイプ= 3（Destination Unreachable）-コード= 4（フラグメンテーションが必要、DFセット）-ICMPヘッダーの2番目のワードの下位16ビットのネクストホップMTU（「未使用」というラベルが付いている） RFC 792）、高位16ビットがゼロに設定されている
IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message
IPv6（RFC 1885）：-タイプ= 2（パケットが大きすぎます）-コード= 0（フラグメンテーションが必要です）-ICMP6メッセージの32ビットMTUフィールドのネクストホップMTU
The amount of information returned with the ICMP PMTU message (IPv4 or IPv6) is limited and this affects what selectors are available for use in further propagating the PMTU information. (See Appendix B for more detailed discussion of this topic.)
ICMP PMTUメッセージ（IPv4またはIPv6）で返される情報の量は制限されており、これはPMTU情報をさらに伝達するために使用できるセレクターに影響します。 （このトピックの詳細については、付録Bを参照してください。）
o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU message contains only 64 bits of the IPsec header (minimum for IPv4), then a security gateway MUST support the following options on a per SPI/SA basis:
o 64ビットのIPsecヘッダーを含むPMTUメッセージ-ICMP PMTUメッセージに64ビットのIPsecヘッダーのみが含まれる場合（IPv4の最小値）、セキュリティゲートウェイはSPI / SAごとに次のオプションをサポートする必要があります。
a. if the originating host can be determined (or the possible sources narrowed down to a manageable number), send the PM information to all the possible originating hosts. b. if the originating host cannot be determined, store the PMTU with the SA and wait until the next packet(s) arrive from the originating host for the relevant security association. If the packet(s) are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the ICMP message(s) about the problem to the originating host. Retain the PMTU information for any message that might arrive subsequently (see Section 6.1.2.4, "PMTU Aging").
a。発信元ホストを特定できる場合（または考えられるソースを管理可能な数に絞り込んだ場合）、考えられるすべての発信元ホストにPM情報を送信します。 b。発信元ホストを特定できない場合は、PMTUをSAとともに保存し、関連するセキュリティアソシエーションの発信元ホストから次のパケットが到着するまで待ちます。パケットがPMTUより大きい場合は、パケットをドロップし、新しいパケットと更新されたPMTUでICMP PMTUメッセージを作成し、問題に関するICMPメッセージを送信します。元のホストに。その後到着する可能性のあるメッセージのPMTU情報を保持します（6.1.2.4項「PMTUエージング」を参照）。
o PMTU message with >64 bits of IPsec header -- If the ICMP message contains more information from the original packet then there may be enough non-opaque information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path.
o 64ビットを超えるIPsecヘッダーを含むPMTUメッセージ-ICMPメッセージに元のパケットからの情報がさらに含まれている場合、不透明でない情報が十分にあり、どのホストにICMP / PMTUメッセージを伝播し、そのシステムに提供するかをすぐに判断できます。 PMTUを格納/更新する場所を決定するために必要な5つのフィールド（送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、トランスポートプロトコル）。このような状況では、セキュリティゲートウェイは、パスのさらに下からICMP PMTUを受信するとすぐにICMP PMTUメッセージを生成する必要があります。
o Distributing the PMTU to the Transport Layer -- The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
o トランスポート層へのPMTUの配布-RFC 1191（Path MTU Discovery）で指定されているように、更新されたPMTUをトランスポート層に取得するためのホストメカニズムは変更されていません。
The calculation of PMTU from an ICMP PMTU MUST take into account the addition of any IPsec header -- AH transport, ESP transport, AH/ESP transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of implementation issues.)
ICMP PMTUからのPMTUの計算では、IPsecヘッダー（AHトランスポート、ESPトランスポート、AH / ESPトランスポート、ESPトンネル、AHトンネル）の追加を考慮する必要があります。 （実装の問題については、付録Bを参照してください。）
Note: In some situations the addition of IPsec headers could result in an effective PMTU (as seen by the host or application) that is unacceptably small. To avoid this problem, the implementation may establish a threshold below which it will not report a reduced PMTU. In such cases, the implementation would apply IPsec and then fragment the resulting packet according to the PMTU. This would result in a more efficient use of the available bandwidth.
注：状況によっては、IPsecヘッダーを追加すると、有効なPMTU（ホストまたはアプリケーションから見た場合）が許容できないほど小さくなる可能性があります。この問題を回避するために、実装では、それを下回るとPMTUの低下を報告しないしきい値を設定できます。このような場合、実装ではIPsecを適用し、PMTUに従って結果のパケットをフラグメント化します。これにより、使用可能な帯域幅をより効率的に使用できます。
In hosts, the granularity with which ICMP PMTU processing can be done differs depending on the implementation situation. Looking at a host, there are 3 situations that are of interest with respect to PMTU issues (See Appendix B for additional details on this topic.):
ホストでは、ICMP PMTU処理を実行できる精度は、実装状況によって異なります。ホストを見ると、PMTUの問題に関して興味深い状況が3つあります（このトピックの詳細については、付録Bを参照してください）。
a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers
a。 IPsecのネイティブIP実装への統合b。バンプインザスタックの実装。IPsecは、TCP / IPプロトコルスタックの既存の実装の下に、ネイティブIPとローカルネットワークドライバーの間に実装されます。
c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host.
c。 IPsec実装なし-この例は、セキュリティゲートウェイがPMTU情報をホストに送り返す場合に関連するため含まれています。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In (b) and (c), the IP layer will only be able to maintain PMTU data at the granularity of source and destination IP addresses (and optionally TOS), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms).
（a）の場合のみ、PMTUデータを通信アソシエーションと同じ粒度で維持できます。 （b）と（c）では、RFC 1191で説明されているように、IP層は送信元と宛先のIPアドレス（およびオプションでTOS）の粒度でのみPMTUデータを維持できます。これは重要な違いです。 1つの通信アソシエーションは同じ送信元および宛先IPアドレスにマップすることができ、各通信アソシエーションは異なる量のIPsecヘッダーオーバーヘッドを持っている可能性があります（たとえば、異なるトランスフォームまたは異なるアルゴリズムの使用により）。
Implementation of the calculation of PMTU and support for PMTUs at the granularity of individual communication associations is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The calculation of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
個々の通信アソシエーションの粒度でのPMTUの計算とPMTUのサポートの実装は、ローカルな問題です。ただし、ホストでのIPsecのソケットベースの実装は、ソケットごとに情報を維持する必要があります（SHOULD）。スタックシステムのバンプは、これらのシステムによって追加されたIPsecヘッダーオーバーヘッドに合わせてICMP PMTUを調整した後、ホストIP実装に渡す必要があります。オーバーヘッドの計算は、返されたICMP PMTUメッセージに存在するSPIおよびその他のセレクター情報の分析によって決定する必要があります（SHOULD）。
In all systems (host or gateway) implementing IPsec and maintaining PMTU information, the PMTU associated with a security association (transport or tunnel) MUST be "aged" and some mechanism put in place for updating the PMTU in a timely manner, especially for discovering if the PMTU is smaller than it needs to be. A given PMTU has to remain in place long enough for a packet to get from the source end of the security association to the system at the other end of the security association and propagate back an ICMP error message if the current PMTU is too big. Note that if there are nested tunnels, multiple packets and round trip times might be required to get an ICMP message back to an encapsulator or originating host.
IPsecを実装してPMTU情報を維持するすべてのシステム（ホストまたはゲートウェイ）では、セキュリティアソシエーション（トランスポートまたはトンネル）に関連付けられたPMTUを「エージング」し、PMTUをタイムリーに更新するために、特に検出のために何らかのメカニズムを導入する必要があります。 PMTUが必要以上に小さい場合。所定のPMTUは、パケットがセキュリティアソシエーションのソースエンドからセキュリティアソシエーションのもう一方の端にあるシステムに到達し、現在のPMTUが大きすぎる場合はICMPエラーメッセージを伝搬するのに十分な長さである必要があります。ネストされたトンネルがある場合、カプセル化装置または発信元ホストにICMPメッセージを返すために、複数のパケットと往復時間が必要になる場合があることに注意してください。
Systems SHOULD use the approach described in the Path MTU Discovery document (RFC 1191, Section 6.3), which suggests periodically resetting the PMTU to the first-hop data-link MTU and then letting the normal PMTU Discovery processes update the PMTU as necessary. The period SHOULD be configurable.
システムは、パスMTU発見ドキュメント（RFC 1191、セクション6.3）で説明されているアプローチを使用する必要があります。これは、定期的にPMTUを最初のホップのデータリンクMTUにリセットし、通常のPMTU発見プロセスに必要に応じてPMTUを更新させることを推奨します。期間は設定可能である必要があります。
Not all systems that implement IPsec will implement auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in the AH and ESP specifications and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported transmitter in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
IPsecを実装するすべてのシステムが監査を実装するわけではありません。ほとんどの場合、監査の粒度はローカルな問題です。ただし、AHとESPの仕様ではいくつかの監査可能なイベントが特定されており、これらの各イベントについて、監査ログに含める必要がある最低限の情報のセットが定義されています。これらの各イベントの追加情報も監査ログに含めることができます。また、この仕様で明示的に呼び出されていない追加のイベントも、監査ログエントリになります。このようなアクションを介してサービス拒否を引き起こす可能性があるため、監査可能なイベントの検出に応答して、レシーバーがメッセージをトランスミッターに送信する必要はありません。
Information of various sensitivity levels may be carried over a single network. Information labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish such information. The use of labels facilitates segregation of information, in support of information flow security models, e.g., the Bell-LaPadula model [BL73]. Such models, and corresponding supporting technology, are designed to prevent the unauthorized flow of sensitive information, even in the face of Trojan Horse attacks. Conventional, discretionary access control (DAC) mechanisms, e.g., based on access control lists, generally are not sufficient to support such policies, and thus facilities such as the SPD do not suffice in such environments.
さまざまな感度レベルの情報が単一のネットワークを介して伝送される場合があります。情報ラベル（例：Unclassified、Company Proprietary、Secret）[DoD85、DoD87]は、そのような情報を区別するためによく使用されます。ラベルを使用すると、情報フローのセキュリティモデル（Bell-LaPadulaモデルなど）をサポートして、情報の分離が容易になります[BL73]。このようなモデルと対応するサポート技術は、トロイの木馬攻撃に直面した場合でも、機密情報の不正な流れを防ぐように設計されています。たとえばアクセス制御リストに基づく従来の随意アクセス制御（DAC）メカニズムは、一般にそのようなポリシーをサポートするのに十分ではないため、SPDなどの機能ではこのような環境では不十分です。
In the military context, technology that supports such models is often referred to as multi-level security (MLS). Computers and networks often are designated "multi-level secure" if they support the separation of labelled data in conjunction with information flow security policies. Although such technology is more broadly applicable than just military applications, this document uses the acronym "MLS" to designate the technology, consistent with much extant literature.
軍事の文脈では、そのようなモデルをサポートするテクノロジーは、しばしばマルチレベルセキュリティ（MLS）と呼ばれます。コンピュータとネットワークは、情報フローセキュリティポリシーと組み合わせてラベル付きデータの分離をサポートしている場合、「マルチレベルセキュア」と呼ばれることがよくあります。そのようなテクノロジーは、軍事用途だけでなくより広く適用できますが、このドキュメントでは、テクノロジーを指定するために「MLS」という頭字語を使用します。
IPsec mechanisms can easily support MLS networking. MLS networking requires the use of strong Mandatory Access Controls (MAC), which unprivileged users or unprivileged processes are incapable of controlling or violating. This section pertains only to the use of these IP security mechanisms in MLS (information flow security policy) environments. Nothing in this section applies to systems not claiming to provide MLS.
IPsecメカニズムは、MLSネットワークを簡単にサポートできます。 MLSネットワーキングでは、強力な強制アクセス制御（MAC）を使用する必要があります。これは、非特権ユーザーまたは非特権プロセスが制御または違反することはできません。このセクションは、MLS（情報フローセキュリティポリシー）環境でのこれらのIPセキュリティメカニズムの使用にのみ関係します。このセクションの内容は、MLSの提供を要求していないシステムには適用されません。
As used in this section, "sensitivity information" might include implementation-defined hierarchic levels, categories, and/or releasability information.
このセクションで使用されている「機密情報」には、実装で定義された階層レベル、カテゴリ、リリース情報などが含まれる場合があります。
AH can be used to provide strong authentication in support of mandatory access control decisions in MLS environments. If explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and confidentiality is not considered necessary within the particular operational environment, AH can be used to authenticate the binding between sensitivity labels in the IP header and the IP payload (including user data). This is a significant improvement over labeled IPv4 networks where the sensitivity information is trusted even though there is no authentication or cryptographic binding of the information to the IP header and user data. IPv4 networks might or might not use explicit labelling. IPv6 will normally use implicit sensitivity information that is part of the IPsec Security Association but not transmitted with each packet instead of using explicit sensitivity information. All explicit IP sensitivity information MUST be authenticated using either ESP, AH, or both.
AHを使用して、MLS環境での必須のアクセス制御決定をサポートする強力な認証を提供できます。明示的なIP機密情報（例：IPSO [Ken91]）が使用され、特定の運用環境で機密性が必要ないと考えられる場合、AHを使用して、IPヘッダーの機密ラベルとIPペイロード（ユーザーデータを含む）間のバインディングを認証できます。 ）。これは、IPヘッダーおよびユーザーデータへの情報の認証または暗号化によるバインドがない場合でも、機密情報が信頼されるラベル付きIPv4ネットワークを大幅に改善したものです。 IPv4ネットワークでは、明示的なラベル付けを使用する場合と使用しない場合があります。 IPv6は通常、明示的な機密情報を使用する代わりに、IPsecセキュリティアソシエーションの一部であるが各パケットで送信されない暗黙的な機密情報を使用します。すべての明示的なIP機密情報は、ESP、AH、またはその両方を使用して認証される必要があります。
Encryption is useful and can be desirable even when all of the hosts are within a protected environment, for example, behind a firewall or disjoint from any external connectivity. ESP can be used, in conjunction with appropriate key management and encryption algorithms, in support of both DAC and MAC. (The choice of encryption and authentication algorithms, and the assurance level of an IPsec implementation will determine the environments in which an implementation may be deemed sufficient to satisfy MLS requirements.) Key management can make use of sensitivity information to provide MAC. IPsec implementations on systems claiming to provide MLS SHOULD be capable of using IPsec to provide MAC for IP-based communications.
暗号化は有用であり、すべてのホストが保護された環境内にある場合でも、たとえばファイアウォールの背後にある場合や、外部接続から切り離されている場合でも望ましい場合があります。 ESPは、適切なキー管理および暗号化アルゴリズムと組み合わせて、DACとMACの両方をサポートして使用できます。 （暗号化アルゴリズムと認証アルゴリズムの選択、およびIPsec実装の保証レベルによって、MLS要件を満たすのに十分であると見なされる実装環境が決まります。鍵管理では、機密情報を利用してMACを提供できます。 MLSを提供すると主張するシステムでのIPsec実装は、IPsecを使用してIPベースの通信にMACを提供できる必要があります（SHOULD）。
Both the Encapsulating Security Payload and the Authentication Header can be combined with appropriate Security Association policies to provide multi-level secure networking. In this case each SA (or SA bundle) is normally used for only a single instance of sensitivity information. For example, "PROPRIETARY - Internet Engineering" must be associated with a different SA (or SA bundle) from "PROPRIETARY - Finance".
カプセル化セキュリティペイロードと認証ヘッダーの両方を適切なセキュリティアソシエーションポリシーと組み合わせて、マルチレベルの安全なネットワークを提供できます。この場合、各SA（またはSAバンドル）は通常、機密情報の単一のインスタンスにのみ使用されます。たとえば、「PROPRIETARY-Internet Engineering」は、「PROPRIETARY-Finance」とは異なるSA（またはSAバンドル）に関連付けられている必要があります。
An MLS implementation (both host and router) MAY associate sensitivity information, or a range of sensitivity information with an interface, or a configured IP address with its associated prefix (the latter is sometimes referred to as a logical interface, or an interface alias). If such properties exist, an implementation SHOULD compare the sensitivity information associated with the packet against the sensitivity information associated with the interface or address/prefix from which the packet arrived, or through which the packet will depart. This check will either verify that the sensitivities match, or that the packet's sensitivity falls within the range of the interface or address/prefix.
MLS実装（ホストとルーターの両方）は、機密性情報、または一連の機密性情報、または構成されたIPアドレスを関連するプレフィックス（後者は、論理インターフェイスまたはインターフェイスエイリアスと呼ばれることもあります）に関連付けることができます（MAY） 。そのようなプロパティが存在する場合、実装は、パケットに関連付けられた機密性情報を、パケットが到着した、またはパケットが通過するインターフェイスまたはアドレス/プレフィックスに関連付けられた機密性情報と比較する必要があります（SHOULD）。このチェックでは、感度が一致すること、またはパケットの感度がインターフェイスまたはアドレス/プレフィックスの範囲内にあることを確認します。
The checking SHOULD be done on both inbound and outbound processing.
チェックは、インバウンドとアウトバウンドの両方の処理で行われる必要があります（SHOULD）。
Section 4.4 discussed two Security Association databases (the Security Policy Database (SPD) and the Security Association Database (SAD)) and the associated policy selectors and SA attributes. MLS networking introduces an additional selector/attribute:
セクション4.4では、2つのセキュリティアソシエーションデータベース（セキュリティポリシーデータベース（SPD）とセキュリティアソシエーションデータベース（SAD））、および関連するポリシーセレクターとSA属性について説明しました。 MLSネットワーキングでは、追加のセレクター/属性が導入されています。
- Sensitivity information.
- 感度情報。
The Sensitivity information aids in selecting the appropriate algorithms and key strength, so that the traffic gets a level of protection appropriate to its importance or sensitivity as described in section 8.1. The exact syntax of the sensitivity information is implementation defined.
機密情報は、適切なアルゴリズムとキー強度を選択するのに役立ちます。これにより、セクション8.1で説明されているように、トラフィックはその重要度または機密性に適したレベルの保護を取得します。機密情報の正確な構文は、実装によって定義されます。
After an inbound packet has passed through IPsec processing, an MLS implementation SHOULD first check the packet's sensitivity (as defined by the SA (or SA bundle) used for the packet) with the interface or address/prefix as described in section 8.2 before delivering the datagram to an upper-layer protocol or forwarding it.
インバウンドパケットがIPsec処理を通過した後、MLS実装は、セクション8.2で説明されているように、インターフェイスまたはアドレス/プレフィックスでパケットの感度（パケットに使用されるSA（またはSAバンドル）で定義）を最初にチェックしてから、上位層プロトコルへのデータグラムまたはそれの転送。
The MLS system MUST retain the binding between the data received in an IPsec protected packet and the sensitivity information in the SA or SAs used for processing, so appropriate policy decisions can be made when delivering the datagram to an application or forwarding engine. The means for maintaining this binding are implementation specific.
MLSシステムは、IPsecで保護されたパケットで受信されたデータと、処理に使用されるSAの機密情報との間のバインディングを保持する必要があるため、アプリケーションまたは転送エンジンにデータグラムを配信するときに適切なポリシー決定を行うことができます。このバインディングを維持する手段は実装固有です。
An MLS implementation of IPsec MUST perform two additional checks besides the normal steps detailed in section 5.1.1. When consulting the SPD or the SAD to find an outbound security association, the MLS implementation MUST use the sensitivity of the data to select an appropriate outbound SA or SA bundle. The second check comes before forwarding the packet out to its destination, and is the sensitivity consistency checking described in section 8.2.
IPsecのMLS実装は、セクション5.1.1で詳述されている通常の手順に加えて、2つの追加のチェックを実行する必要があります。 SPDまたはSADを調べて発信セキュリティアソシエーションを見つける場合、MLS実装はデータの機密性を使用して適切な発信SAまたはSAバンドルを選択する必要があります。 2番目のチェックは、パケットを宛先に転送する前に行われます。これは、セクション8.2で説明されている機密整合性チェックです。
An MLS security gateway MUST follow the previously mentioned inbound and outbound processing rules as well as perform some additional processing specific to the intermediate protection of packets in an MLS environment.
MLSセキュリティゲートウェイは、前述のインバウンドおよびアウトバウンドの処理ルールに従う必要があり、MLS環境でのパケットの中間保護に固有の追加処理を実行する必要があります。
A security gateway MAY act as an outbound proxy, creating SAs for MLS systems that originate packets forwarded by the gateway. These MLS systems may explicitly label the packets to be forwarded, or the whole originating network may have sensitivity characteristics associated with it. The security gateway MUST create and use appropriate SAs for AH, ESP, or both, to protect such traffic it forwards.
セキュリティゲートウェイは、ゲートウェイによって転送されたパケットを発信するMLSシステムのSAを作成して、アウトバウンドプロキシとして機能する場合があります。これらのMLSシステムは、転送されるパケットに明示的にラベルを付ける場合があります。または、発信元のネットワーク全体に感度特性が関連付けられている場合があります。セキュリティゲートウェイは、転送するトラフィックを保護するために、AH、ESP、またはその両方に適切なSAを作成して使用する必要があります。
Similarly such a gateway SHOULD accept and process inbound AH and/or ESP packets and forward appropriately, using explicit packet labeling, or relying on the sensitivity characteristics of the destination network.
同様に、そのようなゲートウェイは、明示的なパケットラベルを使用するか、宛先ネットワークの機密特性に依存して、インバウンドAHおよび/またはESPパケットを受け入れて処理し、適切に転送する必要があります（SHOULD）。
The use of IPsec imposes computational performance costs on the hosts or security gateways that implement these protocols. These costs are associated with the memory needed for IPsec code and data structures, and the computation of integrity check values, encryption and decryption, and added per-packet handling. The per-packet computational costs will be manifested by increased latency and, possibly, reduced throughout. Use of SA/key management protocols, especially ones that employ public key cryptography, also adds computational performance costs to use of IPsec. These per-association computational costs will be manifested in terms of increased latency in association establishment. For many hosts, it is anticipated that software-based cryptography will not appreciably reduce throughput, but hardware may be required for security gateways (since they represent aggregation points), and for some hosts.
IPsecを使用すると、これらのプロトコルを実装するホストまたはセキュリティゲートウェイに計算パフォーマンスのコストがかかります。これらのコストは、IPsecコードとデータ構造に必要なメモリ、整合性チェック値の計算、暗号化と復号化、および追加のパケットごとの処理に関連しています。パケットごとの計算コストは、レイテンシの増加によって明らかになり、場合によっては全体的に削減されます。 SA /キー管理プロトコル、特に公開キー暗号化を使用するプロトコルを使用すると、IPsecの使用に計算パフォーマンスのコストが追加されます。これらのアソシエーションごとの計算コストは、アソシエーションの確立における遅延の増加という観点から明らかになります。多くのホストでは、ソフトウェアベースの暗号化ではスループットがそれほど低下しないことが予想されますが、セキュリティゲートウェイ（集約ポイントを表すため）および一部のホストにはハードウェアが必要になる場合があります。
The use of IPsec also imposes bandwidth utilization costs on transmission, switching, and routing components of the Internet infrastructure, components not implementing IPsec. This is due to the increase in the packet size resulting from the addition of AH and/or ESP headers, AH and ESP tunneling (which adds a second IP header), and the increased packet traffic associated with key management protocols. It is anticipated that, in most instances, this increased bandwidth demand will not noticeably affect the Internet infrastructure. However, in some instances, the effects may be significant, e.g., transmission of ESP encrypted traffic over a dialup link that otherwise would have compressed the traffic.
IPsecを使用すると、IPsecを実装していないインターネットインフラストラクチャの送信、スイッチング、ルーティングコンポーネントに帯域幅使用コストがかかります。これは、AHおよび/またはESPヘッダー、AHおよびESPトンネリング（2番目のIPヘッダーを追加）の追加によるパケットサイズの増加、およびキー管理プロトコルに関連するパケットトラフィックの増加が原因です。ほとんどの場合、この増加した帯域幅需要がインターネットインフラストラクチャに顕著な影響を与えることはないと予想されます。ただし、場合によっては、影響が大きくなることがあります。たとえば、ESPで暗号化されたトラフィックがダイヤルアップリンクを介して送信された場合は、トラフィックが圧縮されます。
Note: The initial SA establishment overhead will be felt in the first packet. This delay could impact the transport layer and application. For example, it could cause TCP to retransmit the SYN before the ISAKMP exchange is done. The effect of the delay would be different on UDP than TCP because TCP shouldn't transmit anything other than the SYN until the connection is set up whereas UDP will go ahead and transmit data beyond the first packet.
注：最初のSA確立のオーバーヘッドは、最初のパケットで感じられます。この遅延は、トランスポート層とアプリケーションに影響を与える可能性があります。たとえば、ISAKMP交換が行われる前に、TCPがSYNを再送信する可能性があります。 UDPは先に進み、最初のパケットを超えてデータを送信するのに対し、TCPは接続が設定されるまでSYN以外を送信しないため、遅延の影響はTCPとUDPでは異なります。
Note: As discussed earlier, compression can still be employed at layers above IP. There is an IETF working group (IP Payload Compression Protocol (ippcp)) working on "protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by IPsec protocols."
注：前に説明したように、IPより上のレイヤーでも圧縮を使用できます。 IETFワーキンググループ（IPペイロード圧縮プロトコル（ippcp））があり、「ペイロードを暗号化するプロトコルで処理する前に、個々のペイロードでロスレス圧縮を実行できるようにするプロトコル仕様。これらの仕様により、圧縮操作が可能になります。 IPsecプロトコルによるペイロードの暗号化の前に実行されます。」
All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document.
IPsecの実装を主張するすべてのIPv4システムは、セキュリティアーキテクチャドキュメントのすべての要件に準拠する必要があります。すべてのIPv6システムは、セキュリティアーキテクチャドキュメントのすべての要件に準拠する必要があります。
The focus of this document is security; hence security considerations permeate this specification.
このドキュメントの焦点はセキュリティです。したがって、セキュリティに関する考慮事項がこの仕様に浸透しています。
This architecture document differs substantially from RFC 1825 in detail and in organization, but the fundamental notions are unchanged. This document provides considerable additional detail in terms of compliance specifications. It introduces the SPD and SAD, and the notion of SA selectors. It is aligned with the new versions of AH and ESP, which also differ from their predecessors. Specific requirements for supported combinations of AH and ESP are newly added, as are details of PMTU management.
このアーキテクチャドキュメントは、RFC 1825と詳細および構成が大幅に異なりますが、基本的な概念は変更されていません。このドキュメントでは、コンプライアンスの仕様に関して、さらに詳細な情報を提供しています。 SPDとSAD、およびSAセレクターの概念を紹介します。これは、AHおよびESPの新しいバージョンと整合しており、前バージョンとは異なります。 PMTU管理の詳細と同様に、AHとESPのサポートされる組み合わせの特定の要件が新しく追加されました。
Acknowledgements
謝辞
Many of the concepts embodied in this specification were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], and the work done for SNMP Security and SNMPv2 Security.
この仕様で具体化されている概念の多くは、米国政府のSP3セキュリティプロトコル、ISO / IECのNLSP、提案されたswIPeセキュリティプロトコル[SDNS、ISO、IB93、IBK93]、およびSNMPセキュリティとSNMPv2のために行われた作業に由来するか、またはそれらの影響を受けています。セキュリティ。
For over 3 years (although it sometimes seems *much* longer), this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, Harry Varnis, and Nina Yuan.
3年以上（時々*はるかに*長く見えるように見えますが）、このドキュメントは複数のバージョンと反復によって進化してきました。この間、多くの人々が重要なアイデアとエネルギーをプロセスとドキュメント自体に提供してきました。著者は、このバージョンの仕様のレビュー、編集、バックグラウンド調査、および調整に広範な支援を提供してくれたKaren Seoに感謝します。著者はまた、IPsecおよびIPngワーキンググループのメンバーに感謝の意を表します（特にアルファベット順）：Steve Bellovin、Steve Deering、James Hughes、Phil Karn、Frank Kastenholz、Perry Metzger、David Mihelcic 、Hilarie Orman、Norman Shulman、William Simpson、Harry Varnis、Nina Yuan。
Appendix A -- Glossary
付録A-用語集
This section provides definitions for several key terms that are employed in this document. Other documents provide additional definitions and background information relevant to this technology, e.g., [VK83, HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
このセクションでは、このドキュメントで使用されているいくつかの主要な用語の定義について説明します。他のドキュメントには、このテクノロジーに関連する追加の定義と背景情報が記載されています（例：[VK83、HA94]）。この用語集には、一般的なセキュリティサービスとセキュリティメカニズムの用語、およびIPsec固有の用語が含まれています。
Access Control Access control is a security service that prevents unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner. In the IPsec context, the resource to which access is being controlled is often: o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network.
アクセス制御アクセス制御は、リソースの不正使用の防止を含む、リソースの不正使用を防止するセキュリティサービスです。 IPsecのコンテキストでは、アクセスが制御されるリソースは、多くの場合、次のとおりです。oホスト、計算サイクル、またはデータoセキュリティゲートウェイ、ゲートウェイの背後にあるネットワーク、またはそのネットワークの帯域幅。
Anti-replay [See "Integrity" below]
アンチリプレイ[下の「完全性」を参照]
Authentication This term is used informally to refer to the combination of two nominally distinct security services, data origin authentication and connectionless integrity. See the definitions below for each of these services.
認証この用語は、2つの名目上異なるセキュリティサービス、データ発信元認証とコネクションレス型の整合性の組み合わせを指すために非公式に使用されます。これらの各サービスについては、以下の定義を参照してください。
Availability Availability, when viewed as a security service, addresses the security concerns engendered by attacks against networks that deny or degrade service. For example, in the IPsec context, the use of anti-replay mechanisms in AH and ESP support availability.
可用性可用性は、セキュリティサービスと見なされると、サービスを拒否または低下させるネットワークに対する攻撃によって引き起こされるセキュリティの懸念に対処します。たとえば、IPsecのコンテキストでは、AHおよびESPでのリプレイ防止メカニズムの使用により可用性がサポートされます。
Confidentiality Confidentiality is the security service that protects data from unauthorized disclosure. The primary confidentiality concern in most instances is unauthorized disclosure of application level data, but disclosure of the external characteristics of communication also can be a concern in some circumstances. Traffic flow confidentiality is the service that addresses this latter concern by concealing source and destination addresses, message length, or frequency of communication. In the IPsec context, using ESP in tunnel mode, especially at a security gateway, can provide some level of traffic flow confidentiality. (See also traffic analysis, below.)
機密性機密性は、不正な開示からデータを保護するセキュリティサービスです。ほとんどの場合の主要な機密性の懸念は、アプリケーションレベルのデータの不正な開示ですが、状況によっては、通信の外部特性の開示も問題になることがあります。トラフィックフローの機密性は、送信元と宛先のアドレス、メッセージの長さ、または通信の頻度を隠すことにより、後者の問題に対処するサービスです。 IPsecのコンテキストでは、特にセキュリティゲートウェイでトンネルモードでESPを使用すると、ある程度のトラフィックフローの機密性を提供できます。 （以下のトラフィック分析も参照してください。）
Encryption Encryption is a security mechanism used to transform data from an intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is designated "decryption". Oftimes the term "encryption" is used to generically refer to both processes.
暗号化暗号化は、データを理解可能な形式（プレーンテキスト）から理解できない形式（暗号テキスト）に変換して機密性を提供するために使用されるセキュリティメカニズムです。逆変換プロセスは「復号化」と呼ばれます。多くの場合、「暗号化」という用語は、一般的に両方のプロセスを指すために使用されます。
Data Origin Authentication Data origin authentication is a security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service.
データ発信元認証データ発信元認証は、要求されたデータソースのIDを検証するセキュリティサービスです。このサービスは通常、コネクションレスの整合性サービスにバンドルされています。
Integrity Integrity is a security service that ensures that modifications to data are detectable. Integrity comes in various flavors to match application requirements. IPsec supports two forms of integrity: connectionless and a form of partial sequence integrity. Connectionless integrity is a service that detects modification of an individual IP datagram, without regard to the ordering of the datagram in a stream of traffic. The form of partial sequence integrity offered in IPsec is referred to as anti-replay integrity, and it detects arrival of duplicate IP datagrams (within a constrained window). This is in contrast to connection-oriented integrity, which imposes more stringent sequencing requirements on traffic, e.g., to be able to detect lost or re-ordered messages. Although authentication and integrity services often are cited separately, in practice they are intimately connected and almost always offered in tandem.
Integrity Integrityは、データへの変更を確実に検出できるようにするセキュリティサービスです。整合性には、アプリケーションの要件に合わせてさまざまな種類があります。 IPsecは、コネクションレス型と部分的なシーケンスの完全性という2つの形式の整合性をサポートしています。コネクションレス整合性は、トラフィックストリーム内のデータグラムの順序に関係なく、個々のIPデータグラムの変更を検出するサービスです。 IPsecで提供される部分シーケンス整合性の形式は、アンチリプレイ整合性と呼ばれ、重複したIPデータグラムの到着を（制約されたウィンドウ内で）検出します。これは、接続指向の整合性とは対照的です。これは、たとえば、失われたメッセージまたは並べ替えられたメッセージを検出できるようにするために、より厳しいシーケンス要件をトラフィックに課します。認証サービスと整合性サービスは別々に引用されることがよくありますが、実際には密接に接続されており、ほとんどの場合タンデムで提供されます。
Security Association (SA) A simplex (uni-directional) logical connection, created for security purposes. All traffic traversing an SA is provided the same security processing. In IPsec, an SA is an internet layer abstraction implemented through the use of AH or ESP.
セキュリティアソシエーション（SA）セキュリティの目的で作成されたシンプレックス（単方向）論理接続。 SAを通過するすべてのトラフィックには、同じセキュリティ処理が提供されます。 IPsecでは、SAはAHまたはESPを使用して実装されるインターネット層の抽象化です。
Security Gateway A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. (See "Trusted Subnetwork" below.) In the IPsec context, a security gateway is a point at which AH and/or ESP is implemented in order to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPsec (either directly or via another security gateway).
セキュリティゲートウェイセキュリティゲートウェイは、2つのネットワーク間の通信インターフェイスとして機能する中間システムです。セキュリティゲートウェイの外部側のホスト（およびネットワーク）のセットは信頼できない（または信頼性が低い）と見なされ、ネットワークおよびホストと内部側は信頼できる（またはより信頼できる）と見なされます。セキュリティゲートウェイによって提供される内部サブネットとホストは、共通のローカルなセキュリティ管理を共有することによって信頼されていると想定されます。 （以下の「信頼されたサブネットワーク」を参照してください。）IPsecのコンテキストでは、セキュリティゲートウェイは、AHやESPが内部ホストのセットにサービスを提供するために実装されるポイントであり、外部ホストと通信するときにこれらのホストにセキュリティサービスを提供しますホストはIPsecを採用しています（直接または別のセキュリティゲートウェイを介して）。
SPI Acronym for "Security Parameters Index". The combination of a destination address, a security protocol, and an SPI uniquely identifies a security association (SA, see above). The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing.
「セキュリティパラメータインデックス」のSPIの頭字語。宛先アドレス、セキュリティプロトコル、およびSPIの組み合わせにより、セキュリティアソシエーション（SA、上記を参照）が一意に識別されます。 SPIはAHおよびESPプロトコルで伝送され、受信システムが受信パケットを処理するSAを選択できるようにします。 SAの作成者（通常はSPIを運ぶパケットの受信者）によって定義されているように、SPIはローカルでのみ意味があります。したがって、SPIは一般に不透明なビット文字列と見なされます。ただし、SAの作成者は、ローカル処理を容易にするためにSPIのビットを解釈することを選択できます。
Traffic Analysis The analysis of network traffic flow for the purpose of deducing information that is useful to an adversary. Examples of such information are frequency of transmission, the identities of the conversing parties, sizes of packets, flow identifiers, etc. [Section 8.6">Sch94]
トラフィック分析攻撃者に役立つ情報を推測するためのネットワークトラフィックフローの分析。そのような情報の例は、送信の頻度、会話する当事者のアイデンティティ、パケットのサイズ、フロー識別子などです。[セクション8.6 "> Sch94]
Trusted Subnetwork A subnetwork containing hosts and routers that trust each other not to engage in active or passive attacks. There also is an assumption that the underlying communications channel (e.g., a LAN or CAN) isn't being attacked by other means.
信頼できるサブネットワーク相互に信頼してアクティブまたはパッシブ攻撃を行わないホストとルーターを含むサブネットワーク。また、基盤となる通信チャネル（LANやCANなど）が他の手段によって攻撃されていないという想定もあります。
Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
B.1 DF bit
B.1 DFビット
In cases where a system (host or gateway) adds an encapsulating header (e.g., ESP tunnel), should/must the DF bit in the original packet be copied to the encapsulating header?
システム（ホストまたはゲートウェイ）がカプセル化ヘッダー（ESPトンネルなど）を追加する場合、元のパケットのDFビットをカプセル化ヘッダーにコピーする必要がありますか？
Fragmenting seems correct for some situations, e.g., it might be appropriate to fragment packets over a network with a very small MTU, e.g., a packet radio network, or a cellular phone hop to mobile node, rather than propagate back a very small PMTU for use over the rest of the path. In other situations, it might be appropriate to set the DF bit in order to get feedback from later routers about PMTU constraints which require fragmentation. The existence of both of these situations argues for enabling a system to decide whether or not to fragment over a particular network "link", i.e., for requiring an implementation to be able to copy the DF bit (and to process ICMP PMTU messages), but making it an option to be selected on a per interface basis. In other words, an administrator should be able to configure the router's treatment of the DF bit (set, clear, copy from encapsulated header) for each interface.
断片化は状況によっては正しいようです。たとえば、非常に小さなPMTUを伝搬するのではなく、非常に小さなMTUのネットワーク、たとえばパケット無線ネットワーク、またはモバイルノードへの携帯電話ホップを介してパケットを断片化することが適切な場合があります。パスの残りの部分で使用します。他の状況では、フラグメンテーションを必要とするPMTU制約について後のルーターからフィードバックを取得するために、DFビットを設定することが適切な場合があります。これらの両方の状況の存在は、システムが特定のネットワーク「リンク」を介してフラグメント化するかどうかを決定できるようにすること、つまり、実装がDFビットをコピーできる（およびICMP PMTUメッセージを処理できる）ことを要求することを主張します。ただし、インターフェースごとに選択するオプションにする。言い換えると、管理者は、インターフェイスごとにルーターによるDFビットの扱い（設定、クリア、カプセル化されたヘッダーからのコピー）を構成できる必要があります。
Note: If a bump-in-the-stack implementation of IPsec attempts to apply different IPsec algorithms based on source/destination ports, it will be difficult to apply Path MTU adjustments.
注：IPsecのバンプインザスタック実装が送信元/宛先ポートに基づいて異なるIPsecアルゴリズムを適用しようとすると、パスMTU調整を適用することが困難になります。
B.2 Fragmentation
B.2断片化
If required, IP fragmentation occurs after IPsec processing within an IPsec implementation. Thus, transport mode AH or ESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which AH or ESP has been applied may itself be fragmented by routers en route, and such fragments MUST be reassembled prior to IPsec processing at a receiver. In tunnel mode, AH or ESP is applied to an IP packet, the payload of which may be a fragmented IP packet. For example, a security gateway, "bump-in-the-stack" (BITS), or "bump-in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to such fragments. Note that BITS or BITW implementations are examples of where a host IPsec implementation might receive fragments to which tunnel mode is to be applied. However, if transport mode is to be applied, then these implementations MUST reassemble the fragments prior to applying IPsec.
必要に応じて、IPsec実装内のIPsec処理後にIPフラグメンテーションが発生します。したがって、トランスポートモードAHまたはESPは、IPデータグラム全体にのみ適用されます（IPフラグメントには適用されません）。 AHまたはESPが適用されたIPパケットは、途中でルーターによってフラグメント化される可能性があり、そのようなフラグメントは、受信側でのIPsec処理の前に再構成する必要があります。トンネルモードでは、AHまたはESPがIPパケットに適用され、そのペイロードはフラグメント化されたIPパケットである場合があります。たとえば、セキュリティゲートウェイ、「bump-in-the-stack」（BITS）、または「bump-in-the-wire」（BITW）IPsec実装では、このようなフラグメントにトンネルモードAHを適用できます。 BITSまたはBITWの実装は、トンネルモードが適用されるフラグメントをホストIPsec実装が受信する可能性のある例であることに注意してください。ただし、トランスポートモードが適用される場合、これらの実装はIPsecを適用する前にフラグメントを再構成する必要があります。
NOTE: IPsec always has to figure out what the encapsulating IP header fields are. This is independent of where you insert IPsec and is intrinsic to the definition of IPsec. Therefore any IPsec implementation that is not integrated into an IP implementation must include code to construct the necessary IP headers (e.g., IP2):
注：IPsecは、常にカプセル化IPヘッダーフィールドが何であるかを理解する必要があります。これは、IPsecを挿入する場所とは関係なく、IPsecの定義に固有です。したがって、IP実装に統合されていないIPsec実装には、必要なIPヘッダー（IP2など）を構築するためのコードを含める必要があります。
o AH-tunnel --> IP2-AH-IP1-Transport-Data o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer
o AHトンネル-> IP2-AH-IP1-Transport-DataからESPトンネル-> IP2-ESP hdr-IP1-Transport-Data-ESPトレーラー
*********************************************************************
Overall, the fragmentation/reassembly approach described above works for all cases examined.
全体として、上記の断片化/再構成アプローチは、調査したすべてのケースで機能します。
AH Xport AH Tunnel ESP Xport ESP Tunnel
Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
----------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y
Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y
S. Gwy (integr w/ IP stack) Y Y Y Y
Outboard crypto processor *
* If the crypto processor system has its own IP address, then it is covered by the security gateway case. This box receives the packet from the host and performs IPsec processing. It has to be able to handle the same AH, ESP, and related IPv4/IPv6 tunnel processing that a security gateway would have to handle. If it doesn't have it's own address, then it is similar to the bump-in-the stack implementation between IP and the network drivers.
* 暗号化プロセッサシステムに独自のIPアドレスがある場合、セキュリティゲートウェイのケースでカバーされます。このボックスは、ホストからパケットを受信し、IPsec処理を実行します。セキュリティゲートウェイが処理する必要があるのと同じAH、ESP、および関連するIPv4 / IPv6トンネル処理を処理できる必要があります。独自のアドレスがない場合は、IPとネットワークドライバー間のバンプインザスタック実装に似ています。
The following analysis assumes that:
次の分析は、次のことを前提としています。
1. There is only one IPsec module in a given system's stack. There isn't an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol, SRC port, and DEST port from IPsec module B. 2. There are several places where IPsec could be implemented (as shown in the table above). a. Hosts with integration of IPsec into the native IP implementation. Implementer has access to the source for the stack. b. Hosts with bump-in-the-stack implementations, where IPsec is implemented between IP and the local network drivers. Source access for stack is not available; but there are well-defined interfaces that allows the IPsec code to be incorporated into the system.
1. 特定のシステムのスタックにはIPsecモジュールが1つだけあります。トランスポートプロトコル、SRCポート、およびDESTポートをIPsecモジュールBから隠すIPsecモジュールA（ESP /暗号化を追加する）はありません。2。IPsecを実装できる場所がいくつかあります（上記の表を参照） ）。 a。 IPsecをネイティブIP実装に統合したホスト。実装者はスタックのソースにアクセスできます。 b。バンプインザスタック実装のホスト。IPSecはIPとローカルネットワークドライバーの間に実装されます。スタックのソースアクセスは利用できません。しかし、IPsecコードをシステムに組み込むことを可能にする明確に定義されたインターフェースがあります。
c. Security gateways and outboard crypto processors with integration of IPsec into the stack. 3. Not all of the above approaches are feasible in all hosts. But it was assumed that for each approach, there are some hosts for whom the approach is feasible.
c。 IPsecをスタックに統合したセキュリティゲートウェイと外部暗号化プロセッサ。 3.上記のアプローチのすべてがすべてのホストで実行可能であるとは限りません。しかし、それぞれのアプローチについて、そのアプローチが実行可能ないくつかのホストがいると想定されていました。
For each of the above 3 categories, there are IPv4 and IPv6, AH transport and tunnel modes, and ESP transport and tunnel modes -- for a total of 24 cases (3 x 2 x 4).
上記の3つのカテゴリにはそれぞれ、IPv4とIPv6、AHトランスポートモードとトンネルモード、ESPトランスポートモードとトンネルモードがあり、合計24ケース（3 x 2 x 4）です。
Some header fields and interface fields are listed here for ease of reference -- they're not in the header order, but instead listed to allow comparison between the columns. (* = not covered by AH authentication. ESP authentication doesn't cover any headers that precede it.)
参照しやすいように、いくつかのヘッダーフィールドとインターフェースフィールドをここに示します。これらはヘッダーの順序ではなく、列間の比較を可能にするためにリストされています。 （* = AH認証ではカバーされません。ESP認証では、その前のヘッダーはカバーされません。）
IP/Transport Interface
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt
? = AH covers Option-Type and Option-Length, but might not cover Option-Data.
？ = AHはOption-TypeとOption-Lengthをカバーしますが、Option-Dataをカバーしない場合があります。
The results for each of the 20 cases is shown below ("works" = will work if system fragments after outbound IPsec processing, reassembles before inbound IPsec processing). Notes indicate implementation issues.
20のケースそれぞれの結果を以下に示します（「機能する」=アウトバウンドIPsec処理後にシステムフラグメントが発生し、インバウンドIPsec処理の前に再構築される場合は機能します）。注記は実装の問題を示します。
a. Hosts (integrated into IP stack)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o ESPトランスポート->（IP1-ESP_hdr-Transport-Data-ESP_trailer）-IPv4-機能-IPv6-機能o ESPトンネル->（IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer）-IPv4- -動作-IPv6-動作
b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network drivers. In this case, the IPsec module would have to do something like one of the following for fragmentation and reassembly. - do the fragmentation/reassembly work itself and send/receive the packet directly to/from the network layer. In AH or ESP transport mode, this is fine. In AH or ESP tunnel mode where the tunnel end is at the ultimate destination, this is fine. But in AH or ESP tunnel modes where the tunnel end is different from the ultimate destination and where the source host is multi-homed, this approach could result in sub-optimal routing because the IPsec module may be unable to obtain the information needed (LAN interface and next-hop gateway) to direct the packet to the appropriate network interface. This is not a problem if the interface and next-hop gateway are the same for the ultimate destination and for the tunnel end. But if they are different, then IPsec would need to know the LAN interface and the next-hop gateway for the tunnel end. (Note: The tunnel end (security gateway) is highly likely to be on the regular path to the ultimate destination. But there could also be more than one path to the destination, e.g., the host could be at an organization with 2 firewalls. And the path being used could involve the less commonly chosen firewall.) OR - pass the IPsec'd packet back to the IP layer where an extra IP header would end up being pre-pended and the IPsec module would have to check and let IPsec'd fragments go by. OR - pass the packet contents to the IP layer in a form such that the IP layer recreates an appropriate IP header
b。ホスト（Bump-in-the-stack）-IPsecをIPレイヤーとネットワークドライバーの間に配置します。この場合、IPsecモジュールは、断片化と再構成のために次のいずれかを実行する必要があります。 -フラグメント化/再構成自体を行い、ネットワーク層との間で直接パケットを送受信します。 AHまたはESPトランスポートモードでは、これで問題ありません。トンネルの終端が最終的な宛先であるAHまたはESPトンネルモードでは、これで問題ありません。ただし、トンネルの終端が最終的な宛先とは異なり、ソースホストがマルチホームであるAHまたはESPトンネルモードでは、IPsecモジュールが必要な情報（LANインターフェースおよびネクストホップゲートウェイ）を使用して、パケットを適切なネットワークインターフェースに送信します。これは、インターフェイスとネクストホップゲートウェイが最終的な宛先とトンネルエンドで同じである場合は問題になりません。しかし、それらが異なる場合、IPsecは、LANインターフェースとトンネルエンドのネクストホップゲートウェイを認識する必要があります。 （注：トンネルの端（セキュリティゲートウェイ）は、最終的な宛先への通常のパス上にある可能性が高いです。ただし、宛先へのパスが複数ある場合もあります。たとえば、ホストが2つのファイアウォールを持つ組織にある場合があります。そして、使用されているパスには、あまり一般的に選択されていないファイアウォールが含まれる場合があります。）または-IPsecパケットをIPレイヤーに渡します。IPレイヤーでは、追加のIPヘッダーがプリペンドされ、IPsecモジュールがIPsecをチェックして許可する必要があります。 'dフラグメントが通り過ぎます。または-パケットの内容を、IP層が適切なIPヘッダーを再作成するような形式でIP層に渡します。
At the network layer, the IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. One cannot assume IPsec has access to the Name. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s).
ネットワーク層では、IPsecモジュールはパケットから次のセレクターにアクセスできます-SRCアドレス、DSTアドレス、次のプロトコル、およびトランスポート層ヘッダーがある場合-> SRCポートとDSTポート。 IPsecが名前にアクセスできるとは限りません。利用可能なセレクタ情報は、関連するセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると想定されています。
o AH-transport --> (IP1-AH-Transport-Data) - IPv4 -- works - IPv6 -- works o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o AH-transport->（IP1-AH-Transport-Data）-IPv4-機能-IPv6-機能o AH-tunnel->（IP2-AH-IP1-Transport-Data）-IPv4-機能-IPv6 -機能o ESP-transport->（IP1-ESP_hdr-Transport-Data-ESP_trailer）-IPv4-機能-IPv6-機能o ESP-tunnel->（IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer ）-IPv4-機能-IPv6-機能
c. Security gateways -- integrate IPsec into the IP stack
c。セキュリティゲートウェイ-IPsecをIPスタックに統合
NOTE: The IPsec module will have access to the following selectors from the packet -- SRC address, DST address, Next Protocol, and if there's a transport layer header --> SRC port and DST port. It won't have access to the User ID (only Hosts have access to User ID information.) Unlike some Bump-in-the-stack implementations, security gateways may be able to look up the Source Address in the DNS to provide a System Name, e.g., in situations involving use of dynamically assigned IP addresses in conjunction with dynamically updated DNS entries. It also won't have access to the transport layer information if there is an ESP header, or if it's not the first fragment of a fragmented message. It is assumed that the available selector information is sufficient to figure out the relevant Security Policy entry and Security Association(s).
注：IPsecモジュールは、パケットから次のセレクターにアクセスできます-SRCアドレス、DSTアドレス、次のプロトコル、およびトランスポート層ヘッダーがある場合-> SRCポートおよびDSTポート。ユーザーIDにアクセスすることはできません（ユーザーID情報にアクセスできるのはホストのみです。）一部のBump-in-the-stack実装とは異なり、セキュリティゲートウェイはDNSでソースアドレスを検索してシステムを提供できる場合がありますたとえば、動的に更新されたDNSエントリと組み合わせて動的に割り当てられたIPアドレスを使用する状況での名前。また、ESPヘッダーがある場合、またはそれが断片化されたメッセージの最初のフラグメントでない場合は、トランスポート層情報にアクセスできません。利用可能なセレクタ情報は、関連するセキュリティポリシーエントリとセキュリティアソシエーションを理解するのに十分であると想定されています。
o AH-tunnel --> (IP2-AH-IP1-Transport-Data) - IPv4 -- works - IPv6 -- works o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) - IPv4 -- works - IPv6 -- works
o AHトンネル->（IP2-AH-IP1-Transport-Data）-IPv4-機能-IPv6-機能o ESPトンネル->（IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer）-IPv4- -動作-IPv6-動作
**********************************************************************
B.3 Path MTU Discovery
B.3パスMTU検出
As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for Path MTU Discovery.
前述のように、「ICMP PMTU」は、パスMTUディスカバリに使用されるICMPメッセージを指します。
The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) is:
以下のB.3.1およびB.3.3（B.3.2ではない）の図の凡例は、次のとおりです。
==== = security association (AH or ESP, transport or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
.... = ICMP message (hereafter referred to as ICMP PMTU) for
IPv4: - Type = 3 (Destination Unreachable) - Code = 4 (Fragmentation needed and DF set) - Next-Hop MTU in the low-order 16 bits of the second word of the ICMP header (labelled unused in RFC 792), with high-order 16 bits set to zero
IPv4：-タイプ= 3（Destination Unreachable）-コード= 4（フラグメンテーションが必要、DFセット）-ICMPヘッダーの2番目のワードの下位16ビットの次ホップMTU（RFC 792で未使用とラベル付け）、ゼロに設定された上位16ビット
IPv6 (RFC 1885): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed and DF set) - Next-Hop MTU in the 32 bit MTU field of the ICMP6
IPv6（RFC 1885）：-タイプ= 2（パケットが大きすぎます）-コード= 0（フラグメンテーションが必要で、DFが設定されています）-ICMP6の32ビットMTUフィールドのネクストホップMTU
Hx = host x Rx = router x SGx = security gateway x X* = X supports IPsec
Hx =ホストx Rx =ルーターx SGx =セキュリティゲートウェイx X * = XはIPsecをサポート
B.3.1 Identifying the Originating Host(s)
B.3.1発信元ホストの特定
The amount of information returned with the ICMP message is limited and this affects what selectors are available to identify security associations, originating hosts, etc. for use in further propagating the PMTU information.
ICMPメッセージで返される情報の量は制限されており、これは、PMTU情報をさらに伝達するために使用するセキュリティアソシエーション、発信元ホストなどを識別するために使用できるセレクターに影響します。
In brief... An ICMP message must contain the following information from the "offending" packet: - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits
簡単に言うと... ICMPメッセージには、「問題の」パケットからの次の情報が含まれている必要があります。-IPv4（RFC 792）-IPヘッダーと最小64ビット
Accordingly, in the IPv4 context, an ICMP PMTU may identify only the first (outermost) security association. This is because the ICMP PMTU may contain only 64 bits of the "offending" packet beyond the IP header, which would capture only the first SPI from AH or ESP. In the IPv6 context, an ICMP PMTU will probably provide all the SPIs and the selectors in the IP header, but maybe not the SRC/DST ports (in the transport header) or the encapsulated (TCP, UDP, etc.) protocol. Moreover, if ESP is used, the transport ports and protocol selectors may be encrypted.
したがって、IPv4のコンテキストでは、ICMP PMTUは最初の（最も外側の）セキュリティアソシエーションのみを識別できます。これは、ICMP PMTUに含まれる可能性のある64ビットの「問題の」パケットがIPヘッダーを超えているため、AHまたはESPから最初のSPIのみがキャプチャされるためです。 IPv6のコンテキストでは、ICMP PMTUはおそらくIPヘッダー内のすべてのSPIとセレクターを提供しますが、SRC / DSTポート（トランスポートヘッダー内）またはカプセル化（TCP、UDPなど）プロトコルを提供しない可能性があります。さらに、ESPを使用する場合は、トランスポートポートとプロトコルセレクターを暗号化できます。
Looking at the diagram below of a security gateway tunnel (as mentioned elsewhere, security gateways do not use transport mode)...
セキュリティゲートウェイトンネルの下の図を見る（他の場所で述べたように、セキュリティゲートウェイはトランスポートモードを使用しません）...
H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4
Suppose that the security policy for SG1 is to use a single SA to SG2 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, and H5. And suppose H0 sends a data packet to H5 which causes R1 to send an ICMP PMTU message to SG1. If the PMTU message has only the SPI, SG1 will be able to look up the SA and find the list of possible hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out that H0 sent the traffic that triggered the ICMP PMTU message.
SG1のセキュリティポリシーが、ホストH0、H1、およびH2とホストH3、H4、およびH5間のすべてのトラフィックに対してSG2への単一のSAを使用することであるとします。また、H0がデータパケットをH5に送信するとします。これにより、R1はICMP PMTUメッセージをSG1に送信します。 PMTUメッセージにSPIのみがある場合、SG1はSAを検索し、可能なホスト（H0、H1、H2、ワイルドカード）のリストを見つけることができます。しかし、SG1は、H0がICMP PMTUメッセージをトリガーしたトラフィックを送信したことを理解する方法がありません。
original after IPsec ICMP
packet processing packet
-------- ----------- ------
IP-3 header (S = R1, D = SG1)
ICMP header (includes PMTU)
IP-2 header IP-2 header (S = SG1, D = SG2)
ESP header minimum of 64 bits of ESP hdr (*)
IP-1 header IP-1 header
TCP header TCP header
TCP data TCP data
ESP trailer
(*) The 64 bits will include enough of the ESP (or AH) header to include the SPI. - ESP -- SPI (32 bits), Seq number (32 bits) - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16 bits), SPI (32 bits)
（*）64ビットには、SPIを含めるのに十分なESP（またはAH）ヘッダーが含まれます。 -ESP-SPI（32ビット）、シーケンス番号（32ビット）-AH-次のヘッダー（8ビット）、ペイロードLen（8ビット）、予約済み（16ビット）、SPI（32ビット）
This limitation on the amount of information returned with an ICMP message creates a problem in identifying the originating hosts for the packet (so as to know where to further propagate the ICMP PMTU information). If the ICMP message contains only 64 bits of the IPsec header (minimum for IPv4), then the IPsec selectors (e.g., Source and Destination addresses, Next Protocol, Source and Destination ports, etc.) will have been lost. But the ICMP error message will still provide SG1 with the SPI, the PMTU information and the source and destination gateways for the relevant security association.
ICMPメッセージで返される情報の量に関するこの制限により、パケットの発信元ホストを特定する際に問題が発生します（ICMP PMTU情報をさらに伝達する場所を知るため）。 ICMPメッセージに含まれているのが64ビットのIPsecヘッダーのみ（IPv4の最小値）の場合、IPsecセレクター（送信元アドレスと宛先アドレス、次のプロトコル、送信元ポートと宛先ポートなど）は失われます。ただし、ICMPエラーメッセージは、関連するセキュリティアソシエーションのSPI、PMTU情報、およびソースゲートウェイと宛先ゲートウェイをSG1に提供します。
The destination security gateway and SPI uniquely define a security association which in turn defines a set of possible originating hosts. At this point, SG1 could: a. send the PMTU information to all the possible originating hosts. This would not work well if the host list is a wild card or if many/most of the hosts weren't sending to SG1; but it might work if the SPI/destination/etc mapped to just one or a small number of hosts. b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive from the originating host(s) for the relevant security association. If it/they are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of (a).
宛先セキュリティゲートウェイとSPIは、セキュリティアソシエーションを一意に定義します。セキュリティアソシエーションは、可能な一連の発信元ホストを定義します。この時点で、SG1は次のことができます。可能なすべての発信元ホストにPMTU情報を送信します。これは、ホストリストがワイルドカードである場合、またはホストの多く/ほとんどがSG1に送信していない場合はうまく機能しません。ただし、SPI /宛先/その他が1つまたは少数のホストにのみマッピングされている場合は機能する可能性があります。 b。 PMTUをSPIなどと一緒に保存し、関連するセキュリティアソシエーションの元のホストから次のパケットが到着するまで待ちます。パケットがPMTUよりも大きい場合は、パケットをドロップし、新しいパケットと更新されたPMTUでICMP PMTUメッセージを作成し、発信元のホストにICMPメッセージを送信します。 ）問題について。これには、元のホストへの通知の遅延が含まれますが、（a）の問題は回避されます。
Since only the latter approach is feasible in all instances, a security gateway MUST provide such support, as an option. However, if the ICMP message contains more information from the original packet, then there may be enough information to immediately determine to which host to propagate the ICMP/PMTU message and to provide that system with the 5 fields (source address, destination address, source port, destination port, and transport protocol) needed to determine where to store/update the PMTU. Under such circumstances, a security gateway MUST generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from further down the path. NOTE: The Next Protocol field may not be contained in the ICMP message and the use of ESP encryption may hide the selector fields that have been encrypted.
後者のアプローチのみがすべての場合に実行可能であるため、セキュリティゲートウェイはオプションとしてそのようなサポートを提供する必要があります。ただし、ICMPメッセージに元のパケットからのより多くの情報が含まれている場合は、ICMP / PMTUメッセージを伝播するホストを即座に決定し、そのシステムに5つのフィールド（送信元アドレス、宛先アドレス、送信元）を提供するのに十分な情報がある場合があります。 PMTUを保存/更新する場所を決定するために必要なポート、宛先ポート、およびトランスポートプロトコル）。このような状況では、セキュリティゲートウェイは、パスのさらに下からICMP PMTUを受信するとすぐにICMP PMTUメッセージを生成する必要があります。注：次のプロトコルフィールドがICMPメッセージに含まれていない可能性があり、ESP暗号化を使用すると、暗号化されたセレクタフィールドが非表示になる場合があります。
B.3.2 Calculation of PMTU
B.3.2 PMTUの計算
The calculation of PMTU from an ICMP PMTU has to take into account the addition of any IPsec header by H1 -- AH and/or ESP transport, or ESP or AH tunnel. Within a single host, multiple applications may share an SPI and nesting of security associations may occur. (See Section 4.5 Basic Combinations of Security Associations for description of the combinations that MUST be supported). The diagram below illustrates an example of security associations between a pair of hosts (as viewed from the perspective of one of the hosts.) (ESPx or AHx = transport mode)
ICMP PMTUからのPMTUの計算では、H1-AHおよび/またはESPトランスポート、またはESPまたはAHトンネルによるIPsecヘッダーの追加を考慮する必要があります。単一のホスト内で、複数のアプリケーションがSPIを共有し、セキュリティアソシエーションのネストが発生する場合があります。 （サポートしなければならない組み合わせの説明については、セクション4.5セキュリティアソシエーションの基本的な組み合わせを参照してください）。次の図は、ホストのペア間のセキュリティアソシエーションの例を示しています（ホストの1つから見た場合）（ESPxまたはAHx =トランスポートモード）。
Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet
In order to figure out the PMTU for each socket that maps to SPI-B, it will be necessary to have backpointers from SPI-B to each of the 2 paths that lead to it -- Socket 1 and Socket 2/SPI-A.
SPI-Bにマップする各ソケットのPMTUを把握するには、SPI-Bから、それにつながる2つのパス（ソケット1とソケット2 / SPI-A）のそれぞれへのバックポインターが必要です。
B.3.3 Granularity of Maintaining PMTU Data
B.3.3 PMTUデータの保守の細分性
In hosts, the granularity with which PMTU ICMP processing can be done differs depending on the implementation situation. Looking at a host, there are three situations that are of interest with respect to PMTU issues:
ホストでは、PMTU ICMP処理を実行できる粒度は、実装状況によって異なります。ホストを見ると、PMTUの問題に関して興味深い3つの状況があります。
a. Integration of IPsec into the native IP implementation b. Bump-in-the-stack implementations, where IPsec is implemented "underneath" an existing implementation of a TCP/IP protocol stack, between the native IP and the local network drivers c. No IPsec implementation -- This case is included because it is relevant in cases where a security gateway is sending PMTU information back to a host.
a。 IPsecのネイティブIP実装への統合b。バンプインザスタック実装。IPsecは、TCP / IPプロトコルスタックの既存の実装の下に、ネイティブIPとローカルネットワークドライバーの間に実装されます。 IPsec実装なし-この例は、セキュリティゲートウェイがPMTU情報をホストに送り返す場合に関連するため含まれています。
Only in case (a) can the PMTU data be maintained at the same granularity as communication associations. In the other cases, the IP layer will maintain PMTU data at the granularity of Source and Destination IP addresses (and optionally TOS/Class), as described in RFC 1191. This is an important difference, because more than one communication association may map to the same source and destination IP addresses, and each communication association may have a different amount of IPsec header overhead (e.g., due to use of different transforms or different algorithms). The examples below illustrate this.
（a）の場合のみ、PMTUデータを通信アソシエーションと同じ粒度で維持できます。その他の場合、RFC 1191に記載されているように、IP層は送信元および宛先IPアドレス（およびオプションでTOS /クラス）の粒度でPMTUデータを維持します。これは、複数の通信アソシエーションが同じ送信元IPアドレスと宛先IPアドレス、および各通信アソシエーションは、異なる量のIPsecヘッダーオーバーヘッドを持っている可能性があります（たとえば、異なるトランスフォームまたは異なるアルゴリズムの使用により）。以下の例はこれを示しています。
In cases (a) and (b)... Suppose you have the following situation. H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds the PMTU of the network hop between them.
（a）と（b）の場合...次のような状況があるとします。 H1はH2に送信しており、R1からR2に送信されるパケットは、それらの間のネットワークホップのPMTUを超えています。
==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
^ |
|.......|
If R1 is configured to not fragment subscriber traffic, then R1 sends an ICMP PMTU message with the appropriate PMTU to H1. H1's processing would vary with the nature of the implementation. In case (a) (native IP), the security services are bound to sockets or the equivalent. Here the IP/IPsec implementation in H1 can store/update the PMTU for the associated socket. In case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses and possibly TOS/Class, as noted above. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
R1が加入者トラフィックを断片化しないように設定されている場合、R1は適切なPMTUを含むICMP PMTUメッセージをH1に送信します。 H1の処理は、実装の性質によって異なります。 （a）（ネイティブIP）の場合、セキュリティサービスはソケットまたは同等のものにバインドされます。ここで、H1のIP / IPsec実装は、関連付けられたソケットのPMTUを格納/更新できます。ケース（b）の場合、H1のIPレイヤーはPMTUを格納/更新できますが、上記のように、送信元アドレスと宛先アドレス、および場合によってはTOS /クラスの粒度でのみ可能です。したがって、特定のSRC / DST / TOS / ClassのPMTUは、特定の送信元と宛先の間の通信アソシエーションに使用されるIPsecヘッダーの最大量の減算になるため、結果は次善の結果になる可能性があります。
In case (c), there has to be a security gateway to have any IPsec processing. So suppose you have the following situation. H1 is sending to H2 and the packet to be sent from SG1 to R exceeds the PMTU of the network hop between them.
（c）の場合、IPsec処理を行うにはセキュリティゲートウェイが必要です。したがって、次のような状況があるとします。 H1はH2に送信しており、SG1からRに送信されるパケットは、それらの間のネットワークホップのPMTUを超えています。
================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|
As described above for case (b), the IP layer in H1 can store/update the PMTU but only at the granularity of Source and Destination addresses, and possibly TOS/Class. So the result may be sub-optimal, since the PMTU for a given SRC/DST/TOS/Class will be the subtraction of the largest amount of IPsec header used for any communication association between a given source and destination.
上記のケース（b）で説明したように、H1のIP層はPMTUを格納/更新できますが、送信元アドレスと宛先アドレス、および場合によってはTOS /クラスの粒度でのみ保存できます。したがって、特定のSRC / DST / TOS / ClassのPMTUは、特定の送信元と宛先の間の通信アソシエーションに使用されるIPsecヘッダーの最大量の減算になるため、結果は次善の結果になる可能性があります。
B.3.4 Per Socket Maintenance of PMTU Data
B.3.4 PMTUデータのソケットごとのメンテナンス
Implementation of the calculation of PMTU (Section B.3.2) and support for PMTUs at the granularity of individual "communication associations" (Section B.3.3) is a local matter. However, a socket-based implementation of IPsec in a host SHOULD maintain the information on a per socket basis. Bump in the stack systems MUST pass an ICMP PMTU to the host IP implementation, after adjusting it for any IPsec header overhead added by these systems. The determination of the overhead SHOULD be determined by analysis of the SPI and any other selector information present in a returned ICMP PMTU message.
PMTUの計算（セクションB.3.2）の実装と、個々の「通信アソシエーション」（セクションB.3.3）の粒度でのPMTUのサポートは、ローカルな問題です。ただし、ホストでのIPsecのソケットベースの実装は、ソケットごとに情報を維持する必要があります（SHOULD）。スタックシステムのバンプは、これらのシステムによって追加されたIPsecヘッダーオーバーヘッドに合わせてICMP PMTUを調整した後、ホストIP実装に渡す必要があります。オーバーヘッドの決定は、返されたICMP PMTUメッセージに存在するSPIおよびその他のセレクター情報の分析によって決定する必要があります（SHOULD）。
B.3.5 Delivery of PMTU Data to the Transport Layer
B.3.5トランスポート層へのPMTUデータの配信
The host mechanism for getting the updated PMTU to the transport layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).
RFC 1191（Path MTU Discovery）で指定されているように、更新されたPMTUをトランスポート層に取得するためのホストメカニズムは変更されていません。
B.3.6 Aging of PMTU Data
B.3.6 PMTUデータのエージング
This topic is covered in Section 6.1.2.4.
このトピックについては、セクション6.1.2.4で説明しています。
Appendix C -- Sequence Space Window Code Example
付録C-シーケンススペースウィンドウのコード例
This appendix contains a routine that implements a bitmask check for a 32 packet window. It was provided by James Hughes (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) and is intended as an implementation example. Note that this code both checks for a replay and updates the window. Thus the algorithm, as shown, should only be called AFTER the packet has been authenticated. Implementers might wish to consider splitting the code to do the check for replays before computing the ICV. If the packet is not a replay, the code would then compute the ICV, (discard any bad packets), and if the packet is OK, update the window.
この付録には、32パケットウィンドウのビットマスクチェックを実装するルーチンが含まれています。 James Hughes（jim_hughes@stortek.com）とHarry Varnis（hgv@anubis.network.com）によって提供され、実装例として意図されています。このコードは、再生のチェックとウィンドウの更新の両方を行うことに注意してください。したがって、このアルゴリズムは、示されているように、パケットが認証された後でのみ呼び出す必要があります。実装者は、ICVを計算する前に、コードを分割してリプレイのチェックを行うことを検討する場合があります。パケットがリプレイでない場合、コードはICVを計算し（不良パケットを破棄）、パケットに問題がない場合はウィンドウを更新します。
#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;
enum {
ReplayWindowSize = 32
};
u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */
/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);
int ChkReplayWindow(u_long seq) {
u_long diff;
if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}
char string_buffer[512];
char string_buffer [512];
#define STRING_BUFFER_SIZE sizeof(string_buffer)
#define STRING_BUFFER_SIZE sizeof（string_buffer）
int main() {
int result;
u_long last, current, bits;
printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");
while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", ¤t);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}
Appendix D -- Categorization of ICMP messages
付録D-ICMPメッセージの分類
The tables below characterize ICMP messages as being either host generated, router generated, both, unassigned/unknown. The first set are IPv4. The second set are IPv6.
以下の表は、ICMPメッセージを、ホスト生成、ルーター生成、どちらも未割り当て/不明として特徴付けています。最初のセットはIPv4です。 2番目のセットはIPv6です。
IPv4
IPv4
Type Name/Codes Reference
========================================================================
HOST GENERATED:
3 Destination Unreachable
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
8 Source Host Isolated [RFC792]
14 Host Precedence Violation [RFC1812]
10 Router Selection [RFC1256]
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
3 Destination Unreachable
0 Net Unreachable [RFC792]
4 Fragmentation Needed, Don't Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC792]
7 Destination Host Unknown [RFC792]
9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792]
11 Destination Network Unreachable for Type of Service[RFC792]
5 Redirect
0 Redirect Datagram for the Network (or subnet) [RFC792]
2 Redirect Datagram for the Type of Service & Network[RFC792]
9 Router Advertisement [RFC1256]
18 Address Mask Reply [RFC950]
IPv4
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
0 Echo Reply [RFC792]
3 Destination Unreachable
1 Host Unreachable [RFC792]
10 Comm. w/Dest. Host is Administratively Prohibited [RFC792]
12 Destination Host Unreachable for Type of Service [RFC792]
13 Communication Administratively Prohibited [RFC1812]
15 Precedence cutoff in effect [RFC1812]
4 Source Quench [RFC792]
5 Redirect
1 Redirect Datagram for the Host [RFC792]
3 Redirect Datagram for the Type of Service and Host [RFC792]
6 Alternate Host Address [JBP]
8 Echo [RFC792]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792,RFC1108]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]
Type Name/Codes Reference
========================================================================
UNASSIGNED TYPE OR UNKNOWN GENERATOR:
1 Unassigned [JBP]
2 Unassigned [JBP]
7 Unassigned [JBP]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
33 IPv6 Where-Are-You [Simpson]
34 IPv6 I-Am-Here [Simpson]
35 Mobile Registration Request [Simpson]
36 Mobile Registration Reply [Simpson]
37 Domain Name Request [Simpson]
38 Domain Name Reply [Simpson]
41-255 Reserved [JBP]
IPv6
IPv6
Type Name/Codes Reference
========================================================================
HOST GENERATED:
1 Destination Unreachable [RFC 1885]
4 Port Unreachable
Type Name/Codes Reference
========================================================================
ROUTER GENERATED:
1 Destination Unreachable [RFC1885]
0 No Route to Destination
1 Comm. w/Destination is Administratively Prohibited
2 Not a Neighbor
3 Address Unreachable
2 Packet Too Big [RFC1885]
0
3 Time Exceeded [RFC1885]
0 Hop Limit Exceeded in Transit
1 Fragment reassembly time exceeded
Type Name/Codes Reference
========================================================================
BOTH ROUTER AND HOST GENERATED:
4 Parameter Problem [RFC1885]
0 Erroneous Header Field Encountered
1 Unrecognized Next Header Type Encountered
2 Unrecognized IPv6 Option Encountered
References
参考文献
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74- 244, The MITRE Corporation, Bedford, MA, May 1973.
[BL73]ベル、D.E。 ＆LaPadula、L.J.、 "Secure Computer Systems：Mathematical Foundations and Model"、Technical Report M74-244、The MITER Corporation、Bedford、MA、1973。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.
[DoD85] US National Computer Security Center、「Department of Defense Trusted Computer System Evaluation Criteria」、DoD 5200.28-STD、US Department of Defense、Ft。ミード、メリーランド州、1985年12月。
[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.
[DoD87] US National Computer Security Center、「Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria」、NCSC-TG-005、Version 1、米国国防総省、フォートミード、メリーランド州、1987年7月31日。
[HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94] Haller、N。、およびR. Atkinson、「On Internet Authentication」、RFC 1704、1994年10月。
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HC98] Harkins、D。、およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[HM97] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）Architecture」、RFC 2094、1997年7月。
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
[ISO] ISO / IEC JTC1 / SC6、ネットワーク層セキュリティプロトコル、ISO-IEC DIS 11577、国際標準化機構、スイス、ジュネーブ、1992年11月29日。
[IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.
[IB93] John IoannidisおよびMatt Blaze、「Unixでのネットワーク層セキュリティのアーキテクチャと実装」、USENIXセキュリティシンポジウムの議事録、カリフォルニア州サンタクララ、1993年10月。
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio
[IBK93] John Ioannidis、Matt Blaze、およびPhil Karn、「swIPe：Network-Layer Security for IP」、1993年春のIETFミーティング、オハイオ州コロンバスでのプレゼンテーション
[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[KA98a]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[KA98b]ケント、S。、およびR.アトキンソン、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.
[Ken91]ケントS.、「インターネットプロトコル用の米国国防総省セキュリティオプション」、RFC 1108、1991年11月。
[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[MSST97] Maughan、D.、Schertler、M.、Schneider、M。、およびJ. Turner、「インターネットセキュリティアソシエーションおよびキー管理プロトコル（ISAKMP）」、RFC 2408、1998年11月。
[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[Orm97] Orman、H。、「The OAKLEY Key Evaluation Protocol」、RFC 2412、1998年11月。
[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[Pip98] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Sch94] Bruce Schneier、Applied Cryptography、セクション8.6、John Wiley＆Sons、ニューヨーク、ニューヨーク、1994。
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.
[SDNS] SDNSセキュアデータネットワークシステム、セキュリティプロトコル3、SP3、ドキュメントSDN.301、リビジョン1.5、1989年5月15日、NIST Publication NIST-IR-90-4250、1990年2月に発行。
[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.
[SMPT98] Shacham、A.、Monsour、R.、Pereira、R。、およびM. Thomas、「IP Payload Compression Protocol（IPComp）」、RFC 2393、1998年8月。
[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[TDG97] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[VK83] V.L. Voydock＆S.T.ケント、「ハイレベルネットワークのセキュリティメカニズム」、ACM Computing Surveys、Vol。 15、No。2、1983年6月。
Disclaimer
免責事項
The views and specification expressed in this document are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this design.
このドキュメントに記載されている見解と仕様は著者の見解と仕様であり、必ずしもそれらの雇用者の見解ではありません。著者とその雇用者は、この設計の正しいまたは正しくない実装または使用から生じる問題に対する責任を明確に否認します。
Author Information
著者情報
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge, MA 02140 USA
Stephen Kent BBN Corporation 70 Fawcett Street Cambridge、MA 02140 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson @Home Network 425 Broadway Redwood City, CA 94063 USA
Randall Atkinson @Home Network 425 Broadway Redwood City、CA 94063 USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。