Re: [nfsv4] 4.0 trunking
"J. Bruce Fields" <bfields@fieldses.org> Thu, 22 September 2016 12:59 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 5B51E12D90A for <nfsv4@ietfa.amsl.com>; Thu, 22 Sep 2016 05:59:28 -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 jHZkRf8MwXNW for <nfsv4@ietfa.amsl.com>; Thu, 22 Sep 2016 05:59:27 -0700 (PDT)
Received: from fieldses.org (fieldses.org [IPv6:2600:3c00::f03c:91ff:fe50:41d6]) by ietfa.amsl.com (Postfix) with ESMTP id 1D20212DCC7 for <nfsv4@ietf.org>; Thu, 22 Sep 2016 05:51:46 -0700 (PDT)
Received: by fieldses.org (Postfix, from userid 2815) id 1E0D83EB; Thu, 22 Sep 2016 08:51:45 -0400 (EDT)
Date: Thu, 22 Sep 2016 08:51:45 -0400
From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20160922125145.GA30013@fieldses.org>
References: <CADaq8jcnananUPDHH4Vzhv93JTxZegsZLMCtZWFD-keHheKvHA@mail.gmail.com> <20160910200355.GA30688@fieldses.org> <BBB2EBDC-6F05-44C1-B45A-C84C24A9AD7F@netapp.com> <20160920213931.GC12789@fieldses.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jfHUr_A=90UTPG7M5+7to3bM1DiYc6sAyYWYOXQTGeTiA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/C7bzvcLsS7eCyHaNy9KSGazIONI>
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: Thu, 22 Sep 2016 12:59:28 -0000
On Thu, Sep 22, 2016 at 07:59:40AM -0400, David Noveck wrote: > The question is what else, if anything needs to be fixed. I had been > thinking that the problems you were seeing indicated that the algorithm in > section 5.8 needed correcting. 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; I could propose some language if you'd like. > I'm not sure of the exact context here, but you have to be aware of the > possibility that a new verifier will not be generated because a given > request is treated as a replay. If you are not doing a callback-changing > SETCLIENTIDs, it is easy to fall into this case. 7530 requires a new verifier even in the case the callback information isn't new. ("The server treats this as a probable callback information update and records an unconfirmed { v, x, c, k, t } and leaves the confirmed { v, x, c, l, s } in place, such that t != s. It does not matter whether k equals l or not.") If you think there's a risk anyway for some reason (bugs, or xid wraparound, maybe?), then we could continue advising a callback-changing SETCLIENTID here. (The Linux client always changes the callback information on this setclientid so my particular case isn't at issue.) To further muddy the waters: I also found Linux knfsd isn't always rejecting SETCLIENTID_CONFIRMs with incorrect verifiers when it should. Even with that bug fixed, this problem is still likely thanks to the weak verifier generation (which I'm also fixing). So I'm still motivated to fix the protocol. I checked our revision history, and that Linux nfsd bug has been there undetected from the start (13-14 years). There's some risk to depending on behavior that implementations have never previously depended on. --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