Subject: RE: [rddp] rddp security

From: [email-masked]
Date: Mon, 25 Nov 2002 18:55:48 -0500

Caitlin,

Well-written, but needs to be taken just a little bit farther ...

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

Absent RDDP, the local resources in question cannot be exposed.
It may be that much of the exposure here is dealt with via:

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

in that from the ULP's standpoint, its memory behavior and rules
for what it may and may not do are similar to those that would
apply for pre-posted receives to a conventional transport stack.
That'll need a good explanation in the Security Considerations
section of the DDP draft.

RDMA is different, as in working through the NFSv4 example,
one discovers that RDMA READ provides a path to the ULP's memory
that avoids the ULP's security (oops).  Asking NFSv4 to run its RPC
security processing before exposing memory for transfer (source)
or after the transfer has been deposited in memory (sink) may
not be the best choice (e.g., vs. providing some way for the
"right thing" to happen on the fly - in essence, one might want
RDMA READ to suck the data through the RPC security processing on
both ends rather than ignoring it).

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

I'm not sure how much that helps from a security standpoint
(inherent implementation complexity is difficult to analyze),
but it's going to need a lot more explanation to convince those
who aren't already convinced.

Thanks,
--David

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Sunday, November 24, 2002 4: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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 25 Nov 2002 23:27:52 -0600

On 11/25/02, [email-masked] wrote:

>I'm not sure how much that helps from a security
>standpoint (inherent implementation complexity is
>difficult to analyze), but it's going to need a lot more
>explanation to convince those who aren't already convinced.
>
All other things being equal, a DDP-enabled ULP will be less
complex for the simple reason that it has fewer explicit
states. All other things being equal, an application with
fewer states will be more robust and have fewer security
risks.

To illustrate why a DDP-enabled application has fewer
states, consider a client that sends a single request for
three related variably-sized data items from a server.

Without DDP, it must:
    send the request
    receive item-A
    receive item-B
    receive item-C
    receive the overall status.
    
With DDP it only has to:
    send the request
    receive the overall status.
    
When an application can work in broader strokes, its state
model simplifies. This has always been true, but it
traditionally comes with a negative performance tradeoff
(throuh use of middleware packages, RPC, CORBA, etc.). RDMA
offers the application both greater simplicity and improved
performance.

Caitlin Bestler

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 25 Nov 2002 23:37:00 -0600

On 11/25/02, [email-masked] wrote:

>
>RDMA is different, as in working through the NFSv4
>example, one discovers that RDMA READ provides a path to
>the ULP's memory that avoids the ULP's security (oops). 
>Asking NFSv4 to run its RPC security processing before
>exposing memory for transfer (source) or after the
>transfer has been deposited in memory (sink) may not be
>the best choice (e.g., vs. providing some way for the
>"right thing" to happen on the fly - in essence, one might
>want RDMA READ to suck the data through the RPC security
>processing on both ends rather than ignoring it).
>
On its own DDP does have a stream orientation to security.
STags are enabled for a stream, not particular packets on a
stream, etc. But that doesn't mean that a ULP could not
implement a more dynamic/selective security mechanism
itself.

An RDMAP aware RPC could implement selective security within
a single RDMAP stream without requiring any hooks in either
the DDP or RDMAP implementations.

The RPC implementations position themselves as the ULP to
RDMAP. They exchange STags between themselves.

An authorized request that requires access to a restricted
region is translated using the correct STag.

For long-lived sessions, such as NFS, the ULP could also
consider establishing multiple streams each with a different
security clearance. Of course that is a more viable approach
under SCTP than TCP.

Caitlin Bestler