Subject: [rddp] Re: SecDir review assignment

From: Derek Atkins <[email-masked]>
Date: Wed, 19 Apr 2006 17:57:49 -0400

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-masked]> writes:

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

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

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinFrom [email-masked] Thu Apr 20 10:34:47 2006
From: Derek Atkins <[email-masked]>
To: [email-masked]
Date: Wed, 19 Apr 2006 17:57:49 -0400
Cc: Russ Housley <[email-masked]>, Pat Cain <[email-masked]>,
	Sam Hartman <[email-masked]>, [email-masked]
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 associfo/rddp

---

From: Derek Atkins <[email-masked]>
Date: Wed, 19 Apr 2006 13:12:47 -0400

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.

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

ated with the 

----

----

----

It says:

----

Says, in its entirety:

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

---

From: Derek Atkins <[email-masked]>
Date: Wed, 19 Apr 2006 13:12:47 -0400

-derek

----

should be:

   It compares ...

----

should be:

--

should be:

----

should (probably) be:

   One key difference ...

----
----

----

--

----

---

From: "Jim Pinkerton" <[email-masked]>
Date: Fri, 21 Apr 2006 13:57:14 -0700

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:[email-masked]]
> Sent: Wednesday, April 19, 2006 2:58 PM
> Cc: Russ Housley; Pat Cain; Sam Hartman; [email-masked]
[<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. 
 
>   2) using Tagged data transfer (RDMA Read Responses and RDMA Writes)
[<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.
 
[<jim>] 
Done. Thanks.
 
> 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.

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

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

>   - dont do this, do do that, ...
[<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.