[rddp] DDP/RDMAP Applicability

[Derek Atkins <[e-mail]>]

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

-derek

----

Spelling error in Abstract:

   It comparese and contrasts the different transport options over IP

should be:

   It compares ...

----

Spelling/typographical errors in section 4, Tagged Messages:

   Tagged messages standardizes direct placemtn of data without per-

should be:

   Tagged messages standardizes direct placement of data without per-

--

   DDP provides a standardized\ 'packing list' which can be interpreted

should be:

   DDP provides a standardized 'packing list' which can be interpreted

----

Typo in 6.9.2. RDMA-Conditional Session Establishment:

   In key difference is that with SCTP the determination as to whether

should (probably) be:

   One key difference ...

----
----

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.

----

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?

--

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.

> ---------- Forwarded message ----------
> Date: Wed, 05 Apr 2006 16:49:04 -0400
> From: The IESG <[e-mail]>
> To: IETF-Announce <[e-mail]>
> Cc: [e-mail]
> Subject: Last Call: 'DDP/RDMAP Security' to Proposed Standard
>
> The IESG has received a request from the Remote Direct Data Placement WG to
> consider the following documents:
>
> - 'DDP/RDMAP Security '
>    <draft-ietf-rddp-security-08.txt> as a Proposed Standard
> - 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data
>    Placement (DDP) '
>    <draft-ietf-rddp-applicability-05.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2006-04-19.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-08.txt
> http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-05.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
>
>

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant

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





ated with the 
   Page Translation Table are not relevant. 

I don't believe this is true.  I think that the security implications
of STag to Data Buffer mapping is JUST as relevant as having the Page
Translation Table.  The threats are all about an attacker trying to
get data into (or out of) a buffer they are not authorized to access.
The threats are the same regardless of the number of layers of mapping
involved.  Indeed, one would think that the Page Translation Table
makes protecting the Data Buffer EASIER, because you can add columns
to the table to include the Stream, PD, and access right information
directly in the PTT, sort of like the IPsec PAD.

----

Section 5.4.2  TLS is Inappropriate for DDP/RDMAP Security 

Part 2 talks about TLS as a connection oriented protocol and
goes on to talk about the problems of buffering and reordering
of packets.  But that's really a red-herring.  It's not TLS
that causes that.  It's TCP!  TCP requires the buffering of
out-of-order packets, because TCP assures in-order streams of
data.  So it's not TLS that causes the problem, but the choice
of using TCP.  TLS doesn't run on top of UDP.   I don't know
if TLS runs on top of SCTP.

So I don't think it's fair to blame TLS for problems that are
really a result of using TCP.

----

Section 6.2.1  Buffer Overrun - RDMA Write or Read Response 

I really like this section.  This should be emphasized more.

----

6.3.2  Using RDMA Read to Access Stale Data 

It says:

   Because of this, the local ULP SHOULD ensure that no stale data 
   is contained in the buffer before remote read access rights are 
   granted (this can be done by zeroing the contents of the memory, 
   for example).  

This reduces the threat to a race condition, but the threat still
remains.  It is still possible for an attacker to read this buffer,
only the time window is reduced before the data is zero'd.  A better
approach would be a means to allow the ULP to inform the DDP/RDMAP
that the buffer is available.  E.g., allow even an Non-Privileged ULP
to notify the engine that a buffer is "in process" and not available..
Sort of like marking the buffer (or stag) as "Busy".  That way the
Stream can only make buffers available that have valid data and you
don't get invalid data buffers.

----

Section 8  Security considerations 

Says, in its entirety:

   This entire document is focused on security considerations. 


While this statement is true, it still might be useful to reiterate
the key points of the document.   E.g.:

  - you must validate your inputs
  - dont do this, do do that, ...
  - etc.



Sam Weiler <[e-mail]> writes:

> ---------- Forwarded message ----------
> Date: Wed, 05 Apr 2006 16:49:04 -0400
> From: The IESG <[e-mail]>
> To: IETF-Announce <[e-mail]>
> Cc: [e-mail]
> Subject: Last Call: 'DDP/RDMAP Security' to Proposed Standard
>
> The IESG has received a request from the Remote Direct Data Placement WG to
> consider the following documents:
>
> - 'DDP/RDMAP Security '
>    <draft-ietf-rddp-security-08.txt> as a Proposed Standard
> - 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data
>    Placement (DDP) '
>    <draft-ietf-rddp-applicability-05.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2006-04-19.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-08.txt
> http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-05.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
>
>

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant

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