Re: [nfsv4] 4.0 trunking
"J. Bruce Fields" <bfields@fieldses.org> Wed, 14 September 2016 16:07 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 DEB9612B396 for <nfsv4@ietfa.amsl.com>; Wed, 14 Sep 2016 09:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 riku9-028UTe for <nfsv4@ietfa.amsl.com>; Wed, 14 Sep 2016 09:07:17 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00::f03c:91ff:fe50:41d6]) by ietfa.amsl.com (Postfix) with ESMTP id ECEB312B36A for <nfsv4@ietf.org>; Wed, 14 Sep 2016 08:48:54 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 65173A8D; Wed, 14 Sep 2016 11:48:54 -0400 (EDT)
Date: Wed, 14 Sep 2016 11:48:54 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20160914154854.GA26422@fieldses.org>
References: <20160907212039.GA6847@fieldses.org> <CADaq8jfiRU7DTRYXGHZvMALAZWeRjhqcpo8Si3_diMt_5dNSMw@mail.gmail.com> <20160908010532.GA10658@fieldses.org> <CADaq8jcnananUPDHH4Vzhv93JTxZegsZLMCtZWFD-keHheKvHA@mail.gmail.com> <20160910200355.GA30688@fieldses.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160910200355.GA30688@fieldses.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/X886AXzLZSQN-6Bbiz5X28ZDj-0>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] 4.0 trunking
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: Wed, 14 Sep 2016 16:07:19 -0000
On Sat, Sep 10, 2016 at 04:03:55PM -0400, J. Bruce Fields wrote: > On Sat, Sep 10, 2016 at 03:38:29PM -0400, David Noveck wrote: > > Thanks for pointing this out. > > > > Before I address the details of this, let me state my overall position: > > > > - I think it is correct that RFC7931 overstates the degree of assurance > > that one might reasonably have regarding the unlikelihood of spurious > > collision of clientid4's and verifiers. > > - Nevertheless, I don't think the situation is as bleak as you paint it, > > with regard to the Linux server approach to these matters that you > > describe. This is basically because I don't see the issue of the > > correlation between clientid4's and verifiers the same way that you do. See > > below. > > - I think it is possible to address the issue satisfactorily in the > > context of an errata rfc7931 errata and will start working on that. > > - Given the weakness of the rfc 3530/7530 requirements in this area, we > > may need (yet another) RFC updating 7530 at some point. > > - I see that as a longer-term effort, since the practices that you > > describe will not result in large numbers of spurious collisions and > > clients can adapt the algorithm to require additional verification. > > - If there are servers out there whose practices are significantly more > > troublesome than the ones you describe, we need to find out soon. Given > > that many of those responsible for v4.0 implementations may not be reading > > this list, I suggest we discuss this at the October Bakeathon. > > > > > > > The Linux server is generating clientid as a (boot time, counter) pair. > > > > I'm assuming the boot time is in the form of a 32-bit unsigned number of > > seconds after some fixed date/time. Correct? > > > > If that is the case, duplicates would require that: > > 1. Two servers be booted during the same second (e.g. when power came back > > on after a disruption). > > Right, or routine maintenance, or whatever. > > > 2. Each of the servers has received the same number of client SETCLIENTIDs > > (mod 4 billion). > > > > Clearly this is possible although I would say that it is unlikely. > > Nevertheless, the "highly unlikely" in RFC7931 is overstating it. > > It turns out that if you have a hundred servers that get rebooted > simultaneously for a kernel update or some similar routine maintenance, > this happen every time. (I'm a step removed from the original case > here, but I believe this is more-or-less accurate and not hypothetical.) > > Pretty sure you can easily hit this without that big a setup, too. > > > The case that would be more worrisome would be one which a server simply > > used a 64-bit word of byte-addressable persistent memory (e.g. NVDIMM, 3d > > xpoint) to maintain a permanent counter, dispensing with the boot time. > > That'd be something worth looking into in cases the users have the right > hardware (not always). (Though note you'd still want to randomize the starting value.) > The workaround I'm going with for now is > initializing the counter part to something random. (Random numbers may > not be completely reliable at boot time either, but I suspect they'll be > good enough here...). > > > That is allowable as RFC7530 stands. I don't expect that this is a current > > problem but, given where persistent memory is going (i.e. cheaper and more > > common), we could see this in the future. > > > > Clearly, spurious clientid4 collisions are possible, which is the point of > > the whole algorithm. > > > > > Ditto for the verifier--it's a (boot time, counter) pair, Sorry, I got this wrong, our verifier is (setclientid time, counter). The problem remains, because as with boot times, setclientid times are often clustered together. (In the case of a client boot or server reboot, the client is likely sending setclientid's to all the servers it cares about at the same time.) --b.
- [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking Adamson, Andy
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking David Noveck
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking Andy Adamson
- Re: [nfsv4] 4.0 trunking J. Bruce Fields
- Re: [nfsv4] 4.0 trunking Chuck Lever
- Re: [nfsv4] 4.0 trunking J. Bruce Fields