Subject: RE: [nfsv4] re: RPCSEC_GSS Init delay

From: Mike Eisler <[email-masked]>
Date: Fri, 12 Aug 2005 02:03:44 -0700 (PDT)

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, August 11, 2005 4:59 PM
> To: [email-masked]
> Subject: [nfsv4] re: RPCSEC_GSS Init delay
> 
> 
> First, I'd like to thank everyone for their responses. I've cut good
> stuff out liberally, to keep this relatively short.
> 
> [Trond wrote]
> > Isn't there some way you can deal with these requests 
> asynchronously? In
> > Linux we can put the request on a "defer" queue if gssd 
> takes too long
> > to respond. We then replay the entire request to the nfsd 
> thread once
> > the congestion issue has been resolved.
> 
> Although interesting, I'll admit I don't see server implementation
> details as relevant. For the above, the question simply becomes:
> "How long can the server leave the request in the defer queue?".

Agreed. Once you decouple the GSS processing from the kernel, and/or
deal with a GSS mechanism that requires calls to outside services something
can fail. While working hard to avoid returning an error is
goodness, returning an error is sometimes necessary.
It seems to me the GSS_S_FAILURE is the right error: "GSS_S_FAILURE indicates that context setup
could not be
   accomplished for reasons unspecified at the GSS-API level, and that
   no interface-defined recovery action is available.
"

> 
> >> Again, I'd like to hear what the client guys think of a disconnect.
> [Robert wrote]
> > Ouch! -- I think just dropping the clients RPCSEC_GSS Init request
> > to allow it an opportunity to resend would be appropriate.
> 
> Further to this, I will note that RFC3530 Sec. 3.1.1 appears to exempt
> NULL from the "must retry after disconnect/reconnect", so it is not
> really clear that a TCP disconnect will get a client to try 
> an RPCSEC_GSS
> Init again?

Actually, in NFSv4, there is no requirement for a client to retry any
procedure, NULL, RPCSEC_GSS INIT, or COMPOUND (mount soft, and that's
what you get). The idea of requiring a
a TCP disconnect whenever the server needs to drop a request is to
signal to the client that request may not have been delivered, so if he
wants it delivered (has mounted hard), retry. Hence if the client 
wants to establish a GSS context, it needs to retry. 

I was thinking that a creative interpretation would be that since
NULLs can be retried without the client breaking the connection,
the server would be free to drop NULLs without breaking the connection,
but that completely defeats the purpose of using NULLs to probe a
connection for vitality. So dropping  INITs without an error or a disconnect
in NFSv4 is just wrong. If we ever wanted to revise RFC2203, we'd add
an equivalent to NFS4ERR_DELAY.

> [Mike wrote]
> > 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.
> 
> This sounds interesting, but if the client specified
> GSS_C_MUTUAL_FLAG when it did gss_init_sec_context(), I 
> thought the server is
> expected to return a token with the successful Init reply. (I 

Yeah that's probably not going to work.

> have assumed that
> the server needs a session key etc to make that token, but 
> I've never delved 
> into gss that deeply.) I notice that RFC2203
> seems to be silent on whether or not GSS_C_MUTUAL_FLAG should be used?

Yes it is silent. I'm not sure that was an oversight. The Solaris API to RPCSEC_GSS
allows one to not specify _MUTUAL (it also appears to allow one to set
GSS_C_REPLAY_FLAG and/or GSS_C_SEQUENCE_FLAG which is contrary to RFC2203, so that's
a bug, at least it is in Solaris 8 based on the tirpc99 source code). 

Not setting _MUTUAL seems OK since RPCSEC_GSS has to verify the MIC of the
sequence number in RPC responses, so that lets the client authenticate the server.

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