Subject: RE: [nfsv4] RPCSEC_GSS time limit

From: Mike Eisler <[email-masked]>
Date: Thu, 11 Aug 2005 09:27:53 -0700 (PDT)

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 7:27 AM
> To: [email-masked]
> Subject: [nfsv4] RPCSEC_GSS time limit
> 
> 
> I've run into a little problem here, where when the server is 
> under heavy
> load, the gssd respond too slowly, such that the kernel nfsd 
> threads time
> out and reply an authentication error.
> 
> Since for an RPCSEC_GSS Init (in an NFS Null RPC), it doesn't 
> seem appropriate
> to return NFS4ERR_DELAY, I was wondering what others thought 
> would be a
> reasonable upper bound on server response time to the request. (Or is
> returning NFS4ERR_DELAY appropriate for this case?)

NFS4ERR_DELAY isn't appropriate ... you would be returning that error
in an overloead NULL procedure which has no place for for a program
specific error code, nor does the response to the RPCSEC_GSS Init have
a place.

You could conceivably come up with an appropriate GSS error to return
(GSS_S_CONTEXT_EXPIRED ?), but I don't know that RPCSEC_GSS clients will
interpret that as _DELAY.

It might be best to drop the request (and disconnect), or queue it, and
retry to gssd.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:17:14 -0500

> It might be best to drop the request (and disconnect), or queue it, and

You can't re-queue and retry gssd on the server side -- gssd may take it
as a replay, for example.

Nico
--

---

From: Mike Eisler <[email-masked]>
Date: Thu, 11 Aug 2005 10:40:11 -0700 (PDT)

> as a replay, for example.

Then the gssd client and the gssd server are broken.

If gssd is using ONC RPC then it can use the duplicate request cache.
If that isn't sufficient for some reason, the gssd protocol
can implement exact once semantics, such as by borrowing from what the
NFSv4.1 sessions proposal has. 

Besides which, replay caches for init tokens in the underlying GSS mechanism (Kerberos V5 for
example) are a crock. RPCSEC_GSS doesn't need 'em, and gssd should turn 'em
off.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:50:26 -0500

> Then the gssd client and the gssd server are broken.

gssd could keep enough state that it could handle replays; an
implementation detail.

> If gssd is using ONC RPC then it can use the duplicate request cache.

Then again, it could be using some other IPC.

> example) are a crock. RPCSEC_GSS doesn't need 'em, and gssd should turn 'em

Agreed, but think of other mechanisms, say ones that require multiple
round-trips.  The kernel<->gssd interface may allow for replays if gssd
can keep the necessary state.  The mechanisms can't generally do so.

Nico
--