Bernard Metzler, Jim Pinkerton, and

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