Remote Direct Data Placement

Black_David | 1 May 2004 20:10

issue (5) - Protection for shared RQ, closure

One more attempt at restating the requirement:

  The proposed requirement is that the Privileged Resource Manager
  contain code sufficient so that a non-RDDP application can be
  converted to an RDDP application without enabling a denial of
  service attack that disconnects innocent clients or having to
  write inter-client receive resource protection code.  This is
  a "MUST implement" requirement, so that the functionality is
  available to any RDDP application; applications MAY use this
  protection, but are not required to do so.

As noted previously:
  a) With my WG chair hat on, I'm going to say that solving
	this shared RQ resource protection problem is a
	requirement on the rddp WG's output.  This is a fairly
	fundamental system robustness issue, even within
	a single application.
And on this basis, I believe the above restatement of the
requirement represents rough consensus of the rddp WG.  This
requirement will also apply to shared completion queue protection.

Any further objections to this should be posted to the list,
but please be clear about whether the objection is to the obligation
to solve this problem (a), or to the solution (Privileged Resource
Manager MUST implement Shared RQ protection).

Thanks,
--David

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

(Continue reading)

headers

Black_David | 1 May 2004 20:31

Security draft issue (4) - IPsec

On to the last, and most difficult open issue from Seoul - what
should RDDP (specifically the security draft) have to say about
a mandatory-to-implement security mechanism.  Here's an extract
from the minutes:

  Section 9 - Should we require IPsec, and therefore implement 
  this section, or make it optional? Suggestion that it be made 
  "mandatory-to-implement, optional-to-use." It was observed that 
  IPS had a similar section because it needed it. Also, now that 
  there is the IKEv2 specification to refer to, the problem is no longer 
  so difficult to document.  Look at IKEv2 and new "Cryptographic
  Algorithms for IKEv2" draft.  If these are used this section in
  the RDDP security draft may not be necessary, as an IKEv2
  reference will be adequate. 

  (4) Core question: Should we say that IPsec is mandatory for RDDP? 
  Secondary question: What parts do we actually require? (IKEv2?)

I have heard a couple of comments on this that deserve some further
elaboration.

- Q: RDDP is part of the transport, can't we defer the security
	requirements to whatever the ULP above the transport requires?
- A: Yes, but that would only cover the payloads, as the ULP won't
	know anything about RDDP headers.  To follow this approach,
	either we have to have a way to protect the RDDP headers or to
	make their protection unnecessary (e.g., as SSL/TLS makes
	protection of TCP headers unnecessary).  The latter approach
	will have to deal with RDDP enabling direct placement of network
	data into ULP/application memory, which seems to be a resource

(Continue reading)

headers

Caitlin Bestler | 1 May 2004 23:04

Re: Security draft issue (4) - IPsec


On May 1, 2004, at 9:31 PM, Black_David <at> emc.com wrote:

> On to the last, and most difficult open issue from Seoul - what
> should RDDP (specifically the security draft) have to say about
> a mandatory-to-implement security mechanism.  Here's an extract
> from the minutes:
>
>   Section 9 - Should we require IPsec, and therefore implement
>   this section, or make it optional? Suggestion that it be made
>   "mandatory-to-implement, optional-to-use." It was observed that
>   IPS had a similar section because it needed it. Also, now that
>   there is the IKEv2 specification to refer to, the problem is no 
> longer
>   so difficult to document.  Look at IKEv2 and new "Cryptographic
>   Algorithms for IKEv2" draft.  If these are used this section in
>   the RDDP security draft may not be necessary, as an IKEv2
>   reference will be adequate.
>
>   (4) Core question: Should we say that IPsec is mandatory for RDDP?
>   Secondary question: What parts do we actually require? (IKEv2?)
>
> I have heard a couple of comments on this that deserve some further
> elaboration.
>
> - Q: RDDP is part of the transport, can't we defer the security
> 	requirements to whatever the ULP above the transport requires?
> - A: Yes, but that would only cover the payloads, as the ULP won't
> 	know anything about RDDP headers.  To follow this approach,
> 	either we have to have a way to protect the RDDP headers or to

(Continue reading)

headers

Caitlin Bestler | 1 May 2004 23:04

Re: Security draft issue (4) - IPsec


On May 1, 2004, at 9:31 PM, Black_David <at> emc.com wrote:

