原文：ftp://ftp.rfc-editor.org/in-notes/rfc4301.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
2008/12/21 0.1.0 初版
2013/10/19 0.2.0 RFC 4303の翻訳に合わせる形で全体を見直しました。
サイト内関連リンク：
RFC 791 IP(日本語訳)
RFC 4302 IPsec(日本語訳)
RFC 4303 ESP(日本語訳)
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. この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況については "Internet Official Protocol Standards" (STD 1)を参照してほしい。この文書の配布に制限はない。
Copyright (C) The Internet Society (2005).
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 のためのセキュリティアーキテクチャ(Security Architecture for IP)" の最新バージョンである。この文書は RFC 2401 を廃止する。
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 の先輩であった故 Charlie Lynn に、この文書をささげる。
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 アーキテクチャのすべての側面を示しているわけではない。例えば、Network Address Translation (NAT) 環境における IPsec の使用方法や、IP マルチキャストのためのより包括的なサポートなど、特殊な環境における付加的なアーキテクチャの詳細は他の文書に示されている。IPsec のセキュリティアーキテクチャの基本的な構成要素は、下層の必須機能の観点から議論されている。追加の RFCが (a)(c)(d) におけるプロトコルを定義している(他の文書へのポインタはセクション 1.3 を参照)。
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]. 文書中のキーワード MUST、 MUST NOT、 REQUIRED、 SHALL、 SHALL NOT、 SHOULD、 SHOUL NOT、 RECOMMENDED、 MAY は、それぞれ RFC 2119 [Bra97] で説明されている通りに解釈される。
The target audience for this document is primarily individuals who implement this IP security technology or who architect systems that will use this technology. Technically adept users of this technology (end users or system administrators) also are part of the target audience. A glossary is provided in Appendix A to help fill in gaps in background/vocabulary. This document assumes that the reader is familiar with the Internet Protocol (IP), related networking technology, and general information system security terms and concepts. この文書の主な対象読者は、この IP セキュリティ技術を実装する個人、またはこの技術を用いたシステムを設計する個人である。この技術に精通している人々(エンドユーザーまたはシステム管理者)もまた、対象読者の一部である。背景や語彙のギャップを埋める手助けとなる用語集は付録 A にて定義されている。この文書は、インターネットプロトコル(IP)や関連するネットワーク技術、情報システムセキュリティの用語・概念に読者が精通していることを前提としている。
As mentioned above, other documents provide detailed definitions of some of the components of IPsec and of their interrelationship. They include RFCs on the following topics: 前述の通り、IPsec の一部の構成要素の詳細な定義とそれらの関係とについて、他の文書が提供されている。それらの文書には以下のトピックに関する RFC が含まれる：
IPsec is designed to provide interoperable, high quality, cryptographically-based security for IPv4 and IPv6. The set of security services offered includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic flow confidentiality. These services are provided at the IP layer, offering protection in a standard fashion for all protocols that may be carried over IP (including IP itself). IPsec は、IPv4 および IPv6 のための相互運用可能で高品質な、暗号化を基礎にしたセキュリティを提供するために設計されている。提供されるサービスには、アクセスコントロール、コネクションレス完全性、データ送信元認証、リプレイの検出と拒否(部分的シーケンス完全性)、機密性(暗号化による)、限定トラフィックフロー機密性が含まれる。これらのサービスは IP 層で提供され、IP 上を運ばれるすべてのプロトコル(IP 自身も含む)に対して標準的手法による保護を提供する。
IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer. Implementations are free to provide more sophisticated firewall mechanisms, and to implement the IPsec-mandated functionality using those more sophisticated mechanisms. (Note that interoperability may suffer if additional firewall constraints on traffic flows are imposed by an IPsec implementation but cannot be negotiated based on the traffic selector features defined in this document and negotiated via IKEv2.) The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection. それが 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. 大部分のセキュリティサービスは、二つのトラフィックセキュリティプロトコル(認証ヘッダ(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 標準や他の 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 がどのように動作するのか、システムの構成要素、前述のようなセキュリティサービスを提供するためにそれらがどのように組み合わされるのかについて、高水準の説明を提供する。この説明の目的は、読者がそのプロセス/システムの全体像を "思い描く(picture)" ことが出来るようになることである。それがどのように 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) によって定義される要求事項に基づく。SPD はユーザーまたは管理者によって、またはそのどちらかが規定する制約の範囲内で動作するアプリケーションによって、確立・維持される。一般にパケットは、SPD 内のエントリに一致する IP とその上位層とのヘッダ情報("セレクタ(Selectors)"、セクション 4.4.1.1 参照)に基づいて、三つの処理動作のうちのひとつを選択される。各パケットは、セレクタによって指定された適用可能な SPD ポリシーに基づいて、IPsec のセキュリティサービスを利用して保護される(PROTECT)か、破棄される(DISCARD)か、IPsec の保護をバイパスする(BYPASS)ことを許可されるかの、いずれかを選択される。
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 はひとつまたは複数の "経路(paths)" を保護するために使用される。経路は (a)ホスト同士の間、(b)セキュリティゲートウェイ同士の間、(c)セキュリティゲートウェイとホストとの間にある。準拠するホスト実装は (a) と (c) とをサポートしなければならない(MUST)。また特定の環境ではセキュリティゲートウェイがホストとしても動作するため、準拠するセキュリティゲートウェイは三つすべての接続形態をサポートしなければならない。
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
保護されない
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| | 破 棄 |<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec 境界
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| | 破 棄 |<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
保護される
図 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. 図の "保護されない(unprotected)" は、"黒い(black)" または "暗号文(ciphertext)" とも説明されるインターフェイスを参照する。また "保護される(protected)" は、"赤い(red)" または "平文(plaintext)" とも説明されるインターフェイスを参照する。上記の保護されるインターフェイスは内部的(例えば、IPsec のホスト実装の中)でもよいし、保護されないインターフェイスは OS の提供するソケットレイヤに接続していてもよい。この文書において "インバウンド(inbound)" という用語は、保護されないインターフェイスを通って IPsec 実装の内部に入るトラフィック、または境界の保護されない側の実装によって発行され、保護されるインターフェイスへと向けらたトラフィックを指す。"アウトバウンド(outbound)" という用語は、保護されたインターフェイスを通って実装内部に入るトラフィック、または境界の保護された側の実装によって発行され、保護されないインターフェイスへと向けられたトラフィックを指す。ひとつの 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 はオプションで IP 圧縮[SMPT01] の交渉をサポートする。これは、IPsec 内で暗号化を採用すると、下位プロトコルによる効果的な圧縮が妨げられるという観測によるものである。
IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP). Both protocols are described in detail in their respective RFCs [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY support AH. (Support for AH has been downgraded to MAY because experience has shown that there are very few contexts in which ESP cannot provide the requisite security services. Note that ESP can be used to provide only integrity, without confidentiality, making it comparable to AH in most contexts.) IPsec はトラフィックセキュリティサービスを提供するために二つのプロトコル、認証ヘッダ(AH)とカプセル化セキュリティペイロード(ESP)とを使用する。両プロトコルの詳細は、それぞれの RFC [Ken05b, Ken05a] において説明されている。IPsec の実装は ESP をサポートしなければならず(MUST)、また AH をサポートしてもよい(MAY)。(AH のサポートは "してもよい(MAY)" に格下げされた。これは ESP で必要十分なセキュリティサービスを提供できない状況が非常にまれであるという経験によるものである。機密性を提供せず完全性だけを提供する目的で ESP を使用することが可能であり、多くの場合 AH に匹敵することに注意してほしい。)
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 パケットに適用される。二つのモードの違いはセクション 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 はセキュリティサービスが提供される粒度をユーザー(またはシステム管理者)が制御することを許可している。例えば、二つのセキュリティゲートウェイの間のすべてのトラフィックを運ぶために単一の暗号トンネルを生成することもできるし、それらのゲートウェイを横断して通信するホストの各組の間の TCP 接続ごとに別々の暗号トンネルを生成することもできる。SPD 管理の枠組みを通して、IPsec は以下を指定する機能を組み入れる：
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])を指定しているが、他の自動鍵配布技術を使用してもよい(MAY)。
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 を実装する方法は多くある。
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 のホスト実装は、いわゆる "ホスト(hosts)" のようには見えない可能性のあるデバイス内に実装されてもよい。例えばルータは、ルータを通過する加入者トラフィックに影響を与えることなくルーティングプロトコル(例えば BGP)や管理機能(例えば TELNET)を保護するために、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. このセクションは、AH・ESP を実装するすべての IPv6 実装と IPv4 実装とのためのセキュリティーアソシエーション管理の要求事項を定義する。"セキュリティアソシエーション(Security Association)"(SA) の概念は IPsec の基盤である。AH と ESP とはともに SA を利用するうえ、IKE の主な機能は SA の確立および保守である。AH または ESP のすべての実装は、下記の SA の概念をサポートしなければならない(MUST)。このセクションの残りでは、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 は、それによって運ばれるトラフィックにセキュリティサービスを提供する単方向の "接続(connection)" である。セキュリティサービスは、AH または ESP のどちらか(両方ではない)によって SA に提供される。AH と ESP とによる保護をひとつのトラフィックストリームに適用する場合、二つの SA を生成し、セキュリティプロトコルの反復適用によって保護機能をもたらすように協調させなければならない。IPsec を使用可能な二つのシステムの間の典型的な双方向通信を保護するためには、SA の組が必要になる(各方向にひとつずつ)。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 の場合、その SA を特定するにはセキュリティパラメータインデックス(SPI)だけで十分である(SPI に関する情報は、付録 A と、AH および ESP の仕様 [Ken05b,Ken05a] を参照してほしい) 。しかしながら実装は、SA を特定するために、SPI と同時に IPsec のプロトコル種別(AH または ESP)を使用することを選択してもよい。マルチキャストをサポートする IPsec 実装は、インバウンドの IPsec データグラムを SA にマッピングするために、後述のアルゴリズムを使用するマルチキャスト SA をサポートしなければならない(MUST)。ユニキャストトラフィックだけをサポートする実装は、この分離アルゴリズムを実装する必要はない。
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])の多くでは、中央の Group Controller/Key Server が一方的にグループセキュリティアソシエーション(GSA)の SPI を割り当てる。この SPI の割り当ては、そのグループを構成する個々のエンドシステム上の鍵管理サブシステム(例えば IKE)と交渉したり協調したりすることはない。その結果として、GSA とユニキャスト SA とが同時に同じ SPI を使用する可能性がある。マルチキャスト能力を持つ IPsec 実装は、SPI がコリジョンを起こす状況であってもインバウンドトラフィックを正しく分離しなければならない(MUST)。
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.2.2)の各エントリは、SPI に加え、その SA の検索が宛先 IP アドレスを利用するのか、宛先/送信元 IP アドレスを使用するのかを示さなければならない。マルチキャスト SA の場合、SA 検索にプロトコルフィールドは採用されない。インバウンドの IPsec 保護されたパケットごとに、実装は "もっとも長い(longest)" SA 識別子と一致するエントリを見つけるために、SAD の検索を実行しなければならない。この状況において、SPI に基づいて検索したときに二つ以上の SAD エントリが一致した場合、(その SAD エントリ内で指定された通り)宛先アドレスまたは宛先/送信元アドレスに基づいて一致したエントリが、 "もっとも長い(longest)" 一致となる。これは、以下のような 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 を検索するのと等価でなければならない(MUST)。例えばソフトウェアベースの実装は、SPI によりハッシュテーブルにインデックスを作成することができる。各ハッシュテーブル内の SAD エントリのリンクリストは、もっとも長い SA 識別子をリンクリスト内の最初に置くようにソートされた状態を維持すればよい。もっとも短い SA 識別子を持つ SAD エントリは、リンクリスト内で最後のエントリになるように並べればよい。ハードウェアベースの実装は、一般的に利用可能な三値連想メモリ(Ternary Content-Addressable Memory)(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. インバウンド IPsec トラフィックを SA にマップするために送信元/宛先アドレスの一致が必要かどうかの指定は、手動 SA 構成の副作用として、または SA 管理プロトコル(例えば IKE や Group Domain of Interpretation (GDOI) [RFC3547] など)による交渉を通して設定されなければならない(MUST)。一般に Source-Specific Multicast (SSM) [HC03] グループは、SPI・宛先マルチキャストアドレス・送信元アドレスの三要素から成る SA 識別子を使用する。Any-Source Multicast グループの 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. 異なるクラスのトラフィック(Differentiated Services Code Point (DSCP) ビット [NiBlBaBL98], [Gro02] によって区別される)が同じ SA 上を送信された場合、受信者がオプションのアンチリプレイ機能を AH および ESP の両方で有効にしていると、その機能が利用するウィンドウメカニズムのために、優先順位の低いパケットが不適切に破棄される可能性がある。したがって送信者は、Quality of Service (Qos)をサポートするために、同じセレクタ値を持つ異なるクラスのトラフィックを異なる SA 上に流すべきである。これを可能にするために IPsec 実装は、同じセレクタを持つ送信者と受信者との間で複数の SA の確立と保守とを許可しなければならない(MUST)。QoS をサポートするためにこれらの並列の SA にトラフィックを分散することは、送信者によるローカルの判断であり、IKE により交渉されるものではない。受信者は異なる SA からのパケットを偏見無しに処理しなければならない(MUST)。これらの要求事項はトランスポートモードとトンネルモードとの両方の SA に適用される。トンネルモード SA の場合、問題の DSCP 値は内側の IP ヘッダの中に現れる。トランスポートモードでは DSCP 値が途中で変更される可能性があるが、この値は SA 選択に関係なく、また SA/パケットの検証の一部としてチェックされてはならない(MUST NOT)ため、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] および Explicit Congestion Notification (ECN) [RaFlBl01] フィールドは "セレクタ(selectors)" ではないが、送信者は与えられた DSCP 値(の集合)を持つパケットを適切な SA に向けるメカニズムを必要とするだろう。このメカニズムは "分類器(classifier)" と呼んでよいだろう。
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 が定義されている。IKE は SA の組を生成するため、簡略化のために、私たちはひとつの組の両 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 ではなく)経路上の二つの中間システム間にセキュリティを望む場合、セキュリティゲートウェイ間またはセキュリティゲートウェイとホストとの間でトランスポートモードを使用してもよい(MAY)。セキュリティゲートウェイ間、またはセキュリティゲートウェイとホストとの間でトランスポートモードを使用する場合、トランスポートモード SA 上で埋め込み IP トンネリング(例えば IP-in-IP [Per96] または Generic Routing Encapsulation (GRE) トンネリング [FaLiHaMeTr00]、または動的ルーティング [ToEgWa04])をサポートするためにトランスポートモードを使用してもよい。明確性のために、中間システム(例えばセキュリティゲートウェイ)によるトランスポートモードの使用は、送信元アドレス(アウトバウンドパケットの場合)、または宛先アドレス(インバウンドパケットの場合)が、その中間システム自身に属するアドレスである場合にのみ許可される。IPsec の重要な部分であるアクセスコントロール機能は、この方法で使用されるトランスポートモード SA を横断するパケットのエンドツーエンドのヘッダには適用できないため、この状況においては極めて限定される。したがってトランスポートモードを使用するこの方法は、特殊な状況において採用される前に注意深く評価されるべきである。
In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any next layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and selected extension headers, but may appear before or after destination options; it MUST appear before next layer protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)). In the case of ESP, a transport mode SA provides security services only for these next layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header preceding it, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [Ken05b]. IPv4 の場合、トランスポートモードのセキュリティプロトコルヘッダは、IP ヘッダとオプションとの直後、上位層プロトコル(例えば TCP または UDP)の前に現れる。IPv6 の場合、セキュリティプロトコルヘッダは、ベース IP ヘッダと選択された拡張ヘッダとの後に現れるが、宛先オプションの前後どちらに現れてもよい(宛先オプションは上位層プロトコル(例えば TCP、UDP、Stream Control Transmission Protocol (SCTP))の前に現れなければならない(MUST))。ESP の場合、トランスポートモード SA は上位層プロトコルに対してのみセキュリティサービスを提供し、ESP ヘッダに先行する拡張ヘッダまたは IP ヘッダには提供しない。AH の場合、それに先行する IP ヘッダの選択部分、拡張ヘッダの選択部分、選択オプション(IPv4 ヘッダ・ IPv6 Hop-by-Hop 拡張ヘッダ・IPv6 送信先拡張ヘッダに含まれる)にも保護が拡張される。AH が提供する範囲の詳細は、AH 仕様[Ken05b]を参照してほしい。
A tunnel mode SA is essentially an SA applied to an IP tunnel, with the access controls applied to the headers of the traffic inside the tunnel. Two hosts MAY establish a tunnel mode SA between themselves. Aside from the two exceptions below, whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus, an SA between two security gateways is typically a tunnel mode SA, as is an SA between a host and a security gateway. The two exceptions are as follows. トンネルモード SA は本質的に IP トンネルに適用される SA であり、IP トンネル内部のトラフィックのヘッダに適用されるアクセスコントロールを持つ。二つのホストが互いの間にトンネルモード SA を確立してもよい(MAY)。以下の二つの例外を除き、セキュリティアソシエーションの一端がセキュリティゲートウェイの場合には常に、その SA はトンネルモードでなければならない(MUST)。したがって一般にセキュリティゲートウェイ間の SA は、ホスト・セキュリティゲートウェイ間と同様、トンネルモード 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 のためにトンネルモードを利用する動機は、いくつかの懸念事項である。例えば、あるセキュリティゲートウェイの背後の宛先に対して複数の経路(例えば異なるセキュリティゲートウェイを経由する経路)がある場合、SA が交渉されたセキュリティゲートウェイに IPsec パケットが送信されることが重要である。同じように、途中でフラグメント化されている可能性のあるパケットは、暗号処理の前に再構築できるように、すべてのフラグメントが同じ IPSec のインスタンスに送信されるようしなければならない。また、あるフラグメントが IPsec によって処理され送信された後に途中でフラグメント化された場合、IPsec 処理される前後のパケットフォーマットのためのフラグメント状態の情報を保持する内側のヘッダと外側のヘッダとが存在することは重要である。このように、SA の一方がセキュリティゲートウェイの場合にトンネルモードを採用する理由はいくつかある。(トランスポートモードと併せて IP-in-IP トンネルを使用することもまた、これらのフラグメント問題を解決する。しかしながらこの構成は、トラフィックにアクセスコントロールポリシーを強制するという IPsec の能力を制限する。)
Note: AH and ESP cannot be applied using transport mode to IPv4 packets that are fragments. Only tunnel mode can be employed in such cases. For IPv6, it would be feasible to carry a plaintext fragment on a transport mode SA; however, for simplicity, this restriction also applies to IPv6 packets. See Section 7 for more details on handling plaintext fragments on the protected side of the IPsec barrier. 注意：フラグメント化された IPv4 パケットに AH と ESP とをトランスポートモードを使用して適用することはできない。そのような場合、トンネルモードのみ採用可能である。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 処理を行う送信元と宛先とを特定する "外側の(outer)" IP ヘッダに加えて、(外見上の)最終的な送信元と宛先とを特定する "内側の(inner)" IP ヘッダが存在する。セキュリティプロトコルヘッダは、外側の IP ヘッダの後、内側の IP ヘッダの前に現れる。トンネルモードにおいて AH が採用された場合、トンネル化された IP パケット全体だけでなく、外側の IP ヘッダ部分にも(上記の通りの)保護が提供される(つまり上位層プロトコルに加え、内側の IP ヘッダ全体が保護される)。ESP が採用された場合、この保護はトンネル化されたパケットにのみ適用され、外側のヘッダには適用されない。
In summary, まとめると以下の通り
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 を定義するセレクタの選択により決定する。またさらに、例えば(チャイルド SA ではなく)IKE SA の生成中に IPsec ピアによって採用される認証方法も、アクセスコントロールの粒度に影響する。
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. 機密性が選択された場合、二つのセキュリティゲートウェイ間の ESP の(トンネルモード)SA は、部分的トラフィックフロー機密性を提供できる。トンネルモードを使用すると、(最終的な)トラフィックの送信元および宛先の身元を隠蔽することで、内側の IP ヘッダを暗号化することができる。また ESP ペイロードのパディングはパケットサイズを隠蔽することもできるため、トラフィックの外見的特徴をさらに隠蔽する。モバイルユーザーがダイアルアップ環境において動的 IP アドレスを割り当てられ、共有する(セキュリティゲートウェイとして動作する)ファイアウォールへの(トンネルモード) ESP SA を確立している場合にも、同じようなトラフィックフロー機密性サービスを提供できる。一般に高粒度の(細かい) 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. 注意：準拠する実装は、NUL 暗号と完全性を持たないアルゴリズムとを両方採用する ESP SA の導入を許可してはならない(MUST NOT)。このイベントのための監査ログエントリは、現在の日付/時刻、ローカルの IKE IP アドレス、リモートの IKE IP アドレスを含むべきである(SHOULD)。SA を開始した側は対応する 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 バンドル(SA bundles)" のサポートも要求しない。これらの機能は、SPD とローカルの(インバウンドおよびアウトバウンドのトラフィックのための)転送機能とを適切に構成することで、今でも効果を持たせることができるが、この能力は IPsec モジュールの範囲外であり、したがってこの仕様の範囲外である。結果として、ネスト化された/バンドルされた SA の管理は RFC 2401 [RFC2401] で暗示されていたモデルにおける場合にくらべ、本質的により複雑に、またより不確実なものになっている。ネスト化された SA のサポートを提供する実装は、ユーザーまたは管理者がネスト化の要件を表すことを可能にする管理インターフェイスを提供するべき(SHOULD)であり、必要な処理に影響を与えるための適切な 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 トラフィック処理のための一般モデルを説明する。以下で説明するモデルは名目上のものであり、実装がこのモデルの詳細に一致する必要はない。しかし標準に準拠するためには、外見的な振る舞いはこのモデルの外見的特徴に一致しなければならない(MUST)。
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)が存在する。ひとつ目のデータベースは、ホストまたはゲートウェイからのインバウンドまたはアウトバウンドのすべての IP トラフィックの処理を決定するポリシーを特定する(セクション 4.4.1)。二つ目のデータベースは、確立された(鍵化された)各 SA に関連するパラメータを含む(セクション 4.4.2)。三つ目のデータベース PAD は、SA 管理プロトコル(IKE など)と SPD との間のひも付けを提供する(セクション 4.4.3)。
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 (またはキャッシュされた SPD)は、IPsec による保護を受けないトラフィックを含め、IPsec 境界を通過するすべての(インバウンドまたはアウトバウンドの)処理時に必ず調べられなければならない。これには IKE などの IPsec 管理トラフィックも含まれる。IPsec 実装は少なくともひとつの SPD をもたなければならず(MUST)、その IPsec 実装が動作している環境において適切であれば、複数の SPD をサポートしてもよい(MAY)。RFC 2401 [RFC2401] で規定されていたのと同様、SPD をインターフェイス単位で保持する必要は無い。しかしながら複数の SPD をサポートする実装は、アウトバウンドのトラフィック処理のために適切な SPD を選択する際に呼ばれる明示的な SPD 選択機能を含まなければならない(MUST)。この機能への入力は、アウトバウンドパケットと、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 は、Access Control List (ACL) や、ファイアウォール・ルータなどにおけるパケットフィルタと同じく、順序付けられたデータベースである。この順序付けという要求事項は、セレクタの値として(ノントリビアルな)範囲が存在するために、エントリがしばしば重複することに起因する。したがってユーザーまたは管理者は、目的のアクセスコントロールポリシーを表すためにエントリを順序付けできなければならない(MUST)。セレクタ値にワイルドカードを使用してもよく、また異なる種類のセレクタは階層的な関連性を持たないため、一般的で標準的な順序を SPD エントリに課す方法はない。
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)
リモートアドレス 新しい SAD 宛
セレクタのPFPフ 先アドレスセレ
ラグの値 クタ値の例
--------------- ------------
a. PFP TRUE 192.0.2.3 (ひとつのホスト)
b. PFP FALSE 192.0.2.1 ～ 192.0.2.10 (ホストの範囲)
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 はきめ細かくても粗くてもよい。例えば、単独の SA が二つのホストの間のすべてのトラフィックを運び、セキュリティサービス一式を提供してよい。あるいは、使用されるアプリケーション(上位層プロトコル(Next Layer Protocol)とそれに関連するフィールド(ポート番号など)とで定義される)に依存して、ホスト間のトラフィックが、異なるセキュリティサービスを持つ複数の SA にまたがってもよい。同じように、セキュリティゲートウェイ間のすべてのトラフィックを単独の SA が運んだり、通信する各ホストの間にひとつの SA が割り当てられたりしてよい。以下に示すセレクタパラメータは、SA の粒度の制御を容易にするために、すべての IPsec 実装によってサポートされなければならない(MUST)。ローカルアドレスおよびリモートアドレスは、IPv4 または IPv6 のどちらか一方であり、混在してはならないことに注意してほしい。同様に、ローカル/リモートのポートセレクタ(および ICMP メッセージのタイプとコード、モビリティヘッダのタイプ)は、パケットのフラグメント化によってこれらのフィールドにアクセスできない状況に対応するために、OPAQUE としてラベル付けされてもよい。
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 にマルチキャストアドレスエントリのサポートは含まれない。マルチキャスト SA をサポートするために、実装は [RFC3740] で定義されている Group SPD (GSPD) を利用するべきである。GSPD は異なる構造を必要とする。つまり、マルチキャストコンテキストにおけるユニキャスト SA のためのローカル/リモートアドレス値に対応する対称関係を使用できないということである。具体的にいうと、SA 上のマルチキャストアドレスに向けられたアウトバウンドトラフィックが、送信元としてそのマルチキャストアドレスを持つインバウンド SA 上で受信されることはないということである。
(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 "フラグメントの扱い" 参照)。
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 つの形式のいずれかである：
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 を説明している。残念ながら、この文書と同時期に公開されているバージョンの IKEv2 の動作は、この SPD のために定義されている動作と正確には一致しない。具体的に言うと IKEv2 は、単一 SA にローカルとリモートとのアドレス/ポートを複数組バインドした単一の SA の交渉を許可していない。その代わりに、ひとつの SA のためにローカルとリモートとのアドレス/ポートが複数交渉されたとき、IKEv2 はそれらを組としては扱わず、任意に組み合わせられるローカルとリモートとの値の(順序付けられていない)集合として扱う。(下記で説明する)セレクタの集合を通して SPD の中で表現される動作を伝える機能を IKE が提供するまで、ユーザーは、アクセスコントロールの意図が IKE の "組み合わせに一致する(mix and match)" 動作と一致するのではない限り、単独の SPD エントリ内に複数のセレクタ集合を含めてはならない(MUST NOT)。ユーザーが複数のセレクタ集合を持つ SPD エントリを生成しようとした場合、実装はこの問題を警告するために、現在の IKE の動作と矛盾する可能性のある構文であることを警告してもよい(MAY)。
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 セレクタの "名称(Name)" と混同してはならない。) リモート/ローカルは IP アドレスとポートとだけに適用され、ICMP メッセージのタイプ/コード、モビリティヘッダのタイプには適用されないことに注意してほしい。また、あるセレクタタイプが予約済みのセレクタ値である 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 は順序付けられたエントリのリストであり、各エントリは以下のフィールドを含む。
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. 注意：セレクタ集合エントリの中で "上位プロトコル(next protocol)" は、(ローカル/リモートの IP アドレスとは異なり)独立した値である。これは、IKEv2 が SA のためのトラフィックセレクタ(TS)を交渉する方法と一貫性を持つ。異なるプロトコルを異なるポートと関連付ける必要があるかもしれないという点でも、これは理にかなっている。SA に対して複数のセレクタ集合を指定することで、単一の SA を複数のプロトコル(およびポート)に関連付けることができる。
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. 上位層プロトコル(Next Layer Protocol)のヘッダ内のフィールドに対して、しばしば追加のセレクタが関連付けられる。特定の上位層プロトコル(Next Layer Protocol)は、ゼロ個またはひとつ、または二つのセレクタを持つことができる。上位層プロトコル(Next Layer Protocol)によっては、フィールドのためのローカル/リモートのセレクタが両方とも存在するわけではない状況もありうる。IPv6 のモビリティヘッダはモビリティヘッダメッセージタイプだけを持つ。AH および ESP は追加のセレクタフィールドを持たない。システムは、自身が受け取ることを望まない ICMP メッセージのタイプとコードとを送信したい場合がある。以下の説明において "ポート(port)" は、上位層プロトコル(Next Layer Protocol)に依存するフィールドを表すために使用されている。
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 エントリは次のようにセットされるだろう：
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 エントリは以下のようにセットされるだろう：
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 traceroute の送信を許可したいが、外部のシステムから背後のシステムへの ICMP traceroute の実行は許可したくない場合、対応する SPD エントリにおいてそのセキュリティゲートウェイのトラフィックセレクタは、次のようにセットされる：
In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA. (See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.) The following parameters are associated with each entry in the SAD. They should all be present except where otherwise noted, e.g., AH Authentication algorithm. This description does not purport to be a MIB, only a specification of the minimal data items required to support an SA in an IPsec implementation. 各 IPsec 実装には名目上のセキュリティアソシエーションデータベース(SAD)が存在し、その中で各エントリはひとつの SA に対応するパラメータを定義する。各 SA はその SAD の中にエントリを持つ。アウトバウンド処理の場合、各 SAD エントリは SPD キャッシュの SPD-S 部の中のエントリによって示される。インバウンド処理の場合、ユニキャスト SA のための SPI は、SA を検索するために単独で、または IPsec プロトコルの種別と連結して使用される。IPsec 実装がマルチキャストをサポートしている場合、SA を検索するためには、SPI に宛先アドレスを加えて、または SPI に宛先アドレスと送信元アドレスとを加えて使用される。(インバウンドの IPsec データグラムを SA にマッピングするために使用されなければならない(MUST)アルゴリズムについては、セクション 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 が生成された時点で交渉された値を最初に持っていなければならない(MUST)。(既存の SA に対する SPD 変更の影響のガイドラインについては、セクション 4.4.1 の "システム稼動中の SPD 変更の扱い" を参照してほしい。) 受信者にとってこれらの値は、(IPsec 処理後の)インバウンドパケットのヘッダフィールドが、その SA のために交渉されたセレクタ値と一致することを確認するために使用されるものである。したがって SAD は、SA に到着したインバウンドトラフィックのセレクタを確認するキャッシュとして振る舞う。受信者にとってこれは、SA に到着したパケットが その SA のためのポリシーと首尾一貫するかどうかの確認の一部である。(ICMP メッセージのための規則についてはセクション 6 を参照してほしい。) これらのフィールドは、セクション 4.4.1.1 "セレクタ" で説明されている特殊な値の形式、範囲、ANY、OPAQUE を取ることができる。また SAD が、SPD 内のエントリと一致しない SA のためのエントリを持つことができる状況もあることに注意してほしい。この文書は SPD が変更されたときに SAD が選択的にクリアされることを強制しないので、SAD エントリを生成した SPD エントリが変更または削除されても、その SAD エントリを残すことができる。また、手動で鍵化された SA が生成されたとき、その SA に対して、どの SPD エントリにも一致しない 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 の経験に基づく)一部の実装は、この点で問題を持つことが知られている。具体的にいうとは、SPD キャッシュの中に単純に (リモートトンネルヘッダ IP アドレス, リモート SPI) の組を持つだけでは十分ではない。なぜならこの組で単独の SAD エントリを常に一意に識別できるとは限らないためである。例えば、同じ NAT の背後にある二つのホストは同じ SPI 値を取り得る。この状況は、あるホストが使用していた IP アドレスが(例えば DHCP を通して)別のホストに割り当てられ、以前のホストに対応する SA がデッドピア検出メカニズムによってまだ削除されていない場合にも起こる可能性がある。これはパケットを誤った SA に送信したり、あるいは鍵管理がその組の一意性を確保している場合には、別の方法での正当な SA の生成が拒否されたりする要因となる可能性がある。したがって実装者は、このような問題を引き起こさない方法で SPD キャッシュと SAD とのリンクを実装するべきである。
The following data items MUST be in the SAD: SAD 内には以下のデータ項目が存在しなければならない(MUST)：
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 ビットのシーケンス番号にも適応する。
For each selector, the following tables show the relationship between the value in the SPD, the PFP flag, the value in the triggering packet, and the resulting value in the SAD. Note that the administrative interface for IPsec can use various syntactic options to make it easier for the administrator to enter rules. For example, although a list of ranges is what IKEv2 sends, it might be clearer and less error prone for the user to enter a single IP address or IP address prefix. 各セレクタごとの以下のテーブルは、SPD 内の値、 PFP フラグ、きっかけとなるパケットの中の値、結果として生じる SAD 内の値の、それぞれの関係を表す。IPsec のための管理インターフェイスは、管理者が規則を入力するのを簡単にするために、様々な構文上のオプションを使用できることに注意してほしい。例えば、IKEv2 が送信するのが範囲のリストだとしても、ユーザーにとっては単独の IP アドレスまたは IP アドレスのプレフィクスを入力するほうが、より明瞭かつ間違いを犯しにくいだろう。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc addr list of ranges 0 IP addr "S" list of ranges
ANY 0 IP addr "S" ANY
list of ranges 1 IP addr "S" "S"
ANY 1 IP addr "S" "S"
rem addr list of ranges 0 IP addr "D" list of ranges
ANY 0 IP addr "D" ANY
list of ranges 1 IP addr "D" "D"
ANY 1 IP addr "D" "D"
protocol list of prot's* 0 prot. "P" list of prot's*
ANY** 0 prot. "P" ANY
OPAQUE**** 0 prot. "P" OPAQUE
list of prot's* 0 not avail. discard packet
ANY** 0 not avail. ANY
OPAQUE**** 0 not avail. OPAQUE
list of prot's* 1 prot. "P" "P"
ANY** 1 prot. "P" "P"
OPAQUE**** 1 prot. "P" ***
list of prot's* 1 not avail. discard packet
ANY** 1 not avail. discard packet
OPAQUE**** 1 not avail. ***
きっかけとな
ったパケット 結果として生じる
セレクタ SPD エントリ PFP 内の値 SAD エントリ
-------- ---------------- --- ----------------- ----------------
ローカル 範囲のリスト 0 IP アドレス "S" 範囲のリスト
アドレス ANY 0 IP アドレス "S" ANY
範囲のリスト 1 IP アドレス "S" "S"
ANY 1 IP アドレス "S" "S"
リモート 範囲のリスト 0 IP アドレス "D" 範囲のリスト
アドレス ANY 0 IP アドレス "D" ANY
範囲のリスト 1 IP アドレス "D" "D"
ANY 1 IP アドレス "D" "D"
プロトコル プロトコルリスト* 0 プロトコル "P" プロトコル
リスト*
ANY** 0 プロトコル "P" ANY
OPAQUE**** 0 プロトコル "P" OPAQUE
プロトコルリスト* 0 利用不可 パケットを破棄
ANY** 0 利用不可 ANY
OPAQUE**** 0 利用不可 OPAQUE
プロトコルリスト* 1 プロトコル "P" "P"
ANY** 1 プロトコル "P" "P"
OPAQUE**** 1 プロトコル "P" ***
プロトコルリスト* 1 利用不可 パケットを破棄
ANY** 1 利用不可 パケットを破棄
OPAQUE**** 1 利用不可 ***
If the protocol is one that has two ports, then there will be selectors for both Local and Remote ports. プロトコルが二つのポートを使用する場合、ローカルとリモートとの両方のポートのためのセレクタが存在することになる。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
loc port list of ranges 0 src port "s" list of ranges
ANY 0 src port "s" ANY
OPAQUE 0 src port "s" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 src port "s" "s"
ANY 1 src port "s" "s"
OPAQUE 1 src port "s" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
rem port list of ranges 0 dst port "d" list of ranges
ANY 0 dst port "d" ANY
OPAQUE 0 dst port "d" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 dst port "d" "d"
ANY 1 dst port "d" "d"
OPAQUE 1 dst port "d" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
きっかけとな
ったパケット 結果として生じる
セレクタ SPD エントリ PFP 内の値 SAD エントリ
-------- ---------------- --- ----------------- ----------------
ローカル 範囲のリスト 0 送信元ポート "s" 範囲のリスト
ポート ANY 0 送信元ポート "s" ANY
OPAQUE 0 送信元ポート "s" OPAQUE
範囲のリスト 0 利用不可 パケットを破棄
ANY 0 利用不可 ANY
OPAQUE 0 利用不可 OPAQUE
範囲のリスト 1 送信元ポート "s" "s"
ANY 1 送信元ポート "s" "s"
OPAQUE 1 送信元ポート "s" ***
範囲のリスト 1 利用不可 パケットを破棄
ANY 1 利用不可 パケットを破棄
OPAQUE 1 利用不可 ***
リモート 範囲のリスト 0 宛先ポート "d" 範囲のリスト
ポート ANY 0 宛先ポート "d" ANY
OPAQUE 0 宛先ポート "d" OPAQUE
範囲のリスト 0 利用不可 パケットを破棄
ANY 0 利用不可 ANY
OPAQUE 0 利用不可 OPAQUE
範囲のリスト 1 宛先ポート "d" "d"
ANY 1 宛先ポート "d" "d"
OPAQUE 1 宛先ポート "d" ***
範囲のリスト 1 利用不可 パケットを破棄
ANY 1 利用不可 パケットを破棄
OPAQUE 1 利用不可 ***
If the protocol is mobility header, then there will be a selector for mh type. プロトコルがモビリティヘッダの場合、mh タイプのためのセレクタが存在することになる。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
-------- ---------------- --- ------------ --------------
mh type list of ranges 0 mh type "T" list of ranges
ANY 0 mh type "T" ANY
OPAQUE 0 mh type "T" OPAQUE
list of ranges 0 not avail. discard packet
ANY 0 not avail. ANY
OPAQUE 0 not avail. OPAQUE
list of ranges 1 mh type "T" "T"
ANY 1 mh type "T" "T"
OPAQUE 1 mh type "T" ***
list of ranges 1 not avail. discard packet
ANY 1 not avail. discard packet
OPAQUE 1 not avail. ***
きっかけとな
ったパケット 結果として生じる
セレクタ SPD エントリ PFP 内の値 SAD エントリ
-------- ---------------- --- ----------------- ----------------
mh タイプ 範囲のリスト 0 mh タイプ "T" パケットを破棄
ANY 0 mh タイプ "T" ANY
OPAQUE 0 mh タイプ "T" OPAQUE
範囲のリスト 0 利用不可 パケットを破棄
ANY 0 利用不可 ANY
OPAQUE 0 利用不可 OPAQUE
範囲のリスト 1 mh タイプ "T" "T"
ANY 1 mh タイプ "T" "T"
OPAQUE 1 mh タイプ "T" ***
範囲のリスト 1 利用不可 パケットを破棄
ANY 1 利用不可 パケットを破棄
OPAQUE 1 利用不可 ***
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 ビットセレクタが含むことができるのは、単一のタイプとコードの範囲、単一のタイプとコード ANY、タイプ ANY とコード ANY である。
Value in
Triggering Resulting SAD
Selector SPD Entry PFP Packet Entry
--------- ---------------- --- ------------ --------------
ICMP type a single type & 0 type "t" & single type &
and code range of codes code "c" range of codes
a single type & 0 type "t" & single type &
ANY code code "c" ANY code
ANY type & ANY 0 type "t" & ANY type &
code code "c" ANY code
OPAQUE 0 type "t" & OPAQUE
code "c"
a single type & 0 not avail. discard packet
range of codes
a single type & 0 not avail. discard packet
ANY code
ANY type & 0 not avail. ANY type &
ANY code ANY code
OPAQUE 0 not avail. OPAQUE
a single type & 1 type "t" & "t" and "c"
range of codes code "c"
a single type & 1 type "t" & "t" and "c"
ANY code code "c"
ANY type & 1 type "t" & "t" and "c"
ANY code code "c"
OPAQUE 1 type "t" & ***
code "c"
a single type & 1 not avail. discard packet
range of codes
a single type & 1 not avail. discard packet
ANY code
ANY type & 1 not avail. discard packet
ANY code
OPAQUE 1 not avail. ***
きっかけとな
ったパケット 結果として生じる
セレクタ SPD エントリ PFP 内の値 SAD エントリ
-------- ---------------- --- ----------------- ----------------
ICMP 単一のタイプ & 0 タイプ "t" & 単一のタイプ &
タイプと コードの範囲 コード "c" コードの範囲
コード 単一のタイプ & 0 タイプ "t" & 単一のタイプ &
ANY コード コード "c" ANY コード
ANY タイプ & 0 タイプ "t" & ANY タイプ &
ANY コード コード "c" ANY コード
OPAQUE 0 タイプ "t" & OPAQUE
コード "c"
単一のタイプ & 0 利用不可 パケットを破棄
コードの範囲
単一のタイプ & 0 利用不可 パケットを破棄
ANY コード
ANY タイプ & 0 利用不可 ANY タイプ &
ANY コード ANY コード
OPAQUE 0 利用不可 OPAQUE
単一のタイプ & 1 タイプ "t" & "t" と "c"
コードの範囲 コード "c"
単一のタイプ & 1 タイプ "t" & "t" と "c"
ANY コード コード "c"
ANY タイプ & 1 タイプ "t" & "t" と "c"
ANY コード コード "c"
OPAQUE 1 タイプ "t" & ***
コード "c"
単一のタイプ & 1 利用不可 パケットを破棄
コードの範囲
単一のタイプ & 1 利用不可 パケットを破棄
ANY コード
ANY タイプ & 1 利用不可 パケットを破棄
ANY コード
OPAQUE 1 利用不可 ***
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 エントリ PFP 内の値 SAD エントリ
-------- ---------------- --- ----------------- --------------
名称 ユーザーまたは N/A N/A N/A
システム名の
リスト
* "プロトコルリスト" は情報であり、SPD または SAD
または IKEv2 がこの情報を示さなければならない手段ではない。
** 0 (ゼロ) はプロトコルの ANY を表すために IKE によって使用さ
れる。
*** 値 OPAQUE と共に PFP=1 を使用するのは誤りであり、IPsec 実装
はそれを禁止するべきである(SHOULD)。
**** IPv4 ではプロトコルフィールドを OPAQUE にすることはできない。
この表は 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 など)との間のひも付けを提供する。これはいくつかの重要な機能を具体化する：
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. また各エントリは、チャイルド SA が生成されるときに、IKE の ID ペイロードが SPD 検索のためのシンボル名として使用されるかどうか、またはトラフィックセレクタのペイロード内で提供されるリモート IP アドレスが SPD 検索に使用されるかどうかを指定する。
Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints. PAD の情報は、二つのピア間で同時に二つ以上のトンネルモード SA の生成をサポートするために使用されてもよい(MAY)ことに注意してほしい(例えば、異なるトンネルエンドポイントを持つ同一のアドレス/ホストを保護するための二つのトンネル)。
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 は順序付けられたデータベースであり、その順序は管理者(またはシングルユーザーのエンドシステムの場合はユーザー)によって定義される。PAD と SPD は協調しなければならないため、通常は同じ管理者が両方に責任を持つことになる。PAD のための順序付けの要求事項は、SPD のためと同じ理由により生じる。つまり、特定のエントリに一致し得る IKE ID の集合において "星の名前(star name)" のエンティティが重複して使用されることが許可されているためである。
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: PAD におけるエントリには 6 種類の ID がサポートされており、SPD エントリを識別するために使用される識別名種別と IP アドレスとの整合性を持つ。各エントリの ID は PAD のためのインデックス、つまり、エントリを選択するために使用される値としての役目を果たす。これらの ID 種別はすべて、IKE ID ペイロード種別と一致させるために使用できる。6 種類は以下の通り：
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" は、この二つのドメイン名要素で終了する任意の 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). 同じように識別名(Distinguished Name)も、厳密にひとつのエントリと一致する完全な識別名(例えば CN = Stephen, O = BBN Technologies, SP = MA, C = US)を指定することができる。あるいはサブツリーを指定することでピアのグループを含めることもできる。例えば "C = US, SP = MA" というエントリは、最上層の相対識別名(RDN)としてこれら二つの属性を含むすべての DN と一致させるために使用できるだろう。
For an RFC 822 e-mail addresses, the same options exist. A complete address such as [email protected] 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 電子メールアドレスにも同様の選択肢がある。[email protected] などの完全なアドレスはひとつのエンティティと一致するが、"@example.com" などのサブツリー名は、@ の右側がこれら二つのドメイン名で終わる名前を持つすべてのエンティティと一致させるために使用できる。
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 電子メールアドレスのサブツリー一致に対応するために実装が使用する個別の構文は、ローカルの問題である。ただし最低でも上記のようなサブツリー検索はサポートされなければならない(MUST)。(DN・DNS 名・RFC 822 アドレスにおける部分文字列検索がサポートされてもよい(MAY)が、必須ではない。)
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 エントリのために使用される同じアドレス範囲の構文がサポートされなければならない(MUST)。この構文は、(通常の範囲による)独立したアドレス、(CIDR 形式のプレフィクスにしたがう範囲指定による)アドレスプレフィクス、または任意のアドレス範囲を指定可能である。
The Key ID field is defined as an OCTET string in IKE. For this name type, only exact-match syntax MUST be supported (since there is no explicit structure for this ID type). Additional matching functions MAY be supported for this ID type. キー ID フィールドは IKE において OCTET 文字列として定義される。この名前種別には完全一致の構文のみがサポートされなければならない(MUST)(ID には明示的な構造がないためである)。この ID のために付加的な一致機能がサポートされてもよい(MAY)。
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types: いったん ID フィールド一致に基づく順序検索によりエントリが位置付けされると、表明された身元を検証する(つまり表明された ID を認証する)必要がある。各エントリごとに、実行されるべき認証の種類の指示がある。この文書は二つの必須認証データ種別のサポートを要求する：
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 リポジトリのリスト、および対応する認証情報)を含んでもよい(MAY)。事前共有秘密に基づく認証の場合、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 と証明書におけるサブジェクト名またはサブジェクト別名との間の一致を管理者が要求できる手段を提供しなければならない(MUST)。前者は識別名として表された 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. この文書は他の認証方法を強制しないが、他の認証方法を採用してもよい(MAY)。
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 エントリは、IKE ピアが提示することのできる ID の集合を、SPD に対して一致するように制限するための情報を含む。各 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 の集合を定義する。エントリによりチャイルド SA のトラフィックセレクタが使用されるべきであると示されている場合、IPv4 かつ/または IPv6 のアドレス範囲を表す追加の情報が要求される。(ピアに両方の種類のアドレスを付与されている可能性があるため、v4 および v6 の両方のアドレス範囲を提供しなければならない(MUST)。)
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. 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 ペイロードにより身元を提示し、その身元を検証するための AUTH ペイロードを送信する。提示された身元ごとの検証を手助けするために、ひとつ以上の CERT ペイロードが送信されてよい。IKE ID ペイロードを受信した IKE エンティティは、前述の一致規則を使用して 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. 最初の IKE 交換の終了時、または後続の CREATE_CHILD_SA 交換の間に、チャイルド SA はトラフィックセレクタのペイロードの交換に基づいて生成される。(この時点で認証済みの)IKE ピアのための PAD エントリは、チャイルド SA の生成を抑制するために使用される：具体的にいうと、PAD エントリはピアから提示されたトラフィックセレクタを使用して SPD が検索される方法を特定する。二つの選択肢がある：シンボル名によって SPD エントリを見つけるために、ピアの提示した IKE ID が使用されるか、SPD エントリのリモート IP アドレスフィールドに基づいて SPD を検索するために、トラフィックセレクタのペイロード内で提示されたピアの IP アドレスが使用されるかである。認証済みのピアが他の正当なピアの 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. SPD エントリを検索する前に PAD がチェックされるため、この保護手段はイニシエータをなりすまし攻撃から保護する。例えば IKE A が、セキュリティゲートウェイであるホストの IP アドレス X に宛てたアウトバウンドパケットを受信したと仮定する。RFC 2401 [RFC2401] およびこの文書は、X を持つ IKE ピアのアドレスを決定する方法を規定しない。しかしながら、X のための代表と推定される A が連絡を取るするすべてのピアは、認証されるための IKE 交換を許可するために PAD に登録されなければならない。そのうえ、認証済みのピアがトラフィックセレクタ交換の中で X であると表明する場合、PAD は問題のピアが 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 と暗号鍵管理とをサポートしなければならない(MUST)。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 とによるアンチリプレイ機能の利用を手助けしたり、オンデマンドによる SA の生成(例えばユーザー指向またはセッション指向の鍵化)に対応したりするために必要である。(SA の "再鍵化(rekeying)" という表記は、実際には新しい 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 管理プロトコルを採用してもよい(MAY)。
When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two SAs created by IKE. If both integrity and confidentiality are employed, then a minimum of four keys are required. Additionally, some cryptographic algorithms may require multiple keys, e.g., 3DES. 自動的な SA/鍵管理プロトコルが採用された場合、このプロトコルからの出力は、単一の SA に対して複数の鍵を生成するために使用される。またこれは、IKE によって生成される二つの SA のために個別の鍵が使用される場合にもあてはまる。完全性と機密性とを両方採用する場合、最低でも 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. 鍵管理システムは、それぞれの鍵ごとに個別のビット文字列を提供するか、すべての鍵が抽出されるひとつのビット文字列を生成することができる。単一のビット文字列が提供される場合、SA の両端においてそのビット文字列を要求された鍵にマップするシステムの部分同士が、同じ方法でマッピングすることを保証するように注意する必要がある。SA の両端の IPsec 実装が同じ鍵のために同じビット群を使用し、システムの無関係の部分がそのビット文字列を個別の鍵に分割することを保証するために、暗号鍵は最初の(最左あるいは上位の)ビットから採取されなければならず(MUST)、完全性鍵は残りのビットから採取されなければならない(MUST)。各鍵のビット数は、それぞれ対応する暗号アルゴリズム仕様の RFC において定義される。複数の暗号鍵または複数の完全性鍵の場合、暗号アルゴリズムの仕様は、その暗号アルゴリズムに提供された単一のビット文字列から抽出する順序を規定しなければならない。
This section discusses issues relating to how a host learns about the existence of relevant security gateways and, once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter, but the Peer Authorization Database (PAD) described in Section 4.4 is the most likely candidate. (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 below.) このセクションでは、ホストが自身に関係のあるセキュリティゲートウェイについて知る方法と、ホストがセキュリティゲートウェイに接触した後でそれらが正しいセキュリティゲートウェイであることを知る方法とに関連する問題を議論する。必要な情報が保存される場所の詳細はローカルの問題だが、セクション 4.4 で説明されているピア権限データベース(PAD)がもっとも有望な候補である。(注意： S* (SH1 や SG2 など)は IPsec を実行中のシステムを表す。)
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host crossing the Internet to his home organization's firewall (SG2). This situation raises several issues: リモートホスト(SH1)がサーバーまたは別のマシン(H1)へアクセスするためにインターネットを使用しており、セキュリティゲートウェイ(SG2)(例えば H1 のトラフィックが通過しなければならないファイアウォール)が存在している状況を考える。この状況の一例は、インターネットを通して自組織のファイアウォール(SG2)に接続するモバイルホストだろう。この状況はいくつかの問題を提起する：
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 をサポートするホストまたはセキュリティゲートウェイは、ユーザー/管理者がその利用に必要となる宛先アドレス範囲に対してひとつ以上のセキュリティゲートウェイのアドレスを構成することのできる管理インターフェイスを持たなければならない(MUST)。これには、ひとつ以上のセキュリティゲートウェイの検索と認証、またそれらのゲートウェイに宛先ホストの代理を務める権限があることを検証するための情報を構成する能力が含まれる。(認証機能は 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)を使用するべきである(SHOULD)。このような環境において受信者は、メッセージがそのマルチキャストグループ用の鍵を処理しているシステムから来たということだけを知る。一般にこのような環境において受信者は、どのシステムがマルチキャストトラフィックを送信したのかを認証することができないだろう。より一般的な他のマルチキャストアプローチのための仕様は、IETF Mutlicast Security Working Group にしたがう。
As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA. Note, however, exceptions arise when one uses multiple SAs to carry traffic of different priorities (e.g., as indicated by distinct DSCP values) but the same selectors. Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry. セクション 4.4.1 "セキュリティポリシーデータベース(SPD)" で述べた通り、IPsec 保護境界を通過する IPsec 管理トラフィックを含むすべてのトラフィックの処理において、SPD(または関連キャッシュ)が参照されなければならない(MUST)。あるパケットに一致する(インバウンドまたはアウトバウンドのトラフィックのどちらかの)ポリシーが SPD 内に見つからない場合、そのパケットは破棄されなければならない(MUST)。処理を簡単にするために、また(SG/BITS/BITW による)高速な SA 検索を可能にするために、この文書は、すべてのアウトバウンドトラフィックのための SPD キャッシュの概念(SPD-O と SPD-S)と、IPsec による保護を受けないインバウンドトラフィックのための SPD キャッシュの概念(SPD-I)とを導入する。(前述の通り、SAD は SA に到達した IPsec 保護を受けるインバウンドトラフィックのセレクタを確認するためのキャッシュとして振る舞う。) 名目上、SPD ごとにひとつのキャッシュが存在する。この仕様のためには、キャッシュされた各エントリは正確にひとつの SA にマップされると仮定する。しかしながら、(例えば異なる DSCP 値によって表される)異なる優先度で同じセレクタのトラフィックを運ぶために複数の SA を使用する場合の例外に注意してほしい。また、関連するエントリを SPD 内に持たない SA のためのエントリを SAD が保持できる状況があることにも注意してほしい。この文書は SPD が変更されたときに SAD が選択的にクリアされることを強制しないので、SAD エントリを生成した SPD エントリが変更または削除されても、その SAD エントリを残すことができる。また、手動で鍵化された SA が生成されたとき、その SA に対して、どの SPD エントリにも対応しない 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. 注意：これは相関 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.
非保護側インターフェイス
^
|
(ネスト化された SA) +----------+
-------------------| 転送 |<-----+
| +----------+ |
| ^ |
| | BYPASS |
V +-----+ |
+-------+ | SPD | +--------+
...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
| (*) | | (*) |---->|(AH/ESP)| 境界
+-------+ +-----+ +--------+
| +-------+ / ^
| |DISCARD| <--/ |
| +-------+ |
| |
| +-------------+
|---------------->| SPD 選択 |
+-------------+
^
| +------+
| -->| ICMP |
| / +------+
|/
|
|
保護側インターフェイス
図 2. アウトバウンドトラフィックの処理モデル
(*) = この部分に SPD キャッシュが現れる。
キャッシュミスが発生した場合、SPD が
確認される。
キャッシュミスが発生した場合、実装が
パケットをバッファリングする必要はない。
IPsec MUST perform the following steps when processing outbound packets: アウトバウンドパケットを処理するとき、IPsec は以下の手順を実行しなければならない(MUST)。
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 の適用前にパケットをフラグメント化してよい(MAY)。(これは IPv4 にのみ適用される。IPv6 におけるパケットのフラグメント化は送信者にのみ許可されている。) デバイスはこれを無効化する設定を持つべきである(SHOULD)。この結果として生じるフラグメントは 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 で説明されている手順にしたがわなければならない(MUST)。
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 メッセージを生成・送信する能力を持つべきである(SHOULD)。その場合の ICMP メッセージのタイプとコードはパケットが破棄された理由に依存する(以下に示す)。破棄の理由は監査ログに記録されるべきである(SHOULD)。このイベントのための監査ログエントリは、その理由、現在の日付/時刻、そのパケットに由来するセレクタ値を含むべきである(SHOULD)。
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 メッセージを W.X.Y.Z に送らせるパケットを送信することができる。これは、セキュリティゲートウェイの背後のホストの間でサービス不能(DoS)攻撃の機会を与えることになる。これを解決するために、セキュリティゲートウェイはこのような環境下で IPsec 実装が ICMP メッセージを送信するかしないかを管理者が設定できる管理制御機能を持つべきである(SHOULD)。
This section describes the handling of the inner and outer IP headers, extension headers, and options for AH and ESP tunnels, with regard to outbound traffic processing. This includes how to construct the encapsulating (outer) IP header, how to process fields in the inner IP header, and what other actions should be taken for outbound, tunnel mode traffic. The general processing described here is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]: このセクションでは、アウトバウンドトラフィック処理に関連して、AH および ESP トンネルのためのインナーおよびアウターの IP ヘッダ・拡張ヘッダ・オプションの扱いを説明する。これには、カプセル化する(アウター) IP ヘッダを構築する方法、インナー IP ヘッダ内のフィールドを処理する方法、アウトバウンドのトンネルモードトラフィックのために採られるべき他のアクションが含まれる。ここで記述されている一般的な処理は、RFC 2003 "IP Encapsulation within IP" [Per96] を手本にしている。
Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2003 [Per96]) in several ways: 注意：IPsec のトンネルモードは、いくつかの点で IP-in-IP トンネリング(RFC 2003 [Per96])と異なる：
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). 以下のサブセクションの表は、異なるヘッダ/オプションの扱いを示している("生成(constructed)" は、外側のフィールドの値が内側のフィールドの値から独立して構成されることを意味する)。
<-- 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
<-- アウターヘッダとインナーヘッダとの関連 -->
カプセル化する側の カプセル化を解除する
IPv4 アウターヘッダ 側のインナーヘッダ
ヘッダフィールド: -------------------- ------------
version 4 (1) 変更なし
header length 生成 変更なし
DS Field 内側のヘッダからコピー(5) 変更なし
ECN Field 内側のヘッダからコピー 生成 (6)
total length 生成 変更なし
ID 生成 変更なし
flags (DF,MF) 生成, DF (4) 変更なし
fragment offset 生成 変更なし
TTL 生成 (2) デクリメント (2)
protocol AH, ESP 変更なし
checksum 生成 生成 (2)(6)
src address 生成 (3) 変更なし
dest address 生成 (3) 変更なし
オプション コピーされない 変更なし
Notes: 注記：
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. 注意：TTL 値をデクリメントするのは通常のパケット転送処理の一環である。したがって、カプセル化するノード自身からパケットが発信された場合、その送信ノードはパケットを発信したのであって転送したのではないため、TTL のデクリメントは行われない。これはホストとルータとにおける BITS およびネイティブの IPsec 実装に適用される。しかしながら IPsec の処理モデルには外部の転送機能も含まれる。構成間違いなどによるパケットのループを防止するために、TTL 処理はその処理モデルの枠内で使用できる。
Note: For multicast traffic, the destination address, or source and destination addresses, may be required for demuxing. In that case, it is important to ensure consistency over the lifetime of the SA by ensuring that the source address that appears in the encapsulating tunnel header is the same as the one that was negotiated during the SA establishment process. There is an exception to this general rule, i.e., a mobile IPsec implementation will update its source address as it moves. 注意：マルチキャストトラフィックの場合、宛先アドレス、または送信元・宛先アドレスが、分離のために必要とされる可能性がある。その場合、カプセル化するトンネルのヘッダ内に現れる送信元アドレスが SA の確立中に交渉されたものと同じであることを保証することで、SA の存続期間を通して一貫性を保証することが重要である。ただしこの一般的規則には例外がある。例えば モバイルの IPsec 実装は、その移動にともなって送信元アドレスを更新するたろう。
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 実装がアウターヘッダのオプションを追加/生成してもよい(MAY)。
<-- 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
<-- アウターヘッダとインナーヘッダとの関連 --->
カプセル化する側の カプセル化を解除する
IPv6 アウターヘッダ 側のインナーヘッダ
ヘッダフィールド: -------------------- ------------
version 6 (1) 変更なし
DS Field 内側のヘッダからコピー(5) 変更なし (9)
ECN Field 内側のヘッダからコピー 生成 (6)
flow label コピーまたは生成 (8) 変更なし
payload length 生成 変更なし
next header AH,ESP,ルーティングヘッダ 変更なし
hop limit 生成 (2) デクリメント (2)
src address 生成 (3) 変更なし
dest address 生成 (3) 変更なし
拡張ヘッダ コピーされない (7) 変更なし
Notes: 注意：
Inbound processing is somewhat different from outbound processing, because of the use of SPIs to map IPsec-protected traffic to SAs. The inbound SPD cache (SPD-I) is applied only to bypassed or discarded traffic. If an arriving packet appears to be an IPsec fragment from an unprotected interface, reassembly is performed prior to IPsec processing. The intent for any SPD cache is that a packet that fails to match any entry is then referred to the corresponding SPD. Every SPD SHOULD have a nominal, final entry that catches anything that is otherwise unmatched, and discards it. This ensures that non-IPsec-protected traffic that arrives and does not match any SPD-I entry will be discarded. インバウンドの処理は IPsec 保護トラフィックを SA にマッピングするために SPI を使用するため、アウトバウンドの処理とは若干異なる。インバウンド SPD キャッシュ (SPD-I) は、バイパスされるトラフィックまたは破棄されるトラフィックにのみ適用される。到着したパケットが非保護側インターフェイスからの IPsec フラグメントと考えられる場合、IPsec 処理の前に再構築が行われる。すべての SPD キャッシュの目的は、どのエントリにも一致しないパケットが、その後に対応する SPD を参照されることである。すべての SPD は、他に一致しないすべてを受け入れて破棄する名目上の最終エントリを持つべきである(SHOULD)。これにより、どの 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
(*) = 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.
非保護側インターフェイス
|
V
+-----+ IPsec 保護
------------------->|分離 |-------------------+
| +-----+ |
| | |
| IPsec 以外 | |
| | |
| V |
| +-------+ +---------+ |
| |DISCARD|<---|SPD-I (*)| |
| +-------+ +---------+ |
| | |
| |-----+ |
| | | |
| | V |
| | +------+ |
| | | ICMP | |
| | +------+ |
| | V
+---------+ | +-----------+
....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
+---------+ | | (AH/ESP) | 境界
^ | +-----------+
| | +---+ |
| BYPASS | +-->|IKE| |
| | | +---+ |
| V | V
| +----------+ +---------+ +----+
|--------<------| 転送 |<---------|SAD 確認|-->|ICMP|
ネスト SAs +----------+ | (***) | +----+
| +---------+
V
保護側インターフェイス
図 3. インバウンドトラフィックの処理モデル
(*) = キャッシュはここに現れる。キャッシュミ
スが発生した場合、次に SPD が確認される。
キャッシュミスが発生した場合、実装が
そのパケットをバッファする必要はない。
(**) = この処理には、SAD (インバウンドパケットの
ための SPD キャッシュを形成する)内の SA
を検索するために、パケットの SPI を使用す
る動作が含まれる(セクション 4.4.2 および
5 の注記の場合を除く)。
下記のステップ 3a 参照。
(***) = この SAD 確認は下記のステップ 4 を表す。
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). 非保護側インターフェイスから到達したすべての IP フラグメントは、AH または ESP の処理の実行前に、IP によって再構築される。IPsec 処理を適用される各インバウンド IP データグラムは、IP の Next Protocol フィールド内の AH または ESP を表す値(または IPv6 コンテキストにおける上位層プロトコルとして AH または ESP を表す値)によって識別される。
IPsec MUST perform the following steps: IPsec は以下のステップを実行しなければならない(MUST)：
To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure the IPsec implementation to send or not send this IKE notification, and if this facility is selected, to rate limit the transmission of such notifications. IPsec システムは DoS 攻撃や間違って設定されたピアによる影響を最小限にするために、IPsec 実装がこの IKE 通知を送信するかどうか、またこの機能が選択された場合には、そのような通知の送信帯域を管理者が制限できる管理制御機能を持つべきである(SHOULD)。
After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition. This function may cause the packet to be sent (outbound) across the IPsec boundary for additional inbound IPsec processing, e.g., in support of nested SAs. If so, then as with ALL outbound traffic that is to be bypassed, the packet MUST be matched against an SPD-O entry. Ultimately, the packet should be forwarded to the destination host or process for disposition. トラフィックがバイパスされるか IPsec を通して処理された後、トラフィックは処理のためにインバウンド転送機能に渡される。追加のインバウンド IPsec 処理(例えばネスト化された SA のサポート)のために、この機能はパケットを IPsec 境界を超えて(アウトバウンド側に)送信してもよい。その場合、バイパスされるすべてのアウトバウンドトラフィックと同様に、パケットは SPD-O エントリに対して検索されなければならない(MUST)。最終的にパケットは、宛先ホスト、または処理のためのプロセスへと転送されなければならない。
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 トラフィックには二つのカテゴリが存在する：エラーメッセージ(例 タイプ = 宛先到達不能(destination unreachable))と、非エラーメッセージ(例 タイプ = エコー(echo))である。このセクションはエラーメッセージにのみ適用される。(IPsec 実装自身に向けられたものではない)非エラーの ICMP メッセージの処理には、SPD エントリを使用することを明示的に示さなければならない(MUST)。
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. このセクションの議論は ICMPv4 だけでなく ICMPv6 にも適用される。また問題分析の手助けとして、ICMP エラーメッセージがログに残るように管理者が設定(選択的(selected)、すべて(all)、無し(none))できるメカニズムを提供するべきである(SHOULD)。
Figure 3 in Section 5.2 shows a distinct ICMP processing module on the unprotected side of the IPsec boundary, for processing ICMP messages (error or otherwise) that are addressed to the IPsec device and that are not protected via AH or ESP. An ICMP message of this sort is unauthenticated, and its processing may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus, there is also a motivation for accepting and acting upon unauthenticated ICMP messages. セクション 5.2 の図 3 には、IPsec 境界の非保護側に独立した ICMP 処理モジュールが示されている。これは、IPsec デバイスに向けられ、AH または ESP による保護を受けていない ICMP メッセージ(エラーまたはそれ以外)を処理するためのものである。この種の ICMP メッセージは認証されておらず、その処理はサービス不能、またはサービス低下を引き起こす可能性がある。これは、一般にその種のメッセージを無視するのが望ましいことを意味している。しかしながら多くの ICMP メッセージは、未認証の送信元(例えば公共のインターネット上のルータ)からホストまたはセキュリティゲートウェイによって受信される。これらの ICMP メッセージを無視することは、例えば PMTU メッセージやリダイレクトメッセージの処理を行わないことになるため、サービス低下を起こし得る。したがって、未認証の ICMP メッセージを受け入れ、それに基づいて動作することへの動機も存在する。
To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size. 準拠する IPsec 実装はこの両極の状況に適応するために、IPsec 実装が未認証の ICMP トラフィックを受け入れるか拒否するかを、ローカルの管理者が設定することを許可しなければならない(MUST)。この制御の粒度は ICMP のタイプごとでなければならず(MUST)、ICMP のタイプとコードとごとであってもよい(MAY)。さらに実装は、そのようなトラフィックを扱うためのメカニズムとパラメータとを組み入れるべきである(SHOULD)。例えば、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 メッセージが前述の確認をパスし、システムがそれを受け入れるように構成されている場合、二つの可能性がある。実装が境界の暗号側にフラグメント化を適用する場合、受け入れられた PMTU 情報は転送モジュール(IPsec 実装の外部)へと渡され、転送モジュールはアウトバウンドパケットのフラグメント化を管理するためにそれを使用する。実装が平文側のフラグメント化に影響するように構成されている場合、PMTU 情報は平文側に渡され、セクション 8.2 で説明されている通りに処理される。
These ICMP messages are not authenticated, but they do come from sources on the protected side of the IPsec boundary. Thus, these messages generally are viewed as more "trustworthy" than their counterparts arriving from sources on the unprotected side of the boundary. The major security concern here is that a compromised host or router might emit erroneous ICMP error messages that could degrade service for other devices "behind" the security gateway, or that could even result in violations of confidentiality. For example, if a bogus ICMP redirect were consumed by a security gateway, it could cause the forwarding table on the protected side of the boundary to be modified so as to deliver traffic to an inappropriate destination "behind" the gateway. Thus, implementers MUST provide controls to allow local administrators to constrain the processing of ICMP error messages received on the protected side of the boundary, and directed to the IPsec implementation. These controls are of the same type as those employed on the unprotected side, described above in Section 6.1.1. これらの ICMP メッセージは認証されていないが、IPsec 境界の保護側の送信元からも来る。したがって一般にこれらのメッセージは、IPsec 境界の非保護側の送信元から来たメッセージより "信頼できる(trustworthy)" ものと見なされる。この場合の主要なセキュリティ問題は、障害を起こしたホストまたはルータが間違った ICMP エラーメッセージを発行し、その結果、そのセキュリティゲートウェイの "背後にある(behind)" 他のデバイスに対するサービスを低下させたり、機密性違反さえ引き起こす可能性があることである。例えば、偽造された ICMP リダイレクトがセキュリティゲートウェイによって処理された場合、IPsec 境界の保護側の転送テーブルが、そのゲートウェイの "背後にある(behind)" 不適切な宛先にトラフィックを配送するように修正される可能性がある。したがって実装は、IPsec 境界の保護側で受信し IPsec 実装に向けられた ICMP エラーメッセージの処理を、ローカルの管理者が抑制することを許可しなければならない(MUST)。これらの制御は、セクション 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 エラーメッセージが SA を通して IPsec 実装の "背後にある(behind)" デバイスに送信された場合、その ICMP メッセージのペイロードもヘッダも、アクセスコントロールの観点から確認されなければならない。これらのメッセージのひとつがセキュリティゲートウェイの背後のホストに転送された場合、受信ホストの IP 実装はそのペイロード、つまりエラー応答の要因となったと思われるパケットのヘッダに基づいて判断する。したがって IPsec 実装は、そのペイロードのヘッダ情報が、それが到着した SA と一貫性があるかどうかを確認すようように構成可能でなければならない(MUST)。(これは、ペイロードのヘッダ(送信元/宛先のアドレスおよびポートフィールドが逆)が、その SA のためのトラフィックセレクタに一致することを意味する。) この種の確認が実行されない場合、例えば、アクティブな SA を持つ受信側 IPsec システム(A)のだれでも、A が現在通信している任意のホスト/ネットワークを参照する ICMP 宛先到達不能メッセージを送信できるだろう。これは、A の他のピアとの通信に対する非常に効果的な DoS 攻撃を可能にするだろう。通常の IPsec のトラフィック受信プロセスはこのような攻撃に対する保護が十分ではない。しかしながら、あらゆる状況でこの確認が必要とされるわけではないため、ローカルの管理者がこの種の確認を実行しないように実装を設定できる必要がある。
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 エラーメッセージに対する以下の処理をサポートしなければならない(MUST)。
If an SA exists that accommodates an outbound ICMP error message, then the message is mapped to the SA and only the IP and ICMP headers are checked upon receipt, just as would be the case for other traffic. If no SA exists that matches the traffic selectors associated with an ICMP error message, then the SPD is searched to determine if such an SA can be created. If so, the SA is created and the ICMP error message is transmitted via that SA. Upon receipt, this message is subject to the usual traffic selector checks at the receiver. This processing is exactly what would happen for traffic in general, and thus does not represent any special processing for ICMP error messages. アウトバウンドの ICMP エラーメッセージに適応する SA が存在する場合、そのメッセージはその SA にマップされ、他のトラフィックの場合と同様に、受信に際して IP と ICMP とのヘッダだけが検証される。ICMP エラーメッセージに対応するトラフィックセレクタに一致する SA が存在しない場合、そのような SA を生成可能かどうかを判断するために SPD が検索される。生成可能な場合、SA が生成され、ICMP エラーメッセージはその SA を通して転送される。受信に際し、そのメッセージは受信側で通常のトラフィックセレクタチェックの対象となる。これは通常のトラフィックに行われる処理そのものであり、ICMP エラーメッセージのための特別な処理を表すものではない。
If no SA exists that would carry the outbound ICMP message in question, and if no SPD entry would allow carriage of this outbound ICMP error message, then an IPsec implementation MUST map the message to the SA that would carry the return traffic associated with the packet that triggered the ICMP error message. This requires an IPsec implementation to detect outbound ICMP error messages that map to no extant SA or SPD entry, and treat them specially with regard to SA creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). It then uses this extracted information to locate an appropriate, active outbound SA, and transmits the error message via this SA. If no such SA exists, no SA will be created, and this is an auditable event. 問題のアウトバウンド ICMP メッセージを運ぶ SA が存在せず、その ICMP エラーメッセージの転送を許可する SPD エントリも存在しない場合、IPsec 実装はそのメッセージを、その ICMP エラーメッセージのきっかけとなったパケットに対応する返送トラフィックを運ぶ SA にマップしなければならない(MUST)。そのためには IPsec 実装が、既存の SA または SPD エントリにマップされないアウトバウンド ICMP エラーメッセージを検出し、SA の生成と検索とに関して特別な扱いをする必要がある。実装はエラーのきっかけとなったパケットのヘッダを(ICMP メッセージのペイロードから)抽出し、送信元および宛先の IP アドレスフィールドを反転し、プロトコルフィールドを抽出し、ポートフィールドを反転する(アクセス可能なら)。そしてその抽出した情報を使用して適切でアクティブなアウトバウンド SA を探し、その SA を通してエラーメッセージを転送する。そのような SA が存在しなければ SA は生成されない。これは監査可能なイベントである。
If an IPsec implementation receives an inbound ICMP error message on an SA, and the IP and ICMP headers of the message do not match the traffic selectors for the SA, the receiver MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which the ICMP error message was received. If the packet fails this check, the IPsec implementation MUST NOT forwarded the ICMP message to the destination. This is an auditable event. IPsec 実装が SA 上でインバウンドの ICMP エラーメッセージを受信し、そのメッセージの IP および ICMP のヘッダがその SA のためのトラフィックセレクタに一致しない場合、受信側は受信したメッセージを特殊な方法で処理しなければならない(MUST)。具体的にいうと、受信側はそのパケットが ICMP エラーメッセージが到達した SA のためのセレクタと一貫性があるかどうかを確認するために、きっかけとなったパケットのヘッダを ICMP ペイロードから抽出し、前述のようなフィールドの反転を行わなければならない。パケットがこの確認に失敗した場合、IPsec 実装は宛先に ICMP メッセージを転送してはならない(MUST NOT)。これは監査可能なイベントである。
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 "フラグメント処理の原理" 参照) 具体的には以下の問題に取り組む：
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 を包含することにも注意してほしい。用語 "ノントリビアル(non-trivial)" は、セレクタが 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. 注意：ここでの用語 "非初期フラグメント(non-initial fragment)" は、アクセスコントロールに必要とされる可能性のあるすべてのセレクタ値を持っているわけではないフラグメントを表す。セクション 4.4.1 で見た通り、非初期フラグメントでは上位層プロトコル(Next Layer Protocol)に依存して、ポート(Ports)に加えて ICMP メッセージのタイプ/コード、またはモビリティヘッダのタイプが存在しない可能性がある。また IPv6 では、拡張ヘッダの数と種類とに依存して、初期フラグメントであっても上位層プロトコル(Next Layer Protocol)またはポート(Ports)(または ICMP メッセージのタイプ/コード、またはモビリティヘッダのタイプ)を含まない可能性がある。非初期フラグメントがポート(Ports)(または ICMP のタイプ/コード、またはモビリティヘッダのタイプ)を含むが上位層プロトコル(Next Layer Proocol)を含まない場合、そのローカル/リモートアドレスに対応し上位層プロトコル(Next Layer Protocol)とポート(Port)(または ICMP のタイプ/コード、またはモビリティヘッダのタイプ)とのための ANY を持つ SPD エントリが存在しない限り、そのフラグメントはアクセスコントロールに必要なすべてのセレクタ情報を持つわけではないだろう。
To address the above issues, three approaches have been defined: 上記の問題を解決するために、三つのアプローチが定義されている：
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 をサポートしなければならない(MUST)。SA が特定のプロトコルのトラフィックを転送する場合、その SA のために設定されたセレクタはポートフィールドに ANY を指定されなければならない(MUST)。そのように定義された SA は、指定されたローカル/リモートアドレスと指定された上位層プロトコル(Next Layer Protocol)とに対し、初期フラグメント・非初期フラグメントを含むすべてのトラフィックを転送するだろう。その SA が特定のプロトコル値に関係なくトラフィックを転送する場合(つまり、(上位層)プロトコルセレクタ値として ANY を指定されている場合)、ポートフィールドの値は未定義であるため、同様に ANY をセットされなければならない(MUST)。(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 をサポートしてもよい(MAY)。そのようなフラグメントを転送するには、SA のためのポート(または ICMP のタイプ/コード、またはモビリティヘッダのタイプ)フィールドセレクタを特定するために OPAQUE が使用されるだろう。この種の SA を採用する場合、重複フラグメント攻撃(overlapping fragment attack)を回避するために、受信側は IPv4 (非初期)フラグメントに対して最小オフセット確認を実行しなければならない(MUST)。IPv6 の非初期フラグメントに対してはこのような確認を実行することが出来ないため、ユーザーと管理者はこのようなフラグメントの転送に危険性があることに注意すべきであり、実装者は IPv6 トラフィックにこの種の SA をサポートしない選択をしてもよい。またこの種の SA は、指定されたローカル/リモートアドレスの組とプロトコル値とに一致するすべての非初期フラグメントを転送するだろう。つまりこの SA 上で転送されるフラグメントは、もしそれがフラグメント化されていなければ、異なるセキュリティの別の SA に向かう可能性があるということである。したがってユーザーと管理者は、両ピアの間で(完全性を持つ)ESP と "最強の(strongest)" 完全性・暗号化アルゴリズムとを使用して、そのようなトラフィックを保護することが推奨される。("最強の(strongest)" アルゴリズムの決定には、利用可能なアルゴリズムの順位付けと、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. 初期フラグメントと非初期フラグメントとを転送する SA を定義するには、特定のポート(または ICMP のタイプ/コード、またはモビリティヘッダのタイプ)のセレクタ値が使用されるだろう。このアプローチは、ユーザーまたは管理者が、同じローカル/リモードアドレスの間でポート(または ICMP のタイプ/コード、またはモビリティヘッダのタイプ)フィールドに基づいて判別されるひとつ以上のトンネルモード SA を生成したい場合に使用できる。これらの SA はノントリビアルなプロトコルセレクタ値を持たなければならず(MUST)、そうでなければ前述のアプローチ #1 を使用しなければならない(MUST)。
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. 注意：このセクションで説明されているアプローチの場合、一般にすべての非初期フラグメントを転送するために二つの実装の間に単一の SA だけを必要とする。しかしながら QoS の差別化のために二つの実装間に複数の SA を持つ場合、ポートに関係なくフラグメントを転送するために複数の SA (それぞれがサポートする QoS クラス用)を必要とする可能性がある。個別の 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 のタイプ)フィールド値を持つトンネルモード SA のための、何らかの形のステートフルフラグメントチェックをサポートしてもよい(MAY)。ノントリビアルのポート(または ICMP のタイプ/コード、または MH のタイプ)を利用するトンネルモード SA 上で非初期フラグメントを送信する実装は、IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO ペイロードによってピアに通知しなければならない(MUST)。
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. このような状況において非初期フラグメントを受け付けないピアは、この提案を拒否しなければならない(MUST)。そのような SA のための非初期フラグメントの送信の交渉に成功しなかった実装は、その SA 上でそのようなフラグメントを送信してはならない(MUST NOT)。この標準では、送信側または受信側においてそのようなフラグメントをピアがどのように扱うか(例えば再構築するなど)を規定しない。しかしながら受信側は、ノントリビアルポート(または ICMP のタイプ/コードまたは MH のタイプ)のセレクタ値を持つ SA 上で受信した非初期フラグメントを、その機能が交渉されているのではない限り、破棄しなければならない(MUST)。また受信側は、パケット全体に適用されるセキュリティポリシーにしたがわない非初期フラグメントを破棄しなければならない(MUST)。このようなパケットの破棄は監査可能なイベントである。異なるセキュリティゲートウェイまたは 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 パケット分類メカニズムによるフラグメントの破棄(DISCARD)をサポートしなければならない(MUST)。すべての実装は、ノントリビアルのポート範囲指定によるトラフィックのバイパス(BYPASS)に対応するために、ステートフルフラグメントチェックをサポートしなければならない(MUST)。懸念事項としては、IPsec 実装に到達した平文の非初期フラグメントのバイパス(BYPASS)が、同じ宛先への IPsec 保護されたトラフィックに提供されるセキュリティを低下させる可能性がある。例えば、特定の送信元/宛先アドレスの間の、特定のプロトコルと宛先ポート(例えばポート 23 (Telnet)上の TCP トラフィック)とのトラフィックに対する IPsec 保護を要求する SPD エントリを持つ IPsec 実装を考える。その実装が、同じ送信元/宛先アドレスとプロトコルで、異なる宛先ポート(例えばポート 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. すべての IPsec 実装は、トンネルモード SA を経由してトラフィックが運ばれるとき、それが発行するトンネルモードヘッダに DF ビットをアウトバウンドパケットからコピーするオプションをサポートしなければならない(MUST)。これは、各 SA ごとに実装が DF ビットをどのように扱うか(セット、クリア、インナーヘッダからコピー)を構成可能でなればならない(MUST)ことを意味する。これはインナーヘッダとアウターヘッダとが共に IPv4 の場合に適用される。
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
IPv4 (RFC 792 [Pos81b]):
- Type = 3 (宛先到達不能)
- Code = 4 (フラグメント化が必要だが、DFがセットされている)
- ICMP ヘッダの第 2 ワード(RFC 792 では "未使用(unused)"
と分類されていた)の下位 16 ビット内の Next-Hop MTU
上位 16 ビットはゼロがセットされる
IPv6 (RFC 2463 [CD98]):
- Type = 2 (パケットが大きすぎる)
- Code = 0 (フラグメント化が必要)
- ICMP6 メッセージの 32 ビット MTU フィールド内の
Next-Hop 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 ヘッダのサイズと、任意の暗号同期化データ、そしてトンネルモード SA の場合は追加 IP ヘッダにより課されるオーバーヘッドも考慮しながら、SAD の PMTU フィールドを更新するのに使用される。
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 エントリにマップされるのを待つべきである(SHOULD)。そのようなトラフィックが到着したとき、それが更新された PMTU 値を超えていれば、以下のように扱われなければならない(MUST)：
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 は "劣化(aged)" しなければならず(MUST)、特に 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 ディスカバリの文書 (RFC 1191 [MD90] のセクション 6.3)で説明されているアプローチを使用するべきである(SHOULD)。その文書では、周期的に PMTU を第一ホップデータリンク MTU(first-hop data-link MTU)にリセットし、必要に応じて通常の PMTU ディスカバリプロセスにその PMTU を更新させることが提案されている。周期は設定可能であるべきである(SHOULD)。
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 実装は監査のサポートを要求されない。監査の粒度は大部分がローカルの問題である。しかしながらこの文書ではいくつかの監査可能イベントを挙げており、それらのイベントごとに、監査ログに含まれるべき(SHOULD)最低限の情報が定義されている。イベントごとの監査ログに追加の情報が含まれてもよい(MAY)し、(この仕様において明示的に宣言されていない)追加のイベントが監査ログを生成してもよい(MAY)。監査可能イベントの検出に際し受信者は、送信者と思われる相手にすべてのメッセージを送る必要はない。そのような動作はサービス拒否を引き起こす可能性があるためである。
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 実装は、この文書のすべての要求事項にしたがわなければならない(MUST)。すべての IPv6 実装は、この文書のすべての要求事項にしたがわなければならない(MUST)。
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. トンネルモード SA が採用されている場合には特に、IPsec は IPsec 境界を通過する両方向の IP ヘッダ情報のバイパスに対して厳しい制限を課す。一部の制約は絶対的なものであり、その他は(多くの場合 SA ごとの原則で)ローカルの管理統制にしたがう。アウトバウンドトラフィックの場合、これらの制約は秘密のチャネル帯域を制限するために設計されている。インバウンドトラフィックの場合、これらの制約は、あるデータストリーム(IPsec 境界の非保護側)を不正に改竄する能力をもつ攻撃者が、別のデータストリーム(IPsec 境界の保護側)に悪影響を与えるのを防ぐために設計されている。トンネルモード 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 エラーメッセージを通過するように構成されている場合、深刻な脆弱性が生じる可能性がある。複数のサイト(A、B、C)が、ESP 保護トンネルを通して互いに(A-B、A-C、B-C)接続している場合を考える。さらに、各トンネルのためのトラフィックセレクタが、プロトコルフィールドとポートフィールドとに ANY を指定されており、また各サイトを扱うセキュリティゲートウェイの背後のシステムのアドレス範囲を含む IP 送信元/宛先アドレス範囲を指定されていると仮定する。これによりサイト B 上のホストは、サイト A 上の任意のホストに対し、サイト C のネットワークのすべてのホストが到達不要であると通知する ICMP Destination Unreachable メッセージを送信することができる。これは非常に効果的な DoS 攻撃だが、その ICMP エラーメッセージが IPsec の提供する(SPD が適切に構成されていればセクション 6.2 で説明されている通りの)確認に従っていれば防げるだろう。
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry". IANA は、asn1-modules レジストリのために値 (3) を割り当て、SPD モジュールのためにオブジェクト識別子 1.3.6.1.5.8.3.1 を割り当てた。付録 C "SPD エントリのための ANS.1" 参照。
This architecture document differs substantially from RFC 2401 [RFC2401] in detail and in organization, but the fundamental notions are unchanged. このアーキテクチャ文書は詳細および構成において RFC 2401[RFC2401] と大幅に異なるが、基本的な概念は変わっていない。
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 を著した Ran Atkinson、特に IPv6 問題に関して第二の一連の IPsec 標準(RFC 2401、2402、2406)および現バージョンに重要な貢献をした Charlie Lynn に感謝したい。また、このプロトコル仕様の開発に貢献してくれた IPsc and MSEC ワーキンググループのメンバーにも感謝したい。
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. このセクションは、この文書で採用されているいくつかの重要な用語の定義を提供する。他の文書(例えば [Shi00]、[VK83]、[HA94])がこの技術に関連する追加の定義と参考資料とを提供する。この用語集に含まれているのは、一般的なセキュリティサービスとセキュリティメカニズム、および IPsec 固有の用語である。
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. この付録は、IP Security Policy Working Group において Luis Sanchez、Matt Condell、John Zao により成されたポリシーのキャッシュのための成果に基づいている。
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. 二つの SPD エントリ内の対応するセレクタ値の間に共通部分がある場合、その二つの SPD エントリには関連がある。関連する SPD エントリ群をキャッシュすることは、誤ったポリシーの施行を引き起こす可能性がある。キャッシュを可能にしたままでこの問題を解決する方法は、それらのエントリを関連付けないことで、あいまいさを取り除くことである。つまり SPD エントリは、すべてのエントリの組の間に空の共通部分のあるセレクタが存在するように書き換えられなければならないということである。いったんエントリが非相関化されれば、それらの順序に制限はなくなる。どのような検索でもただひとつのエントリだけが一致するためである。次のセクションでは非相関化をより詳細に説明し、非相関化を実装するために使用できるアルゴリズムを提示する。
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 内の各エントリを受け取り、ツリー構造を使用してそれをエントリの集合に分割する。ツリーのノードはセレクタであり、ポリシー間をまたがってもよい。各ノードにおいてアルゴリズムはセレクタの値ごとに枝を生成する。また、すべてのセレクタ値の和集合の補集合ために、もうひとつの枝を生成する。ツリーのルートから各リーフまでを縦断することでポリシーが形成される。リーフ上のポリシーは、すでに非相関化されたポリシールールの集合と比較される。各リーフ上のポリシーは、すでに非相関化された集合内のポリシーによって完全に上書きされて破棄されるか、または、非相関化された集合内のすべてのポリシーに対して非相関化された上で追加される。
The basic algorithm does not guarantee an optimal set of decorrelated entries. That is, the entries may be broken up into smaller sets than is necessary, though they will still provide all the necessary policy information. Some extensions to the basic algorithm are described later to improve this and improve the performance of the algorithm. この基本アルゴリズムは、非相関エントリの最適化された集合を保証しない。必要なすべてのポリシー情報は提供するものの、エントリが必要以上に小さい集合に分割される可能性がある。これを改善するために、またアルゴリズムのパフォーマンスを改善するために、この基本アルゴリズムへの拡張をいくつか後述する。
C A set of ordered, correlated entries (a correlated SPD).
Ci The ith entry in C.
U The set of decorrelated entries being built from C.
Ui The ith entry in U.
Sik The kth selection for policy Ci.
Ai The action for policy Ci.
C 順序付けられた相関エントリ(相関 SPD)の集合
Ci C の中の i 番目のエントリ
U C から構築された非相関エントリの集合
Ui U の中の i 番目のエントリ
Sik ポリシー Ci のための k 番目のセクション
Ai ポリシー Ci のためのアクション
A policy (SPD entry) P may be expressed as a sequence of selector values and an action (BYPASS, DISCARD, or PROTECT): ポリシー(SPD エントリ) P は、一連のセレクタ値とアクション(BYPASS または DISCARD または PROTECT)とによって表すことができる：
Ci = Si1 x Si2 x ... x Sik -> Ai
For each policy Cj (j > 1) in C C の中の各ポリシー Cj (j > 1) ごとに
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 内の対応するセレクタ値であると仮定する。
Add all the decorrelated entries at the leaves of the tree to U. ツリーのリーフにおけるすべての非相関エントリを U に追加する。
There are several optimizations that can be made to this algorithm. A few of them are presented here. このアルゴリズムには、いくつかの最適化を行える。ここでその一部を示す。
It is possible to optimize, or at least improve, the amount of branching that occurs by carefully choosing the order of the selectors used for the next branch. For example, if a selector Sjn can be chosen so that all the values for that selector in T are equal to or a superset of the value of Sjn in Cj, then only a single branch needs to be created (since the complement will be null). 次の枝に使用するセレクタの順序を注意深く選択することで、枝分かれの数を最適化、または少なくとも改善できる。例えばセレクタ Sjn を、T 内のそのセレクタのすべての値が Cj 内の Sjn の値と等価またはその上位集合となるように選択することができ、それによりただひとつの枝を生成すればよくなる(補集合が空になるため)。
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. ステップ 2 においてエントリがすでに非相関化されているかどうかを確認するとともに、Cj が U 内のどれかのエントリによって上書きされるかどうかを確認する。もしそうなら、そのエントリは無関係なのでスキップする。エントリ x 内のすべてのセレクタが、エントリ y 内の対応するセレクタと等価またはその上位集合である場合、エントリ x はエントリ y に上書きされる。
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
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
ipsec (8) asn1-modules (3) spd-module (1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- An SPD is a list of policies in decreasing order of preference
SPD ::= SEQUENCE OF SPDEntry
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT traffic
bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- Each entry consists of
name NameSets OPTIONAL,
pFPs PacketFlags, -- Populate from packet flags
-- Applies to ALL of the corresponding
-- traffic selectors in the SelectorLists
condition SelectorLists, -- Policy "condition"
processing Processing -- Policy "action"
}
BypassOrDiscardEntry ::= SEQUENCE {
bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
condition InOutBound }
InOutBound ::= CHOICE {
outbound [0] SelectorLists,
inbound [1] SelectorLists,
bothways [2] BothWays }
BothWays ::= SEQUENCE {
inbound SelectorLists,
outbound SelectorLists }
NameSets ::= SEQUENCE {
passed SET OF Names-R, -- Matched to IKE ID by
-- responder
local SET OF Names-I } -- Used internally by IKE
-- initiator
Names-R ::= CHOICE { -- IKEv2 IDs
dName RDNSequence, -- ID_DER_ASN1_DN
fqdn FQDN, -- ID_FQDN
rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
keyID OCTET STRING } -- KEY_ID
Names-I ::= OCTET STRING -- Used internally by IKE
-- initiator
FQDN ::= IA5String
RFC822Name ::= IA5String
PacketFlags ::= BIT STRING {
-- if set, take selector value from packet
-- establishing SA
-- else use value in SPD entry
localAddr (0),
remoteAddr (1),
protocol (2),
localPort (3),
remotePort (4) }
SelectorLists ::= SET OF SelectorList
SelectorList ::= SEQUENCE {
localAddr AddrList,
remoteAddr AddrList,
protocol ProtocolChoice }
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- if absent, use
-- transport mode
SALifetime ::= SEQUENCE {
seconds [0] INTEGER OPTIONAL,
bytes [1] INTEGER OPTIONAL }
ManualSPI ::= SEQUENCE {
spi INTEGER,
keys KeyIDs }
KeyIDs ::= SEQUENCE OF OCTET STRING
ProcessingAlgs ::= CHOICE {
ah [0] IntegrityAlgs, -- AH
esp [1] ESPAlgs} -- ESP
ESPAlgs ::= CHOICE {
integrity [0] IntegrityAlgs, -- integrity only
confidentiality [1] ConfidentialityAlgs, -- confidentiality
-- only
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
-- Integrity Algorithms, ordered by decreasing preference
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- Confidentiality Algorithms, ordered by decreasing preference
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- Integrity Algorithms
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
IntegrityAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5)
-- tbd (6..65535)
}
-- Confidentiality Algorithms
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
ConfidentialityAlgType ::= INTEGER {
encr-DES-IV64 (1),
encr-DES (2),
encr-3DES (3),
encr-RC5 (4),
encr-IDEA (5),
encr-CAST (6),
encr-BLOWFISH (7),
encr-3IDEA (8),
encr-DES-IV32 (9),
encr-RC4 (10),
encr-NULL (11),
encr-AES-CBC (12),
encr-AES-CTR (13)
-- tbd (14..65535)
}
CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
CombinedModeAlg ::= SEQUENCE {
algorithm CombinedModeType,
parameters ANY -- DEFINED BY algorithm} -- defined outside
-- of this document for AES modes.
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE Copy CE to inner header
df DF,
addresses TunnelAddresses }
TunnelAddresses ::= CHOICE {
ipv4 IPv4Pair,
ipv6 [0] IPv6Pair }
IPv4Pair ::= SEQUENCE {
local OCTET STRING (SIZE(4)),
remote OCTET STRING (SIZE(4)) }
IPv6Pair ::= SEQUENCE {
local OCTET STRING (SIZE(16)),
remote OCTET STRING (SIZE(16)) }
DSCP ::= SEQUENCE {
copy BOOLEAN, -- TRUE copy from inner header
-- FALSE do not copy
mapping OCTET STRING OPTIONAL} -- points to table
-- if no copy
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- for ANY protocol
noNext [0] NoNextLayerProtocol, -- has no next layer
-- items
oneNext [1] OneNextLayerProtocol, -- has one next layer
-- item
twoNext [2] TwoNextLayerProtocol, -- has two next layer
-- items
fragment FragmentNoNext } -- has no next layer
-- info
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- ANY protocol
nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- with either
first AnyNextLayer, -- ANY next layer selector
second AnyNextLayer } -- ANY next layer selector
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- Fragment identifier
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- Protocol
local NextLayerChoice, -- Local and
remote NextLayerChoice } -- Remote ports
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
-- Representation of ANY in next layer field
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- Representation of OPAQUE in next layer field.
-- Matches IKE convention
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- Range for a next layer field
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- List of IP addresses
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPv4 address representations
IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- close, but not quite right ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 address representations
IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- close, but not quite right ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
END
SPDModule
{iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
ipsec (8) asn1-modules (3) spd-module (1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
RDNSequence FROM PKIX1Explicit88
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- SPD は優先順位の降順に並んだポリシーのリストである
SPD ::= SEQUENCE OF SPDEntry
SPDEntry ::= CHOICE {
iPsecEntry IPsecEntry, -- PROTECT トラフィック
bypassOrDiscard [0] BypassOrDiscardEntry }
-- DISCARD/BYPASS
IPsecEntry ::= SEQUENCE { -- 各エントリの構成
name NameSets OPTIONAL,
pFPs PacketFlags, -- パケットフラグから設定
-- SelectorLists 内の対応するすべての
-- トラフィックに適用される
condition SelectorLists, -- ポリシーの "状態"
processing Processing -- ポリシーの "アクション"
}
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, -- レスポンダが IKE ID に一致
-- させる
local SET OF Names-I } -- IKE イニシエータが内部的に
-- 使用する
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 -- IKE イニシエータが内部的に使用
FQDN ::= IA5String
RFC822Name ::= IA5String
PacketFlags ::= BIT STRING {
-- セットされた場合、SA を確立するパケットから
-- セレクタ値を取得する
-- そうでない場合、SPD エントリ内の値を使用する
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 ビットカウンタ
-- FALSE なら 32 ビット
seqOverflow BOOLEAN, -- TRUE なら再鍵化,
-- FALSE なら終了 & 監査
fragCheck BOOLEAN, -- TRUE なら
-- ステートフルフラグメントチェックあり
-- FALSE なら
-- ステートフルフラグメントチェックなし
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL } -- 設定されない場合、
-- トンネルモードを
-- 使用する
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, -- 完全性のみ
confidentiality [1] ConfidentialityAlgs, -- 機密性のみ
both [2] IntegrityConfidentialityAlgs,
combined [3] CombinedModeAlgs }
IntegrityConfidentialityAlgs ::= SEQUENCE {
integrity IntegrityAlgs,
confidentiality ConfidentialityAlgs }
-- 完全性アルゴリズム 優先順位の降順
IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-- 機密性アルゴリズム 優先順位の降順
ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-- 完全性アルゴリズム
IntegrityAlg ::= SEQUENCE {
algorithm IntegrityAlgType,
parameters ANY -- アルゴリズムによって定義される
-- オプション }
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)
}
-- 機密性アルゴリズム
ConfidentialityAlg ::= SEQUENCE {
algorithm ConfidentialityAlgType,
parameters ANY -- アルゴリズムによって定義される
-- オプション }
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 -- アルゴリズムによって定義される }
-- AES モードのためにこの文書外で
-- 定義される
CombinedModeType ::= INTEGER {
comb-AES-CCM (1),
comb-AES-GCM (2)
-- tbd (3..65535)
}
TunnelOptions ::= SEQUENCE {
dscp DSCP,
ecn BOOLEAN, -- TRUE なら CE をインナーヘッダに
-- コピーする
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 ならインナーヘッダからコピーする
-- FALSE ならコピーしない
mapping OCTET STRING OPTIONAL} -- コピーしない場合に
-- テーブルを示す
DF ::= INTEGER {
clear (0),
set (1),
copy (2) }
ProtocolChoice::= CHOICE {
anyProt AnyProtocol, -- 任意のプロトコル用
noNext [0] NoNextLayerProtocol, -- 上位層の項目を持たない
oneNext [1] OneNextLayerProtocol, -- 上位層の項目を一つ持つ
twoNext [2] TwoNextLayerProtocol, -- 上位層の項目を二つ持つ
fragment FragmentNoNext } -- 上位層の情報がない
AnyProtocol ::= SEQUENCE {
id INTEGER (0), -- 任意のプロトコル
nextLayer AnyNextLayers }
AnyNextLayers ::= SEQUENCE { -- 下記のどちらか
first AnyNextLayer, -- 任意の上位層セレクタ
second AnyNextLayer } -- 任意の上位層セレクタ
NoNextLayerProtocol ::= INTEGER (2..254)
FragmentNoNext ::= INTEGER (44) -- フラグメント識別子
OneNextLayerProtocol ::= SEQUENCE {
id INTEGER (1..254), -- ICMP, MH, ICMPv6
nextLayer NextLayerChoice } -- ICMP Type*256+Code
-- MH Type*256
TwoNextLayerProtocol ::= SEQUENCE {
id INTEGER (2..254), -- プロトコル
local NextLayerChoice, -- ローカルポート
remote NextLayerChoice } -- リモートポート
NextLayerChoice ::= CHOICE {
any AnyNextLayer,
opaque [0] OpaqueNextLayer,
range [1] NextLayerRange }
-- 上位層フィールド内の ANY の表現
AnyNextLayer ::= SEQUENCE {
start INTEGER (0),
end INTEGER (65535) }
-- 上位層フィールド内の OPAQUE の表現
-- IKE の慣例に一致する
OpaqueNextLayer ::= SEQUENCE {
start INTEGER (65535),
end INTEGER (0) }
-- 上位層フィールドの範囲
NextLayerRange ::= SEQUENCE {
start INTEGER (0..65535),
end INTEGER (0..65535) }
-- IP アドレスのリスト
AddrList ::= SEQUENCE {
v4List IPv4List OPTIONAL,
v6List [0] IPv6List OPTIONAL }
-- IPv4 アドレスの表現
IPv4List ::= SEQUENCE OF IPv4Range
IPv4Range ::= SEQUENCE { -- 近いが、完全には正しくない ...
ipv4Start OCTET STRING (SIZE (4)),
ipv4End OCTET STRING (SIZE (4)) }
-- IPv6 アドレスの表現
IPv6List ::= SEQUENCE OF IPv6Range
IPv6Range ::= SEQUENCE { -- 近いが、完全には正しくない ...
ipv6Start OCTET STRING (SIZE (16)),
ipv6End OCTET STRING (SIZE (16)) }
END
There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec: IPsec における(平文)フラグメントの処理に関して、解決しなければならない問題が三つある：
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. 第一と第三の問題は、トラフィックを SA (および SPD/キャッシュエントリ)にマッピングするのに決定性アルゴリズムを必要とするために生じる。私たちは IPsec 境界を通過する非初期フラグメントが受信側(または送信側)のアクセス制御ポリシーに違反しないことを保証したいため、三つの問題はすべて重要である。
First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing. 最初に、トランスポートモード 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 処理後のトンネルモードパケットをフラグメント化することを許される。しかしながら IPv4 と異なり、IPv6 におけるフラグメントヘッダは AH または ESP のヘッダの後に現れ、したがって再構築に関して受信側が混乱することがないため、トランスポートモード 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. この仕様は、IPsec 実装が最終目的地でない場合(例えば二つの SG 間)にトランスポートモードを使用することを受け入れる。これは原理的に、アウトバウンドの平文フラグメントが IPsec 処理のためにトランスポートモード SA にマップされる新しい機会を作る。しかしながら、トランスポートモード SA の使用が許可されたこれらの新しいコンテキストにおいて、私たちは IPsec (つまり、非ゼロのフラグメントオフセットフィールドを持つ "アウターヘッダ(outer header)" を持つパケット)に見られるように、フラグメントの転送を禁止し続けるように思える。例えば IP オーバーレイネットワークにおいて、トランスポートモード SA 上を送信されるパケットは IP-in-IP でトンネル化され、したがって IPsec 処理に先立ってフラグメント化に適応するために必須のインナーヘッダを持つ。トランスポートモード SA によって運ばれるとき、IPsec はそのようなトラフィックのためのインナー IP ヘッダを確認せず、したがってそのパケットをフラグメントと見なさないだろう。
For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem. トンネルモード 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.) 例えば、二つのアドレス範囲の間のすべてのトラフィックが IPsec 保護を受ける(BYPASS でも DISCARD でもない SPD エントリがこのアドレス範囲に適用されている)ことを SPD エントリが要求する場合、その SPD エントリはそのアドレス範囲の間ですべてのトラフィックを転送する意図があるという意味を含むため、このアドレス範囲のために定義された SA 上で非初期フラグメントを転送するのは簡単なはずである。しかしながら、フラグメントに一致させられるエントリが複数存在し、かつそれらのエントリが(ANY ではなく)異なるポートフィールドのサブセットを参照する場合、アウトバウンドの非初期フラグメントを正しいエントリに一義的にマップすることは不可能である。(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 に到達したとき、ポートフィールドは暗号化されるだろう。RFC 2401 で説明されている "上位層プロトコル(next layer protocol)" を探すために規定されたアルゴリズムも、このような状況において暗号化された上位層プロトコルに適応するために OPAQUE を使用する動機付けとなった。それにもかかわらず、OPAQUE 値の主な使用方法は、ポートフィールドを持たないパケット(非初期フラグメント)、またはすでにポートフィールドが暗号化されているパケット(IPsec のネスト化された適用の結果)において、トラフィックセレクタフィールドに一致させることであった。RFC 2401 は、いくつかの場面において ANY を OPAQUE の代替にできることを示唆しており、OPAQUE と ANY との使用方法の考察があいまいであった。
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 はアクセス不可能なフィールドにだけ一致すると定義できる。私たちは ANY を OPAQUE の補集合、つまりアクセス可能なポートフィールドにだけ一致するものと定義できるだろう。したがって私たちは、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. 私たちは ANY と OPAQUE とに上記の定義を採用したため、指定されたプロトコルがポートフィールドを持たない場合と、プロトコルセレクタに ANY が使用された場合とに、それらの値がどのように作用するのかを明確にする必要がある。したがって、指定されたプロトコル値がセレクタとして使用され、かつそのプロトコルがポートフィールドを持たない場合、ポートフィールドセレクタは無視されるべきであり、そのポートフィールドのための値として ANY が指定されなければならない(MUST)。(この文脈において(IKEv2 ネゴシエーションのための) ICMP の TYPE および CODE の値は、IPv6 のモビリティヘッダの TYPE と同様、単独のポートフィールドとしてひとまとめに扱われる。) プロトコルセレクタが ANY のとき、これはポートフィールドの定義されていないプロトコルを指定した場合と等価に扱われるべきであり、したがってポートセレクタは無視され、ANY をセットされなければならない(MUST)。
For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However, RFC 2401 did not provide a perfect solution. The use of OPAQUE as a selector value for port fields (a SHOULD in RFC 2401) allowed an SA to carry non-initial fragments. SG 実装の場合、フラグメントが SG の背後のエンドシステムから来たことは明らかだろう。BITW 実装も、その背後のホストまたはゲートウェイからのフラグメントに遭遇する可能性がある。(前述の通り、ネイティブホスト実装と BITS 実装とは、以下で説明する問題をおそらく避けられるだろう。) 最悪の場合、あるパケット由来の複数のフラグメントが異なる BITW または SG のインスタンスに到着し、したがって解決の選択肢としての再構築を不可能にするだろう。そのため私たちは RFC 2401 において、フラグメントはあらゆる実装のンネルモードに適合しなければならないという一般的な要求事項を採用した。しかしなら、RFC 2401 は完全な解決策を提供しなかった。ポートフィールドのためのセレクタ値として OPAQUE を使用すること(RFC 2401 では「するべき(SHOULD)」の要件であった)で、SA は初期フラグメントを転送することができた。
Using the features defined in RFC 2401, if one defined an SA between two IPsec (SG or BITW) implementations using the OPAQUE value for both port fields, then all non-initial fragments matching the source/destination (S/D) address and protocol values for the SA would be mapped to that SA. Initial fragments would NOT map to this SA, if we adopt a strict definition of OPAQUE. However, RFC 2401 did not provide detailed guidance on this and thus it may not have been apparent that use of this feature would essentially create a "non-initial fragment only" SA. RFC 2401 で定義されているこの機能を使用すると、二つの IPsec(SG または BITW)実装の間で両方のポートフィールドに OPAQUE を使用する SA を定義した場合、その SA のための送信元/宛先(S/D)アドレスとプロトコルとの値に一致するすべての非フラグメントは、その SA にマップされるだろう。もし OPAQUE の厳密な定義を採用すると、初期フラグメントはこの SA にマップされないだろう。しかしながら、RFC 2401 はこれについて詳細なガイドラインを提供しておらず、そのため、この機能の使用が原則的に "非初期フラグメントだけ(non-initial fragment only)" の 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. 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. この "フラグメント限定(fragment-only)" SA のアプローチを議論する過程で、些細な問題(RFC 2401 では考慮されなかった問題)を避けなければならないことが指摘された。例えばこの種の SA は、指定された S/D アドレスの間の(指定されたプロトコルのための)すべてのトラフィックに "最高品質(highest quality)" のセキュリティサービスを提供するように設定されなければならない。これは、フラグメント限定 SA に捉えられたすべてのトラフィックが、フラグメント化されない場合に提供されるセキュリティよりも劣ったセキュリティを提供しないことを保証するために必要となる。ここで起こりうる問題は、セキュリティプロトコルとオプションとアルゴリズムとの選択が全順序集合ではなく束であるため、二つの IPsec 実装の間で使用されるために定義される "最高品質(highest quality)" のセキュリティサービスを特定することが出来ない可能性があるということである。(完全性については問題なく BYPASS < AH < ESP(+完全性) と言えるだろうが、ESP の暗号化や完全性に複数のアルゴリズムの選択肢がある場合には複雑になる。) したがってこれを正しく動作させるには、それらのセキュリティパラメータを全体的に順序付けることを強制しなければならないが、それはローカルに行われる可能性がある。
However, this conservative strategy has a possible performance downside. If most traffic traversing an IPsec implementation for a given S/D address pair (and specified protocol) is bypassed, then a fragment-only SA for that address pair might cause a dramatic increase in the volume of traffic afforded crypto processing. If the crypto implementation cannot support high traffic rates, this could cause problems. (An IPsec implementation that is capable of line rate or near line rate crypto performance would not be adversely affected by this SA configuration approach. Nonetheless, the performance impact is a potential concern, specific to implementation capabilities.) しかしながら、この保守的な戦略はパフォーマンスの劣化を起こし得る。与えられた S/D アドレスの組のための IPsec 実装を通過する大部分のトラフィックがバイパスされる場合、そのアドレスの組のためのフラグメント限定 SA は、暗号処理を施されるトラフィック量の劇的な増加を招く可能性がある。その暗号実装が高負荷のトラフィックをサポートできない場合、問題を起こすかもしれない。(回線速度またはそれに近い能力を持つ IPsec 実装は、逆にこの SA 設定のアプローチに影響されないだろう。それでもなおパフォーマンスに及ぼす影響は、実装の能力に固有の潜在的な懸念事項である。)
Another concern is that non-initial fragments sent over a dedicated SA might be used to effect overlapping reassembly attacks, when combined with an apparently acceptable initial fragment. (This sort of attack assumes creation of bogus fragments and is not a side effect of normal fragmentation.) This concern is easily addressed in IPv4, by checking the fragment offset value to ensure that no non-initial fragments have a small enough offset to overlap port fields that should be contained in the initial fragment. Recall that the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 bytes, so any ports should be present in the initial fragment. If we require all non-initial fragments to have an offset of, say, 128 or greater, just to be on the safe side, this should prevent successful attacks of this sort. If the intent is only to protect against this sort of reassembly attack, this check need be implemented only by a receiver. もうひとつの懸念事項は、専用の SA 上を送信された非初期フラグメントが、受け入れ可能なことが明らかな初期フラグメントと組み合わされたとき、重複再構築攻撃(overlapping reassembly attacks)を行うために使用されるかもしれないという点である。(この種の攻撃は偽のフラグメントの生成を前提としており、通常のフラグメント化の副作用ではない。) 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 拡張ヘッダは可変長であり、前述の種類の攻撃に使用されるかもしれないフラグメントを拒否するための、非初期フラグメントの確認に使用できる最大ヘッダ長のような値も存在しない。受信側が同等の保護機能を提供するためには、再構築状態に似た状態を維持する必要があるだろう。そのため、非初期フラグメントが渡されるときに、IPsec (またはファイアウォール)によるポートフィールドの確認を迂回するように設計された攻撃を拒否するであろうフラグメントオフセットチェックを強要することは、IPv4 の場合にのみ可能である。
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. それほど深刻でない懸念は、非初期フラグメント限定 SA 上を送信された非初期フラグメントが、有効な初期フラグメントが到着しなかい状態で送信される可能性があり、それが DoS の機会を示している可能性があことである。これは、SG または BITW デバイスの背後のホストを攻撃するのに使用される可能性がある。しかしながら、SG または BITW デバイスの背後のホストにのみ仕掛けられるこの種の攻撃によって引き起こされるリスクの増加は、小さいと思われる。
If we interpret the ANY selector value as encompassing OPAQUE, then a single SA with ANY values for both port fields would be able to accommodate all traffic matching the S/D address and protocol traffic selectors, an alternative to using the OPAQUE value. But, using ANY here precludes multiple, distinct SAs between the same IPsec implementations for the same address pairs and protocol. So, it is not an exactly equivalent alternative. セレクタ値 ANY を、OPAQUE を包含するものとして解釈すると、両方のポートフィールドに OPAQUE 値の代替として ANY 値を持つ単独の SA は、S/D アドレスとプロトコルとのトラフィックセレクタに一致するすべてのトラフィックに適応できるだろう。しかし、ここで 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. 基本的に問題を処理するフラグメントは、同じ S/D アドレスとプロトコルとのセレクタ値を持つが異なるポートフィールドセレクタ値を持つ SA がひとつ以上定義された場合にのみ生じる。
We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons: 私たちは、SA 処理とは無関係に、BYPASS/DISCARD エントリのための問題を処理する非初期フラグメントも解決しなければならない。これは二つの理由から主としてローカルの問題である：
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 トラフィックのためのフラグメント再構築を実装がサポートしなければならない(MUST)とする。また実装は、ユーザーまたは管理者が、セクション 4.4.1 で説明されている SPD の習慣を使用して、そのようなトラフィックを受け入れたり拒否したりすることを許可しなければならない(MUST)。懸念事項は、IPsec 実装に届いた平文の非初期フラグメントの BYPASS が、同じ宛先への IPsec 保護トラフィックによるセキュリティを低下させる可能性があることである。例えば、特定のプロトコルおよび宛先ポート(例えばポート 23 上の TCP トラフィック(TELNET))のための、特定の送信元/宛先アドレスの間のトラフィックに IPsec 保護を要求する SPD エントリを設定された IPsec 実装を考えよう。またその実装が、同じ送信元/宛先アドレスとプロトコルとからの、異なる宛先ポート(例えばポート 119(NNTP))のためのトラフィックの BYPASS を許可していると仮定する。攻撃者は、バイパスされた場合に同じ送信元からの IPsec 保護されたトラフィックと重複する(偽の送信元アドレスを持つ)非初期フラグメントを送信する可能性がある。ノントリビアルのポート範囲を持つ BYPASS エントリのためのステートフルフラグメントチェックの要求は、この種の攻撃を阻止する。
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 の背後のファイアウォールが残されるべきであると提案した。しかしながらこれは、 IPsec の別の部分における、常にフラグメントを破棄するファイアウォールについての懸念とつじつまの合わない提案のように思える。もし多くのファイアウォールが一般にフラグメントを通過させないとしたら、なぜ私たちはこの場合のフラグメントをそれらが処理すると期待しなければならないのか？ そのためこの分析は、トンネルモード SA でのポートフィールドセレクタを禁止する提案を拒否する。
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. ひとつの提案は、送信側の 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. 本ワーキンググループは、非初期フラグメントだけを転送する SA を生成する過去の合意を退ける。それは RFC 2401 のモデルにおいて OPAQUE ポートフィールドを使用することで暗黙的にサポートされていたが、決して明確に述べられていたわけではない。その(退けられた)文章は、送信側も受信側も各非初期フラグメントをプロトコル 44 (IPv6 のフラグメントヘッダプロトコル ID)として扱うことを要求していた。このアプローチは IPv4 と IPv6 とのフラグメントをより統一的に扱う潜在性を持つが、本質的にこの問題を変えることはなく、BYPASS/DISCARD トラフィックのためのフラグメント処理の問題も解決しない。IPv6 が引き起こすフラグメント重複攻撃(fragment overlap attack)の問題を考えると、この戦略を採用する努力に価値があるようには思えない。
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. 過去、本ワークグループは、IPsec 処理の前に BITS・BITW・SG がフラグメント化を実行することを許可していた。このフラグメント化が送信側の SA 検索の後に実行された場合、"正しい SA にマッピングする(mapping to the right SA)" という問題は無くなる。しかしながらそれでも受信側は、非初期フラグメントがそれを受信した SA と一貫性を持つかどうかを確認できる必要がある。初期フラグメントは経路上で喪失する可能性があるため、受信側はこれまでに述べたすべての潜在的問題に遭遇する。したがって私たちは、自分たちの決定に一貫性を持たせるつもりならば、非初期フラグメントが到着したときに受信者がそれをどう扱うかを述べる必要がある。
There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus, this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed. あらゆる状況においてフラグメントを扱える単純で統一された方法は存在しない。異なる状況では異なるアプローチが役に立つ。ゆえに、この文書は三つの選択肢(ひとつは MUST、二つは MAY)を提示する。将来のある時点で、コミュニティが二つの MAY の経験を得たとき、それらを SHOULD または MUST にしたり、他のアプローチが提案されたりしてもよい。
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 と転送テーブルとを構成する(新しい処理モデルと一貫性を持つ)方法を提供する。単純化のために、この例ではただひとつの SPD-I を前提とする。
The goal in this example is to support a transport mode SA from A to C, carried over a tunnel mode SA from A to B. For example, A might be a laptop connected to the public Internet, B might be a firewall that protects a corporate network, and C might be a server on the corporate network that demands end-to-end authentication of A's traffic. この例の目的は、A から C へのトランスポートモード SA を、A から B へのトンネルモード 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
上位層
ルール ローカル リモート プロトコル アクション
------ -------- -------- ---------- -----------------------
1 C A ESP BYPASS
2 A C ICMP,ESP PROTECT(ESP,トンネル,
完全性+機密性)
3 A C ANY PROTECT(ESP,トランスポート,
完全性のみ)
4 A B ICMP,IKE BYPASS
A's unprotected-side forwarding table is set so that outbound packets destined for C are looped back to the protected side. A's protected-side forwarding table is set so that inbound ESP packets are looped back to the unprotected side. A's forwarding tables contain entries of the form: A の非保護側の転送テーブルは、C に向けられたアウトバウンドパケットが保護側にループバックされるように設定される。A の保護側の転送テーブルは、インバウンドの ESP パケットが非保護側にループバックされるように設定される。A の転送テーブルは以下のエントリを持つ：
Unprotected-side forwarding table
Rule Local Remote Protocol Action
---- ----- ------ -------- ---------------------------
1 A C ANY loop back to protected side
2 A B ANY forward to B
Protected-side forwarding table
Rule Local Remote Protocol Action
---- ----- ------ -------- -----------------------------
1 A C ESP loop back to unprotected side
非保護側の転送テーブル
ルール ローカル リモート プロトコル アクション
------ -------- -------- ---------- ---------------------------
1 A C ANY 保護側にループバック
2 A B ANY B に転送
保護側の転送テーブル
ルール ローカル リモート プロトコル アクション
------ -------- -------- ---------- ---------------------------
1 A C ESP 非保護側にループバック
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 に一致し、したがって BYPASS される。パケットはアウトバウンドパケットとして扱われ、SPD と三度目の比較をされる。今回、そのパケットは SPD ルール 2 に一致し、したがってトンネルモードにおける ESP を適用される。今回は外側の宛先アドレスが B であるため、転送テーブルはパケットをループバックせず、したがってパケットは外に出て行く。
An inbound TCP packet from C to A is wrapped in two ESP headers; the outer header (ESP in tunnel mode) shows B as the source, whereas the inner header (ESP transport mode) shows C as the source. Upon arrival at A, the packet would be mapped to an SA based on the SPI, have the outer header removed, and be decrypted and integrity-checked. Then it would be matched against the SAD selectors for this SA, which would specify C as the source and A as the destination, derived from SPD rule 2. The protected-side forwarding function would then send it back to the unprotected side based on the addresses and the next layer protocol (ESP), indicative of nesting. It is compared against SPD-O (see Figure 3) and found to match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA based on the SPI, integrity-checked, and compared against the SAD selectors derived from SPD rule 3. The forwarding function then passes it up to the next layer, because it isn't an ESP packet. C から A へのインバウンドの TCP パケットは、二つの ESP ヘッダに包まれる。アウターヘッダ(トンネルモードの ESP)は送信元として B を示し、インナーヘッダ(ESP トランスポートモード)は送信元として C を示す。A に到達したとき、パケットは SPI に基づいて SA にマップされ、アウターヘッダを取り除かれ、復号および完全性チェックが行われる。次に、この SA のための SAD セレクタと照合される。SA は SPD ルール 2 に基づき、送信元として C 、宛先として A を指定する。保護側の転送機能はアドレスと上位層プロトコル(ESP)とに基づき、それを非保護側に送り返し、ネスト化を暗示する。それは SPD-O (図 3 参照)と比較され、SPD ルール 1 と一致するため、BYPASS される。パケットは SPI に基づいて SA にマップされ、完全性をチェックされ、SPD ルール 3 に由来する SAD セレクタと比較される。ESP パケットではないため、転送機能はそのパケットを上位層に渡す。
[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[CD98] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[Eas05] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
[Sch05] Schiller, J., "Cryptographic Algorithms for use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic Enforcement of Un-ordered Security Policies", BBN Technical Memo 1346, March 2004.
[FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[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.
[HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[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.
[Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[Sch94] Schneier, B., Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.
[Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3988 EMail: [email protected] Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3152 EMail: [email protected]
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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.
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.
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- [email protected].
Funding for the RFC Editor function is currently provided by the Internet Society. RFC 編集者の活動資金は、現在 Internet Society によって提供されている。