Re: [nfsv4] 4.0 trunking

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

On Thu, Sep 22, 2016 at 07:50:44PM -0400, David Noveck wrote:
> > 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''.

I think that's correct.

What I expect we'll use on the Linux is a minor variation on its
existing algorithm:

	1. a SETCLIENTID to IP address X1 returns (C, V1).
 
	2.  Later a SETCLIENTID to IP address X2 returns (C, V2).  If
	V1==V2, the two servers are different, otherwise:

	3. Send a SETCLIENTID_CONFIRM(C, V2) to X1.

That final SETCLIENTID_CONFIRM succeeds if and only if X1 and X2 are the
same.

--b.


> 	actually point to the same server:
> 
> 	3. Confirm that SETCLIENTID with SETCLIENTID_CONFIRM(client, V2)
> 	sent to X1.




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