> On to the last, and most difficult open issue from Seoul - what
> should RDDP (specifically the security draft) have to say about
> a mandatory-to-implement security mechanism.  Here's an extract
> from the minutes:
>
>   Section 9 - Should we require IPsec, and therefore implement
>   this section, or make it optional? Suggestion that it be made
>   "mandatory-to-implement, optional-to-use." It was observed that
>   IPS had a similar section because it needed it. Also, now that
>   there is the IKEv2 specification to refer to, the problem is no 
> longer
>   so difficult to document.  Look at IKEv2 and new "Cryptographic
>   Algorithms for IKEv2" draft.  If these are used this section in
>   the RDDP security draft may not be necessary, as an IKEv2
>   reference will be adequate.
>
>   (4) Core question: Should we say that IPsec is mandatory for RDDP?
>   Secondary question: What parts do we actually require? (IKEv2?)
>
> I have heard a couple of comments on this that deserve some further
> elaboration.
>
> - Q: RDDP is part of the transport, can't we defer the security
> 	requirements to whatever the ULP above the transport requires?
> - A: Yes, but that would only cover the payloads, as the ULP won't
> 	know anything about RDDP headers.  To follow this approach,
> 	either we have to have a way to protect the RDDP headers or to

(Continue reading)

headers

Black_David | 1 May 2004 23:49

RE: Security draft issue (4) - IPsec

Caitlin,

> Until IPsec is mandatory-to-implement for IP hosts I see no
> justification for making it mandatory for RDDP endpoints. And
> of course if it were mandatory-to-implement for IP Hosts, RDDP
> would not have to implement it.

IPsec is mandatory-to-implement for IPv6 hosts, FWIW.  The IESG
will not approve standards-track RFCs that lack mandatory-to-
implement security measures, although it's possible to reference
measures that already exist elsewhere in the environment.

If RDDP introduced no new risks above and beyond TCP or SCTP
over IPv4, then falling back to the security requirements of
those underlying protocols might be acceptable - I don't
believe this to be the case, though (i.e., there are new
RDDP-specific security risks).

Thanks,
--David 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Caitlin Bestler [mailto:cait <at> asomi.com] 
> Sent: Saturday, May 01, 2004 5:05 PM

(Continue reading)

headers

Caitlin Bestler | 9 May 2004 10:08

RE: Security draft issue (4) - IPsec


Black_David <at> emc.com said:
> Caitlin,
>
>> Until IPsec is mandatory-to-implement for IP hosts I see no
>> justification for making it mandatory for RDDP endpoints. And
>> of course if it were mandatory-to-implement for IP Hosts, RDDP
>> would not have to implement it.
>
> IPsec is mandatory-to-implement for IPv6 hosts, FWIW.  The IESG
> will not approve standards-track RFCs that lack mandatory-to-
> implement security measures, although it's possible to reference
> measures that already exist elsewhere in the environment.
>
> If RDDP introduced no new risks above and beyond TCP or SCTP
> over IPv4, then falling back to the security requirements of
> those underlying protocols might be acceptable - I don't
> believe this to be the case, though (i.e., there are new
> RDDP-specific security risks).
>
> Thanks,
> --David

I do not see any RDDP specific vulnerabilities that are relevant
to the use of IPsec.

A non-RDDP application enables reception of peer messages into
application buffers. Given the nature of non-RDDP LLPs, use
of intermediate system buffering is likely.

(Continue reading)

headers

Caitlin Bestler | 9 May 2004 10:13

RE: Security draft issue (4) - IPsec


Black_David <at> emc.com said:
> Caitlin,
>
>> Until IPsec is mandatory-to-implement for IP hosts I see no
>> justification for making it mandatory for RDDP endpoints. And
>> of course if it were mandatory-to-implement for IP Hosts, RDDP
>> would not have to implement it.
>
> IPsec is mandatory-to-implement for IPv6 hosts, FWIW.  The IESG
> will not approve standards-track RFCs that lack mandatory-to-
> implement security measures, although it's possible to reference
> measures that already exist elsewhere in the environment.
>
> If RDDP introduced no new risks above and beyond TCP or SCTP
> over IPv4, then falling back to the security requirements of
> those underlying protocols might be acceptable - I don't
> believe this to be the case, though (i.e., there are new
> RDDP-specific security risks).
>
> Thanks,
> --David

I do not see any RDDP specific vulnerabilities that are relevant
to the use of IPsec.

A non-RDDP application enables reception of peer messages into
application buffers. Given the nature of non-RDDP LLPs, use
of intermediate system buffering is likely.

(Continue reading)

headers

Black_David | 9 May 2004 23:18

RE: Security draft issue (4) - IPsec

Caitlin,

