draft-ietf-rddp-security-08.txt   draft-ietf-rddp-security-09.txt 
Internet Draft James Pinkerton Internet Draft James Pinkerton
draft-ietf-rddp-security-08.txt Microsoft Corporation draft-ietf-rddp-security-09.txt Microsoft Corporation
Category: Standards Track Ellen Deleganes Category: Standards Track Ellen Deleganes
Expires: September, 2006 Intel Corporation Expires: November, 2006 Intel Corporation
Sara Bitan Sara Bitan
Microsoft Corporation Microsoft Corporation
March 2006 May 2006
DDP/RDMAP Security DDP/RDMAP Security
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
skipping to change at page 2, line ? skipping to change at page 2, line ?
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document analyzes security issues around implementation and This document analyzes security issues around implementation and
use of the Direct Data Placement Protocol(DDP) and Remote Direct use of the Direct Data Placement Protocol(DDP) and Remote Direct
Memory Access Protocol (RDMAP). It first defines an architectural Memory Access Protocol (RDMAP). It first defines an architectural
model for an RDMA Network Interface Card (RNIC), which can model for an RDMA Network Interface Card (RNIC), which can
implement DDP or RDMAP and DDP. The document reviews various implement DDP or RDMAP and DDP. The document reviews various
attacks against the resources defined in the architectural model attacks against the resources defined in the architectural model
and the countermeasures that can be used to protect the system. and the countermeasures that can be used to protect the system.
Attacks are grouped into spoofing, tampering, information Attacks are grouped into those that can be mitigated by using
disclosure, denial of service, and elevation of privilege. secure communication channels across the network, attacks from
Finally, the document concludes with a summary of security Remote Peers, and attacks from Local Peers. Attack categories
services for DDP and RDMAP, such as IPsec. include spoofing, tampering, information disclosure, denial of
service, and elevation of privilege.
J. Pinkerton, et al. Expires September, 2006 1 J. Pinkerton, et al. Expires November, 2006 1
Table of Contents Table of Contents
1 Introduction.................................................4 1 Introduction.................................................4
2 Architectural Model..........................................6 2 Architectural Model..........................................7
2.1 Components...................................................7 2.1 Components...................................................8
2.2 Resources....................................................9 2.2 Resources...................................................10
2.2.1 Stream Context Memory......................................9 2.2.1 Stream Context Memory.....................................10
2.2.2 Data Buffers..............................................10 2.2.2 Data Buffers..............................................10
2.2.3 Page Translation Tables...................................10 2.2.3 Page Translation Tables...................................11
2.2.4 Protection Domain (PD)....................................11 2.2.4 Protection Domain (PD)....................................11
2.2.5 STag Namespace and Scope..................................11 2.2.5 STag Namespace and Scope..................................12
2.2.6 Completion Queues.........................................12 2.2.6 Completion Queues.........................................13
2.2.7 Asynchronous Event Queue..................................12 2.2.7 Asynchronous Event Queue..................................13
2.2.8 RDMA Read Request Queue...................................13 2.2.8 RDMA Read Request Queue...................................13
2.3 RNIC Interactions...........................................13 2.3 RNIC Interactions...........................................14
2.3.1 Privileged Control Interface Semantics....................13 2.3.1 Privileged Control Interface Semantics....................14
2.3.2 Non-Privileged Data Interface Semantics...................13 2.3.2 Non-Privileged Data Interface Semantics...................14
2.3.3 Privileged Data Interface Semantics.......................14 2.3.3 Privileged Data Interface Semantics.......................15
2.3.4 Initialization of RNIC Data Structures for Data Transfer..14 2.3.4 Initialization of RNIC Data Structures for Data Transfer..15
2.3.5 RNIC Data Transfer Interactions...........................16 2.3.5 RNIC Data Transfer Interactions...........................16
3 Trust and Resource Sharing..................................17 3 Trust and Resource Sharing..................................18
4 Attacker Capabilities.......................................18 4 Attacker Capabilities.......................................19
5 Attacks That Can be Mitigated With End-to-End Security......19 5 Attacks That Can be Mitigated With End-to-End Security......20
5.1 Spoofing....................................................19 5.1 Spoofing....................................................20
5.1.1 Impersonation.............................................19 5.1.1 Impersonation.............................................20
5.1.2 Stream Hijacking..........................................20 5.1.2 Stream Hijacking..........................................21
5.1.3 Man-in-the-Middle Attack..................................20 5.1.3 Man-in-the-Middle Attack..................................21
5.2 Tampering - Network based modification of buffer content....21 5.2 Tampering - Network based modification of buffer content....22
5.3 Information Disclosure - Network Based Eavesdropping........21 5.3 Information Disclosure - Network Based Eavesdropping........22
5.4 Specific Requirements for Security Services.................21 5.4 Specific Requirements for Security Services.................22
5.4.1 Introduction to Security Options..........................22 5.4.1 Introduction to Security Options..........................23
5.4.2 TLS is Inappropriate for DDP/RDMAP Security...............22 5.4.2 TLS is Inappropriate for DDP/RDMAP Security...............23
5.4.3 ULPs Which Provide Security...............................23 5.4.3 ULPs Which Provide Security...............................24
5.4.4 Requirements for IPsec Encapsulation of DDP...............23 5.4.4 Requirements for IPsec Encapsulation of DDP...............24
6 Attacks from Remote Peers...................................25 6 Attacks from Remote Peers...................................26
6.1 Spoofing....................................................25 6.1 Spoofing....................................................26
6.1.1 Using an STag on a Different Stream.......................25 6.1.1 Using an STag on a Different Stream.......................26
6.2 Tampering...................................................26 6.2 Tampering...................................................27
6.2.1 Buffer Overrun - RDMA Write or Read Response..............27 6.2.1 Buffer Overrun - RDMA Write or Read Response..............28
6.2.2 Modifying a Buffer After Indication.......................27 6.2.2 Modifying a Buffer After Indication.......................28
6.2.3 Multiple STags to access the same buffer..................28 6.2.3 Multiple STags to access the same buffer..................29
6.3 Information Disclosure......................................28 6.3 Information Disclosure......................................29
6.3.1 Probing memory outside of the buffer bounds...............28 6.3.1 Probing memory outside of the buffer bounds...............29
6.3.2 Using RDMA Read to Access Stale Data......................28 6.3.2 Using RDMA Read to Access Stale Data......................29
6.3.3 Accessing a Buffer After the Transfer.....................29 6.3.3 Accessing a Buffer After the Transfer.....................30
6.3.4 Accessing Unintended Data With a Valid STag...............29 6.3.4 Accessing Unintended Data With a Valid STag...............30
6.3.5 RDMA Read into an RDMA Write Buffer.......................29 6.3.5 RDMA Read into an RDMA Write Buffer.......................30
6.3.6 Using Multiple STags Which Alias to the Same Buffer.......30 6.3.6 Using Multiple STags Which Alias to the Same Buffer.......31
6.3.7 Controlling Access to PTT & STag Mapping..................30
6.4 Denial of Service (DOS).....................................31 6.4 Denial of Service (DOS).....................................31
6.4.1 RNIC Resource Consumption.................................31 6.4.1 RNIC Resource Consumption.................................32
6.4.2 Resource Consumption by Idle ULPs.........................32 6.4.2 Resource Consumption by Idle ULPs.........................32
6.4.3 Resource Consumption By Active ULPs.......................32 6.4.3 Resource Consumption By Active ULPs.......................33
6.4.3.1 Multiple Streams Sharing Receive Buffers...............33 6.4.3.1 Multiple Streams Sharing Receive Buffers...............33
6.4.3.2 Remote or Local Peer Attacking a Shared CQ.............34 6.4.3.2 Remote or Local Peer Attacking a Shared CQ.............35
6.4.3.3 Attacking the RDMA Read Request Queue..................37 6.4.3.3 Attacking the RDMA Read Request Queue..................37
6.4.4 Exercise of non-optimal code paths........................37 6.4.4 Exercise of non-optimal code paths........................38
6.4.5 Remote Invalidate an STag Shared on Multiple Streams......38 6.4.5 Remote Invalidate an STag Shared on Multiple Streams......38
6.4.6 Remote Peer attacking an Unshared CQ......................38 6.4.6 Remote Peer attacking an Unshared CQ......................39
6.5 Elevation of Privilege......................................38 6.5 Elevation of Privilege......................................39
7 Attacks from Local Peers....................................40 7 Attacks from Local Peers....................................40
7.1 Local ULP Attacking a Shared CQ.............................40 7.1 Local ULP Attacking a Shared CQ.............................40
7.2 Local Peer Attacking the RDMA Read Request Queue............40 7.2 Local Peer Attacking the RDMA Read Request Queue............40
8 Security considerations.....................................41 7.3 Local ULP Attacking the PTT & STag Mapping..................40
9 IANA Considerations.........................................42 8 Security considerations.....................................42
10 References..................................................43 9 IANA Considerations.........................................43
10.1 Normative References......................................43 10 References..................................................44
10.2 Informative References....................................43 10.1 Normative References......................................44
11 Appendix A: ULP Issues for RDDP Client/Server Protocols.....45 10.2 Informative References....................................44
11 Appendix A: ULP Issues for RDDP Client/Server Protocols.....46
12 Appendix B: Summary of RNIC and ULP Implementation 12 Appendix B: Summary of RNIC and ULP Implementation
Requirements.....................................................49 Requirements.....................................................50
13 Appendix C: Partial Trust Taxonomy..........................51 13 Appendix C: Partial Trust Taxonomy..........................52
14 Author's Addresses..........................................53 14 Author's Addresses..........................................54
15 Acknowledgments.............................................54 15 Acknowledgments.............................................55
16 Full Copyright Statement....................................55 16 Full Copyright Statement....................................56
Table of Figures Table of Figures
Figure 1 - RDMA Security Model....................................7 Figure 1 - RDMA Security Model....................................8
1 Introduction 1 Introduction
RDMA enables new levels of flexibility when communicating between RDMA enables new levels of flexibility when communicating between
two parties compared to current conventional networking practice two parties compared to current conventional networking practice
(e.g. a stream-based model or datagram model). This flexibility (e.g. a stream-based model or datagram model). This flexibility
brings new security issues that must be carefully understood when brings new security issues that must be carefully understood when
designing Upper Layer Protocols (ULPs) utilizing RDMA and when designing Upper Layer Protocols (ULPs) utilizing RDMA and when
implementing RDMA-aware NICs (RNICs). Note that for the purposes implementing RDMA-aware NICs (RNICs). Note that for the purposes
of this security analysis, an RNIC may implement RDMAP and DDP, of this security analysis, an RNIC may implement RDMAP [RDMAP]
or just DDP. Also, a ULP may be an application or it may be a and DDP [DDP], or just DDP. Also, a ULP may be an application or
middleware library. it may be a middleware library.
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
[RFC2828] is used in this specification.
The document first develops an architectural model that is The document first develops an architectural model that is
relevant for the security analysis - it details components, relevant for the security analysis - it details components,
resources, and system properties that may be attacked in Section resources, and system properties that may be attacked in Section
2. The document uses Local Peer to represent the RDMA/DDP 2. The document uses Local Peer to represent the RDMA/DDP
protocol implementation on the local end of a Stream. The local protocol implementation on the local end of a Stream (implemented
Upper-Layer-Protocol (ULP) is used to represent the application with a transport protocol such as [RFC793] or [RFC2960]). The
or middle-ware layer above the Local Peer. The document does not local Upper-Layer-Protocol (ULP) is used to represent the
attempt to differentiate between a Remote Peer and a Remote ULP application or middle-ware layer above the Local Peer. The
(an RDMA/DDP protocol implementation on the remote end of a document does not attempt to differentiate between a Remote Peer
Stream versus the application on the remote end) for several and a Remote ULP (an RDMA/DDP protocol implementation on the
reasons: often the source of the attack is difficult to know for remote end of a Stream versus the application on the remote end)
sure; and regardless of the source, the mitigations required of for several reasons: often the source of the attack is difficult
the Local Peer or local ULP are the same. Thus the document to know for sure; and regardless of the source, the mitigations
generically refers to a Remote Peer rather than trying to further required of the Local Peer or local ULP are the same. Thus the
delineate the attacker. document generically refers to a Remote Peer rather than trying
to further delineate the attacker.
The document then defines what resources a local ULP may share The document then defines what resources a local ULP may share
across Streams and what resources the local ULP may share with across Streams and what resources the local ULP may share with
the Remote Peer across Streams in Section 3. the Remote Peer across Streams in Section 3.
Intentional sharing of resources between multiple Streams may Intentional sharing of resources between multiple Streams may
imply some level of trust between the Streams. However, some imply some level of trust between the Streams. However, some
types of resource sharing have unmitigated security attacks which types of resource sharing have unmitigated security attacks which
would mandate not sharing a specific type of resource unless would mandate not sharing a specific type of resource unless
there is some level of trust between the Streams sharing there is some level of trust between the Streams sharing
skipping to change at page 5, line 17 skipping to change at page 5, line 23
face of a deliberate attack by its peer. For example, a single face of a deliberate attack by its peer. For example, a single
ULP that concurrently supports multiple unrelated Streams (e.g. a ULP that concurrently supports multiple unrelated Streams (e.g. a
server) would presumably treat each of its peers as an untrusted server) would presumably treat each of its peers as an untrusted
peer. For a collection of Streams which share Partial Mutual peer. For a collection of Streams which share Partial Mutual
Trust, the assumption is that any Stream not in the collection is Trust, the assumption is that any Stream not in the collection is
untrusted. For the untrusted peer, a brief list of capabilities untrusted. For the untrusted peer, a brief list of capabilities
is enumerated in Section 4. is enumerated in Section 4.
The rest of the document is focused on analyzing attacks and The rest of the document is focused on analyzing attacks and
recommending specific mitigations to the attacks. Attacks are recommending specific mitigations to the attacks. Attacks are
categorized into attacks mitigated by LLP mechanisms, attacks categorized into attacks mitigated by end-to-end security,
initiated by Remote Peers, and attacks initiated by Local Peers. attacks initiated by Remote Peers, and attacks initiated by Local
For each attack, possible countermeasures are reviewed. Peers. For each attack, possible countermeasures are reviewed.
ULPs within a host are divided into two categories - Privileged ULPs within a host are divided into two categories - Privileged
and Non-Privileged. Both ULP types can send and receive data and and Non-Privileged. Both ULP types can send and receive data and
request resources. The key differences between the two are: request resources. The key differences between the two are:
The Privileged ULP is trusted by the local system to not The Privileged ULP is trusted by the local system to not
maliciously attack the operating environment, but it is not maliciously attack the operating environment, but it is not
trusted to optimize resource allocation globally. For trusted to optimize resource allocation globally. For
example, the Privileged ULP could be a kernel ULP, thus the example, the Privileged ULP could be a kernel ULP, thus the
kernel presumably has in some way vetted the ULP before kernel presumably has in some way vetted the ULP before
allowing it to execute. allowing it to execute.
A Non-Privileged ULP's capabilities are a logical sub-set of A Non-Privileged ULP's capabilities are a logical sub-set of
the Privileged ULP's. It is assumed by the local system that the Privileged ULP's. It is assumed by the local system that
a Non-Privileged ULP is untrusted. All Non-Privileged ULP a Non-Privileged ULP is untrusted. All Non-Privileged ULP
interactions with the RNIC Engine that could affect other interactions with the RNIC Engine that could affect other
ULPs need to be done through a trusted intermediary that can ULPs need to be done through a trusted intermediary that can
verify the Non-Privileged ULP requests. verify the Non-Privileged ULP requests.
If all recommended mitigations are in place the implemented usage The appendices provide focused summaries of this specification.
models, the RDMAP/DDP protocol can be shown to not expose any new Section 11 Appendix A: ULP Issues for RDDP Client/Server
security vulnerabilities. Protocols focuses on implementers of traditional client/server
protocols. Section 12 Appendix B: Summary of RNIC and ULP
Implementation Requirements summarizes all normative requirements
in this specification. Section 13 Appendix C: Partial Trust
Taxonomy provides an abstract model for categorizing trust
boundaries.
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.
2 Architectural Model 2 Architectural Model
This section describes an RDMA architectural reference model that This section describes an RDMA architectural reference model that
is used as security issues are examined. It introduces the is used as security issues are examined. It introduces the
components of the model, the resources that can be attacked, the components of the model, the resources that can be attacked, the
types of interactions possible between components and resources, types of interactions possible between components and resources,
and the system properties which must be preserved. and the system properties which must be preserved.
Figure 1 shows the components comprising the architecture and the Figure 1 shows the components comprising the architecture and the
skipping to change at page 6, line 29 skipping to change at page 7, line 29
capabilities which affect threat analysis, and not focus on capabilities which affect threat analysis, and not focus on
specific implementation options. Also note that the architectural specific implementation options. Also note that the architectural
model is an abstraction, and an actual implementation may choose model is an abstraction, and an actual implementation may choose
to subdivide its components along different boundary lines than to subdivide its components along different boundary lines than
defined here. For example, the Privileged Resource Manager may be defined here. For example, the Privileged Resource Manager may be
partially or completely encapsulated in the Privileged ULP. partially or completely encapsulated in the Privileged ULP.
Regardless, it is expected that the security analysis of the Regardless, it is expected that the security analysis of the
potential threats and countermeasures still apply. potential threats and countermeasures still apply.
Note that the model below is derived from several specific RDMA Note that the model below is derived from several specific RDMA
implementations. A few of note is [VERBS-RDMAC], [VERBS-RDMAC- implementations. A few of note are [VERBS-RDMAC], [VERBS-RDMAC-
Overview], and [INFINIBAND]. Overview], and [INFINIBAND].
+-------------+ +-------------+
| Privileged | | Privileged |
| Resource | | Resource |
Admin<-+>| Manager | ULP Control Interface Admin<-+>| Manager | ULP Control Interface
| | |<------+-------------------+ | | |<------+-------------------+
| +-------------+ | | | +-------------+ | |
| ^ v v | ^ v v
| | +-------------+ +-----------------+ | | +-------------+ +-----------------+
|---------------->| Privileged | | Non-Privileged | +---------------->| Privileged | | Non-Privileged |
| | ULP | | ULP | | | ULP | | ULP |
| +-------------+ +-----------------+ | +-------------+ +-----------------+
| ^ ^ | ^ ^
|Privileged |Privileged |Non-Privileged |Privileged |Privileged |Non-Privileged
|Control |Data |Data |Control |Data |Data
|Interface |Interface |Interface |Interface |Interface |Interface
RNIC | | | RNIC | | |
Interface v v v Interface v v v
================================================================= =================================================================
skipping to change at page 8, line 18 skipping to change at page 9, line 18
definition of Non-Privileged ULP. definition of Non-Privileged ULP.
A design goal of the DDP and RDMAP protocols is to allow, under A design goal of the DDP and RDMAP protocols is to allow, under
constrained conditions, Non-Privileged ULP to send and receive constrained conditions, Non-Privileged ULP to send and receive
data directly to/from the RDMA Engine without Privileged Resource data directly to/from the RDMA Engine without Privileged Resource
Manager intervention - while ensuring that the host remains Manager intervention - while ensuring that the host remains
secure. Thus, one of the primary goals of this document is to secure. Thus, one of the primary goals of this document is to
analyze this usage model for the enforcement that is required in analyze this usage model for the enforcement that is required in
the RNIC Engine to ensure the system remains secure. the RNIC Engine to ensure the system remains secure.
DDP supports both untagged and tagged buffers. Tagged buffers DDP provides two mechanisms for transferring data:
allow the Data Sink ULP to be indifferent to what order (or in
what messages) the Data Source sent the data, or what order
packets are received in. Typically tagged data can be used for
payload transfer, while untagged is best used for control
messages. However each upper layer protocol can determine the
optimal use of tagged and untagged messages for itself. This
document will discuss when Data Source flexibility is of benefit
to applications
Note that in DDP there are two mechanisms for transferring data.
These two data transfer mechanisms are also enabled through
RDMAP, with additional control semantics:
* Untagged data transfer - the Data Source payload simply * Untagged Data Transfer - the incoming payload simply
consumes the first buffer in a queue of buffers that are consumes the first buffer in a queue of buffers that are
in Data Sink specified order (commonly referred to as the in the order specified by the receiving Peer (commonly
Receive Queue), and referred to as the Receive Queue), and
* Tagged data transfer - the Data Source explicitly states * Tagged Data Transfer - the Peer transmitting the payload
which destination buffer is targeted, through use of an explicitly states which destination buffer is targeted,
STag. STag based transfers allow the Data Sink ULP to be through use of an STag. STag based transfers allow the
indifferent to what order (or in what messages) the Data receiving ULP to be indifferent to what order (or in what
Source sent the data, or what order packets are received messages) the opposite Peer sent the data, or what order
in. packets are received in.
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.
For DDP the two forms correspond to Untagged and Tagged DDP For DDP the two forms correspond to Untagged and Tagged DDP
Messages, respectively. For RDMAP the two forms correspond to Messages, respectively. For RDMAP the two forms correspond to
Send Type Messages and RDMA Messages (either RDMA Read or RDMA Send Type Messages and RDMA Messages (either RDMA Read or RDMA
Write Messages), respectively. Typically tagged data can be used Write Messages), respectively.
for payload transfer, while untagged 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.
The host interfaces that could be exercised include: The host interfaces that could be exercised include:
* Privileged Control Interface - A Privileged Resource * Privileged Control Interface - A Privileged Resource
Manager uses the RNIC Interface to allocate and manage Manager uses the RNIC Interface to allocate and manage
RNIC Engine resources, control the state within the RNIC RNIC Engine resources, control the state within the RNIC
Engine, and monitor various events from the RNIC Engine. Engine, and monitor various events from the RNIC Engine.
It also uses this interface to act as a proxy for some It also uses this interface to act as a proxy for some
operations that a Non-Privileged ULP may require (after operations that a Non-Privileged ULP may require (after
performing appropriate countermeasures). performing appropriate countermeasures).
* ULP Control Interface - An ULP uses this interface to the * ULP Control Interface - A ULP uses this interface to the
Privileged Resource Manager to allocate RNIC Engine Privileged Resource Manager to allocate RNIC Engine
resources. The Privileged Resource Manager implements resources. The Privileged Resource Manager implements
countermeasures to ensure that if the Non-Privileged ULP countermeasures to ensure that if the Non-Privileged ULP
launches an attack it can prevent the attack from launches an attack it can prevent the attack from
affecting other ULPs. affecting other ULPs.
* Non-Privileged Data Transfer Interface - A Non-Privileged * Non-Privileged Data Transfer Interface - A Non-Privileged
ULP uses this interface to initiate and to check the ULP uses this interface to initiate and to check the
status of data transfer operations. status of data transfer operations.
skipping to change at page 9, line 51 skipping to change at page 10, line 43
2.2.1 Stream Context Memory 2.2.1 Stream Context Memory
The state information for each Stream is maintained in memory, The state information for each Stream is maintained in memory,
which could be located in a number of places - on the NIC, inside 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 RAM attached to the NIC, in host memory, or in any combination of
the three, depending on the implementation. the three, depending on the implementation.
Stream Context Memory includes state associated with Data Stream Context Memory includes state associated with Data
Buffers. For Tagged Buffers, this includes how STag names, Data Buffers. For Tagged Buffers, this includes how STag names, Data
Buffers, and Page Translation Tables (see section 2.2.3) Buffers, and Page Translation Tables (see Section 2.2.3)
interrelate. It also includes the list of Untagged Data Buffers interrelate. It also includes the list of Untagged Data Buffers
posted for reception of Untagged Messages (commonly called the posted for reception of Untagged Messages (commonly called the
Receive Queue), and a list of operations to perform to send data Receive Queue), and a list of operations to perform to send data
(commonly called the Send Queue). (commonly called the Send Queue).
2.2.2 Data Buffers 2.2.2 Data Buffers
As mentioned previously, there are two different ways to expose a As mentioned previously, there are two different ways to expose a
local ULP's data buffers for data transfer; Untagged Data local ULP's data buffers for data transfer; Untagged Data
Transfer - a buffer can be exposed for receiving RDMAP Send Type Transfer - a buffer can be exposed for receiving RDMAP Send Type
skipping to change at page 11, line 11 skipping to change at page 11, line 54
address) of a buffer to the physical addresses that are used by address) of a buffer to the physical addresses that are used by
the RNIC Engine to move data. If on a specific system a mapping 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 is not used, then a subset of the attacks examined may be
appropriate. Note that the Page Translation Table may or may not appropriate. Note that the Page Translation Table may or may not
be a shared resource. be a shared resource.
2.2.4 Protection Domain (PD) 2.2.4 Protection Domain (PD)
A Protection Domain (PD) is a local construct to the RDMA A Protection Domain (PD) is a local construct to the RDMA
implementation, and never visible over the wire. Protection implementation, and never visible over the wire. Protection
Domains are assigned to two of the resources of concern, Stream Domains are assigned to three of the resources of concern -
Context Memory and STags associated with Page Translation Table Stream Context Memory, STags associated with Page Translation
entries and data buffers. A correct implementation of a Table entries, and data buffers. A correct implementation of a
Protection Domain requires that resources which belong to a given Protection Domain requires that resources which belong to a given
Protection Domain can not be used on a resource belonging to Protection Domain can not be used on a resource belonging to
another Protection Domain, because Protection Domain membership another Protection Domain, because Protection Domain membership
is checked by the RNIC prior to taking any action involving such is checked by the RNIC prior to taking any action involving such
a resource. Protection Domains are therefore used to ensure that a resource. Protection Domains are therefore used to ensure that
an STag can only be used to access an associated data buffer on an STag can only be used to access an associated data buffer on
one or more Streams that are associated with the same Protection one or more Streams that are associated with the same Protection
Domain as the specific STag. Domain as the specific STag.
If an implementation chooses to not share resources between If an implementation chooses to not share resources between
skipping to change at page 13, line 24 skipping to change at page 14, line 13
multiple Streams. multiple Streams.
2.3 RNIC Interactions 2.3 RNIC Interactions
With RNIC resources and interfaces defined, it is now possible to With RNIC resources and interfaces defined, it is now possible to
examine the interactions supported by the generic RNIC functional examine the interactions supported by the generic RNIC functional
interfaces through each of the 3 interfaces - Privileged Control interfaces through each of the 3 interfaces - Privileged Control
Interface, Privileged Data Interface, and Non-Privileged Data Interface, Privileged Data Interface, and Non-Privileged Data
Interface. As mentioned previously in Section 2.1 Components, Interface. As mentioned previously in Section 2.1 Components,
there are two data transfer mechanisms to be examined - Untagged there are two data transfer mechanisms to be examined - Untagged
data transfer and Tagged data transfer. Data Transfer and Tagged Data Transfer.
2.3.1 Privileged Control Interface Semantics 2.3.1 Privileged Control Interface Semantics
Generically, the Privileged Control Interface controls the RNIC's Generically, the Privileged Control Interface controls the RNIC's
allocation, deallocation, and initialization of RNIC global allocation, de-allocation, and initialization of RNIC global
resources. This includes allocation and deallocation of Stream resources. This includes allocation and de-allocation of Stream
Context Memory, Page Translation Tables, STag names, Completion Context Memory, Page Translation Tables, STag names, Completion
Queues, RDMA Read Request Queues, and Asynchronous Event Queues. Queues, RDMA Read Request Queues, and Asynchronous Event Queues.
The Privileged Control Interface is also typically used for The Privileged Control Interface is also typically used for
managing Non-Privileged ULP resources for the Non-Privileged ULP managing Non-Privileged ULP resources for the Non-Privileged ULP
(and possibly for the Privileged ULP as well). This includes (and possibly for the Privileged ULP as well). This includes
initialization and removal of Page Translation Table resources, initialization and removal of Page Translation Table resources,
and managing RNIC events (possibly managing all events for the and managing RNIC events (possibly managing all events for the
Asynchronous Event Queue). Asynchronous Event Queue).
skipping to change at page 13, line 52 skipping to change at page 14, line 41
The Non-Privileged Data Interface enables data transfer (transmit The Non-Privileged Data Interface enables data transfer (transmit
and receive) but does not allow initialization of the Page and receive) but does not allow initialization of the Page
Translation Table resources. However, once the Page Translation Translation Table resources. However, once the Page Translation
Table resources have been initialized, the interface may enable a Table resources have been initialized, the interface may enable a
specific STag mapping to be enabled and disabled by directly specific STag mapping to be enabled and disabled by directly
communicating with the RNIC, or create an STag mapping for a communicating with the RNIC, or create an STag mapping for a
buffer that has been previously initialized in the RNIC. buffer that has been previously initialized in the RNIC.
For RDMAP, ULP data can be sent by one of the previously For RDMAP, ULP data can be sent by one of the previously
described data transfer mechanisms - Untagged data transfer or described data transfer mechanisms - Untagged Data Transfer or
Tagged Data Transfer. Three RDMAP data transfer mechanisms are Tagged Data Transfer. Two RDMAP data transfer mechanisms are
defined, one using Untagged data transfer (Send Type Messages), defined, one using Untagged Data Transfer (Send Type Messages),
and one using Tagged data transfer (RDMA Read Responses and RDMA and one using Tagged Data Transfer (RDMA Read Responses and RDMA
Writes). ULP data reception through RDMAP can be done by Writes). ULP data reception through RDMAP can be done by
receiving Send Type Messages into buffers that have been posted receiving Send Type Messages into buffers that have been posted
on the Receive Queue or Shared Receive Queue. Thus a Receive on the Receive Queue or Shared Receive Queue. Thus a Receive
Queue or Shared Receive Queue can only be affected by Untagged Queue or Shared Receive Queue can only be affected by Untagged
data transfer. Data reception can also be done by receiving RDMA Data Transfer. Data reception can also be done by receiving RDMA
Write and RDMA Read Response Messages into buffers that have Write and RDMA Read Response Messages into buffers that have
previously been exposed for external write access through previously been exposed for external write access through
advertisement of an STag (i.e. Tagged data transfer). advertisement of an STag (i.e. Tagged Data Transfer).
Additionally, to cause ULP data to be pulled (read) across the Additionally, to cause ULP data to be pulled (read) across the
network, RDMAP uses an RDMA Read Request Message (which only network, RDMAP uses an RDMA Read Request Message (which only
contains RDMAP control information necessary to access the ULP contains RDMAP control information necessary to access the ULP
buffer to be read), to cause an RDMA Read Response Message to be buffer to be read), to cause an RDMA Read Response Message to be
generated that contains the ULP data. generated that contains the ULP data.
For DDP, transmitting data means sending DDP Tagged or Untagged For DDP, transmitting data means sending DDP Tagged or Untagged
Messages. For data reception, for DDP it can receive Untagged Messages. For data reception, DDP can receive Untagged Messages
Messages into buffers that have been posted on the Receive Queue into buffers that have been posted on the Receive Queue or Shared
or Shared Receive Queue. It can also receive Tagged DDP Messages Receive Queue. It can also receive Tagged DDP Messages into
into buffers that have previously been exposed for external write buffers that have previously been exposed for external write
access through advertisement of an STag. access through advertisement of an STag.
Completion of data transmission or reception generally entails Completion of data transmission or reception generally entails
informing the ULP of the completed work by placing completion informing the ULP of the completed work by placing completion
information on the Completion Queue. For data reception, only an information on the Completion Queue. For data reception, only an
Untagged data transfer can cause completion information to be put Untagged Data Transfer can cause completion information to be put
in the Completion Queue. in the Completion Queue.
2.3.3 Privileged Data Interface Semantics 2.3.3 Privileged Data Interface Semantics
The Privileged Data Interface semantics are a superset of the The Privileged Data Interface semantics are a superset of the
Non-Privileged Data Transfer semantics. The interface can do Non-Privileged Data Transfer semantics. The interface can do
everything defined in the prior section, as well as everything defined in the prior section, as well as
create/destroy buffer to STag mappings directly. This generally create/destroy buffer to STag mappings directly. This generally
entails initialization or clearing of Page Translation Table entails initialization or clearing of Page Translation Table
state in the RNIC. state in the RNIC.
skipping to change at page 14, line 53 skipping to change at page 15, line 43
a. Initialization of the allocated Page Translation Table a. Initialization of the allocated Page Translation Table
entries with the location of the Data Buffer, and entries with the location of the Data Buffer, and
b. Initialization of a mapping from an allocated STag name b. Initialization of a mapping from an allocated STag name
to a set of Page Translation Table entry(s) or partial- to a set of Page Translation Table entry(s) or partial-
entries. entries.
Note that an implementation may not have a Page Translation Table 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 (i.e. it may support a direct mapping between an STag and a Data
Buffer). In this case threats and mitigations associated with the Buffer). If there is no Page Translation Table, then attacks
Page Translation Table are not relevant. based on changing its contents or exhausting its resources are
not possible.
Initialization of the contents of the Page Translation Table can Initialization of the contents of the Page Translation Table can
be done by either the Privileged ULP or by the Privileged be done by either the Privileged ULP or by the Privileged
Resource Manager as a proxy for the Non-Privileged ULP. By Resource Manager as a proxy for the Non-Privileged ULP. By
definition the Non-Privileged ULP is not trusted to directly definition the Non-Privileged ULP is not trusted to directly
manipulate the Page Translation Table. In general the concern is manipulate the Page Translation Table. In general the concern is
that the Non-Privileged ULP may try to maliciously initialize the that the Non-Privileged ULP may try to maliciously initialize the
Page Translation Table to access a buffer for which it does not Page Translation Table to access a buffer for which it does not
have permission. have permission.
The exact resource allocation algorithm for the Page Translation The exact resource allocation algorithm for the Page Translation
Table is outside the scope of this document. It may be allocated Table is outside the scope of this document. It may be allocated
for a specific Data Buffer, or be allocated as a pooled resource for a specific Data Buffer, or be allocated as a pooled resource
to be consumed by potentially multiple Data Buffers, or be to be consumed by potentially multiple Data Buffers, or be
managed in some other way. This document attempts to abstract managed in some other way. This document attempts to abstract
implementation dependent issues, and group them into higher level implementation dependent issues, and group them into higher level
security issues such as resource starvation and sharing of security issues such as resource starvation and sharing of
resources between Streams. resources between Streams.
The next issue is how an STag name is associated with a Data The next issue is how an STag name is associated with a Data
Buffer. For the case of an Untagged Data Buffer, there is no wire Buffer. For the case of an Untagged Data Buffer (i.e. Untagged
visible mapping between an STag and the Data Buffer. Note that Data Transfer), there is no wire visible mapping between an STag
there may, in fact, be an STag which represents the buffer, if an and the Data Buffer. Note that there may, in fact, be an STag
implementation chooses to internally represent Untagged Data which represents the buffer, if an implementation chooses to
Buffer using STags. However, because the STag by definition is internally represent Untagged Data Buffer using STags. However,
not visible on the wire, this is a local host implementation because the STag by definition is not visible on the wire, this
specific issue which should be analyzed in the context of a local is a local host implementation specific issue which should be
host implementation specific security analysis, and thus is analyzed in the context of a local host implementation specific
outside the scope of this document. security analysis, and thus is outside the scope of this
document.
For a Tagged Data Buffer, either the Privileged ULP or the For a Tagged Data Buffer (i.e. Tagged Data Transfer), either the
Privileged Resource Manager acting on behalf of the Non- Privileged ULP or the Privileged Resource Manager acting on
Privileged ULP may initialize a mapping from an STag to a Page behalf of the Non-Privileged ULP may initialize a mapping from an
Translation Table, or may have the ability to simply STag to a Page Translation Table, or may have the ability to
enable/disable an existing STag to Page Translation Table simply enable/disable an existing STag to Page Translation Table
mapping. There may also be multiple STag names which map to a mapping. There may also be multiple STag names which map to a
specific group of Page Translation Table entries (or sub- specific group of Page Translation Table entries (or sub-
entries). Specific security issues with this level of flexibility entries). Specific security issues with this level of flexibility
are examined in Section 6.2.3 Multiple STags to access the same are examined in Section 6.2.3 Multiple STags to access the same
buffer. buffer.
There are a variety of implementation options for initialization 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 and mapping an STag to a group
of Page Translation Table entries which have security of Page Translation Table entries which have security
repercussions. This includes support for separation of Mapping an repercussions. This includes support for separation of Mapping an
skipping to change at page 16, line 21 skipping to change at page 17, line 9
ULP to post multiple operation requests to send data (referred to ULP to post multiple operation requests to send data (referred to
as the Send Queue). Depending upon the implementation, Data as the Send Queue). Depending upon the implementation, Data
Buffers used in the operations may or may not have Page Buffers used in the operations may or may not have Page
Translation Table entries associated with them, and may or may Translation Table entries associated with them, and may or may
not have STags associated with them. Because this is a local host not have STags associated with them. Because this is a local host
specific implementation issue rather than a protocol issue, the specific implementation issue rather than a protocol issue, the
security analysis of threats and mitigations is left to the host security analysis of threats and mitigations is left to the host
implementation. implementation.
Receive operations are different for Tagged Data Buffers versus Receive operations are different for Tagged Data Buffers versus
Untagged Data Buffers (i.e. Tagged data transfer vs. Untagged Untagged Data Buffers (i.e. Tagged Data Transfer vs. Untagged
data transfer). For Untagged data transfer, if more than one Data Transfer). For Untagged Data Transfer, if more than one
Untagged Data Buffer can be posted by the ULP, the DDP Untagged Data Buffer can be posted by the ULP, the DDP
specification requires that they be consumed in sequential order specification requires that they be consumed in sequential order
(the RDMAP specification also requires this). Thus the most (the RDMAP specification also requires this). Thus the most
general implementation is that there is a sequential queue of general implementation is that there is a sequential queue of
receive Untagged Data Buffers (Receive Queue). Some receive Untagged Data Buffers (Receive Queue). Some
implementations may also support sharing of the sequential queue implementations may also support sharing of the sequential queue
between multiple Streams. In this case defining "sequential" between multiple Streams. In this case defining "sequential"
becomes non-trivial - in general the buffers for a single Stream becomes non-trivial - in general the buffers for a single Stream
are consumed from the queue in the order that they were placed on are consumed from the queue in the order that they were placed on
the queue, but there is no consumption order guarantee between the queue, but there is no consumption order guarantee between
Streams. Streams.
For receive Tagged data transfer (i.e. Tagged Data Buffers, RDMA For receive Tagged Data Transfer (i.e. Tagged Data Buffers, RDMA
Write Buffers, or RDMA Read Buffers), at some time prior to data Write Buffers, or RDMA Read Buffers), at some time prior to data
transfer, the mapping of the STag to specific Page Translation transfer, the mapping of the STag to specific Page Translation
Table entries (if present) and the mapping from the Page Table entries (if present) and the mapping from the Page
Translation Table entries to the Data Buffer must have been Translation Table entries to the Data Buffer must have been
initialized (see section 2.3.4 for interaction details). initialized (see Section 2.3.4 for interaction details).
3 Trust and Resource Sharing 3 Trust and Resource Sharing
It is assumed that in general the Local and Remote Peer are It is assumed that in general the Local and Remote Peer are
untrusted, and thus attacks by either should have mitigations in untrusted, and thus attacks by either should have mitigations in
place. place.
A separate, but related issue is resource sharing between A separate, but related issue is resource sharing between
multiple Streams. If local resources are not shared, the multiple Streams. If local resources are not shared, the
resources are dedicated on a per Stream basis. Resources are resources are dedicated on a per Stream basis. Resources are
skipping to change at page 19, line 17 skipping to change at page 20, line 17
This section describes the RDMAP/DDP attacks where the only This section describes the RDMAP/DDP attacks where the only
solution is to implement some form of end-to-end security. The solution is to implement some form of end-to-end security. The
analysis includes a detailed description of each attack, what is analysis includes a detailed description of each attack, what is
being attacked, and a description of the countermeasures that can being attacked, and a description of the countermeasures that can
be taken to thwart the attack. be taken to thwart the attack.
Some forms of attack involve modifying the RDMAP or DDP payload Some forms of attack involve modifying the RDMAP or DDP payload
by a network based attacker or involve monitoring the traffic to by a network based attacker or involve monitoring the traffic to
discover private information. An effective tool to ensure discover private information. An effective tool to ensure
confidentiality is to encrypt the data stream through mechanisms confidentiality is to encrypt the data stream through mechanisms
such as IPsec encryption. An effective tool to ensure the remote such as IPsec encryption. Additionally, authentication protocols
entity is who they claim to be as well as ensuring that the such as IPsec authentication are an effective tool to ensure the
payload is unmodified as it traverses the network is the use of remote entity is who they claim to be as well as ensuring that
authentication protocols such as IPSec Authentication. the payload is unmodified as it traverses the network.
Note that connection setup and teardown is presumed to be done in Note that connection setup and teardown is presumed to be done in
stream mode (i.e. no RDMA encapsulation of the payload), so there stream mode (i.e. no RDMA encapsulation of the payload), so there
are no new attacks related to connection setup/teardown beyond are no new attacks related to connection setup/teardown beyond
what is already present in the LLP (e.g. TCP or SCTP). Note, what is already present in the LLP (e.g. TCP or SCTP). Note,
however, that RDMAP/DDP parameters may be exchanged in stream however, that RDMAP/DDP parameters may be exchanged in stream
mode, and if they are corrupted by an attacker unintended mode, and if they are corrupted by an attacker unintended
consequences will result. Therefore, any existing mitigations for consequences will result. Therefore, any existing mitigations for
LLP Spoofing, Tampering, Repudiation, Information Disclosure, LLP Spoofing, Tampering, Repudiation, Information Disclosure,
Denial of Service, or Elevation of Privilege continue to apply Denial of Service, or Elevation of Privilege continue to apply
skipping to change at page 19, line 54 skipping to change at page 20, line 54
network based attacker. A network based spoofing attack applies network based attacker. A network based spoofing attack applies
to all Remote Peers. This section analyzes the various types of to all Remote Peers. This section analyzes the various types of
spoofing attacks applicable to RDMAP & DDP. spoofing attacks applicable to RDMAP & DDP.
5.1.1 Impersonation 5.1.1 Impersonation
A network based attacker can impersonate a legal RDMAP/DDP Peer A network based attacker can impersonate a legal RDMAP/DDP Peer
(by spoofing a legal IP address). This can either be done as a (by spoofing a legal IP address). This can either be done as a
blind attack (see [RFC3552]) or by establishing an RDMAP/DDP blind attack (see [RFC3552]) or by establishing an RDMAP/DDP
Stream with the victim. Because an RDMAP/DDP Stream requires an Stream with the victim. Because an RDMAP/DDP Stream requires an
LLP Stream to be fully initialized (e.g. for [TCP] it is in the LLP Stream to be fully initialized (e.g. for [RFC793] it is in
ESTABLISHED state), existing transport layer protection the ESTABLISHED state), existing transport layer protection
mechanisms against blind attacks remain in place. mechanisms against blind attacks remain in place.
For a blind attack to succeed, it requires the attacker to inject 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 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 least the 4-tuple as well as guess a sequence number within the
window) while also guessing valid RDMAP or DDP parameters. There window) while also guessing valid RDMAP or DDP parameters. There
are many ways to attack the RDMAP/DDP protocol if the transport are many ways to attack the RDMAP/DDP protocol if the transport
protocol is assumed to be vulnerable. For example, for Tagged protocol is assumed to be vulnerable. For example, for Tagged
Messages, this entails guessing the STag and TO values. If the Messages, this entails guessing the STag and TO values. If the
attacker wishes to simply terminate the connection, it can do so attacker wishes to simply terminate the connection, it can do so
skipping to change at page 22, line 11 skipping to change at page 23, line 11
integrity against a specific attack depend on whether the integrity against a specific attack depend on whether the
authentication is machine level authentication (such as IPsec), authentication is machine level authentication (such as IPsec),
or ULP authentication. or ULP authentication.
5.4.1 Introduction to Security Options 5.4.1 Introduction to Security Options
The following security services can be applied to an RDMAP/DDP The following security services can be applied to an RDMAP/DDP
Stream: Stream:
1. Session confidentiality - protects against eavesdropping 1. Session confidentiality - protects against eavesdropping
(section 5.3). (Section 5.3).
2. Per-packet data source authentication - protects against the 2. Per-packet data source authentication - protects against the
following spoofing attacks: network based impersonation following spoofing attacks: network based impersonation
(section 5.1.1), Stream hijacking (section 5.1.2), and man in (Section 5.1.1), Stream hijacking (Section 5.1.2), and man in
the middle (section 5.1.3). the middle (Section 5.1.3).
3. Per-packet integrity - protects against tampering done by 3. Per-packet integrity - protects against tampering done by
network based modification of buffer content (section 5.2) network based modification of buffer content (Section 5.2)
4. Packet sequencing - protects against replay attacks, which is 4. Packet sequencing - protects against replay attacks, which is
a special case of the above tampering attack. a special case of the above tampering attack.
If an RDMAP/DDP Stream may be subject to impersonation attacks, If an RDMAP/DDP Stream may be subject to impersonation attacks,
or Stream hijacking attacks, it is recommended that the Stream be or Stream hijacking attacks, it is recommended that the Stream be
authenticated, integrity protected, and protected from replay authenticated, integrity protected, and protected from replay
attacks; it may use confidentiality protection to protect from attacks; it may use confidentiality protection to protect from
eavesdropping (in case the RDMAP/DDP Stream traverses a public eavesdropping (in case the RDMAP/DDP Stream traverses a public
network). network).
skipping to change at page 22, line 46 skipping to change at page 23, line 46
the key management protocol while AH and ESP are used to protect the key management protocol while AH and ESP are used to protect
IP traffic. Please see those RFCs for a complete description of IP traffic. Please see those RFCs for a complete description of
the respective protocols. the respective protocols.
IPsec is capable of providing the above security services for IP IPsec is capable of providing the above security services for IP
and TCP traffic respectively. ULP protocols are able to provide and TCP traffic respectively. ULP protocols are able to provide
only part of the above security services. only part of the above security services.
5.4.2 TLS is Inappropriate for DDP/RDMAP Security 5.4.2 TLS is Inappropriate for DDP/RDMAP Security
TLS [RFC 2246] provide Stream authentication, integrity and TLS [RFC 2246] provides Stream authentication, integrity and
confidentiality for TCP based ULPs. TLS supports one-way (server confidentiality for TCP based ULPs. TLS supports one-way (server
only) or mutual certificates based authentication. only) or mutual certificates based authentication.
There are at least two limitations that make TLS underneath RDMAP If TLS is layered underneath RDMAP, there are at least two
inappropriate for DDP/RDMA security: limitations that make TLS inappropriate for DDP/RDMA security:
1. The maximum length supported by the TLS record layer protocol 1. The maximum length supported by the TLS record layer protocol
is 2^14 bytes - longer packets must be fragmented (as a is 2^14 bytes - longer packets must be fragmented (as a
comparison, the maximum length of an Untagged DDP Message is comparison, the maximum length of an Untagged DDP Message is
roughly 2^32). roughly 2^32).
2. TLS is a connection oriented protocol. If a stream cipher or 2. TLS is a connection oriented protocol. If a stream cipher or
block cipher in CBC mode is used for bulk encryption, then a block cipher in CBC mode is used for bulk encryption, then a
packet can be decrypted only after all the packets preceding packet can be decrypted only after all the packets preceding
it have already arrived. If TLS is used to protect DDP/RDMAP it have already arrived. If TLS is used to protect DDP/RDMAP
traffic, then TLS must gather all out-of-order packets before traffic, then TCP must gather all out-of-order packets before
RDMAP/DDP can place them into the ULP buffer. Thus one of the TLS can decrypt them. Only after this is done can RDMAP/DDP
primary features of DDP/RDMAP - enabling implementations to place them into the ULP buffer. Thus one of the primary
have a flow-through architecture with little to no buffering, features of DDP/RDMAP - enabling implementations to have a
can not be achieved if TLS is used to protect the data flow-through architecture with little to no buffering, can
stream. not be achieved if TLS is used to protect the data stream.
If TLS is layered on top of RDMAP or DDP, TLS does not protect 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 the RDMAP and/or DDP headers. Thus a man-in-the-middle attack can
still occur by modifying the RDMAP/DDP header to incorrectly still occur by modifying the RDMAP/DDP header to incorrectly
place the data into the wrong buffer, thus effectively corrupting place the data into the wrong buffer, thus effectively corrupting
the data stream. the data stream.
For these reasons, it is NOT RECOMMENDED that TLS be layered on For these reasons, it is NOT RECOMMENDED that TLS be layered on
top of RDMAP or DDP. top of RDMAP or DDP.
skipping to change at page 24, line 7 skipping to change at page 25, line 7
follow the requirements defined in RFC3723 Section 2.3 and follow the requirements defined in RFC3723 Section 2.3 and
Section 5, including the associated normative references for Section 5, including the associated normative references for
those sections. Note that this means that support for IPSEC ESP those sections. Note that this means that support for IPSEC ESP
mode is normative. mode is normative.
Additionally, since IPsec acceleration hardware may only be able Additionally, since IPsec acceleration hardware may only be able
to handle a limited number of active IKE Phase 2 SAs, Phase 2 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 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 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 IKE Phase 2 delete message MUST NOT be interpreted as a reason
for tearing down an DDP/RDMA Stream. Rather, it is preferable to 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 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 bring up another IKE Phase 2 SA to protect it. This avoids the
potential for continually bringing Streams up and down. potential for continually bringing Streams up and down.
Note that there are serious security issues if IPsec is not Note that there are serious security issues if IPsec is not
implemented end-to-end. For example, if IPsec is implemented as a implemented end-to-end. For example, if IPsec is implemented as a
tunnel in the middle of the network, any hosts between the Peer tunnel in the middle of the network, any hosts between the Peer
and the IPsec tunneling device can freely attack the unprotected and the IPsec tunneling device can freely attack the unprotected
Stream. Stream.
skipping to change at page 25, line 50 skipping to change at page 26, line 50
potentially be able to perform either RDMA Read Operations to potentially be able to perform either RDMA Read Operations to
read the contents of the associated data buffer, perform RDMA read the contents of the associated data buffer, perform RDMA
Write Operations to modify the contents of the associated data Write Operations to modify the contents of the associated data
buffer, or to invalidate the STag to disable further access to buffer, or to invalidate the STag to disable further access to
the buffer. the buffer.
An attempt by a Remote Peer to access a buffer with an STag on a 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 different Stream in the same Protection Domain may or may not be
an attack depending on whether resource sharing is intended (i.e. an attack depending on whether resource sharing is intended (i.e.
whether the Streams shared Partial Mutual Trust or not). For some whether the Streams shared Partial Mutual Trust or not). For some
ULPs using an STag on multiple Streams within the same Protection ULPs, using an STag on multiple Streams within the same
Domain could be desired behavior. For other ULPs attempting to Protection Domain could be desired behavior. For other ULPs,
use an STag on a different Stream could be considered to be an attempting to use an STag on a different Stream could be
attack. Since this varies by ULP, a ULP typically would need to considered to be an attack. Since this varies by ULP, a ULP
be able to control the scope of the STag. typically would need to be able to control the scope of the STag.
In the case where an implementation does not share resources In the case where an implementation does not share resources
between Streams (including STags), this attack can be defeated by between Streams (including STags), this attack can be defeated by
assigning each Stream to a different Protection Domain. Before assigning each Stream to a different Protection Domain. Before
allowing remote access to the buffer, the Protection Domain of allowing remote access to the buffer, the Protection Domain of
the Stream where the access attempt was made is matched against the Stream where the access attempt was made is matched against
the Protection Domain of the STag. If the Protection Domains do the Protection Domain of the STag. If the Protection Domains do
not match, access to the buffer is denied, an error is generated, not match, access to the buffer is denied, an error is generated,
and the RDMAP Stream associated with the attacking Stream is and the RDMAP Stream associated with the attacking Stream is
terminated. terminated.
skipping to change at page 27, line 56 skipping to change at page 28, line 56
Peer could force the ULP down operational paths that were never Peer could force the ULP down operational paths that were never
intended. intended.
The local ULP can protect itself from this type of attack by The local ULP can protect itself from this type of attack by
revoking remote access when the original data transfer has revoking remote access when the original data transfer has
completed and before it validates the contents of the buffer. The completed and before it validates the contents of the buffer. The
local ULP can either do this by explicitly revoking remote access local ULP can either do this by explicitly revoking remote access
rights for the STag when the Remote Peer indicates the operation rights for the STag when the Remote Peer indicates the operation
has completed, or by checking to make sure the Remote Peer has completed, or by checking to make sure the Remote Peer
invalidated the STag through the RDMAP Remote Invalidate invalidated the STag through the RDMAP Remote Invalidate
capability (see section 6.4.5 Remote Invalidate an STag Shared on capability (see Section 6.4.5 Remote Invalidate an STag Shared on
Multiple Streams for a definition of Remote Invalidate), and if Multiple Streams for a definition of Remote Invalidate), and if
it did not, the local ULP then explicitly revokes the STag remote it did not, the local ULP then explicitly revokes the STag remote
access rights. access rights.
The local ULP SHOULD follow the above procedure to protect the The local ULP SHOULD follow the above procedure to protect the
buffer before it validates the contents of the buffer (or uses buffer before it validates the contents of the buffer (or uses
the buffer in any way). the buffer in any way).
An RNIC MUST ensure that network packets using the STag for a An RNIC MUST ensure that network packets using the STag for a
previously advertised buffer can no longer modify the buffer previously advertised buffer can no longer modify the buffer
after the ULP revokes remote access rights for the specific STag. after the ULP revokes remote access rights for the specific STag.
6.2.3 Multiple STags to access the same buffer 6.2.3 Multiple STags to access the same buffer
See section 6.3.6 Using Multiple STags Which Alias to the Same See Section 6.3.6 Using Multiple STags Which Alias to the Same
Buffer for this analysis. Buffer for this analysis.
6.3 Information Disclosure 6.3 Information Disclosure
The main potential source for information disclosure is through a The main potential source for information disclosure is through a
local buffer that has been enabled for remote access. If the local buffer that has been enabled for remote access. If the
buffer can be probed by a Remote Peer on another Stream, then buffer can be probed by a Remote Peer on another Stream, then
there is potential for information disclosure. there is potential for information disclosure.
The potential attacks that could result in unintended information The potential attacks that could result in unintended information
disclosure and countermeasures are detailed in the following disclosure and countermeasures are detailed in the following
sections. sections.
6.3.1 Probing memory outside of the buffer bounds 6.3.1 Probing memory outside of the buffer bounds
This is essentially the same attack as described in Section This is essentially the same attack as described in Section 6.2.1
6.2.1, except an RDMA Read Request is used to mount the attack. Buffer Overrun - RDMA Write or Read Response, except an RDMA Read
The same countermeasure applies. Request is used to mount the attack. The same countermeasure
applies.
6.3.2 Using RDMA Read to Access Stale Data 6.3.2 Using RDMA Read to Access Stale Data
If a buffer is being used for a combination of reads and writes If a buffer is being used for some combination of reads and
(either remote or local), and is exposed to the Remote Peer with writes (either remote or local), and is exposed to a Remote Peer
at least remote read access rights, the Remote Peer may be able with at least remote read access rights before it is initialized
to examine the contents of the buffer before they are initialized with the correct data, there is a potential race condition where
with the correct data. In this situation, whatever contents were the Remote Peer can view the prior contents of the buffer. This
present in the buffer before the buffer is initialized can be becomes a security issue if the prior contents of the buffer were
viewed by the Remote Peer, if the Remote Peer performs an RDMA not intended to be shared with the Remote Peer.
Read.
Because of this, the local ULP SHOULD ensure that no stale data To eliminate this race condition, the local ULP SHOULD ensure
is contained in the buffer before remote read access rights are that no stale data is contained in the buffer before remote read
granted (this can be done by zeroing the contents of the memory, access rights are granted (this can be done by zeroing the
for example). contents of the memory, for example). This ensures that the
Remote Peer can not access the buffer until the stale data has
been removed.
6.3.3 Accessing a Buffer After the Transfer 6.3.3 Accessing a Buffer After the Transfer
If the Remote Peer has remote read access to a buffer, and by If the Remote Peer has remote read access to a buffer, and by
some mechanism tells the local ULP that the transfer has been some mechanism tells the local ULP that the transfer has been
completed, but the local ULP does not disable remote access to completed, but the local ULP does not disable remote access to
the buffer before modifying the data, it is possible for the the buffer before modifying the data, it is possible for the
Remote Peer to retrieve the new data. Remote Peer to retrieve the new data.
This is similar to the attack defined in Section 6.2.2 Modifying This is similar to the attack defined in Section 6.2.2 Modifying
skipping to change at page 30, line 39 skipping to change at page 31, line 39
Peers do not mutually trust each other, it is possible for one Peers do not mutually trust each other, it is possible for one
Remote Peer to overwrite the contents that have been written by Remote Peer to overwrite the contents that have been written by
the other Remote Peer. the other Remote Peer.
Thus a ULP with multiple Remote Peers which do not share Partial Thus a ULP with multiple Remote Peers which do not share Partial
Mutual Trust MUST NOT grant write access to the same buffer Mutual Trust MUST NOT grant write access to the same buffer
through different STags. A buffer should be exposed to only one through different STags. A buffer should be exposed to only one
untrusted Remote Peer at a time to ensure that no information untrusted Remote Peer at a time to ensure that no information
disclosure or information tampering occurs between peers. disclosure or information tampering occurs between peers.
6.3.7 Controlling Access to PTT & STag Mapping
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.
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 a local ULP can only initialize the Page
Translation Table (PTT)to point to its own buffers.
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.
6.4 Denial of Service (DOS) 6.4 Denial of Service (DOS)
A DOS attack is one of the primary security risks of RDMAP. This A DOS attack is one of the primary security risks of RDMAP. This
is because RNIC resources are valuable and scarce, and many ULP is because RNIC resources are valuable and scarce, and many ULP
environments require communication with untrusted Remote Peers. environments require communication with untrusted Remote Peers.
If the Remote Peer can be authenticated or the ULP payload If the Remote Peer can be authenticated or the ULP payload
encrypted, clearly, the DOS profile can be reduced. For the encrypted, clearly, the DOS profile can be reduced. For the
purposes of this analysis, it is assumed that the RNIC must be purposes of this analysis, it is assumed that the RNIC must be
able to operate in untrusted environments, which are open to DOS able to operate in untrusted environments, which are open to DOS
style attacks. style attacks.
skipping to change at page 41, line 5 skipping to change at page 40, line 51
The same type of argument applies even if the RDMA Read Request The same type of argument applies even if the RDMA Read Request
is not shared - but a local ULP attempts to allocate all of the is not shared - but a local ULP attempts to allocate all of the
RNIC's resources when the queue is created. RNIC's resources when the queue is created.
Thus access to interfaces that allocate RDMA Read Request Queue Thus access to interfaces that allocate RDMA Read Request Queue
entries MUST be restricted to a trusted Local Peer, such as a entries MUST be restricted to a trusted Local Peer, such as a
Privileged Resource Manager. The Privileged Resource Manager Privileged Resource Manager. The Privileged Resource Manager
SHOULD prevent a local ULP from allocating more than its fair SHOULD prevent a local ULP from allocating more than its fair
share of resources. share of resources.
7.3 Local ULP Attacking the PTT & STag Mapping
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.
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 a local ULP can only initialize the Page
Translation Table (PTT)to point to its own buffers.
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.
8 Security considerations 8 Security considerations
This entire document is focused on security considerations. 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.
Additionally, the appendices provide a summary of the security
requirements for specific audiences. Section 11 Appendix A: ULP
Issues for RDDP Client/Server Protocols provides a summary of
implementation issues and requirements for applications which
implement a traditional client/server style of interaction. It
provides additional insight and applicability of the normative
text in Sections 5, 6, and 7. Section 12, Appendix B: Summary of
RNIC and ULP Implementation Requirements provides a convenient
summary of normative requirements for implementers.
9 IANA Considerations 9 IANA Considerations
IANA considerations are not addressed by this document. Any IANA IANA considerations are not addressed by this document. Any IANA
considerations resulting from the use of DDP or RDMA must be considerations resulting from the use of DDP or RDMA must be
addressed in the relevant standards. addressed in the relevant standards.
10 References 10 References
10.1 Normative References 10.1 Normative References
[RFC2828] Shirley, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[DDP] Shah, H., J. Pinkerton, R. Recio, and P. Culley, "Direct [DDP] Shah, H., J. Pinkerton, R. Recio, and P. Culley, "Direct
Data Placement over Reliable Transports", Internet-Draft Work Data Placement over Reliable Transports", Internet-Draft Work
in Progress draft-ietf-rddp-ddp-04.txt, December 2004. in Progress draft-ietf-rddp-ddp-05.txt, July 2005.
[RDMAP] Recio, R., P. Culley, D. Garcia, J. Hilland, "An RDMA [RDMAP] Recio, R., P. Culley, D. Garcia, J. Hilland, "An RDMA
Protocol Specification", Internet-Draft Work in Progress Protocol Specification", Internet-Draft Work in Progress
draft-ietf-rddp-rdmap-03.txt, December 2004. draft-ietf-rddp-rdmap-05.txt, July 2005.
[RFC2406] Kent, S., Atkinson, R. "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2401] Kent, S., Atkinson, R. "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S., Atkinson, R. "IP Authentication Header", RFC
2402, November 1998.
[RFC3723] Aboba, B., et al, "Securing Block Storage Protocols [RFC3723] Aboba, B., et al, "Securing Block Storage Protocols
over IP", Internet draft (work in progress), RFC3723, April over IP", RFC3723, April 2004.
2004.
[SCTP] Stewart, R. et al., "Stream Control Transmission [RFC2960] Stewart, R. et al., "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[TCP] Postel, J., "Transmission Control Protocol - DARPA Internet [RFC793] Postel, J., "Transmission Control Protocol - DARPA
Program Protocol Specification", RFC 793, September 1981. Internet Program Protocol Specification", RFC 793, September
1981.
10.2 Informative References 10.2 Informative References
[RFC2828] Shirley, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[APPLICABILITY] Bestler, C. , Coene, L. "Applicability of Remote [APPLICABILITY] Bestler, C. , Coene, L. "Applicability of Remote
Direct Memory Access Protocol (RDMA) and Direct Data Direct Memory Access Protocol (RDMA) and Direct Data
Placement (DDP)", Internet-Draft Work in Progress draft-ietf- Placement (DDP)", Internet-Draft Work in Progress draft-ietf-
rddp-applicability-05.txt, December 2005. rddp-applicability-06.txt, April 2006.
[IPv6-Trust] Nikander, P., J.Kempf, E. Nordmark, "IPv6 Neighbor [IPv6-Trust] Nikander, P., J.Kempf, E. Nordmark, "IPv6 Neighbor
Discovery Trust Models and threats", Informational RFC, Discovery Trust Models and threats", Informational RFC,
RFC3756, May 2004. RFC3756, May 2004.
[NFSv4CHANNEL] Williams, N., "On the Use of Channel Bindings to [NFSv4CHANNEL] Williams, N., "On the Use of Channel Bindings to
Secure Channels", Internet-Draft draft-ietf-nfsv4-channel- Secure Channels", Internet-Draft draft-ietf-nfsv4-channel-
bindings-02.txt, July 2004. bindings-02.txt, July 2004.
[VERBS-RDMAC] "RDMA Protocol Verbs Specification", RDMA [VERBS-RDMAC] "RDMA Protocol Verbs Specification", RDMA
skipping to change at page 46, line 6 skipping to change at page 47, line 6
* Section 6.1.1 Using an STag on a Different Stream. To * Section 6.1.1 Using an STag on a Different Stream. To
ensure that one client can not access another ensure that one client can not access another
client's data via use of the other client's STag, the client's data via use of the other client's STag, the
server ULP must either scope an STag to a single server ULP must either scope an STag to a single
Stream or use a unique Protection Domain per client. Stream or use a unique Protection Domain per client.
If a single client has multiple Streams that share If a single client has multiple Streams that share
Partial Mutual Trust, then the STag can be shared Partial Mutual Trust, then the STag can be shared
between the associated Streams by using a single between the associated Streams by using a single
Protection Domain among the associated Streams (see Protection Domain among the associated Streams (see
section 5.4.3 ULPs Which Provide Security for Section 5.4.3 ULPs Which Provide Security for
additional issues). To prevent unintended sharing of additional issues). To prevent unintended sharing of
STags within the associated Streams, a server ULP STags within the associated Streams, a server ULP
should use STags in such a fashion that it is should use STags in such a fashion that it is
difficult to predict the next allocated STag number. difficult to predict the next allocated STag number.
* Tampering * Tampering
* 6.2.2 Modifying a Buffer After Indication. Before the * 6.2.2 Modifying a Buffer After Indication. Before the
local ULP operates on a buffer that was written by local ULP operates on a buffer that was written by
the Remote Peer using an RDMA Write or RDMA Read, the the Remote Peer using an RDMA Write or RDMA Read, the
local ULP MUST ensure the buffer can no longer be local ULP MUST ensure the buffer can no longer be
modified, by invalidating the STag for remote access modified, by invalidating the STag for remote access
(note that this is stronger than the SHOULD in (note that this is stronger than the SHOULD in
section 6.2.2). This can either be done explicitly by Section 6.2.2). This can either be done explicitly by
revoking remote access rights for the STag when the revoking remote access rights for the STag when the
Remote Peer indicates the operation has completed, or Remote Peer indicates the operation has completed, or
by checking to make sure the Remote Peer Invalidated by checking to make sure the Remote Peer Invalidated
the STag through the RDMAP Invalidate capability, and the STag through the RDMAP Invalidate capability, and
if it did not, the local ULP then explicitly revoking if it did not, the local ULP then explicitly revoking
the STag remote access rights. the STag remote access rights.
* Information Disclosure * Information Disclosure
* 6.3.2 Using RDMA Read to Access Stale Data. In a * 6.3.2 Using RDMA Read to Access Stale Data. In a
general purpose server environment there is no general purpose server environment there is no
compelling rationale to not require a buffer to be compelling rationale to not require a buffer to be
initialized before remote read is enabled (and an initialized before remote read is enabled (and an
enormous down side of unintentionally sharing data). enormous down side of unintentionally sharing data).
Thus a local ULP MUST (this is stronger than the Thus a local ULP MUST (this is stronger than the
SHOULD in section 6.3.2) ensure that no stale data is SHOULD in Section 6.3.2) ensure that no stale data is
contained in a buffer before remote read access contained in a buffer before remote read access
rights are granted to a Remote Peer (this can be done rights are granted to a Remote Peer (this can be done
by zeroing the contents of the memory, for example). by zeroing the contents of the memory, for example).
* 6.3.3 Accessing a Buffer After the Transfer. This * 6.3.3 Accessing a Buffer After the Transfer. This
mitigation is already covered by section 6.2.2 mitigation is already covered by Section 6.2.2
(above). (above).
* 6.3.4 Accessing Unintended Data With a Valid STag. * 6.3.4 Accessing Unintended Data With a Valid STag.
The ULP must set the base and bounds of the buffer The ULP must set the base and bounds of the buffer
when the STag is initialized to expose only the data when the STag is initialized to expose only the data
to be retrieved. to be retrieved.
* 6.3.5 RDMA Read into an RDMA Write Buffer. If a peer * 6.3.5 RDMA Read into an RDMA Write Buffer. If a peer
only intends a buffer to be exposed for remote write only intends a buffer to be exposed for remote write
access, it must set the access rights to the buffer access, it must set the access rights to the buffer
to only enable remote write access. to only enable remote write access.
* 6.3.6 Using Multiple STags Which Alias to the Same * 6.3.6 Using Multiple STags Which Alias to the Same
Buffer. The requirement in section 6.1.1 (above) Buffer. The requirement in Section 6.1.1 (above)
mitigates this attack. A server buffer is exposed to mitigates this attack. A server buffer is exposed to
only one client at a time to ensure that no only one client at a time to ensure that no
information disclosure or information tampering information disclosure or information tampering
occurs between peers. occurs between peers.
* 5.3 - Network Based Eavesdropping. Confidentiality * 5.3 - Network Based Eavesdropping. Confidentiality
services should be enabled by the ULP if this threat services should be enabled by the ULP if this threat
is a concern. is a concern.
* Denial of Service * Denial of Service
skipping to change at page 47, line 50 skipping to change at page 48, line 50
allowed to enable this feature in an unsafe mode, if allowed to enable this feature in an unsafe mode, if
the two local ULPs share Partial Mutual Trust, they the two local ULPs share Partial Mutual Trust, they
must behave in the following manner: must behave in the following manner:
1) The sizing of the completion queue is based on the 1) The sizing of the completion queue is based on the
size of the receive queue and send queues as size of the receive queue and send queues as
documented in 6.4.3.2 Remote or Local Peer Attacking documented in 6.4.3.2 Remote or Local Peer Attacking
a Shared CQ. a Shared CQ.
2) The local ULP ensures that CQ entries are reaped 2) The local ULP ensures that CQ entries are reaped
frequently enough to adhere to section 6.4.3.2's frequently enough to adhere to Section 6.4.3.2's
rules. rules.
* 6.4.3.2 Remote or Local Peer Attacking a Shared CQ. * 6.4.3.2 Remote or Local Peer Attacking a Shared CQ.
There are two mitigations specified in this section - There are two mitigations specified in this section -
one requires a worst-case size of the CQ, and can be one requires a worst-case size of the CQ, and can be
implemented entirely within the Privileged Resource implemented entirely within the Privileged Resource
Manager. The second approach requires cooperation Manager. The second approach requires cooperation
with the local ULP server (to not post too many with the local ULP server (to not post too many
buffers), and enables a smaller CQ to be used. buffers), and enables a smaller CQ to be used.
skipping to change at page 48, line 30 skipping to change at page 49, line 30
RDMA Read operations to server buffers. However, RDMA Read operations to server buffers. However,
because the server ULP knows best which of its because the server ULP knows best which of its
Streams share Partial Mutual Trust, this requirement Streams share Partial Mutual Trust, this requirement
can be reflected back to the ULP. The ULP (i.e. can be reflected back to the ULP. The ULP (i.e.
server) requirement in this case is that it MUST NOT server) requirement in this case is that it MUST NOT
allow RDMA Read Request Queues to be shared between allow RDMA Read Request Queues to be shared between
ULPs which do not have Partial Mutual Trust. ULPs which do not have Partial Mutual Trust.
* 6.4.5 Remote Invalidate an STag Shared on Multiple * 6.4.5 Remote Invalidate an STag Shared on Multiple
Streams. This mitigation is already covered by Streams. This mitigation is already covered by
section 6.2.2 (above). Section 6.2.2 (above).
12 Appendix B: Summary of RNIC and ULP Implementation Requirements 12 Appendix B: Summary of RNIC and ULP Implementation Requirements
This appendix is informative. This appendix is informative.
Below is a summary of implementation requirements for the RNIC: Below is a summary of implementation requirements for the RNIC:
* 3 Trust and Resource Sharing * 3 Trust and Resource Sharing
* 5.4.4 Requirements for IPsec Encapsulation of DDP
* 6.1.1 Using an STag on a Different Stream * 6.1.1 Using an STag on a Different Stream
* 6.2.1 Buffer Overrun - RDMA Write or Read Response * 6.2.1 Buffer Overrun - RDMA Write or Read Response
* 6.2.2 Modifying a Buffer After Indication * 6.2.2 Modifying a Buffer After Indication
* 6.3.7 Controlling Access to PTT & STag Mapping
* 6.4.1 RNIC Resource Consumption * 6.4.1 RNIC Resource Consumption
* 6.4.3.1 Multiple Streams Sharing Receive Buffers * 6.4.3.1 Multiple Streams Sharing Receive Buffers
* 7.1 Local ULP Attacking a Shared CQ
* 6.4.3.2 Remote or Local Peer Attacking a Shared CQ * 6.4.3.2 Remote or Local Peer Attacking a Shared CQ
* 6.4.3.3 Attacking the RDMA Read Request Queue * 6.4.3.3 Attacking the RDMA Read Request Queue
* 6.4.6 Remote Peer attacking an Unshared CQ. * 6.4.6 Remote Peer attacking an Unshared CQ.
* 6.5 Elevation of Privilege 38 * 6.5 Elevation of Privilege 39
* 5.4.4 Requirements for IPsec Encapsulation of DDP * 7.1 Local ULP Attacking a Shared CQ
* 7.3 Local ULP Attacking the PTT & STag Mapping
Below is a summary of implementation requirements for the ULP Below is a summary of implementation requirements for the ULP
above the RNIC: above the RNIC:
* 5.3 Information Disclosure - Network Based Eavesdropping
* 6.1.1 Using an STag on a Different Stream * 6.1.1 Using an STag on a Different Stream
* 6.2.2 Modifying a Buffer After Indication * 6.2.2 Modifying a Buffer After Indication
* 6.3.2 Using RDMA Read to Access Stale Data * 6.3.2 Using RDMA Read to Access Stale Data
* 6.3.3 Accessing a Buffer After the Transfer * 6.3.3 Accessing a Buffer After the Transfer
* 6.3.4 Accessing Unintended Data With a Valid STag * 6.3.4 Accessing Unintended Data With a Valid STag
* 6.3.5 RDMA Read into an RDMA Write Buffer * 6.3.5 RDMA Read into an RDMA Write Buffer
* 6.3.6 Using Multiple STags Which Alias to the Same Buffer * 6.3.6 Using Multiple STags Which Alias to the Same Buffer
* 5.3 - Network Based Eavesdropping
* 7.1 Local ULP Attacking a Shared CQ
* 6.4.5 Remote Invalidate an STag Shared on Multiple * 6.4.5 Remote Invalidate an STag Shared on Multiple
Streams Streams
13 Appendix C: Partial Trust Taxonomy 13 Appendix C: Partial Trust Taxonomy
This appendix is informative. This appendix is informative.
Partial Trust is defined as when one party is willing to assume Partial Trust is defined as when one party is willing to assume
that another party will refrain from a specific attack or set of 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. attacks, the parties are said to be in a state of Partial Trust.
 End of changes. 86 change blocks. 
253 lines changed or deleted 289 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/