Re: [nfsv4] Potential erratta for RFC7931

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

On Mon, Oct 03, 2016 at 12:25:30PM -0400, Chuck Lever wrote:
> 
> > On Oct 3, 2016, at 11:37 AM, J. Bruce Fields <[e-mail]> wrote:
> > 
> > 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.
> 
> I don't see any language in RFC 7931 that says "clients MUST use
> exactly this algorithm." Thus I feel the algorithm documented in
> RFC 7931 is no more than an implementation suggestion, just as
> similar sections of RFCs 7530 and 5661 are no more than that.
> 
> Documenting every implementation of trunking detection that doesn't
> match what is in that RFC doesn't seem reasonable.
> 
> 1) "people need to know about it" : Is there a particular
> interoperability concern you see arising out of the use of the simpler
> algorithm?

No, that was probably overreach, sorry.  Other things being equal, I'd
certainly rather we document what's in actually in use, but it's not the
end of the world.

> 2) "easier to analyze" : there is already analysis in RFC 7931. Is
> that analysis inadequate enough to replace it? Is there a substantial
> problem with it?

I don't know of anything major beyond this one issue.

Mainly the algorithm and accompanying analysis are just much more
complicated than necessary, which makes it harder to get right.

> At this point RFC 7931 is immutable (aside from errata). Unless there
> is a significant reason to update that document, I would rather use
> the errata approach.

Sure, maybe it's too late for a bigger rewrite.

--b.