Subject: Re: [rddp] rddp security and nfsv4

From: "John Hufferd" <[email-masked]>
Date: Sat, 23 Nov 2002 12:12:55 -0800

David,
You are right, of course, I almost added to my note: "or the needed
functional equivalent", then erased that before I sent it in order to keep
the group from spending its time re-plowing that security ground.  Well I
guess we are into it now.

Your point about NFSv4 is also right but they had a number of releases to
refine their approach which I do not think would be a productive direction
for rddp since I believe the IETF will want us to get it right the first
time.  It also seems to me that if the application (in this case NFSv4)
chooses not to use any security functions provided by RDMA sessions, it is
similar to "Optional to use".    It is not clear to me that "Optional to
use" permits us to not have a requirement to implement/offer a function
like IPsec.

Now Caitlin brings up the point that DDP
<Snip>"is supposed to run over IP transports: especially SCTP and TCP.

The ipsec charter specifies the goal as being to "develop mechanisms to
protect client protocols of IP".

So whether IPsec is present or not is just not relevant to DDP, anymore
than whether Ethernet or ATM is the L2 protocol. DDP rides just above L4.
DDP and IPsec should both be blissfully ignorant of each other."<Snip>

I am not sure that view removes the rddp workgroup from ensuring that we
know all the security exposures that are possible and ensuring that our DDP
protocol operates within that envelope and in fact can "work and play well"
and naturally with approprate security solutions such as IPsec.  It is in
fact not obvious how we set up a TCP or SCTP connection and then hand that
over to an RDMA/DDP NIC type HW implementations without carefully
understanding the approprate security approaches and security exposures
involved.  I think it would be a good idea to use IPsec as the base for our
thoughts about how this might work, and attempt to make sure we at least
understand how that might work before we invent some other techniques.

My only intended point in my original note on the subject, which you
quoted, is that I thought that IPsec was being dismissed out of hand much
to early, which is what I saw us try to do with iSCSI, only to have to go
back and fix it up before we were through.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

[email-masked]@ietf.org on 11/22/2002 06:50:58 PM

Sent by:    [email-masked]

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    [email-masked], [email-masked]
Subject:    [rddp] rddp security and nfsv4

John,

[excerpt from the rddp mailing list]
> Yes, you will find that all the new protocols in the IETF will be faced
> with IPsec.  This was not a storage issue, it is an IETF issue.  Storage
> did not seek this our, it was inflicted on Storage (for right or wrong
> reasons).  And it had nothing to do with something special
> about storage.

I'm sorry, but that's overstated in several ways.  The IETF does not
require IPsec - at least one obvious counterexample is that NFSv4 does
not use IPsec for its security.  NFSv4 does have security mechanisms
that can provide security properties similar to those that can be obtained
from IPsec, and those mechanisms were the result of what the IETF does
require - all protocol specifications must include a Security
Considerations
section (quoting from http://www.ietf.org/ID-nits.html):

   Security Considerations section
 Must have meaningful exploration of security issues raised by
 proposal, should include both risks and description of solutions or
 workarounds

Please note that identifying a serious security issue and ignoring
it is not allowed (people try this every so often - the security ADs
reject those drafts in very short order).

The security requirements for IP Storage were based on considerations of
what sort of data would be carried over those protocols, and what would
be necessary to adequately secure that data against security threats that
can be expected in a public network.  The same sort of analysis will be
expected of rddp, although it may not reach the same conclusions.

NFSv4 might be a good place to start in exploring appropriate
security mechanisms for RDDP, as NFSv4 has its own security mechanisms
built into the protocol, and there is little point in duplicating them
at a lower layer in the protocol stack.  Hence use of RDMA with NFSv4
raises some interesting security concerns:

 - Ensure that NFSv4 can still secure its payloads in the
  manner it currently does.
 - Consider how to protect the RDMA and DDP headers
  that NFSv4 doesn't currently grok.

Use of IPsec for the latter initially strikes me as akin to using
a sledgehammer to kill an ant (yes, a dead ant does result, but
accompanied by a lot of unnecessary noise and collateral damage ... ).

I've cc:'d the NFSv4 WG list in the hope of sparking some interest
in that community to work on this issue, as I believe the nfsv4
WG charter is in the process of being revised to include work on
NFSv4 over RDDP (hmm ... I wonder if they understand what they're
getting themselves into?).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
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: Sun, 24 Nov 2002 15:40:56 -0600

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