RE: DDP/RDMAP Applicability

Derek Atkins wrote:
> I was asked to review the DDP/RDMAP specifications.  Here are
> my comments on draft-ietf-rddp-applicability-05.txt
> 

Typos noted and fixed. Thanks.

> 
> ----
> ----
> 
> Section 6.6 : Data Integrity Implications
> 
> CRC32 helps protect against accidental data corruption, but
> not intensional data corruption.  An attacker could easily
> intentionally corrupt the data and a CRC32 cannot detect
> that.  I recommend some stronger wording that an active
> attacker could easily subvert the CRC32, or at least
> additional text that explains that CRC32 only protects
> against accidental data corruption and not intensional data
> corruption. 
> 

Clarification on the types of corruption will be added.

> ----
> 
> Section 9 : Security considerations
> 
> The discussion of the steering tag doesn't discuss what
> information is exposed, or how guessable these tags could be.
>  What's the implication of a "peer" guessing at random STags?
>  Could I get data that I shouldn't have access to?  Are these
> STags tied to a particular peer session, and if so how?
> 

A paragraph will be added to emphasize that STags must be
validated for use on a connection. Therefore there is a set
of advertised buffers that a peer can access, and those
are the *only* buffers that the peer can use. There is
no "guessing" involved.

However there is no way for the RDMA layer to know that
the peer has not *confused* which of the buffers it is
authorized to use and has specified the wrong one.

> --
> 
> There's no discussion of peer authentication.  How do I know
> who I'm talking to and how do I authenticate and authorize
> their RDMA access?
> 
> ----
> 
> Section 9.2 : Tagged Buffer Exposure
> 
> This section does not go into enough detail of what can
> happen if an attacker can insert random (or worse, non
> random!) data into arbitrary buffers.  We've got so many
> buffer overrun attacks.  Imagine what could happen if an
> attacker didn't need to overrun a buffer but could co-opt the
> RDMA and insert arbitrary data into buffers directly.
> 

Language will be added emphasizing that random data placed
into advertised buffers must be handled by the ULP, just
as sending arbitrary data over a non-RDMA connection must
be detected and handled up the ULP.