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.