[要約] RFC 4301は、インターネットプロトコル（IP）のセキュリティアーキテクチャに関する文書で、IPsec（IP Security）プロトコルスイートの設計と実装の基盤を提供します。この文書の目的は、インターネット上での通信の機密性、データの完全性、および認証を保証するためのフレームワークを定義することにあります。利用場面としては、VPN（Virtual Private Network）の構築、エンドツーエンドのセキュリティ通信、サイト間通信の保護などがあります。関連するRFCには、RFC 4302（IP Authentication Header）、RFC 4303（IP Encapsulating Security Payload）、RFC 4306（Internet Key Exchange（IKEv2）Protocol）などがあり、これらはIPsecの様々な側面を詳細に説明しています。
Network Working Group S. Kent
Request for Comments: 4301 K. Seo
Obsoletes: 2401 BBN Technologies
Category: Standards Track December 2005
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998).
このドキュメントでは、IPレイヤーでトラフィックにセキュリティサービスを提供するように設計された「IPのセキュリティアーキテクチャ」の更新バージョンについて説明します。このドキュメントは、RFC 2401（1998年11月）を廃止します。
Dedication
献身
This document is dedicated to the memory of Charlie Lynn, a long-time senior colleague at BBN, who made very significant contributions to the IPsec documents.
この文書は、BBNの長年の上級同僚であるチャーリー・リンの記憶に捧げられています。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Summary of Contents of Document ............................4
1.2. Audience ...................................................4
1.3. Related Documents ..........................................5
2. Design Objectives ...............................................5
2.1. Goals/Objectives/Requirements/Problem Description ..........5
2.2. Caveats and Assumptions ....................................6
3. System Overview .................................................7
3.1. What IPsec Does ............................................7
3.2. How IPsec Works ............................................9
3.3. Where IPsec Can Be Implemented ............................10
4. Security Associations ..........................................11
4.1. Definition and Scope ......................................12
4.2. SA Functionality ..........................................16
4.3. Combining SAs .............................................17
4.4. Major IPsec Databases .....................................18
4.4.1. The Security Policy Database (SPD) .................19
4.4.1.1. Selectors .................................26
4.4.1.2. Structure of an SPD Entry .................30
4.4.1.3. More Regarding Fields Associated
with Next Layer Protocols .................32
4.4.2. Security Association Database (SAD) ................34
4.4.2.1. Data Items in the SAD .....................36
4.4.2.2. Relationship between SPD, PFP
flag, packet, and SAD .....................38
4.4.3. Peer Authorization Database (PAD) ..................43
4.4.3.1. PAD Entry IDs and Matching Rules ..........44
4.4.3.2. IKE Peer Authentication Data ..............45
4.4.3.3. Child SA Authorization Data ...............46
4.4.3.4. How the PAD Is Used .......................46
4.5. SA and Key Management .....................................47
4.5.1. Manual Techniques ..................................48
4.5.2. Automated SA and Key Management ....................48
4.5.3. Locating a Security Gateway ........................49
4.6. SAs and Multicast .........................................50
5. IP Traffic Processing ..........................................50
5.1. Outbound IP Traffic Processing
(protected-to-unprotected) ................................52
5.1.1. Handling an Outbound Packet That Must Be
Discarded ..........................................54
5.1.2. Header Construction for Tunnel Mode ................55
5.1.2.1. IPv4: Header Construction for
Tunnel Mode ...............................57
5.1.2.2. IPv6: Header Construction for
Tunnel Mode ...............................59
5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
6. ICMP Processing ................................................63
6.1. Processing ICMP Error Messages Directed to an
IPsec Implementation ......................................63
6.1.1. ICMP Error Messages Received on the
Unprotected Side of the Boundary ...................63
6.1.2. ICMP Error Messages Received on the
Protected Side of the Boundary .....................64
6.2. Processing Protected, Transit ICMP Error Messages .........64
7. Handling Fragments (on the protected side of the IPsec
boundary) ......................................................66
7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
Fragments .................................................67
7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
7.3. Stateful Fragment Checking ................................68
7.4. BYPASS/DISCARD Traffic ....................................69
8. Path MTU/DF Processing .........................................69
8.1. DF Bit ....................................................69
8.2. Path MTU (PMTU) Discovery .................................70
8.2.1. Propagation of PMTU ................................70
8.2.2. PMTU Aging .........................................71
9. Auditing .......................................................71
10. Conformance Requirements ......................................71
11. Security Considerations .......................................72
12. IANA Considerations ...........................................72
13. Differences from RFC 2401 .....................................72
14. Acknowledgements ..............................................75
Appendix A: Glossary ..............................................76
Appendix B: Decorrelation .........................................79
B.1. Decorrelation Algorithm ...................................79
Appendix C: ASN.1 for an SPD Entry ................................82
Appendix D: Fragment Handling Rationale ...........................88
D.1. Transport Mode and Fragments ..............................88
D.2. Tunnel Mode and Fragments .................................89
D.3. The Problem of Non-Initial Fragments ......................90
D.4. BYPASS/DISCARD Traffic ....................................93
D.5. Just say no to ports? .....................................94
D.6. Other Suggested Solutions..................................94
D.7. Consistency................................................95
D.8. Conclusions................................................95
Appendix E: Example of Supporting Nested SAs via SPD and
Forwarding Table Entries...............................96
References.........................................................98
Normative References............................................98
Informative References..........................................99
This document specifies the base architecture for IPsec-compliant systems. It describes how to provide a set of security services for traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] environments. This document describes the requirements for systems that implement IPsec, the fundamental elements of such systems, and how the elements fit together and fit 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 the IPsec architecture. Other documents address additional architectural details in specialized environments, e.g., use of IPsec in Network Address Translation (NAT) environments and more comprehensive support for IP multicast. The 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 [POS81A]とIPv6 [DH98]環境の両方で、IPレイヤーでトラフィックに一連のセキュリティサービスを提供する方法について説明します。このドキュメントでは、IPSECを実装するシステムの要件、そのようなシステムの基本的な要素、および要素がどのように適合し、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 automated (The Internet Key Exchange (IKE)) d. Cryptographic algorithms for authentication and encryption
a. セキュリティプロトコル - 認証ヘッダー（AH）およびセキュリティペイロードのカプセル化（ESP）b。セキュリティ協会 - それらが何であり、どのように機能するか、どのように管理されるか、関連する処理c。キー管理 - マニュアルおよび自動化（インターネットキーエクスチェンジ（IKE））d。認証と暗号化のための暗号化アルゴリズム
This document is not a 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 spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of the sequence of letters "IPsec" should be understood to refer to the IPsec protocols.
スペル「IPSEC」が推奨され、これとすべての関連するIPSEC標準全体で使用されます。IPSECの他のすべての大文字（例：IPSEC、IPSEC、IPSEC）は非推奨です。ただし、文字「IPSEC」のシーケンスの大文字は、IPSECプロトコルを参照することを理解する必要があります。
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].
キーワードは、このドキュメントに表示される場合、RFC 2119 [bra97]に記載されているように解釈される場合、必要な、必須、必要は、推奨、推奨、勧めてはいけません。
The target audience for this document is primarily individuals who implement this IP security technology or who architect systems that will use this technology. Technically adept users of this technology (end users or system administrators) also are part of the target audience. A glossary is provided in Appendix A to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol (IP), related networking technology, and general information system security terms and concepts.
このドキュメントのターゲットオーディエンスは、主にこのIPセキュリティテクノロジーを実装する個人、またはこのテクノロジーを使用するアーキテクトシステムを実装する個人です。このテクノロジー（エンドユーザーまたはシステム管理者）の技術的に熟練したユーザーもターゲットオーディエンスの一部です。バックグラウンド/語彙のギャップを埋めるために、付録Aに用語集が提供されています。このドキュメントは、読者がインターネットプロトコル（IP）、関連するネットワーキングテクノロジー、および一般情報システムのセキュリティ用語と概念に精通していることを前提としています。
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their interrelationship. They include RFCs on the following topics:
上記のように、他のドキュメントは、IPSECとその相互関係のコンポーネントの一部の詳細な定義を提供します。次のトピックにRFCSが含まれます。
a. security protocols -- RFCs describing the Authentication Header (AH) [Ken05b] and Encapsulating Security Payload (ESP) [Ken05a] protocols. b. cryptographic algorithms for integrity and encryption -- one RFC that defines the mandatory, default algorithms for use with AH and ESP [Eas05], a similar RFC that defines the mandatory algorithms for use with IKEv2 [Sch05] plus a separate RFC for each cryptographic algorithm. c. automatic key management -- RFCs on "The Internet Key Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)" [Sch05].
a. セキュリティプロトコル -認証ヘッダー（AH）[KEN05B]を記述するRFCおよびセキュリティペイロード（ESP）[KEN05A]プロトコルのカプセル化。b。整合性と暗号化のための暗号化アルゴリズム - AHおよびESP [EAS05]で使用するための必須のデフォルトアルゴリズムを定義する1つのRFC、IKEV2 [SCH05]と各クライプトグラフィックアルゴリスムの使用のための必須アルゴリズムと別のRFCを定義する同様のRFCは。c。自動キー管理 - 「インターネットキーエクスチェンジ（IKEV2）プロトコル」[KAU05]および「インターネットキーエクスチェンジバージョン2（IKEV2）（IKEV2）で使用する暗号化アルゴリズム」[SCH05]のRFC。
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, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself).
IPSECは、IPv4およびIPv6に相互運用可能で高品質の暗号化ベースのセキュリティを提供するように設計されています。提供されるセキュリティサービスのセットには、アクセス制御、コネクションレスの整合性、データの起源認証、検出、リプレイ（部分シーケンスの整合性の形式）、機密性（暗号化による）、および限られたトラフィックフローの機密性が含まれます。これらのサービスはIPレイヤーで提供され、IP（IP自体を含む）に携帯できるすべてのプロトコルに対して標準的な方法で保護を提供します。
IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer. Implementations are free to provide more sophisticated firewall mechanisms, and to implement the IPsec-mandated functionality using those more sophisticated mechanisms. (Note that interoperability may suffer if additional firewall constraints on traffic flows are imposed by an IPsec implementation but cannot be negotiated based on the traffic selector features defined in this document and negotiated via IKEv2.) The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.
IPSECには、IPレイヤーでのアクセス制御の重要な側面であるため、最小限のファイアウォール機能の仕様が含まれています。実装は、より洗練されたファイアウォールメカニズムを自由に提供し、それらのより洗練されたメカニズムを使用してIPSECが義務付けている機能を実装できます。（トラフィックフローの追加ファイアウォールの制約がIPSECの実装によって課される場合、このドキュメントで定義され、IKEV2を介して交渉されたトラフィックセレクター機能に基づいて交渉することはできない場合、相互運用性が低下する可能性があることに注意してください。）すべてのIPSECトラフィックが提供される認証と整合性は、ファイアウォール（IPSEC内部パラメーターに違反していない）と個別の暗号保護を使用することで得られるよりも優れたアクセス制御を提供します。
Most of the security services are provided through 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 a context, and the ways in which they are employed, will be determined by the users/administrators in that context. It is the goal of the IPsec architecture to ensure that compliant implementations include the services and management interfaces needed to meet the security requirements of a broad user population.
ほとんどのセキュリティサービスは、2つのトラフィックセキュリティプロトコル、認証ヘッダー（AH）とカプセル化セキュリティペイロード（ESP）を使用し、暗号化の主要な管理手順とプロトコルを使用することで提供されます。コンテキストで採用されているIPSECプロトコルのセット、およびそれらが採用される方法は、そのコンテキストでユーザー/管理者によって決定されます。IPSECアーキテクチャの目標は、準拠した実装には、幅広いユーザー人口のセキュリティ要件を満たすために必要なサービスと管理インターフェイスが含まれるようにすることです。
When IPsec is correctly implemented and deployed, it ought not adversely affect users, hosts, and other Internet components that do not employ IPsec for traffic protection. IPsec security protocols (AH and ESP, and to a lesser extent, IKE) are designed to be cryptographic algorithm independent. This modularity permits selection of different sets of cryptographic algorithms as appropriate, without affecting the other parts of the implementation. For example, different user communities may select different sets of cryptographic algorithms (creating cryptographically-enforced cliques) if required.
IPSECが正しく実装および展開されている場合、トラフィック保護のためにIPSECを使用していないユーザー、ホスト、およびその他のインターネットコンポーネントに悪影響を及ぼさないはずです。IPSECセキュリティプロトコル（AHおよびESP、およびそれほどではないが、IKE）は、暗号化アルゴリズムに依存しないように設計されています。このモジュール性により、実装の他の部分に影響を与えることなく、必要に応じて暗号化アルゴリズムのさまざまなセットの選択が可能になります。たとえば、さまざまなユーザーコミュニティが、必要に応じて、異なる暗号化アルゴリズムのセット（暗号化されたクリークの作成）を選択する場合があります。
To facilitate interoperability in the global Internet, a set of default cryptographic algorithms for use with AH and ESP is specified in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2 is specified in [Sch05]. [Eas05] and [Sch05] will be periodically updated to keep pace with computational and cryptologic advances. By specifying these algorithms in documents that are separate from the AH, ESP, and IKEv2 specifications, these algorithms can be updated or replaced without affecting the standardization progress of the rest of the IPsec document suite. The use of these cryptographic 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.
グローバルインターネットでの相互運用性を促進するために、AHおよびESPで使用するデフォルトの暗号化アルゴリズムのセットは[EAS05]で指定されており、IKEV2の必須の義務的なアルゴリズムのセットは[SCH05]で指定されています。[EAS05]および[SCH05]は定期的に更新され、計算および暗号化の進歩に対応します。これらのアルゴリズムをAH、ESP、およびIKEV2仕様とは別のドキュメントで指定することにより、これらのアルゴリズムをIPSECドキュメントスイートの残りの標準化の進捗に影響を与えることなく、更新または置き換えることができます。これらの暗号化アルゴリズムの使用は、IPSECトラフィック保護および主要な管理プロトコルと組み合わせて、システムとアプリケーション開発者が高品質のインターネット層の暗号セキュリティテクノロジーを展開できるようにすることを目的としています。
The suite of IPsec protocols and associated default cryptographic 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 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, as a security gateway (SG), or as an independent device, affording protection to IP traffic. (A security gateway is an intermediate system implementing IPsec, e.g., a firewall or router that has been IPsec-enabled.) More detail on these classes of implementations is provided later, in Section 3.3. The protection offered by IPsec 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 actions based on IP and next layer header information ("Selectors", Section 4.4.1.1) matched against entries in the SPD. Each packet is either PROTECTed using IPsec security services, DISCARDed, or allowed to BYPASS IPsec protection, based on the applicable SPD policies identified by the Selectors.
IPSECの実装は、セキュリティゲートウェイ（SG）または独立したデバイスとしてホストで動作し、IPトラフィックを保護します。（セキュリティゲートウェイは、IPSECを実装する中間システムです。たとえば、IPSEC対応のファイアウォールまたはルーター。）これらのクラスの実装の詳細については、後でセクション3.3に記載されています。IPSECが提供する保護は、ユーザーまたはシステム管理者によって確立および維持されるセキュリティポリシーデータベース（SPD）によって定義された要件に基づいています。一般に、IPおよび次のレイヤーヘッダー情報（「セレクター」、セクション4.4.1.1）に基づく3つの処理アクションのいずれかに対してパケットが選択されます。SPDのエントリと一致します。各パケットは、IPSECセキュリティサービスを使用して保護され、廃棄された、またはセレクターによって識別される該当するSPDポリシーに基づいてIPSEC保護をバイパスすることが許可されています。
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network (see Figure 1 below). Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration. These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded.
IPSECは、ホストまたはネットワークのために、保護されていないインターフェイスと保護されたインターフェイスの境界を作成します（下の図1を参照）。境界を通過するトラフィックは、IPSEC構成を担当するユーザーまたは管理者によって指定されたアクセスコントロールの対象となります。これらのコントロールは、パケットが妨害されずに境界を通過するか、AHまたはESPを介してセキュリティサービスが提供されているのか、それとも破棄されているかを示しています。
IPsec security services are offered at the IP layer through selection of appropriate security protocols, cryptographic algorithms, and cryptographic keys. IPsec can be used to protect one or more "paths" (a) between a pair of hosts, (b) between a pair of security gateways, or (c) between a security gateway and a host. A compliant host implementation MUST support (a) and (c) and a compliant security gateway must support all three of these forms of connectivity, since under certain circumstances a security gateway acts as a host.
IPSECセキュリティサービスは、適切なセキュリティプロトコル、暗号化アルゴリズム、および暗号化キーの選択を通じてIPレイヤーで提供されます。IPSECを使用して、1つ以上の「パス」を保護することができます（a）ホストのペア間、（b）セキュリティゲートウェイのペア間、または（c）セキュリティゲートウェイとホストの間の間の間の間のペア。準拠したホストの実装は（a）および（c）をサポートする必要があり、準拠したセキュリティゲートウェイは、これらの3つの形式の接続性すべてをサポートする必要があります。特定の状況では、セキュリティゲートウェイがホストとして機能するためです。
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
Figure 1. Top Level IPsec Processing Model
図1.トップレベルのIPSEC処理モデル
In this diagram, "unprotected" refers to an interface that might also be described as "black" or "ciphertext". Here, "protected" refers to an interface that might also be described as "red" or "plaintext". The protected interface noted above may be internal, e.g., in a host implementation of IPsec, the protected interface may link to a socket layer interface presented by the OS. In this document, the term "inbound" refers to traffic entering an IPsec implementation via the unprotected interface or emitted by the implementation on the unprotected side of the boundary and directed towards the protected interface. The term "outbound" refers to traffic entering the implementation via the protected interface, or emitted by the implementation on the protected side of the boundary and directed toward the unprotected interface. An IPsec implementation may support more than one interface on either or both sides of the boundary.
この図では、「保護されていない」とは、「ブラック」または「ciphertext」とも記述されるインターフェイスを指します。ここで、「保護された」とは、「赤」または「プレーンテキスト」とも記載されているインターフェイスを指します。上記の保護されたインターフェイスは内部である可能性があります。たとえば、IPSECのホスト実装では、保護されたインターフェイスがOSが提示するソケットレイヤーインターフェイスにリンクする場合があります。このドキュメントでは、「Inbound」という用語は、保護されていないインターフェイスを介してIPSEC実装の入力または保護されていない境界側の実装によって放出され、保護されたインターフェイスに向けられたトラフィックを指します。「アウトバウンド」という用語とは、保護されたインターフェイスを介して実装に入るトラフィック、または境界の保護された側の実装によって放出され、保護されていないインターフェイスに向けられたトラフィックを指します。IPSECの実装は、境界のいずれかまたは両側に複数のインターフェイスをサポートする場合があります。
Note the facilities for discarding traffic on either side of the IPsec boundary, the BYPASS facility that allows traffic to transit the boundary without cryptographic protection, and the reference to IKE as a protected-side key and security management function.
IPSEC境界の両側にトラフィックを廃棄する施設、暗号化保護なしにトラフィックが境界を通過できるようにするバイパス機能、および保護された側面キーおよびセキュリティ管理機能としてのIKEへの参照に注意してください。
IPsec optionally supports negotiation of IP compression [SMPT01], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers.
IPSECはオプションで、IP圧縮[SMPT01]の交渉をサポートします。これは、暗号化がIPSEC内で使用されると、より低いプロトコル層による効果的な圧縮を防ぐという観察によって部分的に動機付けられています。
IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in detail in their respective RFCs [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.)
IPSECは、2つのプロトコルを使用してトラフィックセキュリティサービスを提供します - 認証ヘッダー（AH）とセキュリティペイロードのカプセル化（ESP）。両方のプロトコルは、それぞれのRFC [KEN05B、KEN05A]で詳細に説明されています。IPSECの実装はESPをサポートする必要があり、AHをサポートする場合があります。（AHのサポートは5月に格下げされています。これにより、ESPが必要なセキュリティサービスを提供できないコンテキストが非常に少ないことが示されているため、ESPは機密性なしで整合性のみを提供するために使用できることに注意してください。コンテキスト。）
o The IP Authentication Header (AH) [Ken05b] offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti-replay features.
o IP認証ヘッダー（AH）[KEN05B]は、オプションの（受信者の裁量で）レプレイアンチレプレイ機能を備えた、整合性とデータの起源認証を提供します。
o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers the same set of services, and also offers confidentiality. Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED. When ESP is used with confidentiality enabled, there are provisions for limited traffic flow confidentiality, i.e., provisions for concealing packet length, and for facilitating efficient generation and discard of dummy packets. This capability is likely to be effective primarily in virtual private network (VPN) and overlay network contexts.
o セキュリティペイロード（ESP）プロトコル[KEN05A]が同じサービスセットを提供し、機密性も提供します。整合性のない機密性を提供するためにESPを使用することは推奨されません。ESPが機密性を有効にして使用する場合、トラフィックフローの機密性が限られていること、つまりパケットの長さを隠し、効率的な生成とダミーパケットの破棄を促進するための規定があります。この機能は、主に仮想プライベートネットワーク（VPN）およびオーバーレイネットワークコンテキストで効果的である可能性があります。
o Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database (SPD, Section 4.4.1).
o AHとESPの両方は、暗号化キーの分布とセキュリティポリシーデータベース（SPD、セクション4.4.1）によって決定されるトラフィックフローの管理を通じて強制されるアクセス制御を提供します。
These protocols may be applied individually or in combination with each other to provide IPv4 and IPv6 security services. However, most security requirements can be met through the use of ESP by itself. Each protocol supports two modes of use: transport mode and tunnel mode. In transport mode, AH and ESP provide protection primarily for next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets. The differences between the two modes are discussed in Section 4.1.
これらのプロトコルは、IPv4およびIPv6セキュリティサービスを提供するために、個別にまたは互いに組み合わせて適用できます。ただし、ほとんどのセキュリティ要件は、ESPを単独で使用することで満たすことができます。各プロトコルは、輸送モードとトンネルモードの2つの使用モードをサポートしています。輸送モードでは、AHとESPは主に次の層プロトコルの保護を提供します。トンネルモードでは、AHとESPがトンネル付きIPパケットに適用されます。2つのモードの違いについては、セクション4.1で説明します。
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, through the SPD management paradigm, incorporates facilities for specifying:
IPSECを使用すると、ユーザー（またはシステム管理者）がセキュリティサービスが提供される粒度を制御できます。たとえば、2つのセキュリティゲートウェイの間にすべてのトラフィックを運ぶための単一の暗号化されたトンネルを作成するか、これらのゲートウェイ全体で通信する各ペアのペア間の各TCP接続に対して別の暗号化されたトンネルを作成できます。IPSECは、SPD管理パラダイムを通じて、指定するための施設が組み込まれています。
o which security protocol (AH or ESP) to employ, the mode (transport or tunnel), security service options, what cryptographic algorithms to use, and in what combinations to use the specified protocols and services, and
o 使用するセキュリティプロトコル（AHまたはESP）、モード（輸送またはトンネル）、セキュリティサービスオプション、使用する暗号化アルゴリズム、および指定されたプロトコルとサービスを使用する組み合わせ、および
o the granularity at which protection should be applied.
o 保護を適用する粒度。
Because most of the security services provided by IPsec require the use of cryptographic keys, IPsec relies on a separate set of mechanisms for putting these keys in place. This document requires support for both manual and automated distribution of keys. It specifies a specific public-key based approach (IKEv2 [Kau05]) for automated key management, but other automated key distribution techniques MAY be used.
IPSECが提供するセキュリティサービスのほとんどは暗号化キーを使用する必要があるため、IPSECはこれらのキーを配置するための個別のメカニズムセットに依存しています。このドキュメントでは、キーの手動および自動化された配布の両方をサポートする必要があります。自動化されたキー管理用の特定のパブリックキーベースのアプローチ（IKEV2 [KAU05]）を指定しますが、他の自動化されたキーディストリビューション手法を使用できます。
Note: This document mandates support for several features for which support is available in IKEv2 but not in IKEv1, e.g., negotiation of an SA representing ranges of local and remote ports or negotiation of multiple SAs with the same selectors. Therefore, this document assumes use of IKEv2 or a key and security association management system with comparable features.
注：このドキュメントは、IKEV2でサポートが利用可能であるが、IKEV1では利用可能ではないいくつかの機能のサポートを義務付けています。たとえば、ローカルおよびリモートポートの範囲を表すSAの交渉、または同じセレクターとの複数のSAの交渉。したがって、このドキュメントでは、IKEV2または同等の機能を備えたキーおよびセキュリティ協会の管理システムの使用を想定しています。
There are many ways in which IPsec may be implemented in a host, or in conjunction with a router or firewall to create a security gateway, or as an independent security device.
IPSECをホストに実装したり、セキュリティゲートウェイを作成したり、独立したセキュリティデバイスとしてルーターまたはファイアウォールと併せて実装することができる多くの方法があります。
a. IPsec may be integrated into the native IP stack. This requires access to the IP source code and is applicable to both hosts and security gateways, although native host implementations benefit the most from this strategy, as explained later (Section 4.4.1, paragraph 6; Section 4.4.1.1, last paragraph).
a. IPSECは、ネイティブIPスタックに統合される場合があります。これにはIPソースコードへのアクセスが必要であり、ホストとセキュリティゲートウェイの両方に適用できますが、ネイティブのホストの実装は、後で説明するように、この戦略から最も利益を得ます（セクション4.4.1、パラグラフ6、セクション4.4.1.1、最後のパラグラフ）。
b. In a "bump-in-the-stack" (BITS) implementation, 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 a dedicated, inline security protocol processor is a common design feature of 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. Usually, the BITW device is itself 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. 専用のインラインセキュリティプロトコルプロセッサの使用は、軍隊が使用するシステム、および一部の商業システムの一般的な設計機能です。時々「ワイヤーの衝突」（BITW）の実装と呼ばれます。このような実装は、ホストまたはゲートウェイのいずれかを提供するように設計されている場合があります。通常、BITWデバイス自体はIPアドレス可能です。単一のホストをサポートする場合、ビットの実装に非常に類似している場合がありますが、ルーターやファイアウォールをサポートする場合は、セキュリティゲートウェイのように動作する必要があります。
This document often talks in terms of use of IPsec by a host or a security gateway, without regard to whether the implementation is native, BITS, or BITW. When the distinctions among these implementation options are significant, the document makes reference to specific implementation approaches.
このドキュメントは、実装がネイティブ、ビット、またはBITWであるかどうかに関係なく、ホストまたはセキュリティゲートウェイによるIPSECの使用に関してしばしば話します。これらの実装オプション間の区別が重要な場合、ドキュメントは特定の実装アプローチを参照します。
A host implementation of IPsec may appear in devices that might not be viewed as "hosts". For example, a router might employ IPsec to protect routing protocols (e.g., BGP) and management functions (e.g., Telnet), without affecting subscriber traffic traversing the router. A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic. The architecture described in this document is very flexible. For example, a computer with a full-featured, compliant, native OS IPsec implementation should be capable of being configured to protect resident (host) applications and to provide security gateway protection for traffic traversing the computer. Such configuration would make use of the forwarding tables and the SPD selection function described in Sections 5.1 and 5.2.
IPSECのホスト実装は、「ホスト」と見なされないデバイスに表示される場合があります。たとえば、ルーターは、ルーターを通過するサブスクライバートラフィックに影響を与えることなく、ルーティングプロトコル（例：BGP）および管理機能（たとえば、Telnet）を保護するためにIPSECを使用する場合があります。セキュリティゲートウェイは、管理トラフィックと加入者トラフィックを保護するために、個別のIPSEC実装を採用する場合があります。このドキュメントで説明されているアーキテクチャは非常に柔軟です。たとえば、フル機能の準拠したネイティブOS IPSECの実装を備えたコンピューターは、居住者（ホスト）アプリケーションを保護し、コンピューターを通過するトラフィックにセキュリティゲートウェイ保護を提供するように構成できる必要があります。このような構成は、フォワーディングテーブルとセクション5.1および5.2で説明されているSPD選択関数を利用します。
This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both AH and ESP. 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 SAs. All implementations of AH or ESP MUST support the concept of an SA as described below. The remainder of this section describes various aspects of SA management, defining required characteristics for SA policy management and SA management techniques.
このセクションでは、すべてのIPv6実装と、AH、ESP、またはAHとESPの両方を実装するIPv4実装のセキュリティ協会管理要件を定義します。「セキュリティ協会」（SA）の概念は、IPSECの基本です。AHとESPの両方がSASを利用しており、IKEの主要な機能はSASの確立と維持です。AHまたはESPのすべての実装は、以下に説明するようにSAの概念をサポートする必要があります。このセクションの残りの部分では、SA管理のさまざまな側面について説明し、SAポリシー管理とSA管理技術に必要な特性を定義します。
An 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 are applied to a traffic stream, then two SAs must be created and coordinated to effect protection through iterated application of the security protocols. To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement.
SAは、シンプルな「接続」であり、セキュリティサービスがそれによって運ばれるトラフィックに提供されます。セキュリティサービスは、AHまたはESPを使用することにより、SAに提供されますが、両方ではありません。AHとESP保護の両方がトラフィックストリームに適用される場合、セキュリティプロトコルの反復アプリケーションを介して保護を実施するために、2つのSAを作成および調整する必要があります。2つのIPSEC対応システム間の典型的な双方向通信を確保するには、SASのペア（各方向に1つ）が必要です。IKEは、この共通の使用要件を認識してSAペアを明示的に作成します。
For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. (For information on the SPI, see Appendix A and the AH and ESP specifications [Ken05b, Ken05a].) However, as a local matter, an implementation may choose to use the SPI in conjunction with the IPsec protocol type (AH or ESP) for SA identification. If an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
ユニキャストトラフィックを運ぶために使用されるSAの場合、セキュリティパラメーターインデックス（SPI）はそれ自体でSAを指定するのに十分です。（SPIの詳細については、付録AおよびAHおよびESP仕様[KEN05B、KEN05A]を参照してください。）ただし、ローカルな問題として、実装はIPSECプロトコルタイプ（AHまたはESP）と組み合わせてSPIを使用することを選択する場合があります。SA識別用。IPSECの実装がマルチキャストをサポートする場合、インバウンドIPSECデータグラムをSASにマッピングするために、以下のアルゴリズムを使用してマルチキャストSASをサポートする必要があります。ユニキャストトラフィックのみをサポートする実装では、この脱倍化アルゴリズムを実装する必要はありません。
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that reside in the individual end systems that constitute the group. Consequently, it is possible that a GSA and a unicast SA can simultaneously use the same SPI. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions.
多くの安全なマルチキャストアーキテクチャなど、[RFC3740]では、中央グループコントローラー/キーサーバーがグループセキュリティ協会（GSA）SPIを一方的に割り当てます。このSPIの割り当ては、グループを構成する個々のエンドシステムに存在する主要な管理（IKE）サブシステムと交渉または調整されていません。その結果、GSAとユニキャストSAが同じSPIを同時に使用できる可能性があります。マルチキャスト利用可能なIPSECの実装は、SPI衝突のコンテキストでも、インバウンドトラフィックを正しく脱化する必要があります。
Each entry in the SA Database (SAD) (Section 4.4.2) must indicate whether the SA lookup makes use of the destination IP address, or the destination and source IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination address, or destination and source address (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows:
SAデータベースの各エントリ（SAD）（セクション4.4.2）は、SAのルックアップがSPIに加えて、宛先IPアドレスまたは宛先およびソースIPアドレスを使用するかどうかを示す必要があります。マルチキャストSASの場合、SAルックアップにはプロトコルフィールドが使用されていません。IPSECで保護された各パケットについて、実装は、「最も長い」SA識別子と一致するエントリを見つけるように、SADの検索を実施する必要があります。これに関連して、SPI値に基づいて2つ以上のSADエントリが一致する場合、宛先アドレスまたは宛先およびソースアドレス（SADエントリに示されているように）に基づいて一致するエントリが「最長」の一致です。これは、次のように悲しい検索の論理的な順序を意味します。
1. Search the SAD for a match on the combination of SPI, destination address, and source address. If an SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 2.
1. SPI、宛先アドレス、およびソースアドレスの組み合わせの試合を悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドパケットを処理します。それ以外の場合は、ステップ2に進みます。
2. Search the SAD for a match on both SPI and destination address. If the SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, proceed to step 3.
2. SPIアドレスと宛先アドレスの両方でマッチを悲しみを検索します。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドパケットを処理します。それ以外の場合は、ステップ3に進みます。
3. Search the SAD for a match on only SPI if the receiver has chosen to maintain a single SPI space for AH and ESP, and on both SPI and protocol, otherwise. If an SAD entry matches, then process the inbound packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
3. ReceiverがAHとESPの単一のSPIスペースを維持することを選択した場合、SPIのみで試合を検索してください。悲しいエントリが一致する場合は、その一致する悲しいエントリでインバウンドパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントを記録します。
In practice, an implementation may choose any method (or none at all) to accelerate this search, although its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order. For example, a software-based implementation could index into a hash table by the SPI. The SAD entries in each hash table bucket's linked list could be kept sorted to have those SAD entries with the longest SA identifiers first in that linked list. Those SAD entries having the shortest SA identifiers could be sorted so that they are the last entries in the linked list. A hardware-based implementation may be able to effect the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features.
実際には、実装では、この検索を加速するための方法（またはまったくない）を選択する場合がありますが、外部から表示される動作は、上記の順序でSADを検索したことと機能的に同等でなければなりません。たとえば、ソフトウェアベースの実装は、SPIによってハッシュテーブルにインデックスを付けることができます。各ハッシュテーブルバケットのリンクリストの悲しいエントリは、そのリンクリストで最初に最初に最も長いSA識別子を持つこれらの悲しいエントリを持つように並べ替えておくことができます。最短のSA識別子を持つこれらの悲しいエントリは、リンクリストの最後のエントリであるようにソートすることができます。ハードウェアベースの実装は、一般的に利用可能な3成分アドレス可能なメモリ（TCAM）機能を使用して、本質的に最長の一致検索に影響を与えることができる場合があります。
The indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier composed of an SPI, a destination multicast address, and source address. An Any-Source Multicast group SA requires only an SPI and a destination multicast address as an identifier.
INBOUND IPSECトラフィックをSASにマッピングするためにソースと宛先アドレスのマッチングが必要かどうかを示すことは、SAマネジメントプロトコルなど、IKEまたはグループドメインの解釈（GDOI）を使用したネゴシエーションを使用して、マニュアルSA構成の副作用として設定する必要があります。[RFC3547]。通常、ソース固有のマルチキャスト（SSM）[HC03]グループは、SPI、宛先マルチキャストアドレス、およびソースアドレスで構成される3タプルSA識別子を使用します。任意のソースマルチキャストグループSAには、識別子としてSPIと宛先マルチキャストアドレスのみが必要です。
If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism.
さまざまなクラスのトラフィック（差別化されたサービスコードポイント（DSCP）ビット[Niblbabl98]、[GRO02]によって区別される場合）が同じSAで送信され、受信機がAHとESPの両方で利用可能なオプションのアンチレプレイ機能を使用している場合、これにより、この機能で使用されるウィンドウ化メカニズムにより、優先度の低いパケットが不適切に破棄される可能性があります。したがって、送信者は異なるクラスのトラフィックを配置する必要がありますが、同じセレクター値を使用して、サービス品質（QoS）を適切にサポートするために異なるSASに使用する必要があります。これを許可するには、IPSECの実装では、同じセレクターを使用して、特定の送信者と受信機の間の複数のSAの確立とメンテナンスを許可する必要があります。QoSをサポートするためのこれらの並列SAS間のトラフィックの分布は、送信者によってローカルに決定され、IKEによって交渉されません。受信者は、偏見なく異なるSASからパケットを処理する必要があります。これらの要件は、輸送およびトンネルモードSASの両方に適用されます。トンネルモードSASの場合、問題のDSCP値が内部IPヘッダーに表示されます。輸送モードでは、DSCP値は途中で変更される可能性がありますが、これはSA選択に値が使用されていないため、IPSEC処理に関して問題を引き起こすことはありません。SA/パケット検証の一部として確認する必要はありません。ただし、SAでパケットの重要な再注文が発生した場合、たとえば、途中でDSCP値の変更の結果として、これは、反レプレイメカニズムの適用によりレシーバーによるパケット廃棄をトリガーする可能性があります。
DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", as that term in used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier".
議論：DSCP [NIBLBABL98、GRO02]および明示的な混雑通知（ECN）[RAFLBL01]フィールドは「セレクター」ではありません。の）適切なSAへのDSCP値。このメカニズムは、「分類器」と呼ばれる場合があります。
As noted above, two types of SAs are defined: transport mode and tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose to require that both SAs in a pair be of the same mode, transport or tunnel.
上記のように、2種類のSASが定義されています：輸送モードとトンネルモード。IkeはSASのペアを作成するため、簡単にするために、ペアの両方のSASが同じモード、輸送、またはトンネルの両方であることを要求することを選択します。
A transport mode SA is an SA typically employed between a pair of hosts to provide end-to-end security services. When security is desired between two intermediate systems along a path (vs. end-to-end use of IPsec), transport mode MAY be used between security gateways or between a security gateway and a host. In the case where transport mode is used between security gateways or between a security gateway and a host, transport mode may be used to support in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing [ToEgWa04]) over transport mode SAs. To clarify, the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself. The access control functions that are an important part of IPsec are significantly limited in this context, as they cannot be applied to the end-to-end headers of the packets that traverse a transport mode SA used in this fashion. Thus, this way of using transport mode should be evaluated carefully before being employed in a specific context.
トランスポートモードSAは、通常、ホストのペア間で使用されるSAで、エンドツーエンドのセキュリティサービスを提供します。パスに沿った2つの中間システム（IPSECのエンドツーエンドの使用）間でセキュリティが望まれる場合、セキュリティゲートウェイまたはセキュリティゲートウェイとホストの間で輸送モードを使用できます。セキュリティゲートウェイ間またはセキュリティゲートウェイとホストの間で輸送モードが使用される場合、IP内トンネリング（例：IP-in-IP [PER96]または一般的なルーティングカプセル化（GRE）トンネリングをサポートするために輸送モードを使用できます。[Falihametr00]または動的ルーティング[toegwa04]）輸送モードSAS。明確にするために、中間システム（セキュリティゲートウェイなど）による輸送モードの使用は、ソースアドレス（アウトバウンドパケット用）または宛先アドレス（インバウンドパケット用）が中間システムに属するアドレスであるパケットに適用された場合にのみ許可されます。自体。IPSECの重要な部分であるアクセス制御機能は、このコンテキストでは、このファッションで使用されたトランスポートモードSAを横断するパケットのエンドツーエンドヘッダーに適用できないため、このコンテキストでは大幅に制限されています。したがって、特定のコンテキストで採用される前に、輸送モードを使用するこの方法は慎重に評価する必要があります。
In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any next layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and selected extension headers, but may appear before or after destination options; it MUST appear before next layer protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)). In the case of ESP, a transport mode SA provides security services only for these next 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 preceding it, 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 [Ken05b].
IPv4では、トランスポートモードのセキュリティプロトコルヘッダーがIPヘッダーとオプションの直後に表示され、次のレイヤープロトコル（TCPやUDPなど）の直前に表示されます。IPv6では、セキュリティプロトコルヘッダーがベースIPヘッダーと選択した拡張ヘッダーの後に表示されますが、宛先オプションの前後に表示される場合があります。次のレイヤープロトコル（TCP、UDP、ストリーム制御伝送プロトコル（SCTP））の前に表示する必要があります。ESPの場合、トランスポートモードSAは、IPヘッダーまたはESPヘッダーの前のエクステンションヘッダーではなく、これらの次のレイヤープロトコルに対してのみセキュリティサービスを提供します。AHの場合、保護は、その前のIPヘッダーの選択された部分、拡張ヘッダーの選択された部分、および選択されたオプションに拡張されます（IPv4ヘッダー、IPv6ホップバイホップエクステンションヘッダー、またはIPv6宛先拡張機能に含まれますヘッダー）。AHが提供するカバレッジの詳細については、AH仕様[KEN05B]を参照してください。
A tunnel mode SA is essentially an SA applied to an IP tunnel, with the access controls applied to the headers of the traffic inside the tunnel. Two hosts MAY establish a tunnel mode SA between themselves. Aside from the two exceptions below, 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 typically a tunnel mode SA, as is an SA between a host and a security gateway. The two exceptions are as follows.
トンネルモードSAは、本質的にIPトンネルに適用されるSAであり、アクセス制御がトンネル内のトラフィックのヘッダーに適用されます。2人のホストが自分の間にトンネルモードSAを確立することができます。以下の2つの例外は別として、セキュリティ協会のいずれかの端がセキュリティゲートウェイである場合、SAはトンネルモードでなければなりません。したがって、2つのセキュリティゲートウェイの間のSAは、通常、ホストとセキュリティゲートウェイの間のSAと同様に、トンネルモードSAです。2つの例外は次のとおりです。
o Where traffic is destined for a security gateway, e.g., Simple Network Management Protocol (SNMP) commands, the security gateway is acting as a host and transport mode is allowed. In this case, the SA terminates at a host (management) function within a security gateway and thus merits different treatment.
o トラフィックがセキュリティゲートウェイ、たとえばシンプルなネットワーク管理プロトコル（SNMP）コマンドに向けられている場合、セキュリティゲートウェイはホストとして機能し、輸送モードが許可されています。この場合、SAはセキュリティゲートウェイ内のホスト（管理）機能で終了し、したがって異なる治療に値します。
o As noted above, security gateways MAY support a transport mode SA to provide security for IP traffic between two intermediate systems along a path, e.g., between a host and a security gateway or between two security gateways.
o 上記のように、セキュリティゲートウェイは、トランスポートモードSAをサポートして、ホストとセキュリティゲートウェイの間、または2つのセキュリティゲートウェイ間で、パスに沿った2つの中間システム間のIPトラフィックのセキュリティを提供する場合があります。
Several concerns motivate the use of tunnel mode for an SA involving a security gateway. For example, if there are multiple paths (e.g., via different security gateways) to the same destination behind a security gateway, it is important that an IPsec packet be sent to the security gateway with which the SA was negotiated. Similarly, a packet that might be fragmented en route must have all the fragments delivered to the same IPsec instance for reassembly prior to cryptographic processing. Also, when a fragment is processed by IPsec and transmitted, then fragmented en route, it is critical that there be inner and outer headers to retain the fragmentation state data for the pre- and post-IPsec packet formats. Hence there are several reasons for employing tunnel mode when either end of an SA is a security gateway. (Use of an IP-in-IP tunnel in conjunction with transport mode can also address these fragmentation issues. However, this configuration limits the ability of IPsec to enforce access control policies on traffic.)
いくつかの懸念は、セキュリティゲートウェイを含むSAのトンネルモードの使用を動機付けています。たとえば、セキュリティゲートウェイの後ろの同じ宛先に複数のパス（異なるセキュリティゲートウェイを介して）がある場合、SAが交渉されたセキュリティゲートウェイにIPSECパケットを送信することが重要です。同様に、途中で断片化される可能性のあるパケットは、暗号化処理の前に再組み立てのためにすべてのフラグメントを同じIPSECインスタンスに配信する必要があります。また、フラグメントがIPSECによって処理されて送信され、途中で断片化された場合、IPSEC前後のパケット形式の断片化状態データを保持するための内側および外側のヘッダーがあることが重要です。したがって、SAのいずれかの端がセキュリティゲートウェイである場合、トンネルモードを使用する理由はいくつかあります。（トランスポートモードと併せてIP-in-IPトンネルを使用すると、これらの断片化の問題にも対処できます。ただし、この構成により、IPSECがトラフィックのアクセス制御ポリシーを実施する能力が制限されます。）
Note: AH and ESP cannot be applied using transport mode to IPv4 packets that are fragments. Only tunnel mode can be employed in such cases. For IPv6, it would be feasible to carry a plaintext fragment on a transport mode SA; however, for simplicity, this restriction also applies to IPv6 packets. See Section 7 for more details on handling plaintext fragments on the protected side of the IPsec barrier.
注：AHとESPは、トランスポートモードを使用してフラグメントであるIPv4パケットに適用できません。このような場合には、トンネルモードのみを使用できます。IPv6の場合、トランスポートモードSAでプレーンテキストフラグメントを運ぶことが可能です。ただし、簡単にするために、この制限はIPv6パケットにも適用されます。IPSECバリアの保護された側のプレーンテキストフラグメントの取り扱いの詳細については、セクション7を参照してください。
For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing source and destination, plus an "inner" IP header that specifies the (apparently) ultimate source and 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 next 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 implementation of IPsec MUST support both transport and tunnel mode. This is true for native, BITS, and BITW implementations for hosts.
a) IPSECのホスト実装は、輸送モードとトンネルモードの両方をサポートする必要があります。これは、ホストのネイティブ、ビット、およびBITWの実装に当てはまります。
b) A security gateway MUST support tunnel mode and MAY support transport 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, or to provide security between two intermediate systems along a path.
b) セキュリティゲートウェイは、トンネルモードをサポートする必要があり、輸送モードをサポートする必要があります。トランスポートモードをサポートする場合は、セキュリティゲートウェイがホストとして機能している場合にのみ使用する必要があります。たとえば、ネットワーク管理のために、またはパスに沿って2つの中間システム間でセキュリティを提供するためです。
The set of security services offered by an SA depends on the security protocol selected, the SA mode, the endpoints of the SA, and the election of optional services within the protocol.
SAが提供するセキュリティサービスのセットは、選択されたセキュリティプロトコル、SAモード、SAのエンドポイント、およびプロトコル内のオプションサービスの選挙に依存します。
For example, both AH and ESP offer integrity and authentication services, but the coverage differs for each protocol and differs for transport vs. tunnel mode. 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 IP or extension headers that may change in a fashion not predictable by the sender.
たとえば、AHとESPの両方が整合性と認証サービスを提供しますが、カバレッジは各プロトコルで異なり、輸送モードとトンネルモードで異なります。送信者と受信機の間で途中でIPv4オプションまたはIPv6拡張ヘッダーの整合性を保護する必要がある場合、AHは、送信者が予測できないファッションで変更される可能性のあるIPまたは拡張ヘッダーを除き、このサービスを提供できます。
However, the same security may be achieved in some contexts by applying ESP to a tunnel carrying a packet.
ただし、パケットを運ぶトンネルにESPを適用することにより、一部のコンテキストでも同じセキュリティが達成される場合があります。
The granularity of access control provided is determined by the choice of the selectors that define each SA. Moreover, the authentication means employed by IPsec peers, e.g., during creation of an IKE (vs. child) SA also affects the granularity of the access control afforded.
提供されるアクセス制御の粒度は、各SAを定義するセレクターの選択によって決定されます。さらに、認証は、IPSECピアによって採用されていることを意味します。たとえば、IKE（子ども）SAの作成中に、提供されるアクセス制御の粒度にも影響します。
If confidentiality 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 that are carrying traffic from many subscribers.
機密性が選択されている場合、2つのセキュリティゲートウェイの間のESP（トンネルモード）SAは、部分的なトラフィックフローの機密性を提供できます。トンネルモードを使用すると、内側のIPヘッダーを暗号化し、（究極の）トラフィックソースと宛先のアイデンティティを隠します。さらに、ESPペイロードパディングを呼び出してパケットのサイズを隠し、トラフィックの外部特性をさらに隠すこともできます。モバイルユーザーがダイヤルアップコンテキストで動的IPアドレスを割り当てられ、（トンネルモード）ESP SAを企業ファイアウォール（セキュリティゲートウェイとして機能する）に確立する場合、同様のトラフィックフローの機密性サービスが提供される場合があります。多くの加入者からトラフィックを運んでいる粗粒度のものよりも、微細顆粒性SASは一般に、トラフィック分析に対してより脆弱であることに注意してください。
Note: A compliant implementation MUST NOT allow instantiation of an ESP SA that employs both NULL encryption and no integrity algorithm. An attempt to negotiate such an SA is an auditable event by both initiator and responder. The audit log entry for this event SHOULD include the current date/time, local IKE IP address, and remote IKE IP address. The initiator SHOULD record the relevant SPD entry.
注：準拠した実装では、ヌル暗号化と整合性アルゴリズムの両方を使用するESP SAのインスタンス化を許可してはなりません。このようなSAを交渉しようとする試みは、イニシエーターとレスポンダーの両方が監査可能なイベントです。このイベントの監査ログエントリには、現在の日付/時間、ローカルIKE IPアドレス、およびリモートIKE IPアドレスを含める必要があります。イニシエーターは、関連するSPDエントリを記録する必要があります。
This document does not require support for nested security associations or for what RFC 2401 [RFC2401] called "SA bundles". These features still can be effected by appropriate configuration of both the SPD and the local forwarding functions (for inbound and outbound traffic), but this capability is outside of the IPsec module and thus the scope of this specification. As a result, management of nested/bundled SAs is potentially more complex and less assured than under the model implied by RFC 2401 [RFC2401]. An implementation that provides support for nested SAs SHOULD provide a management interface that enables a user or administrator to express the nesting requirement, and then create the appropriate SPD entries and forwarding table entries to effect the requisite processing. (See Appendix E for an example of how to configure nested SAs.)
このドキュメントでは、ネストされたセキュリティ協会、またはRFC 2401 [RFC2401]が「SAバンドル」と呼ぶものをサポートする必要はありません。これらの機能は、SPDとローカル転送機能（インバウンドトラフィックとアウトバウンドトラフィック用）の両方の適切な構成によって引き続き影響を受ける可能性がありますが、この機能はIPSECモジュールの外側、したがってこの仕様の範囲外です。その結果、ネストされた/バンドルされたSASの管理は、RFC 2401 [RFC2401]によって暗示されるモデルの下では、潜在的に複雑で保証されていません。ネストされたSASのサポートを提供する実装は、ユーザーまたは管理者がネスト要件を表現し、適切なSPDエントリと転送テーブルエントリを作成して必要な処理を実施できる管理インターフェイスを提供する必要があります。（ネストされたSASを構成する方法の例については、付録Eを参照してください。）
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 IPsec functionality, in support of these interoperability and functionality goals. The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant.
IPSEC実装でのIPトラフィックの処理に関連する詳細の多くは、主に局所的な問題であり、標準化の対象ではありません。ただし、相互運用性を確保し、IPSECの生産的な使用に不可欠な最小限の管理機能を提供するために、処理の一部の外部側面を標準化する必要があります。このセクションでは、これらの相互運用性と機能性の目標をサポートする、IPSEC機能に関連するIPトラフィックを処理するための一般的なモデルについて説明します。以下に説明するモデルは名目です。実装は、提示されたこのモデルの詳細と一致する必要はありませんが、実装の外部動作は、準拠するためにこのモデルの外部的に観察可能な特性に対応する必要があります。
There are three nominal databases in this model: the Security Policy Database (SPD), the Security Association Database (SAD), and the Peer Authorization Database (PAD). The first specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host or security gateway (Section 4.4.1). The second database contains parameters that are associated with each established (keyed) SA (Section 4.4.2). The third database, the PAD, provides a link between an SA management protocol (such as IKE) and the SPD (Section 4.4.3).
このモデルには、セキュリティポリシーデータベース（SPD）、セキュリティアソシエーションデータベース（SAD）、およびピア認証データベース（PAD）の3つの名目データベースがあります。最初のものは、ホストまたはセキュリティゲートウェイ（セクション4.4.1）からのすべてのIPトラフィックの処分を決定するポリシーを指定します。2番目のデータベースには、確立された各（キー付き）SA（セクション4.4.2）に関連付けられるパラメーターが含まれています。3番目のデータベースであるPADは、SA管理プロトコル（IKEなど）とSPD（セクション4.4.3）の間のリンクを提供します。
Multiple Separate IPsec Contexts
複数の個別のIPSECコンテキスト
If an IPsec implementation acts as a security gateway for multiple subscribers, it MAY implement multiple separate IPsec contexts. Each context MAY have and MAY use completely independent identities, policies, key management SAs, and/or IPsec SAs. This is for the most part a local implementation matter. However, a means for associating inbound (SA) proposals with local contexts is required. To this end, if supported by the key management protocol in use, context identifiers MAY be conveyed from initiator to responder in the signaling messages, with the result that IPsec SAs are created with a binding to a particular context. For example, a security gateway that provides VPN service to multiple customers will be able to associate each customer's traffic with the correct VPN.
IPSEC実装が複数のサブスクライバーのセキュリティゲートウェイとして機能する場合、複数の個別のIPSECコンテキストを実装する場合があります。各コンテキストは、完全に独立したアイデンティティ、ポリシー、主要な管理SAS、および/またはIPSEC SASを使用している場合があります。これは、ほとんどの場合、ローカル実装の問題です。ただし、インバウンド（SA）提案をローカルコンテキストに関連付ける手段が必要です。この目的のために、使用中の主要な管理プロトコルによってサポートされている場合、コンテキスト識別子がシグナリングメッセージのイニシエーターからレスポンダーに伝えられ、結果が特定のコンテキストへの拘束力で作成された結果です。たとえば、複数の顧客にVPNサービスを提供するセキュリティゲートウェイは、各顧客のトラフィックを正しいVPNに関連付けることができます。
Forwarding vs Security Decisions
セキュリティ決定とセキュリティの決定
The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented employs a sophisticated forwarding function. IPsec assumes only that outbound and inbound traffic that has passed through IPsec processing is forwarded in a fashion consistent with the context in which IPsec is implemented. Support for nested SAs is optional; if required, it requires coordination between forwarding tables and SPD entries to cause a packet to traverse the IPsec boundary more than once.
ここで説明するIPSECモデルは、IPSECが採用される可能性のある幅広いコンテキストに対応するために、転送（ルーティング）とセキュリティの決定の明確な分離を具体化します。転送は、2つのインターフェイスしかない場合、または複雑な場合、たとえばIPSECが実装されているコンテキストが洗練された転送機能を採用している場合に複雑な場合があります。IPSECは、IPSEC処理を通過したアウトバウンドトラフィックとインバウンドトラフィックが、IPSECが実装されるコンテキストと一致する方法で転送されることのみを想定しています。ネストされたSASのサポートはオプションです。必要に応じて、テーブルとSPDエントリの転送間の調整が必要になり、パケットがIPSEC境界を複数回回転させます。
"Local" vs "Remote"
「ローカル」対「リモート」
In this document, with respect to IP addresses and ports, the terms "Local" and "Remote" are used for policy rules. "Local" refers to the entity being protected by an IPsec implementation, i.e., the "source" address/port of outbound packets or the "destination" address/port of inbound packets. "Remote" refers to a peer entity or peer entities. The terms "source" and "destination" are used for packet header fields.
このドキュメントでは、IPアドレスとポートに関して、「ローカル」と「リモート」という用語がポリシールールに使用されます。「ローカル」とは、IPSECの実装によって保護されているエンティティ、つまり、アウトバウンドパケットの「ソース」アドレス/ポートまたはインバウンドパケットの「宛先」アドレス/ポートを指します。「リモート」とは、ピアエンティティまたはピアエンティティを指します。「ソース」と「宛先」という用語は、パケットヘッダーフィールドに使用されます。
"Non-initial" vs "Initial" Fragments
「非独創的」対 "初期"フラグメント
Throughout this document, the phrase "non-initial fragments" is used to mean fragments that do not contain all of the selector values that may be needed for access control (e.g., they might not contain Next Layer Protocol, source and destination ports, ICMP message type/code, Mobility Header type). And the phrase "initial fragment" is used to mean a fragment that contains all the selector values needed for access control. However, it should be noted that for IPv6, which fragment contains the Next Layer Protocol and ports (or ICMP message type/code or Mobility Header type [Mobip]) will depend on the kind and number of extension headers present. The "initial fragment" might not be the first fragment, in this context.
このドキュメント全体を通して、「非独創的なフラグメント」というフレーズは、アクセス制御に必要なすべてのセレクター値を含まないフラグメントを意味するために使用されます（たとえば、次のレイヤープロトコル、ソースおよび宛先ポート、ICMPが含まれない場合があります。メッセージタイプ/コード、モビリティヘッダータイプ）。「初期フラグメント」というフレーズは、アクセス制御に必要なすべてのセレクター値を含むフラグメントを意味するために使用されます。ただし、次のレイヤープロトコルとポート（またはICMPメッセージタイプ/コードまたはモビリティヘッダータイプ[MOBIP]）が次のレイヤープロトコルとポートを含むIPv6の場合、存在する拡張ヘッダーの種類と数に依存することに注意してください。この文脈では、「初期フラグメント」は最初の断片ではないかもしれません。
An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. 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 specifies minimum management functionality that must be provided, to allow a user or system administrator to control whether and how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE. An IPsec implementation MUST have at least one SPD, and it MAY support multiple SPDs, if appropriate for the context in which the IPsec implementation operates. There is no requirement to maintain SPDs on a per-interface basis, as was specified in RFC 2401 [RFC2401]. However, if an implementation supports multiple SPDs, then it MUST include an explicit SPD selection function that is invoked to select the appropriate SPD for outbound traffic processing. The inputs to this function are the outbound packet and any local metadata (e.g., the interface via which the packet arrived) required to effect the SPD selection function. The output of the function is an SPD identifier (SPD-ID).
SAは、IPSEC境界を通過するトラフィックのためのセキュリティポリシーを実施するために使用される管理構造です。したがって、SA処理の重要な要素は、IPデータグラムに提供されるサービスとどのような方法で提供されるかを指定する基礎となるセキュリティポリシーデータベース（SPD）です。データベースとそのインターフェイスの形式は、この仕様の範囲外です。ただし、このセクションでは、ユーザーまたはシステム管理者がホストが送信または受信したり、セキュリティゲートウェイを通過したりするトラフィックにIPSECを適用するかどうか、どのように適用されるかを制御できるようにするために、提供する必要がある最小管理機能を指定します。IPSECの境界を横断するIPSECによって保護されていないトラフィックを含む、すべてのトラフィック（インバウンドおよびアウトバウンド）の処理中にSPDまたは関連するキャッシュを参照する必要があります。これには、IKEなどのIPSEC管理トラフィックが含まれます。IPSECの実装には、少なくとも1つのSPDが必要であり、IPSEC実装が動作するコンテキストに適切な場合、複数のSPDをサポートする場合があります。RFC 2401 [RFC2401]で指定されたように、インターフェイスごとにSPDを維持する必要はありません。ただし、実装が複数のSPDをサポートする場合、アウトバウンドトラフィック処理に適切なSPDを選択するために呼び出される明示的なSPD選択関数を含める必要があります。この関数への入力は、Autboundパケットと、SPD選択関数を実施するために必要なローカルメタデータ（たとえば、パケットが到着したインターフェイス）です。関数の出力はSPD識別子（SPD-ID）です。
The SPD is an ordered database, consistent with the use of Access Control Lists (ACLs) or packet filters in firewalls, routers, etc. The ordering requirement arises because entries often will overlap due to the presence of (non-trivial) ranges as values for selectors. Thus, a user or administrator MUST be able to order the entries to express a desired access control policy. There is no way to impose a general, canonical order on SPD entries, because of the allowed use of wildcards for selector values and because the different types of selectors are not hierarchically related.
SPDは、ファイアウォール、ルーターなどでのアクセス制御リスト（ACLS）またはパケットフィルターの使用と一致する順序付けられたデータベースです。順序付け要件は、値として（非純粋な）範囲が存在するためにエントリが重複することが多いために発生します。セレクター用。したがって、ユーザーまたは管理者は、目的のアクセス制御ポリシーを表現するためにエントリを注文できる必要があります。セレクター値にワイルドカードを使用することが許可されているため、さまざまなタイプのセレクターが階層的に関連していないため、SPDエントリに一般的な標準的な順序を課す方法はありません。
Processing Choices: DISCARD, BYPASS, PROTECT
選択の処理：廃棄、バイパス、保護
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 PROTECT using IPsec. The first choice refers to traffic that is not allowed to traverse the IPsec boundary (in the specified direction). The second choice refers to traffic that is allowed to cross the IPsec boundary without IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security protocols to be employed, their mode, security service options, and the cryptographic algorithms to be used.
SPDは、IPSECの保護とトラフィックが提供されるトラフィックを区別し、IPSECをバイパスすることができます。これは、送信者によって適用されるIPSEC保護と、受信者に存在する必要があるIPSEC保護に適用されます。アウトバウンドまたはインバウンドデータグラムの場合、3つの処理の選択肢が可能です：廃棄、バイパスIPSEC、またはIPSECを使用して保護します。最初の選択は、IPSEC境界を通過することが許可されていないトラフィックを指します（指定された方向）。2番目の選択肢とは、IPSEC保護なしにIPSEC境界を通過できるトラフィックを指します。3番目の選択肢とは、IPSEC保護が提供されるトラフィックを指し、そのようなトラフィックのために、SPDは使用するセキュリティプロトコル、モード、セキュリティサービスオプション、および使用する暗号化アルゴリズムを指定する必要があります。
SPD-S, SPD-I, SPD-O
SPD-S、SPD-I、SPD-O
An SPD is logically divided into three pieces. The SPD-S (secure traffic) contains entries for all traffic subject to IPsec protection. SPD-O (outbound) contains entries for all outbound traffic that is to be bypassed or discarded. SPD-I (inbound) is applied to inbound traffic that will be bypassed or discarded. All three of these can be decorrelated (with the exception noted above for native host implementations) to facilitate caching. If an IPsec implementation supports only one SPD, then the SPD consists of all three parts. If multiple SPDs are supported, some of them may be partial, e.g., some SPDs might contain only SPD-I entries, to control inbound bypassed traffic on a per-interface basis. The split allows SPD-I to be consulted without having to consult SPD-S, for such traffic. Since the SPD-I is just a part of the SPD, if a packet that is looked up in the SPD-I cannot be matched to an entry there, then the packet MUST be discarded. Note that for outbound traffic, if a match is not found in SPD-S, then SPD-O must be checked to see if the traffic should be bypassed. Similarly, if SPD-O is checked first and no match is found, then SPD-S must be checked. In an ordered, non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there is one lookup in the SPD.
SPDは論理的に3つのピースに分割されます。SPD-S（セキュアトラフィック）には、IPSEC保護の対象となるすべてのトラフィックのエントリが含まれています。SPD-O（アウトバウンド）には、バイパスまたは破棄されるすべてのアウトバウンドトラフィックのエントリが含まれています。SPD-I（インバウンド）は、バイパスまたは破棄されるインバウンドトラフィックに適用されます。これらの3つはすべて、キャッシュを容易にするために（上記のネイティブホストの実装については上記の例外を除く）非相関することができます。IPSEC実装が1つのSPDのみをサポートする場合、SPDは3つの部分すべてで構成されます。複数のSPDがサポートされている場合、それらのいくつかは部分的である可能性があります。たとえば、一部のSPDには、インバウンドバイパスされたトラフィックがインターフェイスごとに制御するためにSPD-Iエントリのみを含む場合があります。分割により、SPD-Iに相談することなく、そのようなトラフィックについて相談することができます。SPD-IはSPDの一部にすぎないため、SPD-Iで調べられたパケットをそこのエントリに一致させることができない場合、パケットを破棄する必要があります。アウトバウンドトラフィックの場合、一致がSPD-Sで見つかっていない場合、SPD-Oをチェックしてトラフィックをバイパスする必要があるかどうかを確認する必要があることに注意してください。同様に、SPD-Oが最初にチェックされ、一致が見つからない場合は、SPD-Sをチェックする必要があります。順序付けられた、相関していないSPDでは、SPD-S、SPD-I、およびSPD-Oのエントリがインターリーブされます。したがって、SPDには1つのルックアップがあります。
SPD Entries
SPDエントリ
Each SPD entry specifies packet disposition as BYPASS, DISCARD, or PROTECT. The entry is keyed by a list of one or more selectors. The SPD contains an ordered list of these entries. The required selector types are defined in Section 4.4.1.1. These selectors are used to define the granularity of the SAs that are created in response to an outbound packet or in response to a proposal from a peer. The detailed structure of an SPD entry is described in Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that matches anything that is otherwise unmatched, and discards it.
各SPDエントリは、パケットの処分をバイパス、廃棄、または保護として指定します。エントリは、1つ以上のセレクターのリストによってキーが付けられています。SPDには、これらのエントリの順序付けられたリストが含まれています。必要なセレクタータイプは、セクション4.4.1.1で定義されています。これらのセレクターは、アウトバウンドパケットまたはピアからの提案に応じて作成されたSASの粒度を定義するために使用されます。SPDエントリの詳細な構造については、セクション4.4.1.2で説明しています。すべてのSPDには、それ以外の場合は比類のないものに一致する名目上の最終エントリが必要で、廃棄する必要があります。
The SPD MUST permit a user or administrator to specify policy entries as follows:
SPDは、ユーザーまたは管理者が次のようにポリシーエントリを指定することを許可する必要があります。
- SPD-I: For inbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded.
- SPD-I：バイパスまたは破棄されるインバウンドトラフィックの場合、エントリは、バイパスまたは破棄されるトラフィックに適用されるセレクターの値で構成されます。
- SPD-O: For outbound traffic that is to be bypassed or discarded, the entry consists of the values of the selectors that apply to the traffic to be bypassed or discarded.
- SPD-O：バイパスまたは破棄されるアウトバウンドトラフィックの場合、エントリは、バイパスまたは破棄されるトラフィックに適用されるセレクターの値で構成されます。
- SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic to be protected via AH or ESP, controls on how to create SAs based on these selectors, and the parameters needed to effect this protection (e.g., algorithms, modes, etc.). Note that an SPD-S entry also contains information such as "populate from packet" (PFP) flag (see paragraphs below on "How To Derive the Values for an SAD entry") and bits indicating whether the SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications).
- SPD-S：IPSECを使用して保護されるトラフィックの場合、エントリは、AHまたはESPを介して保護されるトラフィックに適用されるセレクターの値で構成され、これらのセレクターに基づいてSASを作成する方法とパラメーターを制御します。この保護を実施するために必要な（例：アルゴリズム、モードなど）。SPD-Sエントリには、「Packet From Packet」（PFP）フラグ（「悲しいエントリの値を導き出す方法」に関する段落を参照）や、SAルックアップがローカルを使用しているかどうかを示すビットなどの情報も含まれていることに注意してください。SPIに加えてリモートIPアドレス（AH [KEN05B]またはESP [KEN05A]仕様を参照）。
Representing Directionality in an SPD Entry
SPDエントリの方向性を表します
For traffic protected by IPsec, the Local and Remote address and ports in an SPD entry are swapped to represent directionality, consistent with IKE conventions. In general, the protocols that IPsec deals with have the property of requiring symmetric SAs with flipped Local/Remote IP addresses. However, for ICMP, there is often no such bi-directional authorization requirement. Nonetheless, for the sake of uniformity and simplicity, SPD entries for ICMP are specified in the same way as for other protocols. Note also that for ICMP, Mobility Header, and non-initial fragments, there are no port fields in these packets. ICMP has message type and code and Mobility Header has mobility header type. Thus, SPD entries have provisions for expressing access controls appropriate for these protocols, in lieu of the normal port field controls. For bypassed or discarded traffic, separate inbound and outbound entries are supported, e.g., to permit unidirectional flows if required.
IPSECによって保護されているトラフィックの場合、SPDエントリのローカルおよびリモートアドレスとポートは、IKE規則と一致する方向性を表すように交換されます。一般に、IPSECが扱うプロトコルには、ローカル/リモートIPアドレスが反転した対称SASが必要な特性があります。ただし、ICMPの場合、そのような双方向認証要件はしばしばありません。それにもかかわらず、均一性とシンプルさのために、ICMPのSPDエントリは、他のプロトコルと同じ方法で指定されています。また、ICMP、モビリティヘッダー、および非向性フラグメントの場合、これらのパケットにポートフィールドはないことに注意してください。ICMPにはメッセージタイプとコードがあり、モビリティヘッダーにはモビリティヘッダータイプがあります。したがって、SPDエントリには、通常のポートフィールドコントロールの代わりに、これらのプロトコルに適したアクセス制御を表現するための規定があります。バイパスまたは廃棄されたトラフィックの場合、必要に応じて単方向の流れを許可するために、個別のインバウンドおよびアウトバウンドエントリがサポートされます。
OPAQUE and ANY
不透明と任意
For each selector in an SPD entry, in addition to the literal values that define a match, there are two special values: ANY and OPAQUE. ANY is a wildcard that matches any value in the corresponding field of the packet, or that matches packets where that field is not present or is obscured. OPAQUE indicates that the corresponding selector field is not available for examination because it may not be present in a fragment, it does not exist for the given Next Layer Protocol, or prior application of IPsec may have encrypted the value. The ANY value encompasses the OPAQUE value. Thus, OPAQUE need be used only when it is necessary to distinguish between the case of any allowed value for a field, vs. the absence or unavailability (e.g., due to encryption) of the field.
一致を定義するリテラル値に加えて、SPDエントリ内の各セレクターについて、2つの特別な値があります。パケットの対応するフィールドの任意の値に一致するワイルドカード、またはそのフィールドが存在しないか、不明瞭なパケットに一致するワイルドカードです。Opaqueは、対応するセレクターフィールドがフラグメントに存在しない可能性があるため、検査に使用できないことを示しています。特定のレイヤープロトコルには存在しないか、IPSECの以前の適用が値を暗号化した可能性があります。任意の値には、不透明な値が含まれます。したがって、不透明は、フィールドの許可された値の場合を区別する必要がある場合にのみ使用する必要があります。
How to Derive the Values for an SAD Entry
悲しいエントリの値を導き出す方法
For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new SA Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry. For outbound traffic, there are SPD-S cache entries and SPD-O cache entries. For inbound traffic not protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (see Section 4.4.2). If IPsec processing is specified for an entry, a "populate from packet" (PFP) flag may be asserted for one or more of the selectors in the SPD entry (Local IP address; Remote IP address; Next Layer Protocol; and, depending on Next Layer Protocol, Local port and Remote port, or ICMP type/code, or Mobility Header type). If asserted for a given selector X, the flag indicates that the SA to be created should take its value for X from the value in the packet. Otherwise, the SA should take its value(s) for X from the value(s) in the SPD entry. Note: In the non-PFP case, the selector values negotiated by the SA management protocol (e.g., IKEv2) may be a subset of those in the SPD entry, depending on the SPD policy of the peer. Also, whether a single flag is used for, e.g., source port, ICMP type/code, and Mobility Header (MH) type, or a separate flag is used for each, is a local matter.
SPDエントリの各セレクターについて、エントリは、SPDおよびパケットのエントリからの新しいSAデータベース（SAD、セクション4.4.2を参照）の対応する値を導出する方法を指定します。目標は、パケットまたは一致するSPDエントリからの特定のセレクター値に基づいて、悲しいエントリとSPDキャッシュエントリを作成できるようにすることです。アウトバウンドトラフィックには、SPD-SキャッシュエントリとSPD-Oキャッシュエントリがあります。IPSECによって保護されていないインバウンドトラフィックの場合、SPD-Iキャッシュエントリがあり、インバウンドIPSECで保護されたトラフィックのキャッシュを表すSADがあります（セクション4.4.2を参照）。IPSEC処理がエントリに指定されている場合、SPDエントリの1つ以上のセレクター（ローカルIPアドレス、リモートIPアドレス、次のレイヤープロトコル;および、およびに応じて、「パケットからの入力」（PFP）フラグが「パケットから入力」（PFP）フラグを主張することができます。次のレイヤープロトコル、ローカルポートおよびリモートポート、またはICMPタイプ/コード、またはモビリティヘッダータイプ）。特定のセレクターXに対して主張された場合、フラグは、作成されるSAがパケット内の値からXの値を取得する必要があることを示しています。それ以外の場合、SAはSPDエントリの値からXの値を取得する必要があります。注：非PFPの場合、SAマネジメントプロトコル（例えば、IKEV2）によってネゴシエートされたセレクター値は、ピアのSPDポリシーに応じて、SPDエントリのサブセットのサブセットである可能性があります。また、ソースポート、ICMPタイプ/コード、モビリティヘッダー（MH）タイプなど、単一のフラグが使用されるかどうか、またはそれぞれに別のフラグが使用されるかどうかは、ローカルの問題です。
The following example illustrates the use of the PFP flag in the context of a security gateway or a BITS/BITW implementation. Consider an SPD entry where the allowed value for Remote address is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an outbound packet arrives with a destination address of 192.0.2.3, and there is no extant SA to carry this packet. The value used for the SA created to transmit this packet could be either of the two values shown below, depending on what the SPD entry for this selector says is the source of the selector value:
次の例は、セキュリティゲートウェイまたはBITS/BITWの実装のコンテキストでのPFPフラグの使用を示しています。リモートアドレスの許可値がIPv4アドレスの範囲であるSPDエントリを考えてみましょう：192.0.2.1〜192.0.2.10。192.0.2.3の宛先アドレスでアウトバウンドパケットが到着し、このパケットを運ぶ現存するSAがないと仮定します。このパケットを送信するために作成されたSAに使用される値は、このセレクターのSPDエントリがセレクター値のソースであると言っていることに応じて、以下に示す2つの値のいずれかのいずれかです。
PFP flag value example of new
for the Remote SAD dest. address
addr. selector selector value
--------------- ------------
a. PFP TRUE 192.0.2.3 (one host)
b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
Note that if the SPD entry above had a value of ANY for the Remote address, then the SAD selector value would have to be ANY for case (b), but would still be as illustrated for case (a). Thus, the PFP flag can be used to prohibit sharing of an SA, even among packets that match the same SPD entry.
上記のSPDエントリにリモートアドレスに対して値がある場合、SADセレクター値はケース（b）に対して任意のものでなければなりませんが、ケース（a）の場合は依然として説明されています。したがって、PFPフラグを使用して、同じSPDエントリに一致するパケット間でも、SAの共有を禁止できます。
Management Interface
管理インターフェイス
For every IPsec implementation, there MUST be a management interface that allows a user or system administrator to manage the SPD. The interface must allow the user (or administrator) to specify the security processing to be applied to every packet that traverses the IPsec boundary. (In a native host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per-packet basis, as noted at the end of Section 4.4.1.1 and in Section 5.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.1.1, and MUST support (total) ordering of these entries, as seen via this interface. The SPD entries' selectors are analogous to the ACL or packet filters commonly found in a stateless firewall or packet filtering router and which are currently managed this way.
すべてのIPSEC実装について、ユーザーまたはシステム管理者がSPDを管理できるようにする管理インターフェイスが必要です。インターフェイスにより、ユーザー（または管理者）が、IPSEC境界を通過するすべてのパケットに適用されるセキュリティ処理を指定する必要があります。（セクション4.4.1.1の最後とセクション5に記載されているように、SPDは、ソケットインターフェイスを使用して、SPDをパケットごとに参照する必要がない場合があります。）SPDは、セクション4.4.1.1で定義されているセレクターと一致するエントリの作成を許可する必要があり、このインターフェイスを介して見られるように、これらのエントリの（合計）順序をサポートする必要があります。SPDエントリのセレクターは、ステートレスファイアウォールまたはパケットフィルタリングルーターによく見られるACLまたはパケットフィルターに類似しており、現在この方法で管理されています。
In host systems, applications MAY be allowed to create SPD entries. (The means of signaling 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. 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.
ホストシステムでは、アプリケーションがSPDエントリを作成できる場合があります。（IPSECの実装にそのような要求を合図する手段は、この標準の範囲外です。）ただし、システム管理者は、ユーザーまたはアプリケーションがシステムポリシーをオーバーライドできるかどうかを指定できる必要があります。管理インターフェイスの形式はこのドキュメントで指定されておらず、ホストとセキュリティゲートウェイで異なる場合があり、ホスト内では、ソケットベースの実装とBITS実装でインターフェイスが異なる場合があります。ただし、このドキュメントでは、すべてのIPSEC実装がサポートする必要があるSPD要素の標準セットを指定しています。
Decorrelation
非相関
The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching, which enables more efficient processing of outbound traffic in security gateways and BITS/BITW implementations. Decorrelation [CoSa04] is only a means of improving performance and simplifying the processing description. This RFC does not require a compliant implementation to make use of decorrelation. For example, native host implementations typically make use of caching implicitly because they bind SAs to socket interfaces, and thus there is no requirement to be able to decorrelate SPD entries in these implementations.
このドキュメントで説明されている処理モデルは、セキュリティゲートウェイとBITS/BITWの実装でのアウトバウンドトラフィックのより効率的な処理を可能にするキャッシュを可能にするために、重複するSPDエントリを切り替える能力を想定しています。分離[COSA04]は、パフォーマンスを改善し、処理の説明を簡素化する手段にすぎません。このRFCは、非相関を利用するために準拠した実装を必要としません。たとえば、ネイティブのホストの実装は通常、SASをソケットインターフェイスに結合するため、暗黙的にキャッシュを使用します。したがって、これらの実装でSPDエントリを切り離すことができるための要件はありません。
Note: Unless otherwise qualified, the use of "SPD" refers to the body of policy information in both ordered or decorrelated (unordered) state. Appendix B provides an algorithm that can be used to decorrelate SPD entries, but any algorithm that produces equivalent output may be used. Note that when an SPD entry is decorrelated all the resulting entries MUST be linked together, so that all members of the group derived from an individual, SPD entry (prior to decorrelation) can all be placed into caches and into the SAD at the same time. For example, suppose one starts with an entry A (from an ordered SPD) that when decorrelated, yields entries A1, A2, and A3. When a packet comes along that matches, say A2, and triggers the creation of an SA, the SA management protocol (e.g., IKEv2) negotiates A. And all 3 decorrelated entries, A1, A2, and A3, are placed in the appropriate SPD-S cache and linked to the SA. The intent is that use of a decorrelated SPD ought not to create more SAs than would have resulted from use of a not-decorrelated SPD.
注：特に適格でない限り、「SPD」の使用とは、順序付けられた（順序付けられていない）状態の両方のポリシー情報の本体を指します。付録Bには、SPDエントリを切り離すために使用できるアルゴリズムを提供しますが、同等の出力を生成するアルゴリズムは任意のアルゴリズムを使用できます。SPDエントリが非相関がある場合、結果のすべてのエントリをリンクする必要があるため、個人から派生したグループのすべてのメンバーがすべて（非相関の前）をすべてキャッシュに入れてSADに配置できるようにすることに注意してください。。たとえば、1つが、逆相関すると、エントリA1、A2、およびA3が生成されるエントリA（順序付けられたSPDから）から始まるとします。それが一致するパケットが登場すると、A2とSAの作成をトリガーし、SA管理プロトコル（IKEV2）がAを交渉し、3つの逆相関エントリすべて、A1、A2、およびA3が適切なSPDに配置されます。-SキャッシュとSAにリンクします。意図は、切り離されたSPDの使用は、相関していないSPDの使用に起因するよりも多くのSASを作成するべきではないということです。
If a decorrelated SPD is employed, there are three options for what an initiator sends to a peer via an SA management protocol (e.g., IKE). By sending the complete set of linked, decorrelated entries that were selected from the SPD, a peer is given the best possible information to enable selection of the appropriate SPD entry at its end, especially if the peer has also decorrelated its SPD. However, if a large number of decorrelated entries are linked, this may create large packets for SA negotiation, and hence fragmentation problems for the SA management protocol.
非相関SPDが採用されている場合、SA管理プロトコル（IKEなど）を介してイニシエーターがピアに送信するものには3つのオプションがあります。SPDから選択されたリンクされた、切り離されたエントリの完全なセットを送信することにより、特にピアがSPDを非相関させた場合、適切なSPDエントリの選択を可能にするために、ピアに可能な限り最良の情報が与えられます。ただし、多数の非相関エントリがリンクされている場合、これによりSAネゴシエーションのための大きなパケットが作成される可能性があり、したがってSA管理プロトコルの断片化の問題が発生する可能性があります。
Alternatively, the original entry from the (correlated) SPD may be retained and passed to the SA management protocol. Passing the correlated SPD entry keeps the use of a decorrelated SPD a local matter, not visible to peers, and avoids possible fragmentation concerns, although it provides less precise information to a responder for matching against the responder's SPD.
あるいは、（相関）SPDからの元のエントリを保持し、SA管理プロトコルに渡すことができます。相関のSPDエントリを渡すと、非相関SPDがピアに表示されない局所的な問題を使用し、可能性のある断片化の懸念を回避します。
An intermediate approach is to send a subset of the complete set of linked, decorrelated SPD entries. This approach can avoid the fragmentation problems cited above yet provide better information than the original, correlated entry. The major shortcoming of this approach is that it may cause additional SAs to be created later, since only a subset of the linked, decorrelated entries are sent to a peer. Implementers are free to employ any of the approaches cited above.
中間的なアプローチは、リンクされた、逆相関SPDエントリの完全なセットのサブセットを送信することです。このアプローチは、上記の断片化の問題を回避できますが、元の相関エントリよりも優れた情報を提供します。このアプローチの主要な欠点は、リンクされた逆相関エントリのサブセットのみがピアに送信されるため、追加のSASが後で作成される可能性があることです。実装者は、上記のアプローチのいずれかを自由に使用できます。
A responder uses the traffic selector proposals it receives via an SA management protocol to select an appropriate entry in its SPD. The intent of the matching is to select an SPD entry and create an SA that most closely matches the intent of the initiator, so that traffic traversing the resulting SA will be accepted at both ends. If the responder employs a decorrelated SPD, it SHOULD use the decorrelated SPD entries for matching, as this will generally result in creation of SAs that are more likely to match the intent of both peers. If the responder has a correlated SPD, then it SHOULD match the proposals against the correlated entries. For IKEv2, use of a decorrelated SPD offers the best opportunity for a responder to generate a "narrowed" response.
レスポンダーは、SA管理プロトコルを介して受け取るトラフィックセレクターの提案を使用して、SPDの適切なエントリを選択します。マッチングの意図は、SPDエントリを選択し、イニシエーターの意図に最も密接に一致するSAを作成し、結果として生じるSAを横切るトラフィックが両端で受け入れられるようにすることです。レスポンダーが非相関SPDを採用している場合、一致するために非相関SPDエントリを使用する必要があります。これにより、これは一般に、両方のピアの意図と一致する可能性が高いSASが作成されるためです。レスポンダーに相関のSPDがある場合、提案を相関エントリと一致させる必要があります。IKEV2の場合、非相関SPDの使用は、レスポンダーが「狭くなった」応答を生成するための最良の機会を提供します。
In all cases, when a decorrelated SPD is available, the decorrelated entries are used to populate the SPD-S cache. If the SPD is not decorrelated, caching is not allowed and an ordered search of SPD MUST be performed to verify that inbound traffic arriving on an SA is consistent with the access control policy expressed in the SPD.
すべての場合において、非相関SPDが利用可能な場合、decorarederalatedエントリを使用してSPD-Sキャッシュを入力します。SPDが否認されていない場合、キャッシュは許可されておらず、SAに到着するインバウンドトラフィックがSPDで表現されたアクセス制御ポリシーと一致することを確認するために、SPDの順序付けられた検索を実行する必要があります。
Handling Changes to the SPD While the System Is Running
システムが実行されている間にSPDに変更を処理する
If a change is made to the SPD while the system is running, a check SHOULD be made of the effect of this change on extant SAs. An implementation SHOULD check the impact of an SPD change on extant SAs and SHOULD provide a user/administrator with a mechanism for configuring what actions to take, e.g., delete an affected SA, allow an affected SA to continue unchanged, etc.
システムが実行されている間にSPDに変更が加えられた場合、現存するSASに対するこの変更の影響についてチェックする必要があります。実装では、現存するSASに対するSPDの変更の影響を確認し、ユーザー/管理者に実行するアクションを構成するメカニズムを提供する必要があります。
An SA 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 Layer Protocol and related fields, e.g., ports), 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 by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types. Also, note that the Local/Remote port selectors (and ICMP message type and code, and Mobility Header type) may be labeled as OPAQUE to accommodate situations where these fields are inaccessible due to packet fragmentation.
SAは、SAのトラフィックのセットを定義するために使用されるセレクターに応じて、細粒または粗粒である場合があります。たとえば、2つのホスト間のすべてのトラフィックは、単一のSAを介して運ばれ、セキュリティサービスの均一なセットを提供できます。あるいは、使用中のアプリケーション（次のレイヤープロトコルおよび関連フィールドなどで定義されているように）に応じて、さまざまなSASが提供するアプリケーション（次のレイヤープロトコルおよび関連フィールドで定義されているように）に応じて、複数のSASに分散する場合があります。同様に、セキュリティゲートウェイのペア間のすべてのトラフィックは、単一のSAで携帯することができます。または、通信ホストペアごとに1つのSAを割り当てることができます。次のセレクターパラメーターは、SA粒度の制御を容易にするために、すべてのIPSEC実装によってサポートする必要があります。ローカルアドレスとリモートアドレスの両方がIPv4またはIPv6のいずれかである必要があるが、アドレスタイプの組み合わせではないことに注意してください。また、ローカル/リモートポートセレクター（およびICMPメッセージタイプとコード、およびモビリティヘッダータイプ）は、パケットの断片化によりこれらのフィールドがアクセスできない状況に対応するために不透明としてラベル付けされる場合があることに注意してください。
- Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to support more than one remote system sharing the same SA, e.g., behind a security gateway.
- リモートIPアドレス（ES）（IPv4またはIPv6）：これは、IPアドレスの範囲のリストです（Unicast、Broadcast（IPv4のみ））。この構造により、単一のIPアドレス（些細な範囲を介して）、アドレスのリスト（それぞれ些細な範囲）、または一連のアドレス（低値と高値、包括的）、および最も一般的な形式の表現が可能になります。範囲のリスト。アドレス範囲は、セキュリティゲートウェイの背後にある同じSAを共有する複数のリモートシステムをサポートするために使用されます。
- Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of IP addresses (unicast, broadcast (IPv4 only)). This structure allows expression of a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses (low and high values, inclusive), as well as the most generic form of a list of ranges. Address ranges are used to support more than one source system sharing the same SA, e.g., behind a security gateway. Local refers to the address(es) being protected by this implementation (or policy entry).
- ローカルIPアドレス（ES）（IPv4またはIPv6）：これは、IPアドレスの範囲のリストです（Unicast、Broadcast（IPv4のみ））。この構造により、単一のIPアドレス（些細な範囲を介して）、アドレスのリスト（それぞれ些細な範囲）、または一連のアドレス（低値と高値、包括的）、および最も一般的な形式の表現が可能になります。範囲のリスト。アドレス範囲は、セキュリティゲートウェイの背後にある同じSAを共有する複数のソースシステムをサポートするために使用されます。ローカルは、この実装（またはポリシーエントリ）によって保護されている住所を指します。
Note: The SPD does not include support for multicast address entries. To support multicast SAs, an implementation should make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries require a different structure, i.e., one cannot use the symmetric relationship associated with local and remote address values for unicast SAs in a multicast context. Specifically, outbound traffic directed to a multicast address on an SA would not be received on a companion, inbound SA with the multicast address as the source.
注：SPDには、マルチキャストアドレスエントリのサポートは含まれていません。マルチキャストSASをサポートするには、[RFC3740]で定義されているように、実装がグループSPD（GSPD）を使用する必要があります。GSPDエントリには異なる構造が必要です。つまり、マルチキャストコンテキストでユニキャストSASのローカルおよびリモートアドレス値に関連する対称関係を使用することはできません。具体的には、SAのマルチキャストアドレスに向けられたアウトバウンドトラフィックは、ソースとしてマルチキャストアドレスを備えたコンパニオン、インバウンドSAで受信されません。
- Next Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This is an individual protocol number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol is whatever comes after any IP extension headers that are present. To simplify locating the Next Layer Protocol, there SHOULD be a mechanism for configuring which IPv6 extension headers to skip. The default configuration for which protocols to skip SHOULD include the following protocols: 0 (Hop-by-hop options), 43 (Routing Header), 44 (Fragmentation Header), and 60 (Destination Options). Note: The default list does NOT include 51 (AH) or 50 (ESP). From a selector lookup point of view, IPsec treats AH and ESP as Next Layer Protocols.
- 次のレイヤープロトコル：IPv4 "プロトコル"またはIPv6 "次のヘッダー"フィールドから取得しました。これは、個々のプロトコル番号、またはIPv6のみの場合、不透明です。次のレイヤープロトコルは、存在するIP拡張ヘッダーの後に来るものです。次のレイヤープロトコルの検索を簡素化するには、スキップするIPv6拡張ヘッダーを構成するメカニズムがあるはずです。スキップするプロトコルのデフォルト構成には、次のプロトコルを含める必要があります：0（ホップバイホップオプション）、43（ルーティングヘッダー）、44（フラグメンテーションヘッダー）、および60（宛先オプション）。注：デフォルトリストには、51（AH）または50（ESP）は含まれません。Selector Lookupの観点から、IPSECはAHとESPを次のレイヤープロトコルとして扱います。
Several additional selectors depend on the Next Layer Protocol value:
いくつかの追加のセレクターは、次のレイヤープロトコル値に依存します。
* If the Next Layer Protocol uses two ports (as do TCP, UDP, SCTP, and others), then there are selectors for Local and Remote Ports. Each of these selectors has a list of ranges of values. Note that the Local and Remote ports may not be available in the case of receipt of a fragmented packet or if the port fields have been protected by IPsec (encrypted); thus, a value of OPAQUE also MUST be supported. Note: In a non-initial fragment, port values will not be available. If a port selector specifies a value other than ANY or OPAQUE, it cannot match packets that are non-initial fragments. If the SA requires a port value other than ANY or OPAQUE, an arriving fragment without ports MUST be discarded. (See Section 7, "Handling Fragments".)
* 次のレイヤープロトコルが2つのポート（TCP、UDP、SCTPなどと同様）を使用する場合、ローカルポートとリモートポート用のセレクターがあります。これらのセレクターのそれぞれには、値の範囲のリストがあります。断片化されたパケットの受領の場合、またはポートフィールドがIPSEC（暗号化）によって保護されている場合、ローカルポートとリモートポートは利用できない場合があることに注意してください。したがって、不透明の値もサポートする必要があります。注：非独創的なフラグメントでは、ポート値は利用できません。ポートセレクターがどの値または不透明以外の値を指定している場合、非独創的なフラグメントであるパケットと一致することはできません。SAがどのポート値または不透明以外のポート値を必要とする場合、ポートのない到着するフラグメントを破棄する必要があります。（セクション7、「断片の取り扱い」を参照してください。）
* If the Next Layer Protocol is a Mobility Header, then there is a selector for IPv6 Mobility Header message type (MH type) [Mobip]. This is an 8-bit value that identifies a particular mobility message. Note that the MH type may not be available in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".) For IKE, the IPv6 Mobility Header message type (MH type) is placed in the most significant eight bits of the 16-bit local "port" selector.
* 次のレイヤープロトコルがモビリティヘッダーである場合、IPv6モビリティヘッダーメッセージタイプ（MHタイプ）[MOBIP]のセレクターがあります。これは、特定のモビリティメッセージを識別する8ビット値です。断片化されたパケットを受け取った場合、MHタイプは利用できない場合があることに注意してください。（セクション7、「断片の取り扱い」を参照してください。）IKEの場合、IPv6モビリティヘッダーメッセージタイプ（MHタイプ）は、16ビットローカル「ポート」セレクターの最も重要な8ビットに配置されます。
* If the Next Layer Protocol value is ICMP, then there is a 16-bit selector for the ICMP message type and code. The message type is a single 8-bit value, which defines the type of an ICMP message, or ANY. The ICMP code is a single 8-bit value that defines a specific subtype for an ICMP message. For IKE, the message type is placed in the most significant 8 bits of the 16-bit selector and the code is placed in the least significant 8 bits. This 16-bit selector can contain a single type and a range of codes, a single type and ANY code, and ANY type and ANY code. Given a policy entry with a range of Types (T-start to T-end) and a range of Codes (C-start to C-end), and an ICMP packet with Type t and Code c, an implementation MUST test for a match using
* 次のレイヤープロトコル値がICMPの場合、ICMPメッセージタイプとコードに16ビットセレクターがあります。メッセージタイプは、ICMPメッセージのタイプなどを定義する単一の8ビット値です。ICMPコードは、ICMPメッセージの特定のサブタイプを定義する単一の8ビット値です。IKEの場合、メッセージタイプは16ビットセレクターの最も重要な8ビットに配置され、コードは最も重要な8ビットに配置されます。この16ビットセレクターには、単一のタイプと範囲のコード、単一のタイプと任意のコード、および任意のタイプと任意のコードを含めることができます。さまざまなタイプ（T-スタートからT延長）とさまざまなコード（C-スタートからCエンド）のポリシーエントリ、およびタイプTとコードCのICMPパケットが与えられた場合、実装はテストする必要があります。使用して一致します
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
C-end
Note that the ICMP message type and code may not be available in the case of receipt of a fragmented packet. (See Section 7, "Handling Fragments".)
断片化されたパケットを受け取った場合、ICMPメッセージタイプとコードは利用できない場合があることに注意してください。（セクション7、「断片の取り扱い」を参照してください。）
- Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways:
- 名前：これは、上記の他の人のようなセレクターではありません。パケットから取得されません。名前は、IPSECローカルまたはリモートアドレスのシンボリック識別子として使用できます。名前付きSPDエントリは2つの方法で使用されます。
1. A named SPD entry is used by a responder (not an initiator) in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for "road warriors". The name used to match this field is communicated during the IKE negotiation in the ID payload. In this context, the initiator's Source IP address (inner IP header in tunnel mode) is bound to the Remote IP address in the SAD entry created by the IKE negotiation. This address overrides the Remote IP address value in the SPD, when the SPD entry is selected in this fashion. All IPsec implementations MUST support this use of names.
1. 名前付きSPDエントリは、リモートIPアドレスセレクター、たとえば「ロードウォリアーズ」にIPアドレスが適切でない場合に、アクセス制御をサポートするためにレスポンダー（イニシエーターではない）によって使用されます。このフィールドに一致するために使用される名前は、IDペイロードのIKE交渉中に伝えられます。これに関連して、イニシエーターのソースIPアドレス（トンネルモードの内部IPヘッダー）は、IKEネゴシエーションによって作成されたSADエントリのリモートIPアドレスにバインドされます。このアドレスは、SPDエントリがこの方法で選択されている場合、SPDのリモートIPアドレス値をオーバーライドします。すべてのIPSEC実装は、この名前の使用をサポートする必要があります。
2. A named SPD entry may be used by an initiator to identify a user for whom an IPsec SA will be created (or for whom traffic may be bypassed). The initiator's IP source address (from inner IP header in tunnel mode) is used to replace the following if and when they are created:
2. 名前付きSPDエントリは、IPSEC SAが作成される（またはトラフィックがバイパスされる可能性がある）ユーザーを識別するために、イニシエーターによって使用される場合があります。イニシエーターのIPソースアドレス（トンネルモードの内側のIPヘッダーから）を使用して、作成された場合と次の場合を交換します。
- local address in the SPD cache entry - local address in the outbound SAD entry - remote address in the inbound SAD entry
- SPDキャッシュエントリのローカルアドレス - アウトバウンドの悲しいエントリのローカルアドレス - インバウンドの悲しいエントリのリモートアドレス
Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below).
この使用のサポートは、マルチユーザー、ネイティブホストの実装ではオプションであり、他の実装には適用されません。この名前はローカルでのみ使用されることに注意してください。主要な管理プロトコルによっては通信されません。また、上記のケース1（レスポンダー）に使用されるもの以外の名前の形式は、イニシエーターのコンテキストに適用されます（以下を参照）。
An SPD entry can contain both a name (or a list of names) and also values for the Local or Remote IP address.
SPDエントリには、名前（または名前のリスト）とローカルまたはリモートのIPアドレスの値の両方を含めることができます。
For case 1, responder, the identifiers employed in named SPD entries are one of the following four types:
ケース1のレスポンダーの場合、名前付きSPDエントリで採用されている識別子は、次の4つのタイプの1つです。
a. a fully qualified user name string (email), e.g., mozart@foo.example.com (this corresponds to ID_RFC822_ADDR in IKEv2)
a. 完全に適格なユーザー名文字列（電子メール）、例えばmozart@foo.example.com（これはIKEV2のID_RFC822_ADDRに対応）
b. a fully qualified DNS name, e.g., foo.example.com (this corresponds to ID_FQDN in IKEv2)
b. 完全に資格のあるDNS名、たとえば、foo.example.com（これはIKEV2のID_FQDNに対応）
c. X.500 distinguished name, e.g., [WaKiHo97], CN = Stephen T. Kent, O = BBN Technologies, SP = MA, C = US (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding)
c. X.500著名な名前、例えば[wakiho97]、cn = stephen T. kent、o = bbnテクノロジー、sp = ma、c = us（これは、解読後、ikev2のid_der_asn1_dnに対応します）
d. a byte string (this corresponds to Key_ID in IKEv2)
d. バイト文字列（これはikev2のkey_idに対応します）
For case 2, initiator, the identifiers employed in named SPD entries are of type byte string. They are likely to be Unix UIDs, Windows security IDs, or something similar, but could also be a user name or account name. In all cases, this identifier is only of local concern and is not transmitted.
ケース2のイニシエーターの場合、名前付きSPDエントリで採用されている識別子はタイプバイト文字列です。それらは、UNIX UID、WindowsセキュリティID、または同様のものである可能性がありますが、ユーザー名またはアカウント名でもある可能性があります。すべての場合において、この識別子は現地の懸念のみであり、送信されません。
The IPsec implementation context determines how selectors are used. For example, a native host implementation typically makes use of a socket interface. When a new connection is established, the SPD can be consulted and an SA bound to the socket. Thus, traffic sent via that socket need not result in additional lookups to the SPD (SPD-O and SPD-S) cache. In contrast, a BITS, BITW, or security gateway implementation needs to look at each packet and perform an SPD-O/SPD-S cache lookup based on the selectors.
IPSEC実装コンテキストは、セレクターの使用方法を決定します。たとえば、ネイティブホストの実装は通常、ソケットインターフェイスを使用します。新しい接続が確立されると、SPDに相談し、SAをソケットにバインドできます。したがって、そのソケットを介して送信されるトラフィックは、SPD（SPD-OおよびSPD-S）キャッシュを追加の検索につながる必要はありません。対照的に、BITS、BITW、またはセキュリティゲートウェイの実装は、各パケットを調べて、セレクターに基づいてSPD-O/SPD-Sキャッシュルックアップを実行する必要があります。
This section contains a prose description of an SPD entry. Also, Appendix C provides an example of an ASN.1 definition of an SPD entry.
このセクションには、SPDエントリの散文説明が含まれています。また、付録Cは、SPDエントリのASN.1定義の例を示しています。
This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKEv2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKEv2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKEv2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics.
このテキストは、SPDのペイロードに直接マッピングすることを目的とした方法でSPDを説明し、SPDエントリに必要なポリシーをIKEを通じて交渉できるようにします。残念ながら、IKEV2のバージョンのセマンティクスは、このドキュメント[kau05]と同時に公開されています。具体的には、IKEV2は、ローカルおよびリモートアドレスとポートの複数のペアを単一のSAに結合する単一のSAの交渉を有効にしません。代わりに、複数のローカルアドレスとリモートアドレスとポートがSAのためにネゴシエートされると、IKEV2はこれらをペアとしてではなく、（順序付けられていない）ローカルおよびリモート値のセットとして任意にペアにすることができます。IKEは、セレクターセットを介してSPDで表現されるセマンティクスを伝える施設を提供するまで（以下に説明するように）、アクセス制御の意図がIKE「ミックスアンドマッチ」と一致しない限り、単一のSPDエントリに複数のセレクターセットを含めてはなりません。セマンティクス。実装は、ユーザーが複数のセレクターセットを使用してSPDエントリを作成する場合、ユーザーにこの問題を警告するように警告する場合があります。その構文は、現在のIKEセマンティクスとの競合の可能性を示します。
The management GUI can offer the user other forms of data entry and display, e.g., the option of using address prefixes as well as ranges, and symbolic names for protocols, ports, etc. (Do not confuse the use of symbolic names in a management interface with the SPD selector "Name".) Note that Remote/Local apply only to IP addresses and ports, not to ICMP message type/code or Mobility Header type. Also, if the reserved, symbolic selector value OPAQUE or ANY is employed for a given selector type, only that value may appear in the list for that selector, and it must appear only once in the list for that selector. Note that ANY and OPAQUE are local syntax conventions -- IKEv2 negotiates these values via the ranges indicated below:
管理GUIは、ユーザーに他の形式のデータ入力と表示を提供できます。たとえば、アドレスプレフィックスと範囲、プロトコル、ポートなどのシンボリック名を使用するオプション（管理者でのシンボリック名の使用を混同しないでください。SPDセレクター「名前」とのインターフェース。）リモート/ローカルは、ICMPメッセージタイプ/コードまたはモビリティヘッダータイプではなく、IPアドレスとポートにのみ適用されることに注意してください。また、予約済みのシンボリックセレクター値不透明または特定のセレクタータイプに採用されている場合、その値のみがそのセレクターのリストに表示される場合があり、そのセレクターのリストに1回だけ表示される必要があります。いずれかと不透明はローカル構文規則であることに注意してください-IKEV2は、以下に示す範囲を介してこれらの値を交渉します。
ANY: start = 0 end = <max>
OPAQUE: start = <max> end = 0
An SPD is an ordered list of entries each of which contains the following fields.
SPDは、それぞれに次のフィールドが含まれているエントリの順序付けられたリストです。
o Name -- a list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name".
o 名前 - IDのリスト。この準セレクターはオプションです。サポートする必要があるフォームは、上記のセクション4.4.1.1「名前」の下で説明します。
o PFP flags -- one per traffic selector. A given flag, e.g., for Next Layer Protocol, applies to the relevant selector across all "selector sets" (see below) contained in an SPD entry. When creating an SA, each flag specifies for the corresponding traffic selector whether to instantiate the selector from the corresponding field in the packet that triggered the creation of the SA or from the value(s) in the corresponding SPD entry (see Section 4.4.1, "How to Derive the Values for an SAD Entry"). Whether a single flag is used for, e.g., source port, ICMP type/code, and MH type, or a separate flag is used for each, is a local matter. There are PFP flags for: - Local Address - Remote Address - Next Layer Protocol - Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) - Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
o PFPフラグ - トラフィックセレクターごとに1つ。特定のフラグ、たとえば、次のレイヤープロトコルの場合、SPDエントリに含まれるすべての「セレクターセット」（以下を参照）にわたって関連するセレクターに適用されます。SAを作成するとき、各フラグは、対応するトラフィックセレクターに、SAの作成をトリガーしたパケットの対応するフィールドまたは対応するSPDエントリの値からインスタンス化するかどうかを指定します（セクション4.4.1を参照してください。、「悲しいエントリの価値を導き出す方法」）。たとえば、ソースポート、ICMPタイプ/コード、MHタイプなどに単一のフラグが使用されるか、それぞれに別のフラグが使用されるかは、ローカルの問題です。次のPFPフラグがあります。-ローカルアドレス - リモートアドレス - 次のレイヤープロトコル - ローカルポート、またはICMPメッセージタイプ/コードまたはモビリティヘッダータイプ（次のレイヤープロトコルに依存） - リモートポート、またはICMPメッセージタイプ/コードまたはモビリティヘッダータイプ（次のレイヤープロトコルに応じて）
o One to N selector sets that correspond to the "condition" for applying a particular IPsec action. Each selector set contains: - Local Address - Remote Address - Next Layer Protocol - Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) - Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol)
o 特定のIPSECアクションを適用するための「条件」に対応する1つのnセレクターセット。各セレクターセットには以下が含まれます。-ローカルアドレス - リモートアドレス - 次のレイヤープロトコル - ローカルポートまたはICMPメッセージタイプ/コードまたはモビリティヘッダータイプ（次のレイヤープロトコルに依存） - リモートポート、またはICMPメッセージタイプ/コードまたはモビリティヘッダータイプ（次のレイヤープロトコルに応じて）
Note: The "next protocol" selector is an individual value (unlike the local and remote IP addresses) in a selector set entry. This is consistent with how IKEv2 negotiates the Traffic Selector (TS) values for an SA. It also makes sense because one may need to associate different port fields with different protocols. It is possible to associate multiple protocols (and ports) with a single SA by specifying multiple selector sets for that SA.
注：「次のプロトコル」セレクターは、セレクターセットエントリの個々の値（ローカルおよびリモートIPアドレスとは異なり）です。これは、IKEV2がSAのトラフィックセレクター（TS）値をどのように交渉するかと一致しています。また、異なるポートフィールドを異なるプロトコルに関連付ける必要がある可能性があるため、理にかなっています。そのSAの複数のセレクターセットを指定することにより、複数のプロトコル（およびポート）を単一のSAに関連付けることができます。
o Processing info -- which action is required -- PROTECT, BYPASS, or DISCARD. There is just one action that goes with all the selector sets, not a separate action for each set. If the required processing is PROTECT, the entry contains the following information. - IPsec mode -- tunnel or transport
o 情報の処理 - どのアクションが必要か - 保護、バイパス、または破棄。すべてのセレクターセットに合わせて1つのアクションがあり、各セットの個別のアクションではありません。必要な処理が保護されている場合、エントリには次の情報が含まれています。-IPSECモード - トンネルまたは輸送
- (if tunnel mode) local tunnel address -- For a non-mobile host, if there is just one interface, this is straightforward; if there are multiple interfaces, this must be statically configured. For a mobile host, the specification of the local address is handled externally to IPsec. - (if tunnel mode) remote tunnel address -- There is no standard way to determine this. See 4.5.3, "Locating a Security Gateway". - Extended Sequence Number -- Is this SA using extended sequence numbers? - stateful fragment checking -- Is this SA using stateful fragment checking? (See Section 7 for more details.) - Bypass DF bit (T/F) -- applicable to tunnel mode SAs - Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs - IPsec protocol -- AH or ESP - algorithms -- which ones to use for AH, which ones to use for ESP, which ones to use for combined mode, ordered by decreasing priority
- （トンネルモードの場合）ローカルトンネルアドレス - 非モバイルホストの場合、インターフェイスが1つしかない場合、これは簡単です。複数のインターフェイスがある場合、これは静的に構成する必要があります。モバイルホストの場合、ローカルアドレスの仕様はIPSECの外部で処理されます。 - （トンネルモードの場合）リモートトンネルアドレス - これを決定する標準的な方法はありません。4.5.3、「セキュリティゲートウェイの位置」を参照してください。 - 拡張シーケンス番号 - このSAは拡張シーケンス番号を使用していますか？ - ステートフルなフラグメントチェック - このSAは、ステートフルフラグメントチェックを使用していますか？（詳細についてはセクション7を参照してください。） - バイパスDFビット（T/F） - トンネルモードSASに適用 - DSCP（T/F）またはDSCP値のバイパスを制限するために必要な場合は、保護されていないDSCP値（配列）にマップ - トンネルモードSASに適用 - IPSECプロトコル - AHまたはESPアルゴリズム - AHに使用するもの、ESPに使用するもの、組み合わせモードに使用するものは、優先順位を減らすことによって順序付けられます。
It is a local matter as to what information is kept with regard to handling extant SAs when the SPD is changed.
SPDが変更されたときの現存するSASの処理に関して、どの情報が保持されているかについてのローカルな問題です。
Additional selectors are often associated with fields in the Next Layer Protocol header. A particular Next Layer Protocol can have zero, one, or two selectors. There may be situations where there aren't both local and remote selectors for the fields that are dependent on the Next Layer Protocol. The IPv6 Mobility Header has only a Mobility Header message type. AH and ESP have no further selector fields. A system may be willing to send an ICMP message type and code that it does not want to receive. In the descriptions below, "port" is used to mean a field that is dependent on the Next Layer Protocol.
多くの場合、追加のセレクターは、次のレイヤープロトコルヘッダーのフィールドに関連付けられています。特定の次のレイヤープロトコルには、ゼロ、1つ、または2つのセレクターを持つことができます。次のレイヤープロトコルに依存するフィールドにローカルセレクターとリモートセレクターの両方がない状況がある場合があります。IPv6モビリティヘッダーには、モビリティヘッダーメッセージタイプのみがあります。AHとESPには、それ以上のセレクターフィールドがありません。システムは、受信したくないICMPメッセージタイプとコードを喜んで送信する場合があります。以下の説明では、「ポート」は次のレイヤープロトコルに依存するフィールドを意味するために使用されます。
A. If a Next Layer Protocol has no "port" selectors, then the Local and Remote "port" selectors are set to OPAQUE in the relevant SPD entry, e.g.,
A.次のレイヤープロトコルに「ポート」セレクターがない場合、ローカルおよびリモートの「ポート」セレクターは、関連するSPDエントリで不透明に設定されています。
Local's next layer protocol = AH "port" selector = OPAQUE
ローカルの次のレイヤープロトコル= ah "port" selector = opaque
Remote's next layer protocol = AH "port" selector = OPAQUE
リモートの次のレイヤープロトコル= ah "port" selector = opaque
B. Even if a Next Layer Protocol has only one selector, e.g., Mobility Header type, then the Local and Remote "port" selectors are used to indicate whether a system is willing to send and/or receive traffic with the specified "port" values. For example, if Mobility Headers of a specified type are allowed to be sent and received via an SA, then the relevant SPD entry would be set as follows:
B.次のレイヤープロトコルに1つのセレクター、たとえばモビリティヘッダータイプのみがある場合でも、ローカルおよびリモートの「ポート」セレクターを使用して、システムが指定された「ポート」でトラフィックを送信または/または受信する意思があるかどうかを示します。値。たとえば、指定されたタイプのモビリティヘッダーをSAを介して送信および受信できる場合、関連するSPDエントリは次のように設定されます。
Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type
ローカルの次のレイヤープロトコル=モビリティヘッダー「ポート」セレクター=モビリティヘッダーメッセージタイプ
Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type
リモートの次のレイヤープロトコル=モビリティヘッダー「ポート」セレクター=モビリティヘッダーメッセージタイプ
If Mobility Headers of a specified type are allowed to be sent but NOT received via an SA, then the relevant SPD entry would be set as follows:
指定されたタイプのモビリティヘッダーを送信することが許可されているが、SAを介して受信されない場合、関連するSPDエントリは次のように設定されます。
Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type
ローカルの次のレイヤープロトコル=モビリティヘッダー「ポート」セレクター=モビリティヘッダーメッセージタイプ
Remote's next layer protocol = Mobility Header "port" selector = OPAQUE
リモートの次のレイヤープロトコル=モビリティヘッダー "ポート"セレクター=オパイク
If Mobility Headers of a specified type are allowed to be received but NOT sent via an SA, then the relevant SPD entry would be set as follows:
指定されたタイプのモビリティヘッダーを受信することが許可されているが、SAを介して送信されない場合、関連するSPDエントリは次のように設定されます。
Local's next layer protocol = Mobility Header "port" selector = OPAQUE
ローカルの次のレイヤープロトコル=モビリティヘッダー "ポート"セレクター=透明
Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type
リモートの次のレイヤープロトコル=モビリティヘッダー「ポート」セレクター=モビリティヘッダーメッセージタイプ
C. If a system is willing to send traffic with a particular
"port" value but NOT receive traffic with that kind of
port value, the system's traffic selectors are set as
follows in the relevant SPD entry:
Local's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
Remote's next layer protocol = ICMP "port" selector = OPAQUE
リモートの次のレイヤープロトコル= ICMP "ポート"セレクター=オパク
D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry:
D.システムが特定の「ポート」値でトラフィックを受け取ることをいとわないが、その種のトラフィックを送信しないことを示すために、システムのトラフィックセレクターは、関連するSPDエントリで次のように設定されています。
Local's next layer protocol = ICMP "port" selector = OPAQUE
ローカルの次のレイヤープロトコル= ICMP "ポート"セレクター=不透明
Remote's
next layer protocol = ICMP
"port" selector = <specific ICMP type & code>
For example, if a security gateway is willing to allow systems behind it to send ICMP traceroutes, but is not willing to let outside systems run ICMP traceroutes to systems behind it, then the security gateway's traffic selectors are set as follows in the relevant SPD entry:
たとえば、セキュリティゲートウェイがその背後にあるシステムがICMPトレーサーアウトを送信できるようにしているが、外部システムがICMPトレーサーをその背後にシステムに実行できるようにすることをいとわない場合、セキュリティゲートウェイのトラフィックセレクターは、関連するSPDエントリで次のように設定されます。：
Local's next layer protocol = 1 (ICMPv4) "port" selector = 30 (traceroute)
ローカルの次のレイヤープロトコル= 1（icmpv4） "port" selector = 30（traceroute）
Remote's next layer protocol = 1 (ICMPv4) "port" selector = OPAQUE
リモートの次のレイヤープロトコル= 1（icmpv4） "port" selector = opaque
In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA. (See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.) The following parameters are associated with each entry in the SAD. They should all be present except where otherwise noted, e.g., AH Authentication algorithm. This description does not purport to be a MIB, only a specification of the minimal data items required to support an SA in an IPsec implementation.
各IPSECの実装には、名目セキュリティ協会データベース（SAD）があり、各エントリは1つのSAに関連付けられたパラメーターを定義します。各SAには悲しいエントリがあります。アウトバウンド処理の場合、各悲しいエントリは、SPDキャッシュのSPD-S部分のエントリによって指摘されます。インバウンド処理の場合、ユニキャストSASの場合、SPIはSAを検索するために単独で使用されるか、IPSECプロトコルタイプと組み合わせて使用されます。IPSEC実装がマルチキャストをサポートする場合、SPIプラス宛先アドレス、またはSPIプラス宛先およびソースアドレスを使用してSAを検索します。（インバウンドIPSECデータグラムをSASにマッピングするために使用する必要があるアルゴリズムの詳細については、セクション4.1を参照してください。）次のパラメーターは、SADの各エントリに関連付けられています。それ以外の場合は、AH認証アルゴリズムなどを除いて、すべて存在する必要があります。この説明は、MIBであると主張するものではなく、IPSEC実装でSAをサポートするために必要な最小データ項目の仕様のみです。
For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See the paragraph in Section 4.4.1 under "Handling Changes to the SPD while the System is Running" for guidance on the effect of SPD changes on extant SAs.) For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, "Selectors". Note also that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
セクション4.4.1.1で定義されている各セレクターについて、SASのインバウンドSAのエントリは、SAが作成された時点でネゴシエートされた値または値を最初に入力する必要があります。（現存するSASに対するSPD変更の効果に関するガイダンスについては、「システムが実行中にSPDの処理の変更」に基づくセクション4.4.1の段落を参照してください。）レシーバーの場合、これらの値は、インバウンドパケット（IPSEC処理後）は、SAに対してネゴシエートされたセレクター値と一致します。したがって、SADは、SASに到着するインバウンドトラフィックのセレクターをチェックするためのキャッシュとして機能します。受信機の場合、これはSAに到着するパケットがSAのポリシーと一致していることを確認することの一部です。（ICMPメッセージのルールについては、セクション6を参照してください。）これらのフィールドは、セクション4.4.1.1、「セレクター」で説明されているように、特定の値、範囲、任意、または不透明の形式を持つことができます。また、SASのエントリがSPDに対応するエントリを持っていないSASのエントリをいくつか持つことができるいくつかの状況があることに注意してください。このドキュメントでは、SPDが変更されたときにSADが選択的にクリアされることを義務付けていないため、それらを作成したSPDエントリが変更または削除されたときに悲しいエントリが残ることがあります。また、手動でキー付きSAが作成された場合、SPDエントリに対応しないこのSAに悲しいエントリがある可能性があります。
Note: The SAD can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender, and the destination address is the multicast group address. An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA. Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic.
注：SADは、手動で構成されている場合、マルチキャストSASをサポートできます。アウトバウンドマルチキャストSAは、ユニキャストSAと同じ構造を持っています。ソースアドレスは送信者のアドレスであり、宛先アドレスはマルチキャストグループアドレスです。インバウンドのマルチキャストSAは、問題のマルチキャストSAに送信することを許可された各ピアのソースアドレスで構成する必要があります。マルチキャストSAのSPI値は、ユニキャストSAのように、レシーバーではなくマルチキャストグループコントローラーによって提供されます。SPDエントリの一部である複数の個々のIPソースアドレス（ユニキャストSASの場合）に対応するために悲しいエントリが必要になる場合があるため、インバウンドに必要なマルチキャストSASに必要な機能は、IPSEC実装にすでに存在する機能です。ただし、SPDにはマルチキャストエントリに対応するための規定がないため、このドキュメントでは、マルチキャストのインバウンドSAの悲しいエントリを作成する自動化された方法を指定していません。インバウンドのマルチキャストトラフィックに対応するために、手動で構成されたSADエントリのみを作成できます。
Implementation Guidance: This document does not specify how an SPD-S entry refers to the corresponding SAD entry, as this is an implementation-specific detail. However, some implementations (based on experience from RFC 2401) are known to have problems in this regard. In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT could choose the same SPI value. The situation also may arise if a host is assigned an IP address (e.g., via DHCP) previously used by some other host, and the SAs associated with the old host have not yet been deleted via dead peer detection mechanisms. This may lead to packets being sent over the wrong SA or, if key management ensures the pair is unique, denying the creation of otherwise valid SAs. Thus, implementors should implement links between the SPD cache and the SAD in a way that does not engender such problems.
実装ガイダンス：このドキュメントでは、実装固有の詳細であるため、SPD-Sエントリが対応するSADエントリを指す方法を指定していません。ただし、いくつかの実装（RFC 2401の経験に基づく）は、この点で問題を抱えていることが知られています。特に、SPDキャッシュに（リモートトンネルヘッダーIPアドレス、リモートSPI）ペアを単に保存するだけでは十分ではありません。ペアは常に単一のSADエントリを一意に識別するとは限らないからです。たとえば、同じNATの背後にある2つのホストが同じSPI値を選択できます。ホストに以前に他のホストが以前に使用していたIPアドレス（DHCPを介して）を割り当てられ、古いホストに関連付けられたSASがデッドピア検出メカニズムを介してまだ削除されていない場合、状況は発生する可能性があります。これにより、間違ったSAを介してパケットが送信されるか、キー管理がペアが一意であることを保証し、特定の有効なSAの作成を否定する場合があります。したがって、実装者は、そのような問題を生み出さない方法で、SPDキャッシュとSADの間にリンクを実装する必要があります。
The following data items MUST be in the SAD:
次のデータ項目は悲しいことでなければなりません。
o Security Parameter Index (SPI): a 32-bit value selected by the receiving end of an SA to uniquely identify the SA. In an SAD entry for an outbound SA, the SPI is used to construct the packet's AH or ESP header. In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA (see text on unicast/multicast in Section 4.1).
o セキュリティパラメーターインデックス（SPI）：SAの受信側によって選択された32ビット値SAを一意に識別します。アウトバウンドSAの悲しいエントリでは、SPIを使用してパケットのAHまたはESPヘッダーを構築します。インバウンドSAの悲しいエントリでは、SPIを使用してトラフィックを適切なSAにマッピングします（セクション4.1のユニキャスト/マルチキャストのテキストを参照）。
o Sequence Number Counter: a 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated.
o シーケンス番号カウンター：AHまたはESPヘッダーでシーケンス番号フィールドを生成するために使用される64ビットカウンター。64ビットシーケンス番号はデフォルトですが、交渉すると32ビットシーケンス番号もサポートされています。
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, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry.
o シーケンスカウンターオーバーフロー：シーケンス番号カウンターのオーバーフローが監査可能なイベントを生成し、SAで追加のパケットの送信を防ぐか、ロールオーバーが許可されるかどうかを示すフラグ。このイベントの監査ログエントリには、SPI値、現在の日付/時間、ローカルアドレス、リモートアドレス、および関連するSADエントリのセレクターを含める必要があります。
o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay.
o アンチレプレイウィンドウ：インバウンドAHまたはESPパケットがリプレイであるかどうかを判断するために使用される64ビットカウンターとビットマップ（または同等）。
Note: If anti-replay has been disabled by the receiver for an SA, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is ignored for the SA in question. 64-bit sequence numbers are the default, but this counter size accommodates 32-bit sequence numbers as well.
注：SAのレシーバーによってアンチレプレイが無効になっている場合、たとえば手動でキー付きSAの場合、問題のSAについてはアンチレプレイウィンドウが無視されます。64ビットシーケンス番号はデフォルトですが、このカウンターサイズには32ビットシーケンス番号も対応します。
o AH Authentication algorithm, key, etc. This is required only if AH is supported.
o AH認証アルゴリズム、キーなど。これは、AHがサポートされている場合にのみ必要です。
o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode algorithm is used, these fields will not be applicable.
o ESP暗号化アルゴリズム、キー、モード、IVなど。複合モードアルゴリズムが使用されている場合、これらのフィールドは適用されません。
o ESP integrity algorithm, keys, etc. If the integrity service is not selected, these fields will not be applicable. If a combined mode algorithm is used, these fields will not be applicable.
o ESP Integrityアルゴリズム、キーなど。整合性サービスが選択されていない場合、これらのフィールドは適用されません。複合モードアルゴリズムを使用すると、これらのフィールドは適用されません。
o ESP combined mode algorithms, key(s), etc. This data is used when a combined mode (encryption and integrity) algorithm is used with ESP. If a combined mode algorithm is not used, these fields are not applicable.
o ESPコンバインドモードアルゴリズム、キーなど。このデータは、ESPで複合モード（暗号化と整合性）アルゴリズムが使用されるときに使用されます。複合モードアルゴリズムを使用していない場合、これらのフィールドは適用されません。
o Lifetime of this SA: 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 with 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 Certificate Revocation Lists (CRLs) used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining the SA lifetime in this fashion. Note: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is:
o このSAの寿命：SAを新しいSA（および新しいSPI）に置き換えるか、終了した時間間隔に加えて、これらのアクションが発生する必要があることを示しています。これは、時間またはバイト数として表される場合があります。または、優先順位を取得するための最初の寿命で両方の同時使用ができます。準拠した実装は、両方のタイプの寿命をサポートする必要があり、両方の同時使用をサポートする必要があります。時間が採用されており、IKEがSAの確立にX.509証明書を採用している場合、SA寿命は証明書の有効性間隔、およびSAのIKE取引所で使用される証明書取消リスト（CRL）の次のイシュエートによって制約されなければなりません。。イニシエーターとレスポンダーの両方が、この方法でSA寿命を制約する責任があります。注：SASの期限が切れるときのリフレッシュキーを処理する方法の詳細は、ローカルな問題です。ただし、合理的なアプローチの1つは次のとおりです。
(a) If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec cryptographic 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 MUST 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.
(a) バイト数を使用する場合、実装はIPSEC暗号化アルゴリズムが適用されるバイト数をカウントする必要があります。ESPの場合、これは暗号化アルゴリズム（ヌル暗号化を含む）であり、AHの場合、これは認証アルゴリズムです。これには、パッドバイトなどが含まれます。実装は、SAの終わりにカウンターを同期しないようにすることができなければならないことに注意してください。同じ方法。
(b) There SHOULD be two kinds of lifetime -- a soft lifetime that warns the implementation to initiate action such as setting up a replacement SA, and a hard lifetime when the current SA ends and is destroyed.
(b) 生涯には2種類の寿命があるはずです。柔らかい寿命は、交換用SAのセットアップなどのアクションを開始するための実装と、現在のSAが終了して破壊されたときの硬い寿命です。
(c) If the entire packet does not get delivered during the SA's lifetime, the packet SHOULD be discarded.
(c) SAの寿命の間にパケット全体が配信されない場合、パケットを破棄する必要があります。
o IPsec protocol mode: tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA.
o IPSECプロトコルモード：トンネルまたは輸送。AHまたはESPのモードがこのSAのトラフィックに適用されるかを示します。
o Stateful fragment checking flag. Indicates whether or not stateful fragment checking applies to this SA.
o ステートフルなフラグメントチェックフラグ。このSAにステートフルなフラグメントチェックが適用されるかどうかを示します。
o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both inner and outer headers are IPv4.
o バイパスDFビット（T/F） - 内側ヘッダーと外側ヘッダーの両方がIPv4であるトンネルモードSASに適用されます。
o DSCP values -- the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA.
o DSCP値 - このSAを持ち歩くパケットに許可されたDSCP値のセット。値が指定されていない場合、DSCP固有のフィルタリングは適用されません。1つ以上の値が指定されている場合、これらは、アウトバウンドパケットのトラフィックセレクターに一致するいくつかのSAから1つのSAを選択するために使用されます。これらの値は、SAに到着するインバウンドトラフィックに対してチェックされていないことに注意してください。
o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns.
o DSCP値のバイパスを制限するために必要な場合、DSCP（T/F）またはマップを保護されていないDSCP値（配列）にマップします - トンネルモードSASに適用されます。この機能は、カバーチャネルシグナル伝達の懸念に対処するために、内側ヘッダーから外側ヘッダーの値にDSCP値をマッピングします。
o Path MTU: any observed path MTU and aging variables.
o PATH MTU：観測されたパスMTUおよび老化変数。
o Tunnel header IP source and destination address -- both addresses must be either IPv4 or IPv6 addresses. The version implies the type of IP header to be used. Only used when the IPsec protocol mode is tunnel.
o トンネルヘッダーIPソースと宛先アドレス -両方のアドレスはIPv4またはIPv6アドレスのいずれかでなければなりません。このバージョンは、使用するIPヘッダーのタイプを意味します。IPSECプロトコルモードがトンネルである場合にのみ使用されます。
For each selector, the following tables show the relationship between the value in the SPD, the PFP flag, the value in the triggering packet, and the resulting value in the SAD. Note that the administrative interface for IPsec can use various syntactic options to make it easier for the administrator to enter rules. For example, although a list of ranges is what IKEv2 sends, it might be clearer and less error prone for the user to enter a single IP address or IP address prefix.
各セレクターについて、次のテーブルは、SPDの値、PFPフラグ、トリガーパケットの値、およびSADの結果の値との関係を示しています。IPSECの管理インターフェイスは、さまざまな構文オプションを使用して、管理者がルールの入力を容易にすることができることに注意してください。たとえば、範囲のリストはIKEV2が送信するものですが、ユーザーが単一のIPアドレスまたはIPアドレスのプレフィックスを入力すると、より明確でエラーが少ない場合があります。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
rem addr list of ranges 0 IP addr "D" list of ranges
ANY 0 IP addr "D" ANY
list of ranges 1 IP addr "D" "D"
ANY 1 IP addr "D" "D"
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
If the protocol is one that has two ports, then there will be selectors for both Local and Remote ports.
プロトコルが2つのポートを持つプロトコルの場合、ローカルポートとリモートポートの両方にセレクターがあります。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
rem port list of ranges 0 dst port "d" list of ranges
ANY 0 dst port "d" ANY
OPAQUE 0 dst port "d" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
If the protocol is mobility header, then there will be a selector for mh type.
プロトコルがモビリティヘッダーの場合、MHタイプのセレクターがあります。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
If the protocol is ICMP, then there will be a 16-bit selector for ICMP type and ICMP code. Note that the type and code are bound to each other, i.e., the codes apply to the particular type. This 16-bit selector can contain a single type and a range of codes, a single type and ANY code, and ANY type and ANY code.
プロトコルがICMPの場合、ICMPタイプとICMPコード用の16ビットセレクターがあります。タイプとコードは互いにバインドされていることに注意してください。つまり、コードは特定のタイプに適用されます。この16ビットセレクターには、単一のタイプと範囲のコード、単一のタイプと任意のコード、および任意のタイプと任意のコードを含めることができます。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
a single type & 0 not avail. discard packet
range of codes
a single type & 0 not avail. discard packet
ANY code
ANY type & 0 not avail. ANY type &
ANY code ANY code
OPAQUE 0 not avail. OPAQUE
a single type & 1 type "t" & "t" and "c"
range of codes code "c"
a single type & 1 type "t" & "t" and "c"
ANY code code "c"
ANY type & 1 type "t" & "t" and "c"
ANY code code "c"
OPAQUE 1 type "t" & ***
code "c"
a single type & 1 not avail. discard packet
range of codes
a single type & 1 not avail. discard packet
ANY code
ANY type & 1 not avail. discard packet
ANY code
OPAQUE 1 not avail. ***
If the name selector is used:
名前セレクターが使用されている場合：
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
name list of user or N/A N/A N/A
system names
* "List of protocols" is the information, not the way
that the SPD or SAD or IKEv2 have to represent this
information.
** 0 (zero) is used by IKE to indicate ANY for
protocol.
*** Use of PFP=1 with an OPAQUE value is an error and
SHOULD be prohibited by an IPsec implementation.
**** The protocol field cannot be OPAQUE in IPv4. This
table entry applies only to IPv6.
The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions:
Peer Authorizationデータベース（PAD）は、SPDとIKEなどのセキュリティ協会の管理プロトコルとの間のリンクを提供します。いくつかの重要な機能を具体化します。
o identifies the peers or groups of peers that are authorized to communicate with this IPsec entity o specifies the protocol and method used to authenticate each peer o provides the authentication data for each peer o constrains the types and values of IDs that can be asserted by a peer with regard to child SA creation, to ensure that the peer does not assert identities for lookup in the SPD that it is not authorized to represent, when child SAs are created o peer gateway location info, e.g., IP address(es) or DNS names, MAY be included for peers that are known to be "behind" a security gateway
o このIPSECエンティティと通信することが許可されているピアまたはピアのグループを識別するo各ピアを認証するために使用されるプロトコルと方法を指定しますo各ピアの認証データを提供しますoピアが主張できるIDのタイプと値を制約します子SAの作成に関して、ピアが代表することを許可されていないSPDのルックアップのアイデンティティを主張しないようにします。、セキュリティゲートウェイの「背後」であることが知られている仲間に含まれる場合があります
The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder.
パッドは、ピアがイニシエーターまたはレスポンダーのいずれかとして機能する場合、IKEピアにこれらの機能を提供します。
To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below). The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-shared secrets) and the authentication data (e.g., the pre-shared secret or the trust anchor relative to which the peer's certificate will be validated). For certificate-based authentication, the entry also may provide information to assist in verifying the revocation status of the peer, e.g., a pointer to a CRL repository or the name of an Online Certificate Status Protocol (OCSP) server associated with the peer or with the trust anchor associated with the peer.
これらの機能を実行するために、パッドには、IPSECエンティティが通信する各ピアまたはピアグループのエントリが含まれています。エントリは、個々のピア（ユーザー、エンドシステム、またはセキュリティゲートウェイ）に名前を付けるか、ピアグループを指定します（以下に定義されているIDマッチングルールを使用）。エントリは、使用された認証プロトコル（IKEV1、IKEV2、KINK）メソッド（例：証明書または事前に共有された秘密）と認証データ（例えば、ピアの証明書がどこに行くか比較的共有秘密または信頼アンカーを指定します。検証されます）。証明書ベースの認証の場合、エントリは、ピアの取り消しステータス、たとえばCRLリポジトリへのポインターまたはオンライン証明書ステータスプロトコル（OCSP）サーバーの名前またはピアに関連付けられたトラストアンカー。
Each entry also specifies whether the IKE ID payload will be used as a symbolic name for SPD lookup, or whether the remote IP address provided in traffic selector payloads will be used for SPD lookups when child SAs are created.
また、各エントリは、IKE IDペイロードがSPDルックアップのシンボリック名として使用されるかどうか、またはトラフィックセレクターペイロードで提供されるリモートIPアドレスが、子SASが作成されたときにSPDルックアップに使用されるかどうかを指定します。
Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints.
パッド情報は、同じアドレス/ホストを保護するために2つのトンネルなど、2つのトンネルの間で一度に複数のトンネルモードSAの作成をサポートするために使用できることに注意してください。
The PAD is an ordered database, where the order is defined by an administrator (or a user in the case of a single-user end system). Usually, the same administrator will be responsible for both the PAD and SPD, since the two databases must be coordinated. The ordering requirement for the PAD arises for the same reason as for the SPD, i.e., because use of "star name" entries allows for overlaps in the set of IKE IDs that could match a specific entry.
パッドは注文されたデータベースで、注文は管理者（またはシングルユーザーエンドシステムの場合のユーザー）によって定義されます。通常、2つのデータベースを調整する必要があるため、同じ管理者がPADとSPDの両方に対して責任を負います。パッドの順序付け要件は、SPDと同じ理由で発生します。つまり、「星名」エントリの使用により、特定のエントリと一致する可能性のあるIKE IDのセットの重複が可能になります。
Six types of IDs are supported for entries in the PAD, consistent with the symbolic name types and IP addresses used to identify SPD entries. The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry. All of these ID types can be used to match IKE ID payload types. The six types are:
SPDエントリを識別するために使用されるシンボリック名タイプとIPアドレスと一致する、パッド内のエントリには6種類のIDがサポートされています。各エントリのIDは、パッドのインデックスとして機能します。つまり、エントリを選択するために使用される値です。これらのIDタイプはすべて、IKE IDペイロードタイプに一致するために使用できます。6つのタイプは次のとおりです。
o DNS name (specific or partial) o Distinguished Name (complete or sub-tree constrained) o RFC 822 email address (complete or partially qualified) o IPv4 address (range) o IPv6 address (range) o Key ID (exact match only)
o DNS名（具体的または部分的）o特別名（完了またはサブツリー制約）o RFC 822メールアドレス（完全または部分的に資格のある）o IPv4アドレス（範囲）o ipv6アドレス（範囲）oキーID（正確な一致のみ）
The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string ".example.com" could be used to match any DNS name ending in these two domain name components.
最初の3つの名前のタイプは、正確な一致と同様に、サブツリーマッチングに対応できます。DNS名は完全に資格があるため、たとえばfoo.example.comなど、正確に1つの名前と一致する場合があります。あるいは、名前には部分的に指定されることにより、ピアのグループが含まれる場合があります。たとえば、文字列「.example.com」を使用して、これら2つのドメイン名コンポーネントで終わるDNS名を一致させることができます。
Similarly, a Distinguished Name may specify a complete Distinguished Name to match exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA, C = US. Alternatively, an entry may encompass a group of peers by specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA" might be used to match all DNs that contain these two attributes as the top two Relative Distinguished Names (RDNs).
同様に、著名な名前は、1つのエントリ（CN = Stephen、O = BBN Technologies、SP = MA、C = USなど）を正確に1つのエントリに一致させるように完全に識別した名前を指定する場合があります。あるいは、エントリは、サブツリーを指定することにより、ピアのグループを含む場合があります。たとえば、「C = us、sp = ma」のフォームのエントリは、これら2つの属性を含むすべてのDNSを上位2つの親relativeとして一致させるために使用される場合があります。著名な名前（RDN）。
For an RFC 822 e-mail addresses, the same options exist. A complete address such as foo@example.com matches one entity, but a sub-tree name such as "@example.com" could be used to match all the entities with names ending in those two domain names to the right of the @.
RFC 822の電子メールアドレスの場合、同じオプションが存在します。foo@example.comなどの完全なアドレスは1つのエンティティと一致しますが、「@example.com」などのサブツリー名を使用して、すべてのエンティティを@の右側にある2つのドメイン名で終了する名前と一致させることができます。。
The specific syntax used by an implementation to accommodate sub-tree matching for distinguished names, domain names or RFC 822 e-mail addresses is a local matter. But, at a minimum, sub-tree matching of the sort described above MUST be supported. (Substring matching within a DN, DNS name, or RFC 822 address MAY be supported, but is not required.)
識別名、ドメイン名、またはRFC 822電子メールアドレスのサブツリーマッチングに対応するために実装で使用される特定の構文は、ローカルな問題です。ただし、少なくとも、上記のソートのサブツリーマッチングをサポートする必要があります。（DN、DNS名、またはRFC 822アドレス内のサブストリングマッチングがサポートされる場合がありますが、必要ありません。）
For IPv4 and IPv6 addresses, the same address range syntax used for SPD entries MUST be supported. This allows specification of an individual address (via a trivial range), an address prefix (by choosing a range that adheres to Classless Inter-Domain Routing (CIDR)-style prefixes), or an arbitrary address range.
IPv4およびIPv6アドレスの場合、SPDエントリに使用される同じアドレス範囲の構文をサポートする必要があります。これにより、個々のアドレス（些細な範囲を介して）、アドレスのプレフィックス（クラスのないドメイン間ルーティング（CIDR）スタイルのプレフィックスを順守する範囲を選択することにより）、または任意のアドレス範囲を指定できます。
The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type.
キーIDフィールドは、IKEのOctet Stringとして定義されます。この名前のタイプの場合、正確な試合構文のみをサポートする必要があります（このIDタイプに明示的な構造がないため）。このIDタイプには、追加のマッチング関数がサポートされる場合があります。
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types:
IDフィールドマッチングに基づいてパッドの順序付けられた検索に基づいてエントリが配置されたら、主張されたIDを確認する必要があります。つまり、主張されたIDを認証する必要があります。パッドエントリごとに、実行する認証の種類が表示されます。このドキュメントでは、2つの必要な認証データ型のサポートが必要です。
- X.509 certificate - pre-shared secret
- X.509証明書 - 事前に共有秘密
For authentication based on an X.509 certificate, the PAD entry contains a trust anchor via which the end entity (EE) certificate for the peer must be verifiable, either directly or via a certificate path. See RFC 3280 for the definition of a trust anchor. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a list of appropriate OCSP responders or CRL repositories, and associated authentication data. For authentication based on a pre-shared secret, the PAD contains the pre-shared secret to be used by IKE.
X.509証明書に基づく認証の場合、パッドエントリには、ピアの最終エンティティ（EE）証明書が直接または証明書パスを介して検証可能でなければならない信頼アンカーが含まれています。信頼アンカーの定義については、RFC 3280を参照してください。証明書ベースの認証で使用されるエントリには、証明書の取り消しステータス、たとえば適切なOCSP応答者またはCRLリポジトリのリスト、および関連する認証データを促進するための追加データが含まれる場合があります。事前に共有された秘密に基づく認証のために、パッドにはIKEが使用する事前に共有された秘密が含まれています。
This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. Thus, implementations MUST provide a means for an administrator to require a match between an asserted IKE ID and the subject name or subject alt name in a certificate. The former is applicable to IKE IDs expressed as distinguished names; the latter is appropriate for DNS names, RFC 822 e-mail addresses, and IP addresses. Since KEY ID is intended for identifying a peer authenticated via a pre-shared secret, there is no requirement to match this ID type to a certificate field.
このドキュメントでは、ピアによって主張されたIKE IDが、そのピアの身元を認証するために採用されているEnd Entity証明書の特定のフィールドに構文的に関連することを必要としません。ただし、多くの場合、そのような要件を課すことが適切であることがよくあります。たとえば、単一のエントリが一連のピアを表す場合、それぞれが異なるSPDエントリを持っている可能性があります。したがって、実装は、管理者が証明書の主張されたIKE IDと件名名または件名ALT名との一致を要求する手段を提供する必要があります。前者は、著名な名前として表現されたIKE IDに適用されます。後者は、DNS名、RFC 822電子メールアドレス、およびIPアドレスに適しています。キーIDは、事前に共有された秘密を介して認証されたピアを識別することを目的としているため、このIDタイプを証明書フィールドに一致させる必要はありません。
See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE performs peer authentication using certificates or pre-shared secrets.
IKEV1 [HARCAR98]およびIKEV2 [KAU05]を参照してください。IKEは、証明書または事前に共有された秘密を使用してピア認証を実行する方法の詳細を参照してください。
This document does not mandate support for any other authentication methods, although such methods MAY be employed.
このドキュメントは、そのような方法が採用される場合がありますが、他の認証方法のサポートを義務付けていません。
Once an IKE peer is authenticated, child SAs may be created. Each PAD entry contains data to constrain the set of IDs that can be asserted by an IKE peer, for matching against the SPD. Each PAD entry indicates whether the IKE ID is to be used as a symbolic name for SPD matching, or whether an IP address asserted in a traffic selector payload is to be used.
IKEピアが認証されると、子SASが作成される場合があります。各パッドエントリには、SPDと一致するために、IKEピアによって主張できるIDのセットを制約するデータが含まれています。各パッドエントリは、IKE IDがSPDマッチングのシンボリック名として使用されるかどうか、またはトラフィックセレクターのペイロードでアサートされたIPアドレスを使用するかどうかを示します。
If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. (A peer may be authorized for both address types, so there MUST be provision for both a v4 and a v6 address range.)
エントリがIKE IDを使用することを示している場合、パッドエントリIDフィールドは、認定されたIDのセットを定義します。エントリが子SASトラフィックセレクターを使用することを示している場合、IPv4および/またはIPv6アドレス範囲の形で追加のデータ要素が必要です。（両方のアドレスタイプに対してピアが承認される場合があるため、V4とV6アドレス範囲の両方の規定が必要です。）
During the initial IKE exchange, the initiator and responder each assert their identity via the IKE ID payload and send an AUTH payload to verify the asserted identity. One or more CERT payloads may be transmitted to facilitate the verification of each asserted identity.
最初のIKE Exchangeでは、イニシエーターとレスポンダーはそれぞれIKE IDペイロードを介して身元を主張し、AUTHペイロードを送信して、主張されたアイデンティティを確認します。1つ以上の証明書のペイロードを送信して、主張された各アイデンティティの検証を促進する場合があります。
When an IKE entity receives an IKE ID payload, it uses the asserted ID to locate an entry in the PAD, using the matching rules described above. The PAD entry specifies the authentication method to be employed for the identified peer. This ensures that the right method is used for each peer and that different methods can be used for different peers. The entry also specifies the authentication data that will be used to verify the asserted identity. This data is employed in conjunction with the specified method to authenticate the peer, before any CHILD SAs are created.
IKEエンティティがIKE IDペイロードを受信すると、ASSERTED IDを使用して、上記の一致するルールを使用して、パッド内のエントリを見つけます。パッドエントリは、識別されたピアに使用される認証方法を指定します。これにより、各ピアに適切な方法が使用され、異なるピアに異なる方法を使用できるようになります。エントリは、主張されたIDの検証に使用される認証データも指定します。このデータは、子供のSASが作成される前に、指定された方法と組み合わせてピアを認証するために採用されています。
Child SAs are created based on the exchange of traffic selector payloads, either at the end of the initial IKE exchange or in subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now authenticated) IKE peer is used to constrain creation of child SAs; specifically, the PAD entry specifies how the SPD is searched using a traffic selector proposal from a peer. There are two choices: either the IKE ID asserted by the peer is used to find an SPD entry via its symbolic name, or peer IP addresses asserted in traffic selector payloads are used for SPD lookups based on the remote IP address field portion of an SPD entry. It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers.
子SASは、最初のIKE Exchangeの終了時またはその後のCreate_Child_SA取引所のいずれかで、トラフィックセレクターのペイロードの交換に基づいて作成されます。（現在認証されている）Ike Peerのパッドエントリは、子SASの作成を制限するために使用されます。具体的には、パッドエントリは、ピアからのトラフィックセレクターの提案を使用してSPDの検索方法を指定します。2つの選択肢があります。ピアによって主張されたIKE IDは、そのシンボリック名を介してSPDエントリを見つけるために使用されます。エントリ。認証されたピアが他の正当なピアに関連付けられたスプーフィングIDを防ぐために、子SASの作成にこれらの制約を課す必要があります。
Note that because the PAD is checked before searching for an SPD entry, this safeguard protects an initiator against spoofing attacks. For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 [RFC2401] and this document do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. Thus, the PAD provides a binding of address ranges (or name sub-spaces) to peers, to counter such attacks.
SPDエントリを検索する前にパッドがチェックされるため、この保護手段はスプーフィング攻撃からイニシエーターを保護することに注意してください。たとえば、IKE Aがセキュリティゲートウェイが提供するホストであるIPアドレスX向けのアウトバウンドパケットを受け取ると仮定します。RFC 2401 [RFC2401]およびこのドキュメントは、IKEピアサービングXのアドレスを決定する方法を指定していません。ただし、Xの推定代表者としてA AS AS AS AS AS AS AS AS AS AS ASがIKEの交換を許可するためには、PADに登録する必要があります。認証されます。さらに、認証されたピアがトラフィックセレクターの交換でXを表すと主張すると、パッドはXを表すことが問題のピアが許可されているかどうかを判断するためにパッドに相談します。スペース）そのような攻撃に対抗するために、ピアに。
All IPsec implementations MUST support 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 service available for AH and ESP requires automated SA management. Moreover, the granularity of key distribution employed with IPsec determines the granularity of authentication provided. In general, data origin authentication in AH and ESP is limited by the extent to which secrets used with the integrity 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で使用される重要な分布の粒度は、提供された認証の粒度を決定します。一般に、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 SA 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 might 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.
最も単純な形式の管理は手動管理です。この管理では、他のシステムとの通信を確保するために関連するキーイング材料およびSA管理データを使用して、各システムを手動で構成します。手動技術は、小規模な静的環境では実用的ですが、うまく拡張しません。たとえば、企業は、いくつかのサイトでセキュリティゲートウェイで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のアンチレプレイ機能の使用を促進し、ユーザー指向およびセッション指向のキーイングのためのSASのオンデマンド作成に対応するために必要です。（SAを「再キー」するという概念は、実際に新しいSAを使用して新しいSAの作成を意味することに注意してください。これは、一般的に自動化されたSA/キー管理プロトコルの使用を暗示するプロセスです。）
The default automated key management protocol selected for use with IPsec is IKEv2 [Kau05]. This document assumes the availability of certain functions from the key management protocol that are not supported by IKEv1. Other automated SA management protocols MAY be employed.
IPSECで使用するために選択されたデフォルトの自動化キー管理プロトコルはIKEV2 [KAU05]です。このドキュメントでは、IKEV1によってサポートされていない主要な管理プロトコルからの特定の機能の可用性を想定しています。他の自動化されたSA管理プロトコルが採用される場合があります。
When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two SAs created by IKE. If both integrity and confidentiality are employed, then a minimum of four keys are required. Additionally, some cryptographic algorithms may require multiple keys, e.g., 3DES.
自動化されたSA/キー管理プロトコルを採用すると、このプロトコルからの出力を使用して、単一のSAの複数のキーを生成します。これは、IKEによって作成された2つのSAのそれぞれに異なるキーが使用されるためにも発生します。完全性と機密性の両方が採用されている場合、最低4つのキーが必要です。さらに、一部の暗号化アルゴリズムには、3DEなどの複数のキーが必要になる場合があります。
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 keys 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 keys MUST be taken from the first (left-most, high-order) bits and the integrity keys MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant cryptographic algorithm specification RFC. In the case of multiple encryption keys or multiple integrity keys, the specification for the cryptographic algorithm must specify the order in which they are to be selected from a single string of bits provided to the cryptographic 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, but the Peer Authorization Database (PAD) described in Section 4.4 is the most likely candidate. (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 below.)
このセクションでは、ホストが関連するセキュリティゲートウェイの存在についてどのように学習するかに関する問題について説明し、ホストがこれらのセキュリティゲートウェイに連絡したら、これらが正しいセキュリティゲートウェイであることをどのように知っているかについて説明します。必要な情報が保存されている場所の詳細はローカルの問題ですが、セクション4.4で説明されているピア認証データベース（PAD）は最も可能性の高い候補です。（注：s*は、以下のSH1およびSG2などのIPSECを実行しているシステムを示しています。）
Consider a situation in which a remote host (SH1) 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 crossing the Internet to his home organization's firewall (SG2). This situation raises several issues:
リモートホスト（SH1）がインターネットを使用してサーバーまたは他のマシン（H2）にアクセスし、たとえばH1のトラフィックが通過する必要があるファイアウォール（SG2）がある場合があります。この状況の例は、インターネットを彼の自宅組織のファイアウォール（SG2）に渡るモバイルホストです。この状況はいくつかの問題を提起します：
1. How does SH1 know/learn about the existence of the security gateway SG2?
1. SH1は、セキュリティゲートウェイ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?
2. SG2をどのように認証し、SG2を認証したら、SG2がH2を表すことが許可されていることをどのように確認しますか？
3. How does SG2 authenticate SH1 and verify that SH1 is authorized to contact H2?
3. SG2はSH1を認証し、SH1がH2に連絡する権限があることをどのように確認しますか？
4. How does SH1 know/learn about any additional gateways that provide alternate paths to H2?
4. SH1は、H2への代替パスを提供する追加のゲートウェイをどのように知っていますか？
To address these problems, an IPsec-supporting host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use. This includes the ability to configure information for locating and authenticating one or more security gateways and verifying the authorization of these gateways to represent the destination host. (The authorization function is implied in the PAD.) This document does not address the issue of how to automate the discovery/verification of security gateways.
これらの問題に対処するために、IPSECサポートホストまたはセキュリティゲートウェイには、ユーザー/管理者がその使用を必要とする宛先アドレスの範囲用の1つ以上のセキュリティゲートウェイのアドレスを構成できるようにする管理インターフェイスが必要です。これには、1つ以上のセキュリティゲートウェイを見つけて認証するための情報を構成し、宛先ホストを表すこれらのゲートウェイの承認を検証する機能が含まれます。（許可機能はパッドに暗示されています。）このドキュメントは、セキュリティゲートウェイの発見/検証を自動化する方法の問題には対処されていません。
The receiver-orientation of the SA implies that, in the case of unicast traffic, the destination system will select the SPI value. By having the destination select the SPI value, there is no potential for manually configured SAs to conflict with automatically configured (e.g., via a key management protocol) SAs or for SAs from multiple sources to conflict with each other. For multicast traffic, there are multiple destination systems associated with a single SA. 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.
SAの受信機向きは、ユニキャストトラフィックの場合、宛先システムがSPI値を選択することを意味します。宛先にSPI値を選択させることにより、手動で構成されたSASが自動的に構成された（例えば、主要な管理プロトコルを介して）SASまたは複数のソースからのSASが互いに競合する可能性はありません。マルチキャストトラフィックの場合、単一のSAに関連付けられた複数の宛先システムがあります。そのため、一部のシステムまたは個人は、各マルチキャストグループに代わってSPIまたはSPIを選択するために、すべてのマルチキャストグループ間で調整し、ここに定義されていないメカニズムを介してそのマルチキャストグループのすべての正当なメンバーにグループのIPSEC情報を伝える必要があります。
Multiple senders to a multicast group SHOULD use a single Security Association (and hence SPI) for all traffic to that group when a symmetric key encryption or integrity 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 approaches are deferred to the IETF Multicast Security Working Group.
マルチキャストグループへの複数の送信者は、対称キー暗号化または整合性アルゴリズムが採用されている場合、そのグループへのすべてのトラフィックに対して単一のセキュリティアソシエーション（およびSPI）を使用する必要があります。このような状況では、受信者は、メッセージがそのマルチキャストグループのキーを所有するシステムから来たことのみを知っています。このような状況では、レシーバーは一般に、どのシステムがマルチキャストトラフィックを送信したかを認証できません。他のより一般的なマルチキャストアプローチの仕様は、IETFマルチキャストセキュリティワーキンググループに延期されます。
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors. Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.
セクション4.4.1「セキュリティポリシーデータベース（SPD）」で述べたように、IPSEC管理トラフィックを含むIPSEC保護境界を通過するすべてのトラフィックの処理中にSPD（または関連するキャッシュ）を参照する必要があります。パケットと一致する（インバウンドトラフィックまたはアウトバウンドトラフィックのいずれか）に一致するポリシーが見つからない場合、パケットを破棄する必要があります。処理を簡素化し、非常に高速なSAルックアップ（SG/BITS/BITW用）を可能にするために、このドキュメントでは、すべてのアウトバウンドトラフィック（SPD-OプラスSPD-S）のSPDキャッシュの概念と、インバウンドのキャッシュを紹介します。非IPSEC保護トラフィック（SPD-I）。（前述のように、SADは、SASに到着するインバウンドIPSEC保護されたトラフィックのセレクターをチェックするためのキャッシュとして機能します。）SPDごとに名目上1つのキャッシュがあります。この仕様の目的のために、各キャッシュされたエントリが正確に1つのSAにマッピングされると想定されています。ただし、例外は、複数のSASを使用して異なる優先順位のトラフィック（例えば、異なるDSCP値で示されているように）が同じセレクターのトラフィックを運ぶ場合に発生します。また、SASにはSASのエントリをSPDに持っていないSASのエントリを持つことができる状況がいくつかあることに注意してください。このドキュメントでは、SPDが変更されたときにSADが選択的にクリアされることを義務付けていないため、それらを作成したSPDエントリが変更または削除されたときに悲しいエントリが残ることがあります。また、手動でキー付きSAが作成された場合、SPDエントリに対応しないこのSAに悲しいエントリがある可能性があります。
Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry, whereas an ordered search of the SPD would have resulted in a match against a different entry. But, if the SPD entries are first decorrelated, then the resulting entries can safely be cached. Each cached entry will indicate that matching traffic should be bypassed or discarded, appropriately. (Note: The original SPD entry might result in multiple SAs, e.g., because of PFP.) Unless otherwise noted, all references below to the "SPD" or "SPD cache" or "cache" are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache containing entries from the decorrelated SPD.
SPDエントリは重複する可能性があるため、一般的にこれらのエントリを安全にキャッシュすることはできません。単純なキャッシングはキャッシュエントリとの試合につながる可能性がありますが、SPDの順序付けられた検索は別のエントリとの試合になりました。ただし、SPDエントリが最初に切り離されている場合、結果のエントリを安全にキャッシュできます。キャッシュされた各エントリは、一致するトラフィックを適切にバイパスまたは破棄する必要があることを示します。（注：元のSPDエントリは、PFPのために複数のSASをもたらす可能性があります。）特に明記しない限り、以下のすべての参照は「SPD」または「SPDキャッシュ」または「キャッシュ」が脱線したSPDに対するものです（SPD-I、SPD-O、SPD-S）または逆相関SPDからのエントリを含むSPDキャッシュ。
Note: 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. This provides an implicit caching mechanism, and the portions of the preceding discussion that address caching can be ignored in such implementations.
注：ソケットに基づいたホストIPSEC実装では、新しいソケットが作成されて、もしあれば、そのソケットに流れるトラフィックにIPSEC処理が適用されるものを決定するために、SPDに相談されます。これは、暗黙のキャッシュメカニズムを提供し、キャッシュに対処する前述の議論の一部をそのような実装で無視できます。
Note: It is assumed that one starts with a correlated SPD because that is how users and administrators are accustomed to managing these sorts of access control lists or firewall filter rules. Then the decorrelation algorithm is applied to build a list of cache-able SPD entries. The decorrelation is invisible at the management interface.
注：ユーザーと管理者がこの種のアクセス制御リストまたはファイアウォールフィルタールールの管理に慣れている方法であるため、相関SPDで始まると想定されています。次に、脱線アルゴリズムが適用され、キャッシュ可能なSPDエントリのリストが作成されます。除去は、管理インターフェイスでは見えません。
For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed.
インバウンドIPSECトラフィックの場合、SPIによって選択された悲しいエントリは、AHまたはESP処理が実行された後、IPSECパケットの到着と一致するセレクターのキャッシュとして機能します。
First consider the path for traffic entering the implementation via a protected interface and exiting via an unprotected interface.
最初に、保護されたインターフェイスを介して実装に入るトラフィックのパスを検討し、保護されていないインターフェイスを介して終了します。
Unprotected Interface
^
|
(nested SAs) +----------+
-------------------|Forwarding|<-----+
| +----------+ |
| ^ |
| | BYPASS |
V +-----+ |
+-------+ | SPD | +--------+
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
| (*) | | (*) |---->|(AH/ESP)| boundary
+-------+ +-----+ +--------+
| +-------+ / ^
| |DISCARD| <--/ |
| +-------+ |
| |
| +-------------+
|---------------->|SPD Selection|
+-------------+
^
| +------+
| -->| ICMP |
| / +------+
|/
|
|
Protected Interface
Figure 2. Processing Model for Outbound Traffic (*) = The SPD caches are shown here. If there is a cache miss, then the SPD is checked. There is no requirement that an implementation buffer the packet if there is a cache miss.
図2.アウトバウンドトラフィックの処理モデル（*）= SPDキャッシュをここに示します。キャッシュミスがある場合、SPDがチェックされます。キャッシュミスがある場合、実装がパケットをバッファするという要件はありません。
IPsec MUST perform the following steps when processing outbound packets:
IPSECは、アウトバウンドパケットを処理するときに次の手順を実行する必要があります。
1. When a packet arrives from the subscriber (protected) interface, invoke the SPD selection function to obtain the SPD-ID needed to choose the appropriate SPD. (If the implementation uses only one SPD, this step is a no-op.)
1. サブスクライバー（保護）インターフェイスからパケットが到着したら、SPD選択関数を呼び出して、適切なSPDを選択するために必要なSPD-IDを取得します。（実装が1つのSPDのみを使用している場合、このステップはNO-OPです。）
2. Match the packet headers against the cache for the SPD specified by the SPD-ID from step 1. Note that this cache contains entries from SPD-O and SPD-S.
2. ステップ1からSPD-IDで指定されたSPDのキャッシュに対してパケットヘッダーを一致させます。このキャッシュには、SPD-OおよびSPD-Sのエントリが含まれていることに注意してください。
3a. If there is a match, then process the packet as specified by the matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH or ESP. If IPsec processing is applied, there is a link from the SPD cache entry to the relevant SAD entry (specifying the mode, cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec processing is as previously defined, for tunnel or transport modes and for AH or ESP, as specified in their respective RFCs [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of the stateful fragment checking flag (and the DF bit in the IP header of the outbound packet) determine whether the packet can (must) be fragmented prior to or after IPsec processing, or if it must be discarded and an ICMP PMTU message is sent.
3a。一致がある場合は、一致するキャッシュエントリで指定されたパケットを処理します。つまり、AHまたはESPを使用してバイパス、破棄、または保護します。IPSEC処理が適用されている場合、SPDキャッシュエントリから関連するSADエントリへのリンクがあります（モード、暗号化アルゴリズム、キー、SPI、PMTUなど）。IPSEC処理は、トンネルまたは輸送モードの場合、およびそれぞれのRFC [KEN05B、KEN05A]で指定されているAHまたはESPについて、以前に定義されています。SA PMTU値、さらにステートフルフラグメントチェックフラグ（およびアウトバウンドパケットのIPヘッダーのDFビット）の値は、IPSEC処理の前または後にパケットを断片化できるかどうか、またはそれができるかどうかを決定することに注意してください。廃棄する必要があり、ICMP PMTUメッセージが送信されます。
3b. If no match is found in the cache, search the SPD (SPD-S and SPD-O parts) specified by SPD-ID. If the SPD entry calls for BYPASS or DISCARD, create one or more new outbound SPD cache entries and if BYPASS, create one or more new inbound SPD cache entries. (More than one cache entry may be created since a decorrelated SPD entry may be linked to other such entries that were created as a side effect of the decorrelation process.) If the SPD entry calls for PROTECT, i.e., creation of an SA, the key management mechanism (e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a new outbound (SPD-S) cache entry is created, along with outbound and inbound SAD entries, otherwise the packet is discarded. (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it MAY be processed against the newly created cache entry, if one is created.) Since SAs are created in pairs, an SAD entry for the corresponding inbound SA also is created, and it contains the selector values derived from the SPD entry (and packet, if any PFP flags were "true") used to create the inbound SA, for use in checking inbound traffic delivered via the SA.
3b。キャッシュに一致が見つからない場合は、SPD-IDで指定されたSPD（SPD-SおよびSPD-Oパーツ）を検索します。SPDエントリがバイパスまたは破棄を必要とする場合は、1つ以上の新しいアウトバウンドSPDキャッシュエントリを作成し、バイパスする場合は、1つ以上の新しいインバウンドSPDキャッシュエントリを作成します。（非相関SPDエントリは、非相関プロセスの副作用として作成された他のそのようなエントリにリンクされている可能性があるため、複数のキャッシュエントリが作成される場合があります。）SPDエントリが保護、つまりSAの作成、つまりSA、作成、主要な管理メカニズム（IKEV2など）が呼び出され、SAを作成します。SAの作成が成功した場合、新しいアウトバウンド（SPD-S）キャッシュエントリが作成され、アウトバウンドとインバウンドの悲しいエントリが作成されます。そうしないと、パケットが破棄されます。（SPDルックアップをトリガーするパケットは、実装によって破棄される場合があるか、新しく作成されたキャッシュエントリに対して処理される場合があります。作成された、SAを介して配信されるインバウンドトラフィックをチェックするために使用されるInbound SAの作成に使用されるSPDエントリ（およびパケットの「真」の場合、パケット）から派生したセレクター値が含まれています。
4. The packet is passed to the outbound forwarding function (operating outside of the IPsec implementation), to select the interface to which the packet will be directed. This function may cause the packet to be passed back across the IPsec boundary, for additional IPsec processing, e.g., in support of nested SAs. If so, there MUST be an entry in SPD-I database that permits inbound bypassing of the packet, otherwise the packet will be discarded. If necessary, i.e., if there is more than one SPD-I, the traffic being looped back MAY be tagged as coming from this internal interface. This would allow the use of a different SPD-I for "real" external traffic vs. looped traffic, if needed.
4. パケットは、パケットが指示されるインターフェイスを選択するために、アウトバウンド転送機能（IPSEC実装外で動作）に渡されます。この関数は、ネストされたSASをサポートして、追加のIPSEC処理のために、パケットをIPSEC境界全体に渡される可能性があります。その場合、Packetのインバウンドバイパスを許可するSPD-Iデータベースにエントリがある必要があります。そうしないと、パケットが破棄されます。必要に応じて、つまり、複数のSPD-Iがある場合、ループされるトラフィックのタグ付けは、この内部インターフェイスから来るとタグ付けされる場合があります。これにより、必要に応じて、「実際の」外部トラフィックとループトラフィックに異なるSPD-Iを使用することができます。
Note: With the exception of IPv4 and IPv6 transport mode, an SG, BITS, or BITW implementation MAY fragment packets before applying IPsec. (This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.) The device SHOULD have a configuration setting to disable this. The resulting fragments are evaluated against the SPD in the normal manner. Thus, fragments not containing port numbers (or ICMP message type and code, or Mobility Header type) will only match rules having port (or ICMP message type and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for more details.)
注：IPv4およびIPv6トランスポートモードを除き、IPSECを適用する前に、SG、BITS、またはBITWの実装がパケットをフラグメントする場合があります。（これはIPv4にのみ適用されます。IPv6パケットの場合、オリジネーターのみがそれらをフラグメントすることができます。）デバイスには、これを無効にするための構成設定が必要です。結果のフラグメントは、通常の方法でSPDに対して評価されます。したがって、ポート番号（またはICMPメッセージタイプとコード、またはモビリティヘッダータイプ）を含むフラグメントは、ポート（またはICMPメッセージタイプとコード、またはMHタイプ）の不透明なセレクターを持つルールのみと一致します。（詳細については、セクション7を参照してください。）
Note: With regard to determining and enforcing the PMTU of an SA, the IPsec system MUST follow the steps described in Section 8.2.
注：SAのPMTUの決定と実施に関して、IPSECシステムはセクション8.2で説明されている手順に従う必要があります。
If an IPsec system receives an outbound packet that it finds it must discard, it SHOULD be capable of generating and sending an ICMP message to indicate to the sender of the outbound packet that the packet was discarded. The type and code of the ICMP message will depend on the reason for discarding the packet, as specified below. The reason SHOULD be recorded in the audit log. The audit log entry for this event SHOULD include the reason, current date/time, and the selector values from the packet.
IPSECシステムが廃棄しなければならないと判断したアウトバウンドパケットを受信した場合、パケットが破棄されたことをアウトバウンドパケットの送信者に示すためにICMPメッセージを生成および送信できるはずです。ICMPメッセージのタイプとコードは、以下に指定されているように、パケットを破棄する理由に依存します。その理由は、監査ログに記録する必要があります。このイベントの監査ログエントリには、パケットからの理由、現在の日付/時間、およびセレクター値を含める必要があります。
a. The selectors of the packet matched an SPD entry requiring the packet to be discarded.
a. パケットのセレクターは、パケットを破棄する必要があるSPDエントリと一致しました。
IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)
IPv4タイプ= 3（宛先の到達不能）コード= 13（管理上禁止）
IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)
IPv6タイプ= 1（宛先の到達不能）コード= 1（管理的に禁止されている目的地との通信）
b1. The IPsec system successfully reached the remote peer but was unable to negotiate the SA required by the SPD entry matching the packet because, for example, the remote peer is administratively prohibited from communicating with the initiator, the initiating peer was unable to authenticate itself to the remote peer, the remote peer was unable to authenticate itself to the initiating peer, or the SPD at the remote peer did not have a suitable entry.
B1。IPSECシステムはリモートピアに正常に到達しましたが、パケットに一致するSPDエントリに必要なSAと交渉することができませんでした。たとえば、リモートピアはイニシエーターと通信することを管理的に禁止しているため、開始ピアは自分自身を認証することができませんでした。リモートピア、リモートピアは開始ピアに認証することができませんでした。または、リモートピアのSPDには適切なエントリがありませんでした。
IPv4 Type = 3 (destination unreachable) Code = 13 (Communication Administratively Prohibited)
IPv4タイプ= 3（宛先の到達不能）コード= 13（管理上禁止）
IPv6 Type = 1 (destination unreachable) Code = 1 (Communication with destination administratively prohibited)
IPv6タイプ= 1（宛先の到達不能）コード= 1（管理的に禁止されている目的地との通信）
b2. The IPsec system was unable to set up the SA required by the SPD entry matching the packet because the IPsec peer at the other end of the exchange could not be contacted.
B2。IPSECシステムは、交換のもう一方の端でのIPSECピアに接触できなかったため、パケットに一致するSPDエントリに必要なSAを設定できませんでした。
IPv4 Type = 3 (destination unreachable) Code = 1 (host unreachable)
IPv4 Type = 3（宛先の到達不可）コード= 1（到達不可能なホスト）
IPv6 Type = 1 (destination unreachable) Code = 3 (address unreachable)
IPv6タイプ= 1（宛先の到達不能）コード= 3（到達不可能なアドレス）
Note that an attacker behind a security gateway could send packets with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to W.X.Y.Z. This creates an opportunity for a denial of service (DoS) attack among hosts behind a security gateway. To address this, a security gateway SHOULD include a management control to allow an administrator to configure an IPsec implementation to send or not send the ICMP messages under these circumstances, and if this facility is selected, to rate limit the transmission of such ICMP responses.
セキュリティゲートウェイの背後にある攻撃者は、スプーフィングされたソースアドレスW.X.Y.Zを備えたパケットをIPSECエンティティに送信することができることに注意してください。これにより、セキュリティゲートウェイの背後にあるホストの間でサービス拒否（DOS）攻撃の機会が生まれます。これに対処するために、セキュリティゲートウェイには、管理者がこれらの状況に基づいてICMPメッセージを送信または送信しないようにIPSEC実装を構成できるようにするための管理制御を含める必要があります。
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels, with regard to outbound traffic processing. This includes how to construct the encapsulating (outer) IP header, how to process fields in the inner IP header, and what other actions should be taken for outbound, tunnel mode traffic. The general processing described here is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
このセクションでは、アウトバウンドトラフィック処理に関して、AHおよびESPトンネルの内側および外側のIPヘッダー、拡張ヘッダー、およびオプションの処理について説明します。これには、カプセル化（外側）IPヘッダーの構築方法、内側のIPヘッダーでフィールドを処理する方法、およびアウトバウンドのトンネルモードトラフィックに対して他のアクションを実行する方法が含まれます。ここで説明する一般的な処理は、RFC 2003「IP内のIPカプセル化」[PER96]の後にモデル化されています。
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.
o 外側のIPヘッダーソースアドレスと宛先アドレスは、トンネルの「エンドポイント」（カプセレータと脱カプセレータ）を識別します。内側のIPヘッダーソースアドレスと宛先アドレスは、それぞれ（このトンネルの観点から）データグラムの元の送信者と受信者を識別します。
(See footnote 3 after the table in 5.1.2.1 for more details on the encapsulating source IP address.)
（5.1.2.1のテーブルの後の脚注3を参照してください。ソースIPアドレスのカプセル化の詳細をご覧ください。）
o The inner IP header is not changed except as noted below for TTL (or Hop Limit) and the DS/ECN Fields. The inner IP header otherwise remains unchanged during its delivery to the tunnel exit point.
o 内側のIPヘッダーは、TTL（またはホップ制限）およびDS/ECNフィールドについて以下に示すように変更されません。それ以外の場合は、内側のIPヘッダーは、トンネル出口ポイントへの配信中に変更されません。
o No change to IP options or extension headers in the inner header occurs during delivery of the encapsulated datagram through the tunnel.
o 内側ヘッダーのIPオプションまたは拡張ヘッダーに変更はありません。トンネルを介したカプセル化されたデータグラムの配信中に発生します。
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2003 [Per96]) in several ways:
注：IPSECトンネルモードは、いくつかの方法でIP-in-IPトンネリング（RFC 2003 [Per96]）とは異なります。
o IPsec offers certain controls to a security administrator to manage covert channels (which would not normally be a concern for tunneling) and to ensure that the receiver examines the right portions of the received packet with respect to application of access controls. An IPsec implementation MAY be configurable with regard to how it processes the outer DS field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for the outer DS field will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the outer DS field to be mapped to a fixed value, which MAY be configured on a per-SA basis. (The value might really be fixed for all traffic outbound from a device, but per-SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying.
o IPSECは、セキュリティ管理者に特定のコントロールを提供して、カバーチャネルを管理し（通常はトンネリングの懸念ではありません）、受信者がアクセス制御の適用に関して受信したパケットの適切な部分を調べることを確認します。IPSECの実装は、送信されたパケット用のトンネルモードの外側DSフィールドをどのように処理するかに関して構成可能である場合があります。アウトバウンドトラフィックの場合、外側のDSフィールドの1つの構成設定は、IPSECトンネルのIPv4およびIPv6ヘッダー処理に関する次のセクションで説明されているように動作します。もう1つは、外側のDSフィールドを固定値にマッピングできるようにします。（値は、デバイスからのすべてのトラフィックに対して実際に固定される可能性がありますが、SAあたりの粒度性も可能です。）この構成オプションにより、ローカル管理者は、これらのビットをコピーすることで提供されるカバーチャネルがコピーの利点を上回るかどうかを判断できます。
o IPsec describes how to handle ECN or DS and provides the ability to control propagation of changes in these fields between unprotected and protected domains. In general, propagation from a protected to an unprotected domain is a covert channel and thus controls are provided to manage the bandwidth of this channel. Propagation of ECN values in the other direction are controlled so that only legitimate ECN changes (indicating occurrence of congestion between the tunnel endpoints) are propagated. By default, DS propagation from an unprotected domain to a protected domain is not permitted. However, if the sender and receiver do not share the same DS code space, and the receiver has no way of learning how to map between the two spaces, then it may be appropriate to deviate from the default. Specifically, an IPsec implementation MAY be configurable in terms of how it processes the outer DS field for tunnel mode for received packets. It may be configured to either discard the outer DS value (the default) OR to overwrite the inner DS field with the outer DS field. If offered, the discard vs. overwrite behavior MAY be configured on a per-SA basis. This configuration option allows a local administrator to decide whether the vulnerabilities created by copying these bits outweigh the benefits of copying. See [RFC2983] for further information on when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to IPsec processing (including tunnel decapsulation).
o IPSECは、ECNまたはDSを処理する方法を説明し、保護されていないドメインと保護されたドメイン間のこれらのフィールドの変化の伝播を制御する機能を提供します。一般に、保護されていないドメインから保護されていないドメインへの伝播は秘密のチャネルであるため、このチャネルの帯域幅を管理するためにコントロールが提供されます。反対方向のECN値の伝播が制御されるため、正当なECNの変化のみ（トンネルエンドポイント間の輻輳の発生を示す）が伝播されます。デフォルトでは、保護されていないドメインから保護されたドメインへのDS伝播は許可されていません。ただし、送信者とレシーバーが同じDSコードスペースを共有しておらず、受信機が2つのスペース間でマッピングする方法を学習する方法がない場合、デフォルトから逸脱することが適切かもしれません。具体的には、IPSECの実装は、受信パケットのトンネルモードの外側のDSフィールドをどのように処理するかという点で構成可能である場合があります。外側のDS値（デフォルト）を破棄するか、内側のDSフィールドを外側のDSフィールドで上書きするように構成されている場合があります。提供された場合、廃棄と上書きの動作は、SAごとに構成できます。この構成オプションにより、ローカル管理者は、これらのビットをコピーすることで作成された脆弱性がコピーの利点を上回るかどうかを判断できます。[RFC2983]を参照してください。これらの各動作がいつ役立つかについての詳細については、また、IPSEC処理（トンネル脱カプセル化を含む）の前またはその後のDiffServトラフィックコンディショニングの必要性についても必要です。
o IPsec allows the IP version of the encapsulating header to be different from that of the inner header.
o IPSECを使用すると、カプセル化ヘッダーのIPバージョンを内部ヘッダーのヘッダーとは異なることができます。
The tables in the following sub-sections show the handling for the different header/option fields ("constructed" means that 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
DS Field copied from inner hdr (5) no change
ECN Field copied from inner hdr constructed (6)
total length constructed no change
ID constructed no change
flags (DF,MF) constructed, DF (4) no change
fragment offset constructed no change
TTL constructed (2) decrement (2)
protocol AH, ESP no change
checksum constructed constructed (2)(6)
src address constructed (3) no change
dest address constructed (3) no change
Options never copied no change
Notes:
ノート：
(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 IPv4 checksum changes when the TTL changes.) Note: Decrementing the TTL value is a normal part of forwarding a packet. Thus, a packet originating from the same node as the encapsulator does not have its TTL decremented, since the sending node is originating the packet rather than forwarding it. This applies to BITS and native IPsec implementations in hosts and routers. However, the IPsec processing model includes an external forwarding capability. TTL processing can be used to prevent looping of packets, e.g., due to configuration errors, within the context of this processing model.
(2) 内側のヘッダーのTTLは、転送前のエンコプセーターと、パケットを転送する場合は脱カプセレータによって減少します。（TTLが変更されるとIPv4チェックサムが変更されます。）注：TTL値の減少は、パケットの転送の通常の部分です。したがって、送信ノードがパケットを転送するのではなくパケットを発信しているため、エンコプセーターと同じノードから発信されるパケットはTTLを減少させません。これは、ホストとルーターのビットおよびネイティブIPSEC実装に適用されます。ただし、IPSEC処理モデルには、外部転送機能が含まれています。TTL処理は、この処理モデルのコンテキスト内で、構成エラーのために、パケットのループを防ぐために使用できます。
(3) Local and Remote addresses depend on the SA, which is used to determine the Remote address, which in turn determines which Local address (net interface) is used to forward the packet.
(3) ローカルおよびリモートアドレスは、リモートアドレスを決定するために使用されるSAに依存します。これは、パケットを転送するためにどのローカルアドレス（ネットインターフェイス）が使用されるかを決定します。
Note: For multicast traffic, the destination address, or source and destination addresses, may be required for demuxing. In that case, it is important to ensure consistency over the lifetime of the SA by ensuring that the source address that appears in the encapsulating tunnel header is the same as the one that was negotiated during the SA establishment process. There is an exception to this general rule, i.e., a mobile IPsec implementation will update its source address as it moves.
注：マルチキャストトラフィックの場合、宛先アドレス、またはソースおよび宛先のアドレスがデモで必要になる場合があります。その場合、カプセル化トンネルヘッダーに表示されるソースアドレスがSAの確立プロセス中に交渉されたものと同じであることを確認することにより、SAの寿命を帯びた一貫性を確保することが重要です。この一般的なルールには例外があります。つまり、モバイルIPSECの実装により、移動中のソースアドレスが更新されます。
(4) Configuration determines whether to copy from the inner header (IPv4 only), clear, or set the DF.
(4) 構成は、内側のヘッダー（IPv4のみ）からコピーするか、DFをクリアするか、設定するかを決定します。
(5) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further information.
(5) パケットがすぐに外側ヘッダーのDSCP値が適切でないドメインを入力する場合、その値はドメインの適切な値にマッピングする必要があります[Niblbabl98]。詳細については、RFC 2475 [BBCDWW98]を参照してください。
(6) If the ECN field in the inner header is set to ECT(0) or ECT(1), where ECT is ECN-Capable Transport (ECT), and if the ECN field in the outer header is set to Congestion Experienced (CE), then set the ECN field in the inner header to CE; otherwise, make no change to the ECN field in the inner header. (The IPv4 checksum changes when the ECN changes.)
(6) 内側のヘッダーのECNフィールドがECT（0）またはECT（1）に設定されている場合、ECTはECN対応輸送（ECT）であり、外側ヘッダーのECNフィールドが輻輳の経験豊富（CE）に設定されている場合、次に、内側のヘッダーにECNフィールドをCEに設定します。それ以外の場合は、内側ヘッダーのECNフィールドに変更を加えません。（ECNが変更されると、IPv4チェックサムが変更されます。）
Note: IPsec does not copy the options from the inner header into the outer header, nor does IPsec construct the options in the outer header. However, post-IPsec code MAY insert/construct options for the outer header.
注：IPSECは、オプションを内側ヘッダーから外側ヘッダーにコピーせず、IPSECが外側ヘッダーにオプションを構築しません。ただし、Post-IPECコードは、外側ヘッダーのオプションを挿入/構築する場合があります。
<-- How Outer Hdr Relates Inner Hdr --->
Outer Hdr at Inner Hdr at
IPv6 Encapsulator Decapsulator
Header fields: -------------------- ------------
version 6 (1) no change
DS Field copied from inner hdr (5) no change (9)
ECN Field copied from inner hdr constructed (6)
flow label copied or configured (8) no change
payload length 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 (7) no change
Notes:
ノート：
(1) - (6) See Section 5.1.2.1.
(1) - （6）セクション5.1.2.1を参照してください。
(7) IPsec does not copy the extension headers from the inner packet into outer headers, nor does IPsec construct extension headers in the outer header. However, post-IPsec code MAY insert/construct extension headers for the outer header.
(7) IPSECは、内側のパケットから外側のヘッダーに拡張ヘッダーをコピーせず、IPSECは外側ヘッダーに拡張ヘッダーを構築しません。ただし、Post-IPECコードは、外側ヘッダーの拡張ヘッダーを挿入/構築する場合があります。
(8) See [RaCoCaDe04]. Copying is acceptable only for end systems, not SGs. If an SG copied flow labels from the inner header to the outer header, collisions might result.
(8) [racocade04]を参照してください。コピーは、SGSではなく、エンドシステムに対してのみ受け入れられます。SGが内側のヘッダーから外側のヘッダーにコピーされたフローラベルをコピーすると、衝突が発生する可能性があります。
(9) An implementation MAY choose to provide a facility to pass the DS value from the outer header to the inner header, on a per-SA basis, for received tunnel mode packets. The motivation for providing this feature is to accommodate situations in which the DS code space at the receiver is different from that of the sender and the receiver has no way of knowing how to translate from the sender's space. There is a danger in copying this value from the outer header to the inner header, since it enables an attacker to modify the outer DSCP value in a fashion that may adversely affect other traffic at the receiver. Hence the default behavior for IPsec implementations is NOT to permit such copying.
(9) 実装は、受信したトンネルモードパケットに対して、SAごとに外部ヘッダーから内側ヘッダーにDS値を渡す機能を提供することを選択できます。この機能を提供する動機は、受信機のDSコードスペースが送信者のそれとは異なり、受信者が送信者のスペースから翻訳する方法を知る方法を知ることができない状況に対応することです。攻撃者がレシーバーの他のトラフィックに悪影響を与える可能性のあるファッションで外側のDSCP値を変更できるようにするため、この値を外側ヘッダーから内側ヘッダーにコピーすることには危険があります。したがって、IPSEC実装のデフォルトの動作は、そのようなコピーを許可することではありません。
Inbound processing is somewhat different from outbound processing, because of the use of SPIs to map IPsec-protected traffic to SAs. The inbound SPD cache (SPD-I) is applied only to bypassed or discarded traffic. If an arriving packet appears to be an IPsec fragment from an unprotected interface, reassembly is performed prior to IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded.
IPSECで保護されたトラフィックをSASにマッピングするためにSPIを使用するため、インバウンド処理はアウトバウンド処理とは多少異なります。インバウンドSPDキャッシュ（SPD-I）は、バイパスまたは破棄されたトラフィックにのみ適用されます。到着するパケットが保護されていないインターフェイスからのIPSECフラグメントのように見える場合、IPSEC処理の前に再組み立てが実行されます。SPDキャッシュの意図は、エントリと一致しないパケットが対応するSPDと呼ばれることです。すべてのSPDには、それ以外の場合は比類のないものをキャッチし、それを破棄する名目上の最終エントリを持つ必要があります。これにより、SPD-Iエントリが到着し、一致しない非IPSECで保護されていないトラフィックが破棄されます。
Unprotected Interface
|
V
+-----+ IPsec protected
------------------->|Demux|-------------------+
| +-----+ |
| | |
| Not IPsec | |
| | |
| V |
| +-------+ +---------+ |
| |DISCARD|<---|SPD-I (*)| |
| +-------+ +---------+ |
| | |
| |-----+ |
| | | |
| | V |
| | +------+ |
| | | ICMP | |
| | +------+ |
| | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | Boundary
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
nested SAs +----------+ | (***) | +----+
| +---------+
V
Protected Interface
Figure 3. Processing Model for Inbound Traffic
図3.インバウンドトラフィックの処理モデル
(*) = The caches are shown here. If there is
a cache miss, then the SPD is checked.
There is no requirement that an
implementation buffer the packet if
there is a cache miss.
(**) = This processing includes using the
packet's SPI, etc., to look up the SA
in the SAD, which forms a cache of the
SPD for inbound packets (except for
cases noted in Sections 4.4.2 and 5).
See step 3a below.
(***) = This SAD check refers to step 4 below.
Prior to performing AH or ESP processing, any IP fragments that arrive via the unprotected interface are reassembled (by IP). 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 a next layer protocol in the IPv6 context).
AHまたはESP処理を実行する前に、保護されていないインターフェイスを介して到着するIPフラグメントは（IPによって）再組み立てされます。IPSEC処理が適用される各インバウンドIPデータグラムは、IP次のプロトコルフィールド（またはIPv6コンテキストの次のレイヤープロトコルとしてのAHまたはESPのAHまたはESP値の外観によって識別されます。
IPsec MUST perform the following steps:
IPSECは次の手順を実行する必要があります。
1. When a packet arrives, it may be tagged with the ID of the interface (physical or virtual) via which it arrived, if necessary, to support multiple SPDs and associated SPD-I caches. (The interface ID is mapped to a corresponding SPD-ID.)
1. パケットが到着すると、複数のSPDと関連するSPD-Iキャッシュをサポートするために、必要に応じて到着したインターフェイス（物理的または仮想）のIDでタグ付けされる場合があります。（インターフェイスIDは、対応するSPD-IDにマッピングされます。）
2. The packet is examined and demuxed into one of two categories: - If the packet appears to be IPsec protected and it is addressed to this device, an attempt is made to map it to an active SA via the SAD. Note that the device may have multiple IP addresses that may be used in the SAD lookup, e.g., in the case of protocols such as SCTP. - Traffic not addressed to this device, or addressed to this device and not AH or ESP, is directed to SPD-I lookup. (This implies that IKE traffic MUST have an explicit BYPASS entry in the SPD.) If multiple SPDs are employed, the tag assigned to the packet in step 1 is used to select the appropriate SPD-I (and cache) to search. SPD-I lookup determines whether the action is DISCARD or BYPASS.
2. パケットは検査され、2つのカテゴリのいずれかに分類されます。-パケットがIPSECの保護されているように見える場合、このデバイスに宛てられた場合、SADを介してアクティブなSAにマッピングする試みが行われます。デバイスには、SCTPなどのプロトコルの場合、SADルックアップで使用される可能性のある複数のIPアドレスがある場合があることに注意してください。 - このデバイスには対処されていない、またはAHまたはESPではなくこのデバイスに宛てられていないトラフィックは、SPD-I検索に向けられています。（これは、IKEトラフィックにSPDに明示的なバイパスエントリが必要であることを意味します。）複数のSPDが使用されている場合、ステップ1のパケットに割り当てられたタグを使用して、検索する適切なSPD-I（およびキャッシュ）を選択します。SPD-I Lookupは、アクションが廃棄またはバイパスされているかどうかを決定します。
3a. If the packet is addressed to the IPsec device and AH or ESP is specified as the protocol, the packet is looked up in the SAD. For unicast traffic, use only the SPI (or SPI plus protocol). For multicast traffic, use the SPI plus the destination or SPI plus destination and source addresses, as specified in Section 4.1. In either case (unicast or multicast), if there is no match, discard the traffic. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI, source and destination of the packet, IPsec protocol, and any other selector values of the packet that are available. If the packet is found in the SAD, process it accordingly (see step 4).
3a。パケットがIPSECデバイスに宛てられ、AHまたはESPがプロトコルとして指定されている場合、パケットはSADで検索されます。ユニキャストトラフィックの場合、SPI（またはSPI Plusプロトコル）のみを使用します。マルチキャストトラフィックの場合、セクション4.1で指定されているように、SPIプラス宛先またはSPIプラス宛先およびソースアドレスを使用します。どちらの場合でも（ユニキャストまたはマルチキャスト）、一致していない場合は、トラフィックを破棄します。これは監査可能なイベントです。このイベントの監査ログエントリには、パケットの現在の日付/時刻、SPI、ソースと宛先、IPSECプロトコル、および使用可能なパケットのその他のセレクター値を含める必要があります。パケットがSADで見つかった場合は、それに応じて処理します（ステップ4を参照）。
3b. If the packet is not addressed to the device or is addressed to this device and is not AH or ESP, look up the packet header in the (appropriate) SPD-I cache. If there is a match and the packet is to be discarded or bypassed, do so. If there is no cache match, look up the packet in the corresponding SPD-I and create a cache entry as appropriate. (No SAs are created in response to receipt of a packet that requires IPsec protection; only BYPASS or DISCARD cache entries can be created this way.) If there is no match, discard the traffic. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI if available, IPsec protocol if available, source and destination of the packet, and any other selector values of the packet that are available.
3b。パケットがデバイスにアドレス指定されないか、このデバイスにアドレス指定され、AHまたはESPではない場合は、（適切な）SPD-Iキャッシュのパケットヘッダーを調べてください。一致があり、パケットを破棄またはバイパスする場合は、そうしてください。キャッシュの一致がない場合は、対応するSPD-Iのパケットを調べ、必要に応じてキャッシュエントリを作成します。（IPSEC保護を必要とするパケットの受領に応じてSASは作成されません。この方法でキャッシュエントリのバイパスまたは破棄のみを作成できます。）一致しない場合は、トラフィックを破棄します。これは監査可能なイベントです。このイベントの監査ログエントリには、現在の日付/時刻、利用可能な場合はSPI、利用可能な場合はIPSECプロトコル、パケットのソースと宛先、および使用可能なパケットのその他のセレクター値を含める必要があります。
3c. Processing of ICMP messages is assumed to take place on the unprotected side of the IPsec boundary. Unprotected ICMP messages are examined and local policy is applied to determine whether to accept or reject these messages and, if accepted, what action to take as a result. For example, if an ICMP unreachable message is received, the implementation must decide whether to act on it, reject it, or act on it with constraints. (See Section 6.)
3c。ICMPメッセージの処理は、IPSEC境界の保護されていない側で行われると想定されています。保護されていないICMPメッセージを検討し、ローカルポリシーを適用して、これらのメッセージを受け入れるか拒否するか、そして受け入れられた場合、結果としてどのような行動をとるかを判断します。たとえば、ICMPの到達不可能なメッセージが受信された場合、実装は、制約で行動するか、拒否するか、または制約で行動するかを決定する必要があります。（セクション6を参照）
4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received.
4. 上記のステップ3Aで選択された悲しいエントリを使用して、指定されたAHまたはESP処理を適用します。次に、SADエントリによって識別されたインバウンドセレクターとパケットを一致させ、受信したパケットが受信したSAに適していることを確認します。
5. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet. This is an auditable event. The audit log entry for this event SHOULD include the current date/time, SPI, IPsec protocol(s), source and destination of the packet, any other selector values of the packet that are available, and the selector values from the relevant SAD entry. The system SHOULD also be capable of generating and sending an IKE notification of INVALID_SELECTORS to the sender (IPsec peer), indicating that the received packet was discarded because of failure to pass selector checks.
5. IPSECシステムがSAでインバウンドパケットを受信し、パケットのヘッダーフィールドがSAのセレクターと一致しない場合、パケットを破棄する必要があります。これは監査可能なイベントです。このイベントの監査ログエントリには、現在の日付/時刻、SPI、IPSECプロトコル、パケットのソースと宛先、使用可能なパケットのその他のセレクター値、および関連するSADエントリからのセレクター値を含める必要があります。。また、システムは、Invalid_SelectorsのIKE通知を送信者（IPSEC PEER）に生成および送信することもできます。
To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure the IPsec implementation to send or not send this IKE notification, and if this facility is selected, to rate limit the transmission of such notifications.
IPSECシステムには、DOS攻撃の影響、または誤って構成されたピアの影響を最小限に抑えるために、管理者がこのIKE通知を送信または送信しないようにIPSEC実装を構成できるようにする管理コントロールを含める必要があります。レートは、そのような通知の送信を制限します。
After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. This function may cause the packet to be sent (outbound) across the IPsec boundary for additional inbound IPsec processing, e.g., in support of nested SAs. If so, then as with ALL outbound traffic that is to be bypassed, the packet MUST be matched against an SPD-O entry. Ultimately, the packet should be forwarded to the destination host or process for disposition.
トラフィックがIPSECを介してバイパスまたは処理された後、処分のためにインバウンド転送機能に渡されます。この関数は、追加のインバウンドIPSEC処理、たとえばネストされたSASをサポートするために、IPSEC境界全体にパケットを送信（アウトバウンド）する場合があります。もしそうなら、バイパスされるすべてのアウトバウンドトラフィックと同様に、パケットはSPD-Oエントリと一致する必要があります。最終的に、パケットは宛先ホストまたは処分のためにプロセスに転送する必要があります。
This section describes IPsec handling of ICMP traffic. There are two categories of ICMP traffic: error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Disposition of non-error, ICMP messages (that are not addressed to the IPsec implementation itself) MUST be explicitly accounted for using SPD entries.
このセクションでは、ICMPトラフィックのIPSEC処理について説明します。ICMPトラフィックには2つのカテゴリがあります：エラーメッセージ（例：Type =宛先の到達不可）と非誤差メッセージ（例：Type = echo）。このセクションでは、エラーメッセージのみに適用されます。非エラーの処分、ICMPメッセージ（IPSEC実装自体に対処されていない）は、SPDエントリの使用について明示的に説明する必要があります。
The discussion in this section applies to ICMPv6 as well as to ICMPv4. Also, a mechanism SHOULD be provided to allow an administrator to cause ICMP error messages (selected, all, or none) to be logged as an aid to problem diagnosis.
このセクションの議論は、ICMPv6とICMPV4に適用されます。また、管理者がICMPエラーメッセージ（選択された、すべて、またはなし）を問題診断の援助として記録できるようにするためのメカニズムを提供する必要があります。
Figure 3 in Section 5.2 shows a distinct ICMP processing module on the unprotected side of the IPsec boundary, for processing ICMP messages (error or otherwise) that are addressed to the IPsec device and that are not protected via AH or ESP. An ICMP message of this sort is unauthenticated, and its processing may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus, there is also a motivation for accepting and acting upon unauthenticated ICMP messages.
セクション5.2の図3は、IPSEC境界の保護されていない側の個別のICMP処理モジュールを示しています。これは、IPSECデバイスにアドレス指定され、AHまたはESPを介して保護されていないICMPメッセージ（エラーまたはその他）を処理します。この種のICMPメッセージは認識されておらず、その処理はサービスの否定または劣化をもたらす可能性があります。これは、一般に、そのようなメッセージを無視することが望ましいことを示唆しています。ただし、多くのICMPメッセージは、公開インターネットのルーターなど、無許可のソースからホストまたはセキュリティゲートウェイによって受信されます。これらのICMPメッセージを無視すると、PMTUメッセージとリダイレクトメッセージの処理に失敗したため、サービスを分解する可能性があります。したがって、認識されていないICMPメッセージを受け入れ、行動する動機もあります。
To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size.
このスペクトルの両端に対応するには、準拠したIPSEC実装により、ローカル管理者がIPSEC実装を構成して、認識されていないICMPトラフィックを受け入れるか拒否することを許可する必要があります。この制御は、ICMPタイプの粒度にある必要があり、ICMPタイプとコードの粒度にある場合があります。さらに、実装には、そのようなトラフィックを処理するためのメカニズムとパラメーターを組み込む必要があります。たとえば、認可されていないICMPの受領がPMTUを些細なサイズに設定するのを防ぐために、トラフィックごとに最小PMTUを確立する機能がある可能性があります。
If an ICMP PMTU message passes the checks above and the system is configured to accept it, then there are two possibilities. If the implementation applies fragmentation on the ciphertext side of the boundary, then the accepted PMTU information is passed to the forwarding module (outside of the IPsec implementation), which uses it to manage outbound packet fragmentation. If the implementation is configured to effect plaintext side fragmentation, then the PMTU information is passed to the plaintext side and processed as described in Section 8.2.
ICMP PMTUメッセージが上記のチェックに合格し、システムがそれを受け入れるように構成されている場合、2つの可能性があります。実装が境界の暗号文の断片化を適用すると、受け入れられたPMTU情報が転送モジュール（IPSEC実装以外）に渡され、それを使用してアウトバウンドパケットの断片化を管理します。実装がプレーンテキスト側の断片化を実施するように構成されている場合、PMTU情報はプレーンテキスト側に渡され、セクション8.2で説明されているように処理されます。
These ICMP messages are not authenticated, but they do come from sources on the protected side of the IPsec boundary. Thus, these messages generally are viewed as more "trustworthy" than their counterparts arriving from sources on the unprotected side of the boundary. The major security concern here is that a compromised host or router might emit erroneous ICMP error messages that could degrade service for other devices "behind" the security gateway, or that could even result in violations of confidentiality. For example, if a bogus ICMP redirect were consumed by a security gateway, it could cause the forwarding table on the protected side of the boundary to be modified so as to deliver traffic to an inappropriate destination "behind" the gateway. Thus, implementers MUST provide controls to allow local administrators to constrain the processing of ICMP error messages received on the protected side of the boundary, and directed to the IPsec implementation. These controls are of the same type as those employed on the unprotected side, described above in Section 6.1.1.
これらのICMPメッセージは認証されていませんが、IPSEC境界の保護された側のソースから来ています。したがって、これらのメッセージは一般に、境界の保護されていない側のソースから到着するカウンターパートよりも「信頼できる」ものと見なされます。ここでの主なセキュリティ上の懸念は、侵害されたホストまたはルーターが、「セキュリティゲートウェイの背後にある他のデバイスのサービスを分解できる、または機密性の違反につながる可能性のある誤ったICMPエラーメッセージを放出する可能性があることです。たとえば、偽のICMPリダイレクトがセキュリティゲートウェイによって消費された場合、境界の保護された側の転送テーブルが変更され、「ゲートウェイ」の背後にある「不適切な宛先」にトラフィックを届けることができます。したがって、実装者は、ローカル管理者が境界の保護された側で受信されたICMPエラーメッセージの処理を制限し、IPSEC実装に向けてコントロールを提供する必要があります。これらのコントロールは、上記のセクション6.1.1で説明されている保護されていない側で採用されているものと同じタイプです。
When an ICMP error message is transmitted via an SA to a device "behind" an IPsec implementation, both the payload and the header of the ICMP message require checking from an access control perspective. If one of these messages is forwarded to a host behind a security gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus, an IPsec implementation MUST be configurable to check that this payload header information is consistent with the SA via which it arrives. (This means that the payload header, with source and destination address and port fields reversed, matches the traffic selectors for the SA.) If this sort of check is not performed, then, for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP Destination Unreachable message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack regarding communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. However, not all contexts may require such checks, so it is also necessary to allow a local administrator to configure an implementation to NOT perform such checks.
ICMPエラーメッセージがIPSEC実装の「背後」のデバイスにSAを介して送信されると、ペイロードとICMPメッセージのヘッダーの両方がアクセス制御の観点からチェックする必要があります。これらのメッセージのいずれかがセキュリティゲートウェイの背後にあるホストに転送された場合、受信ホストIP実装はペイロード、つまりエラー応答をトリガーしたとされるパケットのヘッダーに基づいて決定を下します。したがって、IPSECの実装は、このペイロードヘッダー情報が到着するSAと一致していることを確認するために設定可能でなければなりません。（これは、ソースおよび宛先アドレスとポートフィールドが逆になっているペイロードヘッダーがSAのトラフィックセレクターと一致することを意味します。）この種のチェックが実行されない場合、たとえば、受信IPSECシステム（）アクティブなSAは、Aが現在通信しているホスト/ネットを指すICMP宛先の到達不可能なメッセージを送信することができます。そのような攻撃から保護するのに十分です。ただし、すべてのコンテキストがそのようなチェックを必要とするわけではないため、ローカル管理者がそのようなチェックを実行しないように実装を構成できるようにする必要もあります。
To accommodate both policies, the following convention is adopted. If an administrator wants to allow ICMP error messages to be carried by an SA without inspection of the payload, then configure an SPD entry that explicitly allows for carriage of such traffic. If an administrator wants IPsec to check the payload of ICMP error messages for consistency, then do not create any SPD entries that accommodate carriage of such traffic based on the ICMP packet header. This convention motivates the following processing description.
両方のポリシーに対応するために、次の条約が採用されています。管理者が、ペイロードを検査せずにICMPエラーメッセージをSAによって携帯することを許可したい場合は、そのようなトラフィックのキャリッジを明示的に許可するSPDエントリを構成します。管理者がIPSECにICMPエラーメッセージのペイロードを一貫性を確認することを望んでいる場合、ICMPパケットヘッダーに基づいてそのようなトラフィックのキャリッジに対応するSPDエントリを作成しないでください。この条約は、次の処理の説明を動機付けます。
IPsec senders and receivers MUST support the following processing for ICMP error messages that are sent and received via SAs.
IPSEC送信者と受信機は、SASを介して送信および受信されるICMPエラーメッセージの次の処理をサポートする必要があります。
If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic. If no SA exists that matches the traffic selectors associated with an ICMP error message, then the SPD is searched to determine if such an SA can be created. If so, the SA is created and the ICMP error message is transmitted via that SA. Upon receipt, this message is subject to the usual traffic selector checks at the receiver. This processing is exactly what would happen for traffic in general, and thus does not represent any special processing for ICMP error messages.
アウトバウンドICMPエラーメッセージに対応するSAが存在する場合、メッセージはSAにマッピングされ、他のトラフィックの場合と同様に、IPおよびICMPヘッダーのみが受領時にチェックされます。ICMPエラーメッセージに関連付けられたトラフィックセレクターに一致するSAが存在しない場合、SPDは検索され、そのようなSAを作成できるかどうかを判断します。その場合、SAが作成され、ICMPエラーメッセージがそのSAを介して送信されます。受領すると、このメッセージは、レシーバーでの通常のトラフィックセレクターチェックの対象となります。この処理は、一般的にトラフィックに対して起こるものであるため、ICMPエラーメッセージの特別な処理を表すものではありません。
If no SA exists that would carry the outbound ICMP message in question, and if no SPD entry would allow carriage of this outbound ICMP error message, then an IPsec implementation MUST map the message to the SA that would carry the return traffic associated with the packet that triggered the ICMP error message. This requires an IPsec implementation to detect outbound ICMP error messages that map to no extant SA or SPD entry, and treat them specially with regard to SA creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). It then uses this extracted information to locate an appropriate, active outbound SA, and transmits the error message via this SA. If no such SA exists, no SA will be created, and this is an auditable event.
問題のアウトバウンドICMPメッセージを運ぶSAが存在しない場合、およびSPDエントリがこのアウトバウンドICMPエラーメッセージのキャリッジが許可されない場合、IPSEC実装は、パケットに関連付けられたリターントラフィックを運ぶメッセージをSAにマッピングする必要があります。これにより、ICMPエラーメッセージがトリガーされました。これには、現存するSAまたはSPDエントリなしにマッピングされたアウトバウンドICMPエラーメッセージを検出し、SAの作成と検索に関して特別に処理するIPSEC実装が必要です。実装は、（ICMPメッセージペイロードから）エラーをトリガーしたパケットのヘッダーを抽出し、ソースと宛先IPアドレスフィールドを逆転させ、プロトコルフィールドを抽出し、ポートフィールドを逆にします（アクセス可能な場合）。次に、この抽出された情報を使用して、適切なアクティブなアウトバウンドSAを見つけ、このSAを介してエラーメッセージを送信します。そのようなSAが存在しない場合、SAは作成されません。これは監査可能なイベントです。
If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which the ICMP error message was received. If the packet fails this check, the IPsec implementation MUST NOT forwarded the ICMP message to the destination. This is an auditable event.
IPSEC実装がSAでインバウンドICMPエラーメッセージを受信し、メッセージのIPおよびICMPヘッダーがSAのトラフィックセレクターと一致しない場合、受信者は受信メッセージを特別な方法で処理する必要があります。具体的には、受信機は、ICMPペイロードからトリガーパケットのヘッダーを抽出し、上記のように逆フィールドを抽出して、ICMPエラーメッセージを受信したSAのセレクターとパケットが一致しているかどうかを判断する必要があります。パケットがこのチェックに失敗した場合、IPSEC実装はICMPメッセージを宛先に転送してはなりません。これは監査可能なイベントです。
Earlier sections of this document describe mechanisms for (a) fragmenting an outbound packet after IPsec processing has been applied and reassembling it at the receiver before IPsec processing and (b) handling inbound fragments received from the unprotected side of the IPsec boundary. This section describes how an implementation should handle the processing of outbound plaintext fragments on the protected side of the IPsec boundary. (See Appendix D, "Fragment Handling Rationale".) In particular, it addresses:
このドキュメントの以前のセクションでは、（a）IPSEC処理後のアウトバウンドパケットの断片化メカニズムについて説明し、IPSEC処理の前に受信機でそれを再組み立てし、（b）IPSEC境界の保護されていない側面から受け取ったインバウンドフラグメントを処理します。このセクションでは、実装がiPSEC境界の保護された側のアウトバウンドプレーンテキストフラグメントの処理を処理する方法について説明します。（付録D、「断片の処理根拠」を参照してください。）特に、次のことを扱います。
o mapping an outbound non-initial fragment to the right SA (or finding the right SPD entry) o verifying that a received non-initial fragment is authorized for the SA via which it was received o mapping outbound and inbound non-initial fragments to the right SPD-O/SPD-I entry or the relevant cache entry, for BYPASS/DISCARD traffic
o 右のSAにアウトバウンドの非初心者フラグメントをマッピングします（または右のSPDエントリを見つける）o受信した非初心的なフラグメントが、右側のマッピングおよびインバウンドの非初心的なフラグメントをマッピングしたSAに対して許可されていることを確認するSPD-O/SPD-Iエントリまたは関連するキャッシュエントリ、バイパス/破棄トラフィック
Note: In Section 4.1, transport mode SAs have been defined to not carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two special values, ANY and OPAQUE, were defined for selectors and that ANY includes OPAQUE. The term "non-trivial" is used to mean that the selector has a value other than OPAQUE or ANY.
注：セクション4.1では、トランスポートモードSASがフラグメント（IPv4またはIPv6）を運ばないように定義されています。また、セクション4.4.1では、2つの特別な値、あらゆるものと不透明がセレクターに対して定義され、あらゆるものが不透明なことに注意してください。「非自明」という用語は、セレクターが不透明または任意以外の値を持っていることを意味するために使用されます。
Note: The term "non-initial fragment" is used here to indicate a fragment that does not contain all the selector values that may be needed for access control. As observed in Section 4.4.1, depending on the Next Layer Protocol, in addition to Ports, the ICMP message type/code or Mobility Header type could be missing from non-initial fragments. Also, for IPv6, even the first fragment might NOT contain the Next Layer Protocol or Ports (or ICMP message type/code, or Mobility Header type) depending on the kind and number of extension headers present. If a non-initial fragment contains the Port (or ICMP type and code or Mobility Header type) but not the Next Layer Protocol, then unless there is an SPD entry for the relevant Local/Remote addresses with ANY for Next Layer Protocol and Port (or ICMP type and code or Mobility Header type), the fragment would not contain all the selector information needed for access control.
注：「非独創的なフラグメント」という用語は、アクセス制御に必要なすべてのセレクター値を含まないフラグメントを示すためにここで使用されます。次のレイヤープロトコルに応じて、セクション4.4.1で観察されているように、ポートに加えて、ICMPメッセージタイプ/コードまたはモビリティヘッダータイプが非初心者フラグメントから欠落している可能性があります。また、IPv6の場合、最初のフラグメントでさえ、存在する拡張ヘッダーの種類と数に応じて、次のレイヤープロトコルまたはポート（またはICMPメッセージタイプ/コード、またはモビリティヘッダータイプ）を含まない場合があります。非Initialフラグメントにポート（またはICMPタイプとコードまたはモビリティヘッダータイプ）が含まれているが、次のレイヤープロトコルが含まれていない場合、次のレイヤープロトコルとポート用の関連するローカル/リモートアドレスのSPDエントリがある場合を除き（またはICMPタイプとコードまたはモビリティヘッダータイプ）、フラグメントには、アクセス制御に必要なすべてのセレクター情報が含まれていません。
To address the above issues, three approaches have been defined:
上記の問題に対処するために、3つのアプローチが定義されています。
o Tunnel mode SAs that carry initial and non-initial fragments (See Section 7.1.) o Separate tunnel mode SAs for non-initial fragments (See Section 7.2.) o Stateful fragment checking (See Section 7.3.)
o 初期および非独創的なフラグメントを搭載するトンネルモードSAS（セクション7.1を参照）o非独創的なフラグメントの分離トンネルモードSAS（セクション7.2を参照）oステートフルフラグメントチェック（セクション7.3を参照）
All implementations MUST support tunnel mode SAs that are configured to pass traffic without regard to port field (or ICMP type/code or Mobility Header type) values. If the SA will carry traffic for specified protocols, the selector set for the SA MUST specify the port fields (or ICMP type/code or Mobility Header type) as ANY. An SA defined in this fashion will carry all traffic including initial and non-initial fragments for the indicated Local/Remote addresses and specified Next Layer protocol(s). If the SA will carry traffic without regard to a specific protocol value (i.e., ANY is specified as the (Next Layer) protocol selector value), then the port field values are undefined and MUST be set to ANY as well. (As noted in 4.4.1, ANY includes OPAQUE as well as all specific values.)
すべての実装は、ポートフィールド（またはICMPタイプ/コードまたはモビリティヘッダータイプ）値に関係なくトラフィックを渡すように構成されたトンネルモードSASをサポートする必要があります。SAが指定されたプロトコルのトラフィックを運ぶ場合、SAに設定されたセレクターは、ポートフィールド（またはICMPタイプ/コードまたはモビリティヘッダータイプ）を指定する必要があります。この方法で定義されているSAは、指定されたローカル/リモートアドレスの初期および非独創的なフラグメントを含むすべてのトラフィックを運び、指定された次のレイヤープロトコルを運びます。SAが特定のプロトコル値（つまり、（次のレイヤー）プロトコルセレクター値として指定されている）に関係なくトラフィックを運ぶ場合、ポートフィールド値は未定義であり、いずれかに設定する必要があります。（4.4.1に記載されているように、任意の任意には、すべての特定の値が含まれます。）
An implementation MAY support tunnel mode SAs that will carry only non-initial fragments, separate from non-fragmented packets and initial fragments. The OPAQUE value will be used to specify port (or ICMP type/code or Mobility Header type) field selectors for an SA to carry such fragments. Receivers MUST perform a minimum offset check on IPv4 (non-initial) fragments to protect against overlapping fragment attacks when SAs of this type are employed. Because such checks cannot be performed on IPv6 non-initial fragments, users and administrators are advised that carriage of such fragments may be dangerous, and implementers may choose to NOT support such SAs for IPv6 traffic. Also, an SA of this sort will carry all non-initial fragments that match a specified Local/Remote address pair and protocol value, i.e., the fragments carried on this SA belong to packets that if not fragmented, might have gone on separate SAs of differing security. Therefore, users and administrators are advised to protect such traffic using ESP (with integrity) and the "strongest" integrity and encryption algorithms in use between both peers. (Determination of the "strongest" algorithms requires imposing an ordering of the available algorithms, a local determination at the discretion of the initiator of the SA.)
実装は、非フロージャメントパケットと初期フラグメントとは別の非初心者フラグメントのみを搭載するトンネルモードSASをサポートする場合があります。不透明な値は、SAのポート（またはICMPタイプ/コードまたはモビリティヘッダータイプ）フィールドセレクターを指定するために使用され、そのようなフラグメントを運びます。受信機は、このタイプのSASを使用したときに、重複するフラグメント攻撃から保護するために、IPv4（非初期的な）フラグメントで最小オフセットチェックを実行する必要があります。このようなチェックはIPv6非初期的なフラグメントで実行できないため、ユーザーと管理者は、そのようなフラグメントのキャリッジは危険である可能性があり、実装者はIPv6トラフィックのSASをサポートしないことを選択する場合があります。また、この種のSAは、指定されたローカル/リモートアドレスのペアとプロトコル値に一致するすべての非向性フラグメントを運びます。異なるセキュリティ。したがって、ユーザーと管理者は、ESP（整合性を持つ）と、両方のピア間で使用されている「最も強い」整合性と暗号化アルゴリズムを使用して、そのようなトラフィックを保護することをお勧めします。（「最強の」アルゴリズムの決定には、利用可能なアルゴリズムの順序付けを課す必要があります。これは、SAの開始者の裁量での局所決定です。）
Specific port (or ICMP type/code or Mobility Header type) selector values will be used to define SAs to carry initial fragments and non-fragmented packets. This approach can be used if a user or administrator wants to create one or more tunnel mode SAs between the same Local/Remote addresses that discriminate based on port (or ICMP type/code or Mobility Header type) fields. These SAs MUST have non-trivial protocol selector values, otherwise approach #1 above MUST be used.
特定のポート（またはICMPタイプ/コードまたはモビリティヘッダータイプ）セレクター値を使用して、SASを定義して初期フラグメントと非フラグメントパケットを運ぶことができます。ユーザーまたは管理者が、ポート（またはICMPタイプ/コードまたはモビリティヘッダータイプ）フィールドに基づいて識別する同じローカル/リモートアドレスの間に1つ以上のトンネルモードSASを作成する場合、このアプローチを使用できます。これらのSAには、自明でないプロトコルセレクターの値が必要です。そうしないと、上記のアプローチ＃1を使用する必要があります。
Note: In general, for the approach described in this section, one needs only a single SA between two implementations to carry all non-initial fragments. However, if one chooses to have multiple SAs between the two implementations for QoS differentiation, then one might also want multiple SAs to carry fragments-without-ports, one for each supported QoS class. Since support for QoS via distinct SAs is a local matter, not mandated by this document, the choice to have multiple SAs to carry non-initial fragments should also be local.
注：一般的に、このセクションで説明するアプローチでは、すべての非独創的なフラグメントを運ぶために2つの実装の間に単一のSAが必要です。ただし、QoS分化の2つの実装の間に複数のSASを使用することを選択した場合、サポートされている各QoSクラスの1つは、ポートで複数のSASを運ぶことを望むかもしれません。個別のSASを介したQoSのサポートはローカルな問題であり、この文書で義務付けられていないため、非初期的なフラグメントを運ぶために複数のSAを持つこともローカルでなければなりません。
An implementation MAY support some form of stateful fragment checking for a tunnel mode SA with non-trivial port (or ICMP type/code or MH type) field values (not ANY or OPAQUE). Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
実装は、非自明のポート（またはICMPタイプ/コードまたはMHタイプ）のフィールド値（または不透明ではない）を備えたトンネルモードSAをチェックする何らかの形式のステートフルフラグメントをサポートする場合があります。非独創的なポート（またはICMPタイプ/コードまたはMHタイプ）セレクターを使用するトンネルモードSAで非初期的なフラグメントを送信する実装は、IKE NON_FIRST_FRAGMENTS_ALSOペイロードを通知してピアに通知する必要があります。
The peer MUST reject this proposal if it will not accept non-initial fragments in this context. If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. This standard does not specify how peers will deal with such fragments, e.g., via reassembly or other means, at either sender or receiver. However, a receiver MUST discard non-initial fragments that arrive on an SA with non-trivial port (or ICMP type/code or MH type) selector values unless this feature has been negotiated. Also, the receiver MUST discard non-initial fragments that do not comply with the security policy applied to the overall packet. Discarding such packets is an auditable event. Note that in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
ピアは、このコンテキストで無向的な断片を受け入れない場合、この提案を拒否しなければなりません。実装がそのようなSAの非独創的な断片の伝達を正常に交渉しない場合、SA上にそのような断片を送信してはなりません。この標準では、ピアがそのようなフラグメントをどのように扱うかを指定していません。ただし、受信者は、この機能が交渉されていない限り、非文書ポート（またはICMPタイプ/コードまたはMHタイプ）セレクター値を備えたSAに到着する非向性フラグメントを廃棄する必要があります。また、受信者は、全体的なパケットに適用されるセキュリティポリシーに準拠していない非独創的なフラグメントを廃棄する必要があります。そのようなパケットの廃棄は監査可能なイベントです。パケットのフラグメントが異なるセキュリティゲートウェイまたはBITW実装を介して送信または受信される可能性があるネットワーク構成では、フラグメントを追跡するためのステートフルな戦略が失敗する可能性があることに注意してください。
All implementations MUST support DISCARDing of fragments using the normal SPD packet classification mechanisms. All implementations MUST support stateful fragment checking to accommodate BYPASS traffic for which a non-trivial port range is specified. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort. As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail.
すべての実装は、通常のSPDパケット分類メカニズムを使用したフラグメントの破棄をサポートする必要があります。すべての実装は、非自明のポート範囲が指定されているバイパストラフィックに対応するために、ステートフルなフラグメントチェックをサポートする必要があります。懸念は、IPSECの実装に到着するクリアテキストの非初心者フラグメントのバイパスが、同じ宛先に向けられたIPSEC保護されたトラフィックが提供されるセキュリティを損なう可能性があることです。たとえば、特定のソース/宛先アドレスペア間のトラフィックのIPSEC保護を必要とするSPDエントリで構成されたIPSEC実装を検討し、特定のプロトコルと宛先ポート（ポート23のTCPトラフィック（Telnet）のTCPトラフィック）を検討します。この実装により、同じソース/宛先アドレスペアとプロトコルからのトラフィックのバイパスも可能であると仮定しますが、別の宛先ポート（ポート119（NNTP）など）。攻撃者は、バイパスされれば、同じソースからのIPSECで保護されたトラフィックと重複し、IPSECで保護されたトラフィックの完全性に違反する可能性がある非初心者フラグメント（偽造ソースアドレス付き）を送信できます。自明でないポート範囲を使用してバイパスエントリをチェックすることを要求すると、この種の攻撃が防止されます。上記のように、パケットのフラグメントが異なるセキュリティゲートウェイまたはBITW実装を介して送信または受信される可能性のあるネットワーク構成では、フラグメントを追跡するためのステートフルな戦略が失敗する可能性があります。
The application of AH or ESP to an outbound packet increases the size of a packet and thus may cause a packet to exceed the PMTU for the SA via which the packet will travel. An IPsec implementation also may receive an unprotected ICMP PMTU message and, if it chooses to act upon the message, the result will affect outbound traffic processing. This section describes the processing required of an IPsec implementation to deal with these two PMTU issues.
AHまたはESPをアウトバウンドパケットに適用すると、パケットのサイズが増加するため、パケットが移動するSAのPMTUを超えるパケットを超える可能性があります。IPSECの実装は、保護されていないICMP PMTUメッセージを受信する場合があり、メッセージに基づいて行動することを選択した場合、結果はアウトバウンドトラフィック処理に影響します。このセクションでは、これら2つのPMTUの問題に対処するためにIPSEC実装に必要な処理について説明します。
All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4.
すべてのIPSECの実装は、トンネルモードSAを介してトラフィックが運ばれるときに、アウトバウンドパケットからエミストするトンネルモードヘッダーにDFビットをコピーするオプションをサポートする必要があります。これは、各SAのDFビット（設定、クリア、内側ヘッダーからのコピー）の実装の扱いを構成することが可能であることを意味します。これは、内側ヘッダーと外側の両方のヘッダーがIPv4であるSASに適用されます。
This section discusses IPsec handling for unprotected Path MTU Discovery messages. ICMP PMTU is used here to refer to an ICMP message for:
このセクションでは、保護されていないパスMTU発見メッセージのIPSEC処理について説明します。ICMP PMTUは、以下のICMPメッセージを参照するために使用されます。
IPv4 (RFC 792 [Pos81b]): - 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 (labeled "unused" in RFC 792), with high-order 16 bits set to zero)
IPv4（RFC 792 [POS81B]）： - type = 3（宛先到達不可） - コード= 4（断片化が必要とDFセット）-ICMPヘッダーの2番目の単語の低次の16ビット（ラベル付き）RFC 792の「未使用」）、高次の16ビットがゼロに設定されています）
IPv6 (RFC 2463 [CD98]): - Type = 2 (Packet Too Big) - Code = 0 (Fragmentation needed) - Next-Hop MTU in the 32-bit MTU field of the ICMP6 message
IPv6（RFC 2463 [CD98]）： - type = 2（パケットが大きすぎる） - コード= 0（フラグメンテーションが必要） - ICMP6メッセージの32ビットMTUフィールドのネクストホップMTU
When an IPsec implementation receives an unauthenticated PMTU message, and it is configured to process (vs. ignore) such messages, it maps the message to the SA to which it corresponds. This mapping is effected by extracting the header information from the payload of the PMTU message and applying the procedure described in Section 5.2. The PMTU determined by this message is used to update the SAD PMTU field, taking into account the size of the AH or ESP header that will be applied, any crypto synchronization data, and the overhead imposed by an additional IP header, in the case of a tunnel mode SA.
IPSECの実装が認証されていないPMTUメッセージを受信し、そのようなメッセージを処理する（無視する）ように構成されている場合、それが対応するSAにメッセージをマップします。このマッピングは、PMTUメッセージのペイロードからヘッダー情報を抽出し、セクション5.2で説明した手順を適用することにより行われます。このメッセージで決定されたPMTUは、適用されるAHまたはESPヘッダーのサイズ、暗号同期データ、および追加のIPヘッダーによって課されるオーバーヘッドを考慮して、SAD PMTUフィールドを更新するために使用されます。トンネルモードSA。
In a native host implementation, it is possible to maintain PMTU data at the same granularity as for unprotected communication, so there is no loss of functionality. Signaling of the PMTU information is internal to the host. For all other IPsec implementation options, the PMTU data must be propagated via a synthesized ICMP PMTU. In these cases, the IPsec implementation SHOULD wait for outbound traffic to be mapped to the SAD entry. When such traffic arrives, if the traffic would exceed the updated PMTU value the traffic MUST be handled as follows:
ネイティブのホストの実装では、保護されていない通信と同じ粒度でPMTUデータを維持することが可能であるため、機能の損失はありません。PMTU情報の信号は、ホストの内部です。他のすべてのIPSEC実装オプションについては、PMTUデータを合成されたICMP PMTUを介して伝播する必要があります。これらの場合、IPSECの実装は、アウトバウンドトラフィックが悲しいエントリにマッピングされるのを待つ必要があります。そのようなトラフィックが到着した場合、トラフィックが更新されたPMTU値を超える場合、トラフィックは次のように処理する必要があります。
Case 1: Original (cleartext) packet is IPv4 and has the DF bit set. The implementation SHOULD discard the packet and send a PMTU ICMP message.
ケース1：元の（ClearText）パケットはIPv4で、DFビットが設定されています。実装では、パケットを破棄し、PMTU ICMPメッセージを送信する必要があります。
Case 2: Original (cleartext) packet is IPv4 and has the DF bit clear. The implementation SHOULD fragment (before or after encryption per its configuration) and then forward the fragments. It SHOULD NOT send a PMTU ICMP message.
ケース2：オリジナル（ClearText）パケットはIPv4で、DFがビットクリアされています。実装は（構成ごとに暗号化の前または暗号化の前または後）フラグメントを断片化し、フラグメントを転送する必要があります。PMTU ICMPメッセージを送信しないでください。
Case 3: Original (cleartext) packet is IPv6. The implementation SHOULD discard the packet and send a PMTU ICMP message.
ケース3：オリジナル（ClearText）パケットはIPv6です。実装では、パケットを破棄し、PMTU ICMPメッセージを送信する必要があります。
In all IPsec implementations, the PMTU associated with an SA MUST be "aged" and some mechanism is required to update the PMTU in a timely manner, especially for discovering if the PMTU is smaller than required by current network conditions. A given PMTU has to remain in place long enough for a packet to get from the source of the SA to the peer, and to propagate an ICMP error message if the current PMTU is too big.
すべてのIPSEC実装では、SAに関連付けられたPMTUは「老化」している必要があり、特にPMTUが現在のネットワーク条件で必要とするよりも小さいかどうかを発見するために、PMTUをタイムリーに更新するために何らかのメカニズムが必要です。特定のPMTUは、パケットがSAのソースからピアに到達し、現在のPMTUが大きすぎる場合はICMPエラーメッセージを伝播するのに十分な長さを維持する必要があります。
Implementations SHOULD use the approach described in the Path MTU Discovery document (RFC 1191 [MD90], 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.
実装は、PATH MTU Discoveryドキュメント（RFC 1191 [MD90]、セクション6.3）で説明されているアプローチを使用する必要があります。必要。期間は構成可能である必要があります。
IPsec implementations are not required to support auditing. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this document, 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の実装は必要ありません。ほとんどの場合、監査の粒度は地元の問題です。ただし、このドキュメントではいくつかの監査可能なイベントが特定されており、これらの各イベントでは、監査ログに含まれるべき最小の情報セットが定義されています。追加情報は、これらの各イベントの監査ログにも含まれる場合があり、この仕様で明示的に呼び出されない追加のイベントは、監査ログエントリになる可能性があります。そのようなアクションを介してサービスの拒否を誘発する可能性があるため、監査可能なイベントの検出に応じて、受信者が監査可能なイベントの検出に応じてメッセージを送信する必要はありません。
All IPv4 IPsec implementations MUST comply with all requirements of this document. All IPv6 implementations MUST comply with all requirements of this document.
すべてのIPv4 IPSEC実装は、このドキュメントのすべての要件に準拠する必要があります。すべてのIPv6の実装は、このドキュメントのすべての要件に準拠する必要があります。
The focus of this document is security; hence security considerations permeate this specification.
このドキュメントの焦点はセキュリティです。したがって、セキュリティ上の考慮事項は、この仕様に浸透します。
IPsec imposes stringent constraints on bypass of IP header data in both directions, across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern.
IPSECは、特にトンネルモードSAが採用されている場合、IPSECバリア全体で、両方向のIPヘッダーデータのバイパスに厳しい制約を課します。一部の制約は絶対的ですが、他の制約はローカルな管理管理の対象となります。アウトバウンドトラフィックの場合、これらの制約は、カバーチャネルの帯域幅を制限するように設計されています。インバウンドトラフィックの場合、制約は、1つのデータストリーム（IPSECバリアの保護されていない側面）を改ざんする能力を持つ敵を、他のデータストリーム（バリアの保護された側面）に悪影響を与えるように設計されています。トンネルモードSASのDSCP値の処理を扱うセクション5の議論は、この懸念を示しています。
If an IPsec implementation is configured to pass ICMP error messages over SAs based on the ICMP header values, without checking the header information from the ICMP message payload, serious vulnerabilities may arise. Consider a scenario in which several sites (A, B, and C) are connected to one another via ESP-protected tunnels: A-B, A-C, and B-C. Also assume that the traffic selectors for each tunnel specify ANY for protocol and port fields and IP source/destination address ranges that encompass the address range for the systems behind the security gateways serving each site. This would allow a host at site B to send an ICMP Destination Unreachable message to any host at site A, that declares all hosts on the net at site C to be unreachable. This is a very efficient DoS attack that could have been prevented if the ICMP error messages were subjected to the checks that IPsec provides, if the SPD is suitably configured, as described in Section 6.2.
ICMPメッセージペイロードからヘッダー情報をチェックせずに、ICMPヘッダー値に基づいてSASでICMPエラーメッセージを渡すようにIPSEC実装が構成されている場合、深刻な脆弱性が生じる可能性があります。ESP保護されたトンネル（A-B、A-C、およびB-C）を介していくつかのサイト（A、B、およびC）が互いに接続されているシナリオを考えてみましょう。また、各トンネルのトラフィックセレクターは、プロトコルとポートフィールド、および各サイトにサービスを提供するセキュリティゲートウェイの背後にあるシステムのアドレス範囲を含むIPソース/宛先アドレスの範囲を指定すると仮定します。これにより、サイトBのホストは、サイトAのホストにICMP宛先の到達不可能なメッセージを送信できます。これにより、サイトCのネット上のすべてのホストが到達不能であると宣言されます。これは非常に効率的なDOS攻撃であり、セクション6.2で説明されているように、SPDが適切に構成されている場合、IPSECが提供するチェックにICMPエラーメッセージが提供された場合、防止できた可能性があります。
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
IANAは、Asn1-Modulesレジストリに値（3）を割り当て、SPDモジュールにオブジェクト識別子1.3.6.1.5.8.3.1を割り当てました。付録C、「SPDエントリについてはASN.1」を参照してください。
This architecture document differs substantially from RFC 2401 [RFC2401] in detail and in organization, but the fundamental notions are unchanged.
このアーキテクチャのドキュメントは、RFC 2401 [RFC2401]とは大きく異なるものと組織的に異なりますが、基本的な概念は変更されていません。
o The processing model has been revised to address new IPsec scenarios, improve performance, and simplify implementation. This includes a separation between forwarding (routing) and SPD selection, several SPD changes, and the addition of an outbound SPD cache and an inbound SPD cache for bypassed or discarded traffic. There is also a new database, the Peer Authorization Database (PAD). This provides a link between an SA management protocol (such as IKE) and the SPD.
o 処理モデルは、新しいIPSECシナリオに対処し、パフォーマンスを改善し、実装を簡素化するために改訂されています。これには、転送（ルーティング）とSPD選択の分離、いくつかのSPD変更、およびバイパスまたは破棄されたトラフィック用のアウトバウンドSPDキャッシュの追加と、インバウンドSPDキャッシュが含まれます。新しいデータベース、ピア認証データベース（PAD）もあります。これにより、SA管理プロトコル（IKEなど）とSPDの間のリンクが提供されます。
o There is no longer a requirement to support nested SAs or "SA bundles". Instead this functionality can be achieved through SPD and forwarding table configuration. An example of a configuration has been added in Appendix E.
o ネストされたSASまたは「SAバンドル」をサポートするための要件はもうありません。代わりに、この機能は、SPDおよび転送テーブル構成によって達成できます。付録Eに構成の例が追加されました。
o SPD entries were redefined to provide more flexibility. Each SPD entry now consists of 1 to N sets of selectors, where each selector set contains one protocol and a "list of ranges" can now be specified for the Local IP address, Remote IP address, and whatever fields (if any) are associated with the Next Layer Protocol (Local Port, Remote Port, ICMP message type and code, and Mobility Header type). An individual value for a selector is represented via a trivial range and ANY is represented via a range than spans all values for the selector. An example of an ASN.1 description is included in Appendix C.
o SPDエントリは再定義され、より柔軟性を提供しました。各SPDエントリは、1〜Nセットのセレクターセットで構成され、各セレクターセットには1つのプロトコルが含まれ、「範囲のリスト」がローカルIPアドレス、リモートIPアドレス、および関連付けられているフィールド（存在する場合）に指定できるようになりました。次のレイヤープロトコル（ローカルポート、リモートポート、ICMPメッセージタイプとコード、モビリティヘッダータイプ）。セレクターの個々の値は、些細な範囲を介して表され、任意はセレクターのすべての値にスパンするよりも範囲を介して表されます。ASN.1の説明の例は、付録Cに含まれています。
o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and ECN. The tunnel section has been updated to explain how to handle DSCP and ECN bits.
o TOS（IPv4）とトラフィッククラス（IPv6）は、DSCPとECNに置き換えられています。トンネルセクションは、DSCPおよびECNビットの処理方法を説明するために更新されました。
o For tunnel mode SAs, an SG, BITS, or BITW implementation is now allowed to fragment packets before applying IPsec. This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them.
o トンネルモードSASの場合、IPSECを適用する前に、SG、BITS、またはBITWの実装がパケットをフラグメントするようになりました。これはIPv4にのみ適用されます。IPv6パケットの場合、オリジネーターのみがそれらを断片化できます。
o When security is desired between two intermediate systems along a path or between an intermediate system and an end system, transport mode may now be used between security gateways and between a security gateway and a host.
o パスに沿った2つの中間システム間、または中間システムとエンドシステム間でセキュリティが望まれる場合、セキュリティゲートウェイとセキュリティゲートウェイとホスト間で輸送モードを使用できるようになります。
o This document clarifies that for all traffic that crosses the IPsec boundary, including IPsec management traffic, the SPD or associated caches must be consulted.
o この文書は、IPSEC管理トラフィックを含むIPSEC境界を通過するすべてのトラフィックについて、SPDまたは関連するキャッシュを相談する必要があることを明確にしています。
o This document defines how to handle the situation of a security gateway with multiple subscribers requiring separate IPsec contexts.
o このドキュメントでは、複数のサブスクライバーが個別のIPSECコンテキストを必要とするセキュリティゲートウェイの状況を処理する方法を定義します。
o A definition of reserved SPIs has been added.
o 予約されたスピスの定義が追加されました。
o Text has been added explaining why ALL IP packets must be checked -- IPsec includes minimal firewall functionality to support access control at the IP layer.
o すべてのIPパケットをチェックする必要がある理由を説明するテキストが追加されました。IPSECには、IPレイヤーでのアクセス制御をサポートするための最小限のファイアウォール機能が含まれています。
o The tunnel section has been updated to clarify how to handle the IP options field and IPv6 extension headers when constructing the outer header.
o トンネルセクションが更新され、外側ヘッダーを構築するときにIPオプションフィールドとIPv6拡張ヘッダーを処理する方法を明確にします。
o SA mapping for inbound traffic has been updated to be consistent with the changes made in AH and ESP for support of unicast and multicast SAs.
o インバウンドトラフィックのSAマッピングは、ユニキャストおよびマルチキャストSASのサポートのためにAHおよびESPで行われた変更と一致するように更新されました。
o Guidance has been added regarding how to handle the covert channel created in tunnel mode by copying the DSCP value to outer header.
o DSCP値を外側のヘッダーにコピーすることにより、トンネルモードで作成されたカバーチャネルを処理する方法に関するガイダンスが追加されました。
o Support for AH in both IPv4 and IPv6 is no longer required.
o IPv4とIPv6の両方でAHのサポートは不要になりました。
o PMTU handling has been updated. The appendix on PMTU/DF/Fragmentation has been deleted.
o PMTUの取り扱いが更新されました。PMTU/DF/断片化の付録が削除されました。
o Three approaches have been added for handling plaintext fragments on the protected side of the IPsec boundary. Appendix D documents the rationale behind them.
o IPSEC境界の保護された側のプレーンテキストフラグメントを処理するために、3つのアプローチが追加されています。付録Dは、その背後にある根拠を文書化しています。
o Added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc.)
o SASのセレクター値を導出する方法を説明する改訂されたテキスト（SPDエントリまたはパケットから）など）
o Added a new table describing the relationship between selector values in an SPD entry, the PFP flag, and resulting selector values in the corresponding SAD entry.
o SPDエントリのセレクター値と、対応するSADエントリの結果のセレクター値の関係を説明する新しいテーブルを追加しました。
o Added Appendix B to describe decorrelation.
o 脱相関を説明するために付録Bを追加しました。
o Added text describing how to handle an outbound packet that must be discarded.
o 廃棄する必要があるアウトバウンドパケットを処理する方法を説明するテキストが追加されました。
o Added text describing how to handle a DISCARDED inbound packet, i.e., one that does not match the SA upon which it arrived.
o 廃棄されたインバウンドパケット、つまり到着したSAと一致しないものを処理する方法を説明するテキストが追加されました。
o IPv6 mobility header has been added as a possible Next Layer Protocol. IPv6 Mobility Header message type has been added as a selector.
o IPv6モビリティヘッダーは、次のレイヤープロトコルの可能性として追加されています。IPv6モビリティヘッダーメッセージタイプがセレクターとして追加されました。
o ICMP message type and code have been added as selectors.
o ICMPメッセージタイプとコードがセレクターとして追加されています。
o The selector "data sensitivity level" has been removed to simplify things.
o セレクター「データ感度レベル」が削除され、物事を簡素化しました。
o Updated text describing handling ICMP error messages. The appendix on "Categorization of ICMP Messages" has been deleted.
o ICMPエラーメッセージの処理を説明する更新されたテキスト。「ICMPメッセージの分類」に関する付録は削除されました。
o The text for the selector name has been updated and clarified.
o セレクター名のテキストは更新および明確にされています。
o The "Next Layer Protocol" has been further explained and a default list of protocols to skip when looking for the Next Layer Protocol has been added.
o 「次のレイヤープロトコル」がさらに説明され、次のレイヤープロトコルを探すときにスキップするプロトコルのデフォルトのリストが追加されました。
o The text has been amended to say that this document assumes use of IKEv2 or an SA management protocol with comparable features.
o テキストは、このドキュメントが同等の機能を備えたIKEV2またはSA管理プロトコルの使用を想定していると言って修正されています。
o Text has been added clarifying the algorithm for mapping inbound IPsec datagrams to SAs in the presence of multicast SAs.
o マルチキャストSASの存在下で、インバウンドIPSECデータグラムをSASにマッピングするためのアルゴリズムを明確にするテキストが追加されました。
o The appendix "Sequence Space Window Code Example" has been removed.
o 付録「シーケンススペースウィンドウコードの例」が削除されました。
o With respect to IP addresses and ports, the terms "Local" and "Remote" are used for policy rules (replacing source and destination). "Local" refers to the entity being protected by an IPsec implementation, i.e., the "source" address/port of outbound packets or the "destination" address/port of inbound packets. "Remote" refers to a peer entity or peer entities. The terms "source" and "destination" are still used for packet header fields.
o IPアドレスとポートに関しては、「ローカル」および「リモート」という用語は、ポリシールール（ソースと宛先を置き換える）に使用されます。「ローカル」とは、IPSECの実装によって保護されているエンティティ、つまり、アウトバウンドパケットの「ソース」アドレス/ポートまたはインバウンドパケットの「宛先」アドレス/ポートを指します。「リモート」とは、ピアエンティティまたはピアエンティティを指します。「ソース」と「宛先」という用語は、パケットヘッダーフィールドにまだ使用されています。
The authors would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827; and Charlie Lynn, who made significant contributions to the second series of IPsec standards (RFCs 2401, 2402, and 2406) and to the current versions, especially with regard to IPv6 issues. The authors also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification.
著者は、最初のIPSECアクティビティで重要な役割を果たし、IPSEC標準の最初のシリーズを執筆したRan Atkinsonの貢献を認めたいと考えています。RFCS1825-1827。そして、特にIPv6の問題に関して、第2シリーズのIPSEC標準（RFCS 2401、2402、および2406）および現在のバージョンに多大な貢献をしたチャーリーリン。著者はまた、このプロトコル仕様の開発に貢献したIPSECおよびMSECワーキンググループのメンバーに感謝したいと思います。
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., [Shi00], [VK83], and [HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms.
このセクションでは、このドキュメントで採用されているいくつかの重要な用語の定義を提供します。他のドキュメントは、この技術に関連する追加の定義と背景情報を提供します。この用語集には、一般的なセキュリティサービスとセキュリティメカニズムの用語、さらにIPSEC固有の用語が含まれています。
Access Control 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:
アクセス制御不正な方法でリソースの使用の防止を含む、リソースの不正使用を防ぐセキュリティサービス。IPSECのコンテキストでは、アクセスが制御されているリソースはしばしば次のとおりです。
o for a host, computing cycles or data o for a security gateway, a network behind the gateway or bandwidth on that network.
o ホストの場合、セキュリティゲートウェイのコンピューティングサイクルまたはデータo、そのネットワークのゲートウェイの背後にあるネットワークまたは帯域幅。
Anti-replay See "Integrity" below.
レプレイ防止以下の「完全性」を参照してください。
Authentication 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 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 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コンテキストでは、TunnelモードでESPを使用して、特にセキュリティゲートウェイで使用すると、ある程度のトラフィックフローの機密性を提供できます。（以下の「トラフィック分析」も参照してください。）
Data Origin Authentication A security service that verifies the identity of the claimed source of data. This service is usually bundled with connectionless integrity service.
データ起源認証請求されたデータソースのIDを検証するセキュリティサービス。このサービスは通常、Connectionless Integrity Serviceにバンドルされています。
Encryption 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". Often the term "encryption" is used to generically refer to both processes.
暗号化データは、知識のある形式（Plantext）から理解できない形式（ciphertext）に変換するために使用され、機密性を提供します。逆変換プロセスは「復号化」と指定されます。多くの場合、「暗号化」という用語は、両方のプロセスを一般的に参照するために使用されます。
Integrity 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.
整合性データの変更が検出可能になることを保証するセキュリティサービス。整合性には、アプリケーションの要件に合わせてさまざまなフレーバーがあります。IPSECは、2つの形式の整合性をサポートしています。つまり、コネクションレスと部分的な配列の整合性の形式です。ConnectionLess Integrityは、トラフィックのストリーム内でのデータグラムの順序に関係なく、個々のIPデータグラムの変更を検出するサービスです。IPSECで提供される部分的な配列の整合性の形式は、レプレイの整合性と呼ばれ、重複するIPデータグラムの到着（制約付きウィンドウ内）を検出します。これは、接続指向の整合性とは対照的であり、紛失または順序付けされたメッセージを検出できるように、トラフィックにより厳しいシーケンス要件を課します。認証と整合性のサービスはしばしば別々に引用されていますが、実際には密接に接続されており、ほとんど常にタンデムで提供されています。
Protected vs. Unprotected "Protected" refers to the systems or interfaces that are inside the IPsec protection boundary, and "unprotected" refers to the systems or interfaces that are outside the IPsec protection boundary. IPsec provides a boundary through which traffic passes. There is an asymmetry to this barrier, which is reflected in the processing model. Outbound data, if not discarded or bypassed, is protected via the application of AH or ESP and the addition of the corresponding headers. Inbound data, if not discarded or bypassed, is processed via the removal of AH or ESP headers. In this document, inbound traffic enters an IPsec implementation from the "unprotected" interface. Outbound traffic enters the implementation via the "protected" interface, or is internally generated by the implementation on the "protected" side of the boundary and directed toward the "unprotected" interface. An IPsec implementation may support more than one interface on either or both sides of the boundary. The protected interface may be internal, e.g., in a host implementation of IPsec. The protected interface may link to a socket layer interface presented by the OS.
保護されている対保護されていない「保護された」は、IPSEC保護境界内にあるシステムまたはインターフェイスを指し、「保護されていない」は、IPSEC保護境界の外側にあるシステムまたはインターフェイスを指します。IPSECは、トラフィックが通過する境界を提供します。この障壁には非対称性があり、処理モデルに反映されています。アウトバウンドデータは、廃棄またはバイパスされていない場合、AHまたはESPの適用と対応するヘッダーの追加により保護されます。インバウンドデータは、廃棄またはバイパスされていない場合、AHまたはESPヘッダーの除去を介して処理されます。このドキュメントでは、インバウンドトラフィックが「保護されていない」インターフェイスからIPSEC実装に入ります。アウトバウンドトラフィックは、「保護された」インターフェイスを介して実装に入ります。または、境界の「保護された」側の実装によって内部的に生成され、「保護されていない」インターフェイスに向けられます。IPSECの実装は、境界のいずれかまたは両側に複数のインターフェイスをサポートする場合があります。保護されたインターフェイスは、IPSECのホスト実装などの内部である場合があります。保護されたインターフェイスは、OSが提示するソケットレイヤーインターフェイスにリンクする場合があります。
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. State data associated with an SA is represented in the SA Database (SAD).
セキュリティ協会（SA）セキュリティ目的で作成されたシンプレックス（単方向）論理接続。SAを横断するすべてのトラフィックには、同じセキュリティ処理が提供されます。IPSECでは、SAはAHまたはESPを使用して実装されたインターネット層の抽象化です。SAに関連付けられた状態データは、SAデータベース（SAD）に表されます。
Security Gateway 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 termed unprotected (they are generally at least less protected than those "behind" the SG), while the networks and hosts on the internal side are viewed as protected. The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration. 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つのネットワーク間の通信インターフェイスとして機能する中間システム。セキュリティゲートウェイの外側にあるホスト（およびネットワーク）のセットは保護されていないものと呼ばれます（一般に、「SGの背後」のものよりも少なくとも保護されていません）。一方、内側のネットワークとホストは保護されていると見なされます。セキュリティゲートウェイで提供される内部サブネットとホストは、一般的なローカル、セキュリティ管理を共有するために信頼されると推定されます。IPSECのコンテキストでは、セキュリティゲートウェイは、IPSECを採用する外部ホストと通信するときにこれらのホストにセキュリティサービスを提供するために、AHおよび/またはESPが内部ホストのセットにサービスを提供するために実装されるポイントです。別のセキュリティゲートウェイ）。
Security Parameters Index (SPI) An arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet should be bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type. Additional IP address information is used to identify multicast SAs. 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）受信者が使用する任意の32ビット値。着信パケットをバインドするSAを識別します。ユニキャストSAの場合、SPIはSAを指定するために単独で使用できます。または、IPSECプロトコルタイプと組み合わせて使用できます。追加のIPアドレス情報は、マルチキャストSASを識別するために使用されます。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, and flow identifiers [Sch94].
トラフィック分析敵に役立つ情報を推測する目的で、ネットワークトラフィックフローの分析。このような情報の例は、伝送の頻度、会話の当事者のアイデンティティ、パケットのサイズ、およびフロー識別子です[SCH94]。
Appendix B: Decorrelation
付録B：非相関
This appendix is based on work done for caching of policies in the IP Security Policy Working Group by Luis Sanchez, Matt Condell, and John Zao.
この付録は、Luis Sanchez、Matt Condell、およびJohn ZaoによるIPセキュリティポリシーワーキンググループのポリシーのキャッシュのために行われた作業に基づいています。
Two SPD entries are correlated if there is a non-null intersection between the values of corresponding selectors in each entry. Caching correlated SPD entries can lead to incorrect policy enforcement. A solution to this problem, which still allows for caching, is to remove the ambiguities by decorrelating the entries. That is, the SPD entries must be rewritten so that for every pair of entries there exists a selector for which there is a null intersection between the values in both of the entries. Once the entries are decorrelated, there is no longer any ordering requirement on them, since only one entry will match any lookup. The next section describes decorrelation in more detail and presents an algorithm that may be used to implement decorrelation.
各エントリ内の対応するセレクターの値の間に非ヌル交差点がある場合、2つのSPDエントリが相関します。キャッシュ相関SPDエントリは、誤ったポリシー施行につながる可能性があります。まだキャッシングを可能にするこの問題の解決策は、エントリを非相関させて曖昧さを削除することです。つまり、SPDエントリを書き直す必要があります。これにより、すべてのペアのエントリに、両方のエントリの値の間にヌル交差があるセレクターが存在するようにする必要があります。エントリが非相関すると、1つのエントリのみが検索と一致するため、エントリには注文要件はもうありません。次のセクションでは、非相関についてより詳細に説明し、非相関を実装するために使用できるアルゴリズムを提示します。
The basic decorrelation algorithm takes each entry in a correlated SPD and divides it into a set of entries using a tree structure. The nodes of the tree are the selectors that may overlap between the policies. At each node, the algorithm creates a branch for each of the values of the selector. It also creates one branch for the complement of the union of all selector values. Policies are then formed by traversing the tree from the root to each leaf. The policies at the leaves are compared to the set of already decorrelated policy rules. Each policy at a leaf is either completely overridden by a policy in the already decorrelated set and is discarded or is decorrelated with all the policies in the decorrelated set and is added to it.
基本的な脱線アルゴリズムは、相関のSPDで各エントリを取り、ツリー構造を使用してエントリのセットに分割します。ツリーのノードは、ポリシー間で重複する可能性のあるセレクターです。各ノードで、アルゴリズムはセレクターの各値のブランチを作成します。また、すべてのセレクター値の結合を補完するための1つのブランチを作成します。その後、ポリシーは、根から各葉までツリーを横断することによって形成されます。葉のポリシーは、既に切り離されたポリシールールのセットと比較されます。葉の各ポリシーは、既に切り離されたセットのポリシーによって完全に上書きされ、廃棄されるか、逆相関セットのすべてのポリシーと非相関があり、それに追加されます。
The basic algorithm does not guarantee an optimal set of decorrelated entries. That is, the entries may be broken up into smaller sets than is necessary, though they will still provide all the necessary policy information. Some extensions to the basic algorithm are described later to improve this and improve the performance of the algorithm.
基本的なアルゴリズムは、非相関エントリの最適なセットを保証するものではありません。つまり、エントリは必要以上に小さなセットに分割される場合がありますが、必要なすべてのポリシー情報を提供します。基本的なアルゴリズムへのいくつかの拡張は、これを改善し、アルゴリズムのパフォーマンスを改善するために後で説明します。
C A set of ordered, correlated entries (a correlated SPD). Ci The ith entry in C. U The set of decorrelated entries being built from C. Ui The ith entry in U. Sik The kth selection for policy Ci. Ai The action for policy Ci.
c順序付けられた相関エントリのセット（相関SPD）。CI C. uのITHエントリは、C。uiから構築されている逆相関エントリのセットであり、ポリシーCIのKTH選択。AIポリシーCIのアクション。
A policy (SPD entry) P may be expressed as a sequence of selector values and an action (BYPASS, DISCARD, or PROTECT):
ポリシー（SPDエントリ）pは、セレクター値のシーケンスとアクション（バイパス、廃棄、または保護）として表現できます。
Ci = Si1 x Si2 x ... x Sik -> Ai
1) Put C1 in set U as U1
1) c1をu1としてセットuに入れます
For each policy Cj (j > 1) in C
各ポリシーについてCJ（j> 1）
2) If Cj is decorrelated with every entry in U, then add it to U.
2) CJがuのすべてのエントリとともに逆関連している場合は、UをUに追加します。
3) If Cj is correlated with one or more entries in U, create a tree rooted at the policy Cj that partitions Cj into a set of decorrelated entries. The algorithm starts with a root node where no selectors have yet been chosen.
3) CJがuの1つ以上のエントリと相関している場合、CJを逆相関エントリのセットに分割するポリシーCJにルート化されたツリーを作成します。アルゴリズムは、選択者がまだ選択されていないルートノードから始まります。
A) Choose a selector in Cj, Sjn, that has not yet been chosen when traversing the tree from the root to this node. If there are no selectors not yet used, continue to the next unfinished branch until all branches have been completed. When the tree is completed, go to step D.
a）ルートからこのノードにツリーを通過するときにまだ選択されていないCJ、SJNのセレクターを選択します。まだ使用されていないセレクターがない場合は、すべてのブランチが完成するまで次の未完成のブランチに進みます。ツリーが完成したら、ステップDに移動します。
T is the set of entries in U that are correlated with the entry at this node.
Tは、このノードのエントリと相関するUのエントリのセットです。
The entry at this node is the entry formed by the selector values of each of the branches between the root and this node. Any selector values that are not yet represented by branches assume the corresponding selector value in Cj, since the values in Cj represent the maximum value for each selector.
このノードのエントリは、ルートとこのノードの間の各ブランチのセレクター値によって形成されるエントリです。CJの値は各セレクターの最大値を表すため、ブランチでまだ表されていないセレクター値は、CJの対応するセレクター値を想定しています。
B) Add a branch to the tree for each value of the selector Sjn that appears in any of the entries in T. (If the value is a superset of the value of Sjn in Cj, then use the value in Cj, since that value represents the universal set.) Also add a branch for the complement of the union of all the values of the selector Sjn in T. When taking the complement, remember that the universal set is the value of Sjn in Cj. A branch need not be created for the null set.
b）Tのいずれかのエントリに表示されるセレクターSJNの各値に対してツリーにブランチを追加します（値がCJのSJNの値のスーパーセットである場合、その値はCJの値を使用します。また、ユニバーサルセットを表します。）TのセレクターSJNのすべての値の結合を補完するブランチも追加します。補体を取得するとき、ユニバーサルセットはCJのSJNの値であることを忘れないでください。nullセット用にブランチを作成する必要はありません。
C) Repeat A and B until the tree is completed.
c）ツリーが完成するまでAとBを繰り返します。
D) The entry to each leaf now represents an entry that is a subset of Cj. The entries at the leaves completely partition Cj in such a way that each entry is either completely overridden by an entry in U, or is decorrelated with the entries in U.
d）各葉へのエントリは、CJのサブセットであるエントリを表します。葉のエントリは、各エントリがUへのエントリによって完全にオーバーライドされるか、Uのエントリと切り離されているように、CJを完全にパーティション化します。
Add all the decorrelated entries at the leaves of the tree to U.
ツリーの葉のすべての切り離されたエントリをUに追加します
4) Get next Cj and go to 2.
4) 次のCJを取得して2に進みます。
5) When all entries in C have been processed, then U will contain an decorrelated version of C.
5) Cのすべてのエントリが処理された場合、UにはCの逆バージョンが含まれます。
There are several optimizations that can be made to this algorithm. A few of them are presented here.
このアルゴリズムには、いくつかの最適化を行うことができます。それらのいくつかはここで提示されています。
It is possible to optimize, or at least improve, the amount of branching that occurs by carefully choosing the order of the selectors used for the next branch. For example, if a selector Sjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Sjn in Cj, then only a single branch needs to be created (since the complement will be null).
次のブランチに使用されるセレクターの順序を慎重に選択することによって発生する分岐の量を最適化するか、少なくとも改善することができます。たとえば、セレクターSJNを選択して、Tのそのセレクターのすべての値がCJのSJNの値のスーパーセットに等しいか、1つのブランチのみを作成する必要がある場合（補数はnullになるため、）。
Branches of the tree do not have to proceed with the entire decorrelation algorithm. For example, if a node represents an entry that is decorrelated with all the entries in U, then there is no reason to continue decorrelating that branch. Also, if a branch is completely overridden by an entry in U, then there is no reason to continue decorrelating the branch.
ツリーの枝は、脱相関アルゴリズム全体を進める必要はありません。たとえば、ノードがuのすべてのエントリと非関連するエントリを表している場合、そのブランチを切り替える理由はありません。また、Uへのエントリによってブランチが完全に上書きされた場合、ブランチの切り替えを続ける理由はありません。
An additional optimization is to check to see if a branch is overridden by one of the CORRELATED entries in set C that has already been decorrelated. That is, if the branch is part of decorrelating Cj, then check to see if it was overridden by an entry Cm, m < j. This is a valid check, since all the entries Cm are already expressed in U.
追加の最適化は、すでに非相関されているセットCの相関エントリの1つによってブランチがオーバーライドされているかどうかを確認することです。つまり、ブランチがCJの逆相関の一部である場合、エントリCM、m <jによってオーバーライドされたかどうかを確認してください。これは、すべてのエントリCMがすでにUで表現されているため、有効なチェックです。
Along with checking if an entry is already decorrelated in step 2, check if Cj is overridden by any entry in U. If it is, skip it since it is not relevant. An entry x is overridden by another entry y if every selector in x is equal to or a subset of the corresponding selector in entry y.
ステップ2でエントリが既に切り離されているかどうかを確認するとともに、CJがUのエントリによってオーバーライドされているかどうかを確認してください。エントリxは、xのすべてのセレクターがエントリyの対応するセレクターのサブセットに等しい場合、別のエントリyによってオーバーライドされます。
Appendix C: ASN.1 for an SPD Entry
付録C：SPDエントリのASN.1
This appendix is included as an additional way to describe SPD entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The SPD description in Section 4.4.1 is normative.
この付録は、セクション4.4.1で定義されているように、SPDエントリを記述する追加の方法として含まれています。asn.1構文を使用して、正常にコンパイルされています。この構文は単なる説明であり、コンプライアンスを達成するために実装に採用する必要はありません。セクション4.4.1のSPD説明は規範的です。
SPDModule
spdmodule
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) }
{ISO（1）org（3）dod（6）インターネット（1）セキュリティ（5）メカニズム（5）IPSEC（8）ASN1-modules（3）SPD-Module（1）}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
始める
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
FQDN ::= IA5String
RFC822Name ::= IA5String
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
SelectorLists ::= SET OF SelectorList
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice }
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
KeyIDs ::= SEQUENCE OF OCTET STRING
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm} -- defined outside
-- of this document for AES modes.
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
df DF,
addresses TunnelAddresses }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
END
終わり
Appendix D: Fragment Handling Rationale
付録D：断片の処理理論的根拠
There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec:
IPSECの（プレーンテキスト）フラグメントの処理に関して解決する必要がある3つの問題があります。
- mapping a non-initial, outbound fragment to the right SA (or finding the right SPD entry) - verifying that a received, non-initial fragment is authorized for the SA via which it is received - mapping outbound and inbound non-initial fragments to the right SPD/cache entry, for BYPASS/DISCARD traffic
- 右のSAへの非初性的なアウトバウンドフラグメントのマッピング（または右のSPDエントリを見つける） - 受信した非初心的なフラグメントが受信されたSAに対して認可されていることを確認します - アウトバウンドおよびインバウンドの非初期的なフラグメントをマッピングしますバイパス/破棄トラフィック用の適切なSPD/キャッシュエントリ
The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated.
トラフィックをSAS（およびSPD/キャッシュエントリ）にマッピングするための決定論的アルゴリズムが必要であるため、最初と3番目の問題が発生します。3つの問題はすべて重要です。なぜなら、IPSECの境界を横切る非独創的なフラグメントが、受信機（または送信機）に所定のアクセス制御ポリシーが違反させないことを確認したいからです。
First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing.
まず、輸送モードSASがフラグメントを運ばないように定義されていることに注意してください。これは、RFC 2401からのキャリーオーバーであり、輸送モードSAは常にエンドポイントで終了しました。これは、最悪の場合、IPSECが適用されたIPv4フラグメントが断片化され、宛先に向かう途中で断片化される可能性があるため、基本的な要件です。IPSECレシーバーでのIPフラグメント再組み立て手順では、IPSEC処理後に作成されたPre-IPSECフラグメントとフラグメントを区別することはできません。
For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver with respect to reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. To keep things simple, this specification prohibits carriage of fragments on transport mode SAs for IPv6 traffic.
IPv6の場合、送信者のみがパケットを断片化できます。IPv4に関しては、IPSEC処理後にIPSECの実装は、（外側の）トンネルヘッダーに対する送信者であるため、Tunnel Modeパケットをフラグメントすることが許可されています。ただし、IPv4とは異なり、IPv6のフラグメントヘッダーがAHまたはESPヘッダーの後に表示され、したがってレシーバーに再組み立てに関して混乱を引き起こすことはないため、トランスポートモードSAにプレーンテキストフラグメントを運ぶことが可能です。具体的には、受信者は、IPSEC処理後までフラグメントの再組み立てを試みません。物事をシンプルに保つために、この仕様により、IPv6トラフィックの輸送モードSAS上のフラグメントのキャリッジが禁止されています。
When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation, this seems reasonable, and, as someone already noted, RFC 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would then apply AH or ESP and could re-fragment the packet after IPsec processing.) Because a BITS implementation is assumed to be able to have access to all traffic emanating from its host, even if the host has multiple interfaces, this was deemed a reasonable mandate.
輸送モードSASを使用した最終システムのみが使用された場合、最終システムがIPSECにフラグメントを提供しないように構成できると仮定したため、フラグメントのキャリッジの禁止は問題ではありませんでした。ネイティブのホストの実装の場合、これは合理的であるように思われ、誰かがすでに注目しているように、RFC 2401は、SAルックアップを実行する前にBITS実装がフラグメントを再組み立てする必要があるかもしれないと警告しました。（その後、AHまたはESPを適用し、IPSEC処理後にパケットを再燃させる可能性があります。）BITS実装は、ホストに複数のインターフェイスがある場合でも、ホストから発せられるすべてのトラフィックにアクセスできると想定されているため、これは合理的な任務とみなされます。
In this specification, it is acceptable to use transport mode in cases where the IPsec implementation is not the ultimate destination, e.g., between two SGs. In principle, this creates a new opportunity for outbound, plaintext fragments to be mapped to a transport mode SA for IPsec processing. However, in these new contexts in which a transport mode SA is now approved for use, it seems likely that we can continue to prohibit transmission of fragments, as seen by IPsec, i.e., packets that have an "outer header" with a non-zero fragment offset field. For example, in an IP overlay network, packets being sent over transport mode SAs are IP-in-IP tunneled and thus have the necessary inner header to accommodate fragmentation prior to IPsec processing. When carried via a transport mode SA, IPsec would not examine the inner IP header for such traffic, and thus would not consider the packet to be a fragment.
この仕様では、IPSECの実装が2つのSGの間の最終目的地ではない場合に輸送モードを使用することは許容されます。原則として、これは、IPSEC処理のために、アウトバウンドのプレーンテキストフラグメントを輸送モードSAにマッピングする新しい機会を生み出します。ただし、輸送モードSAが使用されるようになったこれらの新しいコンテキストでは、IPSEC、つまり、非以外の「外側ヘッダー」を備えたパケットで見られるように、フラグメントの送信を引き続き禁止できるように思われます。ゼロフラグメントオフセットフィールド。たとえば、IPオーバーレイネットワークでは、トランスポートモードで送信されるパケットSASはIP-in-IPトンネルであるため、IPSEC処理の前に断片化に対応するために必要な内部ヘッダーがあります。トランスポートモードSAを介して運ばれる場合、IPSECはそのようなトラフィックの内側のIPヘッダーを調べないため、パケットがフラグメントであるとは見なされません。
For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem.
トンネルモードSASの場合、IPSECの実装で処理するためにアウトバウンドフラグメントが到着する可能性が常にありました。断片化されたアウトバウンドパケットに対応する必要性は、一般に非初期的なフラグメントには、TCP、UDP、またはSCTPなどの次のレイヤープロトコルに関連付けられたポートフィールドが含まれないため、問題を引き起こす可能性があります。したがって、特定のIPSEC実装のSPD構成に応じて、Plantextフラグメントが問題を引き起こす可能性がある場合とそうでない場合があります。
For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.)
たとえば、SPDが2つのアドレス範囲間のすべてのトラフィックにIPSEC保護が提供されることを要求する場合（このアドレス範囲にバイパスまたは破棄SPDエントリが適用されません）、このアドレスに対して定義されたSAで非初期的なフラグメントを簡単に運ぶことができます範囲は、SPDエントリはアドレス範囲間のすべてのトラフィックを運ぶ意図を意味するためです。ただし、フラグメントに一致する可能性のある複数のSPDエントリがあり、これらのエントリがポートフィールドの異なるサブセットを参照する場合（任意）、アウトバウンド非向性フラグメントを適切なエントリにマッピングすることはできません。（IPv6の輸送モードSASでの断片のキャリッジを許可することを選択した場合、そのコンテキストでも問題が発生します。）
This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic arrived at an SG, these fields would be encrypted. The algorithm specified for locating the "next layer protocol" described in RFC 2401 also motivated use of OPAQUE to accommodate an encrypted next layer protocol field in such circumstances. Nonetheless, the primary use of the OPAQUE value was to match traffic selector fields in packets that did not contain port fields (non-initial fragments), or packets in which the port fields were already encrypted (as a result of nested application of IPsec). RFC 2401 was ambiguous in discussing the use of OPAQUE vs. ANY, suggesting in some places that ANY might be an alternative to OPAQUE.
この問題は、主に排他的ではありませんが、RFC 2401のポートフィールドのセレクター値として不透明の定義を動機付けました。不透明のもう1つの動機は、IPSECの以前の適用のためにポートフィールドにアクセスできない可能性があるという観察です。たとえば、ホストがトラフィックにIPSECを適用し、トラフィックがSGに到着した場合、これらのフィールドは暗号化されます。RFC 2401で説明されている「次のレイヤープロトコル」を見つけるために指定されたアルゴリズムは、このような状況で暗号化された次のレイヤープロトコルフィールドに対応するために不透明の使用を動機付けました。それにもかかわらず、不透明な値の主な使用は、ポートフィールド（非初期的なフラグメント）を含まないパケットのトラフィックセレクターフィールド、またはポートフィールドがすでに暗号化されているパケットを一致させることでした（IPSECのネストされたアプリケーションの結果として）。RFC 2401は、不透明と任意の不透明の使用について議論するのが曖昧であり、一部の場所では不透明の代替手段である可能性があることを示唆しています。
We gain additional access control capability by defining both ANY and OPAQUE values. OPAQUE can be defined to match only fields that are not accessible. We could define ANY as the complement of OPAQUE, i.e., it would match all values but only for accessible port fields. We have therefore simplified the procedure employed to locate the next layer protocol in this document, so that we treat ESP and AH as next layer protocols. As a result, the notion of an encrypted next layer protocol field has vanished, and there is also no need to worry about encrypted port fields either. And accordingly, OPAQUE will be applicable only to non-initial fragments.
任意の値と不透明な値の両方を定義することにより、追加のアクセス制御機能を獲得します。不透明は、アクセスできないフィールドのみに一致するように定義できます。あらゆるものを不透明の補体として定義できます。つまり、すべての値と一致しますが、アクセス可能なポートフィールドのみです。したがって、このドキュメントの次のレイヤープロトコルを見つけるために採用されている手順を簡素化したため、ESPとAHを次のレイヤープロトコルとして扱います。その結果、暗号化された次のレイヤープロトコルフィールドの概念が消滅し、暗号化されたポートフィールドについても心配する必要はありません。したがって、不透明は非独創的な断片にのみ適用されます。
Since we have adopted the definitions above for ANY and OPAQUE, we need to clarify how these values work when the specified protocol does not have port fields, and when ANY is used for the protocol selector. Accordingly, if a specific protocol value is used as a selector, and if that protocol has no port fields, then the port field selectors are to be ignored and ANY MUST be specified as the value for the port fields. (In this context, ICMP TYPE and CODE values are lumped together as a single port field (for IKEv2 negotiation), as is the IPv6 Mobility Header TYPE value.) If the protocol selector is ANY, then this should be treated as equivalent to specifying a protocol for which no port fields are defined, and thus the port selectors should be ignored, and MUST be set to ANY.
上記の定義を任意の不透明で採用したため、指定されたプロトコルにポートフィールドがない場合、およびプロトコルセレクターに使用される場合、これらの値がどのように機能するかを明確にする必要があります。したがって、特定のプロトコル値がセレクターとして使用され、そのプロトコルにポートフィールドがない場合、ポートフィールドセレクターを無視し、ポートフィールドの値として指定する必要があります。（このコンテキストでは、IPv6モビリティヘッダータイプ値と同様に、ICMPタイプとコード値は単一のポートフィールドとして（IKEV2ネゴシエーションの場合）まとめます。）プロトコルセレクターがいずれかである場合、これは指定と同等であると扱われる必要があります。ポートフィールドが定義されていないプロトコル、したがってポートセレクターを無視する必要があり、任意に設定する必要があります。
For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However, RFC 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in RFC 2401) allowed an SA to carry non-initial fragments.
SG実装の場合、フラグメントがSGの背後にあるエンドシステムから到着する可能性があることは明らかです。また、BITWの実装は、その背後にあるホストまたはゲートウェイからのフラグメントに遭遇する可能性があります。（前述のように、ネイティブのホストの実装とBITS実装は、おそらく以下の問題を回避する可能性があります。）最悪の場合、パケットからのフラグメントは、異なるBITWまたはSGインスタンス化に到達し、したがってソリューションオプションとして再組み立てを排除する可能性があります。したがって、RFC 2401では、すべての実装に対してトンネルモードでフラグメントを収容する必要があるという一般的な要件を採用しました。ただし、RFC 2401は完璧なソリューションを提供しませんでした。ポートフィールドのセレクター値として不透明を使用することで（RFC 2401ではAが必要）、SAは非独創的なフラグメントを運ぶことができました。
Using the features defined in RFC 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the source/destination (S/D) address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA.
RFC 2401で定義された機能を使用して、両方のポートフィールドの不透明値を使用して2つのIPSEC（SGまたはBITW）の実装の間でSAを定義した場合、ソース/宛先（S/D）アドレスとプロトコルに一致するすべての非初期的なフラグメントSAの値はそのSAにマッピングされます。不透明の厳格な定義を採用すると、初期のフラグメントはこのSAにマッピングされません。ただし、RFC 2401はこれに関する詳細なガイダンスを提供していなかったため、この機能を使用すると「非初期的なフラグメントのみ」SAが作成されることは明らかではなかったかもしれません。
In the course of discussing the "fragment-only" SA approach, it was noted that some subtle problems, problems not considered in RFC 2401, would have to be avoided. For example, an SA of this sort must be configured to offer the "highest quality" security services for any traffic between the indicated S/D addresses (for the specified protocol). This is necessary to ensure that any traffic captured by the fragment-only SA is not offered degraded security relative to what it would have been offered if the packet were not fragmented. A possible problem here is that we may not be able to identify the "highest quality" security services defined for use between two IPsec implementation, since the choice of security protocols, options, and algorithms is a lattice, not a totally ordered set. (We might safely say that BYPASS < AH < ESP w/integrity, but it gets complicated if we have multiple ESP encryption or integrity algorithm options.) So, one has to impose a total ordering on these security parameters to make this work, but this can be done locally.
「フラグメントのみの」SAアプローチについて議論する過程で、RFC 2401では考慮されていない問題を避けなければならないことに注意しました。たとえば、この種のSAは、指定されたS/Dアドレス間のトラフィック（指定されたプロトコル用）に「最高品質の」セキュリティサービスを提供するように構成する必要があります。これは、フラグメントのみのSAによってキャプチャされたトラフィックが、パケットが断片化されていない場合に提供されたものと比較して、劣化したセキュリティを提供されないことを保証するために必要です。ここで考えられる問題は、セキュリティプロトコル、オプション、およびアルゴリズムの選択は格子であり、完全に順序付けられたセットではないため、2つのIPSEC実装の間で使用するために定義される「最高品質の」セキュリティサービスを特定できない可能性があることです。（私たちは安全にバイパス<ah <ah <esp w/integrityを言うかもしれませんが、複数のESP暗号化または整合性アルゴリズムのオプションがあると複雑になります。）したがって、この作業を行うにはこれらのセキュリティパラメーターに合計注文を課す必要がありますが、これはローカルで行うことができます。
However, this conservative strategy has a possible performance downside. If most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach. Nonetheless, the performance impact is a potential concern, specific to implementation capabilities.)
ただし、この保守的な戦略には、パフォーマンスの欠点があります。特定のS/Dアドレスペア（および指定されたプロトコル）のIPSEC実装を通過するほとんどのトラフィックがバイパスされた場合、そのアドレスペアのフラグメントのみのSAは、暗号処理に与えられるトラフィックの量の劇的な増加を引き起こす可能性があります。暗号の実装が交通量の多い料金をサポートできない場合、これは問題を引き起こす可能性があります。（ラインレートまたはラインレートに近い暗号パフォーマンスが可能なIPSEC実装は、このSA構成アプローチによって悪影響を受けません。それでも、パフォーマンスへの影響は、実装機能に特有の潜在的な懸念事項です。）
Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments and is not a side effect of normal fragmentation.) This concern is easily addressed in IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of, say, 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver.
別の懸念は、明らかに許容される初期フラグメントと組み合わされた場合、専用のSAを介して送信された非独創的な断片を使用して、重複する再組み立て攻撃を実施するために使用される可能性があることです。（この種の攻撃は、偽の断片の作成を想定しており、通常の断片化の副作用ではありません。）この懸念は、フラグメントオフセット値をチェックして、非独創的なフラグメントがオーバーラップするのに十分な十分なオフセットを持たないことを確認することにより、IPv4で簡単に対処されます。最初のフラグメントに含まれるべきポートフィールド。IPv4 MTUの最小値は576バイトであり、最大IPヘッダーの長さは60バイトであるため、最初のフラグメントにはポートが存在する必要があることを思い出してください。すべての非独創的なフラグメントが、たとえば128以上のオフセットを安全にする必要がある場合、これにより、この種の攻撃が成功するのを防ぐ必要があります。意図がこの種の再組み立て攻撃から保護することのみである場合、このチェックは受信機のみで実装する必要があります。
IPv6 also has a fragment offset, carried in the fragmentation extension header. However, IPv6 extension headers are variable in length and there is no analogous max header length value that we can use to check non-initial fragments, to reject ones that might be used for an attack of the sort noted above. A receiver would need to maintain state analogous to reassembly state, to provide equivalent protection. So, only for IPv4 is it feasible to impose a fragment offset check that would reject attacks designed to circumvent port field checks by IPsec (or firewalls) when passing non-initial fragments.
IPv6には、フラグメンテーション拡張ヘッダーに掲載されたフラグメントオフセットもあります。ただし、IPv6拡張ヘッダーは長さが変動し、非初期的なフラグメントをチェックするために使用できる類似の最大ヘッダー長値はありません。受信者は、同等の保護を提供するために、状態を再組み立て状態と同様に維持する必要があります。したがって、IPv4のみの場合にのみ、非初期的なフラグメントを通過するときにIPSEC（またはファイアウォール）によってポートフィールドチェックを回避するように設計された攻撃を拒否するフラグメントオフセットチェックを課すことが可能です。
Another possible concern is that in some topologies and SPD configurations this approach might result in an access control surprise. The notion is that if we create an SA to carry ALL (non-initial) fragments, then that SA would carry some traffic that might otherwise arrive as plaintext via a separate path, e.g., a path monitored by a proxy firewall. But, this concern arises only if the other path allows initial fragments to traverse it without requiring reassembly, presumably a bad idea for a proxy firewall. Nonetheless, this does represent a potential problem in some topologies and under certain assumptions with respect to SPD and (other) firewall rule sets, and administrators need to be warned of this possibility.
もう1つの可能性のある懸念は、一部のトポロジとSPD構成では、このアプローチがアクセス制御の驚きをもたらす可能性があることです。概念は、すべての（非初期的な）フラグメントを運ぶためにSAを作成すると、SAは別のパス、たとえばプロキシファイアウォールによって監視されているパスを介してプレーンテキストとして到着する可能性のあるトラフィックを運ぶということです。しかし、この懸念は、他のパスが再組み立てを必要とせずに初期フラグメントを通過させることを許可する場合にのみ発生します。おそらくプロキシファイアウォールの悪い考えです。それにもかかわらず、これはいくつかのトポロジの潜在的な問題を表しており、SPDおよび（他の）ファイアウォールルールセットに関する特定の仮定の下で、管理者にこの可能性について警告する必要があります。
A less serious concern is that non-initial fragments sent over a non-initial fragment-only SA might represent a DoS opportunity, in that they could be sent when no valid, initial fragment will ever arrive. This might be used to attack hosts behind an SG or BITW device. However, the incremental risk posed by this sort of attack, which can be mounted only by hosts behind an SG or BITW device, seems small.
それほど深刻ではない懸念は、無効なフラグメントのみのSAを介して送信された非独創的なフラグメントが、有効な初期フラグメントが到着しない場合に送信できるという点で、DOSの機会を表す可能性があることです。これは、SGまたはBITWデバイスの背後にあるホストを攻撃するために使用される場合があります。ただし、SGまたはBITWデバイスの背後にあるホストによってのみマウントできるこの種の攻撃によってもたらされる増分リスクは、小さいようです。
If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative.
セレクター値を不透明なものと解釈すると、両方のポートフィールドの任意の値を持つ単一のSAは、S/Dアドレスとプロトコルトラフィックセレクターに一致するすべてのトラフィックに対応できます。これは、不透明な値を使用する代わりになります。ただし、ここで使用すると、同じアドレスペアとプロトコルの同じIPSEC実装の間に複数の異なるSAが排除されます。したがって、それは正確に同等の代替品ではありません。
Fundamentally, fragment handling problems arise only when more than one SA is defined with the same S/D address and protocol selector values, but with different port field selector values.
基本的に、フラグメント処理の問題は、同じS/Dアドレスとプロトコルセレクターの値で複数のSAが定義されている場合にのみ発生しますが、ポートフィールドセレクターの値が異なります。
We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons:
また、SA処理とは無関係に、バイパス/廃棄エントリのための非初期的なフラグメント処理の問題に対処する必要があります。これは主に2つの理由でローカルな問題です。
1) We have no means for coordinating SPD entries for such traffic between IPsec implementations since IKE is not invoked. 2) Many of these entries refer to traffic that is NOT directed to or received from a location that is using IPsec. So there is no peer IPsec implementation with which to coordinate via any means.
1) IKEが呼び出されていないため、IPSEC実装間でこのようなトラフィックのSPDエントリを調整する手段はありません。2）これらのエントリの多くは、IPSECを使用している場所に向けられていない、または受け取ったトラフィックを指します。そのため、いかなる手段でも調整するピアIPSECの実装はありません。
However, this document should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, this document says that implementations MUST support fragment reassembly for BYPASS/DISCARD traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described in Section 4.4.1. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec-protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort.
ただし、このドキュメントは、IPSEC境界に比べて、すべてのトラフィックに明確に定義されたアクセス制御機能を提供するという目標と一致して、ここでガイダンスを提供する必要があります。そのために、このドキュメントによると、実装は、ポートフィールドが指定されているときにトラフィックをバイパス/破棄するためのフラグメントの再組み立てをサポートする必要があると述べています。また、実装では、ユーザーまたは管理者がセクション4.4.1で説明したSPD規則を使用して、そのようなトラフィックを受け入れるか、そのようなトラフィックを拒否することも許可する必要があります。懸念は、IPSECの実装に到着するクリアテキストの非初心者フラグメントのバイパスが、同じ宛先に向けられたIPSEC保護されたトラフィックが提供されるセキュリティを損なう可能性があることです。たとえば、特定のソース/宛先アドレスペア間のトラフィックのIPSECの保護を必要とするSPDエントリで構成されたIPSEC実装を検討し、特定のプロトコルと宛先ポート、例えばポート23のTCPトラフィック（Telnet）を使用します。この実装により、同じソース/宛先アドレスペアとプロトコルからのトラフィックのバイパスも可能であると仮定しますが、別の宛先ポート（ポート119（NNTP）など）。攻撃者は、バイパスされれば、同じソースからのIPSECで保護されたトラフィックと重複し、IPSECで保護されたトラフィックの完全性に違反する可能性がある非初心者フラグメント（偽造ソースアドレス付き）を送信できます。自明でないポート範囲を使用してバイパスエントリをチェックすることを要求すると、この種の攻撃が防止されます。
It has been suggested that we could avoid the problems described above by not allowing port field selectors to be used in tunnel mode. But the discussion above shows this to be an unnecessarily stringent approach, i.e., since no problems arise for the native OS and BITS implementations. Moreover, some WG members have described scenarios where use of tunnel mode SAs with (non-trivial) port field selectors is appropriate. So the challenge is defining a strategy that can deal with this problem in BITW and SG contexts. Also note that BYPASS/DISCARD entries in the SPD that make use of ports pose the same problems, irrespective of tunnel vs. transport mode notions.
ポートフィールドセレクターをトンネルモードで使用できないことにより、上記の問題を回避できることが示唆されています。しかし、上記の議論は、これが不必要に厳しいアプローチであることを示しています。つまり、ネイティブのOSとBITSの実装では問題が発生しないためです。さらに、一部のWGメンバーは、（自明でない）ポートフィールドセレクターを使用したトンネルモードSASの使用が適切なシナリオを説明しています。したがって、課題は、BITWおよびSGコンテキストでこの問題に対処できる戦略を定義することです。また、ポートを使用するSPDのバイパス/破棄エントリは、トンネルと輸送モードの概念に関係なく、同じ問題を引き起こすことに注意してください。
Some folks have suggested that a firewall behind an SG or BITW should be left to enforce port-level access controls and the effects of fragmentation. However, this seems to be an incongruous suggestion in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about firewalls that always discard fragments. If many firewalls don't pass fragments in general, why should we expect them to deal with fragments in this case? So, this analysis rejects the suggestion of disallowing use of port field selectors with tunnel mode SAs.
一部の人々は、ポートレベルのアクセスコントロールとフラグメンテーションの効果を実施するために、SGまたはBITWの背後にあるファイアウォールを残す必要があることを提案しています。ただし、これはIPSECの他の場所（Ike Payloads）の他の場所では、常に断片を破棄するファイアウォールについて心配しているという点で、不調和な提案のようです。多くのファイアウォールが一般的にフラグメントを通過しない場合、なぜこの場合、それらがフラグメントに対処することを期待する必要があるのですか？したがって、この分析は、トンネルモードSASを使用したポートフィールドセレクターの使用を許可するという提案を拒否します。
One suggestion is to reassemble fragments at the sending IPsec implementation, and thus avoid the problem entirely. This approach is invisible to a receiver and thus could be adopted as a purely local implementation option.
1つの提案は、送信IPSEC実装でフラグメントを再組み立てし、問題を完全に回避することです。このアプローチはレシーバーには見えないため、純粋にローカルな実装オプションとして採用できます。
A more sophisticated version of this suggestion calls for establishing and maintaining minimal state from each initial fragment encountered, to allow non-initial fragments to be matched to the right SAs or SPD/cache entries. This implies an extension to the current processing model (and the old one). The IPsec implementation would intercept all fragments; capture Source/Destination IP addresses, protocol, packet ID, and port fields from initial fragments; and then use this data to map non-initial fragments to SAs that require port fields. If this approach is employed, the receiver needs to employ an equivalent scheme, as it too must verify that received fragments are consistent with SA selector values. A non-initial fragment that arrives prior to an initial fragment could be cached or discarded, awaiting arrival of the corresponding initial fragment.
この提案のより洗練されたバージョンでは、遭遇した各初期フラグメントから最小限の状態を確立および維持することを求めて、非独創的なフラグメントを右のSASまたはSPD/キャッシュエントリに一致させることができます。これは、現在の処理モデル（および古いモデル）の拡張を意味します。IPSECの実装は、すべてのフラグメントを傍受します。初期フラグメントからソース/宛先IPアドレス、プロトコル、パケットID、およびポートフィールドをキャプチャします。次に、このデータを使用して、ポートフィールドを必要とするSASに非初期的なフラグメントをマッピングします。このアプローチが採用されている場合、受信したフラグメントがSAセレクター値と一致していることを確認する必要があるため、受信者は同等のスキームを使用する必要があります。初期フラグメントの前に到着する非独創的なフラグメントは、対応する初期フラグメントの到着を待っている可能性があります。
A downside of both approaches noted above is that they will not always work. When a BITW device or SG is configured in a topology that might allow some fragments for a packet to be processed at different SGs or BITW devices, then there is no guarantee that all fragments will ever arrive at the same IPsec device. This approach also raises possible processing problems. If the sender caches non-initial fragments until the corresponding initial fragment arrives, buffering problems might arise, especially at high speeds. If the non-initial fragments are discarded rather than cached, there is no guarantee that traffic will ever pass, e.g., retransmission will result in different packet IDs that cannot be matched with prior transmissions. In any case, housekeeping procedures will be needed to decide when to delete the fragment state data, adding some complexity to the system. Nonetheless, this is a viable solution in some topologies, and these are likely to be common topologies.
上記の両方のアプローチの欠点は、それらが常に機能するとは限らないということです。BITWデバイスまたはSGが、パケットが異なるSGSまたはBITWデバイスで処理される可能性のあるいくつかのフラグメントを可能にする可能性のあるトポロジで構成されている場合、すべてのフラグメントが同じIPSECデバイスに到達するという保証はありません。このアプローチは、可能な処理の問題も提起します。送信者が対応する初期フラグメントが到着するまで非初気性フラグメントをキャッシュすると、特に高速でバッファリングの問題が発生する可能性があります。非向性フラグメントがキャッシュではなく破棄されている場合、トラフィックが通過するという保証はありません。たとえば、再送信により、以前の送信と一致できない異なるパケットIDが生じます。いずれにせよ、フラグメント状態データをいつ削除するかを決定し、システムに複雑さを追加するために、ハウスキーピング手順が必要になります。それにもかかわらず、これは一部のトポロジーでは実行可能なソリューションであり、これらは一般的なトポロジである可能性があります。
The Working Group rejected an earlier version of the convention of creating an SA to carry only non-initial fragments, something that was supported implicitly under the RFC 2401 model via use of OPAQUE port fields, but never clearly articulated in RFC 2401. The (rejected) text called for each non-initial fragment to be treated as protocol 44 (the IPv6 fragment header protocol ID) by the sender and receiver. This approach has the potential to make IPv4 and IPv6 fragment handling more uniform, but it does not fundamentally change the problem, nor does it address the issue of fragment handling for BYPASS/DISCARD traffic. Given the fragment overlap attack problem that IPv6 poses, it does not seem that it is worth the effort to adopt this strategy.
ワーキンググループは、不透明なポートフィールドを使用してRFC 2401モデルで暗黙的にサポートされていたが、RFC 2401で明確に表現されることはありません。）送信者と受信機によって、各非初気性フラグメントがプロトコル44（IPv6フラグメントヘッダープロトコルID）として扱われるように呼ばれるテキスト。このアプローチは、IPv4およびIPv6フラグメントの処理をより均一にする可能性がありますが、問題を根本的に変更することはなく、バイパス/破棄トラフィックのフラグメント処理の問題に対処することもありません。IPv6がもたらすフラグメントのオーバーラップ攻撃の問題を考えると、この戦略を採用する努力の価値はないようです。
Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform fragmentation prior to IPsec processing. If this fragmentation is performed after SA lookup at the sender, there is no "mapping to the right SA" problem. But, the receiver still needs to be able to verify that the non-initial fragments are consistent with the SA via which they are received. Since the initial fragment might be lost en route, the receiver encounters all of the potential problems noted above. Thus, if we are to be consistent in our decisions, we need to say how a receiver will deal with the non-initial fragments that arrive.
以前、WGは、IPSEC処理の前にIPSECビット、BITW、またはSGが断片化を実行できるようにすることに同意しました。この断片化が送信者を検索した後に実行された場合、「適切なSAへのマッピング」問題はありません。しかし、受信者は、非初期的なフラグメントが受信されるSAと一致していることを確認できる必要があります。最初のフラグメントは途中で失われる可能性があるため、受信者は上記のすべての潜在的な問題に遭遇します。したがって、私たちが私たちの決定に一貫しているなら、私たちは受信者が到着した非独創的な断片をどのように扱うかを言う必要があります。
There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus, this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed.
すべてのコンテキストでフラグメントを処理する簡単で均一な方法はありません。さまざまなアプローチは、さまざまなコンテキストでうまく機能します。したがって、このドキュメントは3つの選択肢を提供します - 1つと2つのメイ。将来のある時点で、コミュニティが2つのメイで経験を積む場合、彼らは肩や必需品、または他のアプローチが提案される可能性があります。
Appendix E: Example of Supporting Nested SAs via SPD and Forwarding Table Entries
付録E：SPDおよび転送テーブルエントリを介したネストされたSASをサポートする例
This appendix provides an example of how to configure the SPD and forwarding tables to support a nested pair of SAs, consistent with the new processing model. For simplicity, this example assumes just one SPD-I.
この付録は、新しい処理モデルと一致して、SASのネストされたペアをサポートするためにSPDと転送テーブルを構成する方法の例を示しています。簡単にするために、この例では1つのSPD-Iのみを想定しています。
The goal in this example is to support a transport mode SA from A to C, carried over a tunnel mode SA from A to B. For example, A might be a laptop connected to the public Internet, B might be a firewall that protects a corporate network, and C might be a server on the corporate network that demands end-to-end authentication of A's traffic.
この例の目標は、AからCへの輸送モードSAをサポートし、トンネルモードSAをAからBに運ぶことです。たとえば、Aはパブリックインターネットに接続されたラップトップである可能性があります。コーポレートネットワーク、およびCは、Aのトラフィックのエンドツーエンド認証を要求するコーポレートネットワーク上のサーバーである可能性があります。
+---+ +---+ +---+
| A |=====| B | | C |
| |------------| |
| |=====| | | |
+---+ +---+ +---+
A's SPD contains entries of the form:
AのSPDには、フォームのエントリが含まれています。
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- -----------------------
1 C A ESP BYPASS
2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
3 A C ANY PROTECT(ESP,transport,integr-only)
4 A B ICMP,IKE BYPASS
A's unprotected-side forwarding table is set so that outbound packets destined for C are looped back to the protected side. A's protected-side forwarding table is set so that inbound ESP packets are looped back to the unprotected side. A's forwarding tables contain entries of the form:
Aの保護されていないサイドの転送テーブルが設定されているため、C用のアウトバウンドパケットが保護された側にループされます。Aの保護された側面の転送テーブルは、インバウンドESPパケットが保護されていない側にループされるように設定されています。Aの転送テーブルには、フォームのエントリが含まれています。
Unprotected-side forwarding table
保護されていないサイド転送テーブル
Rule Local Remote Protocol Action
---- ----- ------ -------- ---------------------------
1 A C ANY loop back to protected side
2 A B ANY forward to B
Protected-side forwarding table
保護された側面転送テーブル
Rule Local Remote Protocol Action
---- ----- ------ -------- -----------------------------
1 A C ESP loop back to unprotected side
An outbound TCP packet from A to C would match SPD rule 3 and have transport mode ESP applied to it. The unprotected-side forwarding table would then loop back the packet. The packet is compared against SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The packet is treated as an outbound packet and compared against the SPD for a third time. This time it matches SPD rule 2, so ESP is applied in tunnel mode. This time the forwarding table doesn't loop back the packet, because the outer destination address is B, so the packet goes out onto the wire.
AからCまでのアウトバウンドTCPパケットは、SPDルール3に一致し、輸送モードESPが適用されます。保護されていないサイド転送テーブルは、パケットをループバックします。パケットはSPD-I（図2を参照）と比較され、SPDルール1と一致するため、バイパスされます。パケットはアウトバウンドパケットとして扱われ、3回目のSPDに対して比較されます。今回はSPDルール2と一致するため、ESPはトンネルモードで適用されます。今回は、外側の宛先アドレスがBであるため、転送テーブルがパケットをループバックしないため、パケットがワイヤーに出ます。
An inbound TCP packet from C to A is wrapped in two ESP headers; the outer header (ESP in tunnel mode) shows B as the source, whereas the inner header (ESP transport mode) shows C as the source. Upon arrival at A, the packet would be mapped to an SA based on the SPI, have the outer header removed, and be decrypted and integrity-checked. Then it would be matched against the SAD selectors for this SA, which would specify C as the source and A as the destination, derived from SPD rule 2. The protected-side forwarding function would then send it back to the unprotected side based on the addresses and the next layer protocol (ESP), indicative of nesting. It is compared against SPD-O (see Figure 3) and found to match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA based on the SPI, integrity-checked, and compared against the SAD selectors derived from SPD rule 3. The forwarding function then passes it up to the next layer, because it isn't an ESP packet.
CからAへのインバウンドTCPパケットは、2つのESPヘッダーに包まれています。外側のヘッダー（トンネルモードのESP）はBをソースとして表示しますが、内側のヘッダー（ESP輸送モード）はCをソースとして表示します。Aに到着すると、パケットはSPIに基づいてSAにマッピングされ、外側のヘッダーを取り外し、復号化され、整合性チェックされます。次に、このSAの悲しいセレクターと一致します。このSAは、SPDルール2から派生したcをソースとして、およびAs as as as the Spd Rule 2から指定します。アドレスと次のレイヤープロトコル（ESP）、ネストを示す。SPD-O（図3を参照）と比較され、SPDルール1に一致することがわかっているため、バイパスされます。パケットは、SPIに基づいてSAにマッピングされ、整合性チェックされ、SPDルール3から派生したSADセレクターと比較されます。転送関数は、ESPパケットではないため、次のレイヤーに渡します。
References
参考文献
Normative References
引用文献
[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[BBCDWW98] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[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月。
[CD98] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[CD98] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98] Deering、S。、およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[EAS05]第3イーストレイク、D。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4305、2005年12月。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Harcar98] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05] Kaufman、C.、ed。、「The Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[Ken05a] Kent、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Ken05b] Kent、S。、「IP Authentication Header」、RFC 4302、2005年12月。
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[MD90] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[MOBIP] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[POS81A] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
[POS81B] Postel、J。、「インターネット制御メッセージプロトコル」、RFC 792、1981年9月。
[Sch05] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[Sch05] Schiller、J。、「インターネットキーエクスチェンジバージョン2（IKEV2）で使用する暗号化アルゴリズム」、RFC 4307、2005年12月。
[WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[Wakiho97] Wahl、M.、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol（V3）：UTF-8文字列名の表現」、RFC 2253、1997年12月。
Informative References
参考引用
[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic Enforcement of Un-ordered Security Policies", BBN Technical Memo 1346, March 2004.
[COSA04] Condell、M。、およびL. Sanchez、「順序付けられていないセキュリティポリシーの決定論的施行について」、BBN Technical Memo 1346、2004年3月。
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[Falihametr00] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing capsulation（GRE）」、RFC 2784、2000年3月。
[Gro02] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.
[Gro02] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。2002年。
[HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[HA94]ハラー、N。およびR.アトキンソン、「インターネット認証について」、RFC 1704、1994年10月。
[NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[Niblbabl98] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[Per96] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[Raflbl01] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な輻輳通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3547] Baugher、M.、Weis、B.、Hardjono、T。、およびH. Harney、「The Group Domain of Strettation」、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[Racocade04] Rajahalme、J.、Conta、A.、Carpenter、B。、およびS. Deering、「IPv6フローラベル仕様」、RFC 3697、2004年3月。
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Sch94] Schneier、B。、Applied Cryptography、セクション8.6、John Wiley＆Sons、ニューヨーク、ニューヨーク、1994。
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[SHI00] Shirey、R。、「Internet Security Glossary」、RFC 2828、2000年5月。
[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[SMPT01] Shacham、A.、Monsour、B.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 3173、2001年9月。
[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[Toegwa04] Touch、J.、Eggert、L。、およびY. Wang、「動的ルーティングのためのIPSEC輸送モードの使用」、RFC 3884、2004年9月。
[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。Kent、「高レベルのネットワークにおけるセキュリティメカニズム」、ACMコンピューティング調査、Vol。15、No。2、1983年6月。
Authors' Addresses
著者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Stephen Kent BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
Karen SEO BBN Technologies 10 Moulton Street Cambridge、MA 02138 USA
Phone: +1 (617) 873-3152
EMail: kseo@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。