Re: [nfsv4] 4.0 trunking
"J. Bruce Fields" <bfields@fieldses.org> Thu, 08 September 2016 01:05 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 EF39D12B3B3 for <nfsv4@ietfa.amsl.com>; Wed, 7 Sep 2016 18:05:34 -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 ZXuscPpzjofG for <nfsv4@ietfa.amsl.com>; Wed, 7 Sep 2016 18:05:33 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00::f03c:91ff:fe50:41d6]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB6F12B37B for <nfsv4@ietf.org>; Wed, 7 Sep 2016 18:05:33 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id D84872218; Wed, 7 Sep 2016 21:05:32 -0400 (EDT)
Date: Wed, 07 Sep 2016 21:05:32 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20160908010532.GA10658@fieldses.org>
References: <20160907212039.GA6847@fieldses.org> <CADaq8jfiRU7DTRYXGHZvMALAZWeRjhqcpo8Si3_diMt_5dNSMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jfiRU7DTRYXGHZvMALAZWeRjhqcpo8Si3_diMt_5dNSMw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/l_tAEBY2HML-2itANlADnVI4VKI>
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: Thu, 08 Sep 2016 01:05:35 -0000
On Wed, Sep 07, 2016 at 08:14:58PM -0400, David Noveck wrote: > > But I can't find any further discussion of how a client might make that > > determination. Am I overlooking it? > > It's actually in section 5.8 of RFC7931. Oops, thanks! Looking at that, I think none of this is true: Note that the NFSv4.0 specification requires the server to make sure that such verifiers are very unlikely to be regenerated. Verifiers given out by one server shouldn't be reused, sure, but that's quite different from the claim that collisions *between* servers are unlikely. Given that it is already highly unlikely that the clientid4 XC is duplicated by distinct servers, Why is that highly unlikely? the probability that SCn is duplicated as well has to be considered vanishingly small. There's no reason to believe the probability of a verifier collision is uncorrelated with the probability of a clientid collision. The Linux server is generating clientid as a (boot time, counter) pair. So collision between servers started at the same time (probably not that unusual) is possible. Ditto for the verifier--it's a (boot time, counter) pair, with the second part coming from a different counter, but normally I think they'll get incremented at the same time, so clientid and verifier are highly correlated. So, we can mitigate this by adding some randomness, OK. But that's a new requirement not apparent from 3530, and I wouldn't be surprised if other servers have similar issues. --b. > I've only been keeping draft-ietf-nfsv4-migration-issues alive because of > the section dealing with issues relating to v4.1.Otherwise, I would have > let the thing expire. The next time I update this, I'll probably collapse > sections 4 and 5 to a short section saying that all the > v4.0 issues were addressed by publication of RFC7931. > > > (It appears that the Linux client is trying to do that by sending > > a setclientid_confirm to server1 using the (clientid,verifier) > > returned from a setclientid reply from server2. That doesn't look > > correct to me.) > > It seems kind of weird but the idea is that if you get the same clientid > from two server IP address they are probably connected to the same server > (i.e are trunked), but there is a chance that having the same clientid is a > coincidence, The idea is that if these are the same server using the > verifier will work but if they are different servers it won't work but will > be harmless. > > > On Wed, Sep 7, 2016 at 5:20 PM, J. Bruce Fields <bfields@fieldses.org> > wrote: > > > In > > https://tools.ietf.org/html/draft-ietf-nfsv4-migration- > > issues-10#section-5.4.2 > > > > In the face of possible trunking of server IP addresses, the > > client will use the receipt of the same clientid4 from multiple > > IP-addresses, as an indication that the two IP- addresses may be > > trunked and proceed to determine, from the observed server > > behavior whether the two addresses are in fact trunked. > > > > But I can't find any further discussion of how a client might make that > > determination. Am I overlooking it? > > > > (It appears that the Linux client is trying to do that by sending a > > setclientid_confirm to server1 using the (clientid,verifier) returned > > from a setclientid reply from server2. That doesn't look correct to > > me.) > > > > --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