RDMAP Security Section

Folks,

At Monday's IETF-61 RDDP WG session,  we discussed the security section of
the RDMAP specification.  We proposed that we discuss and review on this
reflector the overall structure of the security section.  Once we have
general agreement on the normative contents of that section,  the authors
(which will now include Bernard Metzler) will submit an updated RDMAP
specification draft with the proposed text.

Sooo...  following is a recap of what was discussed on Monday and the
proposed normative statements.  Of course, each normative statement will
have a little informative wrapper that puts the normative text in context,
but that text will be vetted out when the update to the RDMAP spec is
published.

Recap of the RDMAP Security Secion content - As discussed on Monday.

   The RDMAP Spec's security section will include normative text that
   describes **all** the security semantics that are relevant to the RDMA
   Protocol and associated informative text.  The latter will include
   extensive references to the RDMASEC for details.

   The proposed RDMAP Spec's security sections, consist of:
      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)

Proposed Normative Statements for the "Summary of RDMAP specific Security
Requirements" section:

   Two components MUST be provided to implement the RDMAP: an RDMA enabled
   NIC (RNIC) and a Privileged Resource Manager (PRM).  The RNIC MUST
   implement the RDMA wire Protocol and perform the security semantics
   described in this section. The PRM MUST implement the security semantics
   described in this section.

   RDMAP enabled NIC (RNIC) Requirements
      An RNIC MUST ensure that a specific Stream in a specific Protection
      Domain cannot 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 provide a mechanism for the ULP to establish and revoke
      the association of a ULP Buffer to an STag and TO range.
      An RNIC MUST provide a mechanism for the ULP to establish and revoke
      read, write, or read and write access to the ULP Buffer referenced by
      an STag.
      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 MUST ensure that if a CQ overflows, any Streams which do not
      use the CQ MUST remain unaffected.
      An RNIC implementation SHOULD provide a mechanism to cap the number
      of outstanding RDMA Read Requests.
      An RNIC MUST NOT enable firmware to be loaded on the RNIC directly
      from 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.

   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 that the Non-Privileged ULP has the right to access a
      specific Data Buffer before allowing an STag for which the ULP has
      access rights to 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 from
      allocating 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 Trust do 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 consume more than its fair share of resources so that
      the Local Peer can apply countermeasures to detect and prevent the
      attack.

Please review the above normative text proposal for completeness and
accuracy.

Thanks,

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp