Re: [nfsv4] 4.0 trunking
"J. Bruce Fields" <bfields@fieldses.org> Fri, 23 September 2016 13:41 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 17D2512B9B0 for <nfsv4@ietfa.amsl.com>; Fri, 23 Sep 2016 06:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, 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 kCtVyU4BhcN0 for <nfsv4@ietfa.amsl.com>; Fri, 23 Sep 2016 06:40:57 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00::f03c:91ff:fe50:41d6]) by ietfa.amsl.com (Postfix) with ESMTP id 623E212BC53 for <nfsv4@ietf.org>; Fri, 23 Sep 2016 06:40:56 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id B86ED2080; Fri, 23 Sep 2016 09:40:55 -0400 (EDT)
Date: Fri, 23 Sep 2016 09:40:55 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20160923134055.GA6804@fieldses.org>
References: <CADaq8jeqr9WPeBeV0ruxwy+5omfgHhJFjAR=tCGL3N-Yjt0PuQ@mail.gmail.com> <20160921024531.GA17232@fieldses.org> <CADaq8jdUJG7zBwn7f2xtLO3gf4nvwjM2H00E6N2oTGP2b9Nzww@mail.gmail.com> <20160921141409.GA20963@fieldses.org> <20160921195339.GC24084@fieldses.org> <CADaq8jfHUr_A=90UTPG7M5+7to3bM1DiYc6sAyYWYOXQTGeTiA@mail.gmail.com> <20160922125145.GA30013@fieldses.org> <CADaq8jdW4NwFV-Lf8fjjcq48Xc+ZJnc-Gn+bOwqXLm6zH9AOUw@mail.gmail.com> <20160922160445.GD30401@fieldses.org> <CADaq8jc3A6BCcT=J+f19QcY5nyMbqHwCbANc15V0Lr4MdeeSDQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jc3A6BCcT=J+f19QcY5nyMbqHwCbANc15V0Lr4MdeeSDQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/-Z70sNclGEoMZalImLFQuWnIGCs>
Cc: "Adamson, Andy" <William.Adamson@netapp.com>, "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: Fri, 23 Sep 2016 13:41:13 -0000
On Thu, Sep 22, 2016 at 07:50:44PM -0400, David Noveck wrote: > > I'll stick a variation on the shorthands I've been using but I > > beleive I'm following section 5.8 otherwise: > > > 1. A previous SETCLIENTID to X1 returned (clientid, verifier) > > (C, V1). > > It was confirmed and kept renewed since. > > > > 2. A new SETCLIENTID to X2 returns (C, V2). > > > > 3. Confirm it with a SETCLIENTID_CONFIRM(C, V2) to X2. > > > > 4. Send a callback-updating SETCLIENTID(C) to X1, which > > returns (C, V1'). > > > > 5. Send a SETCLIENTID_CONFIRM(C, V1') to X2. > > > > Then consider X1 and X2 the same server iff 5 succeeds. > > > This can incorrectly identify X1 and X2 as the same if V1' > > happens to equal V2. > > So section 5.8 is incorrect in telling you to do that. Point taken. Later > we'll discuss what to do instead. > > > In that case X2 will see the SETCLIENTID_CONFIRM as a > > replay of the one in step 3. > > True. > > >The RFC is aware of the possibility but expects it to be rare > > because clientids and confirm verifiers are both 64-bit values, > > and if they were each chosen uniformly at random from that > > space, the chance of both colliding would be insignificant. > > I don't know if I was assuming uniform random choice. in any case, I > grossly underestimated the probability of collision. > > > In practice they may be chosen in a predictable fashion from a > > limited part of the 64-bit space. And the birthday paradox > > compounds this problem in the presence of multiple servers. > > So now we want to look at how to correct the problem. The last sentence of > that paragraph says "Note also that the callback update procedure can be > repeated multiple times to reduce the probability of further spurious > matches". Given what we've seen about the probability of single > collisions, it might seem not worth doing additional iterations. However, > if we continue your scenario, I think the probability of a false positive > can be reduced to exactly zero by doing just one more > SETCLIENTID/SETCLIENTID_CONFIRM > pair. > > So now assume that after step 5, we assume X1 and X2 are distinct if the > operation fails. However, if it succeeds, we do the following: > > 6. Send yet another callback-updating SETCLIENTID(C) to X1, which returns > (C, V1''). > > Note that V1' != V1'' > > 7. Send a SETCLIENTID_CONFIRM(C, V1'') to X2. > > If this operation fails, we conclude that X1 and X2 are distinct and that > step 5 succeeded because V1' = v2. > > If this operation succeeds, I believe we are justified in assuming that X1 > and X2 are the same. Suppose they are distinct. In this case, step 7 can > only succeed if X2 received a SETCLIENTID returning C and V1''. The only > SETCLIENTID X2 received that returned C had the verifier V2. And V2 cannot > equal V1'', since, for us to be in this case V2 = V1' and V1 != V1''. I think that's correct. What I expect we'll use on the Linux is a minor variation on its existing algorithm: 1. a SETCLIENTID to IP address X1 returns (C, V1). 2. Later a SETCLIENTID to IP address X2 returns (C, V2). If V1==V2, the two servers are different, otherwise: 3. Send a SETCLIENTID_CONFIRM(C, V2) to X1. That final SETCLIENTID_CONFIRM succeeds if and only if X1 and X2 are the same. --b. > actually point to the same server: > > 3. Confirm that SETCLIENTID with SETCLIENTID_CONFIRM(client, V2) > sent to X1. > > On Thu, Sep 22, 2016 at 12:04 PM, J. Bruce Fields <bfields@fieldses.org> > wrote: > > > On Thu, Sep 22, 2016 at 10:46:35AM -0400, David Noveck wrote: > > > > > As it now appears that the Linux client had > > > > > implemented something different than that, the correctness of > > the > > > algorithm > > > > > in section 5.8 has to be considered an open question. > > > > > > > It has the same problem; > > > > > > Please explain what the problem is. If we don't agree on what the > > problem > > > is, it is hard to come up with a solution. > > > > OK, my attempt, from scratch: > > > > > One way to do this would be to give a case where a > > > client implementing section 5.8 might interact with two servers and could > > > arrive at the wrong result, assuming the servers meet the requirements of > > > RFC7530, which are, as you pointed out, considerably weaker than those in > > > the VS paragraph in section 5.8. > > > > I'll stick a variation on the shorthands I've been using but I beleive > > I'm following section 5.8 otherwise: > > > > 1. A previous SETCLIENTID to X1 returned (clientid, verifier) (C, V1). > > It was confirmed and kept renewed since. > > > > 2. A new SETCLIENTID to X2 returns (C, V2). > > > > 3. Confirm it with a SETCLIENTID_CONFIRM(C, V2) to X2. > > > > 4. Send a callback-updating SETCLIENTID(C) to X1, which returns (C, V1'). > > > > 5. Send a SETCLIENTID_CONFIRM(C, V1') to X2. > > > > Then consider X1 and X2 the same server iff 5 succeeds. > > > > This can incorrectly identify X1 and X2 as the same if V1' happens to > > equal V2. In that case X2 will see the SETCLIENTID_CONFIRM as a replay > > of the one in step 3. > > > > The RFC is aware of the possibility but expects it to be rare because > > clientids and confirm verifiers are both 64-bit values, and if they were > > each chosen uniformly at random from that space, the chance of both > > colliding would be insignificant. > > > > In practice they may be chosen in a predictable fashion from a limited > > part of the 64-bit space. And the birthday paradox compounds this > > problem in the presence of multiple servers. > > > > Do we agree on the problem? > > > > --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