Re: [nfsv4] 4.0 trunking

[David Noveck <[e-mail]>]

> Great, let me know when there's something to review.

Right now I'm having trouble deciding exactly what needs to be fixed.
Clearly, the paragraph in section 5.8 containing the phrase "vanishingly
small" needs to be corrected since it is, as you pointed out, incorrect.
In the future, I'll refer to this as "the VS paragraph".

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.

> The Linux client looks like it's actually doing something even simpler,

And thus different!

So the questions we need to address are:

   - Whether the algorithm is section 5.8 has been implemented by any
   client.
   - Whether anybody has any reason to believe that that algorithm in
   section 5.8 would not work as described there, even when servers do not
   conform to the VS paragraph.

> basically:
>
>       1. a SETCLIENTID to IP address X1 returns a clientid.  You
>       confirm it and carry on.
>
>       2.  Some time later a SETCLIENTID to IP address X2 returns the
>       same clientid, and verifier V2.  To check whether X1 and X2
>       actually point to the same server:
>
>       3. Confirm that SETCLIENTID with SETCLIENTID_CONFIRM(client, V2)
>       sent to X1.
>

I don't see how that would be helpful.  By hypothesis, X1 and X2 both think
that a specific clientid4/verifier pair is valid.  If that is the case, a
SETCLIENTID_CONFIRM to X1 will succeed, independently of whether X1 and X2
are the same server or not.

> And I don't see how to shoehorn this extra check in there,

So, is the non-shoehorn-able extra check you are referring to the list item
3 above?  If that is the case, then it is easy to see how, given what you
have told us about how the server is assigning clientid4 and verifier
values, why this is commonly resulting in identifying separate servers as
the same.  On the other hand, I can see how someone reading the VS
paragraph might assume that the probability of this happening with two
different servers was "vanishingly small" and so punt.

> so I think it
> needs to add in the extra callback-changing SETCLIENTID to X1.

Although the text is not as clear as it might be , the intention of the
algorithm in section 5.8 is that the SETCLIENTID be done to X2 and
confirmed on X1.  It probably would work the other way around but the
critical part is that the SETCLIENTID and SETCLIENTID_CONFIRM have to go to
different IP addresses, in order to help determine whether  those two
addresses are connected to the same server.

> Oh, now that I look at it I think it's really easy.

Unfortunately, my experience has been that the probability, in this area,
of thinking that something is really easy, and it turning out tht way, is
"vanishingly small" :-(

> All we have to do
> is check that the verifier has changed since step 1.

How exactly do you expect to do that?

>If it has, continue to step 3,

If it has, then I don't see how they could be different servers.

> if it hasn't, they're different servers.

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.

On Wed, Sep 21, 2016 at 3:53 PM, J. Bruce Fields <[e-mail]>
wrote:

> On Wed, Sep 21, 2016 at 10:14:09AM -0400, J. Bruce Fields wrote:
> > On Wed, Sep 21, 2016 at 05:09:59AM -0400, David Noveck wrote:
> > > I think that works.  I'm going to look at how to update section 5.8 of
> > > RFC7931.
> >
> > Great, let me know when there's something to review.
> >
> > The Linux client looks like it's actually doing something even simpler,
> > basically:
> >
> >       1. a SETCLIENTID to IP address X1 returns a clientid.  You
> >       confirm it and carry on.
> >
> >       2.  Some time later a SETCLIENTID to IP address X2 returns the
> >       same clientid, and verifier V2.  To check whether X1 and X2
> >       actually point to the same server:
> >
> >       3. Confirm that SETCLIENTID with SETCLIENTID_CONFIRM(client, V2)
> >       sent to X1.
> >
> > And I don't see how to shoehorn this extra check in there, so I think it
> > needs to add in the extra callback-changing SETCLIENTID to X1.
>
> Oh, now that I look at it I think it's really easy.  All we have to do
> is check that the verifier has changed since step 1.  If it has,
> continue to step 3, if it hasn't, they're different servers.
>
> --b.
>