RDDP Security - misc comments, 1-16

Mike Krause has done a great job reviewing the doc and coming up with
questions. Because there are quite a few questions/issues raised, I'm
dividing them into multiple emails to help focus the discussion. This
email handles questions which don't bring up organizational issues,
through question 16. Organizational issues will be in a separate email.

 

> (3) Figure 1.  One might consider having a line between the admin and
the

> privileged application given the resource manager is not required but
its

> essence may be integrated into the privileged application.  For
example, a

> storage subsystem may already have defined interfaces to
administration

> services and if it has exclusive control of the RNIC would not require
a

> separate resource manager.

> 

 

Will do.

 

> (6) Request proxy interface definition in 4.1 really does not provide
much

> information.  It provides a high-level statement on counter measures
but

> due to organization, such a statement does not have much in terms of

> value.

> 

 

On re-reading this, I agree that there are unresolved issues.
Specifically "Application Control Interface" is not defined. My original
intent here was to differentiate between requests for resources, which
need to go through the Privileged Resource Manager for the reasons
stated, and an interface for the non-privileged application for it to
register buffers with the RNIC. After trying to fix this, I think this
is overly complex. I'd like to collapse the "Application Control
Interface" and the "Request Proxy Interface" into a single "Application
Control Interface", where the definition states that for non-privileged
application usage the Privileged Resource Manager will verify the
request and implement countermeasures. Something like:

 

*               Application Control Interface - An application uses this
interface to the Privileged Resource Manager to allocate RNIC Engine
resources. 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.

 

 

> (7) 4.2.4 Is there any need to discuss the 8-bit key portion of the
STag

> and how an application / ULP can help control the wire-view of the
STag?

> 

 

The 8 bit key is specific to a verbs implementation, not the wire
protocols. I personally don't see how this aids security in any way -
it's trivial to hack. To me the primary justification for including it
was to allow fast lookups and some help in debug (by mixing up the key
values a little). Since calling this "security" to me would be highly
controversial, I'd prefer to leave it out.

 

> (8) 4.28 There is "Event Queue" and one other line but not really
anything

> else stated here.  This seems almost like a fragment or a TBD area.

> 

 

Yep - this is a fragment. I'll complete the thought in the next draft.
As you're aware, this is non-trivial to finish.

 

> (9) 4.3 Is 4.3 just a place holder?  Not clear its relevance to the
draft

> as many system properties can be attacked but these are outside the
scope

> of RDMA itself.

 

This was included at the direction of security folks - in general, all
of the attacks described in the document fall into the category of
system integrity.  One thing that is not done in the document  is to
directly reference which categories the attacks fall into (integrity,
stability, confidentiality). Alternatively, if folks don't see a lot of
value in this section (i.e. what is being attacked is obvious), I could
just delete the section.

 

> (12) Page 15 under NS-RT. There is a note attached but not really

> sufficient information provided w.r.t. the key-based authentication
per

> packet sentence.  Either provide more information here or add a
pointer to

> the appropriate specification or subsequent section where this is

> described

> further.

> 

 

I'll add a cross-ref to chapter 8.

 

> (13) 7.1.1.   Add "each" to , it is recommend that Protection Domain
be

> limited to the number....

> 

Will do. Sentence now reads "it is recommended that Protection Domain be
limited to the number of Streams that each share the same Trust Model."

 

> (14) 7.1.2 Second bullet should use the term window or cross reference
to

> the appropriate specification so that the reader can understand how
this

> is

> somewhat a local issue and that there are tools defined to help
provide

> this service.

> 

 

I've intentionally tried to stay away from Verbs-isms in this document.
Also, I can't reference the verbs spec if it does not have a path to RFC
status (as informational, experimental, standards, whatever).  Thus I've
tried in general to describe issues in the abstract, without talking
about a specific implementation. Or if talking about specific
implementations, try to provide a variety of choices, without mandating
a choice. I agree that the document could be more detailed in
implementation, but I think that also means that we then have to decide
as a group on standardizing a host to RNIC interface. Personally, I'd
rather not gate RDMAP/DDP/etc on this issue. Clearly they are gated on
the security draft.

 

> (15) 7.1.2 fourth bullet,  STag needs to be properly capitalized.  It

> would

> also be good to cross reference back to the error description (per

> previous

> comment) the effects of a STag violation.

> 

 

I've fixed STag and also done a global replace to fix the other 9 times.
Thanks. I've also added text referencing RDMAP and DDP on what happens
when an invalid STag is received. (RDMAP requires a teardown, DDP is
required to signal the error to the ULP, and commonly this will cause a
teardown).

 

> (16) 7.1.5 Need to emphasize that this is an application problem not a

> RDMA

> or DDP problem.

> 

 

I don't agree. For example, if an error on a specific stream causes the
RNIC to hang, all applications using the adapter are effected,
regardless of what the application does. I'll add an example to make
this clearer. Something like:

 

For example, an error on a specific RDMAP stream should not cause the
RNIC to stop processing incoming packets, or corrupt a receive queue for
an unrelated stream.