Subject: [nfsv4] SSV

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 21 Dec 2009 11:59:15 -0500

Will anyone have an SSV implementation at connectathon?

I'm a bit worried.  The protocol doesn't give any way to negotiate SSV
support that I can see: the client requests some form of state
protection, and the server has to either accept it or fail the whole
EXCHANGE_ID.  Will there be servers released that claim 4.1 and kerberos
support but don't support SSV, and if so are clients going to have to
figure out some way to work around that?

--b.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 21 Dec 2009 11:08:37 -0600

> Will anyone have an SSV implementation at connectathon?

We will not.

> figure out some way to work around that?

Why is it a problem? There aren't any 4.0 servers in existence and so 
called 4.0 clients understand
how to work around that.

I.e., there is not a 4.0 server/client which has the 
mandatory-to-implement SPKM3/LIPKEY.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 21 Dec 2009 13:13:35 -0500

>> Will anyone have an SSV implementation at connectathon?

OK, thanks.

By the way, same question for SP4_MACH_CRED--are people implementing it,
or is SP4_MACH_NONE the only thing clients can count on for now?

> mandatory-to-implement SPKM3/LIPKEY.

One difference is the security flavor negotiation, which makes it easy
for the client to recover (or at least return a reasonable error to the
user) in the case where the server doesn't support SPKM3 or LIPKEY.

If a client decides some day it wants to support SSV, and sends an
EXCHANGE_ID specifying SP4_SSV, what happens next?  Our server currently
sends nfserr_encr_alg_unsupp, which doesn't seem quite right to me.  But
maybe it's an obvious enough error that all servers can use it, and
clients can translate it into "mount failed; ssv not supported".  In
which case good, I agree, releasing a server without SSV support sounds
OK.

If the server's stuck returning some catch-all IO error (SERVERFAULT,
INVAL?) then we'll have a harder time adding in SSV later.

--b.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 21 Dec 2009 13:50:13 -0800

> INVAL?) then we'll have a harder time adding in SSV later.

SERVERFAULT would be the best error, since there is an assumption SSV
is REQUIRED. As you say, it is non-negotiable; the choice is for the
client's convenience not that of the server.

I don't see what role the error status value has in whether you add
SSV later.

Let's keep in mind that SSV state protection
was added because it was claimed
that it was  "too hard" to deploy machine credentials.

If no one implements SSV state protection, then we should conclude that
it while it might be hard to deploy machine credentials, but
implementing the solution is even harder. We can then schedule the
removal of SSV support from NFSv4.2.

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

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/