draft-ietf-rddp-security-09.txt   draft-ietf-rddp-security-10.txt 
Internet Draft James Pinkerton Internet Draft James Pinkerton
draft-ietf-rddp-security-09.txt Microsoft Corporation draft-ietf-rddp-security-10.txt Microsoft Corporation
Category: Standards Track Ellen Deleganes Category: Standards Track Ellen Deleganes
Expires: November, 2006 Intel Corporation Expires: December, 2006 Intel Corporation
Sara Bitan
Microsoft Corporation
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 those that can be mitigated by using Attacks are grouped into those that can be mitigated by using
secure communication channels across the network, attacks from secure communication channels across the network, attacks from
Remote Peers, and attacks from Local Peers. Attack categories Remote Peers, and attacks from Local Peers. Attack categories
include spoofing, tampering, information disclosure, denial of include spoofing, tampering, information disclosure, denial of
service, and elevation of privilege. service, and elevation of privilege.
J. Pinkerton, et al. Expires November, 2006 1 J. Pinkerton, et al. Expires December, 2006 1
Table of Contents Table of Contents
1 Introduction.................................................4 1 Introduction.................................................4
2 Architectural Model..........................................7 2 Architectural Model..........................................7
2.1 Components...................................................8 2.1 Components...................................................8
2.2 Resources...................................................10 2.2 Resources...................................................10
2.2.1 Stream Context Memory.....................................10 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...................................11 2.2.3 Page Translation Tables...................................11
2.2.4 Protection Domain (PD)....................................11 2.2.4 Protection Domain (PD)....................................11
skipping to change at page 2, line ? skipping to change at page 2, line ?
5 Attacks That Can be Mitigated With End-to-End Security......20 5 Attacks That Can be Mitigated With End-to-End Security......20
5.1 Spoofing....................................................20 5.1 Spoofing....................................................20
5.1.1 Impersonation.............................................20 5.1.1 Impersonation.............................................20
5.1.2 Stream Hijacking..........................................21 5.1.2 Stream Hijacking..........................................21
5.1.3 Man-in-the-Middle Attack..................................21 5.1.3 Man-in-the-Middle Attack..................................21
5.2 Tampering - Network based modification of buffer content....22 5.2 Tampering - Network based modification of buffer content....22
5.3 Information Disclosure - Network Based Eavesdropping........22 5.3 Information Disclosure - Network Based Eavesdropping........22
5.4 Specific Requirements for Security Services.................22 5.4 Specific Requirements for Security Services.................22
5.4.1 Introduction to Security Options..........................23 5.4.1 Introduction to Security Options..........................23
5.4.2 TLS is Inappropriate for DDP/RDMAP Security...............23 5.4.2 TLS is Inappropriate for DDP/RDMAP Security...............23
5.4.3 ULPs Which Provide Security...............................24 5.4.3 DTLS and RDDP.............................................24
5.4.4 Requirements for IPsec Encapsulation of DDP...............24 5.4.4 ULPs Which Provide Security...............................24
5.4.5 Requirements for IPsec Encapsulation of DDP...............25
6 Attacks from Remote Peers...................................26 6 Attacks from Remote Peers...................................26
6.1 Spoofing....................................................26 6.1 Spoofing....................................................26
6.1.1 Using an STag on a Different Stream.......................26 6.1.1 Using an STag on a Different Stream.......................26
6.2 Tampering...................................................27 6.2 Tampering...................................................27
6.2.1 Buffer Overrun - RDMA Write or Read Response..............28 6.2.1 Buffer Overrun - RDMA Write or Read Response..............28
6.2.2 Modifying a Buffer After Indication.......................28 6.2.2 Modifying a Buffer After Indication.......................28
6.2.3 Multiple STags to access the same buffer..................29 6.2.3 Multiple STags to access the same buffer..................29
6.3 Information Disclosure......................................29 6.3 Information Disclosure......................................29
6.3.1 Probing memory outside of the buffer bounds...............29 6.3.1 Probing memory outside of the buffer bounds...............29
6.3.2 Using RDMA Read to Access Stale Data......................29 6.3.2 Using RDMA Read to Access Stale Data......................29
skipping to change at page 3, line 26 skipping to change at page 3, line 27
9 IANA Considerations.........................................43 9 IANA Considerations.........................................43
10 References..................................................44 10 References..................................................44
10.1 Normative References......................................44 10.1 Normative References......................................44
10.2 Informative References....................................44 10.2 Informative References....................................44
11 Appendix A: ULP Issues for RDDP Client/Server Protocols.....46 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.....................................................50 Requirements.....................................................50
13 Appendix C: Partial Trust Taxonomy..........................52 13 Appendix C: Partial Trust Taxonomy..........................52
14 Author's Addresses..........................................54 14 Author's Addresses..........................................54
15 Acknowledgments.............................................55 15 Acknowledgments.............................................55
16 Full Copyright Statement....................................56 16 Full Copyright Statement....................................57
Table of Figures Table of Figures
Figure 1 - RDMA Security Model....................................8 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
skipping to change at page 24, line 22 skipping to change at page 24, line 22
features of DDP/RDMAP - enabling implementations to have a features of DDP/RDMAP - enabling implementations to have a
flow-through architecture with little to no buffering, can flow-through architecture with little to no buffering, can
not be achieved if TLS is used to protect the data 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.
5.4.3 ULPs Which Provide Security 5.4.3 DTLS and RDDP
DTLS [DTLS] provides security services for datagram protocols,
including unreliable datagram protocols. These services include
anti-replay based on a mechanism adapted from IPsec that is
intended to operate on packets as they are received from the
network. For these and other reasons, DTLS is best applied to
RDDP by employing DTLS beneath TCP, yielding a layering of RDDP
over TCP over DTLS over UDP/IP. Such a layering inserts DTLS at
roughly the same level in the protocol stack as IPsec, making
DTLS's security services an alternative to IPsec's services from
an RDDP standpoint.
For RDDP, IPsec is the better choice for a security framework,
and hence is mandatory-to-implement (as specified elsewhere in
this document). An important contributing factor to the
specification of IPsec rather than DTLS is that the non-RDDP
versions of two initial adopters of RDDP (iSCSI [iSCSI][iSER] and
NFSv4 [NFSv4][NFSv4.1]) are compatible with IPsec but neither of
these protocols currently uses either TLS or DTLS. For the
specific case of iSCSI, IPsec is the basis for mandatory-to-
implement security services [RFC3723]. Therefore this document
and the RDDP protocol specifications contain mandatory
implementation requirements for IPsec rather than for DTLS.
5.4.4 ULPs Which Provide Security
ULPs which provide integrated security but wish to leverage ULPs which provide integrated security but wish to leverage
lower-layer protocol security should be aware of security lower-layer protocol security should be aware of security
concerns around correlating a specific channel's security concerns around correlating a specific channel's security
mechanisms to the authentication performed by the ULP. See mechanisms to the authentication performed by the ULP. See
[NFSv4CHANNEL] for additional information on a promising approach [NFSv4CHANNEL] for additional information on a promising approach
called "channel binding". From [NFSv4CHANNEL]: called "channel binding". From [NFSv4CHANNEL]:
"The concept of channel bindings allows applications to "The concept of channel bindings allows applications to
prove that the end-points of two secure channels at prove that the end-points of two secure channels at
different network layers are the same by binding different network layers are the same by binding
authentication at one channel to the session protection at authentication at one channel to the session protection at
the other channel. The use of channel bindings allows the other channel. The use of channel bindings allows
applications to delegate session protection to lower layers, applications to delegate session protection to lower layers,
which may significantly improve performance for some which may significantly improve performance for some
applications." applications."
5.4.4 Requirements for IPsec Encapsulation of DDP 5.4.5 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. 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.
skipping to change at page 46, line 5 skipping to change at page 45, line 23
[RFC3552] "Guidelines for Writing RFC Text on Security [RFC3552] "Guidelines for Writing RFC Text on Security
Considerations", Best Current Practice RFC, RFC 3552, July Considerations", Best Current Practice RFC, RFC 3552, July
2003. 2003.
[INFINIBAND] "InfiniBand Architecture Specification Volume 1", [INFINIBAND] "InfiniBand Architecture Specification Volume 1",
release 1.2, InfiniBand Trade Association standard. release 1.2, InfiniBand Trade Association standard.
http://www.infinibandta.org/specs. Verbs are documented in http://www.infinibandta.org/specs. Verbs are documented in
chapter 11. chapter 11.
[DTLS] E. Rescorla and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[iSCSI] J. Satran, et al, "Internet Small Computer Systems
Interface (iSCSI)", RFC 3720, April 2004.
[ISER] M. Ko, et al, "iSCSI Extensions for RDMA Specification",
Internet-Draft Work in Progress draft-ietf-ips-iser-05.txt,
October 2005.
[NFSv4] S. Shepler, et al, "Network File System (NFS) version 4
Protocol", RFC 3530, April 2003.
[NFSv4.1] S. Shepler, ed., "NFSv4 Minor Version 1", Internet-
Draft draft-ietf-nfsv4-minorversion1-03.txt, Work in
Progress, June 2006.
11 Appendix A: ULP Issues for RDDP Client/Server Protocols 11 Appendix A: ULP Issues for RDDP Client/Server Protocols
This section is a normative appendix to the document that is This section is a normative appendix to the document that is
focused on client/server ULP implementation requirements to focused on client/server ULP implementation requirements to
ensure a secure server implementation. 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 that have been defined in the prior section which countermeasures that have been defined in the prior section which
are applicable to creation of a secure ULP (e.g. application) are applicable to creation of a secure ULP (e.g. application)
skipping to change at page 47, 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.4 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
skipping to change at page 50, line 13 skipping to change at page 50, line 13
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 * 5.4.5 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.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
skipping to change at page 54, line 22 skipping to change at page 55, line 5
Email: jpink@windows.microsoft.com Email: jpink@windows.microsoft.com
Ellen Deleganes Ellen Deleganes
Intel Corporation Intel Corporation
MS JF5-355 MS JF5-355
2111 NE 25th Ave. 2111 NE 25th Ave.
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 (503) 712-4173 Phone: +1 (503) 712-4173
Email: ellen.m.deleganes@intel.com Email: ellen.m.deleganes@intel.com
15 Acknowledgments
Sara Bitan Sara Bitan
Microsoft Corporation Microsoft Corporation
Email: sarab@microsoft.com Email: sarab@microsoft.com
15 Acknowledgments
Allyn Romanow Allyn Romanow
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1 408 525 8836 Phone: +1 408 525 8836
Email: allyn@cisco.com Email: allyn@cisco.com
Catherine Meadows Catherine Meadows
Naval Research Laboratory Naval Research Laboratory
Code 5543 Code 5543
 End of changes. 14 change blocks. 
15 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/