RDMAP/DDP Security Draft

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

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

3. 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

4. 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).

5. 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”

6. 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...”?

7. 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

8. 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

9. 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??

10. Support Slides

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

12. 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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Attacks & Countermeasures

23. Combinations of Trust

24. 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?