Comments on draft-ietf-rddp-security-01

I have reviewed the recent RDDP Security draft
(http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-01.txt)
and have some comments in advance of tomorrow's
working group meeting.

I'd like to open by complimenting the authors on an excellent
second revision. This is a difficult document, but an important
one.

I don't have many high-level comments. The draft seems
well put-together.

One style thing to mention though - there are many, many
references to "later" or other sections, especially in the earlier
ones. I suggest direct section references.

Apostophes and em-dashes seem to have a different ascii
encoding, which appear strangely with certain text tools.
Suggest conventional ascii.

How specifically do we define "Partial Mutual Trust", which
appears relatively early? One way the reader may take it,
is as an authentication guarantee, for both the local application
and remote peer. But who decides "partial", for instance? Is
the motivation primarily to clarify the use of shared resources,
such as the SRQ?

In the introduction, it seems critical to describe the scope of
possible damage if the trust is violated. I believe it is very
different depending on the resource which is the subject of
the trust. System-level damage should be described differently
from damage which merely :-) damages the application. This is
not a very specific recommendation, I know.

I think there are differences between the trust model as described
here, and a privileged/nonprivileged application (at the end of
the Introduction). It might be worthwhile to bring these out.
For example, the trust model seems primarily oriented at wire-based
attacks, while the privileged/nonprivileged application is a local
matter? What interaction do these have?

Sect 4 pargraph 1 last sentence - "should be preserved when
under attack", just delete "when under attack" and say "should
be preserved". Maybe even "must".

4.2.1 refers to a FIFO list of buffers - maybe not FIFO in the
case of SRQs. Perhaps just "list of buffers" here - but also see
comment on 4.2.10.

4.2.2 buffer exposed to "the Internet"? This is vague.

4.2.2 a general comment - this refers to the RI, while I think
it means the Privileged Resource Manager? Overall, I think the
"RI" term is loosely used, for example it's defined only in Figure 1,
and about 2/3 of the time seems to mean the PRM instead of
the RNIC's programmatic interface. In fact, in 7.5.5 it's used to
mean "Remote Invalidation"!

4.2.3 describes page translation tables. Is it worth bringing out
the possibility they are multi-level and therefore possibly shared?

4.2.4 I suggest merging Mike Krause's comment/observation that
the STag does not in itself provide protection, and in fact should
provide efficiency. This is important to understanding that protection
comes from other facilities.

4.2.5 mention that Completion Queues are of bounded size (like
4.2.6) and so the size can be attacked. CQ attack is much more
likely than AEQ attack, in fact.

4.2.8 clarify the RRQ is inbound.

After (or in) 4.2.8, should add the outbound RRQ as well. It's not
easily attacked, but this queue has interesting flow control interactions
with sends. If the queue overflows, a head-of-line blocking behavior
could be encountered, which is very different from "normal" operation.

4.2.8.2 it's very important to mention that RDMA Read exposes a
buffer for RDMA Write as well. And describe the possible protection.

4.2.8.2 last paragraph, has a vague use of the phrase "data transmission
or reception". For example, RDMA Writes don't yield a completion at
the data sink, counter to the sentence.

4.2.9 refers to an STag which has only local scope that "may not
be visible from the wire". (pp starting "The next issue"). => This "may"
must be a "must" in order for the statement to be true! In fact, if it's
a "may" then a security hole is open.

4.2.10 "send" and "receive" operations - these do not mean "Send" so
are somewhat confusing.

4.2.10 - FIFO order? Perhaps "sequential", in the face of SRQ. The
paragraph goes on to describe this, but not very clearly. I suggest
not using "FIFO" in any case.

Section 5 first paragraph describes when/if the "Local peer" is untrusted.
I noticed here that "local peer" isn't defined, and in fact I think it means
the local application or ULP? I think it would be worth a pass through the
document to be sure all use of the term is consistent. And of course,
defining the term.

Section 6 - it's not clear to me what's an attacker with send-only
capabilities?

Section 7 paragraph 2 - I disagree that connection setup in stream mode
has no new attacks. This is where ULPs may exchange information. If
the information is bad, significant resource issues can clearly result. It's
true however that such exchanges are outside the scope of the document,
I just think the document should not state that there are no new attacks.

7.1.1 should perhaps introduce the PD more directly. The PD is described
in draft-hilland which is not normative.

7.1.1 goes on to say "should" associate a QP to unique PDs, or shared,
I find this discussion to not be clear. Also I'd suggest incorporating Caitlin's
"remote PD" concept, which helps to define the PD and STag scope to a
remote peer.

7.1.2 mentions "allocating STags in an unpredictable way". I want to point
out that it is also possible for the application to "advertise" STags in such
a way, if it manages its own pool. In fact, this can be much more efficient
since STag allocation is not appropriate for the performance path.

7.2.3 MITM attack discussion first says "the only countermeasure" (pp 1)
then says "the best countermeasure" (pp 2). Eh?

I think the summary of 7.2.3 is that MITM attacks should be protected in
the usual way by LLP facilities, and not in DDP/RDMAP. However it may be
worth mentioning that the MPA layer injects a CRC, making this nontrivial
(though no more secure).

In 7.4.2, to me, the most usual exposure of a buffer for RDMA Read is to
provide access to NON-stale data - i.e. an actual transfer such as client
"writing" data by advertising it for pull. Thus the zeroing memory comment
only applies in certain (rare, IMO) cases. The text only generally mentions
this by saying "combination of read and write", and could be clearer. Maybe
giving a specific example?

7.4.5 great place to mention the (more difficult) flip side - RDMA Write into
RDMA Read buffer. This is a definite issue, see my 4.2.8.2 comment.

7.4.6 suggest using the term "aliasing" to help describe the multiple STag
situation.

7.4.9 "eaves dropping" is one word. Worth referring to MITM discussion here
as well?

7.5.1 define "scarce"? Why wouldn't all resources be under the control of
the PRM?

7.5.2.1 mention that if the stream is torn down, then this additionally has
the benefit that RNIC resources are released. For example, it cuts off a
misbehaving peer drawing from a Shared RQ.

7.5.2.3 after "The local Peer can protect itself", first bullet mentions resize.
Really doesn't it just mean "size"? Also give a hint that safe size is >= sum
of all queues, etc. as described immediately following.

7.5.2.3 some of the math examples are confusing - "S-RQ" looks like a minus
sign but isn't? Also MaxPosted*OnEach*Q is not clear.

7.5.2.4 describes the situation "If the issue is a bug in the Remote Peer's
implementation, and not a malicious attack..." - so tell me, how does the
local peer know? :-)

7.5.5 has a funny title: "RI an STag Shared on Multiple Streams". Here "RI"
has a very different meaning - Remote Invalidate. Even when spelled out,
the title is awkward.

8.1 it's not clear how to protect against replay attacks at the RDDP "session"
level. (BTW, session is an undefined term.) Is reply protection purely a
function of transport? This doesn't sound right. By the way, this is only
the second mention of "replay" in the draft.

I note that 8.1.3 mentions NFS and its provision of security - presumably
referring to RPC's GSSAPI support. This is a good topic to discuss in the
NFSv4 working group, but I'm not sure what needs to be mentioned here.
What do the authors have in mind?

I note that section 8.2 is entitled "Recommendations" and describes itself
as being geared toward iSCSI requirements. But it has many MUSTs and
the sections seems somewhat more relevant for an iSCSI over RDMA
document, or perhaps a specific RDDP/IPSec layering, rather than a
general RDMA one. Is a second document appropriate?

I have not yet reviewed the appendices.

Again, good job!

Tom.