RFC5042 日本語訳
5042 Direct Data Placement Protocol (DDP) / Remote Direct MemoryAccess Protocol (RDMAP) Security. J. Pinkerton, E. Deleganes. October 2007. (Format: TXT=127453 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Pinkerton
Request for Comments: 5042 Microsoft Corporation
Category: Standards Track E. Deleganes
Self
October 2007
コメントを求めるワーキンググループJ.ピンカートン要求をネットワークでつないでください: 5042年のマイクロソフト社カテゴリ: 標準化過程E.Deleganes自己2007年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントはDirect Data Placementプロトコル(DDP)とRemote Direct Memory Accessプロトコル(RDMAP)の実装と使用の周りで安全保障問題を分析します。 それは最初に、RDMA Network Interface Card(RNIC)のために建築モデルを定義します。(RDMA Network Interface CardはDDPかRDMAPとDDPを実装することができます)。 ドキュメントは建築モデルで定義されたリソースとシステムを保護するのに使用できる対策に対して様々な攻撃を見直します。 攻撃はネットワーク、Remote Peersからの攻撃、およびLocal Peersからの攻撃の向こう側に安全な通信チャネルを使用することによって緩和できるものに分類されます。 攻撃カテゴリはパロディーの、そして、いじっている情報公開、サービス、および特権の高度否定を含んでいます。
Pinkerton & Deleganes Standards Track [Page 1] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[1ページ]。
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
1. 序論…4 2. 建築モデル…6 2.1. コンポーネント…7 2.2. リソース…9 2.2.1. 文脈メモリを流してください…9 2.2.2. データバッファ…10 2.2.3. ページ変換テーブル…10 2.2.4. 保護ドメイン(PD)…11 2.2.5. 雄ジカ名前空間と範囲…11 2.2.6. 完成は列を作ります…12 2.2.7. 非同期なイベント待ち行列…12 2.2.8. RDMAは要求待ち行列を読みます…13 2.3. RNIC相互作用…13 2.3.1. 特権があるコントロールインタフェース意味論…13 2.3.2. 非特権があるデータは意味論を連結します…13 2.3.3. 特権があるデータは意味論を連結します…14 2.3.4. データ転送のためのRNICデータ構造の初期設定…14 2.3.5. RNICデータ転送相互作用…16 3. 信頼とリソース共有…17 4. 攻撃者能力…18 5. 終わりから終わりへのセキュリティで緩和できる攻撃…18 5.1. だまします…19 5.1.1. ものまね…19 5.1.2. ハイジャックを流してください…20 5.1.3. 中央の男性攻撃…20 5.2. 改ざん--バッファの内容のネットワークベースの変更。21 5.3. 情報公開--ネットワークベースの盗聴…21 5.4. セキュリティー・サービスのための決められた一定の要求…21 5.4.1. セキュリティオプションへの序論…21 5.4.2. TLSはDDP/RDMAPセキュリティのために不適当です…22 5.4.3. DTLSとRDDP…23 5.4.4. セキュリティを提供するULPs…23 5.4.5. DDPのIPsecカプセル化のための要件…23 6. リモート同輩からの攻撃…24 6.1. だまします…25 6.1.1. 異なったストリームで雄ジカを使用します…25 6.2. 改ざん…26 6.2.1. バッファ超過--RDMAは応答を書くか、または読みます…26 6.2.2. 指示の後にバッファを変更します…27 6.2.3. 同じバッファにアクセスする複数の雄ジカ…27 6.3. 情報公開…28 6.3.1. バッファの外でメモリを調べるのはバウンドしています…28 6.3.2. RDMAを使用するのはアクセスの聞き古したデータに読んで聞かせました…28 6.3.3. 転送の後にバッファにアクセスします…28 6.3.4. 有効な雄ジカと共に故意でないデータにアクセスします…29
Pinkerton & Deleganes Standards Track [Page 2] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[2ページ]。
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
6.3.5. RDMAから読み取られたRDMAはバッファを書きます…29 6.3.6. そんなに通称同じバッファに複数の雄ジカを使用します…29 6.4. サービス妨害(DOS)…30 6.4.1. RNICリソース消費…30 6.4.2. 使用されていないULPsによるリソース消費…31 6.4.3. アクティブなULPsによるリソース消費…32 6.4.3.1. 倍数は、受信バッファを共有しながら、流れます。32 6.4.3.2. 共有されたCQを攻撃しているリモートであるか地元の同輩…34 6.4.3.3. RDMA読み出し要求を攻撃して、列を作ってください…36 6.4.4. 非最適のコード経路の運動…37 6.4.5. リモートである、複数のストリームで共有された雄ジカを無効にしてください…37 6.4.6. Unshared CQを攻撃しているリモート同輩…38 6.5. 特権の高度…38 7. 地元の同輩からの攻撃…38 7.1. 共有されたCQを攻撃する地方のULP…39 7.2. RDMAを攻撃している地元の同輩が要求待ち行列を読みました…39 7.3. PTTと雄ジカマッピングを攻撃する地方のULP…39 8. セキュリティ問題…40 9. IANA問題…40 10. 参照…40 10.1. 標準の参照…40 10.2. 有益な参照…41 付録A.ULPはRDDPクライアント/サーバのためにプロトコルを発行します…RNICとULP実装要件の43付録B.概要…46 付録のC.の部分的な信頼分類学…47の承認…49
Pinkerton & Deleganes Standards Track [Page 3] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[3ページ]。
1. Introduction
1. 序論
RDMA enables new levels of flexibility when communicating between two parties compared to current conventional networking practice (e.g., a stream-based model or datagram model). This flexibility brings new security issues that must be carefully understood when designing Upper Layer Protocols (ULPs) utilizing RDMA and when implementing RDMA-aware NICs (RNICs). Note that for the purposes of this security analysis, an RNIC may implement RDMAP [RDMAP] and DDP [DDP], or just DDP. Also, a ULP may be an application or it may be a middleware library.
現在の従来のネットワーク練習(例えば、ストリームベースのモデルかデータグラムモデル)と比べて、2回のパーティーの間で交信するとき、RDMAは新しいレベルの柔軟性を可能にします。 この柔軟性はRDMA意識しているNICs(RNICs)を実装しながらRDMAといつを利用するかでUpper Layerプロトコル(ULPs)を設計するとき慎重に理解しなければならない新しい安全保障問題をもたらします。 この証券分析の目的のために、RNICが、RDMAPが[RDMAP]とDDP[DDP]か、ただDDPであると実装するかもしれないことに注意してください。 また、ULPはアプリケーションであるかもしれませんかそれがミドルウェアライブラリであるかもしれません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Additionally, the security terminology defined in [RFC4949] is used in this specification.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。 さらに、[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は攻撃されるかもしれないコンポーネント、リソース、および系特性について詳述します。 ドキュメントは、Stream([RFC793]か[RFC4960]などのトランスポート・プロトコルで、実装される)の地方の端にRDMA/DDPプロトコル実装を表すのにLocal Peerを使用します。 ローカルのUpper層のプロトコル(ULP)は、Local Peerの上のアプリケーションかミドルウェア層を表すのに使用されます。 ドキュメントは、いくつかの理由で、Remote PeerとRemote ULP(Stream対リモートエンドにおけるアプリケーションのリモートエンドに関するRDMA/DDPプロトコル実装)を区別するのを試みません: しばしば、攻撃の源は確かに知るのが難しいです、そして、ソースにかかわらず緩和がLocal Peerについて必要である、または地方のULPは同じです。 したがって、ドキュメントはさらに攻撃者を図で表わそうとするより一般的にむしろRemote Peerについて言及します。
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がStreamsの向こう側にどんなリソースを共有するかもしれないか、そして、地方のULPがセクション3でStreamsの向こう側にどんなリソースをRemote Peerと共有するかもしれないかを定義します。
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.
複数のStreamsの間の意図的なリソースの共有はStreamsの間の何らかのレベルの信頼を含意するかもしれません。しかしながら、リソース・シェアリングの何人かのタイプには、和らげられないセキュリティー攻撃があります。(セキュリティー攻撃はそこでないなら特定のタイプのリソースを共有しないのが、リソースを共有するStreamsの間の何らかのレベルの信頼であることを強制するでしょう)。
Pinkerton & Deleganes Standards Track [Page 4] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[4ページ]。
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.
部分的なMutual Trust--RDMAP/DDP Streamsの収集。(Streamsは収集からのStreamsが収集で他のStreamsのどれかに対して悪意ある攻撃を実行しないと仮定しても構わないと思っているStreamの地方の、そして、リモートなエンドポイントを表します)。
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はAppendix Cで終点のどの収集がツールを通したPartial Mutual Trust収集にあるかに関する明白なコントロールについて議論させます、Partial Trust Taxonomy。
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が、それが同輩による計画的犯行に直面してさえ強健で非感染するようになるのを保証したがっているとき、信頼されていない同輩関係は適切です。 例えば、おそらく、同時に複数の関係ないStreamsが(例えば、サーバ)であるとサポートする独身のULPは信頼されていない同輩として同輩各人を扱うでしょう。 Partial Mutual Trustを共有するStreamsの収集のために、仮定は収集でないのにおけるどんなStreamも信頼されていないということです。 信頼されていない同輩に関しては、能力の簡潔なリストはセクション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.
ドキュメントの残りは攻撃を分析して、特定の緩和を攻撃に推薦するのに焦点を合わせられます。 攻撃は終わりから終わりへのセキュリティによって緩和された攻撃、Remote Peersによって開始された攻撃、およびLocal Peersによって開始された攻撃に分類されます。 各攻撃において、可能な対策は見直されます。
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:
ホストの中のULPsは2つのカテゴリに分割されます--特権があってNon特権があります。 両方の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.
Privileged ULPが陰湿に操作環境を攻撃しないとローカルシステムによって信じられますが、資源配分をグローバルに最適化するのは信じられません。 例えば、Privileged 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.
Non特権があるULPの能力はPrivileged ULPの論理的な部分集合です。 Nonの特権があるULPが信頼されていないとローカルシステムによって思われます。 他のULPsに影響できたRNIC EngineとのすべてのNon特権があるULP相互作用が、Non特権があるULP要求について確かめることができる信じられた仲介者を通してする必要があります。
Pinkerton & Deleganes Standards Track [Page 5] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[5ページ]。
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 Client/サーバプロトコルのためのULP Issues)は伝統的なクライアント/サーバプロトコルのimplementersに焦点を合わせます。 付録B(RNICとULP Implementation RequirementsのSummary)はこの仕様によるすべての標準の要件をまとめます。 付録C(Partial Trust Taxonomy)は信頼境界を分類するのに抽象モデルを提供します。
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プロトコル実装がこのドキュメントのお勧めの緩和を使用するなら、その実装はそれ(例えば、IP)の下にトランスポート・プロトコル(すなわち、TCPかSCTP)とプロトコルの実装のものを超えてRDMAP/DDPなしで追加担保脆弱性を示すべきではありません。
2. Architectural Model
2. 建築モデル
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 Interfaceの上に座る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.
ここの意図は高い平らなコンポーネントと特定の実装オプションのときに焦点ではなく、脅威分析に影響する能力について説明することです。 また、建築モデルが抽象化であり、実際の実装が、ここで定義されたものと異なった境界に沿ってコンポーネントを細分するのを選ぶかもしれないことに注意してください。 例えば、Privileged ResourceマネージャはPrivileged 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実装から得られることに注意してください。 いくつか、注意において、[VERBS-RDMAC]、[VERBS-RDMAC概要]、および[INFINIBAND]はそうです。
Pinkerton & Deleganes Standards Track [Page 6] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[6ページ]。
+-------------+
| 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
=================================================================
+-------------+ | 特権がある| | リソース| アドミン<+>| マネージャ| ULPコントロールインタフェース| | | <、-、-、-、-、--+-------------------+ | +-------------+ | | | ^vに対して| | +-------------+ +-----------------+ +---------------->| 特権がある| | 非特権があります。| | | ULP| | ULP| | +-------------+ +-----------------+ | ^ ^ |特権がある|特権がある|非特権があります。|コントロール|データ|データ|インタフェース|インタフェース|インタフェースRNIC| | | インタフェースv対v=================================================================
+--------------------------------------+
| |
| RNIC Engine |
| |
+--------------------------------------+
^
|
v
Internet
+--------------------------------------+ | | | RNICエンジン| | | +--------------------------------------+ ^ | インターネットに対して
Figure 1 - RDMA Security Model
図1--RDMA機密保護モデル
2.1. Components
2.1. コンポーネント
The components shown in Figure 1 - RDMA Security Model are:
図1に示されたコンポーネント--RDMA Security Modelは以下の通りです。
* RDMA Network Interface Controller Engine (RNIC) - The component
that implements the RDMA protocol and/or DDP protocol.
* RDMA Network Interface Controller Engine(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.
* 特権があるResourceマネージャ--RNIC Engineに関連しているリソースを管理して、割り当てるのに原因となるコンポーネント。 Resourceマネージャは、データを送りもしませんし、受け取りもしません。 Resourceマネージャが独立しているコンポーネント、RNICの一部であるかULPの部分が実装に依存していることにかかわらずそれに注意してください。
Pinkerton & Deleganes Standards Track [Page 7] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[7ページ]。
* 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--Privileged ULPの定義に関してセクション1、Introductionを見てください。 ローカル・ホストインフラストラクチャは、Privileged ULPがRNIC Interfaceを通して直接RNIC EngineからホストまでData Bufferを写像するのを可能にすることができますが、それで、Privileged ULPは直接RNIC Engineリソースを消費できません。
* Non-Privileged ULP - See Section 1, Introduction, for a
definition of Non-Privileged ULP.
* 非特権があるULP--Non特権があるULPの定義に関してセクション1、Introductionを見てください。
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プロトコルのデザイン目標はホストが安全なままでいるのを確実にしている間、強制的な条件のもとでNon特権があるULPがPrivileged Resourceマネージャ介入なしで直接RDMA Engineからの/にデータを送って、受け取るのを許容することです。 したがって、このドキュメントのプライマリ目標の1つはシステムが安全なままで残っているのを保証するのにRNIC Engineで必要である実施のためにこの用法モデルを分析することです。
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
* そしてUntagged Data Transfer--入って来るペイロードが単に受信Peer(一般的にReceive Queueと呼ばれる)によって指定されたオーダーにあるバッファの待ち行列における最初のバッファを消費する。
* 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.
* タグ付けをされたData Transfer--明らかにペイロードを伝えるPeerは、どの目的地バッファが狙うかを述べます、STagの使用で。 STagベースの転送は、受信ULPが何が、反対のPeerにデータを送るよう命令するか、そして、(またはどんなメッセージで)またはパケットがどんなオーダーで受け取られているかにありきたりであることを許容します。
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を通して追加コントロール意味論で可能にされます。 通常、ペイロード転送にTagged Data Transferを使用できますが、コントロールメッセージにUntagged Data Transferを使用するのは最も良いです。 しかしながら、それぞれのUpper LayerプロトコルはTaggedとUntaggedメッセージのそれ自体の最適の使用を決定できます。 アプリケーションの適用性の詳しい情報に関して2台のトランスファ・メカニズムに関して[APPLICABILITY]を見てください。
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つのフォームがそれぞれUntaggedとTagged DDP Messagesに一致しています。 RDMAPに関しては、2つのフォームがそれぞれSend Type MessagesとRDMA Messages(RDMA ReadかRDMA Write Messagesのどちらか)に一致しています。
Pinkerton & Deleganes Standards Track [Page 8] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[8ページ]。
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).
* 特権があるControl Interface--Privileged Resourceマネージャは、RNIC Engineリソースを割り当てて、管理して、RNIC Engineの中で状態を制御して、RNIC Engineから様々なイベントをモニターするのにRNIC Interfaceを使用します。 また、それは、Non特権がある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 Control Interface--ULPは、リソースをRNIC Engineに割り当てるのにPrivileged Resourceマネージャにこのインタフェースを使用します。 Privileged Resourceマネージャは、Non特権があるULPが攻撃を開始するなら攻撃が他のULPsに影響するのを防ぐことができるのを保証するために対策を実装します。
* Non-Privileged Data Transfer Interface - A Non-Privileged ULP
uses this interface to initiate and check the status of data
transfer operations.
* 非特権があるData Transfer Interface--Non特権がある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.
* 特権があるData Transfer Interface--Non特権があるData Transfer Interfaceによって提供された機能性のスーパーセット。 ULPは直接STagをULP Data Bufferに写像するためにリソースを写像するRNIC Engineを操作できます。
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 Engine、脅威分析で処理されますが、このドキュメントの範囲の外で処理されるなら。
2.2. Resources
2.2. リソース
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 Engineの天然資源について説明します。 RDMAPに関しては、すべての定義されたリソースが適用されます。 DDPのために、RDMA Read Queue以外のすべてのリソースが申し込まれます。
2.2.1. Stream Context Memory
2.2.1. ストリーム文脈メモリ
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.
各Streamのための州の情報はNICの上の多くの場所に位置できたメモリで保守されます、NIC、ホストメモリ、または3つのもののどんな組み合わせでも取り付けられたRAMの中で、実装によって。
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).
ストリームContext MemoryはData Buffersに関連している状態を含んでいます。 Tagged Buffersに関しては、これはSTag名、Data Buffers、およびページTranslation Tables(セクション2.2.3を見る)がどう相互に関係づけるかを含んでいます。 また、それはUntagged Messages(一般的にReceive Queueと呼ばれる)のレセプションのために掲示された、Untagged Data Buffersのリスト、およびデータ(一般的にSend Queueと呼ばれる)を送るために実行する操作のリストを含んでいます。
Pinkerton & Deleganes Standards Track [Page 9] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[9ページ]。
2.2.2. Data Buffers
2.2.2. データバッファ
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のData Buffersを暴露する2つの異なった方法があります: そこでは、DDP Queueゼロの上のRDMAP Send Type Messages(通称DDP Untagged Messages)を受けるためにバッファを暴露することができます。Untagged Data Transfer、またはTagged Data Transfer。そこでは、遠隔アクセスのためにSTags(通称DDP Tagged Messages)を通してバッファを暴露することができます。 ネットワークにバッファを暴露するためにメソッドによって、攻撃から守るのに使用される攻撃と対策が異なっているので、この区別は重要です。
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.
セキュリティ議論の目的、Tagged Data Transferに関しては、独身の論理的なData Bufferは与えられたStreamの上の独身のSTagと共に暴露されます。 実際の実装は複数の物理的なデータバッファが独身のSTagと共にアクセスされるのを可能にする能力を/が集める散布にサポートするかもしれませんが、脅威分析見解から、独身のSTagが独身の論理的なData Bufferへのアクセスを可能にすると思われます。
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.
とにかく、消費者が持っていた記憶力に暴露しない権威を全く暴露するのは、Privileged ResourceマネージャがSTagを全く作成できないのを保証する責任です。
A Data Buffer has specific access rights. The local ULP can control whether a Data Buffer is exposed for local only, or local and remote access, and assign specific access privileges (read, write, read and write) on a per Stream basis.
Data Bufferには、特定のアクセス権があります。 地方のULPはData Bufferが地方の唯一の、または、地方の、そして、リモートなアクセスのために暴露されるかどうかを制御して、特定のアクセス権(読んでください、そして、書いてください、そして、読んでください、そして、書く)をStream基礎あたりのaに割り当てることができます。
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によるAdvertised、おそらく、Remote Peerを与えるということであるときには、データにアクセス権を書いてください(さもなければ、Advertisementへのポイントがあまりないでしょう)。 RDMAP、いつa ULP Advertises、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.
同様に、いくつかのULPsがStream基礎あたりのaで異なったアクセス権をただ一つのバッファに提供したがっているかもしれません。 例えば、いくつかのStreamsには、リード・オンリー・アクセスがあるかもしれません、と或るものは読まれて、リモートに持って、アクセスを書くかもしれません、アクセサリーは他のStreamsに地方のULP/地方のPeerだけに許容されていますが
2.2.3. Page Translation Tables
2.2.3. ページ変換テーブル
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
ページTranslation Tablesはデータ転送操作のためのULPメモリにアクセスできるようにRNICによって使用された構造です。 これらの構造は「ページ」Translation Tablesと呼ばれますが、彼らは全く1ページに参照をつけないかもしれません--概念的に、彼らは、よりもみ皮製でaのULPアドレス空間表現(例えば、仮想アドレス)を写像するのに使用されます。
Pinkerton & Deleganes Standards Track [Page 10] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[10ページ]。
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.
データを動かすのにRNIC Engineによって使用される物理アドレス。 マッピングが特定のシステムの上で使用されていないなら、調べられた攻撃の部分集合は適切であるかもしれません。 ページTranslation Tableが共用資源であるかもしれないことに注意してください。
2.2.4. Protection Domain (PD)
2.2.4. 保護ドメイン(PD)
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.
Protection Domain(PD)はRDMA実装への地方の構造物です。ワイヤの上に決して目に見えません。 保護Domainsは関心に関する3つのリソースに割り当てられます--ストリームContext Memory(ページTranslation Tableエントリー、およびData Buffersに関連しているSTags)。 Protection Domainの正しい実装は、別のProtection Domainに属しながらリソースで与えられたProtection Domainに属すリソースを使用できないのを必要とします、そのようなリソースにかかわるどんな行動も取る前にProtection Domain会員資格がRNICによってチェックされるので。 したがって、特定のSTagと同じProtection Domainに関連している1Streamsの上の関連Data BufferにアクセスするのにSTagを使用できるだけであるのを保証するのにおいて保護Domainsは使用されています。
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.
実装が、Streamsの間のリソースを共有しないのを選ぶなら、それぞれのStreamがそれ自身のものに関連しているのは、お勧めです、ユニークなProtection Domain。 実装が、リソース・シェアリングを許容するのを選ぶなら、Protection Domainが互いと共にPartial Mutual Trustを持っているStreamsの収集に制限されるのは、お勧めです。
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(Privilegedの、または、Non特権がある)が潜在的に複数のProtection Domainsを持つことができることに注意してください。 例えば、サーバの複数のクライアントには互いを買収する能力がないのを保証するのにこれを使用できました。 サーバは、別の(信頼されていない)のクライアントがProtection Domainでカバーされたリソースを使用できなかったのを保証するために1クライアントあたり1Protection Domainを割り当てるでしょう。
2.2.5. STag Namespace and Scope
2.2.5. 雄ジカ名前空間と範囲
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ビットの名前空間を定義します。 実装はサポートされるSTagsの実数に関して異なるかもしれません。 どのような場合でも、これは攻撃を受けることができる境界があるリソースです。 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 Streamsのセットです。 STagが特定のDDP/RDMAP Streamで有効であるなら、そのストリームはストリームがSTagのために持っているアクセス権を条件としてバッファを変更できます(セクション2.2.2を見てください、Data Buffers、追加情報のために)。
Pinkerton & Deleganes Standards Track [Page 11] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[11ページ]。
The analysis presented in this document assumes two mechanisms for limiting the scope of Streams for which the STag is valid:
本書では提示された分析はSTagが有効であるStreamsの範囲を制限するために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.
* 保護Domain範囲。 STagは特定のProtection Domainの中のどんなStreamでも使用されるなら有効であり、Protection DomainのメンバーでないどんなStreamでも使用されるなら、無効です。
* 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.
* Stream範囲を選抜してください。 STagはStream協会が何であるかにかかわらず独身のStreamでProtection Domainに有効です。 いかなる他のStreamでも使用されるなら、無効です。
2.2.6. Completion Queues
2.2.6. 完成待ち行列
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.
完成Queues(CQ)は、概念的に、RNIC Engineがデータの伝達の完成、またはData Transfer Interfaceを通したデータのレセプションの完成に関してどうULPに通知するかを(特にUntagged Data Transferのために; タグ付けをされたData Transferは完成を起こらせることができません)表すのに本書では使用されます。 いかなる時も、飛行における多くのトランスミッションかレセプションがあるかもしれないので、落成はただ一つのイベントとしてというよりむしろ待ち行列としてモデル化されます。 また、実装は他の活動についてULPに通知するのにCompletion Queueを使用するかもしれません。 例えば、特定のULPバッファへのSTagに関するマッピングの完成。 完成Queuesは、Streamsのグループによって共有されるか、または特定のStreamのトラフィックを扱うために指定されるかもしれません。 RDMAP/DDP StreamsのCompletion Queue協会を1つに制限するか、または少ない数が、鋭く攻撃の効果の範囲を制限することによって、いくつかの形式の攻撃を防ぐことができます。
Some implementations may allow this queue to be manipulated directly by both Non-Privileged and Privileged ULPs.
いくつかの実装がこの直接両方によってNon特権があった状態で操られるべき待ち行列とPrivileged ULPsを許容するかもしれません。
2.2.7. Asynchronous Event Queue
2.2.7. 非同期的なイベント待ち行列
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から境界があるサイズのPrivileged ResourceマネージャまでAsynchronous Event Queueは待ち行列です。 RNICによって使用されて、プロトコル違反を含むStreamが変化すると述べる管理活動を必要とするかもしれない様々なイベント、地方の操作誤り、干潮標についてホストに通知するために、待ち行列、およびことによると他のイベントが受信するということです。
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.
Asynchronous Event QueueはRemoteかLocal Peers、そして/または、ULPsが起こるオーバフローの可能性を持っているイベントに待ち行列を引き起こす場合があるので攻撃できるリソースです。
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
実装がさまざまな方法でAsynchronous Event Queueの機能を実装するのにおいて自由であることに注意してください、複数の待ち行列か簡単なコールバックさえ含んでいて。 すべての脆弱性
Pinkerton & Deleganes Standards Track [Page 12] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[12ページ]。
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.
特定、Asynchronous Event Queueの実装にかかわらず適用することを意図します。 例えば、コールバック機能は単に非常に短い待ち行列として見なされるかもしれません。
2.2.8. RDMA Read Request Queue
2.2.8. RDMA読み出し要求待ち行列
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 Read Request Queueは到着した1RDMA Read Request Messagesのための州の情報を保持しますが、RDMA Read Response Messagesがまだ完全に送られるというわけではなかったメモリです。 1RDMA Read Requestがひところ潜在的に傑出している場合があるので、メモリは境界があるサイズの待ち行列としてモデル化されます。 いくつかの実装が複数のStreamsの向こう側に独身のRDMA Read Request Queueの共有を可能にするかもしれません。
2.3. RNIC Interactions
2.3. RNIC相互作用
With RNIC resources and interfaces defined, it is now possible to examine the interactions supported by the generic RNIC functional interfaces through each of the 3 interfaces: Privileged Control Interface, Privileged Data Interface, and Non-Privileged Data Interface. As mentioned previously in Section 2.1, Components, there are two data transfer mechanisms to be examined, Untagged Data Transfer and Tagged Data Transfer.
RNICリソースとインタフェースが定義されている状態で、それぞれの3つのインタフェースを通してジェネリックのRNICの機能的なインタフェースによってサポートされた相互作用を調べるのは現在、可能です: 特権があるコントロールインタフェース、特権があるデータインタフェース、および非特権があるデータは連結します。 Untagged Data TransferとTagged Data Transfer、既述のとおりセクション2.1、Componentsに、調べられるために、2つのデータ転送メカニズムがあります。
2.3.1. Privileged Control Interface Semantics
2.3.1. 特権があるコントロールインタフェース意味論
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.
一般的に、Privileged Control InterfaceはRNICグローバル資源のRNICの配分、反-配分、および初期化を制御します。 これは配分とStream Context Memory、ページTranslation Tables、STag名、Completion Queues、RDMA Read Request Queues、およびAsynchronous Event Queuesの反-配分を含んでいます。
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).
また、Privileged Control Interfaceは、Non特権があるULP(そしてことによるとまた、Privileged ULPのために)のためのNon特権があるULPリソースを管理するのに通常使用されます。 これは、ページTranslation Tableリソースの初期化と取り外しと、RNICイベントを管理するのを含んでいます(Asynchronous Event Queueのためにことによるとすべてのイベントを管理して)。
2.3.2. Non-Privileged Data Interface Semantics
2.3.2. 非特権があるデータインタフェース意味論
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.
Non特権があるData Interfaceはデータ転送(送受信する)を可能にしますが、ページTranslation Tableリソースの初期化を許しません。 しかしながら、ページTranslation Tableリソースがいったん初期化されると、インタフェースは、特定のSTagマッピングが直接RNICとコミュニケートすることによって可能にされて、無効にされるのを可能にするか、または以前にRNICで初期化されたバッファのためのSTagマッピングを作成するかもしれません。
Pinkerton & Deleganes Standards Track [Page 13] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[13ページ]。
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に関しては、以前に説明されたデータ転送メカニズムの1つでULPデータを送ることができます: Untaggedデータ転送かタグ付けをされたデータ転送。 2つのRDMAPデータ転送メカニズムが定義されます、1つがUntagged Data Transfer(Type Messagesを送る)、およびTagged Data Transferを使用する1つ(RDMA Read ResponsesとRDMA Writes)を使用して。 Receive QueueかShared Receive Queueに掲示されたバッファの中にSend Type Messagesを受けることによって、RDMAPを通したULPデータ受信ができます。 したがって、Receive QueueかShared Receive QueueがUntagged Data Transferで影響を受けることができるだけです。 また、RDMA Writeを受けることによって、データ受信ができます、そして、以前に外部に暴露されたバッファの中へのRDMA Read Response MessagesはSTag(すなわち、Tagged Data Transfer)のAdvertisementを通したアクセスを書きます。 さらに、ULPデータがネットワークの向こう側に引かれることを(読みます)引き起こすのに、RDMAPはRDMA Read Request Message(読まれるためにULPバッファにアクセスするのに必要なRDMAP制御情報を含むだけである)を使用して、それがRDMA Read Response Messageに生成されることを引き起こすのが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 TaggedかUntagged Messagesを送ることを意味します。 データ受信に関しては、DDPはReceive QueueかShared Receive Queueに掲示されたバッファの中にUntagged Messagesを受けることができます。 また、それは以前に外部に暴露されたバッファの中へのDDP Messagesが通じてSTagのAdvertisementにアクセスすると書くTaggedを受けることができます。
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.
一般に、データ伝送かレセプションの完成は、完成工事についてCompletion Queueの完成情報を置くことによってULPに知らせるのを伴います。 データ受信に関しては、Untagged Data Transferだけが完成情報をCompletion Queueに入れさせることができます。
2.3.3. Privileged Data Interface Semantics
2.3.3. 特権があるデータインタフェース意味論
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.
Privileged Data Interface意味論はNonの特権があるData Transfer意味論のスーパーセットです。 インタフェースは、直接STagマッピングにバッファを先のセクションで定義されたすべてをして、作成するか、または破壊できます。 一般に、これはRNICのページTranslation Table状態の初期化か開拓地を伴います。
2.3.4. Initialization of RNIC Data Structures for Data Transfer
2.3.4. データ転送のためのRNICデータ構造の初期設定
Initialization of the mapping between an STag and a Data Buffer can be viewed in the abstract as two separate operations:
2が操作を切り離すとき、要約でSTagとData Bufferの間のマッピングの初期設定を見ることができます:
a. Initialization of the allocated Page Translation Table entries
with the location of the Data Buffer, and
a。 そしてData Bufferの位置がある割り当てられたページTranslation Tableエントリーの初期設定。
Pinkerton & Deleganes Standards Track [Page 14] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[14ページ]。
b. Initialization of a mapping from an allocated STag name to a set
of Page Translation Table entry(s) or partial entries.
b。 マッピングの1セットのページTranslation Tableエントリーか割り当てられた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.
実装にはページTranslation Tableがないかもしれないことに注意してください(すなわち、それはSTagとData Bufferの間のダイレクトマッピングをサポートするかもしれません)。 ページTranslation Tableが全くなければ、コンテンツを変えるか、またはあらゆる手段を尽くすことに基づいた攻撃は可能ではありません。
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.
Privileged ULPかNon特権があるULPのプロキシとしてのPrivileged ResourceマネージャがページTranslation Tableのコンテンツの初期設定ができます。 定義上、Non特権があるULPが直接ページTranslation Tableを操作すると信じられません。 一般に、関心はNonの特権があるULPがそれが許可を持っていないバッファにアクセスするために陰湿にページTranslation Tableを初期化しようとするかもしれないということです。
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.
このドキュメントの範囲の外にページTranslation Tableのための正確なリソース割り当てアルゴリズムがあります。 潜在的に複数のData Buffersによって消費されるか、またはある他の方法で管理されるために特定のData Buffer、またはプールされたリソースとしてそれを割り当てるかもしれません。 このドキュメントは抽象的な実装に依存する問題を試みます、そして、それらをStreamsの間のリソース飢餓やリソースの共有などの、より高い平らな安全保障問題に分類してください。
The next issue is how an STag name is associated with a Data Buffer. For the case of an Untagged Data Buffer (i.e., Untagged Data Transfer), there is no wire visible mapping between an STag and the Data Buffer. Note that there may, in fact, be an STag that represents the buffer, if an implementation chooses to internally represent Untagged Data Buffer using STags. However, because the STag, by definition, is not visible on the wire, this is a local host, implementation-specific issue that should be analyzed in the context of a local host implementation-specific security analysis, and thus, is outside the scope of this document.
次の問題はSTag名がどうData Bufferに関連しているかということです。 Untagged Data Buffer(すなわち、Untagged Data Transfer)に関するケースのために、STagとData Bufferの間で写像される目に見えるどんなワイヤもありません。 事実上、バッファを表すSTagがあるかもしれないことに注意してください、実装が、STagsを使用することで内部的にUntagged Data Bufferを表すのを選ぶなら。 しかしながら、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.
Tagged Data Buffer(すなわち、Tagged Data Transfer)に関しては、Non特権があるULPを代表して行動しているPrivileged ULPかPrivileged Resourceマネージャのどちらかが、STagからページTranslation Tableまでマッピングを初期化するか、または単に既存のSTagを有効にするか、または無効にする能力をページTranslation Tableマッピングに持っているかもしれません。 また、エントリー(または、サブエントリー)をページTranslation Tableの特定のグループに写像する複数のSTag名があるかもしれません。 このレベルの柔軟性の特定の安全保障問題はセクション6.2.3、Access Same BufferへのMultiple STagsで調べられます。
Pinkerton & Deleganes Standards Track [Page 15] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[15ページ]。
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).
ページTranslation Tableエントリーの初期化のためのさまざまな実装オプションとセキュリティ跳ね返りを持っているページTranslation TableエントリーのグループにSTagを写像するのがあります。 これは1セットのページTranslation Tableエントリーを写像することに対してSTagを写像して、直接ページTranslation Tableエントリーマッピング(Privileged Resourceマネージャを通したアクセスを必要とすることに対する)にSTagを操作するULPsのためにサポートを写像する分離のサポートを含んでいます。
2.3.5. RNIC Data Transfer Interactions
2.3.5. RNICデータ転送相互作用
RNIC Data Transfer operations can be subdivided into send and receive operations.
RNIC Data Transfer操作に細分できます。操作を送って、受けてください。
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がデータ(Send Queueと呼ばれる)を送るという同時併行処理要求を掲示するのを可能にする待ち行列が通常あります。 実装によって、操作に使用されるData Buffersはそれらに関連しているページTranslation Tableエントリーを持っていて、彼らに関連しているSTagsを持っているかもしれません。 これがプロトコル問題よりむしろローカル・ホストの特定の導入問題であるので、脅威と緩和の証券分析はホスト導入に残されます。
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.
受信してください。Tagged Data Buffers対Untagged Data Buffers(すなわち、Tagged Data Transfer対Untagged Data Transfer)において、操作は異なっています。 Untagged Data Transferに関しては、ULPが1Untagged Data Bufferを掲示できるなら、DDP仕様は、それらが連続したオーダーで消費されるのを必要とします(また、RDMAP仕様はこれを必要とします)。 その結果、最も一般的な実装が連続した待ち行列があるということである、Untagged Data Buffersを受けてください(Queueを受けてください)。 また、いくつかの実装が複数のStreamsの間の連続した待ち行列の共有をサポートするかもしれません。この場合一般に、「連続すること」を定義するのは重要になります、それらがオーダーで待ち行列でしたが、待ち行列に置かれて、Streamが消費されるシングルのためのバッファにもかかわらず、Streamsの間には、消費オーダー保証が全くありません。
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).
データ転送、特定のページTranslation Tableエントリー(存在しているなら)へのSTagに関するマッピング、およびページTranslation TableエントリーからData Bufferまでのマッピングが初期化されるに違いない(相互作用の詳細に関してセクション2.3.4を見てください)前いつかTagged Data Transfer(すなわち、Tagged Data Buffers、RDMA Write Buffers、またはRDMA Read Buffers)を受けてください。
Pinkerton & Deleganes Standards Track [Page 16] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[16ページ]。
3. Trust and Resource Sharing
3. 信頼とリソース・シェアリング
It is assumed that, in general, the Local and Remote Peer are untrusted, and thus attacks by either should have mitigations in place.
一般に、LocalとRemote Peerは信頼されていないです、そして、その結果、どちらかによる攻撃が適所に緩和を持つべきであると思われます。
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.
別々の、しかし、関連する問題は複数のStreamsの間のリソース・シェアリングです。ローカル資源が共有されないなら、リソースはStream基礎あたりのaで捧げられます。 Resources、リソースはセクション2.2で定義されます。 Streamsの間のリソースを共有しない利点は可能な攻撃のタイプを減少させるということです。 リソースを共有しない不都合は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 Engineリソースを共有しながら制御するためにメカニズムを実装するコンポーネントがPrivileged Resourceマネージャであると本書では思われます。 RNIC EngineはRNIC Interfaceを通してPrivileged Resourceマネージャにリソースを暴露します。 すべてのPrivilegedとNon特権があるULPsはResourceマネージャからリソースを要求します(定義上Non特権があるのとPrivilegedアプリケーションの両方が貪欲にリソースを消費しようとするかもしれないことに注意してください、その結果、潜在的サービス妨害(DOS)攻撃を作成します)。 Resourceマネージャは、リソースへの公正なアクセスを確実にするためにリソース経営政策を実装します。 Resourceマネージャは、このドキュメントで詳細なセキュリティー攻撃を考慮に入れるように設計されるべきです。 いくつかのシステムにおいて、Privileged ResourceマネージャがPrivileged 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.
プロキシとしてPrivileged Resourceマネージャを使用し他のULPsに影響できたRNIC EngineとのすべてのNon特権があるULP相互作用を終わらなければなりません。 また、Privileged Resourceマネージャを使用し希少資源に関するすべての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.
Streamsの向こう側のリソースの共有がそうULPのコントロールの下にあるべきです、ともにULPが作動したがっている信頼モデルで、ULPが地方のプロセスを与えたがっているリソース・シェアリングのレベルと同様に。 部分的な信頼とリソースの共有を結合する信頼モデルのタイプについての、より多くの議論に関しては、Appendix C(Partial Trust Taxonomy)を見てください。
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.
Privileged Resourceマネージャは、本当に、StreamsがPartial Mutual Trustを共有するのを保証するためにメカニズムがない場合異なったStreamsがPartial Mutual Trustを共有すると仮定してはいけません。 Streamsを所有しているULPからの明白な通知を含むいくつかの方法でこれができます。
Pinkerton & Deleganes Standards Track [Page 17] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[17ページ]。
4. Attacker Capabilities
4. 攻撃者能力
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 Messagesを移す前に初期のLLP Stream(そして、接続)がセットアップされるのを必要とします。 これは、少なくとも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).
攻撃者が初期の接続を創造したRemote Peerでないなら、攻撃者の能力を区分できるその時は、能力を能力だけを送るか、送って、または受けます。 能力だけを送ってください。攻撃する、RNICリソース(例えば、TCP一連番号)を攻撃できる前に攻撃者が最初に現在のLLP Streamパラメタを推測するのが必要です。 このクラスの攻撃者もそうしたなら、能力と送付者と送付者に受信機のふりをする能力を受信機に受けてください、そして、それらは「中央の男性」攻撃者[RFC3552]と通常呼ばれます。 中央の男性攻撃者には、RNICリソースを攻撃するはるかに広い能力があります。 攻撃の幅は攻撃Remote Peer(すなわち、初期のLLP StreamをセットアップするRemote Peer)のものと本質的には同じです。
5. Attacks That Can Be Mitigated with End-to-End Security
5. 終わりから終わりへのセキュリティで緩和できる攻撃
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
接続設定/裂け目に関連するどんな新しい攻撃もLLP(例えば、TCPかSCTP)に既に存在していることを超えていないようにストリームモード(すなわち、ペイロードのRDMAカプセル化がない)であえてセットアップと裂け目が倒す接続をすることに注意してください。 しかしながら、RDMAP/DDPパラメタがストリームモードで交換されるかもしれないことに注意してください。そうすれば、攻撃者で崩壊すると、予期せぬ結果は結果として生じるでしょう。 またはしたがって、LLP Spoofingのためのどんな既存の緩和、Tampering、Repudiation、情報Disclosure、サービス妨害、も。
Pinkerton & Deleganes Standards Track [Page 18] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[18ページ]。
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.
Privilegeの高度は、適用し(そして、このドキュメントの範囲の外にあります)続けています。 したがって、このセクションでの分析はLLP Streamタイプにかかわらず存在している攻撃に焦点を合わせます。
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.).
改ざんは正統のトラフィック(マシンインターナルかネットワーク)のあらゆる変更です。 スプーフィング攻撃は攻撃者がRemote Peerのアイデンティティを改竄する(アイデンティティはIPアドレス、マシン名、ULPの平らなアイデンティティであるかもしれませんなど)ところでいじる特別なケースです。
5.1. Spoofing
5.1. スプーフィング
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.
Remote Peer、またはネットワークベースの攻撃者がスプーフィング攻撃に着手できます。 ネットワークベースのスプーフィング攻撃はすべてのRemote Peersに適用されます。 このセクションは様々なタイプのRDMAPに適切なスプーフィング攻撃とDDPを分析します。
5.1.1. Impersonation
5.1.1. ものまね
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 Peer(法的なIPアドレスを偽造するのによる)をまねることができます。 ブラインドが攻撃するか([RFC3552]を見てください)、または犠牲者と共にRDMAP/DDP Streamを設立することによって、これができます。 RDMAP/DDP Streamが、LLP Streamが完全に初期化されるのを必要とするので(例えば、[RFC793]に関して、それはESTABLISHED状態にあります)、盲目の攻撃に対する既存のトランスポート層保護メカニズムは適所に残っています。
For a blind attack to succeed, it requires the attacker to inject a valid transport layer segment (e.g., for TCP, it must match at least the 4-tuple as well as guess a sequence number within the window) while also guessing valid RDMAP or DDP parameters. There are many ways to attack the RDMAP/DDP protocol if the transport protocol is assumed to be vulnerable. For example, for Tagged Messages, this entails guessing the STag and TO values. If the attacker wishes to simply terminate the connection, it can do so by correctly guessing the transport and network layer values, and providing an invalid STag. Per the DDP specification, if an invalid STag is received, the Stream is torn down and the Remote Peer is notified with an error. If an attacker wishes to overwrite an Advertised Buffer, it must successfully guess the correct STag and TO. Given that the TO will often start at zero, this is straightforward. The value of the STag should be chosen at random, as discussed in Section 6.1.1, Using an STag on a Different Stream. For Untagged Messages, if the MSN is invalid then the connection may be torn down. If it is valid, then the receive buffers can be corrupted.
盲目の攻撃が成功するように、有効なトランスポート層セグメントを注入するのがまた、有効なRDMAPかDDPパラメタを推測している間、攻撃者を必要とします(例えば、TCPに関して、それは、少なくとも4-tupleを合わせて、窓の中で一連番号を推測しなければなりません)。 トランスポート・プロトコルが被害を受け易いと思われるなら、RDMAP/DDPプロトコルを攻撃する多くの方法があります。 例えば、Tagged Messagesに関して、これは、STagとTO値を推測するのを伴います。 攻撃者が単に接続を終えたいなら、それが、正しく輸送とネットワーク層値を推測して、無効のSTagを提供することによって、そうできます。 無効のSTagが受け取られているなら、DDP仕様に従ってStreamを取りこわします、そして、誤りでRemote Peerに通知します。 攻撃者がAdvertised Bufferを上書きしたいなら、それは首尾よく正しいSTagとTOを推測しなければなりません。 TOがしばしばゼロから出発するなら、これは簡単です。 STagの値はセクション6.1.1で議論するように無作為に選ばれるべきであり、UsingはDifferent Streamの上のSTagです。 Untagged Messagesに関しては、MSNが無効であるなら、接続を取りこわすかもしれません。 それが有効であるなら、受信バッファは崩壊できます。
End-to-end authentication (e.g., IPsec or ULP authentication) provides protection against either the blind attack or the connected attack.
終わりから終わりへの認証(例えば、IPsecかULP認証)は盲目の攻撃か接続攻撃のどちらかに対する保護を提供します。
Pinkerton & Deleganes Standards Track [Page 19] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[19ページ]。
5.1.2. Stream Hijacking
5.1.2. ストリームハイジャック
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.
ストリームハイジャックは、ネットワークベースの攻撃者がStream確立段階を通したLLP関係を立ち聞きするとき、起こって、認証フェーズ(そのようなフェーズが存在しているなら)が首尾よく完成するまで、待っています。 攻撃者は、次に、IPアドレスを偽造して、犠牲者からそれ自身のマシンまでStreamを向け直します。 例えば、攻撃者は、iSCSI認証が首尾よく終了するまで待っていて、次に、iSCSI Streamをハイジャックできます。
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.
接続、そして/または、Stream自身がLLPによって設立されるので、いくつかのLLPsはハイジャックするのが他のものより難しいです。 接続、そして/または、Streamの周りの安全保障問題に関する関連LLPドキュメンテーションがハイジャックされているのを見てください。
5.1.3. Man-in-the-Middle Attack
5.1.3. 介入者攻撃
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一連番号は適度です)中の男性にStreamを暴露することができる、-、-中央は攻撃されます。 1つのスタイルの攻撃は中央の男性がTagged Messages(RDMAPかDDPのどちらか)を送ることです。 STagのために暴露されたバッファがアクセスを可能にしたと発見できるなら、男性は、中央で関連Data Bufferのコンテンツを読むのにRDMA Read操作を使用するか、関連Data Bufferのコンテンツを変更するためにRDMA Write Operationを実行するか、またはバッファへのさらなるアクセスを無効にするために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によって確立されるので、いくつかのLLPsが他のものより介入者攻撃に暴露されます。 接続、そして/または、Streamの周りの安全保障問題に関する関連LLPドキュメンテーションがハイジャックされているのを見てください。
Pinkerton & Deleganes Standards Track [Page 20] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[20ページ]。
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のように。 このモデルは、非常に限られた展開シナリオであり、ここでさらに調べられないでしょう。
5.2. Tampering - Network-Based Modification of Buffer Content
5.2. 改ざん--バッファの内容のネットワークベースの変更
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、介入者攻撃を見てください。
5.3. Information Disclosure - Network-Based Eavesdropping
5.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).
ネットワークを立ち聞きできる攻撃者は、読まれたすべての内容を読んで、Peerのバッファへのアクセスを書くことができます。 情報公開、読みを防ぐために、/書かれたデータを暗号化しなければなりません。 中央のMan Attack、また、セクション5.1.3を見てください。 ULP、またはRDMAPとDDP(例えば、IPsec)へのセキュリティー・サービスを提供できるプロトコルは暗号化ができます。
5.4. Specific Requirements for Security Services
5.4. セキュリティー・サービスのための決められた一定の要求
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.
概して、Stream秘密性は盗聴から守ります。 流れてください、そして、セッション認証と保全保護は様々なスプーフィングと改ざん攻撃に対するカウンタ測定です。 特定の攻撃に対する認証と保全の有効性は認証が平らな認証(IPsecなどの)、またはULP認証を機械加工することであるかどうかに依存します。
5.4.1. Introduction to Security Options
5.4.1. セキュリティオプションへの序論
The following security services can be applied to an RDMAP/DDP Stream:
RDMAP/DDP Streamに以下のセキュリティー・サービスを適用できます:
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. 1パケットあたりのデータ送信端末認証--以下のスプーフィング攻撃から守ります: ネットワークベースのものまね(セクション5.1.1)とStreamハイジャック(セクション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)のネットワークベースの変更で行われた改ざんと認証に結合されたいつに対して保護するか、そして、また、男性に対して保護している1パケットあたりの保全、-、-、中央、攻撃(セクション5.1.3)。
Pinkerton & Deleganes Standards Track [Page 21] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[21ページ]。
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 Streamはものまね攻撃、またはStreamハイジャック攻撃を受けることがあるかもしれないなら、Streamが認証されるのが、お勧めであり、保全は、反射攻撃から保護して、保護されました。 それは、盗聴から保護するのに秘密性保護を使用するかもしれません(RDMAP/DDP Streamが公衆通信回線を横断するといけないので)。
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 Security Architecture[RFC2401](IKE[RFC2409]、IPsec Authentication Header(AH)[RFC2402]、およびIPsec Encapsulating Security有効搭載量(超能力)[RFC2406]ドキュメント)の中で指定されます。 IKEはかぎ管理プロトコルですが、AHと超能力は、IPトラフィックを保護するのに使用されます。 それぞれのプロトコルの完全な記述に関してそれらのRFCsを見てください。
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プロトコルは上のセキュリティー・サービスの一部しか提供できません。
5.4.2. TLS Is Inappropriate for DDP/RDMAP Security
5.4.2. TLSはDDP/RDMAPセキュリティのために不適当です。
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]はStream認証、保全、および秘密性をTCPのベースのULPsに供給します。 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バッファの中にそれらを置くことができます。 したがって、TLSがデータ・ストリームを保護するのに使用されるなら、DDP/RDMAPのプライマリ特徴の1つ(実装が少しがある流れ終えたアーキテクチャをバッファリングでないのに持っているのを可能にする)を達成できません。
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の上で層にされるのは、RECOMMENDEDではありません。
Pinkerton & Deleganes Standards Track [Page 22] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[22ページ]。
5.4.3. DTLS and RDDP
5.4.3. DTLSとRDDP
DTLS [DTLS] provides security services for datagram protocols, including unreliable datagram protocols. These services include anti-replay based on a mechanism adapted from IPsec that is intended to operate on packets as they are received from the network. For these and other reasons, DTLS is best applied to RDDP by employing DTLS beneath TCP, yielding a layering of RDDP over TCP over DTLS over UDP/IP. Such a layering inserts DTLS at roughly the same level in the protocol stack as IPsec, making DTLS's security services an alternative to IPsec's services from an RDDP standpoint.
DTLS[DTLS]は頼り無いデータグラムプロトコルを含むデータグラムプロトコルのためのセキュリティー・サービスを提供します。 これらのサービスはネットワークからそれらを受け取るようにパケットを作動させることを意図するIPsecから適合させられたメカニズムに基づく反再生を含んでいます。 これらと他の理由で、DTLSはTCPの下でDTLSを使うことによって、最も上手にRDDPに適用されます、UDP/IPの上でDTLSの上の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は、セキュリティフレームワークのための、より良い選択であり、したがって、実装するために義務的です(ほかの場所で本書では指定されるように)。 DTLSよりむしろIPsecの仕様への重要な要因はRDDP(iSCSI[iSCSI][iSER]とNFSv4[NFSv4][NFSv4.1])の2人の初期の採用者の非RDDPバージョンがIPsecと互換性がありますが、これらのプロトコルのどちらも現在TLSかDTLSのどちらかを使用しないということです。 iSCSIの特定のケースのために、IPsecは実装するために義務的なセキュリティー・サービス[RFC3723]の基礎です。 したがって、このドキュメントとRDDPプロトコル仕様はDTLSのためにというよりむしろIPsecに、義務的な実装要件を含んでいます。
5.4.4. ULPs That Provide Security
5.4.4. セキュリティを提供するULPs
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個の安全なチャンネルのエンドポイントがもう片方のチャンネルで1個のチャンネルでセッション保護と拘束力がある認証で同じであると立証できます。」 「チャンネル結合の使用で、アプリケーションは、セッション保護がいくつかのアプリケーションのために性能をかなり向上させるかもしれない層を下ろすのを代表として派遣することができます。」
5.4.5. Requirements for IPsec Encapsulation of DDP
5.4.5. DDPのIPsecカプセル化のための要件
The IP Storage working group has spent significant time and effort to define the normative IPsec requirements for IP Storage [RFC3723]. Portions of that specification are applicable to a wide variety of protocols, including the RDDP protocol suite. In order not to replicate this effort, an RNIC implementation MUST follow the requirements defined in RFC 3723, Section 2.3 and Section 5,
IP Storageワーキンググループは、IP Storage[RFC3723]のための標準のIPsec要件を定義するために重要な時間と取り組みを費やしました。 その仕様の部分はRDDPプロトコル群を含むさまざまなプロトコルに適切です。 この取り組みを模写しない命令では、RNIC実装はRFC3723、セクション2.3、およびセクション5で定義された要件に続かなければなりません。
Pinkerton & Deleganes Standards Track [Page 23] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[23ページ]。
including the associated normative references for those sections. Note that this means that support for IPSEC ESP mode is normative.
それらのセクションの関連引用規格を含んでいます。 これが、IPSEC ESPモードのサポートが規範的であることを意味することに注意してください。
Additionally, since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down a DDP/RDMA Stream. Rather, it is preferable to leave the Stream up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing Streams up and down.
さらに、IPsec加速ハードウェアが2SAs、Phase2が削除するアクティブなIKE Phaseの限られた数を扱うことができるだけであるかもしれないので、aが意味するように使用されていないSAsのためにアクティブなPhase2SAsの数を最小限に保つのについてメッセージを送るかもしれません。 IKE Phase2の領収書はメッセージを削除します。引き裂く理由がDDP/RDMA Streamより倒すとき、解釈されてはいけません。 むしろ、Streamが上げる休暇、それを保護するために別のIKE Phase2SAを持って来るためにそれで追加トラフィックを送るなら、望ましいです。 これは絶えずStreamsを上下に持って来る可能性を避けます。
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がネットワークの中央のトンネルとして実装されるなら、PeerとIPsecトンネリングデバイスの間のどんなホストも自由に保護のないStreamを攻撃できます。
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のバージョンに基づいているので、IPsec要件は、RFC2401[RFC2401]で指定して、RFC4301[RFC4301]で指定されたIPsecの、より新しいバージョンの存在にもかかわらず、RFC3723[RFC3723]によって輪郭を描かれるようにRFCsを関係づけて、RFCsを関係づけました。 RDDPプロトコルの重要な早めの応用の1つはiSCSI[iSER]との彼らの使用です。 RDDPのIPsec要件は、IPsecの一般的なプロフィールがiSCSIとRDDPプロトコルと共に使用されるのを許容することによってその用法を容易にするためにIPsecのものに続きます。 将来、IPsecの、より新しいバージョンにRFC3723をアップデートするかもしれません。 どんなそのようなものの要件もアップデートするIPsecセキュリティは一様にiSCSIとRDDPプロトコルに申請されるべきです。
6. Attacks from Remote Peers
6. リモート同輩からの攻撃
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で定義したRDMA Security ModelとRNIC Engine。 分析はそれぞれの攻撃の詳述、攻撃されているもの、および攻撃を阻むために取ることができる対策の記述を含んでいます。
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.).
攻撃は5つのカテゴリに分類されます: Privilegesのスプーフィング、Tampering、情報Disclosure、サービス妨害(DoS)攻撃、およびElevation。 既述のとおり、改ざんは正統のトラフィック(マシンインターナルかネットワーク)のあらゆる変更です。 スプーフィング攻撃は攻撃者がRemote Peerのアイデンティティを改竄する(アイデンティティはIPアドレス、マシン名、ULPの平らなアイデンティティであるかもしれませんなど)ところでいじる特別なケースです。
Pinkerton & Deleganes Standards Track [Page 24] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[24ページ]。
6.1. Spoofing
6.1. スプーフィング
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を分析します。 Remote Peerかネットワークベースの攻撃者がスプーフィング攻撃に着手できます。 ネットワークベースの攻撃者に対する対策に関しては、Endから終わりへのSecurityと共にセクション5、Attacks That Can Be Mitigatedを見てください。
6.1.1. Using an STag on a Different Stream
6.1.1. 異なったストリームで雄ジカを使用します。
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.
Remote Peerからの1つのスタイルの攻撃はそれが使用するのは認可されないSTag値を使用するのを試みることです。 Remote Peerが無効のSTagをLocal Peerに送るなら、DDPとRDMAP仕様に従ってStreamを取りこわさなければならないことに注意してください。 したがって、STagが1Streamの上のRemote Accessのために有効にされたなら、脅威は存在しています、そして、Remote Peerは関係ないStreamでそれを使用できます。 攻撃がうまくいくなら、攻撃者は、関連Data Bufferのコンテンツを読むためにRDMA Read操作を実行するか、関連データバッファのコンテンツを変更するためにRDMA Write操作を実行するか、またはバッファへのさらなるアクセスを無効にするために潜在的にSTagを無効にすることができるかもしれません。
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.
同じProtection Domainの異なったStreamの上のSTagと共にバッファにアクセスするRemote Peerによる試みは攻撃であるかもしれません、リソース・シェアリングが意図するかどうかに(すなわち、StreamsがPartial Mutual Trustを共有したか否かに関係なく)よって。 いくつかのULPsに関しては、同じProtection Domainの中の複数のStreamsの上のSTagを使用するのは、望まれた行動であるかもしれません。 他のULPsに関しては、異なったStreamの上のSTagを使用するのを試みるのを攻撃であると考えることができました。 これがULPで異なるので、ULPは、通常STagの範囲を制御できる必要があるでしょう。
In the case where an implementation does not share resources between Streams (including STags), this attack can be defeated by assigning each Stream to a different Protection Domain. Before allowing remote access to the buffer, the Protection Domain of the Stream where the access attempt was made is matched against the Protection Domain of the STag. If the Protection Domains do not match, access to the buffer is denied, an error is generated, and the RDMAP Stream associated with the attacking Stream is terminated.
実装がStreamsの間のリソースを共有しない(STagsを含んでいて)場合では、各Streamを異なったProtection Domainに割り当てることによって、この攻撃を破ることができます。 バッファに遠隔アクセスを許容する前に、アクセス試みがされたStreamのProtection DomainはSTagのProtection Domainに取り組まされます。 Protection Domainsが合っていないなら、バッファへのアクセスは拒絶されます、そして、誤りは発生しています、そして、攻撃しているStreamに関連しているRDMAP Streamは終えられます。
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.
複数のStreamsの間のリソースを共有する実装には、それ自身のProtection Domainに各Streamを切り離すのは実用的でないかもしれません。 この場合、ULPはまだSTagsのどれかの範囲を独身のStreamに制限できます(遠隔アクセスのためにそれを可能にしているなら)。 STag範囲が独身のStreamに制限されたなら、異なったStreamでそのSTagを使用するどんな試みも誤りをもたらすでしょう、そして、RDMAP Streamは終えられます。
Pinkerton & Deleganes Standards Track [Page 25] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[25ページ]。
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.
したがって、Streamsの間のSTagsを共有しない実装のために各Streamが別々のProtection Domainにあるに違いありませんか、またはSTagの範囲を独身のStreamに制限しなければなりません。
An RNIC MUST ensure that a specific Stream in a specific Protection Domain cannot access an STag in a different Protection Domain.
RNIC MUSTは、特定のProtection Domainの特定のStreamが異なったProtection Domainで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 MUSTは、STagが範囲で独身のStreamに制限されるなら他のどんなStreamも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).
追加設定がそれが引き起こすRemote PeerでSTags(すなわち、ULPの欠陥)かバグを共有しながら故意でないかもしれない、オフもの、使用されるべきSTag。 追加保護のために、実装は、次の割り当てられたSTag番号を予測するのが難しいくらいのファッションでSTagsを割り当てて、また、STagsができるだけ遅いレートで再利用されるのを確実にするべきです。 同輩によるSTagの意図的であるか意図的でない再利用につながるどんな配分方法も避けられるべきです(例えば、メソッドが、そんなにいつも与えられたSTagから始まって、それぞれの新しい配分単位でそれを単調に増強するか、またはメソッドは各操作にそんなにいつも同じSTagを使用します)。
6.2. Tampering
6.2. 改ざん
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.
A Remote Peerかネットワークベースの攻撃者が、リモートな状態でLocal Peerの上のそれが可能にされたData Buffersのコンテンツをいじるのを試みることができる、アクセサリーを書いてください。 Remote Peerから攻撃をいじるタイプは従うセクションで概説されています。 ネットワークベースの攻撃者に対する対策に関しては、Endから終わりへのSecurityと共にセクション5、Attacks That Can Be Mitigatedを見てください。
6.2.1. Buffer Overrun - RDMA Write or Read Response
6.2.1. バッファ超過--RDMAは応答を書くか、または読みます。
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.
この攻撃はリモートな状態で有効な長さの外部が有効にされたData Bufferを及ばせるメモリへのRDMA WriteかRDMA Read Responseを実行するRemote Peerによる試みがアクセサリーを書くということです。 リソースが全くStreamsの向こう側に共有さえされないとき、この攻撃は起こることができます。また、ULPにバグがあるなら、この問題は起こることができます。
The countermeasure for this type of attack must be in the RNIC implementation, leveraging the STag. When the local ULP specifies to the RNIC the base address and the umber of bytes in the buffer that it wishes to make accessible, the RNIC must ensure that the base and bounds check are applied to any access to the buffer referenced by the STag before the STag is enabled for access. When an RDMA data transfer operation (which includes an STag) arrives on a Stream, a base and bounds byte granularity access check must be performed to ensure that the operation accesses only memory locations within the buffer described by that STag.
STagを利用して、RNIC実装にはこのタイプの攻撃のための対策があるに違いありません。 地方のULPがそれが作りたがっているバッファのバイトのベースアドレスとアンバーをアクセスしやすい状態でRNICに指定するとき、RNICは、ベースと領域チェックがSTagがアクセサリーのために有効にされる前にSTagによって参照をつけられたバッファへのどんなアクセスにも適用されるのを確実にしなければなりません。 RDMAデータ転送操作(STagを含んでいる)がStream、ベース、および領域バイトで到着するとき、操作がそのSTagによって説明されたバッファの中で記憶域だけにアクセスするのを保証するために粒状アクセスチェックを実行しなければなりません。
Pinkerton & Deleganes Standards Track [Page 26] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[26ページ]。
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実装は、Remote PeerがSTagが遠隔アクセスのために有効にされたときバッファの外部が指定したメモリにアクセスできないのを確実にしなければなりません。
6.2.2. Modifying a Buffer after Indication
6.2.2. 指示の後にバッファを変更します。
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.
STagのコンテンツを変更するRemote Peer試みがRemote Peerが、STag Data Buffer内容が使用の準備ができているのをLocal Peerか地方のULP(さまざまな手段による)に示した後にRDMA WriteかRDMA Read Responseを実行することによってバッファに参照をつけたなら、この攻撃は起こることができます。 リソースが全くStreamsの向こう側に共有さえされないとき、この攻撃は起こることができます。また、Remote Peer、またはネットワークベースの改ざんにおけるバグがこの問題をもたらすかもしれないことに注意してください。
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.
例えば、制御情報を最初に有効にして、次に、ULPペイロード、および操作のULP系列がまた、ULP制御情報ですが、参照をつけられたバッファが入れてあるSTagが制御情報に操作を実行すると仮定してください。 バリディティチェックが完成した後にもかかわらず、制御データが操作される前を除いて、Remote Peerが追加RDMA WriteかRDMA Read Response(その結果、バッファを変える)を実行できるなら、オンであることで、Remote Peerは決して意図しなかった操作上の経路の下側に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は、Remote Peerが、操作がRDMAP Remote Invalidate能力でSTagを完成するか、または念のためRemote Peerをチェックする無効にしたのを示すときSTagのために明らかにリモートアクセス権を取り消すことによって、これができます。 Remote PeerがSTagを無効にしなかったなら、地方のULPは明らかにSTagのリモートアクセス権を取り消します。 Remote Invalidate、セクション6.4.5を見てください。(Remote Invalidateの定義のためのMultiple Streamsの上のSTag Shared、)
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 SHOULDは、バッファ(または、何らかの方法でバッファを使用する)のコンテンツを有効にする前にバッファを保護するために上の手順に従います。
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 MUSTは、以前にaにSTagを使用することでそのネットワークにパケットを確実にします。ULPが特定のSTagのためにリモートアクセス権を取り消した後にAdvertised Bufferはもうバッファを変更できません。
6.2.3. Multiple STags to Access the Same Buffer
6.2.3. 同じバッファにアクセスする複数の雄ジカ
See Section 6.3.6 Using Multiple STags That Alias to the Same Buffer, for this analysis.
この分析に関してSame Bufferにおいてセクション6.3.6人のUsing Multiple STags Thatアリアを見てください。
Pinkerton & Deleganes Standards Track [Page 27] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[27ページ]。
6.3. Information Disclosure
6.3. 情報公開
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.
遠隔アクセスのために可能にされたローカルのバッファを通して情報公開のための主電位ソースがあります。 別のStreamの上のRemote Peerがバッファを調べることができるなら、情報公開の可能性があります。
The potential attacks that could result in unintended information disclosure and countermeasures are detailed in the following sections.
故意でない情報公開と対策をもたらすことができた起こり得るかもしれない攻撃は以下のセクションで詳細です。
6.3.1. Probing Memory Outside of the Buffer Bounds
6.3.1. バッファ領域の外でメモリを調べます。
This is essentially the same attack as described in Section 6.2.1, Buffer Overrun - RDMA Write or Read Response, except that an RDMA Read Request is used to mount the attack. The same countermeasure applies.
これはセクション6.2.1で説明されるように本質的には同じ攻撃です、Buffer Overrun--RDMA WriteかRead Response、それを除いて、RDMA Read Requestは、攻撃を仕掛けるのに使用されます。 同じ対策は適用されます。
6.3.2. Using RDMA Read to Access Stale Data
6.3.2. RDMAを使用するのはアクセスの聞き古したデータに読んで聞かせました。
If a buffer is being used for some combination of reads and writes (either remote or local), and is exposed to a Remote Peer with at least remote read access rights before it is initialized with the correct data, there is a potential race condition where the Remote Peer can view the prior contents of the buffer. This becomes a security issue if the prior contents of the buffer were not intended to be shared with the Remote Peer.
バッファが読書の何らかの組み合わせに使用されていて、(リモートであるか地方)で書いて、それが正しいデータで初期化される前に少なくともリモート読書アクセス権でRemote Peerに暴露されるなら、潜在的競合条件がRemote Peerがバッファの先のコンテンツを見ることができるところにあります。 バッファの先のコンテンツによって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 SHOULDは、リモート読書アクセス権を与える(例えば、メモリのコンテンツのゼロを合わせることによって、これができます)前にバッファにどんな聞き古したデータも含まないのを確実にします。 これは、聞き古したデータが取り除かれるまでRemote Peerがバッファにアクセスできないのを確実にします。
6.3.3. Accessing a Buffer after the Transfer
6.3.3. 転送の後にバッファにアクセスします。
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.
Remote Peerが、リモート読書アクセスをバッファに持って、何らかのメカニズムで転送が終了しましたが、データを変更する前に地方のULPがバッファに遠隔アクセスを無効にしないと地方のULPに言うなら、Remote Peerが新しいデータを検索するのは、可能です。
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で定義された攻撃と同様であり、ModifyingはIndicationの後のBufferです。 同じ対策は適用されます。 さらに、地方のULP SHOULDは時間のだけアクセス権が検索する必要があったリモート読書にデータを与えます。
Pinkerton & Deleganes Standards Track [Page 28] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[28ページ]。
6.3.4. Accessing Unintended Data with a Valid STag
6.3.4. 有効な雄ジカと共に故意でないデータにアクセスします。
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がRemote Peerがとにかくバッファの他の部分にアクセスするのにおいて可能な状態でバッファリングしますが、全体がバッファの一部だけは意図する参照がアクセスされて、それがそうであるSTagを使用することで遠隔アクセスをバッファに可能にするなら。
To prevent this attack, the ULP SHOULD set the base and bounds of the buffer when the STag is initialized to expose only the data to be retrieved.
STagが検索されるためにデータだけを暴露するために初期化されるとき、この攻撃を防ぐために、ULP SHOULDはバッファのベースと領域を設定します。
6.3.5. RDMA Read into an RDMA Write Buffer
6.3.5. RDMAから読み取られたRDMAはバッファを書きます。
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つの形式の公開は起こることができて、リモートであるだけであるときにはアクセスを書いてください。意図しました。 バッファが関係ないStreamにおける転送からULPデータ、またはデータを含んでいるなら、Remote PeerはRDMA Read操作でデータを検索できるでしょう。 RNIC実装は両方にアクセサリーを読み書きさせるSTagsをサポートするのに必要でないことに注意してください。
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.
最も明白である、バッファが意図するならこの攻撃がどんな交付金にもリモートでないので対策がアクセスを読んだのを書く、-単に。 その時、Remote Peerはバッファに関連しているデータを検索できないでしょう。 そうする試みは誤りをもたらすでしょう、そして、Streamに関連しているRDMAP Streamは終えられるでしょう。
Thus, if a ULP only intends a buffer to be exposed for remote write access, it MUST set the access rights to the buffer to only enable remote write access. Note that this requirement is not meant to restrict the use of zero-length RDMA Reads. Zero-length RDMA Reads do not expose ULP data. Because they are intended to be used as a mechanism to ensure that all RDMA Writes have been received, and do not even require a valid STag, their use is permitted even if a buffer has only been enabled for write access.
したがって、a ULPがリモートな状態で暴露されるバッファを意図するだけであるならアクセスを書いてください、リモートな状態で可能にするだけであるバッファへのアクセス権を設定しなければならない、アクセサリーを書いてください。 この要件がゼロ・レングスRDMA Readsの使用を制限することになっていないことに注意してください。 ゼロ・レングスRDMA Readsは、ULPがデータであると暴露しません。 すべてのRDMA Writesが受け取られたのを確実にして、有効なSTagを必要としないのさえメカニズムとして彼らが使用されることを意図するので、バッファが可能にされるだけであっても彼らの使用が受入れられる、アクセサリーを書いてください。
6.3.6. Using Multiple STags That Alias to the Same Buffer
6.3.6. そんなに通称同じバッファに複数の雄ジカを使用します。
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.
STagsが異なって、互いに信頼されていないRemote Peersによって使用されるなら、同じくらいへの別名が同時にバッファリングする複数のSTagsが意図的でない情報公開をもたらすことができます。 このモデルは特にクライアント/サーバコミュニケーションに当てはまります。そこではサーバは交信することです複数のクライアントと。それのそれぞれが互いに互いを信じません。
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
地方のULPには、読まれるだけであるなら、アクセスは可能にされて、次に、情報公開の完全なコントロールがあります。 したがって、同じデータが(すなわち、バッファ)であると複数のクライアントに同じバッファに複数のSTagsを使用することによって暴露するつもりであったサーバはどんな新しい安全保障問題も作成しません。
Pinkerton & Deleganes Standards Track [Page 29] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[29ページ]。
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).
既に本書では説明されることを超えて。 サーバが同じデータをクライアントに暴露しないつもりであるなら、各クライアントに別々のバッファを使用することに注意してください(STagsを切り離してください)。
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.
あるSTagがアクセスが可能にして、異なったSTagがリモートにするリモート読書に同じバッファに可能にされたアクセスを書かせるとき、あるRemote Peerが別のRemote Peerによって書かれている内容を見るのは、可能です。
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.
STagsがリモートにする両方が可能にされたアクセスを書いて、2Remote Peersが互いに互いを信じないなら、1Remote Peerがもう片方のRemote Peerによって書かれている内容を上書きするのは、可能です。
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.
その結果Partial Mutual Trustを共有しないRemote Peersがそうしてはいけない倍数がある交付金が異なることを通してSTagsをバッファリングすると同じくらいへのアクセスに書くULP。 バッファは確実にするどんな情報公開も情報もいじられないで、同輩の間に起こる時に1信頼されていないRemote Peerだけに暴露されるべきです。
6.4. Denial of Service (DOS)
6.4. サービス妨害(DOS)
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環境が信頼されていないRemote Peersとのコミュニケーションを必要とするからです。 Remote Peerを認証できたか、または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 Streamで有効なパケットを推測できなければなりません。
This section outlines the potential attacks and the countermeasures available for dealing with each attack.
このセクションは各攻撃に対処するのに利用可能な起こり得るかもしれない攻撃と対策を概説します。
6.4.1. RNIC Resource Consumption
6.4.1. RNICリソース消費
This section covers attacks that fall into the general category of a local ULP attempting to unfairly allocate scarce (i.e., bounded) RNIC resources. The local ULP may be attempting to allocate resources on its own behalf, or on behalf of a Remote Peer. Resources that fall into this category include Protection Domains, Stream Context Memory,
このセクションは不公平に不十分な(すなわち、バウンドしている)RNICリソースを割り当てるのを試みる地方のULPの一般的なカテゴリになる攻撃をカバーします。 地方のULPは、それ自身の利益、またはRemote Peerを代表してリソースを割り当てるのを試みているかもしれません。 このカテゴリになるリソースがProtection Domains、Stream Context Memoryを含んでいます。
Pinkerton & Deleganes Standards Track [Page 30] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[30ページ]。
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.
翻訳、Protection Tables、およびSTag名前空間。 これらは現在アクティブな地方のULPsか、より早くリソースを割り当てていますが、現在活動していないものによる攻撃のためであることができます。
This type of attack can occur regardless of whether resources are shared across Streams.
リソースが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:
Privileged Resourceマネージャのコントロールの下ですべての希少資源の配分を置かなければなりません。 これは、以下のことをPrivileged Resourceマネージャは許容します。
* 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).
* Remote Peerが、Streams(関連リソースがある)の過度の数を作成して、修正措置(要求を拒否するか、またはRemote Peerに対してネットワーク層フィルタを適用などなどの)を取るのを試みることによってDOS攻撃に着手するのを試みているかどうか検出してください。
This analysis assumes that the Resource Manager is responsible for handing out Protection Domains, and that RNIC implementations will provide enough Protection Domains to allow the Resource Manager to be able to assign a unique Protection Domain for each unrelated, untrusted local ULP (for a bounded, reasonable number of local ULPs). This analysis further assumes that the Resource Manager implements policies to ensure that untrusted local ULPs are not able to consume all the Protection Domains through a DOS attack. Note that Protection Domain consumption cannot result from a DOS attack launched by a Remote Peer, unless a local ULP is acting on the Remote Peer's behalf.
この分析は、ResourceマネージャがProtection Domainsを与えるのに責任があって、RNIC実装がそれぞれの関係なくて、信頼されていない地方のULP(地方のULPsの境界があって、妥当な数のための)のためにユニークなProtection Domainを割り当てることができる状態でResourceマネージャは許容できるくらいのProtection Domainsを提供すると仮定します。 この分析は、Resourceマネージャが信頼されていない地方のULPsがDOS攻撃ですべてのProtection Domainsを消費できるというわけではないのを保証するために政策を実施するとさらに仮定します。 Protection Domain消費がRemote Peerによって着手されたDOS攻撃から生じることができないことに注意してください、地方のULPがRemote Peerの利益に影響していない場合。
6.4.2. Resource Consumption by Idle ULPs
6.4.2. 使用されていないULPsによるリソース消費
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攻撃の最も簡単なフォームは、リソースの定額を考えて、Remote PeerがRDMAP StreamをLocal Peerに作成して、ひたむきなリソースを要求して、次に、どんな実際の仕事もしないことです。 これは、Remote Peerが非常に軽い重さ(すなわち、単にリソースを交渉しなさい、ただし、データ転送を全くしない)であることを許容して、Local Peerで不釣り合いな額に関するリソースを消費します。
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 Streamsをモニターすることであり、リソースが低くなっているなら、それは、RDMAP Streamsからのリソースを獲得するために、データを移していなくて、ことによるとStreamを終えます。 おそらく、これが運営管理コントロールの下にあるでしょう。
Pinkerton & Deleganes Standards Track [Page 31] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[31ページ]。
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を参照してください: Context Memory、ページTranslation Tables、およびSTag名前空間を流してください。
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.
攻撃が、リソースを消費するためにRemote Peerがメッセージを送るのを必要とするので、いくつかのRNICリソースがRemote Peerからのこのタイプの攻撃で危険でないことに注意してください。 Data Buffers、Completion Queueを受けてください。そうすれば、RDMA Read Request Queueリソースは例です。 しかしながら、これらのリソースはリソースを割り当てるのを試みて、次に活動していなくなる地方のULPから危険です。 また、ULPがLocal Peerにリソースを消費させるRemote Peerとリソースレベルを交渉するなら、これは作成されるかもしれません。 しかしながら、Remote Peerは、それらを消費するためにデータを決して送りません。 使用されていないLocal Peerによって割り当てられたリソースを解放するのにこのセクションで説明された一般的な対策は使用できます。
6.4.3. Resource Consumption by Active ULPs
6.4.3. アクティブなULPsによるリソース消費
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.
このセクションは活発にメッセージを交換しているLocalとRemote PeersからDOS攻撃について説明します。 それぞれのRDMA NICリソースに対する攻撃は調べられます、そして、特定の対策は特定されます。 Stream Context Memory、ページTranslation Tables、およびSTag名前空間に対する攻撃がセクション6.4.1でカバーされていることに注意してください、彼らがここに含まれていないRNIC Resource Consumption。
6.4.3.1. Multiple Streams Sharing Receive Buffers
6.4.3.1. 受信バッファを共有する複数のストリーム
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.
受信バッファが複数のStreamsの向こう側に共有されるなら、正当な分け前以上を消費するRemote Peer缶の試みはData Buffers(すなわち、DDPのためのUntagged BuffersかRDMAPのためのSend Type Messages)を受けます。
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.
リソースが複数のStreamsの向こう側に共有されないなら、Remote PeerがStreamに割り当てたより多くのバッファを消費できないので、この攻撃は可能ではありません。 最悪の場合はRemote PeerがLocal PeerへのRemote PeerのStreamを取りこわすことができたどんな利用可能なバッファももたらさないで、許容された地方の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.
地方であるなら、Streams、当時のRemote Peerが異なったStreamが受信バッファが不足していることを引き起こす受信バッファの正当な分け前よりさらに、そして、その結果、消費するのを試みることができる倍数の中で共有されて、もう片方のStreamが取りこわされることをことによると引き起こしながら、Data Buffersを受けてください。 例えば、Remote Peerが十分な1バイトのUntagged Messagesを送るなら、彼らは局所的に共有されていた状態ですべてを消費できるだろうにて、ほとんど努力せずに先方においては待ち行列リソースを受け取ってください。
Pinkerton & Deleganes Standards Track [Page 32] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[32ページ]。
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.
Local Peerが使用できた1つのメソッドはRemote Peerがリソースの正当な分け前以上を使用して、Streamを終えるのを試みていると認める(割り当てられたリソースが発表されることを引き起こして)ことです。 しかしながら、Local Peerが十分遅いなら、Remote Peerがまだサービス不能攻撃を仕掛けているのは、可能であるかもしれません。 この攻撃から守ることができる1つの対策は低水位の通知を実装することです。 受信してください。低水位の通知が中のバッファの数であるならULPを警告する、待ち行列は1未満敷居です。
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.
ローカルの受信バッファの量が掲示した次に、本当の、または、Local Peerの、または、地方の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
* そしてLocal Peerが受信バッファを補給するにはかかる時間に制限できる。
* The Local Peer maintains statistics to determine which Remote
Peer is consuming buffers.
* Local Peerは、どのRemote Peerがバッファを消費しているかを決定するために統計を取ります。
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).
リソースを使い果たす前に上記の状態は、低水位の通知が到着するのを可能にします、そして、その結果、Local Peerか地方のULPが修正措置を取ることができます(例えば、攻撃しているRemote PeerのStreamを終えてください)。
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.
異なりましたが、同様の攻撃はRemote Peerが多くの故障しているパケットを送って、RNICで再アセンブリバッファとしてULPバッファ(すなわち、DDPのためのUntagged BufferかRDMAPのためにSend Type Messageによって消費されたバッファ)を使用する能力があるかどうかということです。 この場合、Remote Peerは多くの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を警告する最高水位通知を作成することです。 同時に、バッファの指定された数以上が特定のStreamにプロセスにあるとき(すなわち、パケットはバッファのために到着し始めましたが、バッファはまだ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 EngineがStream基礎あたりのaの受信バッファを消費するRemote Peerの性能を制限する能力を提供することです。 残念ながら、これは、多量の状態がaの各Stream基礎あたりのRNIC単位の追跡コネであることを必要とします。
Pinkerton & Deleganes Standards Track [Page 33] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[33ページ]。
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 Engineが複数のStreamsの向こう側に受信バッファを共有する能力を提供するなら、RNIC EngineとPrivileged Resourceマネージャの組み合わせは、Remote Peerが、Local Peerか地方のULPが攻撃を検出して、防ぐために対策を適用できるようにリソースの正当な分け前以上を消費するのを試みているかどうか検出できなければなりません。
6.4.3.2. Remote or Local Peer Attacking a Shared CQ
6.4.3.2. 共有されたCQを攻撃しているリモートであるか地元の同輩
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:
Remote Peerは以下のメソッドの1つを使用することによって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.
* Remote Peerは地方のULPにULPプロトコルで指定された数のCQエントリーを控えさせることができます、ことによるとCQを共有している他のStreamsに不十分なエントリーを出て。
* 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).
* Remote Peer、Local Peer、または地方のULP(または、どんな組み合わせ)が落成で圧倒的であるのによるCQ CQを攻撃できるなら、そのCompletion Queueを共有する他のStreamsにおける完成処理は影響を受けることができます(例えば、Completion Queueは、あふれて、機能するのを止めます)。
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がRemote PeerにCQエントリーを控えさせないか、または信じられた仲介者がいれば、最初の攻撃方法を避けることができます、Privileged Resourceマネージャのように。 残念ながら、Remote PeerがCQエントリーを控えるのを許容しないのがしばしば非現実的である、特に完成エントリーの数が他のULPに依存しているなら、バッファリングの量などの交渉されたパラメタがULPが必要です。 したがって、実装は、CQエントリーの配分を制御するためにPrivileged Resourceマネージャを実装しなければなりません。 Privileged Resourceマネージャの定義に関してセクション2.1、Componentsを見てください。
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
1つの方法で、できるだけ多くの1秒あたりの落成(Remote Peerのために落成を受けてください、そして、Local Peerのために落成を送る)を引き起こすために、LocalかRemote Peerが、落成でCQを圧倒するのを試みることができるのが送付の最小の長さのRDMAP/DDP Messagesであります。 それがRemote Peer攻撃であり、私たちが、Local Peerのものが受信バッファから走行ではなく、(s)がそうする待ち行列を受けると思うなら(そうするなら、次に、これはセクション6.4.3.1Multiple Streams Sharing Receive Buffersに記録された異なった攻撃です)、Remote PeerがCompletion Queueエントリーの正当な分け前以上を消費するのは、可能であるかもしれません。 CQ実装によって、これがオーバーフロー(それが落成が生成したすべてを扱うことができるくらいには大きくないなら)かCQにエントリーを生成することができない別のStreamのためにCQを引き起こす場合があった、(RNICはCQの世代にフロー制御を持っていました。
Pinkerton & Deleganes Standards Track [Page 34] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[34ページ]。
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へのエントリー) どちらの場合ではも、CQは、正しく機能するのを止めるでしょう、そして、CQで落成を予想するどんなStreamsも機能するのを止めるでしょう。
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に関連しているすべてのStreamsが同じであるか異なったProtection Domainsにあることにかかわらずこの攻撃は起こることができます--主要な問題はCompletion Queueエントリーの数が完成を引き起こす場合があるすべての傑出している操作の数より少ないということです。
The Local Peer can protect itself from this type of attack using either of the following methods:
Local Peerはこのタイプの攻撃から以下のメソッドのどちらかを使用することで我が身をかばうことができます:
* 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
* サイズは以下での指定(Send QueueとReceive Queueを大きさで分ける前にStreamでCQリサイズをするべきであるためにCQが、現在、存在して、リサイズされる必要があるなら、CQをリサイズするのはすべてのケースに成功するのに必要でないことに注意する)にされるとしての適正水準ORへのCQです。
* Grant fewer resources than the Remote Peer requested (not
supplying the number of Receive Data Buffers requested).
* Remote Peerが要求したより少ないリソース(Receive Data Buffersの数が要求した供給しない)を与えてください。
The proper sizing of the CQ is dependent on whether the local ULP(s) will post as many resources to the various queues as the size of the queue enables. If the local ULP(s) can be trusted to post a number of resources that is smaller than the size of the specific resource's queue, then a correctly sized CQ means that the CQ is large enough to hold completion status for all the outstanding Data Buffers (both send and receive buffers), or:
CQの適切なサイズ処理は地方のULP(s)が様々な待ち行列への待ち行列のサイズが可能にするのと同じくらい多くのリソースを掲示するかどうかに依存しています。 または、地方のULP(s)が特定のリソースの待ち行列のサイズより小さい多くのリソースを掲示すると信じることができるなら正しく大きさで分けられたCQが、CQがすべての傑出しているData Buffersのための完成状態を保持できるくらい大きいことを意味する、(両方が、バッファを送って、受け取ります):
CQ_MIN_SIZE = SUM(MaxPostedOnEachRQ)
+ SUM(MaxPostedOnEachSRQ)
+ SUM(MaxPostedOnEachSQ)
CQ_分_サイズ=合計(MaxPostedOnEachRQ)+合計(MaxPostedOnEachSRQ)+合計(MaxPostedOnEachSQ)
Where:
どこ:
MaxPostedOnEachRQ = the maximum number of requests that
can cause a completion that will be posted on a
specific Receive Queue.
MaxPostedOnEachRQは特定のReceive Queueに掲示される完成を引き起こす場合がある要求の最大数と等しいです。
MaxPostedOnEachSRQ = the maximum number of requests that
can cause a completion that will be posted on a
specific Shared Receive Queue.
MaxPostedOnEachSRQは特定のShared Receive Queueに掲示される完成を引き起こす場合がある要求の最大数と等しいです。
MaxPostedOnEachSQ = the maximum number of requests that
can cause a completion that will be posted on a
specific Send Queue.
MaxPostedOnEachSQは特定のSend Queueに掲示される完成を引き起こす場合がある要求の最大数と等しいです。
Pinkerton & Deleganes Standards Track [Page 35] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[35ページ]。
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)
CQ_分_サイズ=合計(SizeOfEachRQ)+合計(SizeOfEachSRQ)+合計(SizeOfEachSQ)
Where:
どこ:
SizeOfEachRQ = the maximum number of requests that
can cause a completion that can ever be posted
on a specific Receive Queue.
SizeOfEachRQは今までに特定のReceive Queueに掲示できる完成を引き起こす場合がある要求の最大数と等しいです。
SizeOfEachSRQ = the maximum number of requests that
can cause a completion that can ever be posted
on a specific Shared Receive Queue.
SizeOfEachSRQは今までに特定のShared Receive Queueに掲示できる完成を引き起こす場合がある要求の最大数と等しいです。
SizeOfEachSQ = the maximum number of requests that
can cause a completion that can ever be posted
on a specific Send Queue.
SizeOfEachSQは今までに特定のSend Queueに掲示できる完成を引き起こす場合がある要求の最大数と等しいです。
MaxPosted*OnEach*Q and SizeOfEach*Q vary on a per Stream or per Shared Receive Queue basis.
MaxPosted*OnEach*QとSizeOfEach*QはStreamかShared Receive Queue基礎あたりのaで異なります。
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がPartial Mutual Trustを共有しない複数のStreamsの向こう側にCQを共有しているなら、ULP MUSTは、Completion Queueがあふれないのを保証するためにメカニズムを実装します。 CQsにアクセスするRemote Peersが上の2つの定石のどちらかなら信頼されていなくても共有するために、CQsが実装されるのが、可能であることに注意してください。 ULPがMaxPostedOnEachRQ、MaxPostedOnEachSRQ、およびMaxPostedOnEachSQ以上を掲示しないと信じることができるなら、最初の公式は適用されます。 ULPが限界に従うと信じることができないなら、2番目の公式は適用されます。
6.4.3.3. Attacking the RDMA Read Request Queue
6.4.3.3. RDMA読み出し要求待ち行列を攻撃します。
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
Remote PeerがRDMA Read Request Queueの深さより多くのRDMA Read RequestsをLocal Peerに送るなら、RDMA Read Request Queueを攻撃できます。 RDMA Read Request Queueが共用資源であるなら、これは待ち行列を崩壊させるかもしれません。 待ち行列が共有されないなら、最悪の場合は現在のStreamがもう機能的でないという(例えば、取りこわします)ことです。 共有されたRDMA Read Request Queueが敷居で、それらと同様に作成することになっている解決への1つのアプローチがセクション6.4.3で.1、Multiple Streams Sharing Receive Buffersについて説明しました。 より簡単なアプローチはRDMA Read Request Queueを共有しないことです。
Pinkerton & Deleganes Standards Track [Page 36] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[36ページ]。
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.
または、Streamsの中のリソース、1Streamあたりの消費の困難な限界を実施するために。 したがって、Privileged ResourceマネージャがRDMA Read Request Queueリソース消費を制御しなければならないので、Partial Mutual Trustを共有しないRDMAP/DDP StreamsがRDMA Read Request Queueリソースを共有しません。
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.
問題が悪意ある攻撃ではなく、Remote Peerの実装でバグであるなら、Remote PeerのRNICがRDMA Read Requestsを阻止するのを必要とすることによって、問題を解決できます。 信じられたエージェントを通してRemote Peerで適切にStreamを構成することによって、RNICにLocal PeerでRDMA Read Request Queueの深さを超えているRDMA Read Requestsを伝えさせることができません。 Streamが正しく構成されて、Remote PeerがLocal PeerのRDMA Read Request Queueが扱うことができるより多くの要求を提出するなら、要求はRemote PeerのRNICに前の要求まで完全な状態で列に並ばせられるでしょう。 より多くのRDMA Read RequestsがLocal Peerが扱うことができるより(先のパラグラフの推薦が実装されると仮定して)Local Peerに到着して、Remote PeerのStreamが正しく構成されないなら、RDMAP Streamは終えられます。 その結果、SHOULDが傑出しているRDMA Read Requestsの数にふたをするためにメカニズムを提供するRNIC実装。 このドキュメントの範囲の外にこの限界の構成があります。
6.4.4. Exercise of Non-Optimal Code Paths
6.4.4. 非最適のコード経路の運動
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誤りにおいて、攻撃しているStreamが単に取りこわされることに注意してください。 したがって、この形式の攻撃が有効であるように、Remote Peerは、Streamを取りこわさないデータ経路を運動させる必要があります。
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実装が裂け目のどんな結果も打ち負かさないStreamの「遅い経路」を含んでいるなら、実装が上記の状態を検出して、管理者が行動するのを許容する能力を提供するのは、お勧めです、潜在的に行政上不釣り合いな額に関するリソースを消費するデータ経路を運動させているStreamに関連しているRDMAP Streamを取りこわすのを含んでいて。
6.4.5. Remote Invalidate an STag Shared on Multiple Streams
6.4.5. リモートである、複数のストリームで共有された雄ジカを無効にしてください。
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
Local Peerが遠隔アクセスのためにSTagを有効にしたなら、Remote Peerは、InvalidateかSendと共にSEとInvalidate MessageでRDMAP Sendを使用することによってSTagを離れて無効にするのを試みるかもしれません。 STagが単に現在のStream、当時の唯一の副作用で有効であるなら
Pinkerton & Deleganes Standards Track [Page 37] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[37ページ]。
is that the Remote Peer can no longer use the STag; thus, there are no security issues.
Remote Peerがもう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が複数のStreamsの向こう側に有効であるなら、Remote Peerは、他のStreamsがRemote Invalidateの機能性を使用することによってその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 StreamsがPartial Mutual Trustを共有しないなら(すなわち、Remote Peerは、早まってSTagを離れて無効にするのを試みるかもしれません)、ULP MUST NOTは複数のStreamsの向こう側に有効なSTagを有効にします。
6.4.6. Remote Peer Attacking an Unshared CQ
6.4.6. Unshared CQを攻撃しているリモート同輩
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.
Local Peerが正しくどんなサイズにもCQをしないなら、Remote Peerはunshared CQを攻撃できます。 例えば、Local Peerが、CQが受信されたバッファの落成を扱うのを可能にして、受信バッファ待ち行列がCompletion Queueより長いなら、オーバーフローは潜在的に起こることができます。 攻撃者のStreamへの効果は壊滅的です。 しかしながら、RNICが適所に適切な保護を持っていないなら、また、CQからはみ出す攻撃は関係ないStreamの不正、そして/または、終了を引き起こす場合があります。 したがって、RNIC MUSTは、CQがあふれるなら、CQ MUSTを使用しないどんなStreamsも影響を受けないままで残っているのを確実にします。
6.5. Elevation of Privilege
6.5. 特権の高度
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 Security Architectureは明らかに3つのレベルの特権を区別します: 非特権があって、特権がある、そして、特権がある資源管理プログラム。 Non特権があるULPが特権レベルをPrivileged ULPに登用できるなら、物理アドレスリストをSTagに写像すると、ノードでどんな物理アドレス位置への地方の、そして、リモートなアクセスも提供できます。 Privileged Mode ULPがResourceマネージャになるようにそれ自体を促進できるなら、サービスタイプ攻撃の否定を実行するのは、かなりの量のローカル資源を消費できたところで可能です。
In general, elevation of privilege is a local implementation specific issue and is thus outside the scope of this document.
一般に、その結果、このドキュメントの範囲の外に、特権の高度は、ローカルの実装特定の問題であり、あります。
7. Attacks from Local Peers
7. 地元の同輩からの攻撃
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で定義したRDMA Security ModelとRNIC Engine。
Pinkerton & Deleganes Standards Track [Page 38] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[38ページ]。
7.1. Local ULP Attacking a Shared CQ
7.1. 共有されたCQを攻撃する地方のULP
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.
どちらかが、エントリーの数の正当な分け前より多くの落成を引き起こすのを試みるなら、Shared Completion Queue(CQ--セクション2.2.6を見てください、Completion Queues)に対するDOS攻撃は地方のULPかRemote Peerのどちらかによって引き起こされる場合があります。 その結果、潜在的に、どんなCompletion Queueエントリーも利用可能でないように、別の関係ない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.
Send Queueか完成からReceive Queueから完成でCompletion Queueエントリーを潜在的に陰湿に消費できます。 前者では、攻撃者は地方のULPです。 後者では、攻撃者はRemote Peerです。
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.
攻撃のフォームは地方のULPsが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 MUST NOTがPartial Mutual Trustを共有しないULPsの向こう側に共有しているa CQを有効にするので。
7.2. Local Peer Attacking the RDMA Read Request Queue
7.2. RDMA読み出し要求待ち行列を攻撃している地元の同輩
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 Read Request Queueリソースが複数のStreamsの向こう側にプールされるなら、1つの攻撃は地方のULPが、不公平にStreamsのためのリソースをRDMA Read Request Queueに割り当てるのを試みるかどうかということです。例えば、地方のULPは、Streamsのために特定のRDMA Read Request Queueに関するすべての利用可能資源を割り当てるのを試みます、その結果、RDMA Read Request Queueを共有するULPsに対してリソースを否定します。 RDMA Read Requestが共有されないでも、同じタイプの議論は適用されますが、地方のULPは、待ち行列が作成されるとき、RNICのリソースをすべてに割り当てるのを試みます。
Thus, access to interfaces that allocate RDMA Read Request Queue entries MUST be restricted to a trusted Local Peer, such as a Privileged Resource Manager. The Privileged Resource Manager SHOULD prevent a local ULP from allocating more than its fair share of resources.
したがって、エントリーをRDMA Read Request Queueに割り当てるインタフェースへのアクセスを信じられたLocal Peerに制限しなければなりません、Privileged Resourceマネージャのように。 Privileged ResourceマネージャSHOULDは、地方のULPがリソースの正当な分け前以上を割り当てるのを防ぎます。
7.3. Local ULP Attacking the PTT and STag Mapping
7.3. PTTと雄ジカマッピングを攻撃する地方の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.
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.
Pinkerton & Deleganes Standards Track [Page 39] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[39ページ]。
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、Architectural Modelで議論するように、マッピング要求を仲裁するPrivileged Resourceマネージャの導入は効果的な対策です。 これは、Privileged Resourceマネージャが、地方のULPがそれ自身のバッファを示すために、ページTranslation Table(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.
したがって、Non特権があるULPsがサポートされるなら、Privileged Resourceマネージャは、ULPにはアクセス権があるSTagが特定のData Bufferに関連しているのを許容する前に特定のData BufferにアクセスするためにNon特権があるULPが権利があることを確かめなければなりません。 Data BufferにアクセスするためにページTranslation Tableを初期化するか、またはページTranslation Tableエントリー、または両方のグループを示すためにSTagを初期化するとき、これができます。
8. Security considerations
8. セキュリティ問題
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、Attacks That CanがEndから終わりへのSecurityとMitigatedであることを確実にしてください。 リモート同輩からのセクション6、攻撃。 セクション7、攻撃の詳細に渡る分析のためのLocal PeersからのAttacks、および攻撃を緩和する標準の対策。
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 Client/サーバプロトコルのためのULP Issues)は伝統的なクライアント/サーバが相互作用のスタイルであると実装するアプリケーションのための導入問題と要件の概要を提供します。 それはセクション5、6、および7の標準のテキストの追加洞察と適用性を提供します。 付録B(RNICとULP Implementation RequirementsのSummary)はimplementersのための標準の要件の便利な概要を提供します。
9. IANA Considerations
9. IANA問題
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問題も扱わなければなりません。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley,
"Direct Data Placement over Reliable Transports", RFC
5041, October 2007.
[DDP] 2007年10月のシャーとH.とピンカートンとJ.とRecio、R.とP.Culley、「信頼できる輸送の上のダイレクトデータプレースメント」RFC5041。
[RDMAP] Recio, R., Culley, P., Garcia, D., and J. Hilland, "A
Remote Direct Memory Access Protocol Specification",
RFC 5040, October 2007.
[RDMAP]RecioとR.とCulleyとP.とガルシア、D.とJ.Hilland、「リモートダイレクトメモリアクセスプロトコル仕様」RFC5040(2007年10月)。
Pinkerton & Deleganes Standards Track [Page 40] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[40ページ]。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
Travostino, "Securing Block Storage Protocols over IP",
RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF.Travostino、「IPの上でブロックストレージがプロトコルであると機密保護します」、RFC3723(2004年4月)。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「ストリーム制御伝動プロトコル」、RFC4960、9月2007日
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
10.2. Informative References
10.2. 有益な参照
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC4949] Shirey、R.、「インターネットセキュリティ用語集、バージョン2インチ、RFC4949、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)の適用性」、RFC5045(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 Consortium規格、2003年4月、<草稿-hilland-iwarp動詞http://www.rdmaconsortium.org/ホーム/v1.0-RDMAC.pdf>。
Pinkerton & Deleganes Standards Track [Page 41] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[41ページ]。
[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-概要] _「RDMAはNIC(RNIC)動詞のOverviewを有効にしたこと」はレナートRecio、2003年4月までにプレゼンテーションを滑らせて、<http://www.rdmaconsortium.org/ホーム/RNICはVerbs_Overview2.pdf>です。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[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] 「インフィニバンドアーキテクチャ仕様ボリューム1インチ、1.2、標準のインフィニバンド産業団体<http://www.infinibandta.org/仕様>をリリースしてください。」 動詞は第11章に記録されます。
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[DTLS]レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、2006年4月のRFC4347。
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
and E. Zeidner, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004.
[iSCSI] Satran、J.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、2004年4月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah,
H., and P. Thaler, "Internet Small Computer System
Interface (iSCSI) Extensions for Remote Direct Memory
Access (RDMA)", RFC 5046, October 2007.
[iSER] コー、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターレル、「リモートダイレクトメモリアクセス(RDMA)のためのインターネットスモールコンピュータシステムインタフェース(iSCSI)拡大」、RFC5046(2007年10月)。
[NFSv4] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File
System (NFS) version 4 Protocol", RFC 3530, April 2003.
[NFSv4]Shepler(S.、キャラハン、B.、ロビンソン、D.、サーロウ、R.、Beame、C.、アイスラー、M.、およびD.Noveck)は「File System(NFS)バージョン4プロトコルをネットワークでつなぎます」、RFC3530、2003年4月。
[NFSv4.1] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
"NFSv4 Minor Version 1", Work in Progress, September
2007.
[NFSv4.1] Shepler、S.、エド、アイスラー、M.、エド、D.Noveck、エド、「NFSv4小さい方のバージョン1インチ、進歩、2007年9月に働いてください。」
Pinkerton & Deleganes Standards Track [Page 42] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[42ページ]。
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と定義されます。 さらに、サーバは特定のクライアントとコミュニケートするのに複数のStreamsを使用したがっているかもしれません、そして、それらのStreamsは信頼関係を共有するかもしれません。 このセクションが言いなりになっているRNICとPrivileged Resourceマネージャ実装を仮定することに注意してください--その結果、それは特に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.
攻撃と対策に関する先のセクションの詳細のすべてがサーバに適用されます。 したがって、このセクションで繰り返される要件は非標準の“must"、“should"、および“may"を使用します。 いくつかの場合、このドキュメントの本体からのULPのための標準のSHOULD声明が出される、ULPサーバのための声明で、運転条件に洗練されることができるので、a SHOULDのための動機は不適当にならなければなりません。 先のSHOULDに変えるなら、aはこのセクションで使用しなければなりません、そして、明らかに注意されます、そして、それは大文字している規範的陳述を使用します。
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 Operations(RDMA Read、RDMA Write)を使うかもしれないことに注意してください。 したがって、適切であるところでは、「地方のULP」、「地元の同輩」、および「リモート同輩」が「サーバ」か「クライアント」に代わって使用されます、それぞれの要件の完全な一般性を保有するために。
* Spoofing
* スプーフィング
* Sections 5.1.1 to 5.1.3. For protection against many forms of
spoofing attacks, enable IPsec.
* .1〜5.1に.3に5.1を区分します。 多くの形式のスプーフィング攻撃に対する保護には、IPsecを有効にしてください。
* Section 6.1.1, Using an STag on a Different Stream. To ensure
that one client cannot access another client's data via use of
the other client's STag, the server ULP must either scope an
STag to a single Stream or use a unique Protection Domain per
* セクション6.1 .1 異なったストリームで雄ジカを使用します。 それを確実にするために、もう片方のクライアントのSTagの使用で、あるクライアントは別のクライアントのデータにアクセスできません、サーバULPが独身のStreamへのSTagを見なければならないか、またはユニークなProtection Domainを使用しなければならない単位
Pinkerton & Deleganes Standards Track [Page 43] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[43ページ]。
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.
クライアント。 独身のクライアントがPartial Mutual Trustを共有する複数のStreamsを持っているなら、関連Streamsの間で関連Streamsの中で独身のProtection Domainを使用することによって、STagを共有できます(セクション5.4.4を見てください、ULPs That Provide Security、追加設定のために)。 関連Streams、サーバの中でSTagsの故意でない共有を防ぐために、ULPは次の割り当てられたSTag番号を予測するのが難しいくらいのファッションでSTagsを使用するはずです。
* 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 WriteかRDMA Readを使用することでRemote Peerによって書かれたバッファを作動させる前に、地方のULP MUSTは、もう遠隔アクセスのためにSTagを無効にすることによってバッファを変更できないのを(これがSHOULDよりセクション6.2.2に強いことに注意してください)確実にします。 Remote Peerが、操作が完成したのを示すときSTagのために明らかにリモートアクセス権を取り消すか、または確実にRDMAP Invalidate能力でRemote Peer InvalidatedをSTagにするようにチェックすることによって、これができます。 Remote Peerが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を使用するのはアクセスの聞き古したデータに読んで聞かせました。 汎用のサーバ環境で、リモート読書が可能にされる(そして、何気なく共有しているデータの莫大な下落傾向)前に原理が、バッファが初期化されるのを必要としないのを強制してはいけません。 したがって、a地方のULP MUST(これはSHOULDよりセクション6.3.2に強い)は、リモート読書アクセス権をRemote Peerに与える(例えば、メモリのコンテンツのゼロを合わせることによって、これができます)前にバッファにどんな聞き古したデータも含まないのを確実にします。
* 6.3.3, Accessing a Buffer after the Transfer. This mitigation
is already covered by Section 6.2.2 (above).
* 6.3.3 aにアクセスして、後に転送をバッファリングしてください。 この緩和はセクション6.2.2 (above)で既にカバーされています。
* 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はバッファを書きます。 同輩がリモートな状態で暴露されるバッファを意図するだけであるならアクセスを書いてください、リモートな状態で可能にするだけであるバッファへのアクセス権を設定しなければならない、アクセサリーを書いてください。
Pinkerton & Deleganes Standards Track [Page 44] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[44ページ]。
* 6.3.6, Using Multiple STags That Alias to the Same Buffer. The
requirement in Section 6.1.1 (above) mitigates this attack. A
server buffer is exposed to only one client at a time to ensure
that no information disclosure or information tampering occurs
between peers.
* 6.3.6、そんなに通称同じバッファに複数の雄ジカを使用します。 セクション6.1.1 (above)における要件はこの攻撃を緩和します。 サーババッファは確実にするどんな情報公開も情報もいじられないで、同輩の間に起こる時に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 倍数は、受信バッファを共有しながら、流れます。 何らかのサーバULPsに、ULPメモリーフットプリントサイズは重要である場合があります。 サーバであるなら、ULPは複数のクライアントから重要なネットワークトラフィックを予想していて、1多くのStreamsがあるStreamあたり1つの受信バッファ待ち行列を使用すると、かなりの量のメモリを消費できます。 したがって、aは共有されて、複数のStreamsが魅力的であるということであるかもしれない待ち行列を受けます。
However, because of the attacks outlined in this section,
sharing a single receive queue between multiple clients must
only be done if a mechanism is in place to ensure that one
client cannot consume receive buffers in excess of its limits,
as defined by each ULP. For multiple Streams within a single
client ULP (which presumably shared Partial Mutual Trust), this
added overhead may be avoided.
このセクションで概説された攻撃のためにシングルを共有するのがどのように受信されても、1人のクライアントが限界を超えて受信バッファを消費できないのを保証するためにメカニズムが適所にあるなら、複数のクライアントの間の待ち行列をするだけでよいです、各ULPによって定義されるように。 独身のクライアントULP(どのおそらく、共有されたPartial Mutual Trust)の中の複数のStreamsに関しては、これは、オーバーヘッドが避けられるかもしれないと言い足したか。
* 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緩和は、地方のULPsがPartial Mutual Trustを共有しないならRNICがCQの共有を可能にしないのを必要とします。 したがって、2地方のULPsがPartial Mutual Trustを共有するなら、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、RemoteかLocal Peer Attacking a Shared CQ。
2) The local ULP ensures that CQ entries are reaped frequently
enough to adhere to Section 6.4.3.2's rules.
2) 地方のULPは、CQエントリーがセクション6.4.3.2の規則を固く守ることができるくらいの頻繁に刈り取られるのを確実にします。
* 6.4.3.2, Remote or Local Peer Attacking a Shared CQ. There are
two mitigations specified in this section - one requires a
worst-case size of the CQ, and can be implemented entirely
within the Privileged Resource Manager. The second approach
requires cooperation with the local ULP server (not to post too
many buffers), and enables a smaller CQ to be used.
* 6.4.3.2 リモートであるか地方の同輩攻撃aはCQを共有しました。 このセクションで指定された2つの緩和があります--1つは、CQの最悪の場合サイズを必要として、完全にPrivileged Resourceマネージャの中で実装することができます。 2番目のアプローチは、ローカルのULPサーバ(あまりに多くのバッファを掲示しない)との協力を必要として、より小さいCQが使用されるのを可能にします。
Pinkerton & Deleganes Standards Track [Page 45] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[45ページ]。
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読み出し要求を攻撃して、列を作ってください。 セクションは、サーバのPrivileged ResourceマネージャがサーババッファにRDMA Read操作を実行するULPのためにPartial Mutual Trustを共有しない複数のStreamsの向こう側にRDMA Read Request Queuesを共有させるのを必要としません。 しかしながら、サーバULPが、StreamsのどれがPartial Mutual Trustを最もよく共有するかを知っているので、この要件をULPに映し出すことができます。 この場合ULP(すなわち、サーバ)要件はRDMA Read Request QueuesがPartial Mutual Trustを持っていないULPsの間で共有されるのを許容してはいけないということです。
* 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、Remote Invalidate、Multiple Streamsこの緩和でのSTag Sharedはセクション6.2.2 (above)で既にカバーされています。
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 異なったストリームで雄ジカを使用すること。
* 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 Unshared CQを攻撃しているリモート同輩
* 6.5 Elevation of Privilege 39
* 6.5 特権39の高度
Pinkerton & Deleganes Standards Track [Page 46] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[46ページ]。
* 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と雄ジカマッピングを攻撃する地方の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 異なったストリームで雄ジカを使用すること。
* 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 有効な雄ジカと共に故意でないデータにアクセスすること。
* 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 そんなに通称同じバッファに複数の雄ジカを使用すること。
* 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.
部分的なTrustは1回のパーティーが別のパーティーが特定の攻撃か1セットの攻撃を控えると仮定しても構わないと思っている時と定義されて、パーティーはPartial Trustの州にあると言われています。 部分的に信じられた同輩が異なった攻撃を試みるかもしれないことに注意してください。 これは、裏切りのどんな悪影響も容易に閉じ込められる多くのULPsに適切であるかもしれなく、他のクライアントかULPsをリスクにみなしません。
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.
このセクションで説明されたTrust Modelsで、3は、特性を区別しながら、プライマリになります。 Trust Modelは地方のULPとRemote Peerについて言及します。(Remote PeerはRDMA/DDPで交信する地方の、そして、リモートなULPインスタンスであることを意図します)。
Pinkerton & Deleganes Standards Track [Page 47] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[47ページ]。
* 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 Streamsの組分けの向こう側に共有されます。地方のResource Sharing(はい/いいえ)--ローカル資源が共有されないなら、リソースはStream基礎あたりのaで捧げられます。 Resources、リソースはセクション2.2で定義されます。 Streamsの間のリソースを共有しない利点は可能な攻撃のタイプを減少させるということです。 不都合は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.
* 地方のPartial Trust(はい/いいえ)--Streams(ULPsの1つのULPかグループに通常一致している)が、互いが特定のセットを実行しないと互いに信じるRDMAP/DDPの地方の組分けが攻撃されるかどうかに基づいて地方のPartial Trustは断固としています。
* 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).
* リモートPartial Trust(はい/いいえ)--特定のRDMAP/DDP Streamの地方のULPがStreamのRemote Peerを部分的に信じるかどうか(セクション1とのPartial Trustの定義を見てください、Introduction)に基づいてRemote Partial Trustレベルは決定しています。
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によって使用されると予想されるというわけではありません。 このドキュメントは明確に共用であると予想される5ULP Trust Modelsを分析します。 Trust Modelsは以下の通りです:
* 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--非共有されたLocal Resources、Local Trustがない、Remote Trustがありません。 通常可能な最も安全なモードに立候補したがっているサーバ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--非共有されたLocal Resources、Local Trustがない、Remote Partial Trust。 通常、何らかのメソッドでこのドキュメントの範囲の外部を持っているピアツーピアULPはRemote Peerを認証しました。 何らかの形式の主要なベースの認証がRDMA/DDP Stream基礎あたりのaで使用されない場合、介入者攻撃が起こるのが、可能でないかもしれないことに注意してください。
* 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--Local Resources、Local Trustがない、どんなRemote Trustも共有しませんでした。 通常、リソースの量が必要である信頼されていない環境へ駆け込むサーバULPは大き過ぎるか、またはそれぞれのRDMAP/DDP Streamのために捧げることができないくらいダイナミックです。
* 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--Local Resources、Local Partial Trust、どんなRemote Trustも共有しませんでした。 通常セッション層を提供して、複数のStreamsを使用するULP、追加スループットかフェイルオーバー能力を提供します。 地方のULPの中のすべてのStreamsは互いを部分的に信じますが、Remote Peerは信じません。 埋め込まれた環境に、このTrust Modelは適切であるかもしれません。
Pinkerton & Deleganes Standards Track [Page 48] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[48ページ]。
* 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--共有されたローカル資源、地方の部分的な信頼、リモート部分的な信頼。 通常分散データベースアプリケーションかHighパフォーマンスコンピュータ(HPC)アプリケーションなどの分配された応用。(それは、クラスタで走られるつもりです)。 要件、アプリケーションが同輩のすべてで通常認証して、その時が高く信じられた環境で実行する極端なリソースと性能のため。 アプリケーション同輩は、すべてただ一つのアプリケーション欠点ドメインにいて、データ構造にアクセスするとき、品行方正になるようにお互いに頼ります。 信じられたRemote Peerに不十分な振舞いをもたらす実装欠陥があるなら、全体のアプリケーションは改悪されるかもしれません。
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もRemote Peerも信じられません。 時々、複数の地方のULPsの向こう側にページTranslation Tablesの共有を可能にする最適化ができます。 したがって、Model S-LTは有利である場合があります。 いかなる他のモデルも使用するのが大きい平行なULPの向こう側に比例するリソースで実行不可能になると、モデルS-Tは通常使用されます。 リソーススケーリング問題はスケーリングの周りの性能のためか十分なリソースが絶対にないのでであることができます。 モデルNS-RTをたぶん使用されるべき最もありそうでないモデルですが、完全性のために寄贈します。
Acknowledgments
承認
Sara Bitan Microsoft Corporation EMail: sarab@microsoft.com
サラBitanマイクロソフト社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
カリフォルニア95134サンノゼ(米国)が電話をするアリンRomanowシスコシステムズの170Wタスマンのドライブ: +1 (408) 525-8836 メールしてください: allyn@cisco.com
Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 USA EMail: meadows@itd.nrl.navy.mil
キャサリン草地海軍研究試験所は5543年のDC20375ワシントン(米国)メールをコード化します: meadows@itd.nrl.navy.mil
Pinkerton & Deleganes Standards Track [Page 49] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[49ページ]。
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
Agilent技術Inc.1101クリークサイドの尾根ドライブ、S-RG10ローズビル、100のM/カリフォルニア 95678#の米国が電話をするパトリシアThaler: +1 (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
ジェームスリビングストンNEC Solutions(アメリカ)Inc.7525第166Ave。 東北、スイートD210レッドモンド、ワシントン98052-7811米国は以下に電話をします。 +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
ジョンキャリヤーザリガニ株式会社411のFirst Avenue S、Suite600シアトル、ワシントン98104-2860Phone: 206-701-2090 メールしてください: carrier@cray.com
Caitlin Bestler Broadcom 49 Discovery Irvine, CA 92618 EMail: cait@asomi.com
Discoveryアーバイン、ケイトリンBestler Broadcom49カリフォルニア 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
米国レッドモンド、ワシントン 98052が以下に電話をするバーナードAbobaマイクロソフト社1マイクロソフト方法 +1 (425) 706-6606 メールしてください: bernarda@windows.microsoft.com
Pinkerton & Deleganes Standards Track [Page 50] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[50ページ]。
Authors' Addresses
作者のアドレス
James Pinkerton Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 (425) 705-5442 EMail: jpink@windows.microsoft.com
ワシントン98052レッドモンド(米国)が電話をするジェームスピンカートンマイクロソフト社1マイクロソフト道: +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
自己私書箱9245が耐えるか、または97305が電話をするエレンDeleganes: (503) 642-3950 メールしてください: deleganes@yahoo.com
Pinkerton & Deleganes Standards Track [Page 51] RFC 5042 DDP/RDMAP Security October 2007
ピンカートンとDeleganes規格はDDP/RDMAPセキュリティ2007年10月にRFC5042を追跡します[51ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Pinkerton & Deleganes Standards Track [Page 52]
ピンカートンとDeleganes標準化過程[52ページ]
一覧
スポンサーリンク
