Subject: RE: [rddp] rddp security

From: "Sukanta Ganguly" <[email-masked]>
Date: Sun, 24 Nov 2002 21:35:00 -0800

Some security is definitely required. It also seems from Caitlin's email
that a LLP based security mechanism would be fine enough. So  whether
IPSec runs below or not does not seem to have any dependencies on RDDP.
If it runs over IPSec then more power to the communication channel and
if does not then to it would not violate the RDDP protocol at all. Hence
enforcing IPSec does not really bring in a whole lot of value.

The argument of having to go through this within iSCSI is also a
questionable issue.

Not against IPSec as a security protocol to be used for RDDP, chaining
the requirement is a little too hard a requirment at this point. Other
higher layer security protocol can play an equally important role.

SG

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Sunday, November 24, 2002 1:41 PM
To: [email-masked]
Subject: Re: [rddp] rddp security

There seems to be many misconceptions about rddp, especially concerning
some vague notion that it is somehow insecure.

But compare an application using RDDP versus one using the
raw LLP connection. You will not be able to find any
additional security weaknesses.

1 - RDDP Connections are as secure or insecure as the underlying LLP
connections.

Connections are established and accepted before RDDP mode is entered.
RDDP therefore offers at security at least as strong as for applications
using the raw LLP.

Additionally, RDDP applications may use the raw LLP
connection to first establish their peer's identities before enabling
RDDP mode communications. This can be additional security, even though a
raw ULP application could do the same before enabling its own version of
"fully enabled".

RDDP messages are as secure, or insecure, from third party hijacking as
any LLP message. There is no change in security to the ULP.

2 - The Local Interface exposes local resource only to the degree
explicitly authorized by the local ULP.

A non-DDP local ULP exposes its resources to the traditional
IP stack by posting reads against a socket.

A DDP-enabled local ULP exposes it resources to the DDP
layer by pre-posting reads against a stream and/or enabling STags for
use on a stream.

In either case the local ULP is giving the keys to some of
its resource to its peer. It is ultimately responsible for ensuring that
the peer's use of those resources are in keeping with the purported
purpose of the connection.

With DDP the remote peer has more flexibility on what
*order* it uses the resources available to it. But it has no access to
*additional* resources.

It is true that a DDP-enabled ULP could inprudently enable remote access
to its entire memory. A non-DDP ULP could provide anonymous FTP access
with write access to the entire file system. Neither is advisable, but
neither is a problem with the transport layer.

3 - DDP requires the ULP to pre-authorize all receptions

Traditional IP stacks will buffer incoming data to the
extent of the LLP transmit window.

In contrast a DDP-enabled ULP must pre-post reads for all untagged
buffers and explicitly enable all tagged buffers.

The LLP-only application, therefore, provides greateure exposure of its
host system buffering capacity to denial of service attacks.

3 - DDP enables high performance in user mode.

DDP enables a performance level that cannot be matched from user mode.
RDDP enabled daemons can run in user mode. This clearly only enhances
security.

Even when working with an enhanced interface, a LLP-only application can
only direct incoming traffic to the correct buffer when it can predict
which buffer arrives next. Dynamic placement cannot take place with
establishing an ULP specific context first. This either requires
enabling ULP specific code to run in privileged mode, thereby reducing
system security, or to perform a conext switch first thereby reducing
system performance.

4 - ULP Complexity

DDP enables ULPs to co-operate with fewer ULP visible
exchanges and fewer explicit states.

Most security holes are provided by the ULP, not the
transport. A simpler ULP has a better chance of being implemented in a
robust and secure fashion.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp