Network Working Group J. Pinkerton
Request for Comments: 5042 Microsoft Corporation
Category: Standards Track E. Deleganes
Self
October 2007
Direct Data Placement Protocol (DDP) /
Remote Direct Memory Access Protocol (RDMAP) Security
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from Local Peers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege.
この文書では、直接データ配置プロトコル（DDP）とリモートダイレクトメモリアクセスプロトコル（RDMAP）の実装と使用の周りにセキュリティ上の問題を分析します。これは、最初のDDPまたはRDMAPとDDPを実装することができるRDMAネットワークインターフェイスカード（RNIC）のためのアーキテクチャモデルを定義します。文書は、アーキテクチャ・モデルで定義されたリソースやシステムを保護するために使用することができ、対策に対する様々な攻撃をレビュー。攻撃は、セキュアな通信ネットワークを介してチャンネル、リモートピアからの攻撃、およびローカルピアからの攻撃を使用することによって緩和することができるものに分類されています。攻撃カテゴリはなりすまし、改ざん、情報開示、サービス拒否、および特権の昇格が含まれます。
Table of Contents
目次
1. Introduction ....................................................4
2. Architectural Model .............................................6
2.1. Components .................................................7
2.2. Resources ..................................................9
2.2.1. Stream Context Memory ...............................9
2.2.2. Data Buffers .......................................10
2.2.3. Page Translation Tables ............................10
2.2.4. Protection Domain (PD) .............................11
2.2.5. STag Namespace and Scope ...........................11
2.2.6. Completion Queues ..................................12
2.2.7. Asynchronous Event Queue ...........................12
2.2.8. RDMA Read Request Queue ............................13
2.3. RNIC Interactions .........................................13
2.3.1. Privileged Control Interface Semantics .............13
2.3.2. Non-Privileged Data Interface Semantics ............13
2.3.3. Privileged Data Interface Semantics ................14
2.3.4. Initialization of RNIC Data Structures for
Data Transfer ......................................14
2.3.5. RNIC Data Transfer Interactions ....................16
3. Trust and Resource Sharing .....................................17
4. Attacker Capabilities ..........................................18
5. Attacks That Can Be Mitigated with End-to-End Security .........18
5.1. Spoofing ..................................................19
5.1.1. Impersonation ......................................19
5.1.2. Stream Hijacking ...................................20
5.1.3. Man-in-the-Middle Attack ...........................20
5.2. Tampering - Network-Based Modification of Buffer Content ..21
5.3. Information Disclosure - Network-Based Eavesdropping ......21
5.4. Specific Requirements for Security Services ...............21
5.4.1. Introduction to Security Options ...................21
5.4.2. TLS Is Inappropriate for DDP/RDMAP Security ........22
5.4.3. DTLS and RDDP ......................................23
5.4.4. ULPs That Provide Security .........................23
5.4.5. Requirements for IPsec Encapsulation of DDP ........23
6. Attacks from Remote Peers ......................................24
6.1. Spoofing ..................................................25
6.1.1. Using an STag on a Different Stream ................25
6.2. Tampering .................................................26
6.2.1. Buffer Overrun - RDMA Write or Read Response .......26
6.2.2. Modifying a Buffer after Indication ................27
6.2.3. Multiple STags to Access the Same Buffer ...........27
6.3. Information Disclosure ....................................28
6.3.1. Probing Memory Outside of the Buffer Bounds ........28
6.3.2. Using RDMA Read to Access Stale Data ...............28
6.3.3. Accessing a Buffer after the Transfer ..............28
6.3.4. Accessing Unintended Data with a Valid STag ........29
6.3.5. RDMA Read into an RDMA Write Buffer ................29
6.3.6. Using Multiple STags That Alias to the Same
Buffer .............................................29
6.4. Denial of Service (DOS) ...................................30
6.4.1. RNIC Resource Consumption ..........................30
6.4.2. Resource Consumption by Idle ULPs ..................31
6.4.3. Resource Consumption by Active ULPs ................32
6.4.3.1. Multiple Streams Sharing Receive Buffers ..32
6.4.3.2. Remote or Local Peer Attacking a
Shared CQ .................................34
6.4.3.3. Attacking the RDMA Read Request Queue .....36
6.4.4. Exercise of Non-Optimal Code Paths .................37
6.4.5. Remote Invalidate an STag Shared on
Multiple Streams ...................................37
6.4.6. Remote Peer Attacking an Unshared CQ ...............38
6.5. Elevation of Privilege ....................................38
7. Attacks from Local Peers .......................................38
7.1. Local ULP Attacking a Shared CQ ...........................39
7.2. Local Peer Attacking the RDMA Read Request Queue ..........39
7.3. Local ULP Attacking the PTT and STag Mapping ..............39
8. Security considerations ........................................40
9. IANA Considerations ............................................40
10. References ....................................................40
10.1. Normative References .....................................40
10.2. Informative References ...................................41
Appendix A. ULP Issues for RDDP Client/Server Protocols ...........43
Appendix B. Summary of RNIC and ULP Implementation Requirements ...46
Appendix C. Partial Trust Taxonomy ................................47
Acknowledgments ...................................................49
RDMA enables new levels of flexibility when communicating between two parties compared to current conventional networking practice (e.g., a stream-based model or datagram model). This flexibility brings new security issues that must be carefully understood when designing Upper Layer Protocols (ULPs) utilizing RDMA and when implementing RDMA-aware NICs (RNICs). Note that for the purposes of this security analysis, an RNIC may implement RDMAP [RDMAP] and DDP [DDP], or just DDP. Also, a ULP may be an application or it may be a middleware library.
現在、従来のネットワーク・プラクティス（例えば、ストリームベースのモデルまたはデータグラムモデル）と比較して2者間の通信時にRDMAは、柔軟性の新しいレベルを可能にします。この柔軟性は、上位層プロトコルを設計する際に、慎重に理解しなければならない新たなセキュリティ上の問題（のULP）RDMAを利用し、RDMA対応のNICの（RNICs）を実装する場合をもたらします。このセキュリティ分析の目的のために、RNICはRDMAP [RDMAP]とDDP [DDP]、または単にDDPを実装することがあります。また、ULPは、アプリケーションであってもよいし、ミドルウェアライブラリーであってもよいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Additionally, the security terminology defined in [RFC4949] is used in this specification.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますさらに、RFC 2119に記載されるように解釈されるべきで、[RFC4949]で定義されたセキュリティ用語は、本明細書で使用されます。
The document first develops an architectural model that is relevant for the security analysis. Section 2 details components, resources, and system properties that may be attacked. The document uses Local Peer to represent the RDMA/DDP protocol implementation on the local end of a Stream (implemented with a transport protocol, such as [RFC793] or [RFC4960]). The local Upper-Layer-Protocol (ULP) is used to represent the application or middle-ware layer above the Local Peer. The document does not attempt to differentiate between a Remote Peer and a Remote ULP (an RDMA/DDP protocol implementation on the remote end of a Stream versus the application on the remote end) for several reasons: often, the source of the attack is difficult to know for sure and, regardless of the source, the mitigations required of the Local Peer or local ULP are the same. Thus, the document generically refers to a Remote Peer rather than trying to further delineate the attacker.
文書は、最初のセキュリティ分析に関連するアーキテクチャモデルを開発しています。第2節では、攻撃することができるコンポーネント、リソース、およびシステム・プロパティについて詳しく説明します。文書は、（[RFC793]または[RFC4960]などのトランスポートプロトコルで実現）ストリームのローカル端にRDMA / DDPプロトコルの実装を表すためにローカルピアを使用します。ローカル上層プロトコル（ULP）は、ローカルピア上のアプリケーションやミドルウェア層を表すために使用されます。文書は、リモートピアといくつかの理由でリモートULP（リモートエンド上のアプリケーションに対してストリームのリモートエンドにRDMA / DDPプロトコルの実装）を区別しようとしません：多くの場合、攻撃のソースが困難です確かに知っているとし、ソースに関係なく、ローカルピアまたはローカルULPの必要な緩和策は同じです。このように、文書を総称して、むしろさらに攻撃を描くしようとするよりも、リモートピアを指します。
The document then defines what resources a local ULP may share across Streams and what resources the local ULP may share with the Remote Peer across Streams in Section 3.
文書は、地元のULPは、ストリーム間で共有することがどのような資源や地元のULPは、第3節ではストリーム間でリモートピアと共有することがどのリソースを定義します。
Intentional sharing of resources between multiple Streams may imply some level of trust between the Streams. However, some types of resource sharing have unmitigated security attacks, which would mandate not sharing a specific type of resource unless there is some level of trust between the Streams sharing resources.
複数のストリーム間でのリソースの意図的な共有は、ストリーム間の信頼のいくつかのレベルを意味し得ます。しかし、リソース共有のいくつかの種類がストリームの共有リソース間の信頼のいくつかのレベルが存在しない限り、特定のタイプのリソースを共有しない義務付けるだろう紛れもないセキュリティ攻撃を、持っています。
This document defines a new term, "Partial Mutual Trust", to address this concept:
この文書では、この概念に対処するために、新しい用語、「部分的な相互信頼」を定義しています。
Partial Mutual Trust - a collection of RDMAP/DDP Streams, which represent the local and remote end points of the Stream that are willing to assume that the Streams from the collection will not perform malicious attacks against any of the other Streams in the collection.
部分的な相互信頼 - コレクションからのストリームは、コレクション内の他のストリームのいずれかに対する悪意のある攻撃を実行しないであろうことを前提としていても構わないと思っているストリームのローカルおよびリモートエンドポイントを表しRDMAP / DDPストリームのコレクション。
ULPs have explicit control of which collection of endpoints is in a Partial Mutual Trust collection through tools discussed in Appendix C, Partial Trust Taxonomy.
ULPは、エンドポイントのコレクションは、付録C、部分信頼分類で議論ツールを使って部分的な相互信頼コレクションにあるの明示的な制御を持っています。
An untrusted peer relationship is appropriate when a ULP wishes to ensure that it will be robust and uncompromised even in the face of a deliberate attack by its peer. For example, a single ULP that concurrently supports multiple unrelated Streams (e.g., a server) would presumably treat each of its peers as an untrusted peer. For a collection of Streams that share Partial Mutual Trust, the assumption is that any Stream not in the collection is untrusted. For the untrusted peer, a brief list of capabilities is enumerated in Section 4.
ULPは、それもそのピアによって意図的な攻撃に直面して堅牢かつ妥協のないだろうことを保証したい場合、信頼できないピア関係が適切です。例えば、同時に複数の無関係のストリーム（例えば、サーバ）をサポートする単一のULPは、おそらく信頼できないピアとしてピアの各々を扱うことになります。部分的な相互信頼を共有ストリームのコレクションのために、仮定は、コレクション内の任意のストリームではないが、信頼できないということです。信頼できない相手の場合は、機能の簡単なリストは、第4節に列挙されています。
The rest of the document is focused on analyzing attacks and recommending specific mitigations to the attacks. Attacks are categorized into attacks mitigated by end-to-end security, attacks initiated by Remote Peers, and attacks initiated by Local Peers. For each attack, possible countermeasures are reviewed.
文書の残りの部分は、攻撃を分析し、攻撃を特定の緩和策を推薦に焦点を当てています。攻撃は、エンドツーエンドのセキュリティ、リモートピアによって開始された攻撃によって軽減された攻撃に分類されており、攻撃はローカルピアによって開始します。各攻撃について、可能な対策が検討されています。
ULPs within a host are divided into two categories - Privileged and Non-Privileged. Both ULP types can send and receive data and request resources. The key differences between the two are:
特権と非特権 - ホスト内のULPは、2つのカテゴリに分類されています。どちらのULPタイプは、データおよび要求リソースを送受信することができます。 2間の主な相違点は以下のとおりです。
The Privileged ULP is trusted by the local system not to maliciously attack the operating environment, but it is not trusted to optimize resource allocation globally. For example, the Privileged ULP could be a kernel ULP; thus, the kernel presumably has in some way vetted the ULP before allowing it to execute.
特権ULPは、悪意を持って操作環境を攻撃しないように、ローカルシステムに信頼されているが、世界的に資源配分を最適化するために信頼されていません。例えば、特権ULPは、カーネルのULPである可能性があります。このように、カーネルは、おそらく何らかの方法でそれが実行を許可する前にULPを吟味しています。
A Non-Privileged ULP's capabilities are a logical sub-set of the Privileged ULP's. It is assumed by the local system that a Non-Privileged ULP is untrusted. All Non-Privileged ULP interactions with the RNIC Engine that could affect other ULPs need to be done through a trusted intermediary that can verify the Non-Privileged ULP requests.
非特権ULPの機能は特権ULPのの論理サブセットです。これは、非特権ULPが信頼できないローカルシステムが想定されます。他のULPに影響を与える可能性がRNICエンジンを搭載したすべての非特権ULP相互作用は、非特権ULP要求を確認することができ、信頼できる仲介者を介して行われる必要があります。
The appendices provide focused summaries of this specification. Appendix A, ULP Issues for RDDP Client/Server Protocols, focuses on implementers of traditional client/server protocols. Appendix B, Summary of RNIC and ULP Implementation Requirements, summarizes all normative requirements in this specification. Appendix C, Partial Trust Taxonomy, provides an abstract model for categorizing trust boundaries.
付録には、この仕様の集中要約を提供しています。付録A、ULPの問題RDDPクライアント/サーバプロトコルのためには、従来のクライアント/サーバプロトコルの実装に焦点を当てています。付録B、RNICとULP実装要件の概要は、本明細書におけるすべての規定の要件をまとめたもの。付録C、部分信頼分類は、信頼境界を分類するための抽象モデルを提供します。
If an RDMAP/DDP protocol implementation uses the mitigations recommended in this document, that implementation should not exhibit additional security vulnerabilities above and beyond those of an implementation of the transport protocol (i.e., TCP or SCTP) and protocols beneath it (e.g., IP) without RDMAP/DDP.
RDMAP / DDPプロトコルの実装は、このドキュメントで推奨緩和策を使用している場合は、その実装は、その下のトランスポートプロトコルの実装のものを（すなわち、TCPまたはSCTP）とプロトコルの上とを超えて追加のセキュリティの脆弱性を示すべきではない（例えば、IP） RDMAP / DDPなし。
This section describes an RDMA architectural reference model that is used as security issues are examined. It introduces the components of the model, the resources that can be attacked, the types of interactions possible between components and resources, and the system properties that must be preserved.
このセクションでは、セキュリティ上の問題が検討されているとして使用されるRDMAアーキテクチャ参照モデルを記載しています。これは、モデルの構成要素を導入し、攻撃可能なリソース、コンポーネントおよびリソース、および保存されなければならないシステムの特性との間の可能な相互作用のタイプ。
Figure 1 shows the components comprising the architecture and the interfaces where potential security attacks could be launched. External attacks can be injected into the system from a ULP that sits above the RNIC Interface or from the network.
図1は、アーキテクチャを含む成分及び潜在的なセキュリティ攻撃を起動することができるインターフェイスを示します。外部からの攻撃は、RNICインタフェース上またはネットワークから座っULPからシステム内に注入することができます。
The intent here is to describe high level components and capabilities that affect threat analysis, and not focus on specific implementation options. Also note that the architectural model is an abstraction, and an actual implementation may choose to subdivide its components along different boundary lines from those defined here. For example, the Privileged Resource Manager may be partially or completely encapsulated in the Privileged ULP. Regardless, it is expected that the security analysis of the potential threats and countermeasures still apply.
ここでの意図は、高レベルのコンポーネントと脅威の分析に影響を与える能力を説明し、具体的な実装オプションに焦点を当てていないことです。また、建築モデルが抽象化であることに注意して、実際の実装は、ここで定義されたものとは異なる境界線に沿ってその構成要素を細分化することもできます。例えば、特権リソースマネージャは、部分的にまたは完全にイネーブルULP中にカプセル化され得ます。かかわらず、潜在的な脅威と対策のセキュリティ分析はまだ適用されることを期待されています。
Note that the model below is derived from several specific RDMA implementations. A few of note are [VERBS-RDMAC], [VERBS-RDMAC-Overview], and [INFINIBAND].
以下のモデルはいくつかの特定のRDMA実装に由来することに留意されたいです。ノートの数は、[動詞-RDMAC]、[動詞-RDMAC-概要]、および[INFINIBAND]です。
+-------------+
| Privileged |
| Resource |
Admin<-+>| Manager | ULP Control Interface
| | |<------+-------------------+
| +-------------+ | |
| ^ v v
| | +-------------+ +-----------------+
+---------------->| Privileged | | Non-Privileged |
| | ULP | | ULP |
| +-------------+ +-----------------+
| ^ ^
|Privileged |Privileged |Non-Privileged
|Control |Data |Data
|Interface |Interface |Interface
RNIC | | |
Interface v v v
=================================================================
+--------------------------------------+
| |
| RNIC Engine |
| |
+--------------------------------------+
^
|
v
Internet
Figure 1 - RDMA Security Model
図1 - RDMAセキュリティモデル
The components shown in Figure 1 - RDMA Security Model are:
図1に示した構成要素 - RDMAセキュリティモデルは、以下のとおりです。
* RDMA Network Interface Controller Engine (RNIC) - The component that implements the RDMA protocol and/or DDP protocol.
* RDMAネットワークインタフェースコントローラエンジン（RNIC） - RDMAプロトコルおよび/またはDDPプロトコルを実装するコンポーネント。
* Privileged Resource Manager - The component responsible for managing and allocating resources associated with the RNIC Engine. The Resource Manager does not send or receive data. Note that whether the Resource Manager is an independent component, part of the RNIC, or part of the ULP is implementation dependent.
*特権リソースマネージャ - 管理やRNICエンジンに関連したリソースを割り当てるための責任を負うコンポーネント。 Resource Managerがデータを送信または受信しません。リソースマネージャは、独立成分、RNICの一部であるかどうか、またはULPの一部は実装依存であることに留意されたいです。
* Privileged ULP - See Section 1, Introduction, for a definition of Privileged ULP. The local host infrastructure can enable the Privileged ULP to map a Data Buffer directly from the RNIC Engine to the host through the RNIC Interface, but it does not allow the Privileged ULP to directly consume RNIC Engine resources.
*特権ULP - 特権ULPの定義については、第1、はじめにを参照してください。ローカルホストインフラストラクチャは、RNICインタフェースを介してホストにRNIC Engineから直接データバッファをマップするために特権ULPを有効にすることができますが、それは特権ULPが直接RNICエンジンのリソースを消費することはできません。
* Non-Privileged ULP - See Section 1, Introduction, for a definition of Non-Privileged ULP.
*非特権ULP - 非特権ULPの定義については、第1、はじめに、参照してください。
A design goal of the DDP and RDMAP protocols is to allow, under constrained conditions, Non-Privileged ULP to send and receive data directly to/from the RDMA Engine without Privileged Resource Manager intervention, while ensuring that the host remains secure. Thus, one of the primary goals of this document is to analyze this usage model for the enforcement that is required in the RNIC Engine to ensure that the system remains secure.
DDPとRDMAPプロトコルの設計目標は、ホストが安全なままであることを保証しながら、特権リソースマネージャの介入なしRDMAエンジンへ/から直接データを送受信するために、制約条件の下で、非特権ULPを可能にすることです。したがって、この文書の主な目標の一つは、システムが安全なままであることを保証するために、RNICエンジンに必要とされる執行のために、この使用モデルを分析することです。
DDP provides two mechanisms for transferring data:
DDPは、データを転送するための2つのメカニズムを提供します。
* Untagged Data Transfer - The incoming payload simply consumes the first buffer in a queue of buffers that are in the order specified by the receiving Peer (commonly referred to as the Receive Queue), and
*タグなしデータ転送 - 着信ペイロードが単に受信ピア（一般的に受信キューと呼ぶ）で指定された順序であるバッファのキュー内の最初のバッファを消費し、そして
* Tagged Data Transfer - The Peer transmitting the payload explicitly states which destination buffer is targeted, through use of an STag. STag-based transfers allow the receiving ULP to be indifferent to what order (or in what messages) the opposite Peer sent the data, or in what order packets are received.
*タグ付きデータ転送 - ペイロードを送信するピアが明示のSTagを使用して、バッファが対象とされた先述べています。 STagベースの転送は、受信ULPは、どのような順序（又はどのメッセージ内）に無関心であることを可能にする反対側のピアは、データを送信し、またはどのような順序でパケットが受信されます。
Both data transfer mechanisms are also enabled through RDMAP, with additional control semantics. Typically, Tagged Data Transfer can be used for payload transfer, while Untagged Data Transfer is best used for control messages. However, each Upper Layer Protocol can determine the optimal use of Tagged and Untagged messages for itself. See [APPLICABILITY] for more information on application applicability for the two transfer mechanisms.
どちらのデータ転送メカニズムは、また、追加の制御セマンティクスで、RDMAPで有効にされています。タグなしのデータ転送は、最高の制御メッセージのために使用されている間、典型的には、タグ付きデータ転送は、ペイロード転送のために使用することができます。しかし、それぞれの上位層プロトコルは、自身のために、タグ付きおよびタグなしのメッセージの最適な使用を決定することができます。 2つの搬送機構のアプリケーションの適用の詳細については、[利用可能]を参照してください。
For DDP, the two forms correspond to Untagged and Tagged DDP Messages, respectively. For RDMAP, the two forms correspond to Send Type Messages and RDMA Messages (either RDMA Read or RDMA Write Messages), respectively.
DDPのために、2つの形式はそれぞれ、タグなしおよびタグ付きDDPメッセージに対応します。 RDMAPのために、2つの形式は、それぞれの種類のメッセージとRDMAメッセージ（RDMA読み取りまたはRDMA書き込みメッセージのいずれか）を送信するために対応しています。
The host interfaces that could be exercised include:
行使することができるホストインタフェースは、次のとおり
* Privileged Control Interface - A Privileged Resource Manager uses the RNIC Interface to allocate and manage RNIC Engine resources, control the state within the RNIC Engine, and monitor various events from the RNIC Engine. It also uses this interface to act as a proxy for some operations that a Non-Privileged ULP may require (after performing appropriate countermeasures).
*特権制御インタフェース - 特権リソースマネージャは、割り当て、RNICエンジンのリソースを管理、RNICエンジン内の状態を制御し、RNICエンジンからの様々なイベントを監視するために、RNICインタフェースを使用しています。それはまた、非特権ULPは、（適切な対策を実行した後に）必要とするかもしれないことをいくつかの操作のためのプロキシとして動作するためにこのインタフェースを使用します。
* ULP Control Interface - A ULP uses this interface to the Privileged Resource Manager to allocate RNIC Engine resources. The Privileged Resource Manager implements countermeasures to ensure that, if the Non-Privileged ULP launches an attack, it can prevent the attack from affecting other ULPs.
* ULPコントロールインタフェース - ULPは、RNIC Engineのリソースを割り当てる特権リソース・マネージャに、このインターフェイスを使用しています。特権リソースマネージャは、非特権ULPが攻撃を起動する場合、それは他のULPに影響を与えるからの攻撃を防ぐことができ、ことを確実にするための対策を実装しています。
* Non-Privileged Data Transfer Interface - A Non-Privileged ULP uses this interface to initiate and check the status of data transfer operations.
*非特権データ転送インタフェース - 非特権ULPを開始し、データ転送操作のステータスを確認するためにこのインタフェースを使用します。
* Privileged Data Transfer Interface - A superset of the functionality provided by the Non-Privileged Data Transfer Interface. The ULP is allowed to directly manipulate RNIC Engine mapping resources to map an STag to a ULP Data Buffer.
*特権データ転送インタフェース - 非特権データ転送インタフェースによって提供される機能のスーパーセット。 ULPは、直接ULPデータバッファへのSTagをマップするためにRNICエンジンマッピングリソースを操作することが許可されています。
If Internet control messages, such as ICMP, ARP, RIPv4, etc. are processed by the RNIC Engine, the threat analyses for those protocols is also applicable, but outside the scope of this document.
などICMP、ARP、RIPv4、などのインターネット制御メッセージは、RNICエンジンによって処理されている場合、脅威は、これらのプロトコルのための分析も適用可能であるが、この文書の範囲外。
This section describes the primary resources in the RNIC Engine that could be affected if under attack. For RDMAP, all the defined resources apply. For DDP, all the resources except the RDMA Read Queue apply.
このセクションでは、攻撃を受けた場合に影響を受ける可能性がRNICエンジンの主要なリソースについて説明します。 RDMAPのために、定義されたすべてのリソースが適用されます。 DDPのために、RDMA読むキューを除くすべてのリソースが適用されます。
The state information for each Stream is maintained in memory, which could be located in a number of places - on the NIC, inside RAM attached to the NIC, in host memory, or in any combination of the three, depending on the implementation.
実装に応じて、ホストメモリ内、又は3つの任意の組み合わせで、NICに取り付けられたRAMの内部に、NICに - 各ストリームの状態情報は、多くの場所に配置することができるメモリ内に維持されます。
Stream Context Memory includes state associated with Data Buffers. For Tagged Buffers, this includes how STag names, Data Buffers, and Page Translation Tables (see Section 2.2.3) interrelate. It also includes the list of Untagged Data Buffers posted for reception of Untagged Messages (commonly called the Receive Queue), and a list of operations to perform to send data (commonly called the Send Queue).
ストリームコンテキストメモリは、データ・バッファに関連付けられている状態を含みます。タグ付きバッファの場合、これはどのようにクワガタ名、データバッファ、およびページ変換テーブル（2.2.3項を参照）を相互に関係が含まれています。また、タグなしデータバッファのリストは、タグなし（一般的に受信キューと呼ばれる）メッセージ、および（一般的に送信キューと呼ばれる）のデータを送信するために実行する操作のリストの受信を掲載含まれています。
As mentioned previously, there are two different ways to expose a local ULP's Data Buffers for data transfer: Untagged Data Transfer, where a buffer can be exposed for receiving RDMAP Send Type Messages (a.k.a. DDP Untagged Messages) on DDP Queue zero, or Tagged Data Transfer, where the buffer can be exposed for remote access through STags (a.k.a. DDP Tagged Messages). This distinction is important because the attacks and the countermeasures used to protect against the attack are different depending on the method for exposing the buffer to the network.
先に述べたように、データ転送のためにローカルULPのデータ・バッファを露出するための2つの異なる方法がありますバッファがRDMAPを受信するために露出させることができるタグなしのデータ転送は、DDPキューゼロ、又はタグ付きデータに型メッセージ（別名DDPタグなしメッセージ）を送信しますバッファはスタッグス（別名DDPタグ付きメッセージ）を介してリモート・アクセスのために露出させることができる転写、。攻撃や攻撃から保護するために使用さ対策がネットワークにバッファを露出させるための方法に応じて異なっているので、この区別は重要です。
For the purposes of the security discussion, for Tagged Data Transfer, a single logical Data Buffer is exposed with a single STag on a given Stream. Actual implementations may support scatter/gather capabilities to enable multiple physical data buffers to be accessed with a single STag, but from a threat analysis perspective, it is assumed that a single STag enables access to a single logical Data Buffer.
セキュリティ上の議論の目的のために、タグ付きデータ転送のために、単一の論理データ・バッファは、指定されたストリーム上の単一のSTagで露光されます。実際の実装では、単一のSTagでアクセスされる複数の物理データバッファを有効にする機能を収集/散乱をサポートすることができるが、脅威分析の観点から、単一のSTagは、単一の論理データバッファへのアクセスを可能にしているものとします。
In any event, it is the responsibility of the Privileged Resource Manager to ensure that no STag can be created that exposes memory that the consumer had no authority to expose.
いずれにせよ、それは何のSTagは、消費者が公開する権限を持っていたメモリを公開するように作成できないことを確実にする特権リソース・マネージャの責任です。
A Data Buffer has specific access rights. The local ULP can control whether a Data Buffer is exposed for local only, or local and remote access, and assign specific access privileges (read, write, read and write) on a per Stream basis.
データバッファは、特定のアクセス権を持っています。ローカルULPは、ストリームごとに（読み取り、書き込み、読み出しおよび書き込み）データバッファは、ローカル、またはローカルおよびリモートアクセスのために露出されているかどうかを制御し、特定のアクセス権限を割り当てることができます。
For DDP, when an STag is Advertised, the Remote Peer is presumably given write access rights to the data (otherwise, there would not be much point to the Advertisement). For RDMAP, when a ULP Advertises an STag, it can enable write-only, read-only, or both write and read access rights.
STagがアドバタイズされたときにDDPについては、リモートピアは、おそらく（そうでない場合は、広告に多くのポイントがあるではないでしょう）、データへの書き込みアクセス権を与えられています。 ULPはのSTagをアドバタイズするときRDMAPのために、それは読み取り専用、書き込み専用有効にすることができ、またはその両方が書いて、アクセス権をお読みください。
Similarly, some ULPs may wish to provide a single buffer with different access rights on a per Stream basis. For example, some Streams may have read-only access, some may have remote read and write access, while on other Streams, only the local ULP/Local Peer is allowed access.
同様に、いくつかのULPは、ストリームごとに異なるアクセス権を持つ単一のバッファを提供することを望むかもしれません。例えば、いくつかのストリームは、アクセスのみを読んだことがあり、いくつかは、リモート読んだことがあり、他のストリーム上で、唯一の地元のULP /ローカルピアがアクセスを許可されている間、書き込みアクセスを。
Page Translation Tables are the structures used by the RNIC to be able to access ULP memory for data transfer operations. Even though these structures are called "Page" Translation Tables, they may not reference a page at all - conceptually, they are used to map a ULP address space representation (e.g., a virtual address) of a buffer to the physical addresses that are used by the RNIC Engine to move data. If, on a specific system, a mapping is not used, then a subset of the attacks examined may be appropriate. Note that the Page Translation Table may or may not be a shared resource.
ページ変換テーブルは、データ転送操作のためのULPメモリにアクセスできるようにRNICによって使用される構造です。これらの構造は、「ページ」変換テーブルと呼ばれているにもかかわらず、彼らはすべてのページを参照しないこと - 概念的に、彼らが使用されている物理アドレスに、バッファのULPアドレス空間表現（例えば、仮想アドレス）をマップするために使用されていますRNICエンジンでデータを移動します。 、特定のシステム上で、マッピングが使用されていない場合、検査攻撃のサブセットが適切であり得ます。ページ変換テーブルがまたは共有リソースであってもなくてもよいことに注意してください。
A Protection Domain (PD) is a local construct to the RDMA implementation, and never visible over the wire. Protection Domains are assigned to three of the resources of concern - Stream Context Memory, STags associated with Page Translation Table entries, and Data Buffers. A correct implementation of a Protection Domain requires that resources that belong to a given Protection Domain cannot be used on a resource belonging to another Protection Domain, because Protection Domain membership is checked by the RNIC prior to taking any action involving such a resource. Protection Domains are therefore used to ensure that an STag can only be used to access an associated Data Buffer on one or more Streams that are associated with the same Protection Domain as the specific STag.
保護ドメイン（PD）は、ローカルRDMA実装に構築、及びワイヤ上決して見えます。ストリームコンテキストメモリ、ページ変換テーブルエントリに関連付けられたスタッグス、およびデータ・バッファ - 保護ドメインは、懸念の資源の3に割り当てられています。保護ドメインの正しい実装は、保護ドメインのメンバシップが、このようなリソースを含む任意のアクションを取る前にRNICによって確認されたため、指定された保護ドメインに属するリソースは、別の保護ドメインに属するリソース上で使用することができないことが必要です。保護ドメインは、したがってのSTagのみ特定のSTagと同じ保護ドメインに関連付けられている1つ以上のストリームに関連付けられたデータバッファにアクセスするために使用することができることを保証するために使用されます。
If an implementation chooses not to share resources between Streams, it is recommended that each Stream be associated with its own, unique Protection Domain. If an implementation chooses to allow resource sharing, it is recommended that Protection Domain be limited to the collection of Streams that have Partial Mutual Trust with each other.
実装はストリーム間でリソースを共有しないことを選択した場合は、各ストリームは独自の、ユニークな保護ドメインに関連付けすることをお勧めします。実装は、リソースの共有を許可することを選択した場合は、保護ドメインが互いに部分的な相互信頼を持っているストリームの集合に限定することをお勧めします。
Note that a ULP (either Privileged or Non-Privileged) can potentially have multiple Protection Domains. This could be used, for example, to ensure that multiple clients of a server do not have the ability to corrupt each other. The server would allocate a Protection Domain per client to ensure that resources covered by the Protection Domain could not be used by another (untrusted) client.
（特権または非特権のいずれか）ULPは、潜在的に複数の保護ドメインを持つことができることに注意してください。これは、サーバーの複数のクライアントが壊れてお互いに能力を持っていないことを確認するために、例えば、使用することができます。サーバーは、保護ドメインによってカバーされたリソースは、別の（信頼できない）クライアントで使用することができなかったことを確実にするために、クライアントごとに保護ドメインを割り当てるでしょう。
The DDP specification defines a 32-bit namespace for the STag. Implementations may vary in terms of the actual number of STags that are supported. In any case, this is a bounded resource that can come under attack. Depending upon STag namespace allocation algorithms, the actual name space to attack may be significantly less than 2^32.
DDP仕様はのSTagのために32ビットの名前空間を定義します。実装がサポートされてスタッグスの実際の数の点で変化してもよいです。いずれにせよ、これは攻撃の下に来ることができ有界資源です。 STag名前空間の割り当てアルゴリズムに応じて、攻撃するために実際の名前空間が2 ^ 32よりも大幅に小さくすることができます。
The scope of an STag is the set of DDP/RDMAP Streams on which the STag is valid. If an STag is valid on a particular DDP/RDMAP Stream, then that stream can modify the buffer, subject to the access rights that the stream has for the STag (see Section 2.2.2, Data Buffers, for additional information).
STagのスコープはのSTagが有効であるにDDP / RDMAPストリームのセットです。 STagは、特定のDDP / RDMAPストリーム上で有効である場合、そのストリームは、ストリームがのSTagのために持っているアクセス権の対象バッファを、（追加情報については、セクション2.2.2、データバッファを参照）を変更することができます。
The analysis presented in this document assumes two mechanisms for limiting the scope of Streams for which the STag is valid:
この文書の分析はのSTagが有効であるストリームの範囲を制限するための2つのメカニズムを前提としています。
* Protection Domain scope. The STag is valid if used on any Stream within a specific Protection Domain, and is invalid if used on any Stream that is not a member of the Protection Domain.
*保護ドメインスコープ。 STagは、特定の保護ドメイン内の任意のストリーム上で使用している場合有効であり、保護ドメインのメンバーではないいずれかのストリーム上で使用している場合は無効です。
* Single Stream scope. The STag is valid on a single Stream, regardless of what the Stream association is to a Protection Domain. If used on any other Stream, it is invalid.
*単一ストリームスコープ。 STagは関係なく、ストリーム協会が保護ドメインにあるものの、単一のストリーム上で有効です。他のストリームで使用した場合、それは無効です。
Completion Queues (CQ) are used in this document to conceptually represent how the RNIC Engine notifies the ULP about the completion of the transmission of data, or the completion of the reception of data through the Data Transfer Interface (specifically for Untagged Data Transfer; Tagged Data Transfer cannot cause a completion to occur). Because there could be many transmissions or receptions in flight at any one time, completions are modeled as a queue rather than as a single event. An implementation may also use the Completion Queue to notify the ULP of other activities; for example, the completion of a mapping of an STag to a specific ULP buffer. Completion Queues may be shared by a group of Streams, or may be designated to handle a specific Stream's traffic. Limiting Completion Queue association to one, or a small number, of RDMAP/DDP Streams can prevent several forms of attacks by sharply limiting the scope of the attack's effect.
完了キュー（CQ）はRNICエンジンは、データの送信、または特異的タグなしデータ転送のためのデータ転送インタフェース（介してデータの受信完了の完了についてULPに通知する方法を概念的に表すために、この文書で使用され、タグ付きデータ転送が完了を発生させることはできません）。いずれかの時点での飛行には多くの送信または受信のがあるかもしれないので、補完はキューとしてではなく、単一のイベントとしてモデル化されています。また、実装は他の活動のULPに通知する完了キューを使用することができます。例えば、特定のULPバッファへのSTagのマッピングが完了しました。完了キューは、Streamsのグループで共有することができる、または特定のストリームのトラフィックを処理するように指定することができます。 1に完了キューの関連付けを制限、またはRDMAP / DDPストリームの数が少ない、鋭く攻撃の効果の範囲を制限することによって、攻撃のいくつかの形を防ぐことができます。
Some implementations may allow this queue to be manipulated directly by both Non-Privileged and Privileged ULPs.
いくつかの実装は、このキューは非特権および特権のULPの両方で直接操作することを可能にすることができます。
The Asynchronous Event Queue is a queue from the RNIC to the Privileged Resource Manager of bounded size. It is used by the RNIC to notify the host of various events that might require management action, including protocol violations, Stream state changes, local operation errors, low water marks on receive queues, and possibly other events.
非同期イベントキューは、有界サイズの特権リソースマネージャへのRNICからキューです。プロトコル違反、ストリーム状態が変化すると、ローカル操作エラー、受信キューの低ウォーターマーク、およびおそらく他のイベントなどの管理アクションを必要とするかもしれない様々なイベントのホストに通知するためにRNICによって使用されます。
The Asynchronous Event Queue is a resource that can be attacked because Remote or Local Peers and/or ULPs can cause events to occur that have the potential of overflowing the queue.
非同期イベントキューは、リモートまたはローカルピアおよび/またはのULPは、キューのオーバーフローの可能性を秘めていることに発生する事象を引き起こす可能性があるので、攻撃される可能資源です。
Note that an implementation is at liberty to implement the functions of the Asynchronous Event Queue in a variety of ways, including multiple queues or even simple callbacks. All vulnerabilities identified are intended to apply, regardless of the implementation of the Asynchronous Event Queue. For example, a callback function may be viewed simply as a very short queue.
実装は複数のキュー、あるいは、単純なコールバックを含め、さまざまな方法で非同期イベントキューの機能を実現するために自由であることに注意してください。特定されたすべての脆弱性は、非同期イベントキューの実装にかかわらず、適用することを意図しています。たとえば、コールバック関数は、単に非常に短いキューと見なすことができます。
The RDMA Read Request Queue is the memory that holds state information for one or more RDMA Read Request Messages that have arrived, but for which the RDMA Read Response Messages have not yet been completely sent. Because potentially more than one RDMA Read Request can be outstanding at one time, the memory is modeled as a queue of bounded size. Some implementations may enable sharing of a single RDMA Read Request Queue across multiple Streams.
RDMA読み取り要求キューが到着しましたが、そのためにRDMA読み取り応答メッセージはまだ完全に送信されていない1つの以上のRDMA読み取り要求メッセージの状態情報を保持するメモリです。 1つのRDMA読み取り要求よりも潜在的には、一度に優れた可能性があるので、メモリが制限されたサイズのキューとしてモデル化されています。いくつかの実装では、複数のストリームにまたがる単一のRDMA読み取り要求キューの共有を可能にしてもよいです。
With RNIC resources and interfaces defined, it is now possible to examine the interactions supported by the generic RNIC functional interfaces through each of the 3 interfaces: Privileged Control Interface, Privileged Data Interface, and Non-Privileged Data Interface. As mentioned previously in Section 2.1, Components, there are two data transfer mechanisms to be examined, Untagged Data Transfer and Tagged Data Transfer.
特権制御インタフェース、特権データインタフェース、および非特権データインタフェース：RNICリソースと定義されたインタフェースと、3つのインターフェースのそれぞれを通じてジェネリックRNIC機能インタフェースによってサポートされる相互作用を検査することが可能です。 2.1節で先に述べたように、コンポーネントは、検査される2つのデータ転送メカニズム、タグなしデータ転送とタグ付きデータ転送があります。
Generically, the Privileged Control Interface controls the RNIC's allocation, de-allocation, and initialization of RNIC global resources. This includes allocation and de-allocation of Stream Context Memory, Page Translation Tables, STag names, Completion Queues, RDMA Read Request Queues, and Asynchronous Event Queues.
一般的に、特権制御インタフェースは、RNICの割り当て、割り当て解除、およびRNICグローバルリソースの初期化を制御します。これは、割り当てとストリームコンテキストメモリの割り当て解除、ページ変換テーブル、クワガタ名、完了キュー、RDMA読み取り要求キュー、および非同期イベントキューが含まれています。
The Privileged Control Interface is also typically used for managing Non-Privileged ULP resources for the Non-Privileged ULP (and possibly for the Privileged ULP as well). This includes initialization and removal of Page Translation Table resources, and managing RNIC events (possibly managing all events for the Asynchronous Event Queue).
特権制御インタフェースは、また、一般的に（だけでなく、おそらく特権ULPのための）非特権ULPのための非特権ULPのリソースを管理するために使用されます。これは、ページ変換テーブルのリソースの初期化や削除を含み、そして（おそらく非同期イベントキューのすべてのイベントを管理する）RNICイベントを管理します。
The Non-Privileged Data Interface enables data transfer (transmit and receive) but does not allow initialization of the Page Translation Table resources. However, once the Page Translation Table resources have been initialized, the interface may enable a specific STag mapping to be enabled and disabled by directly communicating with the RNIC, or create an STag mapping for a buffer that has been previously initialized in the RNIC.
非特権データインタフェースは、（送信と受信）のデータ転送を可能にしますが、ページ変換テーブルのリソースの初期化を許可していません。ページ変換テーブルのリソースが初期化されていますしかし、一度、インターフェースが直接RNICと通信することにより、有効と無効にする特定のクワガタマッピングを有効にする、または以前にRNICに初期化されているバッファのためのクワガタマッピングを作成することがあります。
For RDMAP, ULP data can be sent by one of the previously described data transfer mechanisms: Untagged Data Transfer or Tagged Data Transfer. Two RDMAP data transfer mechanisms are defined, one using Untagged Data Transfer (Send Type Messages), and one using Tagged Data Transfer (RDMA Read Responses and RDMA Writes). ULP data reception through RDMAP can be done by receiving Send Type Messages into buffers that have been posted on the Receive Queue or Shared Receive Queue. Thus, a Receive Queue or Shared Receive Queue can only be affected by Untagged Data Transfer. Data reception can also be done by receiving RDMA Write and RDMA Read Response Messages into buffers that have previously been exposed for external write access through Advertisement of an STag (i.e., Tagged Data Transfer). Additionally, to cause ULP data to be pulled (read) across the network, RDMAP uses an RDMA Read Request Message (which only contains RDMAP control information necessary to access the ULP buffer to be read), to cause an RDMA Read Response Message to be generated that contains the ULP data.
タグなしのデータ転送またはタグ付きデータ転送：RDMAPため、ULPデータは、先に説明したデータ転送メカニズムのいずれかによって送信することができます。二RDMAPデータ転送メカニズムは（型メッセージを送る）タグなしのデータ転送を使用して1、定義され、いずれかを使用してタグ付きデータ転送（RDMA読み取り応答とRDMAを書き込み）しています。 RDMAPてULPデータ受信が受信キューに掲示または受信キュー共有されているバッファに型メッセージを送信し受信することによって行うことができます。このように、受信キューまたは共有キューのみタグなしデータ転送によって影響を受ける可能性が受信します。データの受信は、以前のSTag（すなわち、タグ付きデータ転送）の広告を介して外部の書き込みアクセスのために露出されているバッファにRDMA書き込みとRDMA読み取り応答メッセージを受信することによってもを行うことができます。また、ネットワークを介して（読んで）ULPデータを引っ張っさせるように、RDMAPは、RDMA読み取り応答メッセージにさせるために、（読み取り専用にするULPバッファにアクセスするために必要なRDMAP制御情報が含まれています）RDMA読み取り要求メッセージを使用していますULPデータが含まれていることを生成しました。
For DDP, transmitting data means sending DDP Tagged or Untagged Messages. For data reception, DDP can receive Untagged Messages into buffers that have been posted on the Receive Queue or Shared Receive Queue. It can also receive Tagged DDP Messages into buffers that have previously been exposed for external write access through Advertisement of an STag.
DDPのために、データを送信することは、DDPタグ付きまたはタグなしのメッセージを送ることを意味します。データ受信のために、DDPは、受信キューに掲示または受信キュー共有されているバッファにタグなしのメッセージを受け取ることができます。また、以前のSTagの広告を介して外部の書き込みアクセスのために露出されているバッファにタグ付きDDPメッセージを受け取ることができます。
Completion of data transmission or reception generally entails informing the ULP of the completed work by placing completion information on the Completion Queue. For data reception, only an Untagged Data Transfer can cause completion information to be put in the Completion Queue.
データ送信または受信の完了は、一般に完了キューに完了情報を配置することによって完了した作業のULPに通知することを伴います。データ受信のために、唯一のタグなしデータ転送は完了情報が完了キューに置かれることがあります。
The Privileged Data Interface semantics are a superset of the Non-Privileged Data Transfer semantics. The interface can do everything defined in the prior section, as well as create/destroy buffer to STag mappings directly. This generally entails initialization or clearing of Page Translation Table state in the RNIC.
特権データインタフェースのセマンティクスは、非特権データ転送のセマンティクスのスーパーセットです。インターフェイスは、直接クワガタマッピングする前のセクションで定義されたすべてのものだけでなく、作成/破棄バッファを行うことができます。これは、一般的にRNICでページ変換テーブルの状態の初期化や消去を伴います。
Initialization of the mapping between an STag and a Data Buffer can be viewed in the abstract as two separate operations:
STagとデータバッファとの間のマッピングの初期化は、2つの別個の動作として抽象的に見ることができます。
a. Initialization of the allocated Page Translation Table entries with the location of the Data Buffer, and
A。データバッファの場所に割り当てられたページ変換テーブルエントリの初期化、および
b. Initialization of a mapping from an allocated STag name to a set of Page Translation Table entry(s) or partial entries.
B。ページ変換テーブルのエントリ（複数可）または部分的なエントリのセットに割り当てられクワガタ名からマッピングの初期化。
Note that an implementation may not have a Page Translation Table (i.e., it may support a direct mapping between an STag and a Data Buffer). If there is no Page Translation Table, then attacks based on changing its contents or exhausting its resources are not possible.
（すなわち、それはのSTagとデータバッファとの間の直接マッピングをサポートすることができる）の実装は、ページ変換テーブルを有していなくてもよいことに留意されたいです。何ページ変換テーブルが存在しない場合は、その内容を変更したり、そのリソースを消耗に基づく攻撃はできません。
Initialization of the contents of the Page Translation Table can be done by either the Privileged ULP or by the Privileged Resource Manager as a proxy for the Non-Privileged ULP. By definition, the Non-Privileged ULP is not trusted to directly manipulate the Page Translation Table. In general, the concern is that the Non-Privileged ULP may try to maliciously initialize the Page Translation Table to access a buffer for which it does not have permission.
ページ変換テーブルの内容の初期化は、非特権ULPのプロキシとしてのいずれかの特権ULPによって、または特権リソースマネージャによって行うことができます。定義によると、非特権ULPは、直接ページ変換テーブルを操作するために信頼されていません。一般的には、懸念は非特権ULPは、悪意を持って、それが権限のないバッファにアクセスするページ変換テーブルを初期化しようとするかもしれないということです。
The exact resource allocation algorithm for the Page Translation Table is outside the scope of this document. It may be allocated for a specific Data Buffer, or as a pooled resource to be consumed by potentially multiple Data Buffers, or be managed in some other way. This document attempts to abstract implementation dependent issues, and group them into higher level security issues, such as resource starvation and sharing of resources between Streams.
ページ変換テーブルの正確なリソース割り当てアルゴリズムは、この文書の範囲外です。これは、特定のデータバッファに割り当てられてもよいし、プールされたリソースとして潜在的に複数のデータ・バッファによって消費される、または他の何らかの方法で管理します。この文書では、抽象実装依存の問題にしようとし、そして、そのような資源の枯渇とストリーム間のリソースの共有など、より高いレベルのセキュリティの問題、にグループにそれらを。
The next issue is how an STag name is associated with a Data Buffer. For the case of an Untagged Data Buffer (i.e., Untagged Data Transfer), there is no wire visible mapping between an STag and the Data Buffer. Note that there may, in fact, be an STag that represents the buffer, if an implementation chooses to internally represent Untagged Data Buffer using STags. However, because the STag, by definition, is not visible on the wire, this is a local host, implementation-specific issue that should be analyzed in the context of a local host implementation-specific security analysis, and thus, is outside the scope of this document.
次の問題は、クワガタ名がデータバッファに関連付けられている方法です。タグなしデータバッファ（すなわち、タグなしのデータ転送）の場合について、のSTagとデータバッファとの間にワイヤ可視マッピングが存在しません。インプリメンテーションは内部スタッグスを使用してタグなしデータバッファを表現することを選択した場合、実際には、バッファを表すのSTagが存在し得ることに留意されたいです。 STagは、定義により、ワイヤ上の表示されていないためしかし、これは、ローカルホストの実装固有のセキュリティ分析の文脈において分析されるべきローカルホスト、実装に固有の問題であり、したがって、範囲外でありますこのドキュメントの。
For a Tagged Data Buffer (i.e., Tagged Data Transfer), either the Privileged ULP or the Privileged Resource Manager acting on behalf of the Non-Privileged ULP may initialize a mapping from an STag to a Page Translation Table, or may have the ability to simply enable/disable an existing STag to Page Translation Table mapping. There may also be multiple STag names that map to a specific group of Page Translation Table entries (or sub-entries). Specific security issues with this level of flexibility are examined in Section 6.2.3, Multiple STags to Access the Same Buffer.
タグ付きデータバッファ（すなわち、タグ付きデータ転送）については、いずれかの非特権ULPのために行動する特権ULPまたは特権リソースマネージャは、ページ変換表へのSTagからのマッピングを初期化したり、する能力を持っていること単に有効/ページ変換テーブルへのマッピング既存のSTagを無効にします。また、ページ変換テーブルエントリ（またはサブエントリ）の特定のグループにマッピングする複数のSTag名が存在してもよいです。柔軟性のこのレベルでの具体的なセキュリティ上の問題は同じバッファをアクセスするための第6.2.3項、複数のスタッグスで検討されています。
There are a variety of implementation options for initialization of Page Translation Table entries and mapping an STag to a group of Page Translation Table entries that have security repercussions. This includes support for separation of mapping an STag versus mapping a set of Page Translation Table entries, and support for ULPs directly manipulating STag to Page Translation Table entry mappings (versus requiring access through the Privileged Resource Manager).
ページ変換テーブルエントリの初期化とセキュリティの影響を持っているページ変換テーブルエントリのグループにのSTagをマッピングするための実装のさまざまなオプションがあります。これは、ページ変換テーブル・エントリのセットをマッピングし、そしてのULPのサポートが直接（特権リソースマネージャを介してアクセスを必要と対）ページ変換テーブルエントリマッピングへのSTagを操作対のSTagのマッピングを分離するためのサポートを含みます。
RNIC Data Transfer operations can be subdivided into send and receive operations.
RNICデータ転送動作は、送信に細分化し、操作を受け取ることができます。
For send operations, there is typically a queue that enables the ULP to post multiple operation requests to send data (referred to as the Send Queue). Depending upon the implementation, Data Buffers used in the operations may or may not have Page Translation Table entries associated with them, and may or may not have STags associated with them. Because this is a local host specific implementation issue rather than a protocol issue, the security analysis of threats and mitigations is left to the host implementation.
送信操作の場合は、（送信キューと呼ばれる）のデータを送信するために、複数の操作要求を投稿することができますULPキューは、一般的にあります。実装に応じて、業務で使用されるデータ・バッファは、またはそれらに関連するページ変換テーブルエントリがあってもなくてもよい、及びまたはそれらに関連したスタッグスを持っていない可能性があります。これは、ローカルホストの特定の実装の問題ではなく、プロトコルの問題ですので、脅威と緩和策のセキュリティ分析は、ホストの実装に任されています。
Receive operations are different for Tagged Data Buffers versus Untagged Data Buffers (i.e., Tagged Data Transfer vs. Untagged Data Transfer). For Untagged Data Transfer, if more than one Untagged Data Buffer can be posted by the ULP, the DDP specification requires that they be consumed in sequential order (the RDMAP specification also requires this). Thus, the most general implementation is that there is a sequential queue of receive Untagged Data Buffers (Receive Queue). Some implementations may also support sharing of the sequential queue between multiple Streams. In this case, defining "sequential" becomes non-trivial - in general, the buffers for a single Stream are consumed from the queue in the order that they were placed on the queue, but there is no consumption order guarantee between Streams.
操作はタグなしデータ・バッファ対タグ付きデータバッファ（タグなしのデータ転送対、すなわち、タグ付きデータ転送）のために異なって受け取ります。複数のタグなしデータバッファULPによって投稿することができた場合にタグなしデータ転送のために、DDP仕様は、彼らが順番（RDMAP仕様でも、これを必要とする）で消費されている必要があります。このように、最も一般的な実装では、タグなしのデータバッファを（受信キュー）受信のシーケンシャルキューが存在することです。一部の実装は、複数のストリーム間の順次キューの共有をサポートすることができます。この場合は、「シーケンシャル」を定義することは非自明となり - 一般的に、単一ストリームのためのバッファは、彼らがキューに配置された順序でキューから消費されますが、ストリーム間には消費順序を保証するものではありません。
For receive Tagged Data Transfer (i.e., Tagged Data Buffers, RDMA Write Buffers, or RDMA Read Buffers), at some time prior to data transfer, the mapping of the STag to specific Page Translation Table entries (if present) and the mapping from the Page Translation Table entries to the Data Buffer must have been initialized (see Section 2.3.4 for interaction details).
タグが付けられたデータ転送を受ける（すなわち、タグ付きデータバッファ、RDMAの書き込みバッファ、またはRDMA読み取りバッファ）、いくつかの時点でのデータ転送の前に、特定のページ変換テーブルエントリへのSTagのマッピング（存在する場合）とのマッピングデータバッファへのページ変換テーブルエントリは（相互作用の詳細については、セクション2.3.4を参照）が初期化されている必要があります。
It is assumed that, in general, the Local and Remote Peer are untrusted, and thus attacks by either should have mitigations in place.
一般的には、ローカルおよびリモートピアが信頼されていないので、どちらかによる攻撃が代わりに緩和策を持っている必要があり、想定されます。
A separate, but related issue is resource sharing between multiple Streams. If local resources are not shared, the resources are dedicated on a per Stream basis. Resources are defined in Section 2.2, Resources. The advantage of not sharing resources between Streams is that it reduces the types of attacks that are possible. The disadvantage of not sharing resources is that ULPs might run out of resources. Thus, there can be a strong incentive for sharing resources, if the security issues associated with the sharing of resources can be mitigated.
別の、しかし関連の問題は、複数のストリーム間のリソースの共有です。ローカルリソースが共有されていない場合は、リソースは、ストリームごとに専用されています。リソースは、セクション2.2、リソースで定義されています。ストリーム間でリソースを共有していないことの利点は、それが可能であり、攻撃の種類を減少させることです。リソースを共有しないという欠点がのULPは、リソースが不足するかもしれないということです。このように、リソースの共有に関連するセキュリティ上の問題を緩和することができる場合は、リソースを共有するための強力なインセンティブがあることができます。
It is assumed in this document that the component that implements the mechanism to control sharing of the RNIC Engine resources is the Privileged Resource Manager. The RNIC Engine exposes its resources through the RNIC Interface to the Privileged Resource Manager. All Privileged and Non-Privileged ULPs request resources from the Resource Manager (note that by definition both the Non-Privileged and the Privileged application might try to greedily consume resources, thus creating a potential Denial of Service (DOS) attack). The Resource Manager implements resource management policies to ensure fair access to resources. The Resource Manager should be designed to take into account security attacks detailed in this document. Note that for some systems the Privileged Resource Manager may be implemented within the Privileged ULP.
これは、RNICエンジンのリソースの共有を制御する機構を実装するコンポーネントは、特権リソース・マネージャである本書で想定されます。 RNICエンジンは、特権リソースマネージャにRNICインタフェースを通じてリソースを公開しています。リソースマネージャからのすべての特権と非特権のULP要求リソースは（定義非特権および特権アプリケーションの両方でこのように潜在的なサービス拒否（DoS）攻撃を作成し、貪欲リソースを消費しようとするかもしれないことに注意してください）。リソースマネージャは、リソースへの公平なアクセスを確保するために、リソース管理ポリシーを実装しています。リソースマネージャは、本書で詳述アカウントのセキュリティ攻撃に取るように設計されなければなりません。いくつかのシステムのための特権リソースマネージャは、特権ULP内に実装されてもよいことに注意してください。
All Non-Privileged ULP interactions with the RNIC Engine that could affect other ULPs MUST be done using the Privileged Resource Manager as a proxy. All ULP resource allocation requests for scarce resources MUST also be done using a Privileged Resource Manager.
他のULPに影響を与える可能性がRNICエンジンを搭載したすべての非特権ULP相互作用は、プロキシとして特権リソースマネージャを使用して行われなければなりません。希少資源のためのすべてのULPのリソース割り当て要求も特権リソースマネージャを使用して行われなければなりません。
The sharing of resources across Streams should be under the control of the ULP, both in terms of the trust model the ULP wishes to operate under, as well as the level of resource sharing the ULP wishes to give local processes. For more discussion on types of trust models that combine partial trust and sharing of resources, see Appendix C, Partial Trust Taxonomy.
ストリーム間でリソースの共有は、両方の信頼モデルULPの観点から、ULPの制御下になければならないの下で動作することを望む、並びにULPを共有リソースのレベルは、ローカル・プロセスを与えることを望みます。リソースの部分的な信頼と共有を組み合わせた信頼モデルの種類の詳細については、付録C、部分信頼分類を参照してください。
The Privileged Resource Manager MUST NOT assume that different Streams share Partial Mutual Trust unless there is a mechanism to ensure that the Streams do indeed share Partial Mutual Trust. This can be done in several ways, including explicit notification from the ULP that owns the Streams.
ストリームが実際に部分的な相互信頼を共有しないことを保証するメカニズムがない限り、特権Resource Managerが異なるストリームは、部分的な相互信頼を共有すると仮定してはいけません。これは、ストリームを所有しているULPからの明示的な通知を含むいくつかの方法で行うことができます。
An attacker's capabilities delimit the types of attacks that the attacker is able to launch. RDMAP and DDP require that the initial LLP Stream (and connection) be set up prior to transferring RDMAP/DDP Messages. This requires at least one round-trip handshake to occur.
攻撃者の能力は、攻撃者が起動することが可能であることを攻撃の種類を区切ります。 RDMAPとDDPは初期LLPストリーム（及び接続）RDMAP / DDPメッセージを転送する前に設定する必要があります。これが発生するために、少なくとも1つのラウンドトリップハンドシェイクが必要です。
If the attacker is not the Remote Peer that created the initial connection, then the attacker's capabilities can be segmented into send only capabilities or send and receive capabilities. Attacking with send only capabilities requires the attacker to first guess the current LLP Stream parameters before they can attack RNIC resources (e.g., TCP sequence number). If this class of attacker also has receive capabilities and the ability to pose as the receiver to the sender and the sender to the receiver, they are typically referred to as a "man-in-the-middle" attacker [RFC3552]. A man-in-the-middle attacker has a much wider ability to attack RNIC resources. The breadth of attack is essentially the same as that of an attacking Remote Peer (i.e., the Remote Peer that set up the initial LLP Stream).
攻撃者は、最初の接続を作成したリモートピアでない場合、攻撃者の能力は、送信機能のみにセグメント化や能力を送受信することができます。彼らはRNICリソース（例えば、TCPシーケンス番号）を攻撃することができます前に、送信機能のみを攻撃する最初の現在のLLPストリーム・パラメータを推測するために、攻撃者が必要です。攻撃者のこのクラスはまた、機能や送信者に受信機と受信機に送信者として提起する能力を受け取った場合、それらは一般的に「のman-in-the-middle」攻撃[RFC3552]と呼ばれています。 man-in-the-middle攻撃者は、RNICリソースを攻撃するより広い能力を持っています。攻撃の幅は、本質的に攻撃リモートピアと同じである（すなわち、初期LLPストリームを設定するリモートピア）。
This section describes the RDMAP/DDP attacks where the only solution is to implement some form of end-to-end security. The analysis includes a detailed description of each attack, what is being attacked, and a description of the countermeasures that can be taken to thwart the attack.
このセクションでは、唯一の解決策は、エンドツーエンドのセキュリティのいくつかのフォームを実装することですRDMAP / DDP攻撃を記述する。分析は、各攻撃の詳細な説明は、何が攻撃され、攻撃を阻止するために取ることができる対策の説明を含みます。
Some forms of attack involve modifying the RDMAP or DDP payload by a network-based attacker or involve monitoring the traffic to discover private information. An effective tool to ensure confidentiality is to encrypt the data stream through mechanisms, such as IPsec encryption. Additionally, authentication protocols, such as IPsec authentication, are an effective tool to ensure the remote entity is who they claim to be, as well as ensuring that the payload is unmodified as it traverses the network.
攻撃のいくつかの形態は、ネットワークベースの攻撃者によってRDMAPまたはDDPペイロードを修正関与や個人情報を発見するために、トラフィックの監視を伴います。機密性を確保するための効果的なツールは、IPSec暗号化のようなメカニズムを介してデータストリームを暗号化することです。また、このようなIPsec認証などの認証プロトコルは、リモートエンティティは、彼らがあると主張する人であることを確認し、並びにそれがネットワークを横断するようにペイロードが非修飾であることを保証するための有効なツールです。
Note that connection setup and tear down is presumed to be done in stream mode (i.e., no RDMA encapsulation of the payload), so there are no new attacks related to connection setup/tear down beyond what is already present in the LLP (e.g., TCP or SCTP). Note, however, that RDMAP/DDP parameters may be exchanged in stream mode, and if they are corrupted by an attacker unintended consequences will result. Therefore, any existing mitigations for LLP Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or
その接続設定に注意し、取り壊す（接続設定に関連する新たな攻撃が存在しないので（すなわち、ペイロードのないRDMAカプセル化）は、/既にLLPで存在しているものを超えて切断しないストリームモードで実行されていると推定される例えば、 TCPまたはSCTP）。注意は、しかし、そのRDMAP / DDPパラメータは、ストリームモードで交換することができる、と彼らは攻撃者によって破壊された場合、意図しない結果が発生します。 LLPなりすまし、改ざん、否認、情報開示、サービス拒否のためにそのため、既存の緩和策、または
Elevation of Privilege continue to apply (and are out of scope of this document). Thus, the analysis in this section focuses on attacks that are present, regardless of the LLP Stream type.
特権の昇格が引き続き適用され（この文書の範囲外です）。したがって、このセクションの分析に関係なくLLPのストリームタイプの、存在している攻撃に焦点を当てています。
Tampering is any modification of the legitimate traffic (machine internal or network). Spoofing attack is a special case of tampering where the attacker falsifies an identity of the Remote Peer (identity can be an IP address, machine name, ULP level identity, etc.).
改ざんは、正当なトラフィック（マシン内部またはネットワーク）のいずれかの変形例です。スプーフィング攻撃は、攻撃者がリモートピアのアイデンティティを誤らせるどこ改ざんの特殊なケースである（アイデンティティは、IPアドレス、マシン名、ULPレベルのアイデンティティなどすることができます）。
Spoofing attacks can be launched by the Remote Peer, or by a network-based attacker. A network-based spoofing attack applies to all Remote Peers. This section analyzes the various types of spoofing attacks applicable to RDMAP and DDP.
スプーフィング攻撃は、リモートピアによって、またはネットワークベースの攻撃者によって起動することができます。ネットワークベースのスプーフィング攻撃は、すべてのリモートピアに適用されます。このセクションでは、RDMAPとDDPに適用スプーフィング攻撃のさまざまなタイプを分析します。
A network-based attacker can impersonate a legal RDMAP/DDP Peer (by spoofing a legal IP address). This can either be done as a blind attack (see [RFC3552]) or by establishing an RDMAP/DDP Stream with the victim. Because an RDMAP/DDP Stream requires an LLP Stream to be fully initialized (e.g., for [RFC793], it is in the ESTABLISHED state), existing transport layer protection mechanisms against blind attacks remain in place.
ネットワークベースの攻撃者は、（合法のIPアドレスを偽装して）法的RDMAP / DDPピアになりすますことができます。これは、ブラインドアタック（[RFC3552]を参照）として、あるいは被害者とRDMAP / DDPストリームを確立することにより行うことができますどちらか。 RDMAP / DDPストリームが完全に（例えば、[RFC793]のために、それがESTABLISHED状態にある）初期化するLLPストリームを必要とするので、ブラインド攻撃に対する既存のトランスポート層の保護メカニズムは、所定の位置に残ります。
For a blind attack to succeed, it requires the attacker to inject a valid transport layer segment (e.g., for TCP, it must match at least the 4-tuple as well as guess a sequence number within the window) while also guessing valid RDMAP or DDP parameters. There are many ways to attack the RDMAP/DDP protocol if the transport protocol is assumed to be vulnerable. For example, for Tagged Messages, this entails guessing the STag and TO values. If the attacker wishes to simply terminate the connection, it can do so by correctly guessing the transport and network layer values, and providing an invalid STag. Per the DDP specification, if an invalid STag is received, the Stream is torn down and the Remote Peer is notified with an error. If an attacker wishes to overwrite an Advertised Buffer, it must successfully guess the correct STag and TO. Given that the TO will often start at zero, this is straightforward. The value of the STag should be chosen at random, as discussed in Section 6.1.1, Using an STag on a Different Stream. For Untagged Messages, if the MSN is invalid then the connection may be torn down. If it is valid, then the receive buffers can be corrupted.
また、有効なRDMAPを推測したりしながら、成功するために盲目の攻撃に対しては、有効なトランスポート層セグメント（例えば、TCPのために、それは、少なくとも4つのタプルと一致する必要がありますだけでなく、ウィンドウ内のシーケンス番号を推測）を注入する攻撃者が必要ですDDPパラメータ。トランスポートプロトコルが脆弱であると想定されている場合RDMAP / DDPプロトコルを攻撃する多くの方法があります。例えば、タグ付きメッセージのため、これはのSTagを推測し、値に伴います。攻撃者は、単に接続を終了したい場合は、それが正しく、トランスポートとネットワーク層の値を推測し、無効のSTagを提供することで、そうすることができます。無効のSTagを受信した場合DDP仕様に従って、Streamが取り壊され、リモートピアは、エラーが通知されます。攻撃者がアドバタイズバッファを上書きしたい場合は、それが正常に正しいのSTagとTOを推測しなければなりません。 TOは、多くの場合、ゼロからスタートすることを考えると、これは簡単です。別のストリーム上のSTagを使用して、セクション6.1.1で説明したようにのSTagの値は、ランダムに選択されるべきです。 MSNが無効な場合タグなしメッセージに対して、接続が切断されてもよいです。それが有効である場合は、インクルードは、バッファが破損する可能性が受け取ります。
End-to-end authentication (e.g., IPsec or ULP authentication) provides protection against either the blind attack or the connected attack.
エンドツーエンドの認証（例えば、IPSecまたはULP認証）ブラインド攻撃または接続された攻撃のいずれかに対する保護を提供します。
Stream hijacking happens when a network-based attacker eavesdrops on the LLP connection through the Stream establishment phase, and waits until the authentication phase (if such a phase exists) is completed successfully. The attacker then spoofs the IP address and re-directs the Stream from the victim to its own machine. For example, an attacker can wait until an iSCSI authentication is completed successfully, and then hijack the iSCSI Stream.
ストリームハイジャックは、ネットワークベースの攻撃者がストリーム確立フェーズを通してLLP接続で盗聴、及び認証段階まで待機する場合（そのような相が存在する場合）が起こる正常に完了されます。その後、攻撃者はIPアドレスを偽装して、独自のマシンに被害者からのストリームを再指示します。例えば、攻撃者がiSCSI認証が正常に完了するまで待ってから、iSCSIのストリームをハイジャックすることができます。
The best protection against this form of attack is end-to-end integrity protection and authentication, such as IPsec, to prevent spoofing. Another option is to provide a physically segregated network for security. Discussion of physical security is out of scope for this document.
この形式の攻撃に対する最善の保護は、なりすましを防ぐために、IPsecなどのエンド・ツー・エンドの完全性保護と認証、です。別のオプションは、セキュリティのために、物理的に隔離されたネットワークを提供することです。物理的なセキュリティの議論はこの文書の範囲外です。
Because the connection and/or Stream itself is established by the LLP, some LLPs are more difficult to hijack than others. Please see the relevant LLP documentation on security issues around connection and/or Stream hijacking.
接続および/またはそれ自体をストリームがLLPによって確立されているので、いくつかのLLPSは他よりもハイジャックすることがより困難です。接続および/またはストリームのハイジャックの周りのセキュリティ問題に関連LLPのドキュメントを参照してください。
If a network-based attacker has the ability to delete or modify packets that will still be accepted by the LLP (e.g., TCP sequence number is correct), then the Stream can be exposed to a man-in-the-middle attack. One style of attack is for the man-in-the-middle to send Tagged Messages (either RDMAP or DDP). If it can discover a buffer that has been exposed for STag enabled access, then the man-in-the-middle can use an RDMA Read operation to read the contents of the associated Data Buffer, perform an RDMA Write Operation to modify the contents of the associated Data Buffer, or invalidate the STag to disable further access to the buffer.
ネットワークベースの攻撃者が（例えば、TCPシーケンス番号が正しいか）まだLLPによって受け入れられるパケットを削除または変更する能力を有する場合、そのストリームはman-in-the-middle攻撃にさらされることができます。攻撃の一つのスタイルは、のman-in-the-middleタグ付きのメッセージ（RDMAPまたはDDPのいずれか）を送信するためのものです。それはのSTagのために露出されたバッファがアクセスを有効にし、その後のman-in-the-middleはの内容を変更するRDMA書き込み動作を実行し、関連するデータ・バッファの内容を読み取るためにRDMA読み取り操作を使用することができます発見することができた場合関連するデータバッファ、またはバッファへのさらなるアクセスを無効にするのSTagを無効化。
The best protection against this form of attack is end-to-end integrity protection and authentication, such as IPsec, to prevent spoofing or tampering. If authentication and integrity protections are not used, then physical protection must be employed to prevent man-in-the-middle attacks.
この形式の攻撃に対する最善の防御は、なりすましや改ざんを防ぐために、IPsecなどのエンド・ツー・エンドの完全性保護と認証、です。認証と完全性の保護が使用されていない場合は、物理的な保護がman-in-the-middle攻撃を防ぐために使用しなければなりません。
Because the connection/Stream itself is established by the LLP, some LLPs are more exposed to man-in-the-middle attack than others. Please see the relevant LLP documentation on security issues around connection and/or Stream hijacking.
接続は/ストリーム自体はLLPによって確立されているので、いくつかのLLPSはのman-in-the-middleする他よりも攻撃より公開されています。接続および/またはストリームのハイジャックの周りのセキュリティ問題に関連LLPのドキュメントを参照してください。
Another approach is to restrict access to only the local subnet/link, and provide some mechanism to limit access, such as physical security or 802.1.x. This model is an extremely limited deployment scenario, and will not be further examined here.
別のアプローチは、ローカルサブネット/リンクへのアクセスを制限し、そのような物理的なセキュリティまたは802.1.x.として、アクセスを制限するいくつかのメカニズムを提供することですこのモデルは、非常に限られた展開シナリオで、ここでさらに検討されることはありません。
This is actually a man-in-the-middle attack, but only on the content of the buffer, as opposed to the man-in-the-middle attack presented above, where both the signaling and content can be modified. See Section 5.1.3, Man-in-the-Middle Attack.
シグナリングおよびコンテンツの両方を変更することができる上記のman-in-the-middle攻撃とは対照的に、これは、実際にはman-in-the-middle攻撃であるが、唯一のバッファの内容に関する。セクション5.1.3、man-in-the-middle攻撃を参照してください。
An attacker that is able to eavesdrop on the network can read the content of all read and write accesses to a Peer's buffers. To prevent information disclosure, the read/written data must be encrypted. See also Section 5.1.3, Man-in-the-Middle Attack. The encryption can be done either by the ULP, or by a protocol that can provide security services to RDMAP and DDP (e.g., IPsec).
すべての読み取りと書き込みの内容を読むことができるネットワークを盗聴することができ、攻撃者は、ピアのバッファにアクセスします。情報開示を防ぐために、読み取り/書き込みデータが暗号化されなければなりません。また、セクション5.1.3、man-in-the-middle攻撃を参照してください。暗号化はULPによって、または（例えば、IPsec）のRDMAPとDDPにセキュリティサービスを提供することができるプロトコルのいずれかによって行うことができます。
Generally speaking, Stream confidentiality protects against eavesdropping. Stream and/or session authentication and integrity protection is a counter measurement against various spoofing and tampering attacks. The effectiveness of authentication and integrity against a specific attack depends on whether the authentication is machine level authentication (such as IPsec), or ULP authentication.
一般的に言えば、ストリームの機密性は、盗聴から保護します。ストリームおよび/またはセッション認証と完全性保護は、様々ななりすましや改ざん攻撃に対するカウンタ測定です。特定の攻撃に対しての認証と完全性の有効性は、認証が（IPsecなど）マシンレベルの認証、またはULP認証であるかどうかに依存します。
The following security services can be applied to an RDMAP/DDP Stream:
次のセキュリティ・サービスはRDMAP / DDPストリームに適用することができます。
1. Session confidentiality - Protects against eavesdropping (Section 5.3).
1.セッションの機密性は - 盗聴（5.3節）から保護します。
2. Per-packet data source authentication - Protects against the following spoofing attacks: network-based impersonation (Section 5.1.1) and Stream hijacking (Section 5.1.2).
2.パケット単位のデータソース認証 - 次のスプーフィング攻撃から保護：ネットワークベースの偽装（5.1.1項）とストリームのハイジャック（5.1.2項）。
3. Per-packet integrity - Protects against tampering done by network-based modification of buffer content (Section 5.2) and when combined with authentication, also protects against man-in-the-middle attacks (Section 5.1.3).
3.パケットごとの整合性は - バッファコンテンツのネットワークベースの変更（5.2節）および認証と組み合わせると、さらにman-in-the-middle攻撃（5.1.3項）から保護することによって行う改ざんから保護します。
4. Packet sequencing - protects against replay attacks, which is a special case of the above tampering attack.
4.パケットシーケンシング - 上記の改ざん攻撃の特殊なケースである、リプレイ攻撃から保護します。
If an RDMAP/DDP Stream may be subject to impersonation attacks, or Stream hijacking attacks, it is recommended that the Stream be authenticated, integrity protected, and protected from replay attacks; it may use confidentiality protection to protect from eavesdropping (in case the RDMAP/DDP Stream traverses a public network).
RDMAP / DDPストリームは、偽装攻撃、またはストリームのハイジャック攻撃を受ける可能性がある場合、ストリームを認証することを推奨完全性を保護し、リプレイ攻撃から保護されています。それは（場合にRDMAP / DDPストリームは、公衆ネットワークを通過する）盗聴から保護するために機密保護を使用することができます。
IPsec is a protocol suite that is used to secure communication at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [RFC2401], IKE [RFC2409], IPsec Authentication Header (AH) [RFC2402], and IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol, while AH and ESP are used to protect IP traffic. Please see those RFCs for a complete description of the respective protocols.
IPsecは2つのピア間ネットワーク層での通信を保護するために使用されるプロトコル群です。 IPsecプロトコルスイートは、IPセキュリティアーキテクチャ[RFC2401]、IKE [RFC2409]、IPsecの認証ヘッダー（AH）[RFC2402]、およびIPSecカプセル化セキュリティペイロード（ESP）[RFC2406]の文書の中に指定されています。 AHとESPは、IPトラフィックを保護するために使用されるIKEは、鍵管理プロトコルです。それぞれのプロトコルの詳細については、これらのRFCを参照してください。
IPsec is capable of providing the above security services for IP and TCP traffic, respectively. ULP protocols are able to provide only part of the above security services.
IPsecは、それぞれ、IPおよびTCPトラフィックについては、上記のセキュリティサービスを提供することが可能です。 ULPプロトコルは、上記のセキュリティサービスの一部のみを提供することが可能です。
TLS [RFC4346] provides Stream authentication, integrity and confidentiality for TCP based ULPs. TLS supports one-way (server only) or mutual certificates based authentication.
TLS [RFC4346] TCPベースのULPのためのストリーム認証、完全性と機密性を提供します。 TLSは、一方向（サーバーのみ）または相互証明書ベースの認証をサポートしています。
If TLS is layered underneath RDMAP, TLS's connection orientation makes TLS inappropriate for DDP/RDMA security. If a stream cipher or block cipher in CBC mode is used for bulk encryption, then a packet can be decrypted only after all the packets preceding it have already arrived. If TLS is used to protect DDP/RDMAP traffic, then TCP must gather all out-of-order packets before TLS can decrypt them. Only after this is done can RDMAP/DDP place them into the ULP buffer. Thus, one of the primary features of DDP/RDMAP - enabling implementations to have a flow-through architecture with little to no buffering - cannot be achieved if TLS is used to protect the data stream.
TLSはRDMAPの下に階層化されている場合は、TLSの接続方向は、DDP / RDMAセキュリティのためのTLSが不適切になります。 CBCモードでのストリーム暗号またはブロック暗号は、バルク暗号化に使用されている場合、パケットはそれに先行するすべてのパケットが既に到着した後でのみ復号化することができます。 TLSは、DDP / RDMAPトラフィックを保護するために使用されている場合はTLSがそれらを解読することができます前に、その後、TCPは、すべてのアウトオブオーダーのパケットを収集する必要があります。これが行われた後にのみRDMAPすることができます/ DDPはULPバッファーに入れます。このように、DDP / RDMAPの主な機能のひとつ - ないバッファリングをほとんど有するフロースルーアーキテクチャを有するように実装を可能にするには、 - TLSは、データストリームを保護するために使用される場合に達成することができません。
If TLS is layered on top of RDMAP or DDP, TLS does not protect the RDMAP and/or DDP headers. Thus, a man-in-the-middle attack can still occur by modifying the RDMAP/DDP header to place the data into the wrong buffer, thus effectively corrupting the data stream.
TLSはRDMAPまたはDDPの上に階層化されている場合は、TLSはRDMAPおよび/またはDDPヘッダを保護することはできません。したがって、中間者攻撃は依然として効果的にデータ・ストリームを破損、間違ったバッファにデータを配置するRDMAP / DDPヘッダを変更することによって起こり得ます。
For these reasons, it is not RECOMMENDED that TLS be layered on top of RDMAP or DDP.
これらの理由から、TLSがRDMAPまたはDDPの上に階層化することはお勧めしません。
DTLS [DTLS] provides security services for datagram protocols, including unreliable datagram protocols. These services include anti-replay based on a mechanism adapted from IPsec that is intended to operate on packets as they are received from the network. For these and other reasons, DTLS is best applied to RDDP by employing DTLS beneath TCP, yielding a layering of RDDP over TCP over DTLS over UDP/IP. Such a layering inserts DTLS at roughly the same level in the protocol stack as IPsec, making DTLS's security services an alternative to IPsec's services from an RDDP standpoint.
DTLS [DTLS]は信頼性のないデータグラムプロトコルを含むデータグラムプロトコルのセキュリティサービスを提供します。これらのサービスは、それらがネットワークから受信されるパケット上で動作するように意図されたIPsecから適応メカニズムに基づく抗リプレイを含みます。これらおよびその他の理由により、DTLSは最高の、TCPの下にDTLSを使用するUDP / IP経由DTLS上でTCP上RDDPの積層をもたらすことにより、RDDPに適用されます。そのような積層インサートDTLSのIPsecなどのプロトコルスタック中のほぼ同じレベル、DTLSのセキュリティサービスRDDPの観点からのIPsecのサービスの代替を行います。
For RDDP, IPsec is the better choice for a security framework, and hence is mandatory-to-implement (as specified elsewhere in this document). An important contributing factor to the specification of IPsec rather than DTLS is that the non-RDDP versions of two initial adopters of RDDP (iSCSI [iSCSI][iSER] and NFSv4 [NFSv4][NFSv4.1]) are compatible with IPsec but neither of these protocols currently uses either TLS or DTLS. For the specific case of iSCSI, IPsec is the basis for mandatory-to-implement security services [RFC3723]. Therefore, this document and the RDDP protocol specifications contain mandatory implementation requirements for IPsec rather than for DTLS.
RDDPのために、IPsecは（このドキュメントの他の場所で指定されている）セキュリティフレームワークのためのより良い選択であるため、実装に必須のです。むしろDTLS以上のIPsecの仕様に重要な要因は、RDDPの2つの初期採用者の非RDDPバージョン（iSCSIの[iSCSIの】【のiSER]とのNFSv4は[なNFSv4] [NFSv4.1]）はIPsecのどちらも互換性があることですこれらのプロトコルの現在TLSまたはDTLSのいずれかを使用しています。 iSCSIの特定のケースでは、IPsecは実装に必須のセキュリティサービス[RFC3723]のための基礎です。したがって、この文書とRDDPプロトコルの仕様は、IPsecのためではなくDTLSに必須の実装要件が含まれています。
ULPs that provide integrated security but wish to leverage lower-layer protocol security, should be aware of security concerns around correlating a specific channel's security mechanisms to the authentication performed by the ULP. See [NFSv4CHANNEL] for additional information on a promising approach called "channel binding". From [NFSv4CHANNEL]:
統合されたセキュリティを提供するが、下位層のプロトコルのセキュリティを活用したいのULPは、ULPによる認証に特定のチャネルのセキュリティ・メカニズムを相関周りのセキュリティ上の問題に注意する必要があります。 「チャネル結合」と呼ばれる有望なアプローチに関する追加情報については、[NFSv4CHANNEL]を参照してください。 [NFSv4CHANNEL]から：
"The concept of channel bindings allows applications to prove that the end-points of two secure channels at different network layers are the same by binding authentication at one channel to the session protection at the other channel. The use of channel bindings allows applications to delegate session protection to lower layers, which may significantly improve performance for some applications."
「チャネルバインディングの概念は、アプリケーションが他のチャネルでのセッション保護への1つのチャネルでの認証を結合することによって、異なるネットワーク層における2つの安全なチャンネルのエンドポイントが同じであることを証明することができます。チャネルバインディングを使用すると、アプリケーションが委任することができますかなりいくつかのアプリケーションのパフォーマンスを向上させることが下位層へのセッション保護。」
The IP Storage working group has spent significant time and effort to define the normative IPsec requirements for IP Storage [RFC3723]. Portions of that specification are applicable to a wide variety of protocols, including the RDDP protocol suite. In order not to replicate this effort, an RNIC implementation MUST follow the requirements defined in RFC 3723, Section 2.3 and Section 5,
IPストレージワーキンググループはIPストレージのための規範のIPsec要件[RFC3723]を定義するために多大な時間と労力を費やしてきました。その仕様の部分はRDDPプロトコルスイートなどの多種多様なプロトコルにも適用可能です。この努力を複製しないようにするためには、RNICの実装は、RFC 3723で定義された要件、2.3節と第5節に従わなければなりません
including the associated normative references for those sections. Note that this means that support for IPSEC ESP mode is normative.
これらのセクションのための関連する規範的な参照を含みます。これはIPSEC ESPモードのサポートが規範的であることを意味することに注意してください。
Additionally, since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down a DDP/RDMA Stream. Rather, it is preferable to leave the Stream up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing Streams up and down.
また、IPsecの加速ハードウェアためのみアクティブIKEフェーズ2つのSAの限られた数を処理することができる場合があり、フェーズ2の削除メッセージを最小限にアクティブフェーズ2つのSAの数を維持する手段として、アイドルSAのために送られてもよいです。 IKEフェーズ2削除メッセージの受信は、DDP / RDMAストリームを切断する理由として解釈されてはいけません。むしろ、アップストリームを残すことが好ましく、追加のトラフィックが、それに送信された場合、それを保護するために別のIKEフェーズ2 SAを起動します。これは、継続的にアップとダウンストリームをもたらす可能性を回避できます。
Note that there are serious security issues if IPsec is not implemented end-to-end. For example, if IPsec is implemented as a tunnel in the middle of the network, any hosts between the Peer and the IPsec tunneling device can freely attack the unprotected Stream.
IPsecは、エンドツーエンドの実装されていない場合は、重大なセキュリティ上の問題があることに注意してください。 IPsecは、ネットワークの中央のトンネルとして実装されている場合、例えば、ピアとのIPsecトンネルデバイスとの間の任意のホストは自由に保護されていないストリームを攻撃することができます。
The IPsec requirements for RDDP are based on the version of IPsec specified in RFC 2401 [RFC2401] and related RFCs, as profiled by RFC 3723 [RFC3723], despite the existence of a newer version of IPsec specified in RFC 4301 [RFC4301] and related RFCs. One of the important early applications of the RDDP protocols is their use with iSCSI [iSER]; RDDP's IPsec requirements follow those of IPsec in order to facilitate that usage by allowing a common profile of IPsec to be used with iSCSI and the RDDP protocols. In the future, RFC 3723 may be updated to the newer version of IPsec; the IPsec security requirements of any such update should apply uniformly to iSCSI and the RDDP protocols.
RFC 4301 [RFC4301]で指定されたIPSecの新しいバージョンの存在と関連するにもかかわらず、RFC 3723 [RFC3723]でプロファイルとしてRDDPのIPsec要件は、RFC 2401 [RFC2401]および関連するRFCで指定されたIPSecのバージョンに基づいていますRFCの。 RDDPプロトコルの重要な初期の用途の一つは、iSCSI [のiSER]との使用です。 RDDPのIPsecの要件は、IPsecの共通プロファイルを可能にすることにより、その使用を容易にするためのIPsecのものをiSCSIとRDDPプロトコルで使用するに従ってください。将来的には、RFC 3723は、IPsecの新しいバージョンに更新することができます。そのような更新のIPsecセキュリティ要件は、iSCSIとRDDPプロトコルに均一に適用されるべきです。
This section describes remote attacks that are possible against the RDMA system defined in Figure 1 - RDMA Security Model and the RNIC Engine resources defined in Section 2.2. The analysis includes a detailed description of each attack, what is being attacked, and a description of the countermeasures that can be taken to thwart the attack.
RDMAセキュリティモデルと2.2節で定義されたRNICエンジン資源 - このセクションでは、図1で定義されたRDMAシステムに対して可能であり、リモートの攻撃について説明します。分析は、各攻撃の詳細な説明は、何が攻撃され、攻撃を阻止するために取ることができる対策の説明を含みます。
The attacks are classified into five categories: Spoofing, Tampering, Information Disclosure, Denial of Service (DoS) attacks, and Elevation of Privileges. As mentioned previously, tampering is any modification of the legitimate traffic (machine internal or network). A spoofing attack is a special case of tampering where the attacker falsifies an identity of the Remote Peer (identity can be an IP address, machine name, ULP level identity, etc.).
なりすまし、改ざん、情報開示、サービス拒否（DoS）攻撃、および権限の標高：攻撃は、5つのカテゴリに分類されています。先に述べたように、改ざんが正当なトラフィック（マシン内部またはネットワーク）の任意の変形例です。スプーフィング攻撃は、攻撃者がリモートピアのアイデンティティを誤らせるどこ改ざんの特殊なケースである（アイデンティティは、IPアドレス、マシン名、ULPレベルのアイデンティティなどすることができます）。
This section analyzes the various types of spoofing attacks applicable to RDMAP and DDP. Spoofing attacks can be launched by the Remote Peer or by a network-based attacker. For countermeasures against a network-based attacker, see Section 5, Attacks That Can Be Mitigated with End-to-End Security.
このセクションでは、RDMAPとDDPに適用スプーフィング攻撃のさまざまなタイプを分析します。スプーフィング攻撃は、リモートピアまたはネットワークベースの攻撃者によって起動することができます。ネットワークベースの攻撃の対策については、第5章、エンドツーエンドのセキュリティを緩和することができる攻撃を参照してください。
One style of attack from the Remote Peer is for it to attempt to use STag values that it is not authorized to use. Note that if the Remote Peer sends an invalid STag to the Local Peer, per the DDP and RDMAP specifications, the Stream must be torn down. Thus, the threat exists if an STag has been enabled for Remote Access on one Stream and a Remote Peer is able to use it on an unrelated Stream. If the attack is successful, the attacker could potentially be able to either perform RDMA Read operations to read the contents of the associated Data Buffer, perform RDMA Write operations to modify the contents of the associated data buffer, or invalidate the STag to disable further access to the buffer.
リモートピアからの攻撃の一つのスタイルは、使用することを許可されていないクワガタ値を使用しようとするのです。リモートピアがDDPとRDMAP仕様ごとに、ローカルピアに無効のSTagを送信した場合、ストリームは解体しなければならないことに注意してください。 STagが一つのストリーム上のリモートアクセスのために有効になっていると、リモートピアは無関係ストリーム上でそれを使用することがある場合はこのように、脅威が存在します。攻撃が成功すると、攻撃者は潜在的に関連するデータ・バッファの内容を読み取るためにRDMA読み取り操作を実行するいずれかのことができる可能性があり、関連するデータ・バッファの内容を変更したり、さらにアクセスを無効にするのSTagを無効にするためにRDMA書き込み操作を実行しますバッファへ。
An attempt by a Remote Peer to access a buffer with an STag on a different Stream in the same Protection Domain may or may not be an attack, depending on whether resource sharing is intended (i.e., whether the Streams shared Partial Mutual Trust). For some ULPs, using an STag on multiple Streams within the same Protection Domain could be desired behavior. For other ULPs, attempting to use an STag on a different Stream could be considered an attack. Since this varies by ULP, a ULP typically would need to be able to control the scope of the STag.
同じ保護ドメイン内の異なるストリーム上のSTagでバッファにアクセスするためのリモートピアによる試みは、またはリソース共有が意図されているかどうかに応じて、攻撃であってもなくてもよい（すなわち、ストリームが部分相互信頼を共有するかどうか）。いくつかのULPのために、同じ保護ドメイン内の複数のストリーム上のSTagを使用して、目的の動作である可能性があります。他のULPのために、異なるストリーム上のSTagを使用しようとすると、攻撃と見なすことができます。これはULPによって変化するので、ULPは、典型的には、のSTagの範囲を制御できるようにする必要があります。
In the case where an implementation does not share resources between Streams (including STags), this attack can be defeated by assigning each Stream to a different Protection Domain. Before allowing remote access to the buffer, the Protection Domain of the Stream where the access attempt was made is matched against the Protection Domain of the STag. If the Protection Domains do not match, access to the buffer is denied, an error is generated, and the RDMAP Stream associated with the attacking Stream is terminated.
実装は（スタッグス含む）ストリーム間のリソースを共有しない場合には、この攻撃は、異なる保護ドメインに各ストリームを割り当てることによって無効にすることができます。バッファへのリモートアクセスを許可する前に、アクセス試行が行われたストリームの保護ドメインはのSTagの保護ドメインと照合されます。保護ドメインが一致しない場合は、バッファへのアクセスはエラーが生成され、拒否され、攻撃ストリームに関連付けられているRDMAPストリームが終了されます。
For implementations that share resources between multiple Streams, it may not be practical to separate each Stream into its own Protection Domain. In this case, the ULP can still limit the scope of any of the STags to a single Stream (if it is enabling it for remote access). If the STag scope has been limited to a single Stream, any attempt to use that STag on a different Stream will result in an error, and the RDMAP Stream is terminated.
複数のストリーム間でリソースを共有する実装では、それ自身の保護ドメインに各ストリームを分離するために実用的ではないかもしれません。 （それはリモートアクセスのためにそれを可能にされている場合）この場合、ULPは依然として単一のストリームにスタッグスの任意の範囲を制限することができます。クワガタスコープは、単一のストリームに限定されている場合は、別のストリームにそののSTagを使用しようとするとエラーになります、とRDMAPストリームが終了されます。
Thus, for implementations that do not share STags between Streams, each Stream MUST either be in a separate Protection Domain or the scope of an STag MUST be limited to a single Stream.
このように、ストリーム間スタッグスを共有しない実装のために、各ストリームは、単一ストリームに制限されなければならない別個の保護ドメインまたはのSTagの範囲になければなりません。
An RNIC MUST ensure that a specific Stream in a specific Protection Domain cannot access an STag in a different Protection Domain.
RNICは、特定の保護ドメイン内の特定のストリームが異なる保護ドメイン内のSTagにアクセスできないことを保証しなければなりません。
An RNIC MUST ensure that, if an STag is limited in scope to a single Stream, no other Stream can use the STag.
STagを単一のストリームに範囲が限定されている場合RNICは、それを確実にしなければなりません、他のストリームのSTagを使用することはできません。
An additional issue may be unintended sharing of STags (i.e., a bug in the ULP) or a bug in the Remote Peer that causes an off-by-one STag to be used. For additional protection, an implementation should allocate STags in such a fashion that it is difficult to predict the next allocated STag number, and also ensure that STags are reused at as slow a rate as possible. Any allocation method that would lead to intentional or unintentional reuse of an STag by the peer should be avoided (e.g., a method that always starts with a given STag and monotonically increases it for each new allocation, or a method that always uses the same STag for each operation).
追加の問題（すなわち、ULPのバグ）またはオフずつのSTagを引き起こすリモートピアのバグを使用するスタッグスの意図しない共有することができます。さらなる保護のために、実装は、次の割り当てスタッグ数を予測することは困難であるような様式でスタッグスを割り当て、またスタッグスができるだけ遅い速度で再利用されることを確実にすべきです。ピアによってのSTagの故意または意図しない再利用につながる任意の割り当て方法は、例えば（常に一定のSTagで始まり、単調にそれぞれの新しい割り当て、または常に同じのSTagを使用する方法のためにそれを高める方法を避けるべきです各操作のため）。
A Remote Peer or a network-based attacker can attempt to tamper with the contents of Data Buffers on a Local Peer that have been enabled for remote write access. The types of tampering attacks from a Remote Peer are outlined in the sections that follow. For countermeasures against a network-based attacker, see Section 5, Attacks That Can Be Mitigated with End-to-End Security.
リモートピアまたはネットワークベースの攻撃者がリモート書き込みアクセスのために有効にされているローカルピア上のデータバッファの内容を改ざんしようとすることができます。リモートピアからの改ざん攻撃の種類は以下のセクションで概説されています。ネットワークベースの攻撃の対策については、第5章、エンドツーエンドのセキュリティを緩和することができる攻撃を参照してください。
This attack is an attempt by the Remote Peer to perform an RDMA Write or RDMA Read Response to memory outside of the valid length range of the Data Buffer enabled for remote write access. This attack can occur even when no resources are shared across Streams. This issue can also arise if the ULP has a bug.
この攻撃は、RDMA書き込みまたはリモート書き込みアクセスのために有効にデータバッファの有効な長さの範囲の外のメモリへのRDMA読み取り応答を実行するためのリモートピアの試みです。この攻撃にはリソースがストリーム間で共有されていない場合でも発生する可能性があります。 ULPは、バグを持っている場合、この問題も発生する可能性があります。
The countermeasure for this type of attack must be in the RNIC implementation, leveraging the STag. When the local ULP specifies to the RNIC the base address and the umber of bytes in the buffer that it wishes to make accessible, the RNIC must ensure that the base and bounds check are applied to any access to the buffer referenced by the STag before the STag is enabled for access. When an RDMA data transfer operation (which includes an STag) arrives on a Stream, a base and bounds byte granularity access check must be performed to ensure that the operation accesses only memory locations within the buffer described by that STag.
この種の攻撃のための対策は、のSTagを活用し、RNICの実装でなければなりません。地元のULPは、RNICベースアドレスと、それがアクセスできるように望んでいることを、バッファ内のバイトのアンバーに指定すると、RNICは、ベースとの境界チェックが前のSTagによって参照されるバッファへのアクセスに適用されていることを確認する必要がありますSTagはアクセスが有効になっています。 （婚前を含む）RDMAデータ転送操作がストリームに到着したとき、ベース及び境界バイト粒度のアクセスチェックは、操作がそののSTagによって記述バッファ内のみのメモリ位置にアクセスすることを確実にするために実行されなければなりません。
Thus an RNIC implementation MUST ensure that a Remote Peer is not able to access memory outside of the buffer specified when the STag was enabled for remote access.
したがってRNICの実装では、リモートピアがのSTagがリモートアクセス用に有効化されたときに指定されたバッファの外のメモリにアクセスすることができないことを確認しなければなりません。
This attack can occur if a Remote Peer attempts to modify the contents of an STag referenced buffer by performing an RDMA Write or an RDMA Read Response after the Remote Peer has indicated to the Local Peer or local ULP (by a variety of means) that the STag Data Buffer contents are ready for use. This attack can occur even when no resources are shared across Streams. Note that a bug in a Remote Peer, or network-based tampering, could also result in this problem.
リモートピアがリモートピアは、（様々な手段によって）ローカルピアまたはローカルULPに示された後RDMA書き込みまたはRDMA読み取り応答を行うことで、STagを参照バッファの内容を変更しようとすると、この攻撃が発生する可能性があることSTagデータバッファの内容は、使用する準備が整いました。この攻撃にはリソースがストリーム間で共有されていない場合でも発生する可能性があります。リモートピアのバグ、またはネットワークベースの改ざんは、また、このような問題が生じる可能性があることに注意してください。
For example, assume that the STag referenced buffer contains ULP control information as well as ULP payload, and the ULP sequence of operation is to first validate the control information and then perform operations on the control information. If the Remote Peer can perform an additional RDMA Write or RDMA Read Response (thus, changing the buffer) after the validity checks have been completed but before the control data is operated on, the Remote Peer could force the ULP down operational paths that were never intended.
例えば、バッファ参照のSTagはULP制御情報並びにULPペイロードが含まれていると、操作のULPシーケンスは、第1の制御情報を検証し、制御情報に対する操作を実行することです。妥当性チェックが完了した後、リモートピアは（したがって、バッファの変更）、追加のRDMA書き込みまたはRDMA読み取り応答を行うことができますが、制御データが操作される前に、リモートピアは決してなかった運用パスをULPを下に強制することができれば意図されました。
The local ULP can protect itself from this type of attack by revoking remote access when the original data transfer has completed and before it validates the contents of the buffer. The local ULP can do this either by explicitly revoking remote access rights for the STag when the Remote Peer indicates the operation has completed, or by checking to make sure the Remote Peer invalidated the STag through the RDMAP Remote Invalidate capability. If the Remote Peer did not invalidate the STag, the local ULP then explicitly revokes the STag remote access rights. (See Section 6.4.5, Remote Invalidate an STag Shared on Multiple Streams for a definition of Remote Invalidate.)
地元のULPは、元のデータ転送が完了したとき、それはバッファの内容を検証する前に、リモートアクセスを取り消すことにより、この種の攻撃から自身を保護することができます。地元のULPは、いずれかのリモートピアが操作は、完了したことを示しているときに明示的のSTagのためのリモートアクセス権を取り消すことにより、または確認リモートピアがリモート機能を無効にRDMAPを通じてのSTagを無効にするためにチェックすることでこれを行うことができます。リモートピアがのSTagを無効にしなかった場合は、ローカルのULPは、明示のSTagリモートアクセス権を取り消します。 （リモートリモート無効化の定義については、複数のストリーム上のSTagの共有を無効に、6.4.5項を参照してください。）
The local ULP SHOULD follow the above procedure to protect the buffer before it validates the contents of the buffer (or uses the buffer in any way).
それはバッファの内容を検証する（または任意の方法でバッファを使用する）前に、ローカルULPは、バッファを保護するために、上記の手順に従うべきです。
An RNIC MUST ensure that network packets using the STag for a previously Advertised Buffer can no longer modify the buffer after the ULP revokes remote access rights for the specific STag.
RNICは、ULPは、特定のSTagのためのリモートアクセス権を取り消した後、もはやバッファを変更することはできません以前にアドバタイズバッファ用のSTagを使用しているネットワークパケットを確保しなければなりません。
See Section 6.3.6 Using Multiple STags That Alias to the Same Buffer, for this analysis.
この分析のために、同じバッファーにエイリアス、複数スタッグスを使用して、セクション6.3.6を参照してください。
The main potential source for information disclosure is through a local buffer that has been enabled for remote access. If the buffer can be probed by a Remote Peer on another Stream, then there is potential for information disclosure.
情報開示のための主要な潜在的な供給源は、リモートアクセス用に有効にされているローカル・バッファを介して行われます。バッファが別のストリーム上のリモートピアでプローブすることができる場合には、情報開示の可能性があります。
The potential attacks that could result in unintended information disclosure and countermeasures are detailed in the following sections.
意図しない情報開示と対策につながる可能性が潜在的な攻撃は、次のセクションで詳しく説明されています。
This is essentially the same attack as described in Section 6.2.1, Buffer Overrun - RDMA Write or Read Response, except that an RDMA Read Request is used to mount the attack. The same countermeasure applies.
6.2.1項で説明したように、これは本質的に同じ攻撃で、バッファオーバーラン - RDMAの書き込みや読み出し応答、RDMA読み出し要求が攻撃をマウントするために使用されている以外は。同じ対策が適用されます。
If a buffer is being used for some combination of reads and writes (either remote or local), and is exposed to a Remote Peer with at least remote read access rights before it is initialized with the correct data, there is a potential race condition where the Remote Peer can view the prior contents of the buffer. This becomes a security issue if the prior contents of the buffer were not intended to be shared with the Remote Peer.
バッファは、いくつかの組み合わせのために使用されている場合、それが正しいデータで初期化される前に、読み取りと書き込み（リモートまたはローカル）、および少なくともリモート読み取りアクセス権を持つリモートピアにさらされ、潜在的な競合状態がどこそこにありますリモートピアは、バッファの前に内容を表示することができます。バッファの前に内容がリモートピアと共有されることを意図していなかった場合、これはセキュリティ上の問題となります。
To eliminate this race condition, the local ULP SHOULD ensure that no stale data is contained in the buffer before remote read access rights are granted (this can be done by zeroing the contents of the memory, for example). This ensures that the Remote Peer cannot access the buffer until the stale data has been removed.
この競合状態を解消するには、ローカルULPは、リモート読み取りアクセス権が付与される前に、何の古いデータがバッファに格納されていないことを確認する必要があります（これは例えば、メモリの内容をゼロにすることによって行うことができます）。これは、古いデータが削除されるまで、リモートピアがバッファにアクセスできないことを保証します。
If the Remote Peer has remote read access to a buffer and, by some mechanism, tells the local ULP that the transfer has been completed, but the local ULP does not disable remote access to the buffer before modifying the data, it is possible for the Remote Peer to retrieve the new data.
リモートピアがリモートバッファへのアクセスを読んで、いくつかのメカニズムによって、転送が完了したが、地元のULPは、データを変更する前に、バッファへのリモートアクセスを無効にしないことを地元のULPを伝えている場合、それは可能ですリモート新しいデータを取得するためにピア。
This is similar to the attack defined in Section 6.2.2, Modifying a Buffer after Indication. The same countermeasures apply. In addition, the local ULP SHOULD grant remote read access rights only for the amount of time needed to retrieve the data.
これは、表示した後にバッファの変更、6.2.2項で定義された攻撃に似ています。同じ対策が適用されます。また、地元のULPは、データのみを取得するのに必要な時間のためにリモート読み取りアクセス権を付与する必要があります。
If the ULP enables remote access to a buffer using an STag that references the entire buffer, but intends only a portion of the buffer to be accessed, it is possible for the Remote Peer to access the other parts of the buffer anyway.
ULPは、バッファ全体を参照するが、アクセスされるバッファの一部のみを意図したSTagを使用してバッファへのリモートアクセスを可能にする場合、リモートピアは、とにかくバッファの他の部分にアクセスすることが可能です。
To prevent this attack, the ULP SHOULD set the base and bounds of the buffer when the STag is initialized to expose only the data to be retrieved.
この攻撃を防ぐために、ULPは、ベースとのSTagを取得するデータのみを露出するように初期化され、バッファの境界を設定する必要があります。
One form of disclosure can occur if the access rights on the buffer enabled remote read, when only remote write access was intended. If the buffer contained ULP data, or data from a transfer on an unrelated Stream, the Remote Peer could retrieve the data through an RDMA Read operation. Note that an RNIC implementation is not required to support STags that have both read and write access.
バッファ上のアクセス権のみをリモート書き込みアクセスが意図されたリモート読み取りを、有効にした場合の開示の一の形態は、発生する可能性があります。バッファは無関係ストリーム上の転送からULPデータ、またはデータが含まれている場合、リモートピアは、RDMA読み取り操作を介してデータを取得することができます。 RNIC実装は読み取りと書き込みの両方のアクセス権を持っているスタッグスをサポートする必要がないことに注意してください。
The most obvious countermeasure for this attack is to not grant remote read access if the buffer is intended to be write-only. Then the Remote Peer would not be able to retrieve data associated with the buffer. An attempt to do so would result in an error and the RDMAP Stream associated with the Stream would be terminated.
この攻撃のための最も明白な対策は、バッファが書き込み専用であることを意図している場合は、リモート読み取りアクセスを許可しないことです。その後、リモートピアは、バッファに関連付けられたデータを取得することはできません。そうしようとするとエラーになりやストリームに関連付けられているRDMAP Streamが終了されるだろう。
Thus, if a ULP only intends a buffer to be exposed for remote write access, it MUST set the access rights to the buffer to only enable remote write access. Note that this requirement is not meant to restrict the use of zero-length RDMA Reads. Zero-length RDMA Reads do not expose ULP data. Because they are intended to be used as a mechanism to ensure that all RDMA Writes have been received, and do not even require a valid STag, their use is permitted even if a buffer has only been enabled for write access.
ULPが唯一のリモート書き込みアクセスのために露出されるバッファをしようとする場合したがって、それだけでリモート書き込みアクセスを可能にするために、バッファへのアクセス権を設定しなければなりません。この要件は、RDMA読み込みゼロ長の使用を制限することを意味しないことに留意されたいです。長さゼロのRDMAは、ULPデータを公開していない読み込みます。彼らはすべてのRDMAが受信された書き込み、さらに有効なのSTagを必要としないことを保証するメカニズムとして使用されることを意図しているので、その使用は、バッファのみが書き込みアクセスのために有効になっている場合でも、許可されています。
Multiple STags that alias to the same buffer at the same time can result in unintentional information disclosure if the STags are used by different, mutually untrusted Remote Peers. This model applies specifically to client/server communication, where the server is communicating with multiple clients, each of which do not mutually trust each other.
スタッグスが異なる、相互に信頼されていないリモートピアによって使用される場合、同時に同じ緩衝液にエイリアスが意図しない情報開示をもたらすことができる複数スタッグス。このモデルは、特に、サーバーが相互に信頼していないそれぞれの複数のクライアントと通信しているクライアント/サーバー間の通信に適用されます。
If only read access is enabled, then the local ULP has complete control over information disclosure. Thus, a server that intended to expose the same data (i.e., buffer) to multiple clients by using multiple STags to the same buffer creates no new security issues beyond what has already been described in this document. Note that if the server did not intend to expose the same data to the clients, it should use separate buffers for each client (and separate STags).
読み取り専用アクセスが有効になっている場合、ローカルULPは、情報開示を完全に制御を持っています。このように、同じバッファに複数のスタッグスを使用して複数のクライアントに同じデータ（すなわち、バッファ）を露出することを目的とサーバーは既にこの文書に記載されているものを超えて新たなセキュリティ問題を作成しません。サーバーがクライアントに同じデータを公開するつもりはなかった場合、それは各クライアント（および別のスタッグス）のために別々のバッファを使用する必要があることに注意してください。
When one STag has remote read access enabled and a different STag has remote write access enabled to the same buffer, it is possible for one Remote Peer to view the contents that have been written by another Remote Peer.
1のSTagがリモート有効に読み取りアクセス権を持つと異なるのSTagが同じバッファに対応リモート書き込みアクセス権を持っている場合には1つのリモートピアが別のリモートピアによって書かれている内容を表示することが可能です。
If both STags have remote write access enabled and the two Remote Peers do not mutually trust each other, it is possible for one Remote Peer to overwrite the contents that have been written by the other Remote Peer.
両方スタッグスは、リモート書き込みアクセスが有効になっていると2つのリモートピアが相互に信頼していない場合は1つのリモートピアが他のリモートピアによって書かれている内容を上書きすることが可能です。
Thus, a ULP with multiple Remote Peers that do not share Partial Mutual Trust MUST NOT grant write access to the same buffer through different STags. A buffer should be exposed to only one untrusted Remote Peer at a time to ensure that no information disclosure or information tampering occurs between peers.
このように、部分的な相互信頼を共有していない複数のリモートピアとのULPは異なるスタッグスを通じて同じバッファへの書き込みアクセスを許可してはなりません。バッファには情報漏えいや改ざん情報がピア間で生じないことを保証するために、一度に一つだけ信頼できないリモートピアにさらさなければなりません。
A DOS attack is one of the primary security risks of RDMAP. This is because RNIC resources are valuable and scarce, and many ULP environments require communication with untrusted Remote Peers. If the Remote Peer can be authenticated or the ULP payload encrypted, clearly, the DOS profile can be reduced. For the purposes of this analysis, it is assumed that the RNIC must be able to operate in untrusted environments, which are open to DOS-style attacks.
DOS攻撃はRDMAPの主要なセキュリティリスクの一つです。 RNIC資源は貴重かつ不足している、と多くのULP環境が信頼されていないリモートピアとの通信を必要とするからです。リモートピアが認証されることができるか、ULPペイロードは暗号化された場合は、明らかに、DOSのプロファイルを低減することができます。この分析の目的のために、RNICは、DOS形式の攻撃に開かれている信頼されていない環境で動作させることができなければならないことが想定されます。
Denial of service attacks against RNIC resources are not the typical unknown party spraying packets at a random host (such as a TCP SYN attack). Because the connection/Stream must be fully established (e.g., a 3-message transport layer handshake has occurred), the attacker must be able to both send and receive messages over that connection/Stream, or be able to guess a valid packet on an existing RDMAP Stream.
RNICリソースに対するサービス拒否攻撃は、（TCP SYN攻撃など）ランダムホストでパケットを噴霧し、典型的な、未知の当事者ではありません。接続/ストリームが完全に（例えば、3-のメッセージトランスポート層のハンドシェイクが発生している）を確立する必要があるため、攻撃者は両方がその接続/ストリームを介してメッセージを送信し、受信することができ、または上の有効なパケットを推測することができなければなりません既存のRDMAPストリーム。
This section outlines the potential attacks and the countermeasures available for dealing with each attack.
このセクションでは、潜在的な攻撃と各攻撃に対処するために利用可能な対策の概要を示しています。
This section covers attacks that fall into the general category of a local ULP attempting to unfairly allocate scarce (i.e., bounded) RNIC resources. The local ULP may be attempting to allocate resources on its own behalf, or on behalf of a Remote Peer. Resources that fall into this category include Protection Domains, Stream Context Memory,
このセクションでは、不当に乏しい（すなわち、有界）RNICリソースを割り当てるしようとする地元のULPの一般的なカテゴリに分類される攻撃をカバーしています。地元のULPは、独自に代わって、またはリモートピアに代わってリソースを割り当てようとすることができます。このカテゴリに分類されたリソースは、保護ドメイン、ストリームコンテキストメモリが含まれ、
Translation and Protection Tables, and STag namespace. These can be due to attacks by currently active local ULPs or ones that allocated resources earlier but are now idle.
変換および保護テーブル、およびクワガタ名前空間。これらは、以前のリソースが割り当てられたが、現在はアイドル状態になっている現在アクティブなローカルのULPかのものによる攻撃に起因することができます。
This type of attack can occur regardless of whether resources are shared across Streams.
この種の攻撃は関係なく、リソースがストリーム間で共有されているかどうかに発生する可能性があります。
The allocation of all scarce resources MUST be placed under the control of a Privileged Resource Manager. This allows the Privileged Resource Manager to:
すべての希少な資源の配分は、特権リソース・マネージャの管理下に置かなければなりません。これは、特権リソースマネージャをすることができます：
* prevent a local ULP from allocating more than its fair share of resources.
*資源の公正なシェア以上を割り当てるからローカルULPを防ぎます。
* detect if a Remote Peer is attempting to launch a DOS attack by attempting to create an excessive number of Streams (with associated resources) and take corrective action (such as refusing the request or applying network layer filters against the Remote Peer).
*リモートピアが（関連するリソースを持つ）ストリームの過剰な数を作成し、（そのような要求を拒否したり、リモートピアに対してネットワーク層フィルタを適用するなど）是正処置を取るように試みることによって、DOS攻撃を開始しようとしているかどうかを検出。
This analysis assumes that the Resource Manager is responsible for handing out Protection Domains, and that RNIC implementations will provide enough Protection Domains to allow the Resource Manager to be able to assign a unique Protection Domain for each unrelated, untrusted local ULP (for a bounded, reasonable number of local ULPs). This analysis further assumes that the Resource Manager implements policies to ensure that untrusted local ULPs are not able to consume all the Protection Domains through a DOS attack. Note that Protection Domain consumption cannot result from a DOS attack launched by a Remote Peer, unless a local ULP is acting on the Remote Peer's behalf.
この分析は、Resource Managerが保護ドメインを配っする責任があることを前提としていて、RNICの実装は、有界のために（リソース・マネージャは、各関係のない、信頼されていない地元のULPのためのユニークな保護ドメインを割り当てることができるようにするために十分な保護ドメインを提供すること地元のULPの合理的な数）。さらにこの分析は、リソース・マネージャは、信頼されていない地元のULPは、DOS攻撃を介してすべての保護ドメインを消費することができないことを保証するためのポリシーを実装していることを前提としています。保護ドメインの消費量は、地元のULPは、リモートピアのために行動するされていない限り、リモートピアによって起動DOS攻撃に起因することができないことに注意してください。
The simplest form of a DOS attack, given a fixed amount of resources, is for the Remote Peer to create an RDMAP Stream to a Local Peer, request dedicated resources, and then do no actual work. This allows the Remote Peer to be very light weight (i.e., only negotiate resources, but do no data transfer) and consumes a disproportionate amount of resources at the Local Peer.
リソースの一定量与えられたDOS攻撃の最も単純な形式は、ローカルピアにRDMAPストリームを作成するために、リモートピアのために、専用のリソースを要求して、実際の作業を行うんです。これは、リモートピアが非常に軽量にすることができます（つまり、リソースのみを交渉、ないデータ転送を行わない）とローカルピアでの資源の不均衡な量を消費します。
A general countermeasure for this style of attack is to monitor active RDMAP Streams and, if resources are getting low, to reap the resources from RDMAP Streams that are not transferring data and possibly terminate the Stream. This would presumably be under administrative control.
攻撃のこのスタイルのための一般的な対策は、リソースが少なくなっている場合は、データを転送していないRDMAPストリームから資源を享受し、おそらくストリームを終了するには、アクティブRDMAPストリームを監視することです。これはおそらく、管理制御下になります。
Refer to Section 6.4.1 for the analysis and countermeasures for this style of attack on the following RNIC resources: Stream Context Memory, Page Translation Tables, and STag namespace.
ストリームコンテキストメモリ、ページ変換テーブル、およびクワガタ名前空間：以下RNICリソースへの攻撃のこのスタイルの分析と対策については、セクション6.4.1を参照してください。
Note that some RNIC resources are not at risk of this type of attack from a Remote Peer because an attack requires the Remote Peer to send messages in order to consume the resource. Receive Data Buffers, Completion Queue, and RDMA Read Request Queue resources are examples. These resources are, however, at risk from a local ULP that attempts to allocate resources, then goes idle. This could also be created if the ULP negotiates the resource levels with the Remote Peer, which causes the Local Peer to consume resources; however, the Remote Peer never sends data to consume them. The general countermeasure described in this section can be used to free resources allocated by an idle Local Peer.
攻撃は、リソースを消費するために、メッセージを送信するようにリモートピアを必要とするため、いくつかのRNICリソースがリモートピアからこの種の攻撃の危険にさらされていないことに注意してください。受信データバッファ、完了キュー、およびRDMA読み取り要求キューリソースがその例です。これらのリソースがある、しかし、リソースを割り当てるしようと地元のULPの危険にさらされ、その後、アイドル状態になります。 ULPは、リソースを消費するためにローカルピアの原因となるリモートピアとリソースのレベルを交渉する場合にも作成することができます。ただし、リモートピアは、それらを消費するデータを送信することはありません。このセクションで説明する一般的な対策は、アイドルローカルピアによって割り当てられたリソースを解放するために使用することができます。
This section describes DOS attacks from Local and Remote Peers that are actively exchanging messages. Attacks on each RDMA NIC resource are examined and specific countermeasures are identified. Note that attacks on Stream Context Memory, Page Translation Tables, and STag namespace are covered in Section 6.4.1, RNIC Resource Consumption, so they are not included here.
このセクションでは、積極的にメッセージを交換しているローカルおよびリモートピアからのDOS攻撃を記述する。各RDMA NICリソースに対する攻撃が検査され、特定の対策が識別されます。ストリームコンテキストメモリ、ページ変換テーブル、およびクワガタ名前空間への攻撃は、セクション6.4.1でカバーされていることに注意してください、RNICリソース消費ので、彼らはここに含まれていません。
The Remote Peer can attempt to consume more than its fair share of receive Data Buffers (i.e., Untagged Buffers for DDP or Send Type Messages for RDMAP) if receive buffers are shared across multiple Streams.
リモートピアがデータ受信バッファの公正なシェア以上を消費することを試みることができる（すなわち、タグなしDDP用バッファやRDMAP用型メッセージを送る）バッファを受信した場合は、複数のストリーム間で共有されています。
If resources are not shared across multiple Streams, then this attack is not possible because the Remote Peer will not be able to consume more buffers than were allocated to the Stream. The worst case scenario is that the Remote Peer can consume more receive buffers than the local ULP allowed, resulting in no buffers being available, which could cause the Remote Peer's Stream to the Local Peer to be torn down, and all allocated resources to be released.
リソースが複数のストリーム間で共有されていない場合は、リモートピアがストリームに割り当てられていたよりも多くのバッファを消費することができなくなりますので、この攻撃は不可能です。最悪のシナリオは、リモートピアがより多くの地元のULPが取り壊されるローカルピアにリモートピアの流れを引き起こす可能性があり、利用可能であることがないバッファで、その結果、許可、および割り当てられたすべてのリソースを解放することよりも、受信バッファを消費することができるということです。
If local receive Data Buffers are shared among multiple Streams, then the Remote Peer can attempt to consume more than its fair share of the receive buffers, causing a different Stream to be short of receive buffers, and thus, possibly causing the other Stream to be torn down. For example, if the Remote Peer sent enough one-byte Untagged Messages, they might be able to consume all locally shared, receive queue resources with little effort on their part.
地元の受信データバッファが複数のストリーム間で共有されている場合は、リモートピアが短いの可能性があることを他のストリームを引き起こし、これ受信バッファ、およびように異なるストリームを引き起こし、受信バッファの公正なシェアよりも多くを消費しようとすることができます取り壊す。リモートピアが十分に1バイトのタグなしのメッセージを送信した場合、彼らは、すべてのローカル共有消費し、その部分の少しの努力でキューリソースを受信することができるかもしれません。
One method the Local Peer could use is to recognize that a Remote Peer is attempting to use more than its fair share of resources and terminate the Stream (causing the allocated resources to be released). However, if the Local Peer is sufficiently slow, it may be possible for the Remote Peer to still mount a denial of service attack. One countermeasure that can protect against this attack is implementing a low-water notification. The low-water notification alerts the ULP if the number of buffers in the receive queue is less than a threshold.
ローカルピアが使用できる一つの方法は、リモートピアは資源の公正なシェアよりも多くを使用し、（割り当てられたリソースを解放させる）ストリームを終了しようとしていることを認識することです。ローカルピアが十分に遅い場合にリモートピアがまだサービス拒否攻撃をマウントするためにしかし、それは可能かもしれません。この攻撃から守ることができる一つの対策は、低水の通知を実施しています。受信キュー内のバッファの数が閾値未満である場合には、低水の通知は、ULPに警告します。
If all the following conditions are true, then the Local Peer or local ULP can size the amount of local receive buffers posted on the receive queue to ensure a DOS attack can be stopped.
以下のすべての条件に該当する場合は、[ローカルピアまたはローカルULP缶サイズDOS攻撃を確保するために、受信キューに掲載ローカル受信バッファの量を停止することができます。
* A low-water notification is enabled, and
*低水通知が有効になっており、
* The Local Peer is able to bound the amount of time that it takes to replenish receive buffers, and
*ローカルピアは、それが受信バッファを補充するのにかかる時間を束縛することができ、かつ
* The Local Peer maintains statistics to determine which Remote Peer is consuming buffers.
*ローカルピアは、リモートピアがバッファを消費しているかを決定するために統計情報を保持しています。
The above conditions enable the low-water notification to arrive before resources are depleted, and thus, the Local Peer or local ULP can take corrective action (e.g., terminate the Stream of the attacking Remote Peer).
上記の条件は、資源が枯渇する前に到着するように、低水通知を可能にし、従って、ローカル・ピアまたはローカルULP（例えば、攻撃リモートピアのストリームを終了）是正措置をとることができます。
A different, but similar, attack is if the Remote Peer sends a significant number of out-of-order packets and the RNIC has the ability to use the ULP buffer (i.e., the Untagged Buffer for DDP or the buffer consumed by a Send Type Message for RDMAP) as a reassembly buffer. In this case, the Remote Peer can consume a significant number of ULP buffers, but never send enough data to enable the ULP buffer to be completed to the ULP.
リモートピアがout-of-orderパケットのかなりの数を送信し、RNICは、ULPバッファDDPまたは送信タイプによって消費されるバッファの（すなわち、タグなしのバッファを使用する能力を持っている場合には、異なるが、同様の攻撃があります再構成バッファとしてRDMAPのメッセージ）。この場合は、リモートピアはULPバッファのかなりの数を消費しますが、ULPに完了することがULPバッファを有効にするために十分なデータを送信することはできません。
An effective countermeasure is to create a high-water notification that alerts the ULP if there is more than a specified number of receive buffers "in process" (partially consumed, but not completed). The notification is generated when more than the specified number of buffers are in process simultaneously on a specific Stream (i.e., packets have started to arrive for the buffer, but the buffer has not yet been delivered to the ULP).
効果的な対策は、「プロセスの」受信バッファの指定された数（部分的に消費が、完了していない）を超えるがある場合、ULPに警告高水の通知を作成することです。バッファの指定された数よりも多くは、特定のストリーム上で同時に処理しているときに通知が生成される（すなわち、パケットがバッファに到着し始めているが、バッファがまだULPに配信されていません）。
A different countermeasure is for the RNIC Engine to provide the capability to limit the Remote Peer's ability to consume receive buffers on a per Stream basis. Unfortunately, this requires a large amount of state to be tracked in each RNIC on a per Stream basis.
RNICエンジンはストリームごとに受信バッファを消費するリモートピアの能力を制限する機能を提供しに別の対策があります。残念ながら、これは、ストリームごとに各RNICに追跡されるべき状態の大量を必要とします。
Thus, if an RNIC Engine provides the ability to share receive buffers across multiple Streams, the combination of the RNIC Engine and the Privileged Resource Manager MUST be able to detect if the Remote Peer is attempting to consume more than its fair share of resources so that the Local Peer or local ULP can apply countermeasures to detect and prevent the attack.
RNICエンジンは、複数のストリーム間で受信バッファを共有する機能を提供する場合このように、RNICエンジンおよび特権リソースマネージャの組み合わせは、リモートピアがそのように資源の公正なシェアよりも多くを消費しようとしているかどうかを検出できなければなりませんローカルピアまたはローカルULPは、攻撃を検知し、防ぐための対策を適用することができます。
For an overview of the shared CQ attack model, see Section 7.1.
共有CQ攻撃モデルの概要については、7.1節を参照してください。
The Remote Peer can attack a shared CQ by consuming more than its fair share of CQ entries by using one of the following methods:
リモートピアは、次のいずれかの方法を使用してCQエントリの公正なシェア以上を消費することによって共有CQを攻撃することができます。
* The ULP protocol allows the Remote Peer to cause the local ULP to reserve a specified number of CQ entries, possibly leaving insufficient entries for other Streams that are sharing the CQ.
* ULPプロトコルは、ローカルULPはおそらくCQを共有している他のストリームには不十分エントリを残し、CQエントリの指定された数を確保させるためのリモートピアすることができます。
* If the Remote Peer, Local Peer, or local ULP (or any combination) can attack the CQ by overwhelming the CQ with completions, then completion processing on other Streams sharing that Completion Queue can be affected (e.g., the Completion Queue overflows and stops functioning).
*リモートピア、ローカルピア、またはローカルULP（または任意の組み合わせが）例えば、完了キューがオーバーフローして停止（その後、他のストリームの終了処理が完了待ち行列が影響を受ける可能性があることを共有し、補完してCQを圧倒的なCQを攻撃することができる場合機能）。
The first method of attack can be avoided if the ULP does not allow a Remote Peer to reserve CQ entries, or if there is a trusted intermediary, such as a Privileged Resource Manager. Unfortunately, it is often unrealistic not to allow a Remote Peer to reserve CQ entries, particularly if the number of completion entries is dependent on other ULP negotiated parameters, such as the amount of buffering required by the ULP. Thus, an implementation MUST implement a Privileged Resource Manager to control the allocation of CQ entries. See Section 2.1, Components, for a definition of a Privileged Resource Manager.
ULPは、リモートピアがCQエントリを確保するために許可されていない場合、または信頼できる仲介者が存在する場合、攻撃の第一の方法は、このような特権リソースマネージャとして、回避することができます。残念ながら、完了エントリの数は、このようなULPによって必要なバッファリングの量などの他のULPに交渉のパラメータ、に依存している場合は特に、CQエントリを予約するリモートピアを許可しないことが多い非現実的です。したがって、実装はCQエントリの割り当てを制御するために特権リソースマネージャを実装しなければなりません。特権リソースマネージャの定義については、セクション2.1、コンポーネントを参照してください。
One way that a Local or Remote Peer can attempt to overwhelm a CQ with completions is by sending minimum length RDMAP/DDP Messages to cause as many completions (receive completions for the Remote Peer, send completions for the Local Peer) per second as possible. If it is the Remote Peer attacking, and we assume that the Local Peer's receive queue(s) do not run out of receive buffers (if they do, then this is a different attack, documented in Section 6.4.3.1 Multiple Streams Sharing Receive Buffers), then it might be possible for the Remote Peer to consume more than its fair share of Completion Queue entries. Depending upon the CQ implementation, this could either cause the CQ to overflow (if it is not large enough to handle all the completions generated) or for another Stream not to be able to generate CQ entries (if the RNIC had flow control on generation of CQ entries into the CQ). In either case, the CQ will stop functioning correctly, and any Streams expecting completions on the CQ will stop functioning.
ローカルまたはリモートピアが補完してCQを圧倒しようとすることを一つの方法は、可能な毎秒（ローカルピアのための補完を送って、リモートピアのための補完を受ける）など、多くの補完を引き起こすために最小長RDMAP / DDPメッセージを送信することです。それは、リモートピアの攻撃であり、我々はローカルピアの受信キュー（複数可）の、彼らがしなければ、これは、セクション6.4.3.1複数のストリームの共有受信バッファに文書化、異なる攻撃である（受信バッファ不足していないと仮定した場合リモートピアが完了キューエントリの公正なシェアよりも多くを消費するために）、それは可能かもしれません。またはRNICはの世代にフロー制御を持っていた場合、別のストリームのために（CQエントリを生成することができるようにするためではない（生成されたすべての補完を処理するのに十分な大きさでない場合）CQの実装に応じて、これは、CQがオーバーフローする可能性がありますいずれかCQ）はCQにエントリー。いずれの場合も、CQは正常に機能を停止し、CQ上の任意のストリーム期待補完が機能を停止します。
This attack can occur regardless of whether all the Streams associated with the CQ are in the same or different Protection Domains - the key issue is that the number of Completion Queue entries is less than the number of all outstanding operations that can cause a completion.
この攻撃は関係なく、CQに関連付けられているすべてのストリームは、同一または異なる保護ドメインにあるかどうかの発生する可能性があります - 重要な問題は、完了キュー・エントリの数が完了したことを引き起こす可能性があり、すべての未処理の操作の数よりも少ないということです。
The Local Peer can protect itself from this type of attack using either of the following methods:
ローカルピアは、次のいずれかの方法を使用して、この種の攻撃から身を守ることができます。
* Size the CQ to the appropriate level, as specified below (note that if the CQ currently exists and needs to be resized, resizing the CQ is not required to succeed in all cases, so the CQ resize should be done before sizing the Send Queue and Receive Queue on the Stream), OR
下に指定されているように適切なレベルに*サイズCQ、（CQが現在存在し、サイズを変更する必要がある場合CQのサイズ変更が送信キューのサイズを決定する前に行う必要がありますので、CQをリサイズすると、すべてのケースで成功するために必要とされていないことに注意してくださいそして、）ストリーム上のキューを受信したり、
* Grant fewer resources than the Remote Peer requested (not supplying the number of Receive Data Buffers requested).
*（要求されたデータ受信バッファの数を供給しない）要求されたリモートピアより少ないリソースを付与します。
The proper sizing of the CQ is dependent on whether the local ULP(s) will post as many resources to the various queues as the size of the queue enables. If the local ULP(s) can be trusted to post a number of resources that is smaller than the size of the specific resource's queue, then a correctly sized CQ means that the CQ is large enough to hold completion status for all the outstanding Data Buffers (both send and receive buffers), or:
CQの適切なサイズは、キューのサイズが可能とローカルULP（s）は、様々なキューにできるだけ多くの資源を投稿するかどうかに依存しています。地元のULP（s）は、特定のリソースのキューのサイズよりも小さくなっているリソースの数を投稿する信頼できる場合は、正しいサイズのCQは、CQは、すべての未処理データバッファの完了状態を保持するのに十分な大きさであることを意味し（送信および受信バッファの両方）、または：
CQ_MIN_SIZE = SUM(MaxPostedOnEachRQ)
+ SUM(MaxPostedOnEachSRQ)
+ SUM(MaxPostedOnEachSQ)
Where:
どこ：
MaxPostedOnEachRQ = the maximum number of requests that
can cause a completion that will be posted on a
specific Receive Queue.
MaxPostedOnEachSRQ = the maximum number of requests that can cause a completion that will be posted on a specific Shared Receive Queue.
MaxPostedOnEachSRQは共用受信キューの特定に掲載されます完了を引き起こす可能性があります要求の最大数を=。
MaxPostedOnEachSQ = the maximum number of requests that can cause a completion that will be posted on a specific Send Queue.
MaxPostedOnEachSQは、特定の送信キューに掲載されます完了を引き起こす可能性があります要求の最大数を=。
If the local ULP must be able to completely fill the queues, or cannot be trusted to observe a limit smaller than the queues, then the CQ must be sized to accommodate the maximum number of operations that it is possible to post at any one time. Thus, the equation becomes:
地元のULPが完全にキューを埋めることができなければならない、またはキューよりも小さい制限を遵守するために信頼することができない場合は、CQは、いずれかの時点で投稿することが可能であることを操作の最大数を収容する大きさにする必要があります。したがって、方程式は次のようになります。
CQ_MIN_SIZE = SUM(SizeOfEachRQ)
+ SUM(SizeOfEachSRQ)
+ SUM(SizeOfEachSQ)
Where:
どこ：
SizeOfEachRQ = the maximum number of requests that
can cause a completion that can ever be posted
on a specific Receive Queue.
SizeOfEachSRQ = the maximum number of requests that can cause a completion that can ever be posted on a specific Shared Receive Queue.
SizeOfEachSRQはこれまで、特定の共有に掲載のキューを受信することができます完了を引き起こす可能性があります要求の最大数を=。
SizeOfEachSQ = the maximum number of requests that can cause a completion that can ever be posted on a specific Send Queue.
SizeOfEachSQは、これまで、特定の送信キューに掲載することができます完了を引き起こす可能性があります要求の最大数を=。
MaxPosted*OnEach*Q and SizeOfEach*Q vary on a per Stream or per Shared Receive Queue basis.
マックスはあたりストリームまたは共有ごとに異なりますが、キューの基礎を各受信* Qそれぞれの* Qとサイズに*投稿しました。
If the ULP is sharing a CQ across multiple Streams that do not share Partial Mutual Trust, then the ULP MUST implement a mechanism to ensure that the Completion Queue does not overflow. Note that it is possible to share CQs even if the Remote Peers accessing the CQs are untrusted if either of the above two formulas are implemented. If the ULP can be trusted not to post more than MaxPostedOnEachRQ, MaxPostedOnEachSRQ, and MaxPostedOnEachSQ, then the first formula applies. If the ULP cannot be trusted to obey the limit, then the second formula applies.
ULPは、部分的な相互信頼を共有していない複数のストリーム間でCQを共有している場合は、ULPは完了待ち行列がオーバーフローしないことを確実にするためのメカニズムを実装しなければなりません。上記の2つの式のいずれかが実装されている場合のCQにアクセスするリモートピアが信頼されていない場合でも、のCQを共有することが可能であることに注意してください。 ULPはMaxPostedOnEachRQ、MaxPostedOnEachSRQ、およびMaxPostedOnEachSQ以上を投稿しないように信頼できる場合は、最初の式が適用されます。 ULPが制限に従うことを信頼することができない場合は、2番目の式が適用されます。
The RDMA Read Request Queue can be attacked if the Remote Peer sends more RDMA Read Requests than the depth of the RDMA Read Request Queue at the Local Peer. If the RDMA Read Request Queue is a shared resource, this could corrupt the queue. If the queue is not shared, then the worst case is that the current Stream is no longer functional (e.g., torn down). One approach to solving the shared RDMA Read Request Queue would be to create thresholds, similar to those described in Section 6.4.3.1, Multiple Streams Sharing Receive Buffers. A simpler approach is to not share RDMA Read Request Queue resources among Streams or to enforce hard limits of consumption per Stream. Thus, RDMA Read Request Queue resource consumption MUST be controlled by the Privileged Resource Manager such that RDMAP/DDP Streams that do not share Partial Mutual Trust do not share RDMA Read Request Queue resources.
リモートピアはローカルピアのRDMA読み取り要求キューの深さよりもRDMA読み取り要求を送信した場合RDMA読み取り要求キューを攻撃することができます。 RDMA読み取り要求キューは共有リソースである場合、これは壊れキューでした。キューが共有されていない場合には、最悪の場合には（例えば、解体）現在のストリームがもはや機能していることではありません。共有RDMA読み取り要求キューを解決するための1つのアプローチは、複数のストリームの共有は、受信バッファ、セクション6.4.3.1で説明したものと同様のしきい値を、作成することです。単純なアプローチでは、Streamsの間でRDMA読み取り要求キューリソースを共有していないか、またはストリームあたりの消費量のハード制限を強制することです。したがって、RDMA読み取り要求キューリソースの消費量が特権リソースマネージャによって制御されなければならない部分相互信頼を共有しないようにRDMAP / DDPストリームは、RDMA読み取り要求キューリソースを共有しません。
If the issue is a bug in the Remote Peer's implementation, but not a malicious attack, the issue can be solved by requiring the Remote Peer's RNIC to throttle RDMA Read Requests. By properly configuring the Stream at the Remote Peer through a trusted agent, the RNIC can be made not to transmit RDMA Read Requests that exceed the depth of the RDMA Read Request Queue at the Local Peer. If the Stream is correctly configured, and if the Remote Peer submits more requests than the Local Peer's RDMA Read Request Queue can handle, the requests would be queued at the Remote Peer's RNIC until previous requests complete. If the Remote Peer's Stream is not configured correctly, the RDMAP Stream is terminated when more RDMA Read Requests arrive at the Local Peer than the Local Peer can handle (assuming that the prior paragraph's recommendation is implemented). Thus, an RNIC implementation SHOULD provide a mechanism to cap the number of outstanding RDMA Read Requests. The configuration of this limit is outside the scope of this document.
問題は、リモートピアの実装のバグではなく、悪意のある攻撃である場合は、問題がRDMA読み取り要求を絞るためにリモートピアのRNICを要求することによって解決することができます。きちんと信頼できるエージェントを介してリモートピアのストリームを構成することによって、RNICは、ローカルピアでRDMA読み取り要求キューの深さを超えたRDMA読み取り要求を送信しないようにすることができます。ストリームが正しく設定されている場合は、リモートピアは、キューを処理することができますローカルピアのRDMA読み取り要求よりも多くのリクエストを送信した場合、要求が完了する前の要求まで、リモートピアのRNICでキューに入れられます。リモートピアのストリームが正しく設定されていない場合は、よりRDMA読み取り要求がローカルピアは、（前段落の勧告が実装されていると仮定して）扱うことができるよりも、ローカルピアに到着したとき、RDMAP Streamが終了されます。このように、RNICの実装では、優れたRDMA読み取り要求の数をキャップするためのメカニズムを提供する必要があります。この制限の構成は、この文書の範囲外です。
Another form of a DOS attack is to attempt to exercise data paths that can consume a disproportionate amount of resources. An example might be if error cases are handled on a "slow path" (consuming either host or RNIC computational resources), and an attacker generates excessive numbers of errors in an attempt to consume these resources. Note that for most RDMAP or DDP errors, the attacking Stream will simply be torn down. Thus, for this form of attack to be effective, the Remote Peer needs to exercise data paths that do not cause the Stream to be torn down.
DOS攻撃の別の形態は、資源の不均衡な量を消費することができ、データ・パスを行使しようとすることです。エラーの場合は、（ホストまたはRNIC計算リソースのいずれかを消費する）「低速パス」で処理されている場合の例ではあるかもしれない、と攻撃者がこれらのリソースを消費しようとする試みで、エラーの過剰な数を生成します。最もRDMAPまたはDDPエラーのため、攻撃ストリームは、単純に解体されることに注意してください。このように、効果的であるためにこの形式の攻撃のために、リモートピアは、ストリームが取り壊されることはありません。データ・パスを行使する必要があります。
If an RNIC implementation contains "slow paths" that do not result in the tear down of the Stream, it is recommended that an implementation provide the ability to detect the above condition and allow an administrator to act, including potentially administratively tearing down the RDMAP Stream associated with the Stream that is exercising data paths, which consume a disproportionate amount of resources.
RNICの実装は、ストリームの取り壊すにはなりません「遅いパス」が含まれている場合、実装が潜在的に管理上RDMAPストリームを取り壊す含め、上記の条件を検出し、管理者が行動することを可能にする機能を提供することをお勧めしますリソースの不均衡な量を消費するデータパスを、運動しているストリームに関連します。
If a Local Peer has enabled an STag for remote access, the Remote Peer could attempt to remotely invalidate the STag by using the RDMAP Send with Invalidate or Send with SE and Invalidate Message. If the STag is only valid on the current Stream, then the only side effect is that the Remote Peer can no longer use the STag; thus, there are no security issues.
ローカルピアは、リモートアクセス用のSTagを有効にしている場合は、リモートピアは、リモートで無効化して送信するか、SEおよび無効化メッセージを送るRDMAPを使用したSTagを無効にしようとする可能性があり。 STagは、現在のストリームにのみ有効である場合には、唯一の副作用は、リモートピアがもはやのSTagを使用できることではありません。このように、何のセキュリティ上の問題はありません。
If the STag is valid across multiple Streams, then the Remote Peer can prevent other Streams from using that STag by using the Remote Invalidate functionality.
STagは、複数のストリーム間で有効である場合は、リモートピアは、リモート無効化機能を使用しているのSTagを使用してから他のストリームを防ぐことができます。
Thus, if RDDP Streams do not share Partial Mutual Trust (i.e., the Remote Peer may attempt to remotely invalidate the STag prematurely), the ULP MUST NOT enable an STag that would be valid across multiple Streams.
RDDPストリームは、部分的な相互信頼を（すなわち、リモートピアがリモート早まったSTagを無効にすることを試みることができる）を共有していない場合はこのように、ULPは、複数のストリーム間で有効になるのSTagを有効にしないでください。
The Remote Peer can attack an unshared CQ if the Local Peer does not size the CQ correctly. For example, if the Local Peer enables the CQ to handle completions of received buffers, and the receive buffer queue is longer than the Completion Queue, then an overflow can potentially occur. The effect on the attacker's Stream is catastrophic. However, if an RNIC does not have the proper protections in place, then an attack to overflow the CQ can also cause corruption and/or termination of an unrelated Stream. Thus, an RNIC MUST ensure that if a CQ overflows, any Streams that do not use the CQ MUST remain unaffected.
ローカルピアが大きCQ正しくない場合は、リモートピアは、非共有CQを攻撃することができます。例えば、ローカルピアは、受信バッファの完了を処理するためにCQを可能にした場合、受信バッファキューが長く完了待ち行列よりも、その後オーバーフローが潜在的に起こり得ます。攻撃者のストリームへの影響は壊滅的です。 RNICが所定の位置に適切な保護を持っていない場合は、その後、CQをオーバーフローする攻撃も無関係なストリームの破損および/または終了を引き起こす可能性があります。このように、RNICは、CQがオーバーフロー場合、CQを使用していない任意のストリームが影響を受けないままなければならないことを保証しなければなりません。
The RDMAP/DDP Security Architecture explicitly differentiates between three levels of privilege: Non-Privileged, Privileged, and the Privileged Resource Manager. If a Non-Privileged ULP is able to elevate its privilege level to a Privileged ULP, then mapping a physical address list to an STag can provide local and remote access to any physical address location on the node. If a Privileged Mode ULP is able to promote itself to be a Resource Manager, then it is possible for it to perform denial of service type attacks where substantial amounts of local resources could be consumed.
非特権、特権、および特権リソースマネージャ：RDMAP / DDPセキュリティアーキテクチャは、明示的に3つの特権のレベルを区別しています。非特権ULP特権ULPへの特権レベルを上昇させることが可能である場合、のSTagに物理アドレスのリストをマッピングするノード上の物理アドレス位置に、ローカルおよびリモートのアクセスを提供することができます。特権モードULPは、リソース・マネージャであることを自分自身を促進することが可能であるならば、それはローカルリソースのかなりの量を消費することができ、サービスタイプ拒否攻撃を実行するために、それが可能です。
In general, elevation of privilege is a local implementation specific issue and is thus outside the scope of this document.
一般に、特権の上昇はローカル実装固有の問題であり、この文書の範囲外ことです。
This section describes local attacks that are possible against the RDMA system defined in Figure 1 - RDMA Security Model and the RNIC Engine resources defined in Section 2.2.
RDMAセキュリティモデルと2.2節で定義されたRNICエンジン資源 - このセクションでは、図1で定義されたRDMAシステムに対して可能なローカルの攻撃について説明します。
DOS attacks against a Shared Completion Queue (CQ - see Section 2.2.6, Completion Queues) can be caused by either the local ULP or the Remote Peer if either attempts to cause more completions than its fair share of the number of entries; thus, potentially starving another unrelated ULP such that no Completion Queue entries are available.
共用完了キュー（CQ - セクション2.2.6、完了キューを参照）に対するDOS攻撃は、どちらかの試みがエントリ数の公正なシェアよりも多くの補完を引き起こす場合ULPローカルまたはリモートピアのいずれかが原因で発生することができます。このように、潜在的に何の完了キュー・エントリが用意されていないことを関係のない別のULPは、飢え。
A Completion Queue entry can potentially be maliciously consumed by a completion from the Send Queue or a completion from the Receive Queue. In the former, the attacker is the local ULP. In the latter, the attacker is the Remote Peer.
完了キュー・エントリは、潜在的に悪意を持って送信キューまたは受信キューからの完了から完了によって消費することができます。前者で、攻撃者がローカルULPです。後者では、攻撃者がリモートピアです。
A form of attack can occur where the local ULPs can consume resources on the CQ. A local ULP that is slow to free resources on the CQ by not reaping the completion status quickly enough could stall all other local ULPs attempting to use that CQ.
地元のULPは、CQ上のリソースを消費することができる場所な攻撃の形が発生する可能性があります。十分に迅速に完了状態を享受していないことでCQ上の空きリソースに遅いローカルULPは、CQことを使用しようとする他のすべてのローカルのULPを停止できます。
For these reasons, an RNIC MUST NOT enable sharing a CQ across ULPs that do not share Partial Mutual Trust.
これらの理由から、RNICは、部分的な相互信頼を共有していないのULP全体でCQを共有可能にしてはなりません。
If RDMA Read Request Queue resources are pooled across multiple Streams, one attack is if the local ULP attempts to unfairly allocate RDMA Read Request Queue resources for its Streams. For example, a local ULP attempts to allocate all available resources on a specific RDMA Read Request Queue for its Streams, thereby denying the resource to ULPs sharing the RDMA Read Request Queue. The same type of argument applies even if the RDMA Read Request is not shared, but a local ULP attempts to allocate all the RNIC's resources when the queue is created.
RDMA読み取り要求キューリソースが複数のストリーム間でプールされる場合はローカルULPが不当にそのストリームのためのRDMA読み取り要求キューリソースを割り当てようとした場合、1回の攻撃があります。例えば、ローカルULPことによりRDMA読み取り要求キューを共有のULPにリソースを拒否、そのストリームのために特定RDMA読み取り要求キュー上のすべての利用可能なリソースを割り当てよう。引数の同じタイプは、RDMA読み取り要求が共有されていない場合にも適用されますが、地元のULPは、キューが作成されたときに、すべてのRNICのリソースを割り当てようとします。
Thus, access to interfaces that allocate RDMA Read Request Queue entries MUST be restricted to a trusted Local Peer, such as a Privileged Resource Manager. The Privileged Resource Manager SHOULD prevent a local ULP from allocating more than its fair share of resources.
したがって、RDMA読み取り要求キューエントリを割り当てるインターフェイスへのアクセスは、このような特権リソースマネージャとして、信頼できるローカルピアに制限しなければなりません。特権リソースマネージャは、資源の公正なシェア以上を割り当てるからローカルULPを防ぐべきです。
If a Non-Privileged ULP is able to directly manipulate the RNIC Page Translation Tables (which translate from an STag to a host address), it is possible that the Non-Privileged ULP could point the Page Translation Table at an unrelated Stream's or ULP's buffers and, thereby, be able to gain access to information of the unrelated Stream/ULP.
非特権ULPは、直接（ホストアドレスへのSTagから変換）RNICページ変換テーブルを操作することができるならば、非特権ULPは無関係なストリームのか、ULPのバッファでページ変換テーブルを指す可能性がありますそして、それによって、無関係なストリーム/ ULPの情報にアクセスすることができます。
As discussed in Section 2, Architectural Model, introduction of a Privileged Resource Manager to arbitrate the mapping requests is an effective countermeasure. This enables the Privileged Resource Manager to ensure that a local ULP can only initialize the Page Translation Table (PTT) to point to its own buffers.
第2節で述べたように、マッピング要求を調停するためのアーキテクチャモデル、特権リソースマネージャの導入が有効な対策です。これは、ローカルULPのみページ変換テーブル（PTT）は、独自のバッファを指すように初期化できることを保証するために、特権リソースマネージャを有効にします。
Thus, if Non-Privileged ULPs are supported, the Privileged Resource Manager MUST verify that the Non-Privileged ULP has the right to access a specific Data Buffer before allowing an STag for which the ULP has access rights to be associated with a specific Data Buffer. This can be done when the Page Translation Table is initialized to access the Data Buffer or when the STag is initialized to point to a group of Page Translation Table entries, or both.
非特権のULPがサポートされている場合はこのように、特権リソースマネージャは、非特権ULPは、ULPは、特定のデータ・バッファに関連付けられるアクセス権を持っているのSTagを許可する前に、特定のデータバッファにアクセスする権利を持っていることを確かめなければなりません。ページ変換テーブルをデータバッファにアクセスするために初期化されるとき、またはのSTagは、ページ変換テーブルエントリ、またはその両方のグループを指すように初期化されるときに行われることができます。
Please see Sections 5, Attacks That Can be Mitigated with End-to-End Security; Section 6, Attacks from Remote Peers; and Section 7, Attacks from Local Peers, for a detailed analysis of attacks and normative countermeasures to mitigate the attacks.
セクション5、エンドツーエンドのセキュリティを緩和することができる攻撃をご覧ください。第6節、リモートピアからの攻撃。そして攻撃を緩和するために攻撃と規範的な対策の詳細な分析のために第7節、ローカルピアからの攻撃、。
Additionally, the appendices provide a summary of the security requirements for specific audiences. Appendix A, ULP Issues for RDDP Client/Server Protocols, provides a summary of implementation issues and requirements for applications that implement a traditional client/server style of interaction. It provides additional insight and applicability of the normative text in Sections 5, 6, and 7. Appendix B, Summary of RNIC and ULP Implementation Requirements, provides a convenient summary of normative requirements for implementers.
また、付録には、特定のユーザーのセキュリティ要件の概要を提供します。付録A、ULPの問題RDDPクライアント/サーバプロトコルについては、実装上の問題との相互作用の伝統的なクライアント/サーバ・スタイルを実装するアプリケーションのための要件の概要を示します。これは、追加的な洞察力とセクション5、6における規範的なテキストの適用、および7付録B、RNICとULP実装要件の概要を提供し、実装のための規範的要件の便利な概要を提供します。
IANA considerations are not addressed by this document. Any IANA considerations resulting from the use of DDP or RDMA must be addressed in the relevant standards.
IANAの考慮事項は、この文書によって対処されていません。 DDPまたはRDMAの使用に起因する任意のIANA問題は、関連規格に取り組まなければなりません。
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007.
[DDP]シャー、H.、ピンカートン、J.、Recio、R.、およびP. Culley、 "信頼性の高いトランスポート上で直接データ配置"、RFC 5041、2007年10月。
[RDMAP] Recio, R., Culley, P., Garcia, D., and J. Hilland, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[RDMAP] Recio、R.、Culley、P.、ガルシア、D.、およびJ. Hilland、 "リモートダイレクトメモリアクセスプロトコル仕様"、RFC 5040、2007年10月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、RFC 4949、2007年8月。
[APPLICABILITY] Bestler, C. and L. Coene, "Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP)", RFC 5045, October 2007.
[利用可能] Bestler、C.とL. Coene、 "リモートダイレクトメモリアクセスプロトコル（RDMA）と直接データ配置（DDP）の適用"、RFC 5045、2007年10月。
[NFSv4CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure Channels", Work in Progress, July 2004.
[NFSv4CHANNEL]ウィリアムズ、N.、「チャンネルを確保するためにチャネルバインディングの使用について」、進歩、2004年7月の作業。
[VERBS-RDMAC] "RDMA Protocol Verbs Specification", RDMA Consortium standard, April 2003, <http://www.rdmaconsortium.org/ home/draft-hilland-iwarp-verbs-v1.0-RDMAC.pdf>.
[動詞-RDMAC] "RDMAプロトコル動詞仕様"、RDMAコンソーシアムの標準、2003年4月、<http://www.rdmaconsortium.org/ホーム/ドラフト-hilland-iWARPの-動詞-v1.0を-RDMAC.pdf>。
[VERBS-RDMAC-Overview] "RDMA enabled NIC (RNIC) Verbs Overview", slide presentation by Renato Recio, April 2003, <http://www.rdmaconsortium.org/home/ RNIC_Verbs_Overview2.pdf>.
[動詞-RDMAC-概要]、レナートRecioにより、スライドプレゼンテーション、2003年4月 "RDMAは、NIC（RNIC）動詞の概要を有効に"、<http://www.rdmaconsortium.org/home/ RNIC_Verbs_Overview2.pdf>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[INFINIBAND] "InfiniBand Architecture Specification Volume 1", release 1.2, InfiniBand Trade Association standard, <http://www.infinibandta.org/specs>. Verbs are documented in chapter 11.
[INFINIBAND] "のInfiniBandアーキテクチャ仕様の第1巻"、インフィニバンドトレード・アソシエーションの標準を1.2をリリース、<http://www.infinibandta.org/specs>。動詞は、第11章に記載されています。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[iSCSIの】Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[のiSER]コ、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターラー、「インターネット小型コンピュータシステムインタフェース（iSCSIの）リモートダイレクトメモリアクセスのための拡張機能（RDMA ）」、RFC 5046、2007年10月。
[NFSv4] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
【のNFSv4] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[NFSv4.1] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "NFSv4 Minor Version 1", Work in Progress, September 2007.
[NFSv4.1] Shepler、S.、エド。、アイスラー、M.、エド。、およびD. Noveck、エド。、 "NFSv4のマイナーバージョン1"、進歩、2007年9月での作業。
Appendix A: ULP Issues for RDDP Client/Server Protocols
付録A：RDDPクライアント/サーバプロトコルのためのULPの問題
This section is a normative appendix to the document that is focused on client/server ULP implementation requirements to ensure a secure server implementation.
このセクションでは、安全なサーバーの実装を確実にするために、クライアント/サーバーULPの実装要件に焦点を当てている文書への規範的な付録です。
The prior sections outlined specific attacks and their countermeasures. This section summarizes the attacks and countermeasures that have been defined in the prior section, which are applicable to creation of a secure ULP (e.g., application) server. A ULP server is defined as a ULP that must be able to communicate with many clients that do not necessarily have a trust relationship with each other, and to ensure that each client cannot attack another client through server interactions. Further, the server may wish to use multiple Streams to communicate with a specific client, and those Streams may share mutual trust. Note that this section assumes a compliant RNIC and Privileged Resource Manager implementation - thus, it focuses specifically on ULP server (e.g., application) implementation issues.
前のセクションでは、特定の攻撃とその対策を概説しました。このセクションでは、セキュアULP（例えば、アプリケーション）サーバーの作成に適用される前のセクションで定義されている攻撃と対策を、まとめたもの。 ULPサーバは、必ずしも相互に信頼関係を持っていない、と各クライアントがサーバの相互作用を介して別のクライアントを攻撃することができないことを確実にするために多くのクライアントと通信できる必要がありますULPとして定義されます。さらに、サーバは特定のクライアントと通信するために複数のストリームを使用することができ、それらのストリームは、相互信頼を共有することがあります。このセクションに準拠RNICおよび特権リソースマネージャの実装を前提としています - ので、それが特異的ULPサーバ（例えば、アプリケーション）の実装上の問題に焦点を当てています。
All of the prior section's details on attacks and countermeasures apply to the server; thus, requirements that are repeated in this section use non-normative "must", "should", and "may". In some cases, normative SHOULD statements for the ULP from the main body of this document are made MUST statements for the ULP server because the operating conditions can be refined to make the motives for a SHOULD inapplicable. If a prior SHOULD is changed to a MUST in this section, it is explicitly noted and it uses uppercase normative statements.
攻撃とその対策について前セクションの詳細のすべてのサーバに適用されます。したがって、このセクションで繰り返されている要件は、非規範的「必見」を使用し、「べき」、および「かもしれません」。動作条件は適用できないべきであるために動機を作るために洗練することができますので、いくつかのケースでは、規範は、このドキュメントの本体からのULPのためのステートメントは、ULPサーバーのMUSTの発言を行っているべきです。前SHOULDは、このセクションのMUSTに変更された場合、それが明示的に指摘され、それが大文字の規範的なステートメントを使用しています。
The following list summarizes the relevant attacks that clients can mount on the shared server by re-stating the previous normative statements to be client/server specific. Note that each client/server ULP may employ explicit RDMA Operations (RDMA Read, RDMA Write) in differing fashions. Therefore, where appropriate, "Local ULP", "Local Peer", and "Remote Peer" are used in place of "server" or "client", in order to retain full generality of each requirement.
以下のリストは、クライアントは、クライアント/サーバ固有であることを再述べる前の規範的な文で共有サーバー上でマウントすることができ、関連する攻撃をまとめたもの。各クライアント/サーバULPは異なるファッションで明示的にRDMAオペレーション（RDMA読み取り、RDMA書き込み）を採用してもよいことに注意してください。したがって、適切な場合には、「ローカルULP」、「ローカルピア」、および「リモートピア」は、各要件の完全な一般性を保持するために、「サーバー」または「クライアント」の代わりに使用されています。
* Spoofing
*なりすまし
* Sections 5.1.1 to 5.1.3. For protection against many forms of spoofing attacks, enable IPsec.
*セクション5.1.3に5.1.1。スプーフィング攻撃の多くの形態に対する保護のため、IPsecを有効にしてください。
* Section 6.1.1, Using an STag on a Different Stream. To ensure that one client cannot access another client's data via use of the other client's STag, the server ULP must either scope an STag to a single Stream or use a unique Protection Domain per client. If a single client has multiple Streams that share Partial Mutual Trust, then the STag can be shared between the associated Streams by using a single Protection Domain among the associated Streams (see Section 5.4.4, ULPs That Provide Security, for additional issues). To prevent unintended sharing of STags within the associated Streams, a server ULP should use STags in such a fashion that it is difficult to predict the next allocated STag number.
*セクション6.1.1、別のストリーム上のSTagを使用しました。 1つのクライアントが他のクライアントののSTagの使用を介して、他のクライアントのデータにアクセスできないようにするには、サーバーのULPは、いずれかのスコープ単一のストリームへのSTagかは、クライアントごとに固有の保護ドメインを使用する必要があります。単一のクライアントは、部分的な相互信頼を共有する複数のストリームを持っている場合、のSTagは、関連するストリームで1つの保護ドメインを（追加の問題については、セクション5.4.4、セキュリティを提供するのULPを参照）を使って、関連するストリーム間で共有することができます。関連ストリーム内スタッグスの意図しない共有を防ぐために、サーバのULPは、次の割り当てスタッグ数を予測することは困難であるような様式でスタッグスを使用すべきです。
* Tampering
*改ざん
* 6.2.2 Modifying a Buffer after Indication. Before the local ULP operates on a buffer that was written by the Remote Peer using an RDMA Write or RDMA Read, the local ULP MUST ensure the buffer can no longer be modified by invalidating the STag for remote access (note that this is stronger than the SHOULD in Section 6.2.2). This can be done either by explicitly revoking remote access rights for the STag when the Remote Peer indicates the operation has completed, or by checking to make sure the Remote Peer Invalidated the STag through the RDMAP Invalidate capability. If the Remote Peer did not invalidate the STag, the local ULP then explicitly revokes the STag remote access rights.
*表示後にバッファの変更6.2.2。地元のULPはRDMA書き込みまたはRDMA読み取りを使用して、リモートピアによって書かれたバッファに作用する前に、地元のULPは、もはや、リモートアクセスのためのSTagを無効化することにより変更することはできないバッファを確保しなければならない（これはより強力であることに注意してください）6.2.2にする必要があります。これは、リモートピアが操作が完了、またはリモートピアがRDMAP無効化機能を通じてのSTagを無効化されたことを確認するためにチェックすることにより、したことを示すときに明示的のSTagのためのリモートアクセス権を取り消すのいずれかによって行うことができます。リモートピアがのSTagを無効にしなかった場合は、ローカルのULPは、明示のSTagリモートアクセス権を取り消します。
* Information Disclosure
* 情報開示
* 6.3.2, Using RDMA Read to Access Stale Data. In a general purpose server environment, there is no compelling rationale not to require a buffer to be initialized before remote read is enabled (and an enormous downside of unintentionally sharing data). Thus, a local ULP MUST (this is stronger than the SHOULD in Section 6.3.2) ensure that no stale data is contained in a buffer before remote read access rights are granted to a Remote Peer (this can be done by zeroing the contents of the memory, for example).
* 6.3.2、古いデータにアクセスするためにRDMA読み取りを使用しました。汎用サーバー環境では、リモート読み取りを有効にする前に初期化するためのバッファ（と意図せずにデータを共有する巨大なマイナス面）を必要としない何の説得力のある根拠はありません。このように、地元のULPのMUST（これは6.3.2項でSHOULDよりも強いです）リモート読み取りアクセス権が（これはの内容をゼロにすることによって行うことができるリモートピアに付与される前に、何の古いデータがバッファに格納されていないことを確認してください例えばメモリ、）。
* 6.3.3, Accessing a Buffer after the Transfer. This mitigation is already covered by Section 6.2.2 (above).
* 6.3.3、転送後にバッファにアクセスします。この緩和策は、既に6.2.2項（上記）で覆われています。
* 6.3.4, Accessing Unintended Data with a Valid STag. The ULP must set the base and bounds of the buffer when the STag is initialized to expose only the data to be retrieved.
* 6.3.4、有効なのSTagで意図しないデータへのアクセス。 STagが取得されるデータのみを露出するように初期化されるときULPは、ベースと、バッファの境界を設定する必要があります。
* 6.3.5, RDMA Read into an RDMA Write Buffer. If a peer only intends a buffer to be exposed for remote write access, it must set the access rights to the buffer to only enable remote write access.
* RDMA書き込みバッファに6.3.5、RDMA読みます。ピアが唯一のリモート書き込みアクセスのために露出されるバッファをしようとするときは、それだけでリモート書き込みアクセスを可能にするために、バッファへのアクセス権を設定する必要があります。
* 6.3.6, Using Multiple STags That Alias to the Same Buffer. The requirement in Section 6.1.1 (above) mitigates this attack. A server buffer is exposed to only one client at a time to ensure that no information disclosure or information tampering occurs between peers.
* 6.3.6、別名と同じ緩衝液に、複数のスタッグスを使用します。 6.1.1項（上記）での要件は、この攻撃を軽減します。サーババッファには情報漏えいや改ざん情報がピア間で生じないことを保証するために、一度に1つのクライアントのみにさらされます。
* 5.3, Network-Based Eavesdropping. Confidentiality services should be enabled by the ULP if this threat is a concern.
* 5.3、ネットワークベースの盗聴。この脅威が懸念される場合には機密性サービスはULPによって有効にする必要があります。
* Denial of Service
* サービス拒否
* 6.4.3.1, Multiple Streams Sharing Receive Buffers. ULP memory footprint size can be important for some server ULPs. If a server ULP is expecting significant network traffic from multiple clients, using a receive buffer queue per Stream where there is a large number of Streams can consume substantial amounts of memory. Thus, a receive queue that can be shared by multiple Streams is attractive.
* 6.4.3.1、複数のストリームの共有は、受信バッファ。 ULPメモリフットプリントサイズは、一部のサーバーのULPために重要であり得ます。サーバは、ULPは、Streamsの多くはメモリのかなりの量を消費する可能性があり、ストリームあたりの受信バッファキューを使用して、複数のクライアントから大量のネットワークトラフィックを期待している場合。このように、複数のストリームで共有することができる受信キューが魅力的です。
However, because of the attacks outlined in this section,
sharing a single receive queue between multiple clients must
only be done if a mechanism is in place to ensure that one
client cannot consume receive buffers in excess of its limits,
as defined by each ULP. For multiple Streams within a single
client ULP (which presumably shared Partial Mutual Trust), this
added overhead may be avoided.
* 7.1 Local ULP Attacking a Shared CQ. The normative RNIC mitigations require that the RNIC not enable sharing of a CQ if the local ULPs do not share Partial Mutual Trust. Thus, while the ULP is not allowed to enable this feature in an unsafe mode, if the two local ULPs share Partial Mutual Trust, they must behave in the following manner:
*共有CQを攻撃7.1ローカルULP。規範RNIC緩和策は、地元のULPは、部分的な相互信頼を共有していない場合RNICはCQの共有を有効にしないことが必要です。このように、ULPは、2つのローカルのULPは、部分的な相互信頼を共有している場合、彼らは、次のように動作する必要があり、危険なモードでこの機能を有効にするために許可されていないながら。
1) The sizing of the completion queue is based on the size of
the receive queue and send queues, as documented in 6.4.3.2,
Remote or Local Peer Attacking a Shared CQ.
2) The local ULP ensures that CQ entries are reaped frequently enough to adhere to Section 6.4.3.2's rules.
2）地元のULPは、CQエントリは、セクション6.4.3.2のルールに従うことに十分な頻度で享受していることを保証します。
* 6.4.3.2, Remote or Local Peer Attacking a Shared CQ. There are two mitigations specified in this section - one requires a worst-case size of the CQ, and can be implemented entirely within the Privileged Resource Manager. The second approach requires cooperation with the local ULP server (not to post too many buffers), and enables a smaller CQ to be used.
* 6.4.3.2、リモートまたはローカルピア共有CQを攻撃。このセクションで指定された2つの緩和策があります - 一つはCQのワーストケースのサイズを必要とし、特権リソースマネージャ内に完全に実装することができます。第2のアプローチは、ローカルULPサーバ（あまりにも多くのバッファを投稿することではない）との協力を必要とし、小さなCQを使用することができます。
In some server environments, partial trust of the server ULP
(but not the clients) is acceptable; thus, the smaller CQ fully
mitigates the remote attacker. In other environments, the
local server ULP could also contain untrusted elements that can
attack the local machine (or have bugs). In those
environments, the worst-case size of the CQ must be used.
* 6.4.3.3, Attacking the RDMA Read Request Queue. The section requires a server's Privileged Resource Manager not to allow sharing of RDMA Read Request Queues across multiple Streams that do not share Partial Mutual Trust for a ULP that performs RDMA Read operations to server buffers. However, because the server ULP knows which of its Streams best share Partial Mutual Trust, this requirement can be reflected back to the ULP. The ULP (i.e., server) requirement, in this case, is that it MUST NOT allow RDMA Read Request Queues to be shared between ULPs that do not have Partial Mutual Trust.
* 6.4.3.3、RDMA読み取り要求キューを攻撃。セクションでは、サーバーバッファにRDMA読み取り操作を実行ULPのための部分的な相互信頼を共有していない複数のストリーム間でRDMA読み取り要求キューの共有を許可しないように、サーバの特権リソースマネージャが必要です。ただし、サーバーULPは、この要件が戻っULPに反映させることができ、そのストリームの最高のシェア部分相互信頼のかを知っているので。 ULP（つまり、サーバー）の要件は、この場合には、それはRDMAリード要求キューは、部分的な相互信頼を持っていないのULPの間で共有できるようにはならないということです。
* 6.4.5, Remote Invalidate an STag Shared on Multiple Streams. This mitigation is already covered by Section 6.2.2 (above).
* 6.4.5、リモート複数のストリーム上の共有のSTagを無効にします。この緩和策は、既に6.2.2項（上記）で覆われています。
Appendix B: Summary of RNIC and ULP Implementation Requirements
付録B：RNICとULP実装要件の概要
This appendix is informative.
この付録は有益です。
Below is a summary of implementation requirements for the RNIC:
以下は、RNICのための実装要件の概要は次のとおりです。
* 3 Trust and Resource Sharing
* 3信頼とリソースの共有
* 5.4.5 Requirements for IPsec Encapsulation of DDP
DDPのIPsecのカプセル化のための* 5.4.5要件
* 6.1.1 Using an STag on a Different Stream
* 6.1.1別のストリーム上のSTagを使用して
* 6.2.1 Buffer Overrun - RDMA Write or Read Response
* 6.2.1バッファオーバーラン - RDMAの書き込みや読み出し応答
* 6.2.2 Modifying a Buffer after Indication
* 6.2.2表示の後にバッファを変更します
* 6.4.1 RNIC Resource Consumption
* 6.4.1 RNICリソース消費
* 6.4.3.1 Multiple Streams Sharing Receive Buffers
* 6.4.3.1複数のストリームの共有受信バッファ
* 6.4.3.2 Remote or Local Peer Attacking a Shared CQ
* 6.4.3.2リモートまたはローカルピア共有CQを攻撃
* 6.4.3.3 Attacking the RDMA Read Request Queue
* 6.4.3.3 RDMA読み取り要求キューを攻撃
* 6.4.6 Remote Peer Attacking an Unshared CQ
非共有CQを攻撃* 6.4.6リモートピア
* 6.5 Elevation of Privilege 39
*特権39の6.5標高
* 7.1 Local ULP Attacking a Shared CQ
共有CQを攻撃* 7.1ローカルULP
* 7.3 Local ULP Attacking the PTT and STag Mapping
PTTとのSTagのマッピングを攻撃* 7.3ローカルULP
Below is a summary of implementation requirements for the ULP above the RNIC:
以下は、RNIC上記ULPのための実装要件の概要は次のとおりです。
* 5.3 Information Disclosure - Network-Based Eavesdropping
* 5.3情報公開 - ネットワークベースの盗聴
* 6.1.1 Using an STag on a Different Stream
* 6.1.1別のストリーム上のSTagを使用して
* 6.2.2 Modifying a Buffer after Indication
* 6.2.2表示の後にバッファを変更します
* 6.3.2 Using RDMA Read to Access Stale Data
* 6.3.2古いデータにアクセスするためのRDMA読み取りを使用しました
* 6.3.3 Accessing a Buffer after the Transfer
* 6.3.3転送後バッファへのアクセス
* 6.3.4 Accessing Unintended Data with a Valid STag
*有効なのSTagと6.3.4へのアクセス意図しないデータ
* 6.3.5 RDMA Read into an RDMA Write Buffer
RDMA書き込みバッファに* 6.3.5 RDMA読みます
* 6.3.6 Using Multiple STags That Alias to the Same Buffer
* 6.3.6と同じ緩衝液にエイリアス複数のスタッグスを使用して
* 6.4.5 Remote Invalidate an STag Shared on Multiple Streams
* 6.4.5リモート複数のストリーム上の共有のSTagを無効に
Appendix C: Partial Trust Taxonomy
付録C：部分信頼分類
This appendix is informative.
この付録は有益です。
Partial Trust is defined as when one party is willing to assume that another party will refrain from a specific attack or set of attacks, the parties are said to be in a state of Partial Trust. Note that the partially trusted peer may attempt a different set of attacks. This may be appropriate for many ULPs where any adverse effects of the betrayal is easily confined and does not place other clients or ULPs at risk.
部分的な信頼関係が一方の当事者が他の当事者が特定の攻撃や攻撃のセットを控えることを前提とする意志があるときのように定義され、当事者は、部分的に信頼の状態にあると言われています。部分的に信頼されたピアが攻撃の異なるセットを試みることがあります。これは裏切りの悪影響を簡単に閉じ込められているとリスクが他のクライアントまたはのULPを置いていない多くのULPのために適切かもしれません。
The Trust Models described in this section have three primary distinguishing characteristics. The Trust Model refers to a local ULP and Remote Peer, which are intended to be the local and remote ULP instances communicating via RDMA/DDP.
このセクションで説明する信頼モデルは、3つの主要な顕著な特徴を有しています。信頼モデルは、RDMA / DDPを介して通信するローカルとリモートのULPインスタンスであることが意図されているローカルULPとリモートピアを指します。
* Local Resource Sharing (yes/no) - When local resources are shared, they are shared across a grouping of RDMAP/DDP Streams. If local resources are not shared, the resources are dedicated on a per Stream basis. Resources are defined in Section 2.2, Resources. The advantage of not sharing resources between Streams is that it reduces the types of attacks that are possible. The disadvantage is that ULPs might run out of resources.
*ローカルリソースの共有（はい/いいえ） - ローカルリソースが共有されている場合、それらはRDMAP / DDPストリームのグループ間で共有されています。ローカルリソースが共有されていない場合は、リソースは、ストリームごとに専用されています。リソースは、セクション2.2、リソースで定義されています。ストリーム間でリソースを共有していないことの利点は、それが可能であり、攻撃の種類を減少させることです。欠点はのULPは、リソースが不足するかもしれないということです。
* Local Partial Trust (yes/no) - Local Partial Trust is determined based on whether the local grouping of RDMAP/DDP Streams (which typically equates to one ULP or group of ULPs) mutually trust each other not to perform a specific set of attacks.
*ローカル部分信頼（はい/いいえ） - ローカル部分信頼は、（典型的には1つのULP又はのULPのグループに相当）RDMAP / DDPストリームのローカルグループが互いに攻撃の特定のセットを実行するために互いを信頼していないかどうかに基づいて決定されます。
* Remote Partial Trust (yes/no) - The Remote Partial Trust level is determined based on whether the local ULP of a specific RDMAP/DDP Stream partially trusts the Remote Peer of the Stream (see the definition of Partial Trust in Section 1, Introduction).
*リモート部分信頼（はい/いいえ） - リモート部分信頼レベルは、特定のRDMAPのローカルULPは/ DDPストリームは、部分的にストリームのリモートピア（第1、はじめに部分信頼の定義を参照してくださいを信頼するかどうかに基づいて決定されます）。
Not all the combinations of the trust characteristics are expected to be used by ULPs. This document specifically analyzes five ULP Trust Models that are expected to be in common use. The Trust Models are as follows:
信頼性のないすべての組み合わせはのULPによって使用されることが期待されています。この文書では、特に一般的な使用であることが予想される5つのULP信頼モデルを分析します。次のように信頼モデルは以下のとおりです。
* NS-NT - Non-Shared Local Resources, no Local Trust, no Remote Trust; typically, a server ULP that wants to run in the safest mode possible. All attack mitigations are in place to ensure robust operation.
* NS-NT - 非共有ローカルリソース、ローカル・トラスト、ノーリモート・トラスト;一般的に、可能な最も安全なモードで実行したいサーバーULP。すべての攻撃の緩和策は、堅牢な動作を確保するための場所です。
* NS-RT - Non-Shared Local Resources, no Local Trust, Remote Partial Trust; typically, a peer-to-peer ULP that has, by some method outside of the scope of this document, authenticated the Remote Peer. Note that unless some form of key based authentication is used on a per RDMA/DDP Stream basis, it may not be possible for man-in-the-middle attacks to occur.
* NS-RT - 非共有ローカルリソース、ローカル・トラスト、リモート部分信頼。典型的には、この文書の範囲外のいくつかの方法によって、有するピア・ツー・ピアULPは、リモートピアを認証しました。キーベースの認証のいくつかのフォームは、RDMA / DDPストリームごとに使用されていない限り、それが発生するman-in-the-middle攻撃は可能ではないかもしれないことに注意してください。
* S-NT - Shared Local Resources, no Local Trust, no Remote Trust; typically, a server ULP that runs in an untrusted environment where the amount of resources required is either too large or too dynamic to dedicate for each RDMAP/DDP Stream.
* S-NT - 共有ローカルリソース、ローカル・トラスト、ノーリモート・トラスト;一般的に、必要なリソースの量が多すぎる又は各RDMAP / DDPストリームのための専用すぎ動的のいずれかであり、信頼できない環境で実行サーバULP。
* S-LT - Shared Local Resources, Local Partial Trust, no Remote Trust; typically, a ULP that provides a session layer and uses multiple Streams, to provides additional throughput or fail-over capabilities. All the Streams within the local ULP partially trust each other, but do not trust the Remote Peer. This Trust Model may be appropriate for embedded environments.
* S-LT - 共有ローカルリソース、ローカル部分信頼のないリモート・トラスト。典型的には、セッション層を提供し、追加のスループットを提供するか、フェイルオーバー機能をするために、複数のストリームを使用ULP。地元のULP内のすべてのストリームは、部分的にお互いを信頼しますが、リモートピアを信用していません。この信頼モデルは、組み込み環境のために適切かもしれません。
* S-T - Shared Local Resources, Local Partial Trust, Remote Partial Trust; typically, a distributed application, such as a distributed database application or High Performance Computer (HPC) application, which is intended to run on a cluster. Due to extreme resource and performance requirements, the application typically authenticates with all of its peers and then runs in a highly trusted environment. The application peers are all in a single application fault domain and depend on one another to be well-behaved when accessing data structures. If a trusted Remote Peer has an implementation defect that results in poor behavior, the entire application could be corrupted.
* S-T - 共有ローカルリソース、ローカル部分信頼、リモート部分信頼。一般的に、そのようなクラスタ上で実行するように意図された分散データベース・アプリケーションや高性能コンピュータ（HPC）アプリケーションなどの分散アプリケーション、。極端なリソースとパフォーマンスの要件に、アプリケーションは通常、すべてのピアを認証し、非常に信頼できる環境で動作します。アプリケーションのピアは、単一のアプリケーション障害ドメイン内のすべてであり、データ構造にアクセスするとき行儀ことをお互いに依存しています。信頼されたリモートピアが悪い行動につながる実装の欠陥がある場合は、アプリケーション全体が破損している可能性があります。
Models NS-NT and S-NT, above, are typical for Internet networking - neither the local ULP nor the Remote Peer is trusted. Sometimes, optimizations can be done that enable sharing of Page Translation Tables across multiple local ULPs; thus, Model S-LT can be advantageous. Model S-T is typically used when resource scaling across a large parallel ULP makes it infeasible to use any other model. Resource scaling issues can either be due to performance around scaling or because there simply are not enough resources. Model NS-RT is probably the least likely model to be used, but is presented for completeness.
モデルNS-NTおよびS-NTは、上記、インターネットネットワーキングのための典型的なものである - 地元ULPもリモートピアどちらが信頼されています。時には、最適化は、複数のローカルのULP間でページ変換テーブルの共有を可能に行うことができます。従って、モデルS-LTは、有利であり得ます。リソースが大きな平行ULP横切ってスケーリングする場合、モデルS-Tは、典型的に使用される任意の他のモデルを使用することが不可能となります。リソーススケーリングの問題が原因スケーリング周囲または単に十分なリソースがないため、パフォーマンスにのいずれかであることができます。モデルNS-RTは、おそらく使用する最も可能性の高いモデルですが、完全性のために提示されます。
Acknowledgments
謝辞
Sara Bitan Microsoft Corporation EMail: sarab@microsoft.com
サラBitan Microsoft CorporationのEメール：sarab@microsoft.com
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose, CA 95134 USA Phone: +1 (408) 525-8836 EMail: allyn@cisco.com
アリンRomanowシスコシステムズ170 Wタスマン・ドライブサンノゼ、CA 95134 USA電話：+1（408）525から8836 Eメール：allyn@cisco.com
Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 USA EMail: meadows@itd.nrl.navy.mil
キャサリン・メドウズ海軍研究所コード5543ワシントンD.C. 20375 USA Eメール：meadows@itd.nrl.navy.mil
Patricia Thaler Agilent Technologies, Inc. 1101 Creekside Ridge Drive, #100 M/S-RG10 Roseville, CA 95678 USA Phone: +1 (916) 788-5662 EMail: pat_thaler@agilent.com
パトリシア・ターラーアジレント・テクノロジー株式会社1101年クリークサイドリッジドライブ、＃100 M / S-RG10ローズ、CA 95678 USA電話：+1（916）788から5662 Eメール：pat_thaler@agilent.com
James Livingston NEC Solutions (America), Inc. 7525 166th Ave. N.E., Suite D210 Redmond, WA 98052-7811 USA Phone: +1 (425) 897-2033 EMail: james.livingston@necsam.com
ジェームズ・リビングストンNECソリューションズ（アメリカ）社7525第166アベニュー。 N.E.、スイートD210レドモンド、WA 98052から7811 USA電話：+1（425）897から2033 Eメール：james.livingston@necsam.com
John Carrier Cray Inc. 411 First Avenue S, Suite 600 Seattle, WA 98104-2860 Phone: 206-701-2090 EMail: carrier@cray.com
ジョン・キャリアのCray Inc.の411まずアベニューS、スイート600シアトル、WA 98104から2860電話：206-701-2090 Eメール：carrier@cray.com
Caitlin Bestler Broadcom 49 Discovery Irvine, CA 92618 EMail: cait@asomi.com
ケイトリンベストBroadcomの49ディスカバリーアーバイン、CA 92618 Eメール：cait@asomi.co
Bernard Aboba Microsoft Corporation One Microsoft Way USA Redmond, WA 98052 Phone: +1 (425) 706-6606 EMail: bernarda@windows.microsoft.com
バーナードAbobaマイクロソフト社1つのマイクロソフト道、米国ワシントン州レッドモンド98052電話：+1（425）706から6606 Eメール：bernarda@windows.microsoft.com
Authors' Addresses
著者のアドレス
James Pinkerton Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 (425) 705-5442 EMail: jpink@windows.microsoft.com
ジェームズ・ピンカートンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA電話：+1（425）705から5442 Eメール：jpink@windows.microsoft.com
Ellen Deleganes Self P.O. Box 9245 Brooks, OR 97305 Phone: (503) 642-3950 EMail: deleganes@yahoo.com
エレンDeleganes自己私書箱ボックス9245ブルックス、OR 97305電話：（503）642から3950 Eメール：deleganes@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。