Black_David | 1 May 20:10 2004

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)

Black_David | 1 May 20:31 2004

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)

Caitlin Bestler | 1 May 23:04 2004

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)

Caitlin Bestler | 1 May 23:04 2004

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)

Black_David | 1 May 23:49 2004

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)

Caitlin Bestler | 9 May 10:08 2004

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)

Caitlin Bestler | 9 May 10:13 2004

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)

Black_David | 9 May 23:18 2004

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)

Caitlin Bestler | 10 May 07:34 2004

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)

Black_David | 12 May 01:10 2004

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)


Gmane