[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Draft                                 Jim Pinkerton
Document: draft-pinkerton-rddp-security-00.txt   Microsoft Corporation
Expires: December, 2003                        Ellen Deleganes
                                                 Intel Corporation
                                               Bernard Aboba
                                                 Microsoft Corporation


                                               June 2003




                            DDP/RDMAP Security

1  Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

2  Abstract

   This document analyzes security issues around implementation and use
   of the Direct Data Placement Protocol(DDP) and Remote Direct Memory
   Access Protocol (RDMAP). It first defines an architectural model for
   an RDMA Network Interface Card (RNIC), which can implement DDP or
   RDMAP and DDP. The model includes a definition of resources that can
   be attacked. This document then introduces various Trust Models
   between a local peer and a remote peer and the tools that can be
   used to create countermeasures against attacks. Finally, the
   document reviews various attacks and the countermeasures to be used
   against them, grouping the attacks into spoofing, tampering,

J. Pinkerton, et al.    Expires December 2003                       1

Internet-Draft           RDDP/RDMAP Security              June 2003

   information disclosure, denial of service, and elevation of
   privilege.














































J. Pinkerton, et al.   Expires - December 2003               [Page 2]

Internet-Draft           RDDP/RDMAP Security              June 2003

   Table of Contents

   1    Status of this Memo.........................................1
   2    Abstract....................................................1
   2.1  Issues......................................................4
   3    Introduction................................................5
   4    Architectural Model.........................................7
   4.1  Components..................................................8
   4.2  Resources...................................................9
   4.2.1  Connection Context Memory..................................9
   4.2.2  Data Buffers...............................................9
   4.2.3  Page Translation Tables...................................10
   4.2.4  STag Namespace............................................10
   4.2.5  Completion Queues.........................................10
   4.2.6  RDMA Read Request Queue...................................10
   4.3  System Properties..........................................10
   5    Trust Models...............................................11
   6    Attacker Capabilities......................................13
   7    Attacks and Countermeasures................................14
   7.1  Tools for Countermeasures..................................14
   7.1.1  Protection Domain (PD)....................................14
   7.1.2  Limiting STag Scope.......................................14
   7.1.3  Access Rights.............................................15
   7.1.4  Limiting the Scope of the Completion Queue................15
   7.1.5  Limiting the Scope of an Error............................16
   7.2  Spoofing...................................................16
   7.2.1  Using an STag on a different connection...................16
   7.3  Tampering..................................................17
   7.3.1  RDMA Write or RDMA Read Response to Memory Outside of the
   Buffer 18
   7.3.2  Modifying a Buffer After Indicating the Contents Are Ready18
   7.4  Information Disclosure.....................................19
   7.4.1  Probing memory outside of the buffer bounds...............19
   7.4.2  Using RDMA Read to Access Stale Data......................19
   7.4.3  Accessing a buffer after the transfer is over.............20
   7.4.4  Accessing data within a valid STag that was unintended....20
   7.4.5  Using RDMA Read on a buffer meant only for RDMA Write.....20
   7.4.6  Using Multiple Stags to access the same buffer............21
   7.4.7  Remote node loading firmware onto the RNIC................21
   7.5  Denial of Service (DOS)....................................21
   7.5.1  RNIC Resource Consumption.................................21
   7.5.2  Resource Consumption By Active Applications...............22
   7.5.2.1   Receive Data Buffers..................................23
   7.5.2.2   Completion Queue (CQ) Resource Consumption............24
   7.5.2.3   RDMA Read Request Queue...............................26
   7.5.3  Resource Consumption by Idle Applications.................27
   7.5.4  Exercise of non-optimal code paths........................27

J. Pinkerton, et al.   Expires - December 2003               [Page 3]

Internet-Draft           RDDP/RDMAP Security              June 2003

   7.6  Elevation of Privilege.....................................28
   7.6.1  Loading Firmware into the RNIC............................28
   8    IPsec and RDDP.............................................29
   8.1  Introduction to IPsec......................................29
   8.2  Recommendations for IPsec Encapsulation of RDDP............30
   9    Summary Table of Attacks and Trust Models..................31
   10   References.................................................33
   10.1   Normative References......................................33
   10.2   Informative References....................................34
   11   AuthorÆs Addresses.........................................35
   12   Acknowledgments............................................36
   13   Full Copyright Statement...................................37


   Table of Figures

   Figure 1 û RDMA Security Model....................................7
   Figure 2 û Summary Attacks and Trust Model Table.................32



2.1  Issues

   This section is temporary and will go away when all issues have been
   resolved.

   Note: this is far from a complete list of issues; as more are
   raised, they will be added to this list until some sort of consensus
   is reached.  They are in the order found in the specification.

   Issue: IPsec recommendations for RDMAP/DDP.......................30

















J. Pinkerton, et al.   Expires - December 2003               [Page 4]

Internet-Draft           RDDP/RDMAP Security              June 2003

3  Introduction

   RDMA enables new levels of flexibility when communicating between
   two parties compared to current conventional networking practice
   (e.g. a stream-based model or datagram model). This flexibility
   brings new security issues that must be carefully understood when
   designing application protocols utilizing RDMA and when implementing
   RDMA-aware NICs (RNICs). Note that for the purposes of this security
   analysis, an RNIC may implement RDMAP and DDP, or just DDP.

   This specification is work in progress û the intent is to begin the
   discussion with a well thought out framework to analyze the issues.
   An area of particular concern is that there may be more attacks
   possible than have been enumerated here.

   The specification first develops an architectural model that is
   relevant for the security analysis û it details components,
   resources, and system properties that may be attacked. The
   specification then defines Trust Models. Trust is defined as:

        Trust - When one party depends upon the other party to not
        subvert the goals of the protocols, e.g., it will not attempt
        to perform the following attacks: spoofing, repudiation,
        information disclosure, denial of service, or elevation of
        privilege.

   An Untrusted peer is a party that may (or may not) attempt to
   perform one or more of the above attacks. A partially trusted peer
   (either the Local Peer or Remote Peer) may be trusted to not attempt
   to perform some subset of the above attacks, but not trusted to
   perform a different subset.

   For the Untrusted peer, a brief list of capabilities is enumerated.
   The rest of the specification is focused on analyzing attacks.
   First, the tools for mitigating attacks are listed, and then a
   series of attacks on components, resources, or system properties is
   enumerated. For each attack, possible countermeasures are reviewed.

   Applications within a host are divided into two categories û
   Privileged and Non-Privileged. Both application types can send and
   receive data and request resources. The key differences between the
   two are:

        The Privileged Application is partially trusted. It is assumed
        that the Privileged Application will not intentionally attack
        the system (e.g., it is a kernel application), although it may
        be greedy for resources.

J. Pinkerton, et al.   Expires - December 2003               [Page 5]

Internet-Draft           RDDP/RDMAP Security              June 2003

        A Non-Privileged ApplicationÆs capabilities are a logical sub-
        set of the Privileged ApplicationÆs. It is assumed by the local
        host infrastructure that a Non-Privileged Application is
        Untrusted. All Non-Privileged Application interactions with the
        RNIC Engine that could affect other applications need to be
        done through a Trusted intermediary that can verify the Non-
        Privileged Application requests.









































J. Pinkerton, et al.   Expires - December 2003               [Page 6]

Internet-Draft           RDDP/RDMAP Security              June 2003

4  Architectural Model

   This section describes an RDMA architectural reference model that is
   used as security issues are examined. It introduces the components
   of the model, the resources that can be attacked, and the system
   properties, which should be preserved when under attack.

   Figure 1 shows the components comprising the architecture and the
   interfaces where potential security attacks could be launched.
   External attacks can be injected into the system from an application
   that sits above the RI or from the Internet.


             +-------------+     Request Proxy Interface
             |  Privileged |<--------------------------------+
             |  Resource   |                                 |
    Admin<-->|  Manager    |     App Control Interface       |
             |             |<------+-------------------+     |
             +-------------+       |                   |     |
                   ^               v                   v     v
                   |         +-------------+   +-----------------+
                   |         | Privileged  |   |  Non-Privileged |
                   |         | Application |   |  Application    |
                   |         +-------------+   +-----------------+
                   |               ^                   ^
                   |Privileged     |Privileged         |Non-Privileged
                   |Control        |Data               |Data
                   |Interface      |Interface          |Interface
   RNIC            |               |                   |
   Interface(RI)   v               v                   v
   =================================================================

         +-----------------------------------------+
         |                                         |
         |               RNIC Engine               | <------ Firmware
         |                                         |
         +-----------------------------------------+
                             ^
                             |
                             v
                          Internet

                      Figure 1 û RDMA Security Model





J. Pinkerton, et al.   Expires - December 2003               [Page 7]

Internet-Draft           RDDP/RDMAP Security              June 2003

4.1  Components

   The components shown in Figure 1 û RDMA Security Model are:

       *   RNIC Engine û the component that implements the RDMA
           protocol and/or DDP protocol.

       *   Privileged Resource Manager û the component responsible for
           managing and allocating resources associated with the RNIC
           Engine. The Resource Manager does not send or receive data.

       *   Privileged Application û See Section 3 Introduction for a
           definition of Privileged Application. The local host
           infrastructure can enable the Privileged Application to map
           a data buffer directly from the RNIC Engine to the host
           through the RNIC Interface, but it does not allow the
           Privileged Application to directly consume RNIC Engine
           resources.

       *   Non-Privileged Application û See Section 3 Introduction for
           a definition of Non-Privileged Application. All Non-
           Privileged Application interactions with the RNIC Engine
           that could affect other applications MUST be done using the
           Privileged Resource Manager as a proxy.

   A design goal of the DDP and RDMAP protocols is to allow, under
   constrained conditions, Non-Privileged applications to send and
   receive data directly to/from the RDMA Engine without Privileged
   Resource Manager intervention - while ensuring that the host remains
   secure. Thus, one of the primary goals of this paper is to analyze
   this usage model for the enforcement that is required in the RNIC
   Engine to ensure the system remains secure.

   The host interfaces that could be exercised include:

       *   Control Interface - A Privileged Resource Manager uses the
           RI to allocate and manage RNIC Engine resources, control the
           state within the RNIC Engine, and monitor various events
           from the RNIC Engine. It also uses this interface to act as
           a proxy for some operations that a Non-Privileged
           Application may require (after performing appropriate
           countermeasures).

       *   Non-Privileged Data Transfer Interface û A Non-Privileged
           Application uses this interface to initiate and to check the
           status of data transfer operations.


J. Pinkerton, et al.   Expires - December 2003               [Page 8]

Internet-Draft           RDDP/RDMAP Security              June 2003

       *   Privileged Data Transfer Interface û A superset of the
           functionality provided by the Non-Privileged Data Transfer
           Interface. The application is allowed to directly manipulate
           RNIC Engine mapping resources to map an STag to an
           application data buffer.

       *   Request Proxy Interface û a Non-Privileged Application uses
           this interface to control RNIC Engine resources that could
           affect other applications û such as manipulating the RNIC
           Engine's mapping of an STag to an application data buffer.
           The Privileged Resource Manager implements countermeasures
           to ensure that if the Non-Privileged Application launches an
           attack it can prevent the attack from affecting other
           applications.

       *   Figure 1 also shows the ability to load new firmware in the
           RNIC Engine. Not all RNICs will support this, but it is
           shown for completeness and is also reviewed under potential
           attacks.

   If Internet control messages, such as ICMP, ARP, RIPv4, etc. are
   processed by the RNIC Engine, the threat analyses for those
   protocols is also applicable, but outside the scope of this paper.

4.2  Resources

   This section describes the primary resources in the RNIC Engine that
   could be affected if under attack. For RDMAP, all of the defined
   resources apply. For DDP, all of the resources except the RDMA Read
   Queue apply.

4.2.1  Connection Context Memory

   The state information for each connection is maintained in memory,
   which could be located in a number of places - on the NIC, inside
   RAM attached to the NIC, in host memory, or in any combination of
   the three, depending on the implementation.

4.2.2  Data Buffers

   There are two different ways to expose a data buffer; a buffer can
   be exposed for receiving RDMAP Send Type Messages (a.k.a. DDP
   Untagged Messages) on DDP Queue zero or the buffer can be exposed
   for remote access through STags (a.k.a. DDP Tagged Messages). This
   distinction is important because the attacks and the countermeasures
   used to protect against the attack are different depending on the
   method for exposing the buffer to the Internet.

J. Pinkerton, et al.   Expires - December 2003               [Page 9]

Internet-Draft           RDDP/RDMAP Security              June 2003

4.2.3  Page Translation Tables

   Page Translation Tables are the structures used by the RNIC to be
   able to access application memory for data transfer operations. Even
   though these structures are called "Page" Translation Tables, they
   may not reference a page at all û conceptually they are used to map
   an application address space representation of a buffer to the
   physical addresses that are used by the RNIC Engine to move data. If
   on a specific system, a mapping is not used, then a subset of the
   attacks examined may be appropriate.

4.2.4  STag Namespace

   The DDP specification defines a 32-bit namespace for the STag.
   Implementations may vary in terms of the actual number of STags that
   are supported. In any case, this is a bounded resource that can come
   under attack.

4.2.5  Completion Queues

   Completion Queues are used in this specification to conceptually
   represent how the RNIC Engine notifies the Application of the
   completion of the transmission of data, or the completion of the
   reception of data through the Data Transfer Interface. Because there
   could be many transmissions or receptions in flight at any one time,
   completions are modeled as a queue rather than a single event. An
   implementation may also use the Completion Queue to notify the
   application of other activities, for example, the completion of a
   mapping of an STag to a specific application buffer.

4.2.6  RDMA Read Request Queue

   The RDMA Read Request Queue is the memory holding state information
   for one or more RDMA Read Request Messages that have arrived, but
   for which the RDMA Read Response Messages have not yet been
   completely sent.

4.3  System Properties

   System properties that can be attacked included system integrity,
   system stability (liveness, large fluctuations in performance), and
   confidentiality.






J. Pinkerton, et al.   Expires - December 2003              [Page 10]

Internet-Draft           RDDP/RDMAP Security              June 2003

5  Trust Models

   The Trust Models described in this section have three primary
   distinguishing characteristics.

       *   Local Resource Sharing (yes/no) - When local resources are
           shared, they are shared across a grouping of RDMAP/DDP
           Streams. If local resources are not shared, the resources
           are dedicated on a per Stream basis. Resources are defined
           in Section 4.2 - Resources on page 9. The advantage of not
           sharing resources between Streams is that it reduces the
           number of types of attacks that are possible. The
           disadvantage is that applications might run out of
           resources.

       *   Local Trust (yes/no) û Local Trust is determined based on
           whether the local grouping of RDMAP/DDP Streams (which
           typically equates to one application or group of
           applications) mutually trust each other.

       *   Remote Trust (yes/no) û The Remote Trust level is determined
           based on whether the Local Peer of a specific RDMAP/DDP
           Stream trusts the Remote Peer of the Stream (using the same
           definition of trust as stated in the definition of Trust in
           Section 3 Introduction).

   It is assumed in this paper that the component that implements the
   mechanism to control sharing of RNIC Engine resources, is the
   Privileged Resource Manager. The RNIC Engine exposes its resources
   through the RI to the Privileged Resource Manager. All Privileged
   and Non-Privileged applications request resources from the Resource
   Manager. The Resource Manager implements resource management
   policies to ensure fair access to resources. The Resource Manager
   should be designed to take into account security attacks detailed in
   this specification.

   The sharing of resources across connections should be under the
   control of the application, both in terms of the Trust Model the
   application wishes to operate under, as well as the level of
   resource sharing the application wishes to give Local Peer
   processes.

   Not all of the combinations of the trust characteristics are
   expected to be used by applications. This paper specifically
   analyzes five application Trust Models that are expected to be in
   common use. The Trust Models are as follows:


J. Pinkerton, et al.   Expires - December 2003              [Page 11]

Internet-Draft           RDDP/RDMAP Security              June 2003

   1.  NS-NT - Non-Shared Local Resources, no Local Trust, no Remote
       Trust û typically a server application that wants to run in a
       mode that has the least number of potential attacks.

   2.  NS-RT - Non-Shared Local Resources, no Local Trust, Remote Trust
       û typically a peer-to-peer application, which has, by some
       method outside of the scope of this specification, authenticated
       the Remote Peer. <TBD: mention authentication>

   3.  S-NT - Shared Local Resources, no Local Trust, no Remote Trust û
       typically a server application that runs in an untrusted
       environment where the amount of resources required is either too
       large or too dynamic to dedicate for each RDMAP/DDP Stream.

   4.  S-LT - Shared Local Resources, Local Trust, no Remote Trust û
       typically an application, which provides a session layer and
       uses multiple Streams, to provide additional throughput or fail-
       over capabilities. All of the Streams within the local
       application trust each other, but do not trust the remote peer.

   5.  S-T - Shared Local Resources, Local Trust, Remote Trust û
       typically a distributed application, such as a distributed
       database application or a High Performance Computer (HPC)
       application, which is intended to run on a cluster. Due to
       extreme resource and performance requirements, the application
       typically authenticates with all of its peers and then runs in a
       highly trusted environment. The application peers are all in a
       single application fault domain and depend on one another to be
       well-behaved when accessing data structures. If a trusted Remote
       Peer has an implementation defect that results in poor behavior,
       the application could be corrupted. <TBD: mention
       authentication>

   Models NS-NT and S-NT above are typical for Internet networking û
   neither other Local Peers nor the Remote Peer is trusted. Sometimes
   optimizations can be done that enable sharing of Page Translation
   Tables across multiple Local Peers, thus Model S-LT can be
   advantageous. Model S-T is typically used when resource scaling
   across a large parallel application makes it infeasible to use any
   other model. Resource scaling issues can either be due to
   performance around scaling or because there simply are not enough
   resources. Model NS-RT is probably the least likely model to be
   used, but is presented for completeness.





J. Pinkerton, et al.   Expires - December 2003              [Page 12]

Internet-Draft           RDDP/RDMAP Security              June 2003

6  Attacker Capabilities

   An attackerÆs capabilities delimit the types of attacks that
   attacker is able to launch. RDMAP and DDP require that the initial
   LLP Stream (and connection) be set up prior to transferring
   RDMAP/DDP Messages. For the attacker to actively generate an
   RDMAP/DDP protocol attack, it must have the capability to both send
   and receive messages. Attackers with send only capabilities should
   be addressed by the LLP, not by RDMAP/DDP.







































J. Pinkerton, et al.   Expires - December 2003              [Page 13]

Internet-Draft           RDDP/RDMAP Security              June 2003

7  Attacks and Countermeasures

   This section describes the attacks that are possible against the
   RDMA system defined in Figure 1 û RDMA Security Model and the RNIC
   Engine resources defined in Section 4.2. The analysis includes a
   detailed description of each attack, the Trust Models the attack
   applies to (see Section 5 for a description of the Trust Models),
   and a description of the countermeasures appropriate to the Trust
   Model(s) that can be taken to thwart the attack.

   Note that, connection setup and teardown is presumed to be done in
   stream mode (i.e. no RDMA encapsulation of the payload), so there
   are no new attacks related to connection setup/teardown beyond what
   is already present in the LLP (e.g. TCP or SCTP). Consequently, any
   existing analysis of Spoofing, Tampering, Repudiation, Information
   Disclosure, Denial of Service, or Elevation of Privilege continues
   to apply. Thus, the analysis in this section focuses on attacks that
   are present regardless of the LLP Stream type.

7.1  Tools for Countermeasures

   The tools described in this section are the primary mechanisms that
   can be used to provide countermeasures to potential attacks.

7.1.1  Protection Domain (PD)

   Protection Domains are associated with two of the resources of
   concern, connection context memory and STags associated with data
   buffers. Protection Domains are used mainly to ensure that an STag
   can only be used to access the associated data buffer through
   connections in the same Protection Domain as that STag.

   For the Trust Models that are defined to have non-shared resources
   (Trust Models NS-NT and NS-RT), it is recommended that each Stream
   be associated with its own, unique Protection Domain. For those
   Trust Models where resources are shared (Trust Models S-NT, S-LT and
   S-T), it is recommended that Protection Domain be limited to the
   number of Streams that share the same Trust Model.

7.1.2  Limiting STag Scope

   The key to protecting a local data buffer is to limit the scope of
   its STag to the level appropriate for the Trust Model. The scope of
   the STag can be measured in multiple ways.

       *   Number of Connections and/or Streams on which the STag is
           valid. One way to limit the scope of the STag is to limit

J. Pinkerton, et al.   Expires - December 2003              [Page 14]

Internet-Draft           RDDP/RDMAP Security              June 2003

           the connections and/or Streams that are allowed to use the
           STag. As noted in the previous section, use of Protection
           Domains appropriately can limit the scope of the STag. It is
           also possible to create an STag that is valid only on a
           single connection, even in the case where several
           connections are associated with the Protection Domain of the
           STag.

       *   Limit the time an STag is valid. By Invalidating an
           Advertised STag (e.g., revoking remote access to the buffers
           described by an STag when done with the transfer), an entire
           class of attacks can be eliminated.

       *   Limit the buffer the STag can reference. Limiting the scope
           of an STag access to *just* the intended buffers to be
           exposed is critical to prevent certain forms of attacks.

7.1.3  Access Rights

   Access Rights associated with a specific Advertised STag or
   RDMAP/DDP Stream provide another mechanism for applications to limit
   the attack capabilities of the Remote Peer. The Local Peer can
   control whether a data buffer is exposed for local only, or local
   and remote access, and assign specific access privileges (read,
   write, read and write).

   For DDP, when an STag is advertised, the Remote Peer is presumably
   given write access rights to the data (otherwise there was not much
   point to the advertisement). For RDMAP, when an application
   advertises an STag, it can enable write-only, read-only, or both
   write and read access rights.

   Similarly, some applications may wish to provide a single buffer
   with different access rights on a per-connection or per-Stream
   basis. For example, some connections may have read-only access, some
   may have remote read and write access, while on other connections
   only the Local Peer is allowed access.

7.1.4  Limiting the Scope of the Completion Queue

   Completions associated with sending and receiving data, or setting
   up buffers for sending and receiving data, could be accumulated in a
   shared Completion Queue for a group of RDMAP/DDP Streams, or a
   specific RDMAP/DDP Stream could have a dedicated Completion Queue.
   Limiting Completion Queue association to one, or a small number of
   RDMAP/DDP Streams can prevent several forms of Denial of Service
   attacks.

J. Pinkerton, et al.   Expires - December 2003              [Page 15]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.1.5  Limiting the Scope of an Error

   To prevent a variety of attacks, it is important that an RDMAP/DDP
   implementation be robust in the face of errors. If an error on a
   specific Stream can cause other unrelated Streams to fail, then a
   broad class of attacks are enabled against the implementation.

7.2  Spoofing

   Because the RDMAP Stream is only offloaded if it is in the
   ESTABLISHED state, certain types of traditional forms of wire
   attacks do not apply -- an end-to-end handshake must have occurred
   to establish the RDMAP Stream. So, the only form of spoofing that
   applies is one when a remote node can both send and receive packets.

   If a man-in-the-middle has the ability to inject packets, which will
   be accepted by the LLP (e.g., TCP sequence number is correct), one
   style of attack is for the man-in-the-middle to send Tagged Messages
   (either RDMAP or DDP). If it can discover a buffer that has been
   exposed for STag enabled access, then the man-in-the-middle can use
   an RDMA Read operation to read the contents of the associated data
   buffer, perform an RDMA Write Operation to modify the contents of
   the associated data buffer, or invalidate the STag to disable
   further access to the buffer. The only countermeasure for this form
   of attack is to either secure the RDMAP/DDP Stream or attempt to
   provide physical security to prevent man-in-the-middle type access.

   The best protection against this form of attack is end-to-end
   authentication, such as IPsec (see Section 8 IPsec and RDDP on page
   29), to prevent spoofing or tampering. If authentication is not
   used, then a man-in-the-middle attack can occur, enabling spoofing,
   tampering, and repudiation.

   Another approach is to restrict access to only the local
   subnet/link, and provide some mechanism to limit access, such as
   physical security or 802.1.x. This model is an extremely limited
   deployment scenario, and will not be further examined here.

7.2.1  Using an STag on a different connection

   One style of attack from the Remote Peer is for it to attempt to use
   STag values that it is not authorized to use. Note that, if the
   Remote Peer sends an invalid STag to the Local Peer, per the DDP and
   RDMAP specifications, the connection must be torn down. Thus, the
   threat exists if an STag has been enabled for Remote Access on one
   connection and a Remote Peer is able to use it on an unrelated
   connection. If the attack is successful, the attacker could

J. Pinkerton, et al.   Expires - December 2003              [Page 16]

Internet-Draft           RDDP/RDMAP Security              June 2003

   potentially be able to perform either RDMA Read Operations to read
   the contents of the associated data buffer, perform RDMA Write
   Operations to modify the contents of the associated data buffer, or
   to Invalidate the STag to disable further access to the buffer.

   An attempt by a Remote Peer to access a buffer with an STag on a
   different connection in the same Protection Domain may or may not be
   an attack depending on the Trust Model employed by the application.
   For Trust Model S-T, where resources are shared between connections,
   and both Local and Remote Peers are Trusted, using an STag on
   multiple connections within the same Protection Domain is allowed,
   and could be desired behavior. For the other four Trust Models where
   the Remote Peer is not Trusted, and/or resources are not intended to
   be shared, attempting to use an STag on a different connection could
   be considered to be an attack.

   In the case where the Trust Model is defined with no shared
   resources between connections (Trust Models NS-NT and NS-RT), this
   attack can be defeated by assigning each connection to a different
   Protection Domain. Before allowing remote access to the buffer, the
   Protection Domain of the connection where the access attempt was
   made is matched against the Protection Domain of the STag. If the
   Protection Domains do not match, access to the buffer is denied, an
   error is generated, and the RDMAP Stream associated with the
   attacking connection should be terminated. Thus, for Trust Models
   NS-NT and NS-RT, it is RECOMMENDED that each connection be in a
   separate Protection Domain.

   For Trust Models S-NT and S-LT, where resources are shared, but the
   Remote Peers are Untrusted, it may not be practical to separate each
   connection into its own Protection Domain. In this case, the
   application can still limit the scope of any of the STags it is
   enabling for remote access to a single connection. If the STag scope
   has been limited to a single connection, any attempt to use that
   STag on a different connection will result in an error, and the RDMA
   Stream associated with that connection should be terminated. Thus,
   for Trust Models S-NT and S-LT, it is RECOMMENDED that the scope of
   an STag be limited to a single connection.

7.3  Tampering

   A Remote Peer can attempt to tamper with the contents of data
   buffers on a Local Peer that have been enabled for remote write
   access. The types of tampering attacks that are possible are
   outlined in the sections that follow.



J. Pinkerton, et al.   Expires - December 2003              [Page 17]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.3.1  RDMA Write or RDMA Read Response to Memory Outside of the Buffer

   This attack is an attempt by the Remote Peer to perform an RDMA
   Write or RDMA Read Response to memory outside of the valid length
   range of the data buffer enabled for remote write access. This
   attack applies primarily to Trust Models with Untrusted Remote Peers
   (NS-NT, S-NT and S-LT), and can occur even when no resources are
   shared across connections.

   The countermeasure for this type of attack must be in the RNIC
   implementation, using the STag. When the Local Peer specifies to the
   RI, the base and the number of bytes in the buffer that it wishes to
   make accessible, the RI must ensure that the base and bounds check
   are applied to any access to the buffer referenced by the STag
   before the STag is enabled for access. When an RDMA data transfer
   operation (which includes an STag) arrives on a connection, a base
   and bounds byte granularity access check must be performed to ensure
   the operation accesses only memory locations within the buffer
   described by that STag.

   Thus, it is RECOMMENDED that an RI implementation ensure that a
   Remote Peer, regardless of Trust Model, will not be able to access
   memory outside of the buffer specified when the STag was enabled for
   remote access.

7.3.2  Modifying a Buffer After Indicating the Contents Are Ready

   This attack occurs if a Remote Peer attempts to modify the contents
   by performing an RDMA Write or an RDMA Read Response after it had
   indicated to the Local Peer that the data buffer contents were ready
   for use.

   This attack applies primarily to the Trust Models where the Remote
   Peers are not Trusted (Trust Models NS-NT, S-NT and S-LT), and can
   occur even when no resources are shared across connections. Note
   that, an error on the part of a Trusted Remote Peer could also
   result in this problem.

   The Local Peer can protect itself from this type of attack by
   revoking remote access when the original data transfer has completed
   and before it validates the contents of the buffer. The Local Peer
   can either do this by explicitly revoking remote access rights for
   the STag when the Remote Peer indicates the operation has completed,
   or by checking to make sure the Remote Peer Invalidated the STag
   through the RDMAP Invalidate capability, and if it did not, the
   Local Peer then explicitly revokes the STag remote access rights.


J. Pinkerton, et al.   Expires - December 2003              [Page 18]

Internet-Draft           RDDP/RDMAP Security              June 2003

   It is RECOMMENDED that the Local Peer follow the above procedure for
   Trust Models NS-NT, S-NT, and S-LT to protect the buffer. The Local
   Peer MAY also wish to use this procedure for Trust Models NS-RT and
   S-T to protect itself from unintended tampering due to an error in
   the Remote Peer.

7.4  Information Disclosure

   The main potential source for information disclosure is through a
   local buffer that has been enabled for remote access. If the buffer
   can be probed by a Remote Peer on another connection, then there is
   potential for information disclosure.

   Information disclosure attacks mainly apply to the Trust Models that
   include Untrusted Remote Peers (Trust Models NS-NT, S-NT, and S-LT
   as defined in Section 5). Trusted Remote Peers are assumed not to
   purposely attempt such attacks - any attempt is assumed to be due to
   an error or other unexpected failure in the Remote Peer.

   The potential attacks that could result in unintended information
   disclosure and countermeasures are as follows:

7.4.1  Probing memory outside of the buffer bounds

   This is essentially the same attack as described in Section 7.3.1,
   except an RDMA Read Request is used to mount the attack. The same
   countermeasure applies.

7.4.2  Using RDMA Read to Access Stale Data

   If a buffer is being used for a combination of reads and writes
   (either remote or local), and is exposed to the Remote Peer with at
   least remote read access rights, the Remote Peer may be able to
   examine the contents of the buffer before they are initialized with
   the correct data. In this situation, whatever contents were present
   in the buffer before the buffer is initialized can be viewed by the
   Remote Peer, if the Remote Peer performs an RDMA Read. This threat
   applies to Trust Models NS-NT, S-NT, and S-LT.

   Because of this, it is RECOMMENDED that the Local Peer ensure that
   no stale data is contained in the buffer when remote read access
   rights are initially granted (this can be done by zeroing the
   contents of the memory, for example).





J. Pinkerton, et al.   Expires - December 2003              [Page 19]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.4.3  Accessing a buffer after the transfer is over

   If the Remote Peer has remote read access to a buffer, and by some
   mechanism tells the Local Peer that the transfer has been completed,
   but the Local Peer does not disable remote access to the buffer
   before modifying the data, it is possible for the Remote Peer to
   retrieve the new data.

   This is similar to the attack defined in Section 7.3.2 Modifying a
   Buffer After Indicating the Contents Are Ready on page 18. The same
   countermeasures apply. In addition, it is RECOMMENDED that the Local
   Peer should grant remote read access rights only for the amount of
   time needed to retrieve the data.

7.4.4  Accessing data within a valid STag that was unintended

   <TBD: 7.4.4 and 7.4.5 are the same û group together>

   If the Local Peer enables remote access to a buffer using an STag
   that references the entire buffer, but intends only a portion of the
   buffer to be accessed, it is possible for the Remote Peer to access
   the other parts of the buffer anyway. This threat applies to Trust
   Models NS-NT, S-NT, and S-LT.

   To prevent this attack, it is RECOMMENDED that the Local Peer set
   the base and bounds of the buffer when the STag is initialized to
   expose only the data to be retrieved.

7.4.5  Using RDMA Read on a buffer meant only for RDMA Write

   One form of disclosure can occur if the access rights on the buffer
   were set for remote read, when only remote write access was
   intended. This attack applies primarily to Trust Models with
   Untrusted Remote Peers (NS-NT, S-NT and S-LT). If the buffer
   contained application data, or data from a transfer on an unrelated
   connection, the Remote Peer could retrieve the data through an RDMA
   Read operation.

   The most obvious countermeasure for this attack is to not grant
   remote read access if the buffer is intended to be write-only. The
   Remote Peer would not be able to retrieve data associated with the
   buffer. An attempt to do so would result in an error and the RDMAP
   Stream associated with the connection would be terminated.

   Thus, it is RECOMMENDED that if an application only intends a buffer
   to be exposed for remote write access, it set the access rights to
   the buffer to only enable remote write access.

J. Pinkerton, et al.   Expires - December 2003              [Page 20]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.4.6  Using Multiple Stags to access the same buffer

   Multiple STags accessing the same buffer at the same time can result
   in unintentional information disclosure. When one STag has remote
   read access enabled and a different STag has remote write access
   enabled to the same buffer, it is possible for one connection to
   view the contents that have been written by another Remote Peer.
   This is not a problem when all of the STags accessing the buffer
   have only remote read enabled. For Trust Models NS-NT, S-NT, S-LT it
   is RECOMMENDED that multiple Remote Peers not be granted access to
   the same buffer through different STags at the same time. A buffer
   should be exposed to only one Untrusted Remote Peer at a time to
   ensure that no information disclosure occurs between peers.

7.4.7  Remote node loading firmware onto the RNIC

   If the Remote Peer can cause firmware to be loaded onto the RNIC,
   there is an opportunity for information disclosure. See Elevation of
   Privilege in Section 7.6 for this analysis.

7.5  Denial of Service (DOS)

   A DOS attack is one of the primary security risks of RDMAP. This is
   because RNIC resources are valuable and scarce, and many application
   environments require communication with Untrusted Remote Peers. If
   the remote application can be authenticated or encrypted, clearly,
   the DOS profile can be reduced. For the purposes of this analysis,
   it is assumed that the RNIC must be able to operate in Untrusted
   environments, which are open to DOS style attacks.

   Denial of service attacks against RI resources are not the typical
   unknown party spraying packets at a random host (such as a TCP SYN
   attack). Because the connection must be fully established, the
   attacker must be able to both send and receive messages over that
   connection, or be able to guess a valid packet on an existing RDMAP
   Stream.

   This section outlines the potential attacks and the countermeasures
   available for dealing with each attack. For each attack, the Trust
   Model that it applies to is described.

7.5.1  RNIC Resource Consumption

   This section covers attacks that fall into the general category of a
   Local Peer attempting to unfairly allocate scarce RNIC resources.
   The Local Peer may be attempting to allocate resources on its own
   behalf, or on behalf of a Remote Peer. Resources that fall into this

J. Pinkerton, et al.   Expires - December 2003              [Page 21]

Internet-Draft           RDDP/RDMAP Security              June 2003

   category include: Protection Domains, Connection Context Memory,
   Translation and Protection Tables, and STag namespace. These can be
   attacks by currently active Local Peers or ones that allocated
   resources earlier, but are now idle.

   These attacks generally apply to any Trust Model that includes
   Untrusted Local Peers (Trust Models NS-NT, NS-RT and S-NT). This
   type of attack can occur even when resources are not shared across
   connections.

   It is RECOMMENDED that the allocation of all scarce resources be
   placed under the control of a Resource Manager. This allows the
   Resource Manager to:

       *   prevent a Local Peer from allocating more than its fair
           share of resources, and

       *   detect if a Remote Peer is attempting to launch a DOS attack
           by attempting to create an excessive number of connections
           and take corrective action (such as refusing the request or
           applying network layer filters against the Remote Peer).

   Note that, placing scarce resource management under the control of a
   Resource Manager also prevents other Trusted Local Peers from
   attempting to allocate more than their fair share of resources.

   This analysis assumes that the Resource Manager is responsible for
   handing out Protection Domains, and RNIC implementations will
   provide enough Protection Domains to allow the Resource Manager to
   be able to assign a unique Protection Domain for each unrelated,
   Untrusted Local Peer (for a bounded, reasonable number of Local
   Peers). This analysis further assumes that the Resource Manager
   implements policies to ensure that Untrusted Local Peers are not
   able to consume all of the Protection Domains through a DOS attack.
   Note that Protection Domain consumption cannot result from a DOS
   attack launched by a Remote Peer, unless a Local Peer is acting on
   the Remote PeerÆs behalf.

7.5.2  Resource Consumption By Active Applications

   This section describes DOS attacks from Local and Remote Peers that
   are actively exchanging messages. Attacks on each RDMA NIC resource
   are examined, including the Trust Models that apply, and the
   specific countermeasures. Note that, attacks on Connection Context
   Memory, Page Translation Tables, and STag namespace are covered in
   Section 7.5.1 RNIC Resource Consumption, so are not included here.


J. Pinkerton, et al.   Expires - December 2003              [Page 22]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.5.2.1  Receive Data Buffers

   The Remote Peer can attempt to consume more than its fair share of
   receive data buffers (Untagged DDP buffers or for RDMAP buffers
   consumed with Send Type Messages). If resources are not shared
   across multiple connections (Trust Models NS-NT, NS-RT), then this
   attack is not possible because the Remote Peer will not be able to
   consume more buffers than were allocated to the Stream. The worst
   case scenario is that the Remote Peer can consume more receive
   buffers than the Local Peer allowed, resulting in no buffers to be
   available, which would cause the Remote PeerÆs connection to the
   Local Peer to be torn down.

   If local receive data buffers are shared among multiple Streams and
   the Remote Peer is not Trusted (Trust Models S-NT, S-LT), then the
   Remote Peer can attempt to consume more than its fair share of the
   receive buffers, causing a different Stream to be short of receive
   buffers, thus possibly causing the other Stream to be torn down.

   One method the Local Peer could use is to recognize that a Remote
   Peer is attempting to use more than its fair share of resources and
   terminate the Stream. However, if the Local Peer is sufficiently
   slow, it may be possible for the Remote Peer to still mount a denial
   of service attack. An RNIC Engine implementation that enables a more
   robust countermeasure is one that provides high and low-water
   notifications to enable the Local Peer to detect and prevent DOS
   attacks against shared data buffers. If a low-water notification is
   enabled, and the Local Peer is able to bound the amount of time that
   it takes to replenish receive buffers, and the Local Peer maintains
   statistics to determine which Remote Peer is consuming buffers, then
   the Local Peer can size the amount of local receive buffers posted
   on the receive queue such that the low-water notification can arrive
   before resources are depleted and corrective action can be taken
   (e.g., terminate the Stream of the attacking Remote Peer). Enabling
   the high-water notification can help the Local Peer detect a Remote
   Peer that is launching an attack by sending a large number of out-
   of-order packets. The notification is generated when more than the
   specified number of buffers are in process simultaneously on a
   Stream (i.e., packets have started to arrive for the buffer, but
   have not yet been delivered to the ULP).

   A different countermeasure is for the RNIC Engine to provide the
   capability to limit the Remote PeerÆs ability to consume receive
   buffers on a per Stream basis. Unfortunately this requires a large
   amount of state to be tracked on a per RNIC basis.



J. Pinkerton, et al.   Expires - December 2003              [Page 23]

Internet-Draft           RDDP/RDMAP Security              June 2003

   Thus, if an RNIC Engine provides the ability to share receive
   buffers across multiple Streams, it is RECOMMENDED that it enable
   the Local Peer to detect if the Remote Peer is attempting to consume
   more than its fair share of resources so that the application can
   apply countermeasures to detect and prevent the attack.

7.5.2.2  Completion Queue (CQ) Resource Consumption

   DOS attacks against the Completion Queue can be caused by either the
   Local Peer or the Remote Peer if either attempts to cause more
   completions than its fair share, thus potentially starving another
   unrelated Stream such that no Completion Queue entries are
   available.

   A Completion Queue entry can potentially be consumed by a completion
   from the send queue or a receive completion. In the former, the
   attacker is the Local Peer (Trust Models S-NT). In the later, the
   attacker is the Remote Peer (S-NT, S-LT).

   The potential attacks and the countermeasures for each are described
   in the subsections that follow.

7.5.2.2.1   Local Peer Attacking a Shared CQ

   A form of attack can occur for Trust Models NS-NT, NS-RT, and S-NT,
   where the Local Peers are Untrusted, and Local Peers can consume
   resources on the CQ. Sharing a CQ across connections that belong to
   different Protection Domains is NOT RECOMMENDED in cases where any
   of the Local Peers are Untrusted. A Local Peer that is slow to free
   resources on the CQ by not reaping the completion status quick
   enough could stall all other Local Peers attempting to use that CQ.

   One of two countermeasures can be used to avoid this kind of attack.
   The first is to use a different CQ per Untrusted Local Peer. The
   other is to use a Trusted Local Peer to act as a third party to free
   resources on the CQ and place the status in intermediate storage
   until the Untrusted Local Peer reaps the status information.

7.5.2.2.2   Remote Peer Attacking a Shared CQ

   The Remote Peer can attack a CQ by consuming more than its fair
   share of CQ entries by using one of two methods. The first method
   can only be used if the ULP protocol allows the Remote Peer to
   reserve a specified number of CQ entries, possibly leaving
   insufficient entries for other connections that are sharing the CQ.
   The other method is if the Remote Peer can attack the CQ by


J. Pinkerton, et al.   Expires - December 2003              [Page 24]

Internet-Draft           RDDP/RDMAP Security              June 2003

   overwhelming the CQ with completions, which can affect completion
   processing on other Streams sharing that connection.

   The first method of attack can be avoided if the ULP does not allow
   a Remote Peer to reserve CQ entries. This is RECOMMENDED
   particularly for Trust Models S-NT and S-LT, with shared resources
   and Untrusted Remote Peers. If a Local Peer allows this type of
   resource allocation, and it has any Untrusted Remote Peers, then the
   Local Peer it is RECOMMENDED that the CQ be isolated to connections
   within a single Protection Domain.

   One way that a Remote Peer can attempt to overwhelm its CQ with
   completions is by sending minimum length RDMAP/DDP Messages to cause
   as many completions per second as possible. Assuming that the Local
   Peer does not run out of receive buffers (if they do, then this is a
   different attack, documented in Section 7.5.2.1 Receive Data Buffers
   on page 23), then it might be possible for the Remote Peer to
   consume more than its fair share of Completion Queue entries.
   Depending upon the CQ implementation, this could either cause the CQ
   to overflow (if it is not large enough to handle all of the
   completions generated) or for another Stream to not be able to
   generate CQ entries (if the RNIC had flow control on generation of
   CQ entries into the CQ). In either case, the CQ will stop
   functioning correctly and any connections expecting completions on
   the CQ will stop functioning.

   This attack can occur regardless of whether all of the connections
   associated with the CQ are in the same Protection Domain or are in
   different Protection Domains. Because this attack assumes a shared
   local resource and an Untrusted Remote Peer, Trust Models S-NT, S-LT
   apply.

   The Local Peer can protect itself from this type of attack using
   either of the following methods:

       *   Resize the CQ to the appropriate level(note that resizing
           the CQ can fail, so the CQ resize should be done before
           sizing the buffers on the connection), OR

       *   Grant fewer resources than the Remote Peer requested (not
           supplying the number of Receive Data Buffers requested).

   The proper sizing of the CQ is dependent on the Trust Model. For the
   Trust Model described in Section 5, with Trusted Local Peers and
   Untrusted Remote Peers (Trust Model S-LT), a correctly sized CQ
   means that the CQ is large enough to hold completion status for all
   of the outstanding Receive Data Buffers, or:

J. Pinkerton, et al.   Expires - December 2003              [Page 25]

Internet-Draft           RDDP/RDMAP Security              June 2003

   CQ_MIN_SIZE = SUM(MaxPostedOnEachRQ)
                + SUM(MaxPostedOnEachS-RQ)
                + SUM(MaxPostedOnEachSQ)

   If the Trust Model assumes neither the Local Peer nor the Remote
   Peer is trusted (Trust Model S-NT or S-LT), then the CQ must be
   sized to accommodate the maximum number of operations or Receive
   Data Buffers that it is possible to post at any one time, thus the
   equation becomes:

            CQ_MIN_SIZE = SUM(SizeOfEachRQ)
                          + SUM(SizeOfEachS-RQ)
                          + SUM(SizeOfEachSQ)

   Where MaxPosted*OnEach*Q and SizeOfEach*Q varies on a per connection
   or per Shared Receive Queue basis.

7.5.2.3  RDMA Read Request Queue

   Two types of attacks are possible against resources associated with
   RDMA Read Request Queues. One style of attack can only occur when
   the RDMA Read Request Queue resources are pooled across multiple
   connections. This attack occurs when an Untrusted Local Peer
   attempts to unfairly allocate RDMA Read Request Queue resources for
   its connections.

   It is RECOMMENDED that access to interfaces that allocate RDMA Read
   Request Queue entries be restricted to a Trusted Local Peer, such as
   a Resource Manager. The Resource Manager should prevent a Local Peer
   from allocating more than its fair share of resources.

   Another form of attack is the Remote Peer sending more RDMA Read
   Requests than the depth of the RDMA Read Request Queue at the Local
   Peer.

   This attack can be prevented by properly configuring the connection
   when the connection is established. The Remote PeerÆs end of the
   connection should be configured by a trusted agent such that the
   RNIC will not transmit RDMA Read Requests that exceed the depth of
   the RDMA Read Request Queue at the Local Peer. If the connection is
   correctly configured, and if the Remote Peer submits more requests
   than the Local PeerÆs RDMA Read Request Queue can handle, the
   requests will be queued at the Remote PeerÆs connection until
   previous requests complete. If the Remote PeerÆs connection is not
   configured correctly, the RDMAP Stream for that connection is
   terminated when more RDMA Read Requests arrive at the Local Peer


J. Pinkerton, et al.   Expires - December 2003              [Page 26]

Internet-Draft           RDDP/RDMAP Security              June 2003

   than the Local Peer can handle. Thus, the Remote Peer is able to
   only affect its own connection.

7.5.3  Resource Consumption by Idle Applications

   The simplest form of a DOS attack given a fixed amount of resources
   is for the Remote Peer to create a RDMAP Stream to a Local Peer,
   request dedicated resources then do no actual work. This allows the
   Remote Peer to be very light weight (i.e. only negotiate resources,
   but do no data transfer) and consumes a disproportionate amount of
   resources in the server.

   A general countermeasure for this style of attack is to monitor
   active RDMAP Streams and if resources are getting low, reap the
   resources from RDMAP Streams that are not transferring data and
   possibly terminate the connection. This needs to be under
   administrative control, and demonstrates the need for a MIB for
   RDMAP so this condition can be detected and acted upon.

   Refer to Section 7.5.1 for the analysis and countermeasures for this
   style of attack on the following RNIC resources: Connection Context
   Memory, Page Translation Tables and STag namespace.

   Note that some RNIC resources are not at risk of this type of attack
   from a Remote Peer because an attack requires the Remote Peer to
   send messages in order to consume the resource. Receive Data
   Buffers, Completion Queue, and RDMA Read Request Queue resources are
   examples. These resources are, however, at risk form a Local Peer
   that attempts to allocate resources, then goes idle. The general
   countermeasure described in this section can be used to free
   resources allocated by an idle Local Peer.

7.5.4  Exercise of non-optimal code paths

   Another form of DOS attack is to attempt to exercise data paths that
   can consume a disproportionate amount of resources. An example might
   be if error cases are handled on a ôslow pathö (consuming either
   host or RNIC computational resources), and an attacker generates
   excessive numbers of errors in an attempt to consume these
   resources.

   It is RECOMMENDED that an implementation provide the ability to
   detect the above condition and allow an administrator to act,
   including potentially administratively tearing down the RDMAP Stream
   associated with the connection exercising data paths consuming a
   disproportionate amount of resources.


J. Pinkerton, et al.   Expires - December 2003              [Page 27]

Internet-Draft           RDDP/RDMAP Security              June 2003

7.6  Elevation of Privilege

   The RDMAP/DDP Security Architecture explicitly differentiates
   between three levels of privilege û Non-Privileged, Privileged, and
   the Privileged Resource Manager. If a Non-Privileged Application is
   able to elevate its privilege level to a Privileged Application,
   then mapping a physical address list to an STag can provide local
   and remote access to any physical address location on the node. If a
   Privileged Mode Application is able to promote itself to be a
   Resource Manager, then it is possible for it to perform denial of
   service type attacks where substantial amounts of local resources
   could be consumed.

   There is only one mechanism discovered to date, other than
   implementation defects, which would potentially allow an elevation
   of privilege.

7.6.1  Loading Firmware into the RNIC

   If the RI implementation, by some insecure mechanism (or
   implementation defect), can enable a Remote Peer or un-trusted Local
   Peer to load firmware into the RNIC Engine, it is possible to use
   the RNIC to attack the host. Thus, it is RECOMMENDED that an
   implementation not enable firmware to be loaded on the RNIC Engine
   directly from a Remote Peer, unless the update is done via a secure
   protocol, such as IPsec (See Section 8 IPsec and RDDP on page 29).
   It is RECOMMENDED that an implementation not allow a Non-Privileged
   Local Peer to update firmware in the RNIC Engine.




















J. Pinkerton, et al.   Expires - December 2003              [Page 28]

Internet-Draft           RDDP/RDMAP Security              June 2003

8  IPsec and RDDP

8.1  Introduction to IPsec

   IPsec is a protocol suite which is used to secure communication at
   the network layer between two peers.  The IPsec protocol suite is
   specified within the IP Security Architecture [RFC2401], IKE
   [RFC2409], IPsec Authentication Header (AH) [RFC2402] and IPsec
   Encapsulating Security Payload (ESP) [RFC2406] documents.  IKE is
   the key management protocol while AH and ESP are used to protect IP
   traffic.

   An IPsec SA is a one-way security association, uniquely identified
   by the 3-tuple: Security Parameter Index (SPI), protocol (ESP) and
   destination IP.  The parameters for an IPsec security association
   are typically established by a key management protocol. These
   include the encapsulation mode, encapsulation type, session keys and
   SPI values.

   IKE is a two phase negotiation protocol based on the modular
   exchange of messages defined by ISAKMP [RFC2408],and the IP Security
   Domain of Interpretation (DOI) [RFC2407]. IKE has two phases, and
   accomplishes the following functions:



   1.  Protected cipher suite and options negotiation - using keyed
       MACs and encryption and anti-replay mechanisms

   2.  Master key generation - such as via MODP Diffie-Hellman
       calculations

   3.  Authentication of end-points

   4.  IPsec SA management (selector negotiation, options negotiation,
       create, delete, and rekeying)

   Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is
   handled in IKE Phase 2.

   An IKE Phase 2 negotiation is performed to establish both an inbound
   and an outbound IPsec SA.  The traffic to be protected by an IPsec
   SA is determined by a selector which has been proposed by the IKE
   initiator and accepted by the IKE Responder.  In IPsec transport
   mode, the IPsec SA selector can be a "filter" or traffic classifier,
   defined as the 5-tuple: <Source IP address, Destination IP address,
   transport protocol (UDP/SCTP/TCP), Source port, Destination port>.

J. Pinkerton, et al.   Expires - December 2003              [Page 29]

Internet-Draft           RDDP/RDMAP Security              June 2003

   The successful establishment of a IKE Phase-2 SA results in the
   creation of two uni-directional IPsec SAs fully qualified by the
   tuple <Protocol (ESP/AH), destination address, SPI>.

   The session keys for each IPsec SA are derived from a master key,
   typically via a MODP Diffie-Hellman computation.  Rekeying of an
   existing IPsec SA pair is accomplished by creating two new IPsec
   SAs, making them active, and then optionally deleting the older
   IPsec SA pair.  Typically the new outbound SA is used immediately,
   and the old inbound SA is left active to receive packets for some
   locally defined time, perhaps 30 seconds or 1 minute.

8.2  Recommendations for IPsec Encapsulation of RDDP

   Issue: IPsec recommendations for RDMAP/DDP


   This is work that is still to be done.






























J. Pinkerton, et al.   Expires - December 2003              [Page 30]

Internet-Draft           RDDP/RDMAP Security              June 2003

9  Summary Table of Attacks and Trust Models

   <editor: This section is under construction, and will be completed
   in a future version of this document>

   Rows are the attack (grouped into categories)

   Columns are the:

       *   Sec û Section the attack is discussed

       *   Attack Name û short name for the attack

       *   Threat - threat type (DOS, etc)

       *   Columns labeled 1-5 are the Trust Model number (see section
           5 Trust Models on page 11). Each entry has a value of +, -,
           and R (research).






























J. Pinkerton, et al.   Expires - December 2003              [Page 31]

Internet-Draft           RDDP/RDMAP Security              June 2003

+-------+--------------------------+-------+---+---+---+---+---+
|  Sec  | Attack Name              |Threat | 1 | 2 | 3 | 4 | 5 |
+-------+--------------------------+-------+---+---+---+---+---+
| 7.2.1 | STag use on different    | Spoof |   |   |   |   |   |
|       |   connection in same PD  |       |   |   |   |   |   |
+-------+--------------------------+-------+---+---+---+---+---+
| 7.3.1 | Memory write outside of  | Tamper|   |   |   |   |   |
|       |   buffer range           |       |   |   |   |   |   |
| 7.3.2 | Modify Buffer after      | Tamper|   |   |   |   |   |
|       |   contents ready         |       |   |   |   |   |   |
+-------+--------------------------+-------+---+---+---+---+---+
| 7.4.1 | Probe memory outside of  | ID    |   |   |   |   |   |
|       |   buffer bounds          |       |   |   |   |   |   |
| 7.4.2 | Access stale data        | ID    |   |   |   |   |   |
| 7.4.3 | Access buffer after      | ID    |   |   |   |   |   |
|       |   transfer over          |       |   |   |   |   |   |
| 7.4.4 | Unintended data access   | ID    |   |   |   |   |   |
|       |   using valid STag       |       |   |   |   |   |   |
| 7.4.5 | Using RDMA Read on a     | ID    |   |   |   |   |   |
|       |   buffer meant only for  |       |   |   |   |   |   |
|       |   RDMA Write             |       |   |   |   |   |   |
| 7.4.6 | Using multiple STags to  | ID    |   |   |   |   |   |
|       |   access the same buffer |       |   |   |   |   |   |
| 7.4.7 | Remote node loading      | ID    |   |   |   |   |   |
|       |   firmware onto RNIC     |       |   |   |   |   |   |
+-------+--------------------------+-------+---+---+---+---+---+
| 7.5.1 | RNIC resource consumption| DOS   |   |   |   |   |   |
| 7.5.2 | Resource consumption by  | DOS   |   |   |   |   |   |
|       |   active processes       |       |   |   |   |   |   |
| 7.5.3 | Resource consumption by  | DOS   |   |   |   |   |   |
|       |   idle processes         |       |   |   |   |   |   |
| 7.5.4 | Non-optimal code paths   | DOS   |   |   |   |   |   |
+-------+--------------------------+-------+---+---+---+---+---+
| 7.6.1 | Loading firmware onto    | Elev  |   |   |   |   |   |
|       |   RNIC                   |       |   |   |   |   |   |
+-------+--------------------------+-------+---+---+---+---+---+

                  Figure 2 û Summary Attacks and Trust Model Table










J. Pinkerton, et al.   Expires - December 2003              [Page 32]

Internet-Draft           RDDP/RDMAP Security              June 2003

10 References

10.1 Normative References

   [RFC2828] Shirley, R., "Internet Security Glossary", FYI 36, RFC
       2828, May 2000.

   [DDP] Shah, H., J. Pinkerton, R.Recio, and P. Culley, "Direct Data
       Placement over Reliable Transports", Internet-Draft draft-ietf-
       rddp-ddp-01.txt, February 2003.

   [RDMAP] Recio, R., P. Culley, D. Garcia, J. Hilland, "An RDMA
       Protocol Specification", Internet-Draft draft-ietf-rddp-rdmap-
       01.txt, February 2003.

    [SEC-CONS] Rescorla, E., B. Korver, IAB, "Guidelines for Writing
       RFC Text on Security Considerations", Internet-Draft draft-ab-
       sec-cons-03.txt, January 2003.

    [RFC2401] Atkinson, R. and Kent, S., "Security Architecture for the
       Internet Protocol", RFC 2401, November 1998

    [RFC2402] Kent, S., Atkinson, R., "IP Authentication Header", RFC
       2402, November 1998

    [RFC2404] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within
       ESP and AH", RFC 2404, November 1998

    [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security
       Payload (ESP)", RFC 2406, November 1998

    [RFC2407] Piper, D., "The Internet IP Security Domain of
       Interpretation of ISAKMP", RFC 2407, November 1998

    [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J.,
       "Internet Security Association and Key Management Protocol
       (ISAKMP), RFC 2408, November 1998

    [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange
       (IKE)", RFC 2409, November 1998








J. Pinkerton, et al.   Expires - December 2003              [Page 33]

Internet-Draft           RDDP/RDMAP Security              June 2003

10.2 Informative References

    [IPv6-Trust] Nikander, P., J.Kempf, E. Nordmark, "IPv6 Neighbor
       Discovery trust modelsTrust Models and threats", Internet-Draft
       draft-ietf-send-psreq-01.txt, January 2003.











































J. Pinkerton, et al.   Expires - December 2003              [Page 34]

Internet-Draft           RDDP/RDMAP Security              June 2003

11 AuthorÆs Addresses

   James Pinkerton
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA. 98052 USA
   Phone: +1 (425) 705-5442
   Email: jpink@windows.microsoft.com

   Ellen Deleganes
   Intel Corporation
   MS JF5-355
   2111 NE 25th Ave.
   Hillsboro, OR 97124 USA
   Phone: +1 (503) 712-4173
   Email: ellen.m.deleganes@intel.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA. 98052 USA
   Phone: +1
   Email:

























J. Pinkerton, et al.   Expires - December 2003              [Page 35]

Internet-Draft           RDDP/RDMAP Security              June 2003

12 Acknowledgments

   Allyn Romanow

   Catherine Meadows

   Pat Thaler

   James Livingston

   John Carrier





































J. Pinkerton, et al.   Expires - December 2003              [Page 36]

Internet-Draft           RDDP/RDMAP Security              June 2003

13 Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


















J. Pinkerton, et al.   Expires - December 2003              [Page 37]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/