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.
> >