Return-Path: 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 0914512B387 for ; Thu, 22 Sep 2016 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fRRBcCzQpKe7 for ; Thu, 22 Sep 2016 07:53:26 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F28312B2A3 for ; Thu, 22 Sep 2016 07:46:37 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id a62so6456510oib.1 for ; Thu, 22 Sep 2016 07:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kve6nfgMFCf8PSIpMKDnV9M+LnA1pTtVLU79De7Rpq8=; b=yTFyH9FjicgDzwnonvOs7PK0iCvdISQXPn4dDgZHk4luIbRoEAZgHnbParDSAizk0h 5OtgZtk0+pOwuhQgyuoY5xJq/6TJ0WAzmRQRk9Q7q5RZfe9l5xSaPANOKMJC6Fv3e7X6 YFybKba28QDu1t0Sc2k/kBI6FLbpIARcG46pCWtFXLuT1VWtVPoN46+dxcwnc0YM7qhJ pnxrckXhSp3ouIIl9GwoMgTppdDhvC29dyNVmLujNThDnDPUEm3xbqZxReqsXrP4HcUf 0J8Z6OFfIaW0CEtsZB+K9UTx/54fTwGhRDs9G/iIkyD1+eaTip/sArf7i9wcIlp71aiR mFbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kve6nfgMFCf8PSIpMKDnV9M+LnA1pTtVLU79De7Rpq8=; b=bz7VGPzPE+rI2X7mosXREnA/Q7pcyPpMe4i4QrMtR4GCBloT4PqAVHZF6xAvs7+12O Spe9mOmA7UgFj5+HsC49lj+RjzbnEPIKHINP4k+4rBJnn+dom9G1shHoyscIO4jVo64O j+i73CTotxtK+ZUtLmqaYvFJbEX6WiPSEBHOZhnfWHOVsO9sdTXoTioM0H/NbiFSy+JB CzYBqtffDb8kxmzLTMdai7jHcTdzO9KNLqRmQD9zSt+RwpyL7W79bWVpVT5VpooJv11p XK2Iu2gdH5d+5EDZe8eigXTnPqNTe4Y+6kLWk8GPTohV/eWZLOlyrytL2ynZbdhwc8we uoYQ== X-Gm-Message-State: AE9vXwPhOK2cqyifAsxsl+9xSquqZ41EggtHIfia8Y2xpNrJ5ox9Ip5Juhc8SUKyGakkrtvgCIBF320M4o+QyQ== X-Received: by 10.202.76.207 with SMTP id z198mr2835468oia.29.1474555596880; Thu, 22 Sep 2016 07:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.192.10 with HTTP; Thu, 22 Sep 2016 07:46:35 -0700 (PDT) In-Reply-To: <20160922125145.GA30013@fieldses.org> References: <20160910200355.GA30688@fieldses.org> <20160920213931.GC12789@fieldses.org> <20160921024531.GA17232@fieldses.org> <20160921141409.GA20963@fieldses.org> <20160921195339.GC24084@fieldses.org> <20160922125145.GA30013@fieldses.org> From: David Noveck Date: Thu, 22 Sep 2016 10:46:35 -0400 Message-ID: To: "J. Bruce Fields" Content-Type: multipart/alternative; boundary=001a1134f97e8dc18f053d19bace Archived-At: Cc: "Adamson, Andy" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 14:53:30 -0000 --001a1134f97e8dc18f053d19bace Content-Type: text/plain; charset=UTF-8 > > 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. 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 could propose some language if you'd like. If you are talking about language proposing how to address the problem, you feel exists, then you could do that. However I feel it would be better if we focused first on the question of what the problem is. > 7530 requires a new verifier even in the case the callback > information isn't new. Good point but I'm unclear about whether this would count as a verifier "change". It was never clear how you would test this. Anyway, this is a case in which a new verifier is generated but the old one remains valid Whether this counts as the verifier being changed depends on how you test for verifiers being changed. On Thu, Sep 22, 2016 at 8:51 AM, J. Bruce Fields wrote: > 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. > --001a1134f97e8dc18f053d19bace Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> >= ; As it now appears that the Linux client had
> > implemented some= thing different than that, the correctness of > > the algorithm
&g= t; > in section 5.8 has to be considered an open question.

> It has the same problem;=C2=A0<= div>
Please explain what the problem is.=C2=A0 If we don't agre= e on what the problem is, it is hard to come up with a solution.

One way to do this would be to give a case where a client= =C2=A0implementing=C2=A0section=C2=A05.8 might interact with two servers an= d could arrive at the wrong result, assuming the servers meet the requireme= nts of RFC7530, which are, as you pointed out, considerably weaker than tho= se in the VS paragraph in section 5.8.

> I cou= ld propose some language if you'd like.
=C2=A0
If you are talking about language proposing how to address the problem, yo= u feel exists, then you could do that.=C2=A0 However I feel it would be bet= ter if we focused first on the question of what the problem is.

> 7530 requires a new verifier even in the case the callb= ack=C2=A0
> information= =C2=A0isn't new.=C2=A0=C2=A0

Good point = but I'm unclear about whether this would count as a verifier "chan= ge".=C2=A0 It was never clear how you=C2=A0would=C2=A0test this.=C2=A0= Anyway,=C2=A0this is a case in which a new verifier is=C2=A0generated=C2= =A0but the old one=C2=A0remains valid =C2=A0 Whether this counts as the ver= ifier being changed depends on how you test for verifiers being changed.=C2= =A0

On Thu, Sep 22, 2016 at 8:51 AM, J. Bruce Fields <= ;bfields@fieldses= .org> wrote:
On Thu, Sep 22, 2016 at 07:59:40AM -0400, David Noveck wrote:
> The question is what else, if anything needs to be fixed.=C2=A0 I had = been
> thinking that the problems you were seeing indicated that the algorith= m in
> section 5.8 needed correcting.=C2=A0 As it now appears that the Linux = client had
> implemented something different than that, the correctness of the algo= rithm
> 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 o= f the
> possibility that a new verifier will not be generated because a given<= br> > request is treated as a replay.=C2=A0 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 informati= on
isn't new.=C2=A0 ("The server treats this as a probable callback i= nformation
update and records an unconfirmed { v, x, c, k, t } and leaves the
confirmed { v, x, c, l, s } in place, such that t !=3D s.=C2=A0 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).=C2=A0 So I'm stil= l
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).=C2=A0 There's some risk to dep= ending
on behavior that implementations have never previously depended on.

--b.

--001a1134f97e8dc18f053d19bace--