RDMAP/DDP Security Draft draft-ietf-rddp-security-01.txt Jim Pinkerton, Ellen Deleganes, Sara Bitan

Agenda What’s new in this version What’s still to be done

Status of Security Draft Review Document outline/approach appears to be stable Major update/clarifications to text to resolve issues from reflector and private feedback –All feedback from last two IETF sessions done Possibly only minor work left –see end of talk for outstanding issues

Major Changes Revision history in Section 2.2, pdf version has change bars Section on Security Services for RDDP –Currently states SHOULD implement, where SHOULDs are derived from iSCSI security draft Moved “Trust Models” to an appendix and removed all reference to them in the document (including “partial trust”). Krause’s comments Changed “connection” to “Stream” (one or two places were missed – but in some cases it could be both (i.e. connection setup issues).

New Concepts Partial Mutual Trust – from reflector discussion, latest proposal is: A collection of RDMAP/DDP Streams are willing to assume that the local and remote end points of Streams from the collection will not perform malicious attacks against any of the Streams in the collection. Finer granularity interface to RNIC –Added discussion on Send Queue, Receive Queue, Completion Queue, Asynchronous Event Queue –Collapsed “Request Proxy Interface” into ”Application Control Interface” Defined semantics for Privileged vs. Non-Privileged application use of the “Application Control Interface”

New Concepts Resource sharing as a first-tier concept (based on feedback) - Added/modified sections to cover security threats for: –Shared Receive Buffers –Shared Completion Queue –RDMA Read Request Queue –Shared STags (and remote invalidate) 6 pages on “Security Services for RDDP” –Currently states “SHOULD” however RDDP is just a transport. But security services should be tailored to the application? Change this to section SHOULDs to “If IPSec is implemented, then, then XYZ is RECOMMENDED...”?

New Attacks in Specification Spoofing Attacks –Impersonation –Stream Hijacking –Man in the middle attack (rename only) –Unintended sharing of STags Information disclosure –Network based eavesdropping

Outstanding Issues Section 8: Security Section: –Reflector feedback on SSL limitations –Guidance for application protocols (like NFS) which implement security Section 9 – do we copy what is in IPS security draft? Should Appendix A: “Implementing Client/Server Protocols” stay or go? –Intent was to take generic statements in the spec and make specific comments in the context of Client/Server communications –Intended to provide no new requirements – just summarize existing ones from a Client/Server perspective –Concern is that we end up with some duplicated text from the body of the spec. –If section stays, it needs some cleanup

Outstanding Issues Summary Section – What is it supposed to summarize? –Application behavior focused - Attack Name by Attack Type, application behavior to enable attack (e.g. shared resources, mutual partial trust) by data transfer type used by application (Sends, RDMA Write, RDMA Read)? –Countermeasure focus - Attack Name by Attack Type, and countermeasure(s) used for attack PD, E2E Auth, Limit Scope, Resource Manager –Guidance would be appreciated – but preferably don’t choose both ;-) Draft status – informational or proposed standard? Anything else??

Support Slides

Functional Component Model Privileged Resource Manager Privileged Application Non-Privileged Application RNIC Engine firmware Admin Privileged Control Interface Privileged Data Interface Non-Privileged Data Interface Application Control Interface RNIC Interface (RI) Internet

Functional Components Privileged application –Assumed to not intentionally attack the system, but may be greedy for resources Non-privileged application –Desire to provide benefits of RDMAP/DDP without introducing additional security risk –Not trusted, granted only a subset of the capabilities granted to a privileged application Privileged Resource Manager –Controls allocation of “scarce” resources –Implements policies to detect and prevent DoS attacks

The RI in More Detail RI Send Queue Receive Queue Completion Queue Async Event Queue Resources: Page Translation Table, STag Table, Connection Context Memory Host Network RDMA Read Request Queue

Threats and Attack Classes Spoofing –Connection hijacking –Unauthorized STag use Tampering –Unauthorized modification of remote buffers Information Disclosure –Unauthorized read access to remote buffers Denial of Service –Consumption of “precious” resources Elevation of Privilege –Loading FW onto the RNIC = primary threat

Tampering Remote Peer attempts to tamper with buffers on a Local Peer –Attempt to write outside of the buffer bounds –Modify buffer contents after indicating buffer contents are ready for use –Using multiple STags to access the same buffer

Information Disclosure Remote peer attempts to improperly read information in buffers on a Local Peer –Use of RDMA Read to access stale data –Accessing buffer after transfer is over –Accessing unintended data through use of a valid STag –Using multiple STags to access the same buffer

Denial of Service Resource consumption –Receive data buffers when pool is shared –Completion Queue entries –RDMA Read Request Queue –Untagged receive buffers Remote invalidation of an STag across multiple connections

Tools for Counter Measures Protection Domain End-to-end authentication Limiting scope of: –STag Number of connections, amount of buffer advertised, time the buffer is advertised, randomly use the namespace –Buffer access rights Write-only, Read-only, Write/Read –Completion Queue One or more connections –Error generation/propagation Resource manager

Tools for Counter Measures Protection Domain End-to-end authentication Limiting scope of: –STag Number of connections, amount of buffer advertised, time the buffer is advertised, randomly use the namespace –Buffer access rights Write-only, Read-only, Write/Read –Completion Queue One or more connections –Error generation/propagation Resource manager

Counter Measures Protection Domain (PD) –Data buffers associated with an STag can be accessed only through connections in the same PD –Limit CQ access to connections in the same PD Limit STag scope –Limit SdTag usage to a single connection, or connections in the same PD –Limit the time the STag is valid by invalidating STag when data transfer is over –Limit the memory the STag can access by setting base and bounds to just the intended buffers

Counter Measures Set appropriate buffer access rights –Enable only the rights needed (read only, write only or read/write) –Local peer only access for buffers that do not require remote access Limit scope of error propagation/generation –Limit generation of error events to prevent event queue overflow Resource Manager –Put allocation of scarce resource under control of a Resource Manager

Attacks & Countermeasures Threat/Attack ClassPD E2E auth Limit scope Resource Manager STagBuffer Access CQ Error Spoofing Connection hijacking Unauthorized STag use Tampering Unauthorized data modification Information Disclosure Unauthorized data access Denial of Service Consumption of resources Elevation of Privilege Load FW on RNIC (Or not allow this feature)

Combinations of Trust Local Resource Sharing Local Trust? Remote Trust? NameExample Application NNNNS- NT RDDP/DDP client/server Networking NNYNS- RT Authenticated Remote Peer NYNKernel client NYYSimilar to S-T YNNS-NTTypical Networking YNY?? YYNS-LTStorage target YYYS-TMPI

Dimensions of Partial Trust Primarily a tool to educate the non-IETF RDMA community on the risks of traditional RDMA (local and remote trust) Within IETF the assumption is generally no remote trust, no local trust –Thus dimensions of trust could be simplified to just a local resource sharing issue i.e. Are local resources shared between streams? Should we remove dimensions of trust?