Re: SecDir review assignment

Hi,

I was asked to review draft-ietf-rddp-security-08.txt.  Enclosed
below are my comments.

-derek

----

Section 2.2.4  Protection Domain (PD)

It says:

                                Protection 
   Domains are assigned to two of the resources of concern, Stream 
   Context Memory and STags associated with Page Translation Table 
   entries and data buffers. 

This is confusing.  What are the "two resources of concern"?  I
don't know how to parse the rest of this sentence into two objects,
in my reading I see three:

  1) Stream Context Memory
  2) STags associated with Page Translation Table entires
  3) data buffers

I suspect some simple punctuation marks could help here.

----

Section 2.3.2  Non-Privileged Data Interface Semantics 

It says:

         . Three RDMAP data transfer mechanisms are 
   defined, one using Untagged data transfer (Send Type Messages), 
   and one using Tagged data transfer (RDMA Read Responses and RDMA 
   Writes).

Maybe my math is wrong, but I only count two mechanisms here:

  1) using Untagged data transfer (Send Type Messages)
  2) using Tagged data transfer (RDMA Read Responses and RDMA Writes)

What's the third?

--

A couple paragraphs later it says:

              For data reception, for DDP it can receive Untagged 
   Messages into buffers that have been posted on the Receive Queue 
   or Shared Receive Queue. 

This sentence doesn't parse properly.  I think you need to remove
the second "for" and the following "it", so it reads:

         For data reception, DDP can receive ...

----

Section 2.3.4  Initialization of RNIC Data Structures for Data Transfer  

It says:

   Note that an implementation may not have a Page Translation Table 
   (i.e. it may support a direct mapping between an STag and a Data 
   Buffer). In this case threats and mitigations associated 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 <[email protected]> writes:

> ---------- Forwarded message ----------
> Date: Wed, 05 Apr 2006 16:49:04 -0400
> From: The IESG <[email protected]>
> To: IETF-Announce <[email protected]>
> Cc: [email protected]
> 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
> [email protected] or [email protected] 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>
>
>

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