From: cburnett@us.ibm.com
Date: 07/18/02-02:01:07 PM Z
From: cburnett@us.ibm.com
Subject: Re: more on CLID_INUSE for setclientid
Message-ID: <OF1D80AFDB.4BA3CEA9-ON85256BFA.006686CF@us.ibm.com>
Date: Thu, 18 Jul 2002 14:01:07 -0500
Here are some thoughts based on experience with DFS which has a
similar concept of client/server context establishment for state management.
The callback information should be thought of as an attribute of the
client, not part of its unique signature. The unique signature should best
be limited to the nfs_client_id4 information (verifier and id). This is
to allow implementations that support clients with multiple n/w interfaces.
We used to call this multi-homed in DFS speak. The DFS server recognizes and
tracks all the address information for a given clientID. If a server callback
fails over a given callback path, then the alternate paths are tried. With
this level of support, a customer can deploy redundant network paths between
server and client for increased resistance to failure. The client signature
in DFS is a 128 bit value that is guaranteed (or at least trusted) to be
unique across the client space (its actually DCE uuid). When a client
contacts the server with a clientID that is already at the server,
the server does a sanity check on the caller's authentication before
absorbing callback information that differs from what the server
already knows about. The network path is independent of the state management.
So I would suggest that implementations not treat the callback info
or the calling client's authentication as part of the client unique signature.
Instead these are attributes of the client. Saving and using the RPC
authentication information (auth flavor, sec mechanism, principal) seems like
a good way to further verify that the calling client is the right one. This
assumes the client would use the same authentication for all of its
SETCLIENTID calls during a given instantiation
I would think the nfs_client_id4 space (8 bytes of verifier + 1024 bytes of
id) should be sufficient for implementations to create unique client
signatures. If a client (through administration) is configured to use
strong authentication like Kerberos with a client unique principal then there
is a high guarantee against impersonation of a client id by another system.
For such a client, if it gets back a NFS4ERR_CLID_INUSE, it can try generating
a new nfs_client_id4 with any associated recovery that might be needed.
If one is willing to augment the NFS protocol structures a little, some
improvement could perhaps be achieved. The SETCLIENTID4args could have
a new clientid4 member added. When a client issues a new SETCLIENTID call
for a server, it sends a clientid4 value of 0 indicating it does not yet
have a server assigned client id. This tells the server to
return NFS4ERR_CLID_INUSE if the client signiture (nfs_client_id4) already
exists. Once the intitial context is establised, the client provides its
server assigned id in subsequent SETCLIENTID calls if it is providing
another callback path. When the server sees this call for an existing
client signiture with the server assigned clientid4 provided, it knows that
the existing client is providing addtional information for the server to
use.
Anyway, just thought I would pass this past knowledge on for the group to
consider. I will also mention that this "multi-home" capability was added
to DFS from direct customer driven requests. So I think it is an important
availability feature.
BTW: I think there might be in inconsistency in the latest draft on the
nfs_client_id definition between section 8.1.1 and other parts of the
draft. In 8.1.1, its defined as:
struct nfs_client_id {
opaque verifier[4];
opaque id<>;
}
However in section 2.2 its:
struct nfs_client_id4 {
verifier4 verifier;
opaque id<NFS4_OPAQUE_LIMIT>;
};
I am guessing section 8.1.1 should be changed to match the 2.2 definition.
Carl
Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)
rick@snowhite.cis.
uoguelph.ca To: nfsv4-wg@sunroof.eng.
Sent by: owner-nfsv4- sun.com
wg@sunroof.eng.sun.com cc:
Subject: more on CLID_INUSE for
setclientid
07/15/2002 04:58 PM
Well, the more I think about it the more I go around in circles. (I
basically
agree with Dave that the clients really need to try to get nfs_client_id4.
id
unique.)
Here's how it seems to me...
- If two clients do end up with the same nfs_client_id4.id, they can play
a really nasty game of music chairs. One does setclientid, then the other
does setclientid, replacing the clientid on the server. The first one's
setclientid_confirm fails, it does setclientid again, replacing the
second's
clientid, and so on, and so on.
The only thing that stops this is the server replying with the CLID_INUSE
error.
So, the only really safe thing for the server to do is to reply CLID_INUSE
whenever the same nfs_client_id4.id as a current one shows up, BUT...
--> then clients get CLID_INUSE after a reboot or retransmit of a
setclientid
op rpc and the server can't throw away the old clientid state until the
lease is up.
Again, similar to what Dave said, I can't see a good solution to this.
I think, for now, my code is going to paranoid and reply CLID_INUSE unless
all of, the same principal/user, callback address and return IP# are the
same as what was given in the setclientid request that allocated the
clientid.
(This way, the verifier still does tell the server about a client reboot/
retransmit, but minimizes the chance of "musical chairs" if two clients
do somehow get the same nfs_client_id4.id.)
This does imply that clients that change their IP# won't be recognized as
rebooted (which means their old state will hang around unless the lease is
up) and that multiple clients on the same machine will have to be careful
about creating a unique id, but??
Just my thoughts, rick
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:59 AM Z CST