Re: [nfsv4] 4.0 trunking

[David Noveck <[e-mail]>]

> 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.

So section 5.8 is incorrect in telling you to do that.  Point taken.  Later
we'll discuss what to do instead.

> In that case X2 will see the SETCLIENTID_CONFIRM as a
> replay of the one in step 3.

True.

>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.

I don't know if I was assuming uniform random choice.  in any case, I
grossly underestimated the probability of collision.

> 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.

So now we want to look at how to correct the problem.  The last sentence of
that paragraph says "Note also that the callback update procedure can be
repeated multiple times to reduce the probability of further spurious
matches".   Given what we've seen about the probability of single
collisions, it might seem not worth doing additional iterations.  However,
if we continue your scenario, I think the probability of a false positive
can be reduced to exactly zero by doing just one more
SETCLIENTID/SETCLIENTID_CONFIRM
pair.

So now assume that after step 5, we assume X1 and X2 are distinct if the
operation fails.  However, if it succeeds, we do the following:

6. Send yet another callback-updating SETCLIENTID(C) to X1, which returns
(C, V1'').

Note that V1' != V1''

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

If this operation fails, we conclude that X1 and X2 are distinct and that
step 5 succeeded because V1' = v2.

If this operation succeeds, I believe we are justified in assuming that X1
and X2 are the same.  Suppose they are distinct.  In this case, step 7 can
only succeed if X2 received a SETCLIENTID returning C and V1''.  The only
SETCLIENTID X2 received that returned C had the verifier V2.  And V2 cannot
equal V1'', since, for us to be in this case V2 = V1' and V1 != V1''.

On Thu, Sep 22, 2016 at 12:04 PM, J. Bruce Fields <[e-mail]>
wrote:

> 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.
>