headers
William A.(Andy) Adamson | 2 May 2005 23:08
Picon
Favicon

rfc2025 (SPKM) and Version 3 X.509

Hello

Appendix B of rfc2025 states

   This appendix contains, for completeness, the relevant ASN.1 types
   imported from InformationFramework (1993), AuthenticationFramework
   (1993), and [PKCS3].

e.g. use these versions of the InformationFramework and 
AuthenticationFramework asn1 types. this means that SPKM uses only version 1 
or version 2 x.509 certificates - which do not contain any extensions. this is 
problematic - everyone uses vesion 3 x.509 certs - (UMICH, the Grid...)

what, if anything, needs to officially be done to allow SPKM to use version 3 
certificates?

thanks

-->Andy

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 1 comment |
headers
Nicolas Williams | 2 May 2005 23:30
Picon

Re: rfc2025 (SPKM) and Version 3 X.509

On Mon, May 02, 2005 at 05:08:49PM -0400, William A.(Andy) Adamson wrote:
> Hello
> 
> Appendix B of rfc2025 states
> 
>    This appendix contains, for completeness, the relevant ASN.1 types
>    imported from InformationFramework (1993), AuthenticationFramework
>    (1993), and [PKCS3].
> 
> e.g. use these versions of the InformationFramework and 
> AuthenticationFramework asn1 types. this means that SPKM uses only version 1 
> or version 2 x.509 certificates - which do not contain any extensions. this is 
> problematic - everyone uses vesion 3 x.509 certs - (UMICH, the Grid...)
> 
> what, if anything, needs to officially be done to allow SPKM to use version 3 
> certificates?

Deprecate SPKM and replace it with a new mechanism based on DTLS :)

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Khan, Saadia | 3 May 2005 20:28
Picon

Returning NFS4ERR_CB_PATH_DOWN


This is what the spec has to say about NFS4ERR_CB_PATH_DOWN:

   When the client holds delegations, it needs to use RENEW to detect
   when the server has determined that the callback path is down.  When
   the server has made such a determination, only the RENEW operation
   will renew the lease on delegations.  If the server determines the
   callback path is down, it returns NFS4ERR_CB_PATH_DOWN.  Even though
   it returns NFS4ERR_CB_PATH_DOWN, the server MUST renew the lease on
   the record locks and share reservations that the client has
   established on the server.  If for some reason the lock and share
   reservation lease cannot be renewed, then the server MUST return an
   error other than NFS4ERR_CB_PATH_DOWN, even if the callback path is
   also down.

and the more confusing part is:

This difficulty is solved by the following rules:

   o  When the callback path is down, the server MUST NOT revoke the
      delegation if one of the following occurs:

      -  The client has issued a RENEW operation and the server has
         returned an NFS4ERR_CB_PATH_DOWN error.  The server MUST renew
         the lease for any record locks and share reservations the
         client has that the server has known about (as opposed to those
         locks and share reservations the client has established but not
         yet sent to the server, due to the delegation).  The server
         SHOULD give the client a reasonable time to return its
         delegations to the server before revoking the client's
(Continue reading)

Permalink | Reply | 3 comments |
headers
J. Bruce Fields | 3 May 2005 21:12

Re: Returning NFS4ERR_CB_PATH_DOWN

On Tue, May 03, 2005 at 11:28:42AM -0700, Khan, Saadia wrote:
> so it seems like just because the callback path is down, the server
> should not revoke delegations, so in case the server finds out that
> the callback path is down because it is in the middle of recalling the
> delegation, it probably needs to wait for a renew from that client so
> that it can send it NFS4ERR_CB_PATH_DOWN and then wait for atleast one
> lease period before revoking the delegation. 

That's how I read it.  With one exception: the "at least one lease
period" requirement is only for the length of time the server has to
wait for the client to send the renew that the server replies
CB_PATH_DOWN to:

>	The server SHOULD give the client a reasonable time to return
>	its delegations to the server before revoking the client's
>	delegations.

Once it's gotten the chance to return CB_PATH_DOWN, the time to wait is
just described as "a reasonable period":

>       -  The client has not issued a RENEW operation for some period of
>          time after the server attempted to recall the delegation.  This
>          period of time MUST NOT be less than the value of the
>          lease_time attribute.

> Are there other server implementations which have implemented this
> approach

Linux returns CB_PATH_DOWN, but in some situations I think it may not
wait the correct amount of time before returning the delegation--but
(Continue reading)

Permalink | Reply | 1 comment |
headers
rick | 3 May 2005 21:39
Picon

re: delegation recall with CB path down

> so it seems like just because the callback path is down, the server
> should not
> revoke delegations, so in case the server finds out that the callback
> path is down because it is in the middle of recalling the delegation, it
> probably needs to wait for 
> a renew from that client so that it can send it NFS4ERR_CB_PATH_DOWN and
> then 
> wait for atleast one lease period before revoking the delegation. 
> 
> Does this seem like the right approach? Are there other server
> implementations which have implemented this approach and do current
> clients correctly handle this error case?

This is essentially what my server does. After issuing the Recall, it
sets a timeout of "2 * lease + delta" before revocation, if the recall
failed. Since the failed recall will have marked the callback path down,
it will reply NFS4ERR_CB_PATH_DOWN to any Renew during that time.
--> The client should have somewhat more than one lease duration after
    receiving the NFS4ERR_CB_PATH_DOWN to return outstanding delegations.

I've attached my code, in case the comments are of interest to anyone, rick
--- bsd delegation recall code ---
	/*
	 * If the conflict is with an old delegation...
	 */
	if (stp->ls_flags & NFSLCK_OLDDELEG) {
		/*
		 * You can delete it, if it has expired.
		 */
		if (clp->lc_delegtime < NFSD_MONOSEC) {
(Continue reading)

Permalink | Reply | 9 comments |
headers
Spencer Shepler | 4 May 2005 00:58
Picon

Re: Returning NFS4ERR_CB_PATH_DOWN

On Tue, Khan, Saadia wrote:

<...>

> 
> 
> so it seems like just because the callback path is down, the server
> should not
> revoke delegations, so in case the server finds out that the callback
> path is down because it is in the middle of recalling the delegation, it
> probably needs to wait for 
> a renew from that client so that it can send it NFS4ERR_CB_PATH_DOWN and
> then 
> wait for atleast one lease period before revoking the delegation. 
> 
> Does this seem like the right approach? Are there other server
> implementations which have implemented this approach and do current
> clients correctly handle this error case?

Yes, this is appropriate.

The Solaris client, upon receipt of NFS4ERR_CB_PATH_DOWN, will return
all of its delegations.

The Solaris server will do the CB_PATH_DOWN notification but there may
be one bug lurking in there someplace.

I will take the opportunity to close a thread of discussion we had
awhile back that is similar to this.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Shepler | 4 May 2005 00:59
Picon

Re: Returning NFS4ERR_CB_PATH_DOWN

On Tue, J. Bruce Fields wrote:
> On Tue, May 03, 2005 at 11:28:42AM -0700, Khan, Saadia wrote:
> > so it seems like just because the callback path is down, the server
> > should not revoke delegations, so in case the server finds out that
> > the callback path is down because it is in the middle of recalling the
> > delegation, it probably needs to wait for a renew from that client so
> > that it can send it NFS4ERR_CB_PATH_DOWN and then wait for atleast one
> > lease period before revoking the delegation. 
> 
> That's how I read it.  With one exception: the "at least one lease
> period" requirement is only for the length of time the server has to
> wait for the client to send the renew that the server replies
> CB_PATH_DOWN to:
> 
> >	The server SHOULD give the client a reasonable time to return
> >	its delegations to the server before revoking the client's
> >	delegations.
> 
> Once it's gotten the chance to return CB_PATH_DOWN, the time to wait is
> just described as "a reasonable period":

I agree.  The server can extend the period if it observes the client
making a reasonable effort to return delegations (just as it would if
a CB_RECALL has been serviced and there are WRITEs being done for the
file).

Spencer

_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 6 May 2005 21:44
Picon
Favicon

I-D ACTION:draft-ietf-nfsv4-rfc1832bis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title		: XDR: External Data Representation Standard
	Author(s)	: M. Eisler
	Filename	: draft-ietf-nfsv4-rfc1832bis-06.txt
	Pages		: 26
	Date		: 2005-5-6
	
This document describes the External Data Representation Standard
   (XDR) protocol as it is currently deployed and accepted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc1832bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nfsv4-rfc1832bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Eisler | 6 May 2005 22:14

RE: I-D ACTION:draft-ietf-nfsv4-rfc1832bis-06.txt

> From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org] 
[...]
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Network File System Version 
> 4 Working Group of the IETF.
> 
> 	Title		: XDR: External Data Representation Standard
> 	Author(s)	: M. Eisler
> 	Filename	: draft-ietf-nfsv4-rfc1832bis-06.txt
> 	Pages		: 26
> 	Date		: 2005-5-6
> 	
> This document describes the External Data Representation Standard
>    (XDR) protocol as it is currently deployed and accepted.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc1832bis-06.txt

That was fast. This revision is the result of Area
Director review. The feedback was to put real content
into the Security Considerations section.

If you want to see a version with change bars 
relative to -05, see:

  http://www.eisler.com/nfsv4-wg/draft-ietf-nfsv4-rfc1832bis-06.cb

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Spencer Shepler | 13 May 2005 04:14
Picon

errata: sequence id handling with NFS4ERR_OLD_STATEID


In section 8.1.5, we have the following:

   The client MUST monotonically increment the sequence number for the
   CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE
   operations.  This is true even in the event that the previous
   operation that used the sequence number received an error.  The only
   exception to this rule is if the previous operation received one of
   the following errors: NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID,
   NFS4ERR_BAD_STATEID, NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR,
   NFS4ERR_RESOURCE, NFS4ERR_NOFILEHANDLE.

It appears that NFS4ERR_OLD_STATEID is missing from the list of errors
that do not increment the sequence id.

Any objections to that interpretation?

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |

Gmane