Subject: RE: [rddp] DDP/RDMAP Applicability

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 20 Apr 2006 09:19:36 -0700

Derek Atkins wrote:
> I was asked to review the DDP/RDMAP specifications.  Here are
> my comments on draft-ietf-rddp-applicability-05.txt
> 

Typos noted and fixed. Thanks.

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

Clarification on the types of corruption will be added.

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

A paragraph will be added to emphasize that STags must be
validated for use on a connection. Therefore there is a set
of advertised buffers that a peer can access, and those
are the *only* buffers that the peer can use. There is
no "guessing" involved.

However there is no way for the RDMA layer to know that
the peer has not *confused* which of the buffers it is
authorized to use and has specified the wrong one.

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

Language will be added emphasizing that random data placed
into advertised buffers must be handled by the ULP, just
as sending arbitrary data over a non-RDMA connection must
be detected and handled up the ULP.

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 20 Apr 2006 13:08:44 -0700

These are additional paragraphs that would address the questions raised:

In 6.6 (data integrity implications)

   CRC32c only provides protection against random corruption.  To
   protect against unauthorized alteration or forging of data packets
   security methods must be applied.  Use of IPSEC is supported for 
   both SCTP and MPA/TCP.

In 9.1 (Security Consideratins - Connection/Association Setup)

   Authentication of peers and approval of connections is outside of the
   scope of DDP.  Connections are initiated and accepted by the ULP
   using authentication information as provided by the LLP.  IPSEC is
   usable for both TCP and SCTP.

In 9.2 (Security Considerations - Tagged Buffer Exposure)

   DDP validates that STags are only used by the remote peer to the
   extent authorized by the ULP.  The STag is selects amongst authorized
   buffers; an STag by itself does not authorize access.  Spacing STags
   is more a defense against 'off by one' errors than a cryptographic
   protection.

---

From: [email-masked]
Date: Thu, 20 Apr 2006 18:02:58 -0400

Caitlin,

The correct capitalization of IPsec is IPsec ("sec" is lower case).
I also noticed that the ESP reference needs to be updated from
RFC 2406 to RFC 4303 - it is one of a number of references that
aren't cited in the body of the draft (citations should be added
or the reference dropped).  I also have a few comments below.

Please make these changes plus the typo fix noted in previous email
and submit the resulting draft on Monday, just in case anyone else
wants to comment on the new text in the interim.

Thanks,
--David (rddp WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Thursday, April 20, 2006 4:09 PM
> To: [email-masked]
> Subject: RE: [rddp] DDP/RDMAP Applicability
> 

Add a comma at the end of this line.

>    usable for both TCP and SCTP.

"using authentication information as provided by the LLP" could be
misread as implying use of LLP identities.  Change it to "and
connection authentication is the responsibility of the ULP".  In 
addition to fixing the capitalization of IPsec, add the following
to the end of the last sentence above : "and can provide authentication
at a protocol layer beneath DDP"

>    buffers;

"is selects amongst authorized buffers" --> "selects among buffers
previously authorized by the ULP"

>          an STag by itself does not authorize access.  Spacing STags

Replace the last sentence with:

	Use of randomization in generating STag values may be useful in
	preventing 'off by one' and other programmatic errors, but is
	of limited value in countering generation and misuse of STag values
	by an active attacker.  IPsec provides countermeasures that can
	prevent such an unauthorized attacker from gaining access to
	buffers used by DDP and RDMAP.