RE: [rddp] Re: SecDir review assignment

["Jim Pinkerton" <[e-mail]>]

 
Derek, thanks for the detailed review. Comments/updated text enclosed below. I should have a revised ID by end of next, pending any feedback you have on my revisions.
 
 
Jim
 
 
 
 
> -----Original Message-----
> From: Derek Atkins [mailto:[e-mail]]
> Sent: Wednesday, April 19, 2006 2: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.
[<jim>] 
I modified the sentence to state:
 
Protection Domains are assigned to three of the resources of concern - Stream Context Memory, STags associated with Page Translation Table entries, and data buffers. 
 
> 
> ----
> 
> 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?
[<jim>] 
 
This was a typo that was introduced as part of the rewrite to address concerns about Untagged data transfers not having high enough exposure. Thus the document submitted for your review re-categorized the three mechanisms as two, as stated. So your math is right :-) thanks.
 
> 
> --
> 
> 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 ...
[<jim>] 
Done. Thanks.
 
> 
> ----
> 
> 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.
[<jim>] 
 
As David mentioned, the intent was to state that if the resource doesn't exist, you can't attack it. To make this more explicit, I modified the text to:
 
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). If there is no Page Translation Table, then attacks based on changing its contents or exhausting its resources are not possible.
 
 
> 
> ----
> 
> 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.
> 
[<jim>] 
 
Per David's suggestion, I've attempted to make it more clear that the issue is an interaction between TLS/TCP when RDMAP/DDP concepts are applied. Here's the text.
 
2.    TLS is a connection oriented protocol. If a stream cipher or block cipher in CBC mode is used for bulk encryption, then a packet can be decrypted only after all the packets preceding it have already arrived. If TLS is used to protect DDP/RDMAP traffic, then TCP must gather all out-of-order packets before TLS can decrypt them. Only after this is done can RDMAP/DDP place them into the ULP buffer. Thus one of the primary features of DDP/RDMAP - enabling implementations to have a flow-through architecture with little to no buffering, can not be achieved if TLS is used to protect the data stream.
 
> ----
> 
> Section 6.2.1  Buffer Overrun - RDMA Write or Read Response
> 
> I really like this section.  This should be emphasized more.
> 
[<jim>] 
 
Apologies, but I'm unsure on what to do here. I think the topic is well covered in the section. Please advise on what needs to 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.
> 
[<jim>] 
David's comment was right on, in terms of the intent - apologies for not making this clear that with this solution the race is eliminated. Revised text:
 
If a buffer is being used for some combination of reads and writes (either remote or local), and is exposed to a Remote Peer with at least remote read access rights, the Remote Peer may be able to examine the contents of the buffer before it is initialized with the correct data. Because of this potential race condition, whatever contents were present in the buffer before the buffer is advertised can be viewed by the Remote Peer, if the Remote Peer performs an RDMA Read. This becomes a security issue if the prior contents of the buffer were not intended to be shared with the Remote Peer.
To eliminate this race condition, 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 ensures that the Remote Peer can not access the buffer until the stale data has been removed.
 
 
 
> ----
> 
> 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.
[<jim>] 
 
The spec has quite a bit of summary info in the appendices - but totally understood the text isn't very professional. Would the following work, where I provide a brief overview of the various sections and goals? Here's the text:
 
Please see Sections 5 Attacks That Can be Mitigated With End-to-End Security, Section 6 Attacks from Remote Peers, and Section 7 Attacks from Local Peers, for a detailed analysis of attacks and normative countermeasures to mitigate the attacks. 
 
Additionally, the appendices provide a summary of the security requirements for specific audiences. Section 11 Appendix A: ULP Issues for RDDP Client/Server Protocols provides a summary of implementation issues and requirements for applications which implement a traditional client/server style of interaction. It provides additional insight and applicability of the normative text in Sections 5, 6, and 7. Section 12, Appendix B: Summary of RNIC and ULP Implementation Requirements provides a convenient summary of normative requirements for implementers.
 
 
 
 
> 
> 
> 
> 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

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