Re: [rddp] Re: SecDir review assignment

[Derek Atkins <[e-mail]>]

Yes, your descriptions sound good to me.

Technically I did not have significant concerns of these drafts.

-derek

[e-mail] writes:

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

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