Subject: [nfsv4] Potential erratta for RFC7931

From: David Noveck <[email-masked]>
Date: Sat, 1 Oct 2016 09:02:52 -0400

Based on the recent discussion that Bruce and I had, I'm thinking of filing
an erratta, replacing the following paragraph in section 5.8:

Note that the NFSv4.0 specification requires the server to make sure
that such verifiers are very

unlikely to be regenerated.Given that it is already highly unlikely
that the clientid4 XC

is duplicated by distinct servers, the probability that SCn is
duplicated as well has to be

considered vanishingly small.  Note also that the callback update
procedure can be

repeated multiple times to reduce the probability of further spurious matches.

With the following replacement:

Although the NFSv4.0 specification requires the server to make sure that
such verifiers are very unlikely to be regenerated, different servers may
use the same approach to the construction of such verifiers, raising the
probability that two distinct servers might inadvertently assign the same
verifier value. The fact that the servers in question have assigned the
same clientid4 may raise this probability.  In order to guard against the
possibility that such assignments might cause two distinct

servers to be incorrectly considered the same, the SETCLIENTID procedure
mentioned above needs to be repeated at least once.  This will ensure that
the sucessive confirm values SCn, SCn'. SCn'' generated by these repeated
SETCLIENTID operations cannot all collide with a verifier previously
received by the client when communicating with IPn.

Comments?

---

From: Bruce Fields <[email-masked]>
Date: Mon, 3 Oct 2016 11:11:58 -0400

On Sat, Oct 01, 2016 at 09:02:52AM -0400, David Noveck wrote:
> mentioned above needs to be repeated at least once.

Nit: I believe your argument was that one repeat was sufficient.  If
that's the case, let's say that.

And the bottom of p. 24 also needs an update: "Note also that the
callback update procedure can be repeated multiple times to reduce the
probability of further spurious matches."

I'd update it to something like: "The callback update procedure must
then be repeated one more time".

> This will ensure that

I think that's correct, and it's a minimal change, and therefore maybe
it's the right thing for errata.

It bugs me that the only client I've looked at does something different
and much simpler.

After receiving the SETCLIENTID with a clientid matching an established
one, the modified RFC7931 requires, if I have it right:

	1. SETCLIENTID_CONFIRM to the new server.
	2. SETCLIENTID to the old server.
	3. SETCLIENTID_CONFIRM to the new server.  And with this fix:
	4. SETCLIENTID to the old server.
	5. SETCLIENTID_CONFIRM to the new server.

Whereas the Linux client needs only:

	1. SETCLIENTID_CONFIRM to the old server.

And that works just as well.  (The existing Linux client has the same
bug, but that is fixed with just a single if statement and no more
round trips.)

So at some point I'd hope we can document this, as 1) it's actually
being used by a major client so people need to know about it, 2) it's
easier to implement and analyze.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 3 Oct 2016 11:26:10 -0400

> On Oct 3, 2016, at 11:11 AM, Bruce Fields <[email-masked]> wrote:
> 

The Linux client implements something simpler because, at least so far,
it does not support trunking at all. The detection algorithm in that
client is to _avoid_ trunking, when a client administrator (accidentally?)
configures multiple mount points of the same server via different
server interfaces.

The algorithm documented here is for a client fully capable of trunking.

I don't see a strong need to document the weaker algorithm in an RFC.

--
Chuck Lever

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 3 Oct 2016 11:37:07 -0400

> configures multiple mount points of the same server via different

Either way we're trying to answer the question "do these two addresses
point to the same server"?  The only difference is in what we do with
that information--something not covered by this algorithm.

> I don't see a strong need to document the weaker algorithm in an RFC.

There's nothing weaker about this algorithm.  If you see something I'm
missing, please explain.

--b.

---

From: Chuck Lever <[email-masked]>
Date: Mon, 3 Oct 2016 12:25:30 -0400

> On Oct 3, 2016, at 11:37 AM, J. Bruce Fields <[email-masked]> wrote:
> 

I don't see any language in RFC 7931 that says "clients MUST use
exactly this algorithm." Thus I feel the algorithm documented in
RFC 7931 is no more than an implementation suggestion, just as
similar sections of RFCs 7530 and 5661 are no more than that.

Documenting every implementation of trunking detection that doesn't
match what is in that RFC doesn't seem reasonable.

1) "people need to know about it" : Is there a particular
interoperability concern you see arising out of the use of the simpler
algorithm?

2) "easier to analyze" : there is already analysis in RFC 7931. Is
that analysis inadequate enough to replace it? Is there a substantial
problem with it?

At this point RFC 7931 is immutable (aside from errata). Unless there
is a significant reason to update that document, I would rather use
the errata approach.

--
Chuck Lever

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 3 Oct 2016 17:01:49 -0400

> interoperability concern you see arising out of the use of the simpler

No, that was probably overreach, sorry.  Other things being equal, I'd
certainly rather we document what's in actually in use, but it's not the
end of the world.

> that analysis inadequate enough to replace it? Is there a substantial

I don't know of anything major beyond this one issue.

Mainly the algorithm and accompanying analysis are just much more
complicated than necessary, which makes it harder to get right.

> is a significant reason to update that document, I would rather use

Sure, maybe it's too late for a bigger rewrite.

--b.

---

From: David Noveck <[email-masked]>
Date: Mon, 3 Oct 2016 19:21:18 -0400

> Nit: I believe your argument was that one repeat was sufficient. > If that's
the case, let's say that.

Good point.  See the replacement paragraph below

> And the bottom of p. 24 also needs an update: "Note also that
> the callback update procedure can be repeated multiple times
> to reduce the probability of further spurious matches."

That's already within the replaced paragraph.

The new proposed replacement paragraph is as follows:

servers to be incorrectly considered the same, the SETCLIENTID procedure
mentioned above needs to be repeated at least once.  Repeating the
procedure once  is
sufficient to ensure that the successive confirm values SCn, SCn'
 generated by these repeated SETCLIENTID operations cannot all collide with
a verifier previously received by the client when communicating with IPn.

---

From: Bruce Fields <[email-masked]>
Date: Tue, 4 Oct 2016 14:18:22 -0400

> That's already within the replaced paragraph.

Gah, sorry.

> a verifier previously received by the client when communicating with IPn.

Sounds good, I'd just delete "at least once" in the above.

I mean, it's technically accurate, but it leaves me wondering why you're
suggesting that I might want to do this more times.

--b.

---

From: David Noveck <[email-masked]>
Date: Wed, 5 Oct 2016 16:10:59 -0400

> Sounds good, I'd just delete "at least once" in the above.

I will do that change.  Since you can't repeat something less than once,
the change cleans things up while leaving
the meaning the same.

"the SETCLIENTID procedure mentioned above needs to be repeated at least
once" --> "the SETCLIENTID
procedure mentioned above needs to be repeated"

---

From: Bruce Fields <[email-masked]>
Date: Wed, 5 Oct 2016 16:14:06 -0400

> procedure mentioned above needs to be repeated"

OK, thanks.--b.