RE: [rddp] Re: SecDir review assignment

[[e-mail]]

Derek,

Thanks for your review of this and the applicability draft.  It
looks like all the issues involve wording, but I wanted to make
a few comments on some of your concerns that may appear to be technical:

--------

> 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.

I believe that what was intended was to say that if there is no Page
Translation Table, then attacks based on changing its contents or
exhausting its resources are impossible.  The text will need to be
rephrased to say that.

-------------

> Section 5.4.2  TLS is Inappropriate for DDP/RDMAP Security

[... snip ...]

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

I believe both protocols share the blame, and the text should be
revised to make it clear that it is the TLS/TCP combination that
has the drawback.

-------------

> 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.

This text needs some clarifying editing, because it is attempting
to describe the "better approach," namely to zero a not-remotely-
accessible buffer *before* authorizing remote access to it.

Thanks,
--David (rddp WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------



> -----Original Message-----
> From: Derek Atkins [mailto:[e-mail]] 
> Sent: Wednesday, April 19, 2006 5:58 PM
> To: [e-mail]
> Cc: Russ Housley; Pat Cain; Sam Hartman; [e-mail]
> Subject: [rddp] 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 <[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-applicabil
> ity-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
> 

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