Re: [nfsv4] Potential erratta for RFC7931

Bruce Fields <bfields@fieldses.org> Mon, 03 October 2016 15:12 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1BD12B33D for <nfsv4@ietfa.amsl.com>; Mon, 3 Oct 2016 08:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.898
X-Spam-Level:
X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glwaKP6sTBWm for <nfsv4@ietfa.amsl.com>; Mon, 3 Oct 2016 08:12:00 -0700 (PDT)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id 058D012B324 for <nfsv4@ietf.org>; Mon, 3 Oct 2016 08:12:00 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id EC2511CE7; Mon, 3 Oct 2016 11:11:58 -0400 (EDT)
Date: Mon, 03 Oct 2016 11:11:58 -0400
From: Bruce Fields <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20161003151158.GE3324@fieldses.org>
References: <CADaq8jdc+5oLkvaxNkpxm65gH_X8+fGarZLAsq-bgGrUxSYC3A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jdc+5oLkvaxNkpxm65gH_X8+fGarZLAsq-bgGrUxSYC3A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/NyebjnJuFKdSc672TYPZiB4TSp0>
Cc: Bill Baker <bill.baker@oracle.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] Potential erratta for RFC7931
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2016 15:12:03 -0000

On Sat, Oct 01, 2016 at 09:02:52AM -0400, David Noveck wrote:
> 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.

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

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.