From: Talpey, Thomas
[mailto:Thomas.Talpey <at> netapp.com]
Sent: Monday, March 01, 2004 8:54
To: Jim Pinkerton; rddp <at> ietf.org
Subject: Comments on
reviewed the recent RDDP Security draft
and have some comments in advance
working group meeting.
to open by complimenting the authors on an excellent
second revision. This is a
difficult document, but an important
have many high-level comments. The draft seems
thing to mention though - there are many, many
references to "later" or
other sections, especially in the earlier
ones. I suggest direct section
current draft has one reference to “later”. This is now fixed.
and em-dashes seem to have a different ascii
encoding, which appear strangely
with certain text tools.
Suggest conventional ascii.
Fixed 4 quotes, 10 dashes.
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?
definition is in the introduction in the -02 version of the draft. I have
refined the introductory text a bit in the upcoming -03 draft though. Main
issue is the intro implies that anytime you share resources you better only do
it if there is Partial Mutual Trust. That is not true – many types of
resources can be shared safely, and are fully examined in the existing text. However,
there are some conditions where sharing of a specific type of resource has
unmitigated attacks, thus the only time the specific resource should be shared
is if a condition of Partial Mutual Trust exists.
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,
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
appreciate specific recommendations on what to change here.
pargraph 1 last sentence - "should be preserved when
under attack", just delete
"when under attack" and say "should
be preserved". Maybe even
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.
a Shared-RQ is first-in, first-out – i.e. they are taken off of the queue
in the order they were put on. As to when the actual completion occurs is an
entirely separate issue. That said, I don’t think the FIFO statement
actually adds anything, so will remove it.
buffer exposed to "the Internet"? This is vague.
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
catch. I had abreviated Remote Invalidate to make it fit in the table at the
end of the document, but that table is gone, so it is no longer an issue. For
clarity, I have removed all referenced to “RI” and instead used
either RNIC Interface, RNIC (some of the references were not to an interface,
but to the entire RNIC), or Remote Invalidate .
describes page translation tables. Is it worth bringing out
the possibility they are
multi-level and therefore possibly shared?
prefer not. There are a ton of different implementation techniques within the
RNIC. Going to the gory details can be endless, and I don’t think
terribly useful. The document already assumes the Page Translation Tables can
be shared, so I have added a note in this section to that effect. Section 4.2.9
“The exact resource allocation
algorithm for the Page Translation Table is outside the scope of this
specification. It may be allocated for a specific Data Buffer, or be allocated
as a pooled resource to be consumed by potentially multiple Data Buffers, or be
managed in some other way. This paper attempts to abstract implementation
dependent issues, and focus on higher level security issues such as resource
starvation and sharing of resources between Streams.”
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.
appreciate specific text suggestions here.
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.
Likely or not, they are attackable. Is there a suggested text change?
clarify the RRQ is inbound.
What is the RRQ?
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.
Again, what is the RRQ? Are you talking about the Send Queue? If so, the
discussion you outlined above has no security issues, so why go into it? This
isn’t a document focused on the application developer...
it's very important to mention that RDMA Read exposes a
buffer for RDMA Write as well. And
describe the possible protection.
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
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.
rewritten the sentence to be clearer.
“The next issue is how an STag
name is associated with a Data Buffer. For the case of an Untagged Data Buffer,
there is no wire visible mapping between an STag and the Data Buffer. Note that
there may, in fact, be an STag which represents the buffer. However, because the
STag by definition is not visible on the wire, this is a local host specific
issue which should be analyzed in the context of local host implementation
specific security analysis, and thus is outside the scope of this paper.”
"send" and "receive" operations - these do not mean
are somewhat confusing.
me this is a knit. I’ve finessed the text a little to try to make things
clearer though. We were trying to avoid the keywords Send Queue and Receive
Queue, since they are reserved words in other specifications. I’ve bailed
on not using Receive Queue and Send Queue though - I think it makes things a
bit clearer (also defined it in the appropriate place).
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
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.
- it's not clear to me what's an attacker with send-only
re-reading this, it really doesn’t convey the intent at all. Here’s
the proposed re-wording:
capabilities delimit the types of attacks that attacker is able to launch.
RDMAP and DDP require that the initial LLP Stream (and connection) be set up
prior to transferring RDMAP/DDP Messages. Attackers with send only capabilities
must first guess the current LLP Stream parameters before they can attack RNIC
resources (e.g. TCP sequence number). Attackers with both send and receive
capabilities have presumably setup a valid LLP Stream, and thus have a wider
ability to attack RNIC resources.”
Is this any
clearer? If not, can you propose something?
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.
added this point to the paragraph.
should perhaps introduce the PD more directly. The PD is described
in draft-hilland which is not
isn’t even informative – it’s not a work group draft. Thus it
seems inappropriate to bring it into this context. We’ve intentionally
tried to abstract above a verbs implementation to not bog us down on whether
the security analysis implies that we’ve also signed up for verbs being
the “one true way”. That said, it was the intent that the security
analysis completely covers all wire visible security issues embodied in verbs.
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
I don’t understand your issue. To me the text is clear. Please suggest
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.
text to say “Allocating and/or advertising STags numbers in an unpredictable
MITM attack discussion first says "the only countermeasure" (pp 1)
then says "the best
countermeasure" (pp 2). Eh?
don’t see the the issue. Pp1 states two ways. Pp2 states the best way is
the first way (i.e. IPSec, rather then local link security).
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).
don’t understand the point.
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?
don’t understand the ambiguity. I walk through a specific example (i.e. “the
Remote Peer may be able to examine the contents of the buffer before they are
initialized with the correct data.”).
great place to mention the (more difficult) flip side - RDMA Write into
RDMA Read buffer. This is a
definite issue, see my 188.8.131.52 comment.
suggest using the term "aliasing" to help describe the multiple STag
"eaves dropping" is one word. Worth referring to MITM discussion here
define "scarce"? Why wouldn't all resources be under the control of
seems like a knit. The dictionary definition is used. I did change the text to
say “... scarce (i.e. bounded)...”. Does this scratch your itch?
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
"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
meant resize. I’ve reworded it to make this more clear.
the CQ to the appropriate level, as specified below (note that if the CQ
currently exists, and it needs to be resized, resizing the CQ can fail, so the
CQ resize should be done before sizing the Send Queue and Receive Queue on the Stream),
some of the math examples are confusing - "S-RQ" looks like a minus
sign but isn't? Also
MaxPosted*OnEach*Q is not clear.
name of “S-RQ” to “SRQ”. Added formal definitions of
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?
you’re joking (??) Each of the attacks has a specific counter measure
identified, with appropriate normative statements. So the local peer can
differentiate, and it doesn’t matter.
a funny title: "RI an STag Shared on Multiple Streams". Here
has a very different meaning -
Remote Invalidate. Even when spelled out,
the title is awkward.
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.
are four references to replay in the doc. Replay is a generic term, but
specifically in this draft it is packet sequencing replay. Within IPSec, there
are specific features defined to detect replays.
On session, I
agree that it is confusing. I’ve swept the document to replace “session”
with “Stream” where appropriate. In some cases (e.g. IPSec session
keys), session is still appropriate. Also when stated “Stream and/or
session level authentication”. I think with reduced scope of the
term “session” we don’t have to define it.
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?
went over this during today’s meeting, so I won’t go into this
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
8.2 is completely rewritten to now just cross reference the IP Storage security
not yet reviewed the appendices.