Subject: [rddp] Re: security-draft : more scattered points

From: Caitlin Bestler <[email-masked]>
Date: Tue, 24 Jun 2003 18:18:46 -0500

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

The DDP specification carefully avoids specifying the scope
of the 32-bit namespace. It is *likely* to match the scope of
the RNIC, but could be system-wide, per IP address or even
per Protection Domain.

The above paragraph may give a reader the incorrect impression
that the scope is system wide.

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

It needs to be clarified that there is only a signal completion
for a *set* of tagged and untagged messages. This makes it clear
that sizing of the completion queue is a solvable problem. The
maximum number of completions is easily derived from the number
of receives enabled and the number of work requests sent (plus
an allowance for other errors).

While the consolidation of ULP notifications is major benefit
of RDMAP/DDP, it is a security concern. An application that
over-exposes its buffers will not have an "audit trail" to
examine to see what its peer actually sent.

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

It should be observed that a server application may choose to go
even *more* paranoid, and simply not advertise any of its own
buffers.
The benefits of RDMA can be achieved by requiring the client to
expose its buffers. The DAFS protocol is the obvious example of
this.

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

Could you give an example?

I hope you are not implying that the ULP should be solving
problems that are the responsiblity of the LLP, such as
multistreaming and multi-homing.

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

I don't see the connection between Protection Domain scope
and the Trust Models. My advice would simply be that a Protection
Domain should be no wider than the ULP requires. Use of a common
Protection Domain for multiple DDP Streams should only be done
to meet an application requirement. It should not be done because
the RNIC is being stingy and offering fewer PD resources than
the number of DDP Streams it can support.

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

My reading of the DDP spec is that setting the Protection Domain
is *the* way to control the scope of an STag. Specifically, each
endpoint has an assigned Protection Domain. The validity of an
STag is checked against that PD, or within the scope of it. That
the only two checks that I am aware of that are consistent with
the DDP specs are:

    packet.stag.pd == endpoint.pd
    isValid(endpoint.pd+packet.stag)

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