Subject: [nfsv4] re: RPCSEC_GSS Init delay

From: [email-masked]
Date: Thu, 11 Aug 2005 19:58:48 -0400 (EDT)

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?".

>> 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?

[Robert wrote]
> The Solaris client currently waits 30 seconds for a reply.

If others are similar, it sounds like 30-60sec is about as long as the
server should wait. Does the client retry after 30sec or give up and
consider it an error?

[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 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?
(My gssd currently does specify it for the Initiator side.)

rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 11 Aug 2005 20:47:49 -0400

> "How long can the server leave the request in the defer queue?".

...which is an easier question to answer.

If the client disconnects, then the request may be dropped. If it
doesn't, then the server is _required_ to answer according to RFC3530.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Aug 2005 02:15:30 -0500

> server should wait. Does the client retry after 30sec or give up and

Regardless of what clients do, there should be a recommendation.

Clearly at least one server implementation needs to drop some RPCSEC_GSS
GSS context token exchanges on the floor and the question is how should
the server tell the client such that the client doesn't give up.

At a glance neither RFC2203 nor RFC3530 recommend any particular thing
the server could do, nor is there any recommendation or requirement for
the client.

What the Solaris client does now seems bad to me -- I've filed a bug.

I think we could agree that some GSS security context establishment
errors (IMO GSS_S_DEFECTIVE_TOKEN) SHOULD lead to the client re-trying
-- but how many times should the client re-try, and what, with some
backoff?

> This sounds interesting, but if the client specified

But it won't do if the client had last gotten GSS_S_CONTINUE_NEEDED from
GSS_Init_sec_context() and it's smart enough to check.

(GSS_C_MUTUAL_FLAG informs whether that might be the case for the krb5
mech, but more generally that's not the only case where it might
happen.)

> (My gssd currently does specify it for the Initiator side.)

RFC2203 shouldn't have to say -- that's up to the application, NFSv4 in
this case, and RFC3530 doesn't really say either (it does, when
discussing the callback channel, but let's not go there right now).

In general I'd prefer that NFSv4 REQUIRE that GSS_C_MUTUAL_FLAG be used,
even for SPKM-3 (there using GSS_C_NT_ANONYMOUS for the initiator
principal name).

Cheers,

Nico
--