[nfsv4] Potential erratta for RFC7931

David Noveck <davenoveck@gmail.com> Sat, 01 October 2016 13:02 UTC

Return-Path: <davenoveck@gmail.com>
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 DB05712B0B8 for <nfsv4@ietfa.amsl.com>; Sat, 1 Oct 2016 06:02:55 -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 SBSzOOcs6iio for <nfsv4@ietfa.amsl.com>; Sat, 1 Oct 2016 06:02:54 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 213DC12B0EE for <nfsv4@ietf.org>; Sat, 1 Oct 2016 06:02:53 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id w11so158446465oia.2 for <nfsv4@ietf.org>; Sat, 01 Oct 2016 06:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=W7c/eY88L3Y06WP4FeyYc63VyKc7dzhl7YgRVEaqC8s=; b=F90FtynGl0+cGIx1kRJluTzxewPVdajMcqBboh8khiDy3pkeh8DajN/bD5/LN1SYFs 8poYRq0r+L176A/sTlKdOm68IJC4zfOd3MTQdmHO0lXgS3yrQlTKUI9+gNJxB2Bgh3Dm Ghi2bGp0IDk3zDMfg89MWJkaAdg2ZuYlQsUtN55QRWmJ2HuvA5+6myQHdClbcmVHcICs Ul/M492RB4N76as/+ijOTGp+NcYfET7beQ9TFR70slH8XkPWYpz7eC2W6AZfXpm4wBDZ 8MGNNbfn/9GzCscWQN11IcGNQBYlm8MhcJTmRjtNUukBOiNQCYhEhRQ5FLBTBj5NeDpo MMlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=W7c/eY88L3Y06WP4FeyYc63VyKc7dzhl7YgRVEaqC8s=; b=ZA04JUIDxopnGe1HJ/u51cz6NryVJEUJeRowKBhsZRleweeFZNLzzebtPpm2vsWTNB AJu5LS7v2uOohp6LJkfneAAHz/CDKxlXYqwwbS1WMNDVKrHJ1FUh/07XlfBR+FIx7joR rZQWdQfgfu777Ps45cdoRNO4e67FxQ8yfJK7AM4/3W0RJ+AWTjOjfDM20tGAv5+FM3b6 Jum++YTmtJZIwP2AKwaZ481MkrSo/jkk85K8x+r4GgsgFu9XACe+5WERemb3BOhAixp1 vnhCrD+5MfIQkbXVZUwnrcoRI588sQfijXI4jB/Xlk/+zYKUgaKpahpjkYMhWnYlqsY4 kpZg==
X-Gm-Message-State: AA6/9RnzQqewTHuMKQSg69BfKbg+f+2v7HeCNq/CpJvFQFiZB48KQYhkGOx0VCYQcGV+CrR0haCgHrYUVyzKfw==
X-Received: by 10.202.8.143 with SMTP id 137mr10987946oii.13.1475326972483; Sat, 01 Oct 2016 06:02:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.107.77 with HTTP; Sat, 1 Oct 2016 06:02:52 -0700 (PDT)
From: David Noveck <davenoveck@gmail.com>
Date: Sat, 01 Oct 2016 09:02:52 -0400
Message-ID: <CADaq8jdc+5oLkvaxNkpxm65gH_X8+fGarZLAsq-bgGrUxSYC3A@mail.gmail.com>
To: Bruce Fields <bfields@fieldses.org>, Chuck Lever <chuck.lever@oracle.com>, Bill Baker <bill.baker@oracle.com>, Piyush Shivam <piyush.shivam@oracle.com>
Content-Type: multipart/alternative; boundary="94eb2c12f7d21f5f0f053dcd5401"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/4bz0pePmjAJw4IyJkeTBoCSETZM>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: [nfsv4] Potential erratta for RFC7931
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: Sat, 01 Oct 2016 13:02:56 -0000

Based on the recent discussion that Bruce and I had, I'm thinking of filing
an erratta, replacing the following paragraph in section 5.8:


Note that the NFSv4.0 specification requires the server to make sure
that such verifiers are very

unlikely to be regenerated.Given that it is already highly unlikely
that the clientid4 XC

is duplicated by distinct servers, the probability that SCn is
duplicated as well has to be

considered vanishingly small.  Note also that the callback update
procedure can be

repeated multiple times to reduce the probability of further spurious matches.


With the following replacement:

Although the NFSv4.0 specification requires the server to make sure that
such verifiers are very unlikely to be regenerated, different servers may
use the same approach to the construction of such verifiers, raising the
probability that two distinct servers might inadvertently assign the same
verifier value. The fact that the servers in question have assigned the
same clientid4 may raise this probability.  In order to guard against the
possibility that such assignments might cause two distinct

servers to be incorrectly considered the same, the SETCLIENTID procedure
mentioned above needs to be repeated at least once.  This will ensure that
the sucessive confirm values SCn, SCn'. SCn'' generated by these repeated
SETCLIENTID operations cannot all collide with a verifier previously
received by the client when communicating with IPn.

Comments?