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).
著作権（C）インターネット協会（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.
この文書は、IPsecのドキュメントへの非常に重要な貢献をしたチャーリー・リン、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）環境およびIPマルチキャストのためのより包括的なサポートのIPsecの使用を追加アーキテクチャの詳細に取り組みます。 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
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]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
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のとそれらの相互関係の構成要素のうちのいくつかの詳細な定義を提供しています。彼らは、以下のトピックに関するRFCを含めます：
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].
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.
すなわち、IP層でのアクセス制御の重要な側面であるのでIPsecは、最小のファイアウォール機能の仕様を含みます。実装は、より洗練されたファイアウォールの仕組みを提供するために、それらのより洗練されたメカニズムを使用してIPsecで義務付けられた機能を実装するために自由です。 （トラフィックフローに追加のファイアウォール制約がIPsec実装によって課されているが、トラフィックセレクタ機能本書で定義さのIKEv2を介して交渉さに基づいてネゴシエートすることができない場合に、相互運用性を被る可能性があります。）IPsecのファイアウォール機能は、暗号強制を利用しますすべての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とSPD内のエントリと照合次層ヘッダ情報（「セレクタ」、セクション4.4.1.1）に基づいて、3つの処理のいずれかのアクションのために選択されます。各パケットはセレクタで識別適用SPDポリシーに基づいて、IPsecセキュリティサービスを使用して保護、廃棄、またはBYPASS 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はセキュリティゲートウェイとホストとの間のセキュリティゲートウェイの対、または（c）の間（b）に示すように、ホストのペア間、（A）1つ以上の「パス」を保護するために使用することができます。コンプライアントホストの実装では、（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.
この図では、「非保護」はまた、「黒」または「暗号文」として記述されるかもしれないインタフェースを指します。ここで、「保護」は「赤」または「平文」として記述されるかもしれないインタフェースを指します。上述した保護されたインターフェイスが内部であってもよく、例えば、IPsecのホスト実装では、保護されたインタフェースは、OSによって提示ソケット層インターフェースにリンクすることができます。この文書では、用語「インバウンド」とは、保護されていないインタフェースまたは境界の保護されていない側の実装によって放出され、保護されたインターフェイスに向け介して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の境界、暗号保護なしに遷移する境界をトラフィックを許可BYPASS施設、保護された側のキーとセキュリティ管理機能として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は、必要に応じて暗号化IPsecの内で使用されるとき、それは、より低いプロトコル層によって効果的な圧縮を防止することを観察することによって部分的に動機付けIP圧縮[SMPT01]のネゴシエーションをサポートします。
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.)
認証ヘッダー（AH）とカプセル化セキュリティペイロード（ESP） - IPsecはトラフィックのセキュリティサービスを提供するために、2つのプロトコルを使用しています。両方のプロトコルは、それぞれのRFC [Ken05b、Ken05a]に詳細に記載されています。 IPsec実装は、ESPをサポートしなければならないとAHをサポートするかもしれません。経験はESPが必要なセキュリティサービスを提供することができない非常に少数のコンテキストがあることが示されたため、（AHのサポートはMAYに格下げされています。機密性なしに、ESPだけ整合性を提供するために使用できることに注意してください、ほとんどのAHに匹敵することコンテキスト。）
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.
カプセル化セキュリティペイロード（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).
セキュリティポリシーデータベース（SPD、セクション4.4.1）によって決定されるように、暗号鍵の配布を通じて施行、AHとESPの両方のオファーアクセス制御O、およびトラフィックの管理が流れます。
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を使用して満たすことができます。トランスポートモードとトンネルモード：各プロトコルは、使用の二つのモードをサポートします。トランスポートモードでは、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。 「バンプ・イン・スタック」（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アドレス指定可能です。単一のホストをサポートしている場合は、BITS実装に非常に類似したかもしれないが、ルーターまたはファイアウォールをサポートするには、セキュリティゲートウェイのように動作しなければなりません。
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.
この文書では、多くの場合、実装はネイティブ、BITS、または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の両方がSAを利用すると、IKEの主要な機能は、SAの確立と維持です。後述のように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対応システム間の典型的な、双方向通信を確保するために、SAの一対（各方向に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実装がマルチキャストをサポートしている場合、それは、SASへのインバウンドのIPsecデータグラムをマッピングするための以下のアルゴリズムを使用してマルチキャストSAをサポートしなければなりません。ユニキャストトラフィックだけをサポートする実装は、この逆多重化アルゴリズムを実装する必要がありません。
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アドレスを使用するかどうかを示す必要があります。マルチキャストSAのために、プロトコルフィールドは、SAの検索に採用されていません。それは「最長」SA識別子と一致するエントリが見つかったことを各インバウンド、IPsecで保護されたパケットの場合、実装は、SADなどの検索を行わなければなりません。二つ以上のSADエントリはSPI値に基づいて、一致する場合は、この文脈では、次いで、宛先アドレス、または宛先および送信元アドレスに基づいて、一致するエントリが（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、宛先アドレス、およびソースアドレスの組み合わせに一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンドパケットを処理します。それ以外の場合は、ステップ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と宛先アドレスの両方に一致するSADを検索します。 SADエントリが一致した場合、その一致するSADエントリでインバウンドパケットを処理します。それ以外の場合は、ステップ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.そうでない場合、受信機は、AHとESPのための単一のSPI空間を維持することを選択した場合にのみ、SPIに一致するSADを検索し、SPIプロトコルの両方に関する。 SADエントリが一致した場合、その一致するSADエントリでインバウンドパケットを処理します。それ以外の場合は、パケットを破棄し、監査可能なイベントをログに記録します。
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によりハッシュテーブルへのインデックスできました。各ハッシュ・テーブル・バケットのリンクリストにおけるSADエントリは、最初にそのリンクリストの中で最も長いSA識別子を持つものSADエントリを持つようにソートされたまますることができます。彼らはリンクリスト内の最後のエントリになるように最短SA識別子を有するものSADエントリはソートすることができます。ハードウェアベースの実装は、一般的に入手可能な三元連想メモリ（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.
送信元および宛先アドレスマッチングをSAのにインバウンドIPsecトラフィックをマップするために必要であるかどうかの指示は、SA管理プロトコルを使用して手動SA設定の副作用として、または交渉を介してのいずれかで設定しなければなりません、例えば、IKE又は解釈のグループドメイン（GDOI） [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）をサポートするために、異なるのSA上で、異なるクラスのトラフィックを置くが、同じセレクタ値を持つべきです。これを可能にするために、IPsec実装は、同じセレクタで、与えられた送信者と受信者との間で複数のSAの確立と維持を許可する必要があります。 QoSをサポートするために、これらの並列SAの間でトラフィックの配布は、ローカル送信者によって決定され、IKEによって交渉されていません。受信機は、偏見なしに異なるのSAからのパケットを処理しなければなりません。これらの要件は、トランスポートとトンネルモードSAの両方に適用されます。トンネルモードSAの場合には、問題のDSCP値は、内部IPヘッダに現れます。トランスポートモードでは、DSCP値が途中で変更される場合がありますが、値はSAの選択のために採用されておらず、SA /パケットの検証の一部としてチェックしてはならないので、これはIPsec処理に関して問題が発生することはありません。パケットの有意な再配列が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.
上述のように、SAの二つのタイプが定義されている：トランスポートモードとトンネルモード。簡単にするために、我々は、ペアの両方のSAが同じモード、輸送またはトンネルであることを要求することを選択したので、IKEは、SAのペアを作成します。
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は、典型的には、エンドツーエンドのセキュリティサービスを提供するために、ホストのペア間で採用されています。セキュリティは、（IPsecのエンドツーエンドの用途に対して）の経路に沿って二つの中間システム間で所望される場合、トランスポート・モードでは、セキュリティゲートウェイ間、またはセキュリティゲートウェイとホストの間で使用されてもよいです。トランスポートモードはセキュリティゲートウェイ間、またはセキュリティゲートウェイとホストの間で使用される場合には、トランスポートモードは、インIPトンネル（例えば、IPインIP [Per96]または総称ルーティングカプセル化（GRE）トンネルをサポートするために使用することができます【FaLiHaMeTr00]またはトランスポートモードSA上の動的ルーティング[ToEgWa04]）。中間システム（例えば、セキュリティゲートウェイ）によってトランスポートモードの使用を明確にするために、ソースアドレス（送信パケット用）パケット又は（インバウンドパケットの）宛先アドレスに適用される場合にのみ許可されているアドレスは、中間システムに属しています自体。彼らはSAがこの方法で使用されるトランスポートモードを横断するパケットのエンドツーエンドのヘッダーに適用することができないようにIPsecの重要な部分であるアクセス制御機能が著しく、この文脈において制限されています。このように、トランスポートモードを使用するこの方法は、特定のコンテキストで使用される前に慎重に評価する必要があります。
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の場合には、保護はまた、IPv4ヘッダに含まれる、それに先行するIPヘッダの選択された部分、拡張ヘッダの選択された部分、及び選択されたオプション（IPv6のホップバイホップ拡張ヘッダ、またはIPv6宛先拡張に拡張されますヘッダ）。 AHによって与えられるカバレッジの詳細については、[Ken05b] AH仕様を参照してください。
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は、本質的にSAがトンネル内のトラフィックのヘッダに適用されるアクセス制御と、IPトンネルに適用されます。二つのホストは、それらの間のトンネルモードSAを確立することができます。別にセキュリティアソシエーションの両端は、セキュリティゲートウェイであるときはいつでも以下の2つの例外から、SAはトンネルモードでなければなりません。ホストとセキュリティゲートウェイとの間のSAのようにこのように、2つのセキュリティゲートウェイ間の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、セキュリティゲートウェイは、経路に沿って、例えば、ホストとセキュリティゲートウェイの間、または2つのセキュリティゲートウェイとの間に二つの中間システム間のIPトラフィックのセキュリティを提供するために、トランスポートモードSAをサポートするかもしれません。
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用のトンネルモードの使用を動機づける。セキュリティゲートウェイの背後にある同じ宛先への複数のパス（例えば、異なるセキュリティゲートウェイを介して）がある場合、例えば、IPsecパケットがSAがネゴシエートされたときのセキュリティゲートウェイに送信されることが重要です。同様に、途中でフラグメント化されるかもしれないパケットは、暗号処理の前に再構成のためのIPsec同じインスタンスに配信すべてのフラグメントを有していなければなりません。断片はIPSecで処理され、送信された場合も、その後、途中で断片化は、前後のIPsecパケットフォーマットのための断片化状態データを保持するための内側および外側のヘッダが存在することが重要です。したがってSAの両端は、セキュリティゲートウェイである場合、トンネルモードを使用するためのいくつかの理由があります。 （トランスポートモードと併せてIPイン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のホスト実装は、トランスポートとトンネルモードの両方をサポートしなければなりません。これは、ホストのネイティブ、BITS、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）は、セキュリティゲートウェイは、トンネルモードをサポートしなければならないし、転送モードをサポートするかもしれません。それはトランスポート・モードをサポートしている場合、それはセキュリティゲートウェイは、ネットワーク管理のために、例えば、ホストとして動作しているか、または経路に沿って二つの中間システム間のセキュリティを提供する場合にのみ使用されるべきです。
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を確立することができます。細粒度SAは、一般的に多くの加入者からのトラフィックを運んでいる粗粒度のものよりもトラフィック解析に対してより脆弱であることに注意してください。
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.
注意：準拠した実装は、NULL暗号化なし整合性アルゴリズムの両方を使用する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モジュール、従って、本明細書の範囲外です。結果として、入れ子にされた/バンドルSAの管理は、潜在的に、より複雑でRFC 2401 [RFC2401]によって暗示モデルの下でより少ない保証されます。ネストされたSAのサポートを提供する実装は、入れ子要件を表現するために、ユーザまたは管理者を有効に管理インターフェイスを提供し、その後、必要な処理を行うために適切なSPDエントリと転送テーブルエントリを作成する必要があります。 （ネストされたSAを設定する方法の例については、付録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トラフィックの受信または送信の処分を決定するポリシーを指定します。第二のデータベースは、それぞれ確立（キーイング）SA（セクション4.4.2）に関連付けられているパラメータが含まれています。第3のデータベース、PADは、（例えばIKEなど）SA管理プロトコルと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コンテキストを実施することができます。各コンテキストは、持っているかもしれなくて、完全に独立したアイデンティティ、ポリシー、鍵管理のSA、および/またはIPsecのSAを使用するかもしれません。これは、ほとんどの部分はローカルの導入問題です。しかし、現地の状況とのインバウンド（SA）の提案を関連付けるための手段が必要とされます。使用中の鍵管理プロトコルでサポートされている場合は、この目的のために、コンテキスト識別子は、IPsec 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が実装されている文脈と一貫した方法で転送されますを前提としています。ネストされたSAのサポートは任意です。必要であれば、それは何度もIPsecの境界多くを通過するパケットを引き起こすために転送テーブルとSPDのエントリ間の調整が必要となります。
"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実装、すなわち、「送信元」アドレス/ポート又は受信パケットの「宛先」アドレス/ポートによって保護されているエンティティを指します。 「Remoteは、」ピア・エンティティまたはピアエンティティを指します。用語「ソース」および「宛先」は、パケットヘッダフィールドのために使用されます。
"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メッセージタイプ/コード、モビリティヘッダのタイプ）。そして、フレーズ「初期フラグメント」は、アクセス制御のために必要なすべてのセレクタ値を含む断片を意味するために使用されます。しかし、フラグメントが次の層のプロトコルおよびポートが含まれているIPv6のため（またはICMPメッセージのタイプ/コード、またはモビリティヘッダタイプ[Mobip]）が種類や現在の拡張ヘッダの数に依存することに留意すべきです。 「最初のフラグメント」は、この文脈では、最初のフラグメントではないかもしれません。
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は、トラフィック送信またはホストまたはセキュリティゲートウェイを通過することにより、受信に適用されるかどうか、およびどのように制御するために、ユーザまたはシステム管理者を可能にするために、提供されなければならない最低限の管理機能を特定します。 SPD、または関連するキャッシュは、IPsecの境界を横断したIPsecで保護されていないトラフィックを含め、すべてのトラフィック（インバウンドとアウトバウンド）の処理中に協議しなければなりません。これは、IKEなどのIPsec管理トラフィックが含まれています。 IPsec実装は、少なくとも一つのSPDを持たなければならない、とIPsec実装が動作するコンテキストのための適切な場合には、複数のSPDをサポートするかもしれません。 RFC 2401 [RFC2401]で指定されたように、インターフェイス単位でのSPDを維持する必要はありません。実装は、複数のSPDをサポートしている場合は、それは、アウトバウンドトラフィック処理のための適切なSPDを選択するために呼び出され、明示的なSPD選択機能を含まなければなりません。この関数への入力は、アウトバウンドパケットと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は、値として範囲エントリがしばしば（非自明な）の存在下に重複するので、順序付け要件が生じる等、ファイアウォール、ルータでは、アクセス制御リスト（ACL）またはパケットフィルタの使用と一致順序付けデータベース、ありますセレクタのため。したがって、ユーザまたは管理者は、所望のアクセス制御ポリシーを表現するためにエントリを注文することができなければなりません。 SPDエントリに一般的な、標準的な順序を強制する方法があるため、セレクタ値のワイルドカードの使用許可のセレクタの異なるタイプの階層関係しないため、存在しません。
Processing Choices: DISCARD, BYPASS, PROTECT
処理の選択：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つの処理の選択が可能です、BYPASSの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実装が唯一のSPDをサポートしている場合は、SPDは、すべての3つの部分から構成されます。複数のSPDがサポートされている場合は、それらのいくつかは、例えば、いくつかのSPDは、インターフェイスごとに着信バイパスされたトラフィックを制御するために、唯一のSPD-Iのエントリが含まれている場合があり、部分的であってもよいです。スプリットは、SPD-Iは、このようなトラフィックのために、SPD-Sに相談することなく、相談することができます。 SPD-IはSPD-Iがエントリに一致させることができないで検索されたパケットは、そのパケットを破棄しなければならない場合はSPDのほんの一部であるため。一致が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エントリはBYPASS、DISCARDとしてパケット処分を指定する、またはPROTECT。エントリは、一の以上のセレクタのリストをキーとしています。 SPDは、これらのエントリの順序付きリストが含まれています。必要なセレクタタイプは、セクション4.4.1.1で定義されています。これらのセレクタは、発信パケットに応答して、またはピアからの提案に応答して作成されたSAの粒度を定義するために使用されます。 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
- SPD-S：IPsecを使用して保護されるトラフィックの場合は、エントリは、AHまたはESP、これらのセレクタに基づいてSAを作成する方法についてのコントロールを経由して、保護されるトラフィックに適用セレクタの値で構成され、この保護機能（例えば、アルゴリズム、モード、など）を行うのに必要なパラメータ。 SPD-Sのエントリもあるかどうかを示すような「パケットから移入」（PFP）フラグ（「SADエントリの値を導出する方法」に以下の段落を参照）、ビットなどの情報が含まれていることに注意してください
SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications).
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.
SPDエントリにIPsecの、ローカルおよびリモートのアドレスとポートによって保護されたトラフィックのためのIKEの規則と一致方向性を、表現するためにスワップされます。一般的に、IPsecはを扱うプロトコルが反転し、リモート/ローカルIPアドレスで対称SAを必要とする性質を持っています。しかし、ICMPのために、多くの場合、そのような双方向の許可要件はありません。それにもかかわらず、均一性及び簡略化のため、ICMP用SPDエントリは、他のプロトコルの場合と同じ方法で指定されています。 ICMP、モビリティヘッダ、および非初期フラグメントのために、これらのパケットには、ポートフィールドが存在しないことにも注意してください。 ICMPメッセージタイプとコードを有しており、モビリティヘッダは、モビリティ・ヘッダ・タイプを有しています。したがって、SPDエントリは、通常のポートフィールドコントロールの代わりに、これらのプロトコルのための適切なアクセス制御を発現するための規定を持っています。バイパスまたは破棄されたトラフィックのために、別々のインバウンドとアウトバウンドのエントリが必要な場合は、単方向の流れを可能にするために、例えば、サポートされています。
OPAQUE and ANY
OPAQUEと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.
ANYとOPAQUE：SPDエントリ内の各セレクタのために、一致を定義するリテラル値に加えて、二つの特別な値があります。 ANYは、パケットの対応するフィールドに任意の値と一致するワイルドカードであるか、またはそれがそのフィールドが存在しないか、隠されているパケットにマッチします。 OPAQUEは、対応するセレクタフィールド値を暗号化している可能性があり、それは断片中に存在しないかもしれないので、それは与えられた次の層のプロトコルやIPsecの適用前には存在しない検査のために利用可能でないことを示します。任意の値は、OPAQUE値を包含する。したがって、OPAQUE必要性は、フィールドの任意の許容値の場合を区別する必要がある場合にのみ使用、対ことフィールドの（による暗号化に例えば、）非存在または使用不能。
How to Derive the Values for an SAD Entry
SADエントリの値を導出する方法
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エントリ内の各セレクタのために、エントリが新しいSAデータベースの対応する値を導出する方法を指定する（SAD、セクション4.4.2を参照）SPDとパケットのものからエントリー。目標はSADエントリとSPDキャッシュエントリが、パケットから、または一致するSPDエントリから特定のセレクタ値に基づいて作成されるようにすることです。アウトバウンドトラフィックの場合、SPD-SキャッシュエントリとSPD-Oキャッシュエントリがあります。 IPsecので保護されていないインバウンドトラフィックのために、SPD-Iキャッシュエントリが存在しており、インバウンドIPsecで保護されたトラフィックのためのキャッシュを表し、SADは（4.4.2項を参照）があります。リモートIPアドレス;次にレイヤプロトコル、IPsec処理フラグは、1つまたは複数のSPDエントリ内のセレクタの（ローカルIPアドレスをアサートすることができるエントリ、「パケットから移入」（PFP）のために指定されている場合と、に応じて次の層のプロトコル、ローカルポートおよびリモートポート、またはICMPタイプ/コード、またはモビリティヘッダのタイプ）。所与セレクターXアサートした場合、フラグは、SAが作成されることを示すパケット内の値からXのためにその値をとるべきです。そうでなければ、SAはSPDエントリに値（S）から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フラグの使用を示します。 192.0.2.10に192.0.2.1：リモートアドレスの許容値は、IPv4アドレスの範囲であるSPDエントリを考えてみましょう。アウトバウンドパケットは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境界を通過するすべてのパケットに適用されるセキュリティ処理を指定できるようにしなければなりません。用（ソケットインタフェースのネイティブホストIPsec実装を作る使用において、SPDは、セクション4.4.1.1の終了時に、セクション5で述べたように、パケット単位に相談する必要はないかもしれない）管理インターフェース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は、非相関性を利用するために準拠した実装を必要としません。例えば、ネイティブホスト実装は典型的には、インターフェースソケットするSAを結合暗黙ためキャッシングを利用し、したがって、これらの実施形態で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に入れることができるように、SPDエントリがデコリレートされ、すべての結果のエントリは、一緒にリンクされなければならないことに注意してください。たとえば、1は非相関時に、エントリA1、A2、およびA3が得られること（注文したSPDから）エントリAで始まると仮定します。パケットが来るとそれは、A2と言って、一致するとSAの作成をトリガに沿って、SA管理プロトコル（例えば、IKEv2のは）A.を交渉し、すべての3エントリを非相関、A1、A2、およびA3は、適切なSPDに配置されています-SキャッシュとSAにリンクされています。その意図は、非相関SPDの使用は、無相関ではないSPDの使用から生じるであろうよりも多くのSAを作成するべきではないということです。
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の使用をしない保持し、それがレスポンダの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エントリの完全なセットのサブセットを送信することです。このアプローチはまだ元の相関エントリよりも良好な情報を提供する上で引用断片化の問題を回避することができます。このアプローチの主な欠点は、それがリンクされ、非相関エントリはピアに送信されているのサブセットのみ以来、後で作成するために、追加のSA引き起こすかもしれないことです。実装者は、上記の引用のアプローチのいずれかを採用するのは自由です。
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.
レスポンダは、そのSPD内の適切なエントリを選択するために、SA管理プロトコルを介して受信したトラフィックセレクタの提案を使用します。マッチングの目的は、SPDエントリを選択し、得られたSAを通過するトラフィックは、両端に受け入れられるように最も密接に、イニシエータの意図と一致するSAを作成することです。応答者が非相関SPDを採用した場合、これは一般的に、両方のピアの意図と一致する可能性が高いSAの創出につながるよう、マッチングのための非相関SPDエントリを使用すべきです。レスポンダは、相関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が利用可能な場合、すべてのケースでは、非相関エントリはSPD-Sキャッシュを移植するために使用されています。 SPDが非相関化されていない場合は、キャッシュが許可されていないとSPDの注文した検索がSAに到着インバウンドトラフィックが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に行われた場合、チェックが現存のSAに与える影響でなされるべきです。実装は、現存のSA上のSPDの変化の影響を確認する必要がありますと、などをそのまま継続することができ、例えば、影響を受けたSAを削除し、影響を受けるSAを取るべきアクションを設定するためのメカニズムを持つユーザー/管理者に提供すべきである（SHOULD）
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を介して行われ、セキュリティサービスの一様なセットを与えてもよいです。あるいは、ホストのペア間のトラフィックは、複数のSAに広がる可能性があり、別のSAによって提供される異なるセキュリティサービスを、（例えば、ポート、次の層のプロトコルおよび関連分野によって定義されるように）使用されているアプリケーションに応じ。同様に、セキュリティゲートウェイのペア間のすべてのトラフィックは、単一のSA上に担持することができ、または1つのSAは、各通信ホスト対に対して割り当てることができます。以下のセレクタパラメータは、SAの粒度の制御を容易にするために、すべてのIPsec実装によってサポートされなければなりません。ローカルとリモートの両方のアドレスがIPv4またはIPv6のではなく、アドレスの種類の組み合わせのいずれかである必要がありことに注意してください。また、ローカル/リモートポートセレクタ（およびICMPメッセージタイプとコード、モビリティヘッダのタイプ）によるパケットの断片化にこれらのフィールドがアクセス不能である状況に対応するためにOPAQUEとしてラベル付けされてもよいことに留意されたいです。
- 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アドレス（複数可）（IPv4またはIPv6）：これは、IPアドレス（ユニキャスト、ブロードキャストのみ（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アドレス（複数可）（IPv4またはIPv6）：これは、IPアドレス（ユニキャスト、ブロードキャストのみ（IPv4）の）の範囲のリストです。この構造は、（些細な範囲を介して）単一のIPアドレスの発現、またはアドレスのリスト（各自明な範囲）、またはアドレスの範囲（低い及び高い値を含む）、ならびに最も一般的な形式のを可能にします範囲のリスト。アドレス範囲は、セキュリティゲートウェイの背後、例えば、同じSAを共有する複数のソースシステムをサポートするために使用されます。ローカルアドレス（ES）この実装（またはポリシーエントリ）によって保護されていることをいいます。
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はマルチキャストアドレスエントリのためのサポートが含まれていません。 [RFC3740]で定義されるようマルチキャストSAをサポートするために、実装は、グループSPD（GSPD）を利用するべきです。 GSPDエントリー、すなわち、一つのマルチキャスト文脈におけるユニキャストSAのローカルとリモートのアドレス値に関連付けられた対称の関係を使用することができない、異なる構造を必要とします。具体的には、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の「次ヘッダ」フィールドから得られます。これは、ANY、またはIPv6のみ、OPAQUE個々のプロトコル番号です。次の層のプロトコルが存在する任意のIP拡張ヘッダの後に来るものは何でもあります。次の層のプロトコルを見つける簡単にするために、IPv6拡張ヘッダをスキップするように設定するためのメカニズムがあるはずです。 0（ホップバイホップオプション）、43（ルーティングヘッダ）、44（断片化ヘッダ）、および60（宛先オプション）：スキップするプロトコルのデフォルト設定は、以下のプロトコルを含むべきです。注意：デフォルトのリストは51（AH）または50（ESP）は含まれません。ビューのセレクタのルックアップの観点から、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で保護されている場合（暗号化）または断片化パケットを受信した場合に利用可能ではないかもしれないことに留意されたいです。従って、OPAQUEの値もサポートしなければなりません。注：非初期フラグメントでは、ポート値は使用できません。ポートセレクタがANYまたはOPAQUE以外の値を指定した場合、それは非初期フラグメントであるパケットを一致させることはできません。 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メッセージ、または任意のタイプを定義する1つの8ビットの値です。 ICMPコードは、ICMPメッセージの特定のサブタイプを定義する1つの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.
IPアドレスが「道路戦士」を、例えば、リモートIPアドレスセレクタに適切ではない場合1.名前SPDエントリは、アクセス制御をサポートするレスポンダ（ないイニシエータ）によって使用されます。このフィールドを一致させるために使用される名前は、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
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つのタイプのいずれかです：
a. a fully qualified user name string (email), e.g.,
mozart@foo.example.com
(this corresponds to ID_RFC822_ADDR in IKEv2)
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 =スティーブンT.ケント、O = BBN Technologies社、SP = MAは、Cは、米国（これは復号後の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エントリーで必要なポリシーがIKEを通じて交渉することができることを確実にするためにIKEペイロードに直接マッピングするために意図された方法でSPDを説明しています。残念ながら、このドキュメント[Kau05]と同時に発表されIKEv2のバージョンのセマンティクスは、SPDのために定義されたものと正確に整列しません。具体的には、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アドレスとポートに適用されることに留意されたいです。 OPAQUEまたはANY予約、シンボリック・セレクタ値を指定したセレクタ・タイプのために使用されている場合も、唯一その値は、セレクタのリストに表示されることがあり、それはそのセレクタのリストに一度だけ現れなければなりません。 ANYとOPAQUEがローカル構文規則であることに注意してください - 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 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エントリ内の値（S）から作成をトリガーしたパケットの対応するフィールドからセレクタをインスタンス化するかどうか対応するトラフィックセレクタの指定（セクション4.4.1参照、）「どのようにSADエントリの値を導出するために」。単一フラグは、例えば、送信元ポート、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)
特定のIPsecアクションを適用するための「条件」に対応するN個のセレクタセットに対する一つのO。ローカルアドレス - - リモートアドレス - 次の層のプロトコル - ローカルポート、または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）の値を交渉する方法と一致しています。 1は、異なるプロトコルと異なるポートフィールドを関連付ける必要があるかもしれないので、それはまた、理にかなっています。その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処理情報 - アクションが必要とされる - PROTECT、BYPASS、またはDISCARD。すべてのセレクタ・セットではなく、各セットに対して個別のアクションで行くただ一つのアクションがあります。必要な処理がPROTECTある場合、エントリは以下の情報が含まれています。 - の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
It is a local matter as to what information is kept with regard to handling extant SAs when the SPD is changed.
SPDが変更されたときにどのような情報には、現存のSAの取り扱いに関して保たれているように、それはローカルの問題です。
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.,
Local's next layer protocol = AH "port" selector = OPAQUE
現地の次の層プロトコル= AH「ポート」セレクタ= OPAQUE
Remote's next layer protocol = AH "port" selector = OPAQUE
リモートの次の層プロトコル= AH「ポート」セレクタ= 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:
次の層のプロトコルは、その後、ローカルおよびリモートの「ポート」のセレクタは、システムが指定した「ポート」でトラフィックを送信および/または受信する意思があるかどうかを示すために使用されている、唯一の1つのセレクタ、例えば、モビリティヘッダのタイプを持っている場合でも、B.値。指定されたタイプのモビリティヘッダの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
リモートの次の層プロトコル=モビリティヘッダ「ポート」セレクタ= 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
現地の次の層プロトコル=モビリティヘッダ「ポート」セレクタ= 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:
C.システムは、特定の「ポート」の値でトラフィックを送信していく所存ですが、ポート値のようなものでトラフィックを受信しない、該当するSPDエントリに次のようにシステムのトラフィックセレクタが設定されている場合：
Local's next layer protocol = ICMP "port" selector = <specific ICMP type & code>
ローカルの次の層プロトコル= ICMP「ポート」セレクタ= <特定のICMPタイプ・コード>
Remote's next layer protocol = ICMP "port" selector = OPAQUE
リモートの次の層プロトコル= ICMP「ポート」セレクタ= OPAQUE
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「ポート」セレクタ= OPAQUE
Remote's next layer protocol = ICMP "port" selector = <specific ICMP type & code>
リモコンの次の層プロトコル= ICMP「ポート」セレクタ= <特定のICMPタイプ・コード>
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のtracerouteを実行してみましょうことを望んでいない場合、例えば、セキュリティゲートウェイのトラフィックセレクタは、関連するSPDエントリに次のように設定されています：
Local's next layer protocol = 1 (ICMPv4) "port" selector = 30 (traceroute)
ローカルの次の層プロトコル= 1（ICMPv4の） "ポート" セレクタ= 30（トレースルート）
Remote's next layer protocol = 1 (ICMPv4) "port" selector = OPAQUE
リモコンの次の層プロトコル= 1（ICMPv4の）「ポート」セレクタ= 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実装では、各エントリは1つのSAに関連付けられたパラメータを定義する名目セキュリティアソシエーションデータベース（SAD）、があります。各SAはSADにエントリを持っています。アウトバウンド処理のために、各SADエントリはSPDキャッシュのSPD-S部分のエントリによって指し示されています。インバウンド処理のために、ユニキャストSAのために、SPIはSAを検索するために、単独で、またはIPsecプロトコルタイプと組み合わせて使用されます。 IPsec実装がマルチキャストをサポートしている場合は、SPIプラス宛先アドレス、またはSPIプラス宛先と送信元アドレスはSAを検索するために使用されています。 （SASへのインバウンドのIPsecデータグラムをマッピングするために使用されなければならないアルゴリズムの詳細については、セクション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で定義されたセレクタのそれぞれについて、SADにおけるインバウンドSAのエントリが最初にSAが作成された時点でネゴシエートされた値または値が取り込まれなければなりません。 （現存のSA上のSPD変化の影響に関するガイダンスについては、「システムの稼働中にSPDへの変更の処理」のセクション4.4.1で段落を参照してください。）受信機の場合、これらの値はヘッダフィールドのことを確認するために使用されています（IPsec処理後の）着信パケットがSAのために交渉セレクタ値と一致します。このように、SAの上で到着インバウンドトラフィックのセレクタをチェックするためのキャッシュとしてSAD行為。受信機の場合、これは、SAに到着したパケットがSAのための政策と一致していることを確認することの一部です。 （ICMPメッセージのための規則については、セクション6を参照。）これらのフィールドは、特定値の形態を有することができ、範囲、ANY、または不透明セクション4.4.1.1に記載されているように、「セレクタ」。 SADは、SPDで対応するエントリを持っていないSAのエントリを持つことが可能な状況のカップルがあることにも注意してください。 SPDが変更されたときに、このドキュメントでは、SADを選択的にクリアすることを強制しないので、SADのエントリは、それらを作成したSPDエントリが変更または削除されたときに残ることができます。手動でキー入力SAが作成される場合も、任意のSPDエントリに対応していない、このSAのためのSADエントリが存在し得ます。
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は、マルチキャストSAをサポートすることができます。アウトバウンドマルチキャストSAは、ユニキャストSAと同じ構造を有しています。送信元アドレスは、送信者のものであり、宛先アドレスはマルチキャストグループアドレスです。インバウンド、マルチキャストSAは、それぞれのソースアドレスが当該マルチキャストSAに送信することを許可ピアに構成されなければなりません。マルチキャストSAのSPI値は、ユニキャストSAの場合と同様に、マルチキャストグループコントローラによってではなく、受信機によって提供されます。 SADエントリは、（ユニキャストSAの）SPDエントリの一部であった複数の個別のIP送信元アドレス、受信に必要な設備を収容するために必要とされ得るので、マルチキャストのSAは、IPsec実装に既に存在の特徴です。 SPDはマルチキャストエントリを収容するための何の規定がないためしかし、この文書は、マルチキャスト、インバウンドSAのためのSADエントリを作成するための自動化された方法を指定しません。のみ、手動で設定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からの経験に基づいて）いくつかの実装は、この点で問題があることが知られています。具体的には、単に保存（リモートトンネルヘッダのIPアドレスを、リモートSPI）SPDキャッシュ内のペアは、ペアが常に一意に単一のSADエントリを識別しないので、不十分です。例えば、同じNATの背後にある二つのホストは、同じSPI値を選択することができます。ホストが（DHCP経由で、例えば）IPアドレスが割り当てられている場合、状況はまた、以前に他のいくつかのホストで使用される発生する可能性があり、古いホストに関連付けられているSAはまだ死んでピア検出機構を介して削除されていません。これは、鍵管理がそうでなければ、有効なSAの作成を拒否し、ペアが一意である保証した場合、間違ったSAを介して送信されるか、されるパケットにつながる可能性があります。したがって、実装者は、このような問題を生むしない方法で、SPDキャッシュとSAD間のリンクを実装する必要があります。
The following data items MUST be in the SAD:
次のデータ項目は、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を識別するために、SAの受信端で選択された32ビットの値。アウトバウンドSAのためのSADエントリに、SPIはパケットのAHまたはESPヘッダを構築するために使用されます。インバウンドSAのためのSADエントリでは、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アンチリプレイウィンドウ：64ビットカウンタ及びインバウンドAHまたはESPパケットがリプレイであるかどうかを決定するために使用されるビットマップ（または同等品）。
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.
AHがサポートされている場合は、O 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整合性アルゴリズム、鍵などは、これらのフィールドは適用されません。組み合わせたモードアルゴリズムが使用されている場合、これらのフィールドは適用されません。
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:
このSAのO寿命：SAを新しいSA（および新しいSPI）と交換または終了し、プラスこれらのアクションのの兆候が発生しなければならない後の時間間隔。これは、時間やバイト数、または優先して期限切れに最初の寿命の両方を同時に使用するように表すことができます。準拠した実装は、寿命の両方のタイプをサポートしなければならない、との両方の同時使用をサポートしなければなりません。時間が使用される場合、IKEは、SAの確立のためにX.509証明書を使用する場合、および、SA寿命はSAのIKE交換に使用される証明書の有効間隔、及び証明書失効リストのNextIssueDate（CRL）のによって制約されなければなりません。イニシエータとレスポンダの両方が、このやり方でSAのライフタイムを拘束するための責任があります。注：SAはローカルの問題である有効期限が切れたときに、キーのリフレッシュを処理する方法の詳細。しかし、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の各端部の実装は、物事をやっていないので、例えば、実装は、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.
このような電流SAが終了すると破棄された場合、交換SA、およびハード寿命を設定するようにアクションを開始するために、実装に警告ソフト寿命 - （b）の寿命の二種類があるべきです。
(c) If the entire packet does not get delivered during the SA's lifetime, the packet SHOULD be discarded.
パケット全体がSAの存続期間中に配信されない場合は（C）、パケットが破棄されるべきです。
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であり、トンネルモードSAに適用。
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つ以上の値が指定されている場合、これらは、アウトバウンドパケットのトラフィックセレクタに一致するいくつかのうちの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（T / F）、またはDSCP値のバイパスを制限するために、必要に応じて保護されていないDSCP値（アレイ）にマッピング - トンネルモードSAに適用。この機能は、隠れチャネルシグナリングの懸念に対処するために、例えば、外部ヘッダの値に内部ヘッダからDSCP値をマッピングします。
o Path MTU: any observed path MTU and aging variables.
Oパス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.
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"
範囲0の範囲のIP addrは "D" リストのレムaddrのリストANY 0 IP addrの "D" レンジの任意のリスト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
PROTの* 0 PROTのプロトコルリスト。 PROTの* ANY ** 0 PROTの "P" リスト。 "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" ***
PROTの* 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. ***
PROTの* 1役に立つないのリスト。 ANY ** 1役に立つないパケットを破棄する。 **** 1役に立つないOPAQUEパケットを破棄する。 ***
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" ***
範囲のリスト1のsrcポート "S" "S" ANY 1 SRCポート "S" "S" OPAQUE 1つのSRCポート "S" ***
list of ranges 1 not avail. discard packet ANY 1 not avail. discard packet OPAQUE 1 not avail. ***
1役に立つない範囲のリスト。 ANY 1役に立つないパケットを破棄する。役に立つない1 OPAQUEパケットを破棄する。 ***
rem port list of ranges 0 dst port "d" list of ranges ANY 0 dst port "d" ANY OPAQUE 0 dst port "d" OPAQUE
範囲の範囲0 DSTポート "D" リストのレムポートリストANY 0 DSTポート "D" ANY OPAQUE 0 DSTポート "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" ***
範囲のリスト1つのDSTポート "D" "D" ANY 1つのDSTポート "D"、 "D" OPAQUE 1つのDSTポート "D" ***
list of ranges 1 not avail. discard packet ANY 1 not avail. discard packet OPAQUE 1 not avail. ***
1役に立つない範囲のリスト。 ANY 1役に立つないパケットを破棄する。役に立つない1 OPAQUEパケットを破棄する。 ***
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" ***
範囲は1 MHタイプ "T" "T" ANY 1つのMHタイプ "T" "T" OPAQUE 1 MHタイプ "T" のリスト***
list of ranges 1 not avail. discard packet ANY 1 not avail. discard packet OPAQUE 1 not avail. ***
1役に立つない範囲のリスト。 ANY 1役に立つないパケットを破棄する。役に立つない1 OPAQUEパケットを破棄する。 ***
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"
単一タイプ＆1タイプ「T」と「T」及び「C」コードのコード「C」の範囲単一タイプ＆1タイプ「T」と「T」と「C」のコードのコード「C」のいずれかのタイプ＆ 1型 "T" と "T" と "C" ANY符号コード "C" OPAQUE 1つのタイプ "T" ＆***コード "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. ***
シングルタイプ＆1役に立つません。単一タイプ＆1役に立つないコードのパケットの範囲を破棄する。すべてのコードいずれかのタイプ＆1役に立つない、パケット破棄。役に立つない1 OPAQUEコードをパケット破棄。 ***
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.
*「プロトコルの一覧は、」情報ではなく、SPDまたはSADまたはIKEv2のは、この情報を表すために持っていることの方法です。 ** 0（ゼロ）は、プロトコルのいずれかを示すためにIKEによって使用されます。 *** OPAQUE値PFP = 1の使用はエラーであり、IPsec実装により禁止されるべきです。 ****プロトコルフィールドは、IPv4に不透明であることができません。この表のエントリは、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:
ピア許可データベース（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
The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder.
PADは、ピアがイニシエータまたはレスポンダのいずれかとして作用すると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.
これらの機能を実行するために、PADは、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アドレスは、SPDのルックアップに使用されるかどうか、子SAが作成されたとき。
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.
PAD情報が同じアドレス/ホストを保護するために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.
PADは、順序が管理者（またはシングルユーザエンドシステムの場合のユーザ）によって定義される順序付けられたデータベースです。通常、同じ管理者は、2つのデータベースは協調しなければならないので、パッドとSPDの両方を担当します。 「星の名前」のエントリの使用は、特定のエントリに一致する可能性がIKE IDのセットで重複することができますので、PADのための発注要件は、つまり、SPDと同様の理由のために生じます。
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:
IDの6種類は、SPDエントリを識別するために使用されるシンボリック名の種類とIPアドレスと一致し、パッド内のエントリのためにサポートされています。各エントリのID、すなわち、それはエントリを選択するために使用される値であり、PADのための指標として機能します。これらの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)
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.
最初の三つの名前タイプは、サブツリーのマッチングだけでなく、完全一致を収容することができます。 DNS名は、完全修飾され、従って、正確に一つの名前と一致し、例えば、foo.example.comできます。あるいは、名前が部分的に指定されることにより、ピアのグループを包含することができる、例えば、文字列「.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).
同様に、識別名は、正確に一つのエントリに一致するように、完全な識別名を指定することができ、例えば、CN =スティーブン、O = BBN Technologies社、SP = MAは、Cは、米国=。また、エントリは、例えば、サブツリーを指定することで、フォームのエントリピアのグループを包含することができる「C = USを、SP = MAは、」相対上の2つのように、これらの2つの属性を含むすべてのDNを一致させるために使用される可能性があります識別名（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は、「@ example.com」のような1つのエンティティと一致しますが、サブツリー名として完全なアドレスは、右側にそれらの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でのオクテット文字列として定義されています。 （この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フィールドの照合に基づいて、PADの順序付き検索に基づいて設置されると、アサートされたIDを認証するために、すなわち、アサートされたアイデンティティを検証する必要があります。各PADエントリに対して、実行される認証のタイプの表示があります。この文書では、2つの必須の認証データタイプのサポートを必要とします。
- X.509 certificate
- pre-shared secret
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証明書に基づく認証のために、PADエントリは、ピアのエンドエンティティ（EE）証明書が直接または証明書パスを介して、検証可能である必要があり、それを介してトラストアンカーを含んでいます。トラストアンカーの定義については、RFC 3280を参照してください。証明書ベースの認証で使用されるエントリは、証明書の失効ステータスを容易にするために、追加のデータ、例えば、適切なOCSPレスポンダまたはCRLリポジトリ、および関連する認証データのリストを含むことができます。事前共有秘密に基づく認証の場合、PADが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が構文的にそのピアの識別情報を認証するために使用されるエンドエンティティ証明書に特定の分野に関連する必要はありません。しかし、多くの場合、単一のエントリが異なるSPDエントリを有していてもよい人のピアのセットを表し、例えば、場合、そのような要件を課すことが適切であろう。したがって、実装はアサートIKE IDおよび証明書のサブジェクト名またはサブジェクト代替名の間の一致を必要とするには、管理者のための手段を提供しなければなりません。前者は、IKEのIDに該当する識別名として表現です。後者は、DNS名、RFC 822の電子メールアドレス、およびIPアドレスに適しています。 KEY IDが事前共有秘密を介して認証されたピアを識別するために意図されているため、証明書のフィールドにこのIDタイプと一致する必要はありません。
See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE performs peer authentication using certificates or pre-shared secrets.
IKE証明書または事前共有秘密を使用してピア認証を実行する方法の詳細についてのIKEv1 [HarCar98]とのIKEv2 [Kau05]を参照。
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ピアが認証されると、子SAが作成されることがあります。各PADエントリは、SPDとの照合のために、IKEピアによってアサートすることができるIDの集合を制約するデータを含みます。各PADエントリは、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が使用されることを示す場合、PADエントリ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交換中に、イニシエータとレスポンダは、それぞれIKE IDペイロードを経由して自分のアイデンティティを主張し、アサート身元を確認するためにAUTHペイロードを送信します。一つ以上のCERTペイロードは、それぞれアサートされたアイデンティティの検証を容易にするために送信されてもよいです。
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ペイロードを受信すると、上記のマッチング規則を使用して、PADにエントリを検索するためにアサートされたIDを使用します。 PADのエントリが特定されたピアのために使用される認証方式を指定します。これは、右の方法は、各ピアのために使用され、その異なる方法が異なるピアのために使用することができることを確実にします。エントリもアサート身元を確認するために使用される認証データを指定します。任意の子SAが作成される前に、このデータは、ピアを認証するために指定された方法と組み合わせて採用されています。
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.
子SAが初期のIKE交換の終了時またはその後のCREATE_CHILD_SA交換のいずれかで、トラフィックセレクタペイロードの交換に基づいて作成されます。 （現在認証された）IKEピア用のパッドエントリは子SAの作成を制約するために使用されます。具体的には、パッドエントリはSPDがピアからのトラフィックセレクタの提案を使用して検索される方法を指定します。二つの選択肢があります：IKE IDは、ピアによってアサートのいずれかのシンボリック名を介したSPDエントリを見つけるために使用される、またはピアIPアドレスは、セレクタペイロードは、SPDのリモートIPアドレスフィールドの一部に基づいてSPDの検索に使用されたトラフィックにアサートエントリ。他の、正当なピアに関連付けられたIDをスプーフィングから認証されたピアを防ぐために、子供のSAの作成時にこれらの制約を課すことが必要です。
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.
PADはSPDエントリを検索する前にチェックされているので、このセーフガードはスプーフィング攻撃に対してイニシエータを保護することに注意してください。たとえば、IKE Aは、IPアドレスX宛のアウトバウンドパケット、セキュリティゲートウェイが提供するホストを受けることを前提としています。 RFC 2401 [RFC2401]及びAしかしながらIKEピアなるXのアドレスにIKE交換を可能にするために、PADに登録する必要がありXのための推定代表としてが接触任意のピアを決定する方法を指定しない本書認証されます。認証されたピアは、そのトラフィックセレクタ交換でXを表すことをアサートする。また、パッドは当該ピアがこのようにXを表現することを許可されているかどうかを決定するために相談され、PADは、アドレス範囲（または名前のサブの結合を提供しますピアにスペース）、このような攻撃に対抗します。
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のアンチリプレイ機能の使用を容易にするために、そしてUSER-およびセッション別鍵のために、例えば、SAのオンデマンド作成に対応するために必要です。 （「再入力」の概念は、SAが実際に新しいSPI、一般的に自動化された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
自動SA /鍵管理プロトコルが使用される場合、このプロトコルからの出力は、単一のSAのための複数の鍵を生成するために使用されます。異なるキーは、2つのそれぞれのために使用されるので、これはまた、発生します
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はIKEによって作成されました。完全性と機密性の両方が使用される場合には、4つのキーの最小値が必要とされています。さらに、いくつかの暗号アルゴリズムは、例えば、3DESを複数のキーを必要とするかもしれません。
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は、*以下のIPsec、例えば、SH1及びSG2を実行しているシステムを示しています。）
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つまたは複数のセキュリティゲートウェイを認証し、宛先ホストを表すために、これらのゲートウェイの承認を検証するための情報を設定する機能が含まれています。 （承認機能は、PADに暗示されています。）この文書では、セキュリティゲートウェイの発見/検証を自動化する方法の問題に対処しません。
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値を選択して有することによって、互いに競合する複数のソースから自動的に構成（例えば、鍵管理プロトコルを介して）のSAまたはSAの競合する手動で設定SAのない可能性がありません。マルチキャストトラフィックのために、単一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）」、SPD（または関連するキャッシュ）はIPsecの管理トラフィックを含め、IPsec保護境界を超えるすべてのトラフィックの処理中に相談しなければなりません。ポリシーが（インバウンドまたはアウトバウンドトラフィックのための）パケットに一致するSPDに見つからない場合、パケットは捨てなければなりません。処理を簡単にするため、および（SG / BITS / BITWため）非常に高速SA検索を可能にするために、この文書は、すべてのアウトバウンドトラフィック（SPD-OプラスSPD-S）のためのSPDキャッシュ、およびインバウンドのキャッシュの概念を導入します非IPsecで保護されたトラフィック（SPD-I）。 （SASに到着インバウンドIPsecで保護されたトラフィックのセレクタをチェックするためのキャッシュとしてSAD行為、先に述べたように。）SPDごとにキャッシュは公称あります。本明細書の目的のために、キャッシュされた各エントリは正確に一つのSAにマッピングすることが想定されます。一つは、異なる優先順位（異なるDSCP値によって示さ例えば、ように）同じセレクタのトラフィックを伝送するために複数のSAを使用する場合ただし、例外が発生します。 SADは、SPDで対応するエントリを持っていないSAのエントリを持つことが可能な状況のカップルがあること、また、注意してください。 SPDが変更されたときに、このドキュメントでは、SADを選択的にクリアすることを強制しないので、SADのエントリは、それらを作成したSPDエントリが変更または削除されたときに残ることができます。手動でキー入力SAが作成される場合も、任意のSPDエントリに対応していない、このSAのためのSADエントリが存在し得ます。
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の、例えば複数のSA、する可能性があります。）特に断りのない限り、「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.
注意：ユーザーおよび管理者がアクセス制御リストやファイアウォールのフィルタルールのこれらの種類の管理に慣れている方法ですので、1が相関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によって選択されたSADエントリは、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.
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-IDを得るために、SPD選択機能を呼び出すには、適切なSPDを選択する必要がありました。 （実装が唯一のSPDを使用している場合、この手順は、何もしません。）
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.マッチこのキャッシュは、SPD-OとSPD-Sからのエントリが含まれていることをステップ1注からSPD-IDで指定されたSPDのキャッシュに対するパケットヘッダ。
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.
図3（a）。一致がある場合、すなわち、BYPASS、DISCARD、マッチング・キャッシュ・エントリで指定された、またはAHまたはESP使用PROTECTとして、そのパケットを処理します。 IPsec処理が適用される場合、関連するSADエントリ（指定等モード、暗号アルゴリズム、鍵、SPI、PMTU）のSPDキャッシュエントリからリンクがあります。 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エントリはBYPASSまたはDISCARDを求めて、1つ以上の新しいアウトバウンドSPDキャッシュエントリを作成し、BYPASS場合場合は、1つ以上の新しいインバウンドSPDキャッシュエントリを作成します。 （非相関SPDエントリは非相関処理の副作用として作成された他のそのようなエントリにリンクすることができるので、複数のキャッシュ・エントリが作成されてもよい。）SPDエントリは、SAのPROTECT、すなわち、作成を要求する場合（例えば、IKEv2の）鍵管理メカニズムは、SAを作成するために呼び出されます。 SAの作成に成功した場合は、新しいアウトバウンド（SPD-S）キャッシュエントリが作成され、アウトバウンドとインバウンドSADエントリと一緒に、それ以外のパケットは破棄されます。 （SPD検索をトリガするパケットは、実装によって破棄されてもよく、または1つが作成された場合には、新たに作成されたキャッシュ・エントリに対して処理されてもよい。）SAがペアで作成されているので、対応するインバウンドSAのためのSADエントリもあります作成し、それはSAを介して配信インバウンドトラフィックを検査する際に使用するため、インバウンドSAを作成するために使用される（任意のPFPフラグが「真」であれば、そしてパケット）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.
前記パケットは、パケットが向かう先となるインターフェイスを選択するために、（IPsec実装の外で動作）アウトバウンド転送機能に渡されます。この関数は、ネストされたSAのサポートで、例えば、追加のIPsec処理のために、パケットはIPsecの境界を越えて戻される可能性があります。もしそうなら、それ以外のパケットは破棄され、パケットのインバウンドバイパスを許可する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の転送モードを除いて、SG、BITS、またはBITW実装はIPsecを適用する前にパケットを断片化するかもしれません。 （これは、IPv4のみに適用される。IPv6パケットについて、発信のみがそれらを断片化させることができる。）デバイスは、これを無効にする設定構成を有しているべきです。得られた断片は、通常の方法でSPDに対して評価されます。したがって、ポート番号（またはICMPメッセージタイプとコード、またはモビリティヘッダのタイプ）を含有しない断片は、ポート（またはICMPメッセージタイプとコード、またはMHタイプ）OPAQUEまたはANYのセレクタを有するルールと一致します。 （詳細はセクション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)
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)
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)
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.にICMPメッセージを送信するために、それを引き起こしたIPsec実体に、偽装された送信元アドレス、W.X.Y.Zでパケットを送信することができることに注意してくださいこれは、セキュリティゲートウェイの背後にあるホスト間でサービス拒否（DoS）攻撃の拒否のための機会を作成します。これに対処するために、セキュリティゲートウェイは、管理者が送信したりしないような状況下でのICMPメッセージを送信し、この機能が選択されている場合、このような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]:
このセクションでは、アウトバウンドトラフィック処理に関しては、内側と外側のIPヘッダ、拡張ヘッダ、そしてAHおよびESPトンネルのオプションの取り扱いについて説明しています。これは、内側の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.)
（カプセル化送信元IPアドレスの詳細については、5.1.2.1にテーブルの後に脚注3を参照してください。）
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.
内側のIPヘッダoを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イン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フィールドを処理する方法に関して構成可能です。アウトバウンドトラフィックのために、一つの構成は、IPsecトンネルのためのIPv4およびIPv6ヘッダ処理に関する次のセクションで説明したように動作する、外側のDSフィールドに設定します。別のは、外側DSフィールドはSA毎に設定されるかもしれ固定値にマッピングすることを可能にします。 （値は、実際のデバイスからのすべてのトラフィックの発信のために修正されるかもしれないが、あたり-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毎に構成されるかもしれません。この設定オプションは、ローカルの管理者はこれらのビットをコピーすることによって作成された脆弱性は、コピーの利益を上回るかどうかを決定することができます。これらの動作の各々が前または後（トンネルカプセル化解除を含む）IPsec処理へのDiffServトラフィック調整の可能な必要性のためにも有用であってもよく、場合の詳細については、[RFC2983]を参照。
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.)
（2）内部ヘッダ内のTTLは、従来、パケットを転送する場合、転送およびカプセル開放装置によってカプセル化することによりデクリメントされます。 （ときにTTLの変更IPv4のチェックサムが変化します。）
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.
(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.
(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）、次いでCEの内部ヘッダにECNフィールドを設定します。そうでない場合は、内側のヘッダーの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は、外側ヘッダのオプションを構成しません。しかし、後のIPsecコードが挿入/アウターヘッダのオプションを構築することができます。
<-- 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は、外側ヘッダに拡張ヘッダを構築しません。しかし、後のIPsecコードが挿入/外部ヘッダのための拡張ヘッダを構築することができます。
(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]参照。コピーが唯一のエンドシステム、ではないのSGが許容されます。 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.
インバウンド処理ためのSAにIPsecで保護されたトラフィックをマップするための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データグラムは、（IPv6のコンテキストの次の層のプロトコルとして、またはAHまたはESPの）IP次のプロトコルフィールドに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・ルックアップに向けられています。複数のSPDを使用する場合（これは、IKEトラフィックがSPD内の明示的なBYPASSエントリを持たなければならないことを意味する。）、ステップ1で、パケットに割り当てられたタグを検索するために適切なSPD-I（キャッシュ）を選択するために使用されます。 SPD-I・ルックアップは、アクションがDISCARDまたはBYPASSであるか否かを判断します。
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).
図3（a）。パケットがIPsecのデバイスに宛てられ、AHまたはESPがプロトコルとして指定された場合、パケットはSADに検索されます。ユニキャストトラフィックのために、唯一のSPI（またはSPIプラスプロトコル）を使用します。マルチキャストトラフィックについては、セクション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にパケットを検索し、必要に応じてキャッシュエントリを作成します。 （NO SAがIPsec保護を必要とするパケットの受信に応答して作成されていない。唯一BYPASSまたはDISCARDキャッシュエントリはこの方法で作成することができます。）のトラフィックを廃棄し、一致しない場合。これは監査対象イベントとなります。このイベントの監査ログエントリは、現在の日付/時刻、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で選択されたSADエントリを使用して、指定されAHまたはESP処理を施します。次いで、受信したパケットがそれを受信した介してSAに適していることを確認するSADエントリによって識別される着信セレクタに対してパケットを一致。
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エントリからセレクタ値を含むべきです。システムはまた、受信パケットがあるため、セレクタチェックに合格する障害の廃棄されたことを示す、送信者（IPsecピア）にINVALID_SELECTORSのIKE通知を生成し送信することができなければなりません。
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.
DoS攻撃の影響、又は誤設定されたピアを最小にするために、IPsecのシステムは、管理者が、この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の通過バイパスまたは処理された後、それが処分のためのインバウンド転送機能に渡されます。この機能は、パケットが、ネストされたSAのサポートにおいて、例えば、付加的なインバウンドIPsec処理のための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つのカテゴリがあります。このセクションでは、エラーメッセージのみに適用されます。 （IPsec実装自身に対処されていない）非エラー、ICMPメッセージの処分は、明示的に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エラーメッセージ（選択、すべて、またはnone）を引き起こすために、管理者が許可するように提供されるべきです。
6.1.1. ICMP Error Messages Received on the Unprotected Side of the Boundary
6.1.1. 境界の保護されていない側で受信した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デバイスにアドレス指定されると、それは、AHまたはESPを介して保護されていないICMPメッセージ（エラーまたはその他）を処理するため、IPsecの境界の保護されていない側に別個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実装は、未認証のICMPトラフィックを受け入れるか拒否するIPsec実装を設定するには、ローカルの管理者に許可する必要があります。この制御は、ICMPタイプの粒度でなければならず、ICMPタイプとコードの粒度にあってもよいです。また、実装は、そのようなトラフィックに対処するためのメカニズムとパラメータを組み込むべきです。例えば、些細な大きさにPMTUを設定するから、未認証のICMPの受信を防止するために、（先ごとに）トラフィックの最小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実装の外側）転送モジュールに渡されます。実装は、平文側の断片化をもたらすように構成されている場合は、セクション8.2で説明したように、その後、PMTU情報は平文側に渡されて処理されます。
6.1.2. ICMP Error Messages Received on the Protected Side of the Boundary
6.1.2. 境界の保護側で受信したICMPエラーメッセージ
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システム（A ）Aが現在通信している任意のホスト/ネットを指すICMP宛先到達不能メッセージを送信することができるアクティブSAを有し、トラフィックがないのこのようA.通常のIPsec受信処理の他のピアとの通信について高効率のDoS攻撃を行いますこのような攻撃から保護するのに十分な。ただし、いないすべてのコンテキストは、このようなチェックが必要な場合がありますので、ローカルの管理者は、このようなチェックを実行しないように実装を設定できるようにすることも必要です。
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送信側と受信側はSAを経由して送信され、受信された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.
SAは、そのアウトバウンドICMPエラーメッセージを収容存在する場合、メッセージはSAにマッピングされているのみIPとICMPヘッダは他のトラフィックのためのケースであるのと同じように、受信時に検査されます。何SAは、それがICMPエラーメッセージに関連付けられたトラフィックセレクタの一致が存在しない場合、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.
何のSAが存在しない場合、それは問題のアウトバウンドICMPメッセージを運ぶだろう、と何のSPDエントリはこのアウトバウンドICMPエラーメッセージの運送を許可していないならば、その後、IPsec実装は、パケットに関連付けられているリターントラフィックを運ぶSAにメッセージをマップする必要がありますそれは、ICMPエラーメッセージを引き起こしました。これは、無現存SAまたはSPDエントリにマップアウトバウンドICMPエラーメッセージを検出し、SAの作成と検索に関して、特別にそれらを治療するためのIPsec実装が必要です。実装は、送信元および宛先IPアドレスフィールドを反転させる、（ICMPメッセージペイロードからの）エラーを引き起こしたパケットのヘッダを抽出プロトコルフィールドを抽出し、（アクセス可能な場合）ポートフィールドを反転させます。次に、これは適切な、アクティブアウトバウンド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
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では、トランスポートモードSAは断片（IPv4またはIPv6）を運ばないように定義されています。 、4.4.1項でも、二つの特別な値、ANYとOPAQUE、セレクタのために定義されたとANYは、OPAQUE備える点に注意してください。用語「非自明」はセレクタが不透明またはANY以外の値を有することを意味するために使用されます。
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メッセージタイプ/コード、またはモビリティヘッダのタイプ）が含まれない場合があります。非初期フラグメントは、ポート（または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.)
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タイプ/コード、またはモビリティヘッダのタイプ）の値に関係なく、トラフィックを通過させるように構成されているトンネルモードSAをサポートしなければなりません。 SAは、指定されたプロトコルのトラフィックを伝送する場合は、SAのセレクタセットは、ANY、ポートフィールド（またはICMPタイプ/コード、またはモビリティヘッダのタイプ）を指定しなければなりません。この方法で定義されたSAが示されたローカル/リモートアドレスの初期および非初期フラグメントおよび指定された次の層のプロトコル（複数可）を含むすべてのトラフィックを伝送します。 SA（すなわち、いずれかが（次の層）プロトコルセレクタ値として指定される）特定のプロトコルの値に関係なく、トラフィックを伝送する場合、ポートフィールドの値は不定であり、同様にいずれかに設定されなければなりません。 （4.4.1で述べたように、ANY OPAQUEならびにすべての特定の値を含みます。）
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.)
実装は、非断片化パケットと初期フラグメントとは別のみ以外のフラグメントを運ぶトンネルモードSAをサポートするかもしれません。 OPAQUE値は、このような断片を運ぶSAのフィールドセレクタをポート（またはICMPタイプ/コード、またはモビリティヘッダのタイプ）を指定するために使用されます。レシーバは、IPv4上で、この種のSAが採用されている場合、フラグメント攻撃をオーバーラップから保護するために（非初期）フラグメントを最小オフセットのチェックを実行しなければなりません。このようなチェックがIPv6非初期フラグメント上で実行することができないので、ユーザーや管理者は、そのような断片の送料は危険であってもよく、実装がIPv6トラフィックのためにそのようなSAをサポートしないことを選択することをお勧めします。また、この種のSAは、指定されたローカル/リモートアドレスペアとプロトコル値に一致するすべての非初期フラグメント、すなわちを運ぶでしょう、このSAに運ば断片は、断片化されていない場合、別々の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タイプ/コード、またはモビリティヘッダのタイプ）セレクタ値は、最初のフラグメントと非断片化パケットを運ぶためにSAを定義するために使用されるであろう。ユーザまたは管理者は、ポート（またはICMPタイプ/コード、またはモビリティヘッダのタイプ）フィールドに基づいて差別同一のリモート/ローカルアドレス間の1つのまたは複数のトンネルモードSAを作成したい場合は、このアプローチを使用することができます。これらの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を必要とします。 1がQoS差別化のための2つの実装の間で複数のSA持っていることを選択した場合は、その後、1はまた、複数のSAが断片-ポートなしで、サポートされている各QoSクラスのための1つを実行したい場合があります。個別のSAを介した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タイプ）フィールドの値（ないANYまたは不透明）とトンネルモードSAをチェックステートフル断片のいくつかのフォームをサポートするかもしれません。非自明なポート（またはICMPタイプ/コード又はMHタイプ）を利用するトンネルモードSA上の非初期フラグメントを送信する実装セレクタはNON_FIRST_FRAGMENTS_ALSOペイロードをNOTIFY IKEを介してピアに通知しなければなりません。
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パケット分類メカニズムを使用してフラグメントの廃棄をサポートしなければなりません。すべての実装は非自明なポート範囲が指定されているBYPASSトラフィックに対応するためにチェックステートフルフラグメントをサポートしなければなりません。懸念は、セキュリティが同じ宛先に向けIPsecで保護されたトラフィックを得損なう可能性がIPsec実装に到着平文、非初期フラグメントのBYPASSあります。例えば、特定のソース/宛先アドレスペア間のトラフィックのIPsec保護を要求SPDエントリで構成IPsec実装を考慮し、ポート23（Telnetの）上の特定のプロトコルおよび宛先ポート、例えば、TCPトラフィック用。実装は、同じ送信元/宛先アドレスペアとプロトコルから、異なる宛先ポート、例えば、ポート119（NNTP）のトラフィックのBYPASSを可能にすると仮定する。攻撃者は、バイパス場合、同じソースからのIPsecで保護されたトラフィックと重なるので、IPsecで保護されたトラフィックの整合性に違反する可能性（偽造送信元アドレスを持つ）非初期フラグメントを送ることができます。非自明なポート範囲を持つBYPASSエントリをチェックするステートフルフラグメントを要求することは、この種の攻撃を防ぐことができます。上述したように、パケットのフラグメントが異なるセキュリティゲートウェイまたは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メッセージを受信してもよく、それがメッセージに作用することを選択した場合、その結果は、アウトバウンドトラフィックの処理に影響を与えます。このセクションでは、これら二つの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.
トラフィックがトンネルモードSAを介して行われる場合、すべてのIPsec実装は、それが放射するトンネルモードヘッダに発信パケットのDFビットをコピーするオプションをサポートしなければなりません。各SAのDFビット（セット、インナーヘッダからクリア、コピー）の実装の処理を構成することが可能でなければならないことを意味します。これは、両方の内側と外側のヘッダがIPv4であるのSAに適用されます。
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)
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]）： - タイプ= 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実装は、SADエントリにマップするアウトバウンドトラフィックを待つべき。そのようなトラフィックが到着すると、トラフィックが更新さ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.
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：オリジナル（平文）パケットは、IPv4で、DFビットがクリアされています。実装は、（その設定ごとに暗号化の前または後に）断片化し、その後の断片を転送する必要があります。これは、PMTU ICMPメッセージを送るべきではありません。
Case 3: Original (cleartext) packet is IPv6. The implementation SHOULD discard the packet and send a PMTU ICMP message.
ケース3：オリジナル（平文）パケットが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.
実装は、定期的に最初のホップデータリンクMTUにPMTUをリセットした後、通常のPMTU探索プロセスとしてPMTUを更新させることを提案パスMTU探索文書（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ヘッダデータのバイパスに厳しい制約を課します。他の人が、多くの場合、SA毎に、ローカルの管理統制を受けている間、いくつかの制約は、絶対です。アウトバウンドトラフィックの場合、これらの制約は、隠れチャネルの帯域幅を制限するように設計されています。インバウンドトラフィックのために、制約が悪（障壁の保護された側の）他のデータストリームに影響を与えることから、（IPsecの障壁の保護されていない側）1つのデータストリームを改ざんする能力を持って敵を防ぐように設計されています。トンネルモードSAの処理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.
IPsec実装はICMPメッセージペイロードからヘッダ情報を確認せず、ICMPヘッダの値に基づいて、SAの上ICMPエラーメッセージを渡すように構成されている場合、重大な脆弱性が生じる可能性があります。 -B-C、およびB-C：いくつかの部位（A、B、及びC）はESP保護トンネルを介して相互に接続されたシナリオを考えます。また、各トンネルのためのトラフィックセレクタはプロトコルおよびポートフィールドと、各サイトにサービスを提供するセキュリティゲートウェイの背後にあるシステムのアドレス範囲を包含するIP送信元/宛先アドレス範囲のためのいずれかを指定すると仮定する。これは、サイトBのホストに到達するサイトCで、ネット上のすべてのホストを宣言し、サイトAの任意のホストにICMP宛先到達不能メッセージを送信することができるようになります。これはセクション6.2で説明したようにSPDが適切に構成されている場合、ICMPエラーメッセージは、IPsecが提供チェックを行った場合に防止されている可能性が非常に効率的なDoS攻撃です。
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-モジュールレジストリの値（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）もあります。これは、（例えばIKEなど）SA管理プロトコルと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エントリは、現在関連付けられている各セレクタセットは、プロトコル、現在どのようなフィールドのローカルIPアドレス、リモートIPアドレス、および（もしあれば）に指定することができる「範囲のリスト」が含まセレクタ、N個の1から成ります次の層のプロトコル（ローカルポート、リモートポート、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トンネルモードSA、SGについては、BITS、またはBITW実装についてIPsecを適用する前にパケットを断片化させることができます。これは、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、トランスポートモードは、現在のセキュリティゲートウェイとの間とセキュリティゲートウェイとホストの間で使用されてもよいです。
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予約のSPIの定義が追加されています。
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のマッピングは、ユニキャストとマルチキャストSAのサポートのために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 3つのアプローチは、IPsec境界の保護側の平文フラグメントを処理するために追加されました。付録Dは、それらの背後にある理論的根拠を説明します。
o Added revised text describing how to derive selector values for SAs (from the SPD entry or from the packet, etc.)
O（SPDエントリから又はパケットからなど）SAのセレクタ値を導出する方法を説明改訂テキストを追加しました
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エントリ内のセレクタ値との関係、PFPフラグを記述する新しいテーブルを追加し、対応する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.
ICMPエラーメッセージを処理記述O内容を更新。 「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テキストは、マルチキャストSAの存在下でのSAへのインバウンドのIPsecデータグラムをマッピングするためのアルゴリズムを明確に追加されました。
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.
IPアドレスとポートに対するO、「ローカル」と「リモート」という用語は、ポリシールール（交換元および宛先）のために使用されます。 「ローカル」は、アウトバウンドパケットのIPsec実装、すなわち、「送信元」アドレス/ポート又は受信パケットの「宛先」アドレス/ポートによって保護されているエンティティを指します。 「Remoteは、」ピア・エンティティまたはピアエンティティを指します。用語「ソース」と「宛先」は依然としてパケットヘッダフィールドのために使用されます。
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標準の最初のシリーズ執筆蘭アトキンソンの拠出承認したいと思います：RFCの1825年から1827年を。 IPSec標準の第二シリーズ（のRFC 2401、2402、および2406）に、特にIPv6の問題に関しては、現在のバージョンへの重要な貢献をしたとチャーリー・リン、。著者らはまた、このプロトコル仕様の発展に貢献した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.
このセクションでは、この文書で使用されているいくつかの重要な用語の定義を提供します。他の文書は[HA94] [Shi00]、[VK83]、例えばこの技術に関連する追加の定義と背景情報を提供し、そして。一般的なセキュリティサービスとセキュリティメカニズムに関して、プラスの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.
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のコンテキストにおいて、特にセキュリティゲートウェイにおいて、トンネル・モードで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.
データ発信元認証データの主張ソースの身元を確認するセキュリティサービス。このサービスは通常、コネクションレスインテグリティサービスにバンドルされています。
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.
暗号化セキュリティ・メカニズムは、機密性を提供するために、判読できない形式（暗号文）に分かり易い形式（平文）からのデータを変換するために使用されます。逆変換プロセスは「解読」に指定されています。多くの場合、用語「暗号化」とは、一般的に両方のプロセスを参照するために使用されています。
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は整合性の二つの形式をサポートしています。コネクションレスの整合性は、トラフィックのストリームにおけるデータグラムの順序に関係なく、個々の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のコンテキストでは、セキュリティゲートウェイは、ESPは、それらが通信するときにも直接または経由して（IPsecを用いた外部のホストと、これらのホストのセキュリティサービスを提供し、内部ホストのセットを提供するために実装されているAHれる及び/又は点であります別のセキュリティゲートウェイ）。
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）着信パケットが結合すべきSAを識別するために受信機によって使用される任意の32ビット値。ユニキャストSAのために、SPIは、SAを指定するために単独で使用することができ、またはそれは、IPsecプロトコルタイプと組み合わせて使用することができます。追加のIPアドレス情報は、マルチキャストSAを識別するために使用されます。 SPIは、受信したパケットが処理されるの下でSAを選択するために受信システムを可能にするために、AHとESPプロトコルで運ばれます。 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 [Section 8.6">Sch94].
トラフィック分析敵にとって有用な情報を推定するためのネットワークのトラフィックフローの分析。そのような情報の例としては、送信の周波数、会話の当事者のアイデンティティ、パケットのサイズ、フロー識別子[セクション8.6" > 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.
この付録では、ルイス・サンチェス、マットCondell、そしてジョン・蔵王による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つしか任意の検索に一致するだろうから、その上の任意の順序付けの要件は、もはやありません。次のセクションでより詳細に記述する非相関及び非相関化を実現するために使用することができるアルゴリズムを提示します。
B.1. Decorrelation Algorithm
B.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.
A policy (SPD entry) P may be expressed as a sequence of selector values and an action (BYPASS, DISCARD, or PROTECT):
ポリシー（SPDエントリ）Pは、セレクタ値の配列と作用（BYPASS、DISCARD、またはPROTECT）のように表すことができます。
Ci = Si1 x Si2 x ... x Sik -> Ai
CI =のSi1 Si2のX X ... Xシク - >愛
1) Put C1 in set U as U1
1）U1としてセットUでC1を入れ
For each policy Cj (j > 1) in C
Cにおける各ポリシーCjの（j> 1）のために
2) If Cj is decorrelated with every entry in U, then add it to U.
CjのがU内のすべてのエントリを非相関されている場合は2）、その後、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.
CjがU内の1つの以上のエントリと相関している場合3）、非相関エントリのセットに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）値がCjの中SJNの値のスーパーセットである場合、その値から、Cjとの値を使用する（T.の項目のいずれかに表示される選択SJNの各値に対してツリーに分岐を追加普遍集合を表す。）また、補数を取った場合、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.
Cのすべてのエントリが処理された場合5）、次いで、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).
最適化することが可能である、または少なくとも、慎重に次の分岐に使用するセレクタの順序を選択することによって発生した分岐の量を向上させます。 Tにおけるそのセレクタのすべての値が等しいまたはCでSJNの値のスーパーセットであるように選択SJNを選択することができる場合に補体がヌルであるので、例えば、その後、単一のブランチを（作成する必要が）。
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における相関のいずれかのエントリで上書きされているかどうかを確認することです。これは分岐が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.
CjはU.内のエントリそれがある場合、それは関係ありませんから、それをスキップで上書きされている場合、エントリは既にステップ2で非相関されたかどうかをチェックするとともに、確認してください。 xのすべてのセレクタに等しいまたはエントリyに対応するセレクタのサブセットである場合、エントリxは別のエントリ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-モジュール（3）SPD-モジュール（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) } ;
PKIX1Explicit88からの輸入RDNSequence {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-明示（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
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 /キャッシュエントリ）にマッピングするトラフィックのための決定論的なアルゴリズムを必要とするので、第一および第三の問題が発生します。私たちは、IPsecの境界を越える非初期フラグメントに違反する受信機（または送信）で開催中のアクセス制御ポリシーを起こさないことを確認するため、すべての3つの問題が重要です。
D.1. Transport Mode and Fragments
D.1。トランスポートモードおよびフラグメント
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.
まず、我々は、トランスポートモードSAが断片を運ばないように定義されていることに注意してください。これは、トランスポートモードSAは、常にエンドポイントで終了RFC 2401、からのキャリーオーバーです。最悪の場合には、IPsecを適用したIPv4の断片を、宛先に向かう途中、（暗号文パケットとして）フラグメント化されるかもしれない、これは基本的な要件です。 IPsecの受信機におけるIPフラグメント再構成手順は、IPsec処理後に作成された前の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処理の後にトンネルモードのパケットを断片化させることができます。 IPv6におけるフラグメントヘッダは、AHまたはESPヘッダの後に現れるので、再組み立てに関して受信機で混乱を引き起こさないためしかし、IPv4のとは異なり、トランスポートモードSA上で平文断片を運ぶことが可能であろう。具体的には、受信機は、IPsec処理の後まで断片再組み立てのためにしようとしないであろう。物事をシンプルに保つために、この仕様はIPv6トラフィック用のトランスポートモードSA上でのフラグメントの運送を禁止しています。
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.
端部のみのシステムは、トランスポートモードSAを使用した場合、我々は、エンドシステムがIPSecに断片を提供しないように構成することができると仮定するので、断片のキャリッジの禁止は、問題ではなかったです。ネイティブホスト実装の場合、これは、誰かがすでに述べたように、RFC 2401はBITS実装はSAルックアップを実行する前にフラグメントを再構成する必要がある場合がありますことを警告し、合理的なようだ、と。 （これは、次いで、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.
本明細書では、2つのSG間、IPsec実装が最終的な宛先でない場合、例えば、トランスポートモードを使用することが許容されます。原則として、これはアウトバウンド、平文フラグメントはIPsec処理のために、トランスポートモードSAにマッピングするための新しい機会を作成します。しかし、トランスポートモードSAは、現在使用が承認されているこれらの新しい文脈で、非で「アウターヘッダ」を持っているのIPsec、すなわち、パケットによって見られるように、我々は、フラグメントの送信を禁止し続けることができると思わゼロフラグメントオフセットフィールド。例えば、IPオーバレイネットワークでは、トランスポート・モードSAを介して送信されるパケットは、IPsec処理の前にフラグメンテーションを収容するために必要な内部ヘッダを有するこのようIPインIPトンネリングとされています。トランスポート・モードSAを介して行う場合、IPsecは、そのようなトラフィックの内部IPヘッダを調べないので、断片すべきパケットを考慮しないであろう。
D.2. Tunnel Mode and Fragments
D.2。トンネルモードおよびフラグメント
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.
トンネルモードのSAのため、それは常にアウトバウンドフラグメントがIPsec実装での処理のために到着する可能性がある場合でした。非初期フラグメントは、一般的に、TCP、UDP、またはSCTPなどの次の層のプロトコルに関連するポート・フィールドを含んでないので、断片化されたアウトバウンド・パケットに対応する必要性が問題を提起することができます。このように、与えられたIPsec実装のためのSPDの設定に応じて、平文フラグメントは、あるいは、問題を提起しない場合があります。
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つのアドレス範囲の間のすべてのトラフィックが（何BYPASSまたはDISCARD SPDエントリは、このアドレス範囲に適用されていない）、このアドレスに対して定義されたSA上の非初期フラグメントを運ぶために簡単なはず提供IPsec保護であることを必要とする場合範囲は、SPDエントリ以来アドレス範囲の間のすべてのトラフィックを伝送する意図を意味します。これらのエントリは、ポートフィールド（対ANY）の異なるサブセットを参照している場合でも、そこにフラグメントと一致することができ、複数のSPDエントリがあり、場合、明確に、右のエントリーへのアウトバウンド非初期フラグメントをマッピングすることはできません。 （私たちはIPv6のトランスポートモードSA上でのフラグメントのキャリッジを許可することを選択した場合、問題は同様にそのコンテキストで発生します。）
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のポートフィールドのセレクタ値としてOPAQUEの定義をやる気OPAQUEための他の動機は、ポートフィールドが原因のIPsecの適用前にアクセスできない場合があります観察です。ホストは、そのトラフィックにIPsecを適用し、そのトラフィックがSGに到着した場合、これらのフィールドは暗号化されます。また、このような状況で暗号化された次の層のプロトコル・フィールドを収容するOPAQUEの動機使用をRFC 2401に記載された「次のレイヤプロトコル」を配置するための指定されたアルゴリズム。それにもかかわらず、OPAQUE値の主な用途は、トラフィックセレクタポートフィールド（非初期の断片）を含んでいなかったパケット内のフィールド、またはポートフィールドが既に（のIPsecのネストされたアプリケーションの結果として）暗号化されたパケットを照合することでした。 RFC 2401はANYをOPAQUEの代替であるかもしれないいくつかの場所で示唆、ANY対OPAQUEの使用を議論する中で曖昧でした。
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.
私たちは、ANYとOPAQUE値の両方を定義することにより、追加のアクセス制御機能を得ることができます。 OPAQUEはアクセスできないだけでフィールドに一致するように定義することができます。我々は、すなわち、それはすべての値に一致するだろうが、唯一のアクセスポートフィールドに、OPAQUEの補数としてANYを定義することができます。そこで我々は、我々は次の層のプロトコルとしてESPとAHを扱うように、このドキュメントの次の層のプロトコルを見つけるために採用手順を簡素化しています。その結果、暗号化された次の層のプロトコル・フィールドの概念が消えており、どちらか暗号化されたポートフィールドを心配する必要もありません。それに応じて、OPAQUEは唯一の非初期フラグメントに適用されます。
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.
私たちはどんなとOPAQUEのための上記の定義を採用しているので、私たちは、指定されたプロトコル、ポートフィールドを持っていないとき、および任意のプロトコルセレクタに使用される場合、これらの値がどのように機能するかを明確にする必要があります。特定のプロトコル値をセレクタとして使用される場合、そのプロトコルは全くポートフィールドを持っていない場合はそれに応じて、次にポートフィールドセレクタは無視するとANYは、ポートフィールドの値として指定しなければなりませんです。 （IPv6のモビリティヘッダタイプ値は、この文脈では、ICMPタイプおよびコード値は、IKEv2のネゴシエーションのための単一のポートフィールド（）としてひとまとめにされている。）プロトコルセレクタがANYである場合、これは指定するのと同じように扱われるべきです何ポート・フィールドが定義されていないので、ポートセレクタは無視されるべきであり、いずれかに設定されなければならないためのプロトコル。
D.3. The Problem of Non-Initial Fragments
D.3。先頭以外のフラグメントの問題
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,
SG実装の場合、フラグメントがSGの背後にあるエンドシステムから届くかもしれないことは明らかです。 BITW実装はまた、その背後のホストまたはゲートウェイからのフラグメントを発生することがあります。最悪の場合（ネイティブホスト実装とBITS実装は、おそらく次のような問題を回避することができるが。先に述べたように）、パケットからフラグメントが異なるBITWまたはSGのインスタンスに到着し、従って溶液オプションとして再組み立てを妨げる可能性があります。したがって、RFC 2401で、我々はフラグメントがすべての実装のためにトンネルモードに収容されなければならない一般的な要件を採用しました。しかしながら、
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.
RFC 2401は完璧なソリューションを提供していませんでした。ポートフィールド（RFC 2401で必要があります）のためのセレクタ値としてOPAQUEの使用は、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.
一つは、すべての非初期フラグメントは、送信元/送信先（S / D）アドレスおよびプロトコルに一致する、両方のポートフィールドにOPAQUE値を使用して、2つのIPsec（SGまたはBITW）実装との間にSAを定義した場合、RFC 2401で定義された機能を使用してSAの値はそのSAにマップされます。我々はOPAQUEの厳密な定義を採用した場合、最初のフラグメントは、この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 <ESPワット/整合性<そのBYPASSを言うかもしれないが、我々は、複数の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
もう一つの懸念は明らかに許容可能な初期フラグメントと組み合わせたときに、専用のSAを介して送信される非初期フラグメントが、重複し再組み立て攻撃を行うために使用されるかもしれないということです。 （この種の攻撃は、偽の断片の作成を想定し、通常の断片化の副作用ではありません。）この懸念は簡単に対処されます
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.
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.
別の可能な懸念は、いくつかのトポロジーと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.
それほど深刻な懸念は、非初期フラグメントが、その中で、彼らは有効な、初期の断片がこれまでに到着しないだろうときに送信することができ、DoS攻撃の機会を表すかもしれない非初期フラグメントのみのSAを介して送信されるということです。これは、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.
我々はOPAQUE取り囲むような任意のセレクタ値を解釈する場合、両方のポートフィールドのすべての値を持つ単一のSAは、S / Dアドレスとプロトコルトラフィックセレクタの一致するすべてのトラフィック、OPAQUE値を使用する代わりに対応することができるであろう。しかし、ANY、ここで使用すると、同じアドレスのペアとプロトコルに同じ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.
基本的に、フラグメント処理の問題は、複数のSAが同じS / Dアドレスとプロトコルセレクタ値を有するが、異なるポートフィールドセレクタ値で定義されている場合にのみ生じます。
D.4. BYPASS/DISCARD Traffic
D.4。 BYPASS / DISCARDトラフィック
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処理とは独立してBYPASS / DISCARDエントリの非初期フラグメント処理の問題に対処しなければなりません。これは、大きく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.
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境界に対するすべてのトラフィックのために明確に定義され、アクセス制御機能を提供するという当社の目標と一致し、ここにガイダンスを提供する必要があります。そのために、このドキュメントでは、ポートのフィールドが指定された場合の実装がBYPASS / DISCARDトラフィックのフラグメント再構築をサポートしなければならないと述べています。実装は、このようなトラフィックを受け入れるか、4.4.1項で説明したSPDの規則を使用して、このようなトラフィックを拒否するために、ユーザーや管理者に許可する必要があります。懸念は、セキュリティが同じ宛先に向けIPsecで保護されたトラフィックを得損なう可能性がIPsec実装に到着平文、非初期フラグメントのBYPASSあります。例えば、特定のソース/宛先アドレスペア間のトラフィックにIPsec保護を要求SPDエントリで構成IPsec実装を考慮し、ポート23（Telnetの）上の特定のプロトコルおよび宛先ポート、例えば、TCPトラフィック用。実装は、同じ送信元/宛先アドレスペアとプロトコルから、異なる宛先ポート、例えば、ポート119（NNTP）のトラフィックのBYPASSを可能にすると仮定する。攻撃者は、バイパス場合、同じソースからのIPsecで保護されたトラフィックと重なるので、IPsecで保護されたトラフィックの整合性に違反する可能性（偽造送信元アドレスを持つ）非初期フラグメントを送ることができます。非自明なポート範囲を持つBYPASSエントリをチェックするステートフルフラグメントを要求することは、この種の攻撃を防ぐことができます。
D.5. Just say no to ports?
D.5。ただ、ポートにノーと言いますか？
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メンバーは、（非自明な）ポートフィールドセレクタとトンネルモードSAの使用が適切であるシナリオを説明してきました。だから、挑戦はBITWとSGの状況でこの問題に対処することができる戦略を定義しています。かかわらず、トランスポート・モード概念対トンネルの、ポートの使用は、同じ問題を提起するSPDにおけるそのBYPASS / DISCARDエントリを注意。
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の背後にあるファイアウォールがポートレベルのアクセス制御と断片化の影響を強制するために残されるべきであることを示唆しています。しかし、これは（例えば、IKEペイロード中）のIPsecでのそのほかの場所でちぐはぐな提案であるように思わ我々は常に断片を破棄し、ファイアウォールを懸念しています。多くのファイアウォールは、一般的に断片を渡さない場合、なぜ我々は彼らがこのような場合には断片に対処するために期待できますか？だから、この分析は、トンネルモードSAでのポートフィールドセレクタの使用を禁止する提案を拒否します。
D.6. Other Suggested Solutions
D.6。その他の推奨ソリューション
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.
この提案のより洗練されたバージョンは、非初期フラグメントは、右のSAまたはSPD /キャッシュエントリに一致させることができるようにするために、遭遇した各初期フラグメントから最小限の状態を確立し、維持するために呼び出します。これは、現在の処理モデル（と古いもの）への拡張を意味します。 IPsec実装は、すべてのフラグメントを傍受でしょう。最初の断片から送信元/宛先IPアドレス、プロトコル、パケットID、およびポートフィールドを取り込みます。その後、ポートフィールドを必要とSAの非初期フラグメントをマッピングするために、このデータを使用しています。このアプローチを使用する場合、それはあまりにも受信フラグメントが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は、パケットのためのいくつかの断片が異なるのSGまたは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.
ワーキンググループは、OPAQUEポートフィールドの使用を介したRFC 2401モデルで暗黙的にサポートされていました何かを唯一の非初期フラグメントを運ぶためにSAを作成するための条約の以前のバージョンを拒否したが、明確にRFC 2401に連接されません（拒否します各非初期フラグメントを求め）テキストは、送信者と受信者によってプロトコル44（IPv6のフラグメントヘッダプロトコルID）として扱われます。このアプローチは、より均一なハンドリングIPv4およびIPv6フラグメントを作る可能性を秘めているが、それは根本的な問題は変更されません。また、BYPASS / DISCARDトラフィックのためのフラグメント処理の問題に対処ありません。 IPv6はポーズフラグメントオーバーラップアタックの問題を考えると、この戦略を採用するための努力の価値があるように見えるしません。
D.7. Consistency
D.7。一貫性
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 BITS、BITWまたはSGを許可することに同意しました。この断片化は、送信側でSA検索後に実行されている場合は、問題ない「右SAへのマッピング」はありません。しかし、受信機は、まだ非初期フラグメントは、それらが受信される経由SAと一致していることを確認できるようにする必要があります。最初のフラグメントが途中で失われる可能性があるため、受信機は、上述の潜在的な問題のすべてに遭遇します。私達は私達の決定に矛盾しないようにしている場合はこのように、我々は、受信機が到着した非初期フラグメントに対処する方法を言う必要があります。
D.8. Conclusions
D.8。結論
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.
すべてのコンテキスト内のフラグメントを処理するための簡単な、均一な方法はありません。異なるアプローチが異なるコンテキストで良い仕事します。 1つのMUSTと2つのメイズ - したがって、この文書は3つの選択肢を提供しています。将来のある時点で、2つのメイズとコミュニティの利益の経験あれば、彼らはSHOULDsまたはマストになったり、他のアプローチを提案することができます。
Appendix E: Example of Supporting Nested SAs via SPD and Forwarding Table Entries
付録E：SPDを経由してネストされたSAを支えるの例および転送テーブルエントリ
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.
この付録では、新しい処理モデルと一致し、SAのネストされたペアをサポートするために、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からBへのトンネルモードSAを介して搬送されるCへのトランスポートモードSAをサポートすることで、Aは、公衆インターネットに接続されたラップトップかもしれない、Bは保護ファイアウォールかもしれません企業ネットワーク、および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:
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と比較されます。 ESPトンネルモードで適用されるように、この時間は、それは、SPDルール2に一致します。外側の宛先アドレスが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.
AのCからの着信TCPパケットは2つのESPヘッダに包まれています。内部ヘッダ（ESPトランスポートモード）をソースとしてCを示し、一方、外部ヘッダ（トンネルモードでESP）は、ソースとしてBを示しています。 Aに到着すると、パケットは、SPIに基づいてSAにマッピングされた外部ヘッダを削除した、および復号することと整合性がチェックされることになります。それはSPDルール2から誘導先としてソースとAとCを指定するであろう、このSAのためのSADセレクタ、照合される保護された側の転送機能は、その後に基づいて保護されていない側に戻ってそれを送ることになりますアドレスおよび次の層のプロトコル（ESP）、ネスティングを示します。これは、SPD-O（図3参照）と比較し、それがバイパスされるように、SPDルール1に一致することが見出されています。パケットは、SPI、整合性チェックに基づいて、SAにマッピングされ、そして転送機能3. SPDルールに由来する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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[Bra97]ブラドナーの、S.、BCP 14、RFC 2119、1997年3月 "のRFCsにおける使用のためのキーワードは、要求レベルを示すために"。
[CD98] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[CD98]コンタ、A.、およびS.デアリング、 "インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 2463（1998年12月）。
[DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DH98]デアリング、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]第三イーストレイク、D.、RFC 4305、2005年12月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[HarCar98]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Kau05]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[Ken05a]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Ken05b]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[MD90]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Mobip]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81a]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
[Pos81b]ポステル、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]シラー、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]ワール、M.、Kille、S.、およびT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（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.サンチェス、「の決定的施行に関する国連は、注文したセキュリティ・ポリシー」、BBN技術メモ1346年、2004年月。
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
【FaLiHaMeTr00]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（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]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月[HC03]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有マルチキャスト"、進歩、11月3日での作業、 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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[Per96]パーキンス、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.
"IPに明示的輻輳通知の添加（ECN）" [RaFlBl01]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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.、ヴァイス、B.、Hardjono、T.、およびH.ハーニー、 "解釈のグループドメイン"、RFC 3547、2003年7月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、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.、コンタ、A.、大工、B.、およびS.デアリング、 "IPv6のフローラベル仕様"、RFC 3697、2004年3月。
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Sch94]シュナイアー、B.、応用暗号、8.6節、John Wiley＆Sons、ニューヨーク、NY、1994。
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[Shi00] Shirey、R.、 "インターネットセキュリティ用語集"、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.、ペレイラ、R。、およびM.トーマス、 "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]タッチ、J.、エッゲルト、L.、およびY.王、 "ダイナミックルーティングのための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.ケント、「高レベルのネットワークのセキュリティ機構」、ACMコンピューティング調査、巻。 15、第2号、1983年6月。
Authors' Addresses
著者のアドレス
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
スティーブン・ケントBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3988 EMail: kent@bbn.com
電話：+1（617）873-3988 Eメール：kent@bbn.com
Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
カレンソBBNテクノロジーズ10モールトンストリートケンブリッジ、MA 02138 USA
Phone: +1 (617) 873-3152 EMail: kseo@bbn.com
電話：+1（617）873-3152 Eメール：kseo@bbn.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。