Subject: Re: [nfsv4] NFS4 over VPN hangs when connecting > 2 clients
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <20120319173656.GA23670@fieldses.org>
Date: Mon, 19 Mar 2012 13:47:14 -0400
Cc: Rick Macklem <rmacklem@uoguelph.ca>, Nikolaus Rath <Nikolaus@rath.org>,
        linux-nfs@vger.kernel.org, nfsv4@ietf.org
Message-Id: <126867CF-7CAA-4E3D-A9D6-2A5FE30A7DB4@oracle.com>
References: <1085412836.1228438.1332175460830.JavaMail.root@erie.cs.uoguelph.ca> <1802632483.1230802.1332176807484.JavaMail.root@erie.cs.uoguelph.ca> <20120319173656.GA23670@fieldses.org>
To: "J. Bruce Fields" <bfields@fieldses.org>
Sender: linux-nfs-owner@vger.kernel.org


On Mar 19, 2012, at 1:36 PM, J. Bruce Fields wrote:

> On Mon, Mar 19, 2012 at 01:06:47PM -0400, Rick Macklem wrote:
>> I wrote:
>>> J. Bruce Fields wrote:
>>>> On Mon, Mar 12, 2012 at 05:27:08PM -0400, J. Bruce Fields wrote:
>>>>> On Mon, Mar 12, 2012 at 05:14:16PM -0400, Chuck Lever wrote:
>>>>>> IMO, the server should do a comparison of the nfs_client_id4
>>>>>> strings,
>>>>>> and nothing else.
>>>>> 
>>>>> We're supposed to return CLID_INUSE when we see a setclientid from
>>>>> a
>>>>> "different" client using the same string, to keep clients from
>>>>> doing
>>>>> mischief with other clients' state (either maliciously or, as in
>>>>> this
>>>>> case, accidentally).
>>>>> 
>>>>> "Different" here is defined as "not having the same principal". I
>>>>> know
>>>>> what that means in the krb5 case, but I'm less certain in the
>>>>> auth_sys
>>>>> case.
>>>> 
>>>> Cc'ing the ietf list. Is it reasonable for a server to expect
>>>> setclientid's to come from the same client IP address at least in
>>>> the
>>>> auth_sys case, or could that break multi-homed clients?
>>>> 
>>> I think that even a dhcp lease renewal might result in a different
>>> client
>>> IP, if the client has been partitioned from the dhcp server for a
>>> while.
> 
> Yeah, but by that point the client's v4 lease is probably expired anyway
> so the client's not likely to be bothered by the NFS4ERR_INUSE.
> 
>>> I'm not convinced that different client IP# implies different client.
>>> (Even "same ip# implies same client" might not be true, if the dhcp
>>> server assigned the IP# to another machine while the client was
>>> partitioned
>>> from the dhcp server, I think? I haven't looked at current dhcp
>>> implementations, but it seems conceivable to me.)
>>> 
>> Oh, and what about the case of 2 clients that are sitting behind
>> the same NAT gateway? (I think they'd both be seen as having the
>> client host ip# of the gateway, but with different TCP connections
>> on different client port#s.)
> 
> Well, sure, but all I'm proposing here is returning NFS4ERR_INUSE in the
> case where we get setclientid's with the same client-provided id.
> There'd be no change of behavior in the case of multiple clients sharing
> an IP (which is fine, of course).

The migration draft proposes that clients use the same nfs_client_id4 string for all of a server's IP addresses.  Would a server then be obliged to return NFS4ERR_CLID_IN_USE if a client attempts a SETCLIENTID with the same boot verifier and nfs_client_id4 on more than one IP address for the same server?

IMO the server should not try to sort this situation out.

>>> For AUTH_SYS, all the FreeBSD server does is expect the same uid#.
> 
> Yeah, but that's probably usually the same between clients.


-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com