Subject: Re: [nfsv4] more re: RPCSEC_GSS Init delay

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

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 10:07 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [nfsv4] more re: RPCSEC_GSS Init delay
> 
> 
> On Thu, Aug 11, 2005 at 12:53:02PM -0400, 
> [email-masked] wrote:
> > > It might be best to drop the request (and disconnect), or 
> queue it, and
> > > retry to gssd.
> > 
> > Again, I'd like to hear what the client guys think of a disconnect.
> 
> Never mind what the client guys think -- if you have a connection with
> many live contexts being used then disconnecting upon time out in
> establishing a new context will be very painful, first for the client,
> then for the server when the client returns to re-establish the
> connection, the contexts, state... and in so doing 
> exacerbates the gssd
> timeout problem, leading to a vicious cycle of pain.

As a digression, are there NFS servers that drop established contexts 
as a consequence of dropping TCP connections? TCP connection drop 
should have nothing to do with GSS context drop. Of course, the CCM 
GSS mechanism would change this (but CCM-MIC mitigates 
the cost of dropping a CCM context).

> > (As for retrying the upcall, it actually was happenning, 
> but my server
> >  nfsd threads were giving up after 10sec. I increased that 
> to 1 minute
> >  and it resolved the case I was testing. What I'm not sure about is
> >  "how long" I can delay replying to the client before I'm stuck with
> >  the choice of "failed authentication" vs "disconnect".)
> 
> Try not timing out on upcalls to gssd.  If gssd dies, then return some
> generic GSS error (e.g., GSS_S_DEFECTIVE_TOKEN) and let the client
> retry.

So the Solaris 10 client will retry on a _DEFECTIVE_TOKEN error?

Another scheme that occurs to me is for the server to positively
ack the GSS INIT, and then on the subsequent use of the RPCSEC_GSS
handle (server can reserve a special handle value
for this purpose), return a CONTEXT_EXPIRED error. Beats breaking a TCP
connection or hoping the client will retry GSS_INIT on a GSS error.

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

---

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

> So the Solaris 10 client will retry on a _DEFECTIVE_TOKEN error?

No, but I'm thinking it should.  Further, I'm thinking that retrying on
that major status code should be recommended.

> connection or hoping the client will retry GSS_INIT on a GSS error.

But, how can it?  If gssd is taking too long to produce a context token
then the ACK will not have one while the client is expecting one.

Nico
--