Re: [nfsv4] Potential erratta for RFC7931

[Bruce Fields <[e-mail]>]

On Mon, Oct 03, 2016 at 07:21:18PM -0400, David Noveck wrote:
> > Nit: I believe your argument was that one repeat was sufficient. > If that's
> the case, let's say that.
> 
> Good point.  See the replacement paragraph below
> 
> > 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."
> 
> That's already within the replaced paragraph.

Gah, sorry.

> The new proposed replacement paragraph is as follows:
> 
> 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.  Repeating the
> procedure once  is
> sufficient to ensure that the successive confirm values SCn, SCn'
>  generated by these repeated SETCLIENTID operations cannot all collide with
> a verifier previously received by the client when communicating with IPn.

Sounds good, I'd just delete "at least once" in the above.

I mean, it's technically accurate, but it leaves me wondering why you're
suggesting that I might want to do this more times.

--b.

> 
> 
> On Mon, 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.
> >
> > --b.
> >