Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 16 Nov 2004 10:32:27 -0500

So it appears that Nico and Brent are in violent agreement that
requiring clients implementing the pNFS extensions to support NFSv4 
as a storage protocol is an OK thing to do.  I agree, although
I will note that requiring it will make no difference, since all
clients are going to do that anyway (if you a v4.x client and you
have general pnfs client logic, you would have to be crazy not to
support v4.x as a storage protocol).  But anyway, maybe we have 
a consensus on this issue and can move on.

Note however that nobody has said that requiring pNFS servers to
support v4 as a storage protocol is an OK to thing to do.  I
certainly don't think it is and I suspect Brent agrees.  If
Nico also agrees then maybe we can move on.  Otherwise, we can
have a detailed discussion on this issue.

As far as Brent saying:

> I would like to table all discussion of block protocol security
> as being out of scope.  I think it clouds the issue and gets in
> the way of working out an acceptable pNFS extension.

It certainly is tempting, but I don't think we can say, in Lenin's
words, "Comrades, this is no time to have an opposition".

The reason that we can't make this out of scope is that the proposal
which is under discussion is intended to allow block protocols.  If
block protocols were not possible, because of valid security issues,
then the base protocol would look different.  So, even though we 
can discuss such security issues, the bar for those raising these
security objections is very high.  I think would have to show that no
possible block protocol could be acceptable (or at least worthwhile), 
which is a very hard thing to show (since it isn't true or at least 
I don't think it is).

Nico writes:
> So what's in scope is: what sort of protocol should pNFS clients use to
> talk to the storage.

Protocol or protocols?  If it is one, the only possible answer is
NFSv4 and I think everybody agrees that that is a member of the set 
of storage protocols and in fact the first one that we should be
working on.  Any dissent?

So I think the question is best put as:

   What sort of protocols may pNFS clients use to talk to the storage?

And allowing some scope for individual choice within that set.

When Brent writes:
> 2. pNFS should allow different storage protocols.  These are OPTIONAL
> storage protocols.

I agree with him, but the optionality of these additional storage 
protocols is not guaranteed to make this stuff safe from IESG
opposition.  As Nico indicates, we don't know what position the
IESG will take on this.  We may not even know after they have
made a decision and carefully explained it to us :-).  This 
kind of uncertainty is just something we are going to have to
live with, but it should not prevent progress on the generic
parts of pnfs and on storage protocols that won't provoke
these objections.

When Nico writes:

> Perhaps this will fly past the IESG, perhaps not.  I think we should
> inquire with them at some point (and their answer may be that they can't
> yet answer so you just have to try to deliver a document to them and
> see).  Of course, first we need WG consensus on this.

I think we need to figure out how we can make progress without necessarily
have a consensus on the general goodness of block protocols for pnfs
because we may never get it.  Brent has talked about the optionality 
of additional storage protocols and my understanding is that he is
talking about the fact that implementers may choose to implement them
(or not) and that, if implemented, users may choose to use them (or
not).  The protocol development process needs to have a form of 
optionality which I'll call "severability" to distinguish it.  We need:

(1) A general pnfs architecture that allows a set of storage protocols.

(2) A description of how v4.x would be used as a storage protocol,
    including security considerations.

(3-n) A description of how the additional storage protocols would work
      in the pnfs framework, including security considerations, with one
      document for each protocol.

For me, (1) and (2) are the highest priority items and (1) is required
for everybody.  I'm assuming that there will be a v4.x spec that covers
(1) and (2) and that there may have to be negotiation with the IESG
as to (3), (4), etc. as those documents are produced but we have to be 
clear that that (1) and (2) can go ahead while hashing out the issues 
associated with (3-n) to the IESG's satisfaction.  The explanation in
(1) will have to explain that the intention is to allow block protocols
if and only if the security issues can be resolved.  I take the laissez-
faire position that their optionality constitutes an adequate resolution,
but I am worried that the IESG will adopt a more dirigiste approach.  I
think pnfs as a whole has to proceed regardless of that (I fear) endless
debate.    

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Monday, November 15, 2004 11:58 PM
To: Brent Welch
Cc: Mike Eisler; [email-masked]
Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

On Mon, Nov 15, 2004 at 07:12:12PM -0800, Brent Welch wrote:
> Let me try some simple logic.
> 
> My kitten has green eyes.  Therefore all kittens have green eyes.
> 
> Block storage protocols are insecure, 
> therefore all storage protocols are insecure.

NFSv4 is not a block storage protocol.  Neither will pNFS be one either.

You're comparing kittens to fully grown dogs.

