[要約] RFC 5042は、DDP/RDMAPプロトコルのセキュリティに関するものであり、データの直接配置とリモートダイレクトメモリアクセスのセキュリティを強化するためのガイドラインを提供しています。目的は、DDP/RDMAPプロトコルのセキュリティ上の脆弱性を特定し、それらを防ぐための対策を提案することです。
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
ダイレクトデータ配置プロトコル（DDP） /リモートダイレクトメモリアクセスプロトコル（RDMAP）セキュリティ
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.
RDMAは、現在の従来のネットワーキング慣行（ストリームベースのモデルまたはデータグラムモデルなど）と比較して、2つの関係者間で通信するときに新しいレベルの柔軟性を可能にします。この柔軟性は、RDMAを利用して上層層プロトコル（ULPS）を設計し、RDMA認識NIC（RNIC）を実装するときに慎重に理解する必要がある新しいセキュリティの問題をもたらします。このセキュリティ分析の目的のために、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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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がストリーム間で共有できるリソースと、セクション3のストリームを横切るリモートピアとローカルULPが共有できるリソースを定義します。
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.
Partial Mutual Trust- 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.
ULPSは、付録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が堅牢で妥協のないことを保証したい場合、信頼されていないピア関係が適切です。たとえば、複数の無関係なストリーム（サーバーなど）を同時にサポートする単一の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、RDDPクライアント/サーバープロトコルのULPの問題は、従来のクライアント/サーバープロトコルの実装者に焦点を当てています。付録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-Overview]、および[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エンジンに関連するリソースの管理と割り当てを担当するコンポーネント。リソースマネージャーはデータを送信または受信しません。リソースマネージャーが独立したコンポーネントであるかどうか、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、紹介を参照してください。ローカルホストインフラストラクチャにより、特権的なULPは、RNICインターフェイスを介してデータバッファーをRNICエンジンからホストに直接マッピングできますが、特権的な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エンジンに直接データを送信および受信することを許可することです。したがって、このドキュメントの主な目標の1つは、システムが安全なままであることを確認するために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.
* タグ付きデータ転送-Peerは、ペイロードを送信するピアは、雄鹿の使用を通じて、どの宛先バッファーがターゲットにされているかを明示的に述べています。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メッセージとタグ付けされた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エンジンリソースを割り当てます。特権的なリソースマネージャーは、対策を実装して、非恵まれないULPが攻撃を開始した場合、攻撃が他のULPに影響を与えるのを防ぐことができることを保証します。
* Non-Privileged Data Transfer Interface - A Non-Privileged ULP uses this interface to initiate and check the status of data transfer operations.
* 非主要なデータ転送インターフェイス-Privileged 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は、RNICエンジンマッピングリソースを直接操作して、STAGをULPデータバッファーにマッピングすることができます。
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.
各ストリームの状態情報はメモリに維持されます。メモリは、多くの場所に配置できます。NIC、NICに取り付けられたRAM内、ホストメモリ、または実装に応じて3つの組み合わせです。
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つの異なる方法があります：Untaggedデータ転送。DDPキューゼロでRDMAP送信タイプメッセージ（別名DDP Untaggedメッセージ）を受信するためにバッファーを公開できる、またはタグ付きデータ転送、バッファーをスタッグを介してリモートアクセスのために公開できる場所（別名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.
いずれにせよ、消費者が公開する権限がないという記憶を公開する雄鹿を作成できないことを保証することは、特権的なリソースマネージャーの責任です。
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は、データバッファーがローカルのみまたはローカルおよびリモートアクセスに露出しているかどうかを制御し、特定のアクセス特権（読み取り、書き込み、読み取り、書き込み）を1ストリームごとに割り当てることができます。
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.
DDPの場合、STAGが宣伝されている場合、リモートピアにはおそらくデータへの書き込みアクセス権が与えられます（そうでなければ、広告にはあまり意味がありません）。RDMAPの場合、ULPがSTAGを宣伝する場合、書き込みのみ、読み取り専用、または書き込みアクセス権を有効にすることができます。
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のマッピングの完了。完了キューは、ストリームのグループによって共有される場合や、特定のストリームのトラフィックを処理するように指定される場合があります。RDMAP/DDPストリームの完了キューアソシエーションを1つまたは少数に制限することで、攻撃の効果の範囲を大幅に制限することにより、いくつかの形式の攻撃を防ぐことができます。
Some implementations may allow this queue to be manipulated directly by both Non-Privileged and Privileged ULPs.
いくつかの実装により、このキューは、非恵まれないULPと特権の両方の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からBounded Sizeの特権リソースマネージャーまでのキューです。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.
実装は、複数のキューや単純なコールバックなど、非同期イベントキューの関数をさまざまな方法で実装するためのLibertyにあることに注意してください。特定されたすべての脆弱性は、非同期イベントキューの実装に関係なく、適用することを目的としています。たとえば、コールバック関数は、単に非常に短いキューと見なされる場合があります。
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読み取り要求キューは、到着した1つ以上のRDMA読み取りリクエストメッセージの状態情報を保持するメモリですが、RDMA読み取り応答メッセージはまだ完全に送信されていません。潜在的に複数の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つの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と直接通信することにより、特定のSTAGマッピングを有効にして無効にすることができます。
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データは、以前に説明したデータ転送メカニズムの1つである未編成データ転送またはタグ付きデータ転送によって送信できます。2つのRDMAPデータ転送メカニズムが定義されています。1つは未編成データ転送（タイプメッセージの送信）を使用し、もう1つはタグ付きデータ転送（RDMA読み取り応答とRDMAの書き込み）を使用します。RDMAPを介したULPデータ受信は、受信キューに投稿されたバッファーまたは共有の受信キューに送信タイプメッセージを受信することで実行できます。したがって、受信キューまたは共有の受信キューは、未編成データ転送のみの影響を受けることができます。データ受信は、RDMA書き込みとRDMAの読み取り応答メッセージを受信して、STAGの広告（つまり、タグ付きのデータ転送）を通じて外部書き込みアクセスのために公開されていたバッファーに読み取ります。さらに、ネットワーク全体で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は、受信キューに投稿されたバッファーまたは共有の受信キューに編集されていないメッセージを受け取ることができます。また、タグ付きのDDPメッセージをバッファーに受信することもできます。バッファーは、以前にはSTAGの広告を通じて外部書き込みアクセスのために公開されていました。
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.
特権的なデータインターフェイスセマンティクスは、非具体的なデータ転送セマンティクスのスーパーセットです。インターフェイスは、前のセクションで定義されているすべてのものを実行したり、バッファーを作成/破壊してSTAGマッピングを直接作成したりできます。これには、一般に、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. 割り当てられたSTAG名からページ翻訳テーブルエントリのセットまたは部分エントリへのマッピングの初期化。
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.
ページ翻訳テーブルの正確なリソース割り当てアルゴリズムは、このドキュメントの範囲外です。特定のデータバッファーに割り当てられたり、潜在的に複数のデータバッファーによって消費されるプールされたリソースとして割り当てられたり、他の方法で管理されたりする場合があります。このドキュメントは、実装に依存する問題を抽象化し、それらをリソースの飢vateやストリーム間のリソースの共有など、より高いレベルのセキュリティの問題にグループ化しようとします。
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を使用して内部的に攻撃されていないデータバッファを表現することを選択した場合、バッファを表す雄鹿が存在する可能性があることに注意してください。ただし、定義上、スタッグはワイヤー上に表示されないため、これはローカルホストの実装固有の問題であり、ローカルホストの実装固有のセキュリティ分析のコンテキストで分析する必要があり、したがって、範囲外です。このドキュメントの。
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、複数のSTAGで同じバッファにアクセスします。
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をマッピングするためのさまざまな実装オプションがあります。これには、STAGのマッピングとページ翻訳テーブルのセットのマッピングのマッピングのサポート、およびULPのサポートがページ翻訳テーブルエントリマッピングに直接操作するサポート（特権リソースマネージャーを介したアクセスが必要です）が含まれます。
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.
受信操作は、タグ付きデータバッファーと未編性のデータバッファー（つまり、タグ付きデータ転送と未編成データ転送）で異なります。Untaggedデータ転送の場合、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読み取りバッファー）を受信した場合、データ転送の前に、特定のページ翻訳テーブルへのマッピング（存在する場合）、およびページ翻訳データバッファーへのテーブルエントリは初期化されている必要があります（相互作用の詳細については、セクション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のリソースで定義されています。ストリーム間でリソースを共有しないという利点は、可能な攻撃の種類を減らすことです。リソースを共有しないことの欠点は、ULPSがリソースを使い果たす可能性があることです。したがって、リソースの共有に関連するセキュリティの問題を軽減できる場合、リソースを共有するための強力なインセンティブがある可能性があります。
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インターフェイスを通じて特権リソースマネージャーにリソースを公開します。すべての特権的で非恵まれないULPSは、リソースマネージャーにリソースを要求します（定義上、非恵まれないアプリケーションと特権アプリケーションの両方がリソースを貪欲に消費しようとする可能性があることに注意してください。リソースマネージャーは、リソースへの公正なアクセスを確保するために、リソース管理ポリシーを実装しています。リソースマネージャーは、このドキュメントに詳述されているセキュリティ攻撃を考慮するように設計する必要があります。一部のシステムでは、特権的なリソースマネージャーが特権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の希望を共有するリソースのレベルの両方で、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.
特権的なリソースマネージャーは、ストリームが実際に部分的な相互信頼を共有することを保証するメカニズムがない限り、異なるストリームが部分的な相互信頼を共有していると仮定してはなりません。これは、ストリームを所有する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では、RDMAP/DDPメッセージを転送する前に、初期LLPストリーム（および接続）を設定する必要があります。これには、少なくとも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リソースを攻撃する前に現在のLLPストリームパラメーター（TCPシーケンス番号など）を推測する必要があります。このクラスの攻撃者にも、送信者への受信機として、レシーバーへの送信者へのポーズをとる機能が受け取られている場合、通常は「中間の」攻撃者[RFC3552]と呼ばれます。中間の攻撃者は、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 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.
接続のセットアップと解体は、ストリームモード（つまり、ペイロードのRDMAカプセル化はない）で行われると推定されるため、LLPに既に存在するものを超えて接続のセットアップ/解体に関連する新しい攻撃はありません（例えば、TCPまたはSCTP）。ただし、RDMAP/DDPパラメーターはストリームモードで交換される可能性があり、攻撃者が意図しない結果によって破損している場合は、結果として生じることに注意してください。したがって、LLPスプーフィング、改ざん、拒否、情報の開示、サービスの拒否、または特権の昇格のための既存の緩和は、引き続き適用され続けます（そして、この文書の範囲外です）。したがって、このセクションの分析では、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.).
改ざんは、合法的なトラフィック（マシン内部またはネットワーク）の変更です。スプーフィング攻撃は、攻撃者がリモートピアのアイデンティティを偽造する場所を改ざんする特別なケースです（IDは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.
ネットワークベースの攻撃者は、法的なRDMAP/DDPピアになりすまします（法的IPアドレスをスプーフィングすることにより）。これは、ブラインド攻撃として行うこと（[RFC3552]を参照）として、または被害者とRDMAP/DDPストリームを確立することによって行うことができます。RDMAP/DDPストリームでは、LLPストリームを完全に初期化する必要があるため（たとえば、[RFC793]、確立された状態）、ブラインド攻撃に対する既存の輸送層保護メカニズムは残ります。
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.
ブラインド攻撃を成功させるには、攻撃者が有効な輸送層セグメントを注入する必要があります（たとえば、TCPの場合、少なくとも4タプルとウィンドウ内のシーケンス番号を推測する必要があります）。DDPパラメーター。輸送プロトコルが脆弱であると想定されている場合、RDMAP/DDPプロトコルを攻撃する方法はたくさんあります。たとえば、タグ付けされたメッセージの場合、これには雄鹿と値を推測することが伴います。攻撃者が単純に接続を終了したい場合、トランスポートとネットワーク層の値を正しく推測し、無効な雄鹿を提供することでそうすることができます。DDP仕様に従って、無効なSTAGが受信された場合、ストリームは取り壊され、リモートピアはエラーで通知されます。攻撃者が広告されたバッファーの上書きを希望する場合、正しい雄鹿を推測する必要があります。toはしばしばゼロから始まることを考えると、これは簡単です。セクション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によって確立されているため、一部のLLPは他のLLPよりもハイジャックするのが困難です。接続および/またはストリームハイジャックに関するセキュリティ問題に関する関連する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.
ネットワークベースの攻撃者が、LLPによってまだ受け入れられるパケットを削除または変更する機能（たとえば、TCPシーケンス番号が正しい）を持っている場合、ストリームは中間の攻撃にさらされる可能性があります。1つのスタイルの攻撃は、中間者がタグ付きメッセージ（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などのエンドツーエンドの整合性の保護と認証です。認証と整合性の保護が使用されない場合、中間の攻撃を防ぐために物理的保護を採用する必要があります。
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によって確立されているため、一部のLLPは他のLLPよりも中間の攻撃によりさらされています。接続および/またはストリームハイジャックに関するセキュリティ問題に関する関連する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.
これは実際には中程度の攻撃ですが、上記のマンインザミドル攻撃とは対照的に、シグナリングとコンテンツの両方を変更できる中間攻撃とは対照的に、バッファの内容のみです。セクション5.1.3、中間攻撃を参照してください。
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、中間の攻撃も参照してください。暗号化は、ULPによって、またはRDMAPとDDP（IPSECなど）にセキュリティサービスを提供できるプロトコルによって実行できます。
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）、認証と組み合わせると、中間の攻撃（セクション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]文書内で指定されています。IKEは主要な管理プロトコルであり、AHとESPはIPトラフィックを保護するために使用されます。それぞれのプロトコルの完全な説明については、これらの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の接続オリエンテーションにより、TLSはDDP/RDMAセキュリティに不適切になります。CBCモードのストリーム暗号またはブロック暗号がバルク暗号化に使用される場合、その前のすべてのパケットがすでに到着した後にのみパケットを解読できます。TLSがDDP/RDMAPトラフィックを保護するために使用される場合、TLSがそれらを復号化する前に、TCPはすべてのオーダーアウト外のパケットを収集する必要があります。これが完了した後にのみ、RDMAP/DDPをULPバッファーに配置できます。したがって、DDP/RDMAPの主要な機能の1つは、データストリームを保護するために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から採用されたメカニズムに基づくアンチレプレイが含まれます。これらおよびその他の理由により、DTLはTCPの下にDTLSを使用することによりRDDPに最適に適用され、UDP/IPを超えるDTLを超えるTCPを超えるRDDPの層を生成します。このようなレイヤー化は、IPSECとプロトコルスタックでDTLSをほぼ同じレベルに挿入し、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はセキュリティフレームワークに適しているため、必須です（このドキュメントの他の場所で指定されているように）。DTLではなくIPSECの仕様に重要な要因は、RDDP（ISCSI [ISCSI] [ISER]およびNFSV4 [NFSV4] [NFSV4.1]）の2つの初期採用者の非RDDPバージョンがIPSECと互換性があることですこれらのプロトコルのうち、現在、TLSまたはDTLSを使用しています。ISCSIの特定のケースでは、IPSECは、実装対象のセキュリティサービスの基礎です[RFC3723]。したがって、このドキュメントとRDDPプロトコル仕様には、DTLではなくIPSECの必須の実装要件が含まれています。
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]:
統合されたセキュリティを提供するが、低層プロトコルのセキュリティを活用したいULPSは、特定のチャネルのセキュリティメカニズムを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."
「チャネルバインディングの概念により、アプリケーションは、異なるネットワークレイヤーでの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, including the associated normative references for those sections. Note that this means that support for IPSEC ESP mode is normative.
IPストレージワーキンググループは、IPストレージの規範的なIPSEC要件を定義するためにかなりの時間と労力を費やしました[RFC3723]。その仕様の一部は、RDDPプロトコルスイートを含むさまざまなプロトコルに適用できます。この取り組みを再現しないために、RNICの実装は、これらのセクションの関連する規範的参照を含む、RFC 3723、セクション2.3およびセクション5で定義されている要件に従う必要があります。これは、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 SASのみを処理できる可能性があるため、アクティブフェーズ2 SAの数を最小限に抑える手段として、フェーズ2削除メッセージをアイドルSASに送信できます。IKE Phase 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.
RDDPのIPSEC要件は、RFC 3723 [RFC3723]によってプロファイルされたRFC 3723 [RFC3723]で紹介されているように、RFC 2401 [RFC2401]および関連RFCで指定されたIPSECのバージョンに基づいています。RFCS。RDDPプロトコルの重要な初期のアプリケーションの1つは、ISCSI [ISER]での使用です。RDDPのIPSEC要件は、IPSECの共通プロファイルをISCSIおよびRDDPプロトコルで使用できるようにすることにより、その使用を容易にするためにIPSECの要件に従います。将来、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.
このセクションでは、図1 -RDMAセキュリティモデルとセクション2.2で定義されているRNICエンジンリソースで定義されている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つのカテゴリに分類されます。前述のように、改ざんは合法的なトラフィック（マシン内部またはネットワーク）の変更です。スプーフィング攻撃は、攻撃者がリモートピアのアイデンティティを偽造する場所を改ざんする特別なケースです（IDは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.
リモートピアからの攻撃の1つのスタイルは、使用が許可されていないSTAG値を使用しようとすることです。DDPおよびRDMAP仕様に従って、リモートピアがローカルピアに無効なスタッグを送信する場合、ストリームを取り壊す必要があることに注意してください。したがって、1つのストリームでのリモートアクセスのためにSTAGが有効になっており、リモートピアが無関係なストリームで使用できる場合、脅威が存在します。攻撃が成功した場合、攻撃者はRDMA読み取り操作を実行して関連するデータバッファーのコンテンツを読み取るか、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.
同じ保護ドメインの別のストリームに雄鹿のあるバッファーにアクセスしようとするリモートピアが、リソース共有が意図されているかどうか（つまり、ストリームが部分的な相互信頼を共有したかどうか）に応じて、攻撃である場合とそうでない場合があります。一部のULPSの場合、同じ保護ドメイン内の複数のストリームにSTAGを使用することが望ましい動作があります。他のULPSの場合、別のストリームでSTAGを使用しようとすることは、攻撃と見なされる可能性があります。これはULPによって異なるため、ULPは通常、雄鹿の範囲を制御できる必要があります。
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.
実装がストリーム（Stagsを含む）間でリソースを共有しない場合、この攻撃は、各ストリームを異なる保護ドメインに割り当てることで打ち負かすことができます。バッファーへのリモートアクセスを許可する前に、アクセスの試行が行われたストリームの保護ドメインは、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の範囲を単一のストリームに制限することができます（リモートアクセスのためにそれを有効にしている場合）。STAGスコープが単一のストリームに制限されている場合、異なるストリームでその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.
したがって、ストリーム間で雄鹿を共有しない実装の場合、各ストリームは別の保護ドメインにある必要があります。
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.
RNICは、STAGの範囲が単一のストリームに制限されている場合、他のストリームが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).
追加の問題は、オフ1つのスタッグを使用するリモートピアの雄鹿の意図しない共有（つまり、ULPのバグ）またはバグです。追加の保護のために、実装では、次の割り当てられたスタッグ数を予測することが困難であり、雄しべが可能な限り遅い速度で再利用されることを保証するために、実装が舞台を割り当てる必要があります。ピアによる雄鹿の意図的または意図しない再利用につながる割り当て方法は避ける必要があります（たとえば、常に特定の雄鹿から始まり、各新しい割り当てに対して単調にそれを増やすか、または常に同じ雄鹿を使用する方法でそれを増やします操作ごと）。
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.
このタイプの攻撃の対策は、RNIC実装にあり、STAGを活用する必要があります。ローカルULPがRNICに、アクセス可能にしたいバッファー内のバイテスのumberをRNICに指定する場合、RNICは、ベースとバウンドチェックが雄しべの前に参照されたバッファーにアクセスするために、ベースとバウンドチェックが適用されることを確認する必要があります。STAGがアクセスできるようになります。RDMAデータ転送操作（STAGを含む）がストリームに到着する場合、操作がその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.
この攻撃は、リモートピアが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の動作は最初に制御情報を検証し、次に制御情報の操作を実行することであると仮定します。リモートピアが追加の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は、リモートピアが操作が完了したことを示すときに、雄鹿のリモートアクセス権を明示的に取り消すことによって、またはRDMAPリモートの無効化機能を介してリモートピアがSTAGを無効にしたことを確認することにより、これを行うことができます。リモートピアがSTAGを無効にしなかった場合、ローカルULPはStagリモートアクセス権を明示的に取り消します。（セクション6.4.5を参照してください。リモートは、リモートの無効化の定義のために、複数のストリームで共有されているSTAGを無効にします。）
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を使用して、以前に宣伝されたバッファーにSTAGを使用してバッファーを変更できなくなることを確認する必要があります。
See Section 6.3.6 Using Multiple STags That Alias to the Same Buffer, for this analysis.
この分析のために、同じバッファーにエイリアスを使用した複数のSTAGを使用したセクション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.
これは、RDMA読み取り要求が攻撃の取り付けに使用されることを除いて、セクション6.2.1、バッファオーバーランで説明されているバッファーオーバーランまたは読み取り応答と基本的に同じ攻撃です。同じ対策が適用されます。
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が、バッファー全体を参照する雄鹿を使用してバッファーにリモートアクセスできるが、バッファーの一部のみにアクセスすることを意図している場合、リモートピアはとにかくバッファーの他の部分にアクセスすることができます。
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は、スタッグが初期化されたときにバッファーのベースと境界を設定して、取得するデータのみを公開する必要があります。
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.
バッファーのアクセス権がリモートの読み取りを有効にした場合、リモートの書き込みアクセスのみが意図されている場合、1つの形式の開示が発生する可能性があります。バッファに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ストリームが終了します。
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.
同じバッファーに同時にエイリアスする複数のSTAGは、異なる相互に信頼されていないリモートピアによって雄鹿が使用されている場合、意図しない情報開示をもたらす可能性があります。このモデルは、サーバーが複数のクライアントと通信しているクライアント/サーバー通信に特に適用されます。
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は情報開示を完全に制御できます。したがって、同じデータ（つまり、バッファー）を複数のクライアントに同じバッファーに使用して複数のクライアントに公開することを目的としたサーバーは、このドキュメントで既に説明されているものを超えて新しいセキュリティの問題を作成しません。サーバーが同じデータをクライアントに公開するつもりがない場合、クライアントごとに個別のバッファー（および個別のSTAG）を使用する必要があることに注意してください。
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が同じバッファーにリモート書き込みアクセスを有効にしている場合、あるリモートピアが別のリモートピアによって書かれたコンテンツを表示することができます。
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は、異なるスタッグを介して同じバッファーへの書き込みアクセスを許可してはなりません。バッファーは、ピア間で情報の開示や情報の改ざんが発生しないことを確認するために、一度に1つの信頼されていないリモートピアに露出する必要があります。
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の主要なセキュリティリスクの1つです。これは、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, 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.
このセクションでは、希少な（つまり、境界付き）RNICリソースを不当に割り当てようとするローカルULPの一般的なカテゴリに分類される攻撃をカバーしています。地元のULPは、リソースを代表する、またはリモートピアに代わってリソースを割り当てようとしている可能性があります。このカテゴリに分類されるリソースには、保護ドメイン、ストリームコンテキストメモリ、翻訳および保護テーブル、およびスタッグネームスペースが含まれます。これらは、現在アクティブなローカルULPSまたは以前にリソースを割り当てたが今ではアイドル状態になっているものによる攻撃による可能性があります。
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.
この分析では、リソースマネージャーが保護ドメインを配布する責任があり、RNIC実装により、リソースマネージャーが無関係で信頼されていないULPごとにユニークな保護ドメインを割り当てることができるように十分な保護ドメインを提供することを前提としています（境界のある地域の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リソースは、リソースを消費するためにリモートピアがメッセージを送信するためにリモートピアが必要とするため、一部の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のUntagged Buffersまたは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.
ローカルピアが使用できる方法の1つは、リモートピアがリソースの公正なシェア以上の使用を試み、ストリームを終了しようとしていることを認識することです（割り当てられたリソースがリリースされます）。ただし、地元のピアが十分に遅い場合、リモートピアがサービス拒否攻撃を引き起こすことが可能です。この攻撃から保護できる対策の1つは、低水通知を実装することです。低水通知は、受信キュー内のバッファーの数がしきい値未満である場合、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.
別の、しかし類似した攻撃は、リモートピアがかなりの数のオーダーアウト外パケットを送信し、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を圧倒することで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を圧倒しようとする方法の1つは、最小の長さのRDMAP/DDPメッセージを送信して、できるだけ多くの完了（リモートピアの完了を受信し、ローカルピアの完了を送信）を可能な限り引き起こすことです。それがリモートピアの攻撃であり、地元のピアの受信キューが受信バッファーがなくなっていないと仮定します（そうする場合、これは別の攻撃です。）、リモートピアが完了キューエントリの公正なシェア以上の消費を可能にする可能性があります。CQの実装に応じて、これにより、CQがオーバーフローする可能性があります（生成されたすべての完了を処理するのに十分な大きさの場合）、またはCQエントリを生成できない別のストリーム（RNICが生成時にフロー制御がある場合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のサイズ変更を行う前に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がキューのサイズと同じくらい多くのリソースをさまざまなキューに掲載するかどうかに依存します。ローカルULPが特定のリソースのキューのサイズよりも小さい多数のリソースを投稿することを信頼できる場合、正しくサイズの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.
maxpostedoneachrq =特定の受信キューに掲載される完了を引き起こす可能性のあるリクエストの最大数。
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.
sizefeachrq =特定の受信キューに掲載できる完了を引き起こす可能性のあるリクエストの最大数。
SizeOfEachSRQ = the maximum number of requests that can cause a completion that can ever be posted on a specific Shared Receive Queue.
sizefeachsrq =特定の共有受信キューに投稿できる完了を引き起こす可能性のあるリクエストの最大数。
SizeOfEachSQ = the maximum number of requests that can cause a completion that can ever be posted on a specific Send Queue.
sizefeachsq =特定の送信キューに掲載できる完了を引き起こす可能性のあるリクエストの最大数。
MaxPosted*OnEach*Q and SizeOfEach*Q vary on a per Stream or per Shared Receive Queue basis.
maxposted*oneach*qおよびsizefeach*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にアクセスするリモートピアが信頼されていない場合でも、CQSを共有できることに注意してください。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で説明されているものと同様に、複数のストリーム共有を受信したバッファーを作成することです。より簡単なアプローチは、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.
問題がリモートピアの実装のバグであるが、悪意のある攻撃ではない場合、リモートピアのRNICがRDMA読み取りリクエストをスロットルすることを要求することで問題を解決できます。信頼できるエージェントを介してリモートピアでストリームを適切に構成することにより、RNICを作成して、ローカルピアのRDMA読み取り要求キューの深さを超えるRDMA読み取りリクエストを送信しないようにすることができます。ストリームが正しく構成されており、リモートピアがローカルピアのRDMA読み取り要求キューが処理できるよりも多くのリクエストを送信する場合、以前のリクエストが完了するまでリモートピアのRNICでリクエストがキューに登録されます。リモートピアのストリームが正しく構成されていない場合、RDMAPストリームは、ローカルピアが処理できるよりも多くのRDMA読み取り要求がローカルピアに到着すると終了します（以前の段落の推奨が実装されていると仮定します）。したがって、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を有効にした場合、リモートピアは、RDMAP送信を無効化するか、SEで送信し、メッセージを無効にして送信して、RDMAP送信を使用して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を早期にリモートで無効にしようとする場合があります）
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.
このセクションでは、図1 -RDMAセキュリティモデルとセクション2.2で定義されているRNICエンジンリソースで定義されている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.
共有完了キューに対するDOS攻撃（CQ-セクション2.2.6、完了キューを参照）は、エントリの数の公正なシェアよりも多くの完了を引き起こそうとする場合、ローカル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を使用しようとする他のすべてのローカルULPSを失速させる可能性があります。
For these reasons, an RNIC MUST NOT enable sharing a CQ across ULPs that do not share Partial Mutual Trust.
これらの理由により、RNICは、部分的な相互信頼を共有していないULPS間の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の読み取り要求キューリソースが複数のストリームにわたってプールされている場合、1つの攻撃は、ローカルULPがRDMAの読み取り要求リクエストリソースをそのストリームに不当に割り当てようとする場合です。たとえば、ローカルULPは、特定のRDMA読み取りリクエストキューで利用可能なすべてのリソースをそのストリームに割り当てようとするため、RDMA読み取りリクエストキューを共有するULPSのリソースを拒否します。RDMAの読み取り要求が共有されていない場合でも、同じタイプの引数が適用されますが、キューが作成されたときにすべてのRNICのリソースを割り当てようとするローカルULPの試みが適用されます。
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がRNICページの翻訳テーブル（STAGからホストアドレスに変換される）を直接操作できる場合、非具体的な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が特定のデータバッファーにアクセスする権利があることを確認する必要があります。。これは、ページ翻訳テーブルが初期化されてデータバッファーにアクセスする場合、または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、RDDPクライアント/サーバープロトコルのULPの問題は、従来のクライアント/サーバースタイルのインタラクションスタイルを実装するアプリケーションの実装の問題と要件の要約を提供します。セクション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] Shah、H.、Pinkerton、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.、Garcia、D。、およびJ. Hilland、「リモートダイレクトメモリアクセスプロトコル仕様」、RFC 5040、2007年10月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、RFC 3723、2004年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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>.
[Verbs-RDMAC]「RDMAプロトコル動詞仕様」、RDMAコンソーシアムスタンダード、2003年4月、<http://www.rdmaconsortium.org/ home/draft-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>.
[Verbs-rdmac-overview] "RDMA Enabled Nic（RNIC）動詞概要"、Slide Presentation by Renato Recio、2003年4月<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] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[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 Architecture Specification Volume 1"、Release 1.2、Infiniband Trade Association Standard、<http://www.infinibandta.org/specs>。動詞は第11章に文書化されています。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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.、Meth、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、「Internet Small Computer Systems Interface（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] Ko、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、Shah、H。、およびP. Thaler、 "Internet Small Computer System Interface（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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、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.、Ed。、Eisler、M.、ed。、およびD. Noveck、ed。、 "NFSV4 Minor Version 1"、Work in Progress、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.
攻撃と対策に関する前のセクションの詳細はすべて、サーバーに適用されます。したがって、このセクションで繰り返される要件は、非規範的な「必須」、「必須」、および「5月」を使用します。場合によっては、このドキュメントの本体からのULPのstatementは、操作条件を改良してAの動機を適用できないため、ULPサーバーの必要なステートメントが作成されます。このセクションで事前に必須に変更された場合、それは明示的に記録され、大文字の規範的なステートメントを使用します。
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 Read、RDMA Write）を採用する場合があることに注意してください。したがって、必要に応じて、各要件の完全な一般性を保持するために、「サーバー」または「クライアント」の代わりに「ローカルULP」、「ローカルピア」、および「リモートピア」が使用されます。
* Spoofing
* スプーフィング
* Sections 5.1.1 to 5.1.3. For protection against many forms of spoofing attacks, enable IPsec.
* セクション5.1.1〜5.1.3。多くの形態のスプーフィング攻撃に対する保護のために、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を使用しています。あるクライアントが他のクライアントのSTAGを使用して別のクライアントのデータにアクセスできないようにするには、サーバーULPは、クライアントごとにSTAGを単一のストリームにスコープするか、一意の保護ドメインを使用する必要があります。単一のクライアントが部分的な相互信頼を共有する複数のストリームを持っている場合、関連するストリーム間で単一の保護ドメインを使用して、関連するストリーム間でSTAGを共有できます（追加の問題については、セキュリティを提供するセキュリティ5.4.4、ULPSを参照）。関連するストリーム内のスタッグの意図しない共有を防ぐために、サーバーのULPは、次の割り当てられたスタッグ番号を予測することが困難であるような方法でSTAGを使用する必要があります。
* 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を無効にしなかった場合、ローカル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は、リモートの読み取りアクセス権がリモートピアに付与される前に、バッファーに古いデータが含まれていないことを保証します（これはセクション6.3.2のものよりも強力です）（これは、これはの内容をゼロにすることで実行できますたとえば、メモリ）。
* 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で意図しないデータにアクセスします。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.
* 6.3.5、RDMAは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、同じバッファーにエイリアスを使用している複数のSTAGを使用します。セクション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メモリフットプリントサイズは、一部のサーバーULPSにとって重要です。サーバーULPが複数のクライアントからの大幅なネットワークトラフィックを期待している場合、多数のストリームがあるストリームごとの受信バッファキューを使用して、かなりの量のメモリを消費できます。したがって、複数のストリームで共有できる受信キューは魅力的です。
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.
ただし、このセクションで概説されている攻撃のため、各ULPで定義されているように、1つのクライアントがその制限を超えたバッファーを1つの受信バッファーを消費できないことを確認するために、複数のクライアント間で単一の受信キューを共有する必要があります。単一のクライアントULP内の複数のストリーム（おそらく部分的な相互信頼を共有する）の場合、この追加オーバーヘッドは回避できます。
* 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:
* 7.1共有CQを攻撃するローカル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.
1) 完了キューのサイジングは、6.4.3.2で文書化されているように、レシーブキューと送信キューのサイズに基づいており、リモートまたはローカルピアが共有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つの緩和があります。1つは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.
一部のサーバー環境では、サーバーULPの部分的な信頼（クライアントではありません）は受け入れられます。したがって、小さいCQはリモート攻撃者を完全に軽減します。他の環境では、ローカルサーバーのULPには、ローカルマシンを攻撃できる（またはバグがある）ことができる信頼されていない要素も含めることができます。これらの環境では、CQの最悪のサイズを使用する必要があります。
* 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
* 5.4.5 DDPのIPSECカプセル化の要件
* 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
* 6.4.6非共有CQを攻撃するリモートピア
* 6.5 Elevation of Privilege 39
* 6.5特権の標高39
* 7.1 Local ULP Attacking a Shared CQ
* 7.1共有CQを攻撃するローカルULP
* 7.3 Local ULP Attacking the PTT and STag Mapping
* 7.3 PTTおよびSTAGマッピングを攻撃するローカル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
* 6.3.4有効なSTAGで意図しないデータへのアクセス
* 6.3.5 RDMA Read into an RDMA Write Buffer
* 6.3.5 RDMA RDMA書き込みバッファーに読み込みます
* 6.3.6 Using Multiple STags That Alias to the Same Buffer
* 6.3.6同じバッファーにエイリアスを使用する複数のSTAGを使用する
* 6.4.5 Remote Invalidate an STag Shared on Multiple Streams
* 6.4.5リモート複数のストリームで共有された雄鹿を無効にします
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のリソースで定義されています。ストリーム間でリソースを共有しないという利点は、可能な攻撃の種類を減らすことです。不利な点は、ULPSがリソースを使い果たす可能性があることです。
* 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.
* ローカル部分トラスト（はい/いいえ） - ローカル部分の部分的信頼は、RDMAP/DDPストリームのローカルグループ（通常、1つのULPまたはULPのグループに相当）のローカルグループが特定の攻撃を実行しないことを相互に信頼するかどうかに基づいて決定されます。
* 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/DDPストリームのローカルULPがストリームのリモートピアを部分的に信頼するかどうかに基づいて決定されます（セクション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:
信頼特性のすべての組み合わせがULPSによって使用されると予想されるわけではありません。このドキュメントは、一般的に使用されると予想される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ストリームごとに何らかの形のキーベースの認証が使用されない限り、中間の攻撃が発生することはできない場合があることに注意してください。
* 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は有利です。通常、モデルS-Tは、大きな並列ULPを横切ってリソーススケーリングすると、他のモデルを使用することが不可能である場合に使用されます。リソースのスケーリングの問題は、スケーリングに関するパフォーマンスによるものであるか、単に十分なリソースがないためです。モデルNS-RTは、おそらく使用される可能性が最も低いモデルですが、完全性のために提示されます。
Acknowledgments
謝辞
Sara Bitan Microsoft Corporation EMail: sarab@microsoft.com
Sara Bitan Microsoft Corporation Email：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
Allyn Romanow Cisco Systems 170 W Tasman Drive San Jose、CA 95134 USA電話：1（408）525-8836メール：allyn@cisco.com
Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 USA EMail: 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
キャサリン・メドウズ海軍研究研究所コード55543ワシントン、DC 20375米国電子メール：meadows@itd.nrl.navy.mil patricia thaler agilent Technologies、Inc。（916）788-5662メール：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
James Livingston NEC Solutions（America）、Inc。7525 166th Ave. N.E.、Suite D210 Redmond、WA 98052-7811 USA電話：1（425）897-2033メール：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
John Carrier Cray Inc. 411 First Avenue S、Suite 600 Seattle、WA 98104-2860電話：206-701-2090メール：carrier@cray.com
Caitlin Bestler Broadcom 49 Discovery Irvine, CA 92618 EMail: cait@asomi.com
Caitlin Bestler Broadcom 49 Discovery Irvine、CA 92618メール：cait@asomi.com
Bernard Aboba Microsoft Corporation One Microsoft Way USA Redmond, WA 98052 Phone: +1 (425) 706-6606 EMail: bernarda@windows.microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way USA Redmond、WA 98052電話：1（425）706-6606メール：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
James Pinkerton Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA電話：1（425）705-5442メール：jpink@windows.microsoft.com
Ellen Deleganes Self P.O. Box 9245 Brooks, OR 97305 Phone: (503) 642-3950 EMail: deleganes@yahoo.com
Ellen Deleganes Self P.O.ボックス9245ブルックス、または97305電話：（503）642-3950メール：deleganes@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。