> I do not see any RDDP specific vulnerabilities that are relevant
> to the use of IPsec.
> 
> A non-RDDP application enables reception of peer messages into
> application buffers. Given the nature of non-RDDP LLPs, use
> of intermediate system buffering is likely.
> 
> Once received, the Application judges the applicability of
> transport layer security to its needs. It may determine that
> the transport has provided sufficient authentication of the
> remote peer to allow acting upon the received messages without
> further validation, or it may decide to apply its own validation.
> 
> So what changes with RDDP?
> 
> Nothing, except that the intermediate system buffering is
> far less likely. That *improves* security, not worsens it.
> 
> Whether or not IPsec is in use, the Application already
> has full control of which of its buffers are exposed,
> to what extent, and for how long. Procedures to precisely
> control that exposure are already documented in the security
> draft and are not dependent on the use of IPsec or other
> transport layer security.

I think this misses the point by focusing on data instead of
control.  The thing that has changed is that RDDP exposes
a new functional interface for use over the network, providing

(Continue reading)

headers

Caitlin Bestler | 10 May 2004 07:34

RE: Security draft issue (4) - IPsec


Black_David <at> emc.com said:
> Caitlin,
>
>> I do not see any RDDP specific vulnerabilities that are relevant
>> to the use of IPsec.
>>
>> A non-RDDP application enables reception of peer messages into
>> application buffers. Given the nature of non-RDDP LLPs, use
>> of intermediate system buffering is likely.
>>
>> Once received, the Application judges the applicability of
>> transport layer security to its needs. It may determine that
>> the transport has provided sufficient authentication of the
>> remote peer to allow acting upon the received messages without
>> further validation, or it may decide to apply its own validation.
>>
>> So what changes with RDDP?
>>
>> Nothing, except that the intermediate system buffering is
>> far less likely. That *improves* security, not worsens it.
>>
>> Whether or not IPsec is in use, the Application already
>> has full control of which of its buffers are exposed,
>> to what extent, and for how long. Procedures to precisely
>> control that exposure are already documented in the security
>> draft and are not dependent on the use of IPsec or other
>> transport layer security.
>
> I think this misses the point by focusing on data instead of

(Continue reading)

headers

Black_David | 12 May 2004 01:10

RE: Security draft issue (4) - IPsec

Caitlin,

Could you explain a couple of things:

> Nothing, except that the intermediate system buffering is
> far less likely. That *improves* security, not worsens it.

How does this improve security?  What is(are) the threat(s) whose
risk is reduced by eliminating intermediate buffering?

> What has not changed is that no matter what is in the network
> packet, the exposure of application buffers to those packets
> is under control of the application -- not of the network
> packet.
> 
> How precisely the application control the exposure of its
> buffer space, relative to its security requirements, is the
> real issue. The vulnerability of network packets is not
> an RDDP specific issue.
> 
> If the application has tailored its exposure, the attacker
> can modify the headers endlessly. They will still only be
> able to deposit the payload in the buffers the Data Sink
> ULP intended them to be deposited into.

What are the implications of that "If"?  What does an application
have to do to match the buffer exposure of TCP or SCTP via the
sockets interface?  Under what circumstances is that reasonable
(e.g., what other usage patterns does RDDP intend to enable)?
What are the potential consequences of allowing more buffer

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

2	December 2011
8	June 2009
3	May 2009
3	April 2009
25	March 2009
7	February 2009
4	January 2009
10	December 2008
1	October 2008
1	September 2008
2	November 2007
7	October 2007
3	September 2007
2	June 2007
7	May 2007
1	April 2007
8	January 2007
5	October 2006
6	September 2006
4	August 2006
6	July 2006
31	June 2006
7	May 2006
18	April 2006
6	March 2006
1	February 2006
1	January 2006
3	December 2005
3	November 2005
12	October 2005
11	September 2005
8	August 2005
2	July 2005
2	June 2005
5	May 2005
12	April 2005
32	March 2005
12	February 2005
10	January 2005
29	December 2004
36	November 2004
39	October 2004
22	September 2004
37	August 2004
19	July 2004
60	June 2004
32	May 2004
59	April 2004
26	March 2004
31	February 2004
59	January 2004
4	December 2003
22	November 2003
34	October 2003
7	September 2003
22	August 2003
121	July 2003
97	June 2003
133	May 2003
98	April 2003
15	March 2003
122	February 2003
58	January 2003
233	December 2002
151	November 2002
91	October 2002
50	September 2002
5	August 2002
20	July 2002