Or is pNFS an improvement on block storage?  I don't see it that way.
Perhaps you do and can persuade us of this view?  I do see pNFS as an
improvement on _NFS_.

Seriously, figure out what security (and operational) properties you
want a pNFS to provide, figure out what you can get with each storage
protocol option and let's see where this goes.

Also, do we really have enough info right now to figure out that, yeah,
pNFS w/ iSCSI can be made to work w/o mods to deployed iSCSI boxes?  I
suspect the answer is "no."  Further, I suspect the answer is that mods
will be needed.  Finally, I'd much rather see a pNFS solution that has
security properties that truly are comparable to NFSv4's.

> I would like to table all discussion of block protocol security
> as being out of scope.  I think it clouds the issue and gets in
> the way of working out an acceptable pNFS extension.

We're not trying to improve block storage protocols, but we're trying to
come up with a parallelized NFS protocol -- a much, _much_ different
beast that block storage protocols.

So what's in scope is: what sort of protocol should pNFS clients use to
talk to the storage.

And BTW, I've yet to argue that iSCSI needs improvements.

> I am trying to communicate three points:
> 
> 1. pNFS can use NFSv4 as the storage protocol, and should be just
> as secure as NFSv4.  I think REQUIREing that NFSv4 be implemented
> by all clients as one of their possible storage protocols is OK,
> and makes perfect sense.

This is my position.  (Though some client<->storage extensions may be
needed for some things, for all I know.)

> 2. pNFS should allow different storage protocols.  These are OPTIONAL
> storage protocols.  This is important to me because my preferred
> storage protocol is object storage (iSCSI/OSD).  And, there are others
> for whom other storage protocols are important (legacy NFS servers,
> PVFS implementations, block storage on a SAN).  Harking back to the
> alice in wonderland logic above, it should be OK to allow other
> storage protocols w/out compromising pNFS when used with NFSv4 
> or some other secure storage protocol.  Please don't misinterpret this.
> OF COURSE if a customer chooses to use an insecure storage protocol
> they are taking a risk.  But, that doesn't mean all customers are
> taking the same risk because they don't have to use or provide those
> insecure storage protocols in their environment.

Perhaps this will fly past the IESG, perhaps not.  I think we should
inquire with them at some point (and their answer may be that they can't
yet answer so you just have to try to deliver a document to them and
see).  Of course, first we need WG consensus on this.

> 3. Object storage has a secure protocol, but it does place a
> demand on the pNFS client to NFSv4 server communication.
> This is worth debating. It requires that capabilities and signing
> keys be returned to the client over a secure channel so they cannot
> be snooped.

NFSv4 as the storage protocol is like an OSD that knows how to evaluate
ACLs.  Alternatives include a pNFS-server<->storage protocol that
enables a client to do X, and your capabilities token approach is a
third approach.

Cheers,

Nico
-- 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2004 10:45:04 -0600

> have a detailed discussion on this issue.

It's a package deal to me.  NFSv4 must be the REQUIRED to implement
protocol for client<->storage and client<->meta-data.

> then the base protocol would look different.  So, even though we 
                                                ^^^^^^^^^^^^^^^^^^
> can discuss such security issues, the bar for those raising these
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> security objections is very high.  I think would have to show that no
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> which is a very hard thing to show (since it isn't true or at least 

Hooey.  The NFSv4 WG charter says nothing about pNFS, so I think all
aspects of any pNFS proposals are up for discussion until consensus is
reached.

Anyways, the burden is on the authors.  Let them show us the various
combinations they have in mind and let them tell us what their security
and operational properties are.

Then we can discuss this and reach a consensus on what security
properties we _want_ and then we can talk about what's in scope and
what's not.

> And allowing some scope for individual choice within that set.

Ok.  See above.

[...]
> think pnfs as a whole has to proceed regardless of that (I fear) endless

Yes.

Thanks,

Nico
--

---

From: Julian Satran <[email-masked]>
Date: Wed, 17 Nov 2004 09:27:33 +0200

> have a detailed discussion on this issue.

I for one I stated several times that it should be OK for a pNFS server 
not to support V4 as accessing data on the "traditional" V4 path (from the 
server). However I have no opinion about mandating a pNFS server to 
support V4 maps.
Mandating support for V4 maps might even get David Black and my position 
closer :-)
 
> parts of pnfs and on storage protocols that won't provoke

Some storage protocols (mainly block) are insecure in the sense that they 
can't control except at volume level access to storage.
I was not aware that this is an area of concern for IESG (as it is beyond 
securing data in flight).