Subject: [rddp] RE: Security Draft - Definition of Trust / relevance

From: Caitlin Bestler <[email-masked]>
Date: Tue, 24 Jun 2003 16:11:02 -0500

Section 3 has the following definition:

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

I don't find that definition to be that useful. Of all the things
that can go wrong, the *intent* of the peer is only relevant when
dealing with inadvertently authorized RDMA Reads.

The key security issue with RDMA is ensuring that the ULP understands
that *it* controls what access it gives the RNIC and its peers. There
are various strategies for doing so, ranging from very cautious to
very trusting.

Remote access to memory is *only* authorized by posting a read or
by enabling an STag for a Protection Domain.

Security issues may arise when that exposure is wider than the
ULP understands. This may because the ULP is being cavalier, or
that the local interface does not offer adequate controls. For
example the upper-layer-protocol may define a very clear 
procedure for use of a circular buffer, but it is unlikely that
the local interface will offer any direct support for dynamically
adjusting the exposed portion of the STag to match the protocol
specification. In particular, I doubt anyone will ever build
an RNIC that offers anything more than enabling an STag for
a single range of bytes. But there is nothing in the wire
protocol that requires the set of valid addresses for an STag
to be a single contiguous range of bytes.

Anyway, the point is that for a variety of reasons, more bytes
may be exposed for read and/or write than would be the absolute
minimum required to support the ULP.

When this is write access, the data sink has a choice to trust
to rely on its peer fully conforming to the upper layer protocol
as specified, or it may assume that *all* bytes exposed for
write are volatile and undefined.

For writes, the *intent* of the peer is not the critical factor. Indeed
I would argue given that the peer has an already established and
potentially authenticated LLP stream that a far more serious concern is
*accidental* targeting of exposed memory.

After all, software engineers capable of making a mistake are far more
common than those that would deliberately attack you.

Intent is a relevant issue when dealing with inadvertently exposed
read access.

I would characterize the over-exposure issue as follows:

-- The application MUST be able to expose buffers to read/write as
   required by the upper-layer-protocol.
-- The application SHOULD be able to use the local interface to provide
   only the required access. However the application MAY enable more
   access to simplify its own logic.
-- The application MAY assume that its peer will be in full compliance
   with the upper layer protocol. However it SHOULD NOT do so if failure
   to comply places the work or information about any other session at
   risk. (In other words, it is perfectly OK to take a "you break the
   rules, you mess yourself up" attitude. But you should not allow
   peer X breaking the rules to have any adverse affect on peer Y).

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