Re: [nfsv4] 4.0 trunking

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

On Thu, Sep 22, 2016 at 10:46:35AM -0400, David Noveck wrote:
> > > 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.

OK, my attempt, from scratch:

> 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'll stick a variation on the shorthands I've been using but I beleive
I'm following section 5.8 otherwise:

1. A previous SETCLIENTID to X1 returned (clientid, verifier) (C, V1).
It was confirmed and kept renewed since.

2. A new SETCLIENTID to X2 returns (C, V2).

3. Confirm it with a SETCLIENTID_CONFIRM(C, V2) to X2.

4. Send a callback-updating SETCLIENTID(C) to X1, which returns (C, V1').

5. Send a SETCLIENTID_CONFIRM(C, V1') to X2.

Then consider X1 and X2 the same server iff 5 succeeds.

This can incorrectly identify X1 and X2 as the same if V1' happens to
equal V2.  In that case X2 will see the SETCLIENTID_CONFIRM as a replay
of the one in step 3.

The RFC is aware of the possibility but expects it to be rare because
clientids and confirm verifiers are both 64-bit values, and if they were
each chosen uniformly at random from that space, the chance of both
colliding would be insignificant.

In practice they may be chosen in a predictable fashion from a limited
part of the 64-bit space.  And the birthday paradox compounds this
problem in the presence of multiple servers.

Do we agree on the problem?

--b.