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

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

page 6:

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

I believe the correct specification is that all interactions
*that require verification* must be passed through a Trusted
intermediary. As emphasized later in the document, there can be
"safe" interactions, which are interpreted in the context
of earlier validated commands (especially work requests).

The general principle is that the RNIC Engine MUST NOT perform
any access to memory that it was not authorized to access, and
that said authorization must come from an entity that had the
right to grant that permission.

Different execution environments may have more than two classes
of privilege. Whatever privileges a given software component has,
it ought to be allowed to give to the RNIC Engine. (I avoid saying
"should" because I recognize the value to RNIC developers to
standardize their interface with the host system. However,
as valuable as that may be, I believe it is out of scope
for this document).

Missing section - Definitions

Especially "connection".

Which can be an LLP communication link with a rmeote host which must
be estabished, maintained, have acks, congestion windows, etc. Such
as a TCP connection or an SCTP association.

Or it could be the LLP Stream over which two RDMAP/DDP endpoints
communicate DDP Segments. Such as a TCP connection or a pair of
SCTP streams.

If you review the group charter you'll realize that assumptions that
the LLP is TCP are to be avoided.

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

STags must be translated from the STag-specific address space
to an address space that is RNIC Engine accessible.

It would be valid for a system to have a feature whereby memory
maps could be defined for use by IO cards. An STag could simply
be a valid window of such an IO Card accessible memory map.

In most cases the translation will be to physical addresses,
but that is merely a highly prevelant design choice. It has
nothing to do with the protocol.

There is an important aspect of Page Translation Tables that
should be mentioned here -- namely that multiple STags SHOULD
be able to share a single memory map. In IB terms, you have
to be able to create a Memory Region and use it with multiple
Memory Windows.

It is important that the ULP actually be able to precisely tailor
its memory exposure to match its actual requirements. The goal
expressed in the DAT Collaborative's DAPL specifications is that
window binding has to be sufficiently lightweight that it is
reasonable to perform on a per-data-transfer basis. That all
but requires a distinction between the mapping resource and
the range-checking STag.

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