draft-ietf-rddp-security-03.txt   draft-ietf-rddp-security-04.txt 
Internet Draft James Pinkerton Internet Draft James Pinkerton
draft-ietf-rddp-security-03.txt Microsoft Corporation draft-ietf-rddp-security-04.txt Microsoft Corporation
Category: Standards Track Ellen Deleganes Category: Standards Track Ellen Deleganes
Expires: February, 2005 Intel Corporation Expires: February, 2005 Intel Corporation
Sara Bitan Sara Bitan
Microsoft Corporation Microsoft Corporation
August 2004 August 2004
DDP/RDMAP Security DDP/RDMAP Security
1 Status of this Memo 1 Status of this Memo
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 spoofing, tampering, information
disclosure, denial of service, and elevation of privilege. disclosure, denial of service, and elevation of privilege.
Finally, the document concludes with a summary of security Finally, the document concludes with a summary of security
services for DDP and RDMAP, such as IPSec. services for DDP and RDMAP, such as IPsec.
J. Pinkerton, et al. Expires February 2005 1 J. Pinkerton, et al. Expires February 2005 1
Table of Contents Table of Contents
1 Status of this Memo.........................................1 1 Status of this Memo.........................................1
2 Abstract....................................................1 2 Abstract....................................................1
2.1 Issues......................................................3 2.1 Revision History............................................3
2.2 Revision History............................................4 2.1.1 Changes from -02 to -03 version............................3
2.2.1 Changes from -02 to -03 version............................4 2.1.2 Changes from the -01 to the -02 version....................5
2.2.2 Changes from the -01 to the -02 version....................4 2.1.3 Changes from the -00 to -01 version........................5
2.2.3 Changes from the -00 to -01 version........................4
3 Introduction................................................6 3 Introduction................................................6
4 Architectural Model.........................................8 4 Architectural Model.........................................8
4.1 Components..................................................9 4.1 Components..................................................9
4.2 Resources..................................................11 4.2 Resources..................................................11
4.2.1 Stream Context Memory.....................................11 4.2.1 Stream Context Memory.....................................11
4.2.2 Data Buffers..............................................11 4.2.2 Data Buffers..............................................11
4.2.3 Page Translation Tables...................................11 4.2.3 Page Translation Tables...................................11
4.2.4 STag Namespace............................................12 4.2.4 STag Namespace............................................12
4.2.5 Completion Queues.........................................12 4.2.5 Completion Queues.........................................12
4.2.6 Asynchronous Event Queue..................................12 4.2.6 Asynchronous Event Queue..................................12
skipping to change at page 3, line 29 skipping to change at page 3, line 28
8.1 Introduction to Security Options...........................38 8.1 Introduction to Security Options...........................38
8.1.1 Introduction to IPsec.....................................38 8.1.1 Introduction to IPsec.....................................38
8.1.2 Introduction to SSL Limitations on RDMAP..................40 8.1.2 Introduction to SSL Limitations on RDMAP..................40
8.1.3 Applications Which Provide Security.......................40 8.1.3 Applications Which Provide Security.......................40
8.2 Requirements for IPsec Encapsulation of DDP................40 8.2 Requirements for IPsec Encapsulation of DDP................40
9 Security considerations....................................42 9 Security considerations....................................42
10 References.................................................43 10 References.................................................43
10.1 Normative References......................................43 10.1 Normative References......................................43
10.2 Informative References....................................43 10.2 Informative References....................................43
11 Appendix A: Implementing Client/Server Protocols...........44 11 Appendix A: Implementing Client/Server Protocols...........44
12 Appendix B: Summary Table of Attacks.......................47 12 Appendix B: Summary Table of Attacks.......................48
13 Appendix C: Partial Trust Taxonomy.........................48 13 Appendix C: Partial Trust Taxonomy.........................50
14 AuthorĘs Addresses.........................................50 14 AuthorĘs Addresses.........................................52
15 Acknowledgments............................................51 15 Acknowledgments............................................53
16 Full Copyright Statement...................................52 16 Full Copyright Statement...................................54
Table of Figures Table of Figures
Figure 1 - RDMA Security Model....................................9 Figure 1 - RDMA Security Model....................................9
2.1 Issues 2.1 Revision History
This section is temporary and will go away when all issues have 2.1.1 Changes from -03 to -04 version
been resolved.
Issue: Guidance for application protocols like NFS which * Removed "issues" section because all issues have been
implement security <TBD>.........................................40 resolved.
2.2 Revision History * Completed section "Applications Which Provide Security"
by providing a cross reference to channel bindings.
2.2.1 Changes from -02 to -03 version * Substantial rewrite of Section 11 Appendix A:
Implementing Client/Server Protocols. Retargeted it to
focus on server application requirements, rather than
RNIC requirements.
* Changed "IPSec" to "IPsec" everywhere to match the RFC.
* Added new ULP requirement in section 7.5.2.4 Attacking
the RDMA Read Request Queue.
* Reviesed Sectio 12 Appendix B: Summary of RNIC and ULP
Implementation Requirements slightly to add one ULP
requirement and one RNIC requirement which is stated in
the document but was missed in this summary.
2.1.2 Changes from -02 to -03 version
* ID changed from Informational to Standards Track. This * ID changed from Informational to Standards Track. This
caused previous RECOMMENDATIONS to be categorized into caused previous RECOMMENDATIONS to be categorized into
the categories of MUST, SHOULD, MAY, RECOMMENDED, and in the categories of MUST, SHOULD, MAY, RECOMMENDED, and in
one case, "recommended". one case, "recommended".
* Completed Appendix B: Summary of Attacks to provide a * Completed Appendix B: Summary of Attacks to provide a
summary of implementation requirements for applications summary of implementation requirements for applications
using RDDP and for RNICs in Appendix B: Summary of using RDDP and for RNICs in Appendix B: Summary of
Attacks. Attacks.
skipping to change at page 4, line 47 skipping to change at page 5, line 5
* Changed section 8.2 to normative xref to IPS Security, * Changed section 8.2 to normative xref to IPS Security,
plus comment on the value of end-to-end IPsec. plus comment on the value of end-to-end IPsec.
* Added clarifying example on STag invalidation (e.g. One- * Added clarifying example on STag invalidation (e.g. One-
Shot STag discussion). Shot STag discussion).
* Added clarifying text on why SSL is a bad idea. * Added clarifying text on why SSL is a bad idea.
* Normative statement on mitigation for Shared RQ. * Normative statement on mitigation for Shared RQ.
2.2.2 Changes from the -01 to the -02 version 2.1.3 Changes from the -01 to the -02 version
Minimal - some typos, deleted some text previously marked for Minimal - some typos, deleted some text previously marked for
deletion. deletion.
2.2.3 Changes from the -00 to -01 version 2.1.4 Changes from the -00 to -01 version
* Added two pages to the architectural model to describe * Added two pages to the architectural model to describe
the Asynchronous Event Queue, and the types of the Asynchronous Event Queue, and the types of
interactions that can occur between the RNIC and the interactions that can occur between the RNIC and the
modules above it. modules above it.
* Addressed Mike Krauses comments submitted on 12/8/2003 * Addressed Mike Krauses comments submitted on 12/8/2003
* Moved "Trust Models" from the body of the document to an * Moved "Trust Models" from the body of the document to an
appendix. Removed references to it throughout the appendix. Removed references to it throughout the
skipping to change at page 17, line 37 skipping to change at page 17, line 37
account security attacks detailed in this specification. Note account security attacks detailed in this specification. Note
that for some systems the Privileged Resource Manager may be that for some systems the Privileged Resource Manager may be
implemented within the Privileged Application. implemented within the Privileged Application.
The sharing of resources across Streams should be under the The sharing of resources across Streams should be under the
control of the application, both in terms of the trust model the control of the application, both in terms of the trust model the
application wishes to operate under, as well as the level of application wishes to operate under, as well as the level of
resource sharing the application wishes to give Local Peer resource sharing the application wishes to give Local Peer
processes. For more discussion on types of trust models which processes. For more discussion on types of trust models which
combine partial trust and sharing of resources, see Appendix C: combine partial trust and sharing of resources, see Appendix C:
Partial Trust Taxonomy on page 48. Partial Trust Taxonomy on page 50.
6 Attacker Capabilities 6 Attacker Capabilities
An attackerĘs capabilities delimit the types of attacks that An attackerĘs capabilities delimit the types of attacks that
attacker is able to launch. RDMAP and DDP require that the attacker is able to launch. RDMAP and DDP require that the
initial LLP Stream (and connection) be set up prior to initial LLP Stream (and connection) be set up prior to
transferring RDMAP/DDP Messages. Attackers with send only transferring RDMAP/DDP Messages. Attackers with send only
capabilities must first guess the current LLP Stream parameters capabilities must first guess the current LLP Stream parameters
before they can attack RNIC resources (e.g. TCP sequence number). before they can attack RNIC resources (e.g. TCP sequence number).
Attackers with both send and receive capabilities have presumably Attackers with both send and receive capabilities have presumably
skipping to change at page 25, line 47 skipping to change at page 25, line 47
Peer Invalidated the STag through the RDMAP Invalidate Peer Invalidated the STag through the RDMAP Invalidate
capability, and if it did not, the Local Peer then explicitly capability, and if it did not, the Local Peer then explicitly
revokes the STag remote access rights. revokes the STag remote access rights.
The Local Peer SHOULD follow the above procedure to protect the The Local Peer 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).
7.3.3 Multiple STags to access the same buffer 7.3.3 Multiple STags to access the same buffer
See section 7.4.6 on page 27 for this analysis. See section 7.4.6 Using Multiple STags Which Alias to the Same
Buffer on page 27 for this analysis.
7.3.4 Network based modification of buffer content 7.3.4 Network based modification of buffer content
This is actually a man in the middle attack - but only on the This is actually a man in the middle attack - but only on the
content of the buffer, as opposed to the man in the middle attack content of the buffer, as opposed to the man in the middle attack
presented above, where both the signaling and content can be presented above, where both the signaling and content can be
modified. See Section 7.2.3 Man in the Middle Attack on page 22. modified. See Section 7.2.3 Man in the Middle Attack on page 22.
7.4 Information Disclosure 7.4 Information Disclosure
skipping to change at page 26, line 47 skipping to change at page 26, line 47
7.4.3 Accessing a Buffer After the Transfer 7.4.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 Peer that the transfer has been some mechanism tells the Local Peer that the transfer has been
completed, but the Local Peer does not disable remote access to completed, but the Local Peer 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 7.3.2 Modifying This is similar to the attack defined in Section 7.3.2 Modifying
a Buffer After Indicati on page 25. The same countermeasures a Buffer After Indication on page 25. The same countermeasures
apply. In addition, the Local Peer SHOULD grant remote read apply. In addition, the Local Peer SHOULD grant remote read
access rights only for the amount of time needed to retrieve the access rights only for the amount of time needed to retrieve the
data. data.
7.4.4 Accessing Unintended Data With a Valid STag 7.4.4 Accessing Unintended Data With a Valid STag
If the Local Peer enables remote access to a buffer using an STag If the Local Peer enables remote access to a buffer using an STag
that references the entire buffer, but intends only a portion of that references the entire buffer, but intends only a portion of
the buffer to be accessed, it is possible for the Remote Peer to the buffer to be accessed, it is possible for the Remote Peer to
access the other parts of the buffer anyway. access the other parts of the buffer anyway.
skipping to change at page 32, line 25 skipping to change at page 32, line 25
could stall all other Local Peers attempting to use that CQ. could stall all other Local Peers attempting to use that CQ.
One of two countermeasures can be used to avoid this kind of One of two countermeasures can be used to avoid this kind of
attack. The first is to only share a CQ between Streams that attack. The first is to only share a CQ between Streams that
share Partial Mutual Trust (i.e. Streams within the same share Partial Mutual Trust (i.e. Streams within the same
Protection Domain). The other is to use a trusted Local Peer to Protection Domain). The other is to use a trusted Local Peer to
act as a third party to free resources on the CQ and place the act as a third party to free resources on the CQ and place the
status in intermediate storage until the untrusted Local Peer status in intermediate storage until the untrusted Local Peer
reaps the status information. For these reasons, an RNIC MUST NOT reaps the status information. For these reasons, an RNIC MUST NOT
enable sharing a CQ across Streams that belong to different enable sharing a CQ across Streams that belong to different
Protection Domains. Addtionally, an application SHOULD NOT share Protection Domains. Additionally, an application SHOULD NOT share
a CQ between Streams which do not share Partial Mutual Trust. a CQ between Streams which do not share Partial Mutual Trust.
7.5.2.3 Remote Peer Attacking a Shared CQ 7.5.2.3 Remote Peer Attacking a Shared CQ
For an overview of the Shared CQ attack model, see Section For an overview of the Shared CQ attack model, see Section
7.5.2.2. 7.5.2.2.
The Remote Peer can attack a CQ by consuming more than its fair The Remote Peer can attack a CQ by consuming more than its fair
share of CQ entries by using one of the following methods: share of CQ entries by using one of the following methods:
skipping to change at page 35, line 36 skipping to change at page 35, line 36
Requests than the depth of the RDMA Read Request Queue at the Requests than the depth of the RDMA Read Request Queue at the
Local Peer. If the RDMA Read Request Queue is a shared resource, Local Peer. If the RDMA Read Request Queue is a shared resource,
this could corrupt the queue. If the queue is not shared, then this could corrupt the queue. If the queue is not shared, then
the worst case is that the current Stream is disabled. One the worst case is that the current Stream is disabled. One
approach to solving the shared RDMA Read Request Queue would be approach to solving the shared RDMA Read Request Queue would be
to create thresholds, similar to those described in Section to create thresholds, similar to those described in Section
7.5.2.1 Multiple Streams Sharing Receive Buffers on page 30. A 7.5.2.1 Multiple Streams Sharing Receive Buffers on page 30. A
simpler approach is to not share RDMA Read Request Queue simpler approach is to not share RDMA Read Request Queue
resources amoung Streams or enforce hard limits of consumption resources amoung Streams or enforce hard limits of consumption
per Stream. Thus RDMA Read Request Queue resource consumption per Stream. Thus RDMA Read Request Queue resource consumption
MUST be controlled such that RDMAP/DDP Streams which do not share MUST be controlled by the Privileged Resource Manager such that
Partial Mutual Trust do not share RDMA Read Request Queue RDMAP/DDP Streams which do not share Partial Mutual Trust do not
resources. share RDMA Read Request Queue resources. A ULP SHOULD indicate to
the Privileged Resource Manager when allocating a RDMA Read
Request Queue whether or not it shares partial mutual trust with
any other Stream(s).
If the issue is a bug in the Remote PeerĘs implementation, and If the issue is a bug in the Remote PeerĘs implementation, and
not a malicious attack, the issue can be solved by requiring the not a malicious attack, the issue can be solved by requiring the
Remote PeerĘs RNIC to throttle RDMA Read Requests. By properly Remote PeerĘs RNIC to throttle RDMA Read Requests. By properly
configuring the Stream at the Remote Peer through a trusted configuring the Stream at the Remote Peer through a trusted
agent, the RNIC can be made to not transmit RDMA Read Requests agent, the RNIC can be made to not transmit RDMA Read Requests
that exceed the depth of the RDMA Read Request Queue at the Local that exceed the depth of the RDMA Read Request Queue at the Local
Peer. If the Stream is correctly configured, and if the Remote Peer. If the Stream is correctly configured, and if the Remote
Peer submits more requests than the Local PeerĘs RDMA Read Peer submits more requests than the Local PeerĘs RDMA Read
Request Queue can handle, the requests would be queued at the Request Queue can handle, the requests would be queued at the
skipping to change at page 40, line 37 skipping to change at page 40, line 37
cause a significant decrease in its efficiency. cause a significant decrease in its efficiency.
If SSL is layered on top of RDMAP or DDP, SSL does not protect If SSL is layered on top of RDMAP or DDP, SSL 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.
8.1.3 Applications Which Provide Security 8.1.3 Applications Which Provide Security
Issue: Guidance for application protocols like NFS which Applications which provide integrated security but wish to
implement security <TBD>. leverage lower-layer protocol security should be aware of
security concerns around correlating a specific channelĘs
security mechanisms to the authentication performed by the
application. See [NFSv4CHANNEL] for additional information on a
promising approach called "channel binding". From [NFSv4CHANNEL]:
The concept of channel bindings allows applications to prove
that the end-points of two secure channels at different
network layers are the same by binding authentication at one
channel to the session protection at the other channel. The
use of channel bindings allows applications to delegate
session protection to lower layers, which may significantly
improve performance for some applications.
8.2 Requirements for IPsec Encapsulation of DDP 8.2 Requirements for IPsec Encapsulation of DDP
The IP Storage working group has spent significant time and The IP Storage working group has spent significant time and
effort to define the normative IPSec requirements for IP Storage effort to define the normative IPsec requirements for IP Storage
[RFC3723]. Portions of that specification are applicable to a [RFC3723]. Portions of that specification are applicable to a
wide variety of protocols, including the RDDP protocol suite. In wide variety of protocols, including the RDDP protocol suite. In
order to not replicate this effort, an RNIC implementation MUST order to not replicate this effort, an RNIC implementation MUST
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. those sections.
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 an 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.
9 Security considerations 9 Security considerations
This entire specification is focused on security considerations. This entire specification is focused on security considerations.
10 References 10 References
10.1 Normative References 10.1 Normative References
skipping to change at page 43, line 32 skipping to change at page 43, line 32
[SCTP] R. Stewart et al., "Stream Control Transmission Protocol", [SCTP] R. Stewart et al., "Stream Control Transmission Protocol",
RFC 2960, October 2000. RFC 2960, October 2000.
[TCP] Postel, J., "Transmission Control Protocol - DARPA Internet [TCP] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC 793, September 1981. Program Protocol Specification", RFC 793, September 1981.
10.2 Informative References 10.2 Informative References
[IPv6-Trust] Nikander, P., J.Kempf, E. Nordmark, "IPv6 Neighbor [IPv6-Trust] Nikander, P., J.Kempf, E. Nordmark, "IPv6 Neighbor
Discovery trust modelsTrust Models and threats", Internet- Discovery Trust Models and threats", Internet-Draft draft-
Draft draft-ietf-send-psreq-01.txt, January 2003. ietf-send-psreq-01.txt, January 2003.
[NFSv4CHANNEL] Williams, N., "On the Use of Channel Bindings to
Secure Channels", Internet-Draft draft-ietf-nfsv4-channel-
bindings-02.txt, July 2004.
11 Appendix A: Implementing Client/Server Protocols 11 Appendix A: Implementing Client/Server Protocols
<TBD: This section has not been updated to reflect the new This section is a normative appendix to the specification that is
normative focus of this specification. It will be updated in the focused on client/server application implementation requirements
next version.> to ensure a secure server implementation.
The prior sections outlined specific attacks and their The prior sections outlined specific attacks and their
countermeasures. This section summarizes the attacks and countermeasures. This section summarizes the attacks and
countermeasures defined in the prior section which are applicable countermeasures that have been defined in the prior section which
to creation of a secure application server. An application server are applicable to creation of a secure application server. An
is defined as an application which must be able to communicate application server is defined as an application which must be
with many clients which do not trust each other and ensure that able to communicate with many clients which do not trust each
each client can not attack another client through server other and ensure that each client can not attack another client
interactions. Further, the server may wish to use multiple through server interactions. Further, the server may wish to use
Streams to communicate with a specific client, and those Streams multiple Streams to communicate with a specific client, and those
may share mutual trust. Streams may share mutual trust. Note that this section assumes a
compliant RNIC and Privileged Resource Manager implementation -
thus it focuses specifically on application server (i.e. ULP)
implementation issues.
All of the prior section's details on attacks and countermeasures All of the prior section's details on attacks and countermeasures
to protect a single Stream apply to the server. This section apply to the server. In some cases normative SHOULD statements
focuses on security issues where multiple clients are talking for the ULP in the main body of this document are made MUST
with a single server, and what mitigations the server application statements for the ULP because the operating conditions can be
must have in place to ensure robust operation. refined to make the motives for a SHOULD inapplicable. If a prior
SHOULD is changed to a MUST in this section, it is explicitly
noted.
The following list summarizes the relevent attacks that clients The following list summarizes the relevent attacks that clients
can mount on the shared server, by re-stating the previous can mount on the shared server, by re-stating the previous
normative statements to be client/server specific: normative statements to be client/server specific:
* General Requirements
* Section 4.1 Components on page 9. To ensure Non-
Privileged applications running on the server can not
create a DOS attack on each other, all Non-Privileged
Application interactions with the RNIC Engine that
could affect other applications MUST be done using
the Privileged Resource Manager as a proxy.
* Spoofing * Spoofing
* For protection against many forms of spoofing * Sections 7.2.1 to 7.2.3. For protection against many
attacks, enable IPSec. forms of spoofing attacks, enable IPsec.
* Section 7.2.4 Using an STag on a Different Stream on * Section 7.2.4 Using an STag on a Different Stream on
page 23. To ensure that one client can not access page 23. To ensure that one client can not access
another client's data via use of the other client's another client's data via use of the other client's
STag, the server MUST either scope an STag to a STag, the server application MUST either scope an
single Stream or use a Protection Domain per client. STag to a single Stream or use a Protection Domain
If a single client has multiple streams that share per client. If a single client has multiple streams
Partial Mutual Trust, then the STag can be shared that share Partial Mutual Trust, then the STag can be
between the associated Streams by using a single shared between the associated Streams by using a
Protection Domain amoung the associated Streams. To single Protection Domain amoung the associated
Streams (see section 8.1.3 Applications Which Provide
Security on page 40 for additional issues). To
prevent unintended sharing of STags within the prevent unintended sharing of STags within the
associated Streams, an implementation SHOULD allocate associated Streams, a server application SHOULD use
STags in such a fashion that it is difficult to STags in such a fashion that it is difficult to
predict the next allocated STag number. predict the next allocated STag number.
* Tampering * Tampering
* 7.3.1 Buffer Overrun - RDMA Write or Read Response on * 7.3.2 Modifying a Buffer After Indication on page 25.
page 24. To ensure a client can not intentionally or Before the server application operates on a buffer
accidentally cause a buffer overrun, an RNIC that was written using an RDMA Write or RDMA Read,
implementation MUST ensure that a Remote Peer is not the server MUST ensure the the buffer can no longer
able to access memory outside of the buffer specified be modified by invalidating the STag for remote
when the STag was enabled for remote access. access (note that this is stronger than the SHOULD in
section 7.3.2). This can either be done explicitly by
* 7.3.3 Multiple STags to access the same buffer on revoking remote access rights for the STag when the
page 25. See the following bullet's discussion of client indicates the operation has completed, or by
Section 7.4.6. checking to make sure the client Invalidated the STag
through the RDMAP Invalidate capability, and if it
did not, the Local Peer then explicitly revokes the
STag remote access rights.
* Information Disclosure * Information Disclosure
* 7.4.2 Using RDMA Read to Access Stale Data on page * 7.4.2 Using RDMA Read to Access Stale Data on page
26. A server SHOULD ensure that no stale data is 26. A server application MUST (this is stronger than
contained in a buffer before remote read access the SHOULD in section 7.4.2) ensure that no stale
rights are granted to a client (this can be done by data is contained in a buffer before remote read
zeroing the contents of the memory, for example). access rights are granted to a client (this can be
done by zeroing the contents of the memory, for
example).
* 7.4.3 Accessing a Buffer After the Transfer on page
26. This mitigation is already covered by section
7.3.2 (above).
* 7.4.4 Accessing Unintended Data With a Valid STag on
page 26. The application server MUST set the base and
bounds of the buffer when the STag is initialized to
expose only the data to be retrieved.
* 7.4.5 RDMA Read into an RDMA Write Buffer on page 27. * 7.4.5 RDMA Read into an RDMA Write Buffer on page 27.
It is RECOMMENDED that if a server only intends a If a server only intends a buffer to be exposed for
buffer to be exposed for remote write access, it set remote write access, it MUST set the access rights to
the access rights to the buffer to only enable remote the buffer to only enable remote write access.
write access.
* 7.4.6 Using Multiple STags Which Alias to the Same * 7.4.6 Using Multiple STags Which Alias to the Same
Buffer on page 27. It is RECOMMENDED that separate Buffer on page 27. The requirement in section 7.2.4
clients not be granted write access to the same (above) mitigates this attack. A buffer is exposed to
buffer through different STags. A buffer should be only one client at a time to ensure that no
exposed to only one client at a time to ensure that information disclosure or information tampering
no information disclosure or information tampering
occurs between peers. occurs between peers.
* Denial of Service * 7.4.9 Network based eavesdropping on page 28. Enable
IPsec if this threat is a concern.
* 7.5.1 RNIC Resource Consumption on page 29. It is
RECOMMENDED that the server place the allocation of
all scarce resources be placed under the control of a
Privileged Resource Manager.
* Denial of Service
* 7.5.2.1 Multiple Streams Sharing Receive Buffers on * 7.5.2.1 Multiple Streams Sharing Receive Buffers on
page 30. If an RNIC Engine provides the ability to page 30. Application memory footprint size can be
share receive buffers across multiple Streams, it is important for some server applications. If a server
RECOMMENDED that it enable the server to detect if application is expecting significant network traffic
the client is attempting to consume more than its from multiple clients, using a receive buffer queue
fair share of resources so that the server can apply per Stream where there is a large number of Streams
countermeasures to detect and prevent the attack. can consume substantial amounts of memory. Thus a
receive queue that can be shared by multiple Streams
is attractive.
However, because of the attacks outlined in this
section, sharing a single receive queue between
multiple clients MUST ONLY be done if the mechanism
to ensure one client can't consume too many receive
buffers is enabled. For multiple Streams within a
single client application (which presumably shared
partial mutual trust) this added overhead does not
have to be enabled.
* 7.5.2.2 Local Peer Attacking a Shared CQ on page 31. * 7.5.2.2 Local Peer Attacking a Shared CQ on page 31.
Sharing a CQ across Streams that belong to different <TBD>The normative mitigations were
Protection Domains is NOT RECOMMENDED.
* 7.5.2.3 Remote Peer Attacking a Shared CQ on page 32. * RNIC MUST NOT enable sharing a CQ across Streams
If a server allows the client to influence CQ entry that belong to different Protection Domains.
resource allocation, then it is RECOMMENDED that the
CQ be isolated to Streams within a single Protection
Domain (i.e. streams that share Partial Mutual
Trust).
It is RECOMMENDED that the Local Peer implement a * An application SHOULD NOT share a CQ between
mechanism to ensure that the Completion Queue can not Streams which do not share Partial Mutual Trust.
overflow.
* 7.5.2.4 Attacking the RDMA Read Request Queue on page Because the attack is a local server application
35. It is RECOMMENDED that access to interfaces that attacking another server application,
allocate RDMA Read Request Queue entries be
restricted to a trusted Local Peer, such as a
Privileged Resource Manager.
It is RECOMMENDED that RDMA Read Request Queue * 7.5.2.3 Remote Peer Attacking a Shared CQ on page 32.
resource consumption be controlled such that There are two mitigations specified in this section -
RDMAP/DDP Streams which do not share Partial Mutual one requires a worst-case size of the CQ, and can be
Trust do not share RDMA Read Request Queue resources. implemented entirely within the Privileged Resource
Manager. The second approach requires cooperation
with the local application server (to not post too
many buffers), and enables a smaller CQ to be used.
* 7.5.3 Resource Consumption by Idle Applications on In some server environments, partial trust of the
page 36. Refer to Section 7.5.1. server application (but not the clients) is
acceptable, thus the smaller CQ fully mitigates the
remote attacker. In other environments, the local
server application could also contain untrusted
elements which can attack the local machine (or have
bugs). In those environments, the worst-case size of
the CQ must be used.
* 7.5.2.4 The section requires a Privileged Resource
Manager to not enable sharing of RDMA Read Request
Queues across multiple Streams that do not share
partial mutual trust. However, because the server
application knows best which of its Streams share
partial mutual trust, this requirement can be
reflected back to the application. The ULP (i.e.
server) requirement is that it MUST NOT request RDMA
Read Request Queues to be shared between applications
which do not have partial mutual trust.
* 7.5.5 Remote Invalidate an STag Shared on Multiple * 7.5.5 Remote Invalidate an STag Shared on Multiple
Streams on page 37. If DDP/RDMAP Streams do not share Streams on page 37. This mitigation is already
Partial Mutual Trust (i.e. the client may attempt to covered by section 7.3.2 (above).
invalidate the STag prematurely), it is NOT
RECOMMENDED that the server allow an STag to be valid
across multiple Streams.
12 Appendix B: Summary Table of Attacks 12 Appendix B: Summary of RNIC and ULP Implementation Requirements
Below is a summary of implementation requirements for the RNIC: Below is a summary of implementation requirements for the RNIC:
* 7.3.1 Buffer Overrun - RDMA Write or Read Response * 7.3.1 Buffer Overrun - RDMA Write or Read Response
* 7.4.8 Controlling Access to PTT & STag Mapping * 7.4.8 Controlling Access to PTT & STag Mapping
* 7.5.1 RNIC Resource Consumption * 7.5.1 RNIC Resource Consumption
* 7.5.2.1 Multiple Streams Sharing Receive Buffers * 7.5.2.1 Multiple Streams Sharing Receive Buffers
skipping to change at page 47, line 27 skipping to change at page 48, line 27
* 7.5.2.2 Local Peer Attacking a Shared CQ * 7.5.2.2 Local Peer Attacking a Shared CQ
* 7.5.2.3 Remote Peer Attacking a Shared CQ * 7.5.2.3 Remote Peer Attacking a Shared CQ
* 7.5.2.4 Attacking the RDMA Read Request Queue * 7.5.2.4 Attacking the RDMA Read Request Queue
* 7.5.4 Exercise of non-optimal code paths * 7.5.4 Exercise of non-optimal code paths
* 7.6 Elevation of Privilege * 7.6 Elevation of Privilege
* 8.2 Requirements for IPsec Encapsulation of DDP
Below is a summary of implementation requirements for the Below is a summary of implementation requirements for the
application above the RNIC: application above the RNIC:
* 7.2.4 Using an STag on a Different Stream * 7.2.4 Using an STag on a Different Stream
* 7.3.2 Modifying a Buffer After Indication * 7.3.2 Modifying a Buffer After Indication
* 7.4.2 Using RDMA Read to Access Stale Data * 7.4.2 Using RDMA Read to Access Stale Data
* 7.4.3 Accessing a Buffer After the Transfer * 7.4.3 Accessing a Buffer After the Transfer
* 7.4.4 Accessing Unintended Data With a Valid STag * 7.4.4 Accessing Unintended Data With a Valid STag
* 7.4.5 RDMA Read into an RDMA Write Buffer * 7.4.5 RDMA Read into an RDMA Write Buffer
* 7.4.6 Using Multiple STags Which Alias to the Same Buffer * 7.4.6 Using Multiple STags Which Alias to the Same Buffer
* 7.4.9 Network based eavesdropping
* 7.5.2.2 Local Peer Attacking a Shared CQ * 7.5.2.2 Local Peer Attacking a Shared CQ
* 7.5.5 Remote Invalidate an STag Shared on Multiple * 7.5.5 Remote Invalidate an STag Shared on Multiple
Streams Streams
13 Appendix C: Partial Trust Taxonomy 13 Appendix C: Partial Trust Taxonomy
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
 End of changes. 

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