RDMAP Security: Detailed Analysis and Countermeasures

1. RDMAP Security Section Bernard Metzler, Jim Pinkerton, and Renato J. Recio

2. RDMAP Security Section • Status • An informative reference was created by Bernard Metzler. • David Black reviewed the informative section and commented: • The RDMAP Spec really needs to be a stand-alone document,that contains all the relevant semantics associated with RDMAP,which means it needs to include all the normative [RDMASEC] references. • Assuming folks are cool with a normative approach… • The following slides describe the approachnot the exact text that will be added.

3. Proposed Security Sub-Sections • Summary of the Security Model and General Assumptions • Type of section – Informative • Contents: • Attackable Resources • Types of Attackers and Types of Attacks • Trust and Resource Sharing • Summary of RDMAP specific Security Requirements • Type of section – Normative • Contents: • Security Mechanisms • RDMAP Implementation Requirements • Non-Contents: • Responsibilities of the ULP are left in [RDMASEC] • Security Services for RDMAP • Type of section – Mix • Contents: • Informative summary of Available Security Services • Normative Requirements for IPsec Services for RDMAP (Xref RFC3723)

4. Informative summary of Security Model and General Assumptions • List of Attackable described in RDMASEC • Stream Context, Memory, Data Buffers, Page Translation Tables, STag Namespace, Completion Queues, Asynchronous Event Queues, RDMA Read Request Queues are vulnerable to attacks. • Types of Attackers and Types of Attacks • List of possible attackers: • A non-trusted remote peer, a network based attacker or a hostile local application. • List of attack types: • Use of the RDMAP communication channel to place the attack • Use of host RDMA infrastructure to gain access to local or remote resources. • List of attack categories: • Spoofing, Tampering, Information Disclosure, Denial of Service and Elevation of Privilege. • Trust and Resource Sharing • Brief description of responsibilities: • The ULP itself must take appropriate actions to protect exposed resources from attacks. • The sharing of resources across Streams should be under the control of the ULP, in terms of: • the trust model the ULP wishes to operate under, • the level of resource sharing the ULP wishes to give Local Peer processes. • Reference [RDMASEC] for further details on the above.

5. RDMAP specific Security Requirements • This section will describe the required attack countermeasuresas RNIC and Privileged Resource Manager Requirements. • RDMAP enabled NIC (RNIC) Requirements • An RNIC MUST ensure that a specific Stream in a specific Protection Domaincannot access an STag in a different Protection Domain. • An RNIC MUST ensure that if an STag is limited in scope to a single Stream,no other Stream can use the STag. • An RNIC MUST ensure that a Remote Peer is not able to access memory outside of the buffer specified when the STag was enabled for remote access. • An RNIC MUST ensure that the network interface can no longer modify an advertised buffer after the ULP revokes remote access rights for an STag. • An RNIC MUST NOT enable sharing a CQ across ULPs that do not share partial mutual trust. • An RNIC implementation SHOULD provide a mechanism to cap the number of outstanding RDMA Read Requests. • An RNIC MUST ensure that if a CQ overflows, any Streams which do not use the CQ MUST remain unaffected. • An RNIC MUST NOT enable firmware to be loaded on the RNIC directlyfrom an untrusted Local Peer or Remote Peer, unless the Peer is properly authenticated(by a mechanism outside the scope of this specification. The mechanism presumably entails authenticating that the remote ULP has the right to perform the update), and the update is done via a secure protocol, such as IPsec.

6. RDMAP specific Security Req’s… Continued • Privileged Resources Manager Requirement • All Non-Privileged ULP interactions with the RNIC Engine that could affect other ULPs MUST be done using the Privileged Resource Manager as a proxy. • All ULP resource allocation requests for scarce resources MUST also be done using a Privileged Resource Manager. • The Privileged Resource Manager MUST NOT assume different ULPs share Partial Mutual Trust unless there is a mechanism to ensure that the ULPs do indeed share partial mutual trust. • If Non-Privileged ULPs are supported, the Privileged Resource Manager MUST verify thatthe Non-Privileged ULP has the right to access a specific Data Buffer before allowing an STag for which the ULP has access rightsto be associated with a specific Data Buffer. • The Privileged Resource Manager MUST control the allocation of CQ entries. • The Privileged Resource Manager SHOULD prevent a Local Peer fromallocating more than its fair share of resources. • RDMA Read Request Queue resource consumption MUST be controlled by the Privileged Resource Manager such that RDMAP/DDP Streams which do not share Partial Mutual Trustdo not share RDMA Read Request Queue resources. • If an RNIC provides the ability to share receive buffers across multiple Streams,the combination of the RNIC and the Privileged Resource Manager MUST be able to detect if the Remote Peer is attempting to consumemore than its fair share of resourcesso that the Local Peer can apply countermeasures to detect and prevent the attack.

7. Security Services for RDMAP • Informative text that states: • RDMAP uses an IP based network services, therefore, all exchanged control and data packets are vulnerable to spoofing, tampering and information disclosure attacks. • IPsec protocol suite [RFC2401] defines strong countermeasures to protect an IP stream from those attacks. • State that by remaining independent of ULP and LLP security protocols, RDMAP will benefit from continuing improvements at those layers. • Requirements for IPsec Services for RDMAP • MUST implement, but MAY enable • Cross reference RFC3723 normative sections • State that an implementation of the RDDP protocol suite MUST also implement IPsec services as outlined in Section 2.3 of [RFC3723] and MUST follow the requirements of Section 5 (ULP and Transport Attributes) of the RDMAP Spec. • IPsec packets are processed (e.g., integrity checked and possibly decrypted) in the order they are received. • An RDMAP Data Sink will process the decrypted RDMA Messages contained in these packets in the same manner as RDMA Messages contained in unsecured IP packets. • State that IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, idle SAs may be dynamically brought down and a new SA be brought up again, if activity resumes. Thus, the receipt of a IKE Phase 2 delete message MUST NOT be interpreted as a reason for tearing down the RDMAP stream.