Re: [nfsv4] Potential erratta for RFC7931

["J. Bruce Fields" <[e-mail]>]

On Mon, Oct 03, 2016 at 11:26:10AM -0400, Chuck Lever wrote:
> 
> > On Oct 3, 2016, at 11:11 AM, Bruce Fields <[e-mail]> wrote:
> > 
> > On Sat, Oct 01, 2016 at 09:02:52AM -0400, David Noveck wrote:
> >> Although the NFSv4.0 specification requires the server to make sure that
> >> such verifiers are very unlikely to be regenerated, different servers may
> >> use the same approach to the construction of such verifiers, raising the
> >> probability that two distinct servers might inadvertently assign the same
> >> verifier value. The fact that the servers in question have assigned the
> >> same clientid4 may raise this probability.  In order to guard against the
> >> possibility that such assignments might cause two distinct
> >> 
> >> servers to be incorrectly considered the same, the SETCLIENTID procedure
> >> mentioned above needs to be repeated at least once.
> > 
> > Nit: I believe your argument was that one repeat was sufficient.  If
> > that's the case, let's say that.
> > 
> > And the bottom of p. 24 also needs an update: "Note also that the
> > callback update procedure can be repeated multiple times to reduce the
> > probability of further spurious matches."
> > 
> > I'd update it to something like: "The callback update procedure must
> > then be repeated one more time".
> > 
> >> This will ensure that
> >> the sucessive confirm values SCn, SCn'. SCn'' generated by these repeated
> >> SETCLIENTID operations cannot all collide with a verifier previously
> >> received by the client when communicating with IPn.
> >> 
> >> Comments?
> > 
> > I think that's correct, and it's a minimal change, and therefore maybe
> > it's the right thing for errata.
> > 
> > It bugs me that the only client I've looked at does something different
> > and much simpler.
> > 
> > After receiving the SETCLIENTID with a clientid matching an established
> > one, the modified RFC7931 requires, if I have it right:
> > 
> > 	1. SETCLIENTID_CONFIRM to the new server.
> > 	2. SETCLIENTID to the old server.
> > 	3. SETCLIENTID_CONFIRM to the new server.  And with this fix:
> > 	4. SETCLIENTID to the old server.
> > 	5. SETCLIENTID_CONFIRM to the new server.
> > 
> > Whereas the Linux client needs only:
> > 
> > 	1. SETCLIENTID_CONFIRM to the old server.
> > 
> > And that works just as well.  (The existing Linux client has the same
> > bug, but that is fixed with just a single if statement and no more
> > round trips.)
> > 
> > So at some point I'd hope we can document this, as 1) it's actually
> > being used by a major client so people need to know about it, 2) it's
> > easier to implement and analyze.
> 
> The Linux client implements something simpler because, at least so far,
> it does not support trunking at all. The detection algorithm in that
> client is to _avoid_ trunking, when a client administrator (accidentally?)
> configures multiple mount points of the same server via different
> server interfaces.

Either way we're trying to answer the question "do these two addresses
point to the same server"?  The only difference is in what we do with
that information--something not covered by this algorithm.

> The algorithm documented here is for a client fully capable of trunking.
> 
> I don't see a strong need to document the weaker algorithm in an RFC.

There's nothing weaker about this algorithm.  If you see something I'm
missing, please explain.

--b.