Re: [nfsv4] 4.0 trunking

[David Noveck <[e-mail]>]

> > As it now appears that the Linux client had
> > implemented something different than that, the correctness of > > the
algorithm
> > in section 5.8 has to be considered an open question.

> It has the same problem;

Please explain what the problem is.  If we don't agree on what the problem
is, it is hard to come up with a solution.

One way to do this would be to give a case where a
client implementing section 5.8 might interact with two servers and could
arrive at the wrong result, assuming the servers meet the requirements of
RFC7530, which are, as you pointed out, considerably weaker than those in
the VS paragraph in section 5.8.

> I could propose some language if you'd like.

If you are talking about language proposing how to address the problem, you
feel exists, then you could do that.  However I feel it would be better if
we focused first on the question of what the problem is.

> 7530 requires a new verifier even in the case the callback
> information isn't new.

Good point but I'm unclear about whether this would count as a verifier
"change".  It was never clear how you would test this.  Anyway, this is a
case in which a new verifier is generated but the old one remains valid
Whether this counts as the verifier being changed depends on how you test
for verifiers being changed.

On Thu, Sep 22, 2016 at 8:51 AM, J. Bruce Fields <[e-mail]>
wrote:

> On Thu, Sep 22, 2016 at 07:59:40AM -0400, David Noveck wrote:
> > The question is what else, if anything needs to be fixed.  I had been
> > thinking that the problems you were seeing indicated that the algorithm
> in
> > section 5.8 needed correcting.  As it now appears that the Linux client
> had
> > implemented something different than that, the correctness of the
> algorithm
> > in section 5.8 has to be considered an open question.
>
> It has the same problem; I could propose some language if you'd like.
>
> > I'm not sure of the exact context here, but you have to be aware of the
> > possibility that a new verifier will not be generated because a given
> > request is treated as a replay.  If you are not doing a callback-changing
> > SETCLIENTIDs, it is easy to fall into this case.
>
> 7530 requires a new verifier even in the case the callback information
> isn't new.  ("The server treats this as a probable callback information
> update and records an unconfirmed { v, x, c, k, t } and leaves the
> confirmed { v, x, c, l, s } in place, such that t != s.  It does not
> matter whether k equals l or not.")
>
> If you think there's a risk anyway for some reason (bugs, or xid
> wraparound, maybe?), then we could continue advising a callback-changing
> SETCLIENTID here.
>
> (The Linux client always changes the callback information on this
> setclientid so my particular case isn't at issue.)
>
> To further muddy the waters: I also found Linux knfsd isn't always
> rejecting SETCLIENTID_CONFIRMs with incorrect verifiers when it should.
> Even with that bug fixed, this problem is still likely thanks to the
> weak verifier generation (which I'm also fixing).  So I'm still
> motivated to fix the protocol.
>
> I checked our revision history, and that Linux nfsd bug has been there
> undetected from the start (13-14 years).  There's some risk to depending
> on behavior that implementations have never previously depended on.
>
> --b.
>