headers
Jeffrey Hutzelman | 1 Oct 2009 04:31
Picon
Favicon

Re: [secdir] draft-ietf-nfsv4-federated-fs-reqts-03

--On Wednesday, September 30, 2009 02:36:20 PM -0500 Nicolas Williams 
<Nicolas.Williams <at> sun.com> wrote:

>  - A note that orphaned FSNs and FSLs cannot be easily distinguished
>    from ones referenced by junctions and FSNs, respectively.  Therefore
>    objects will tend to pile up.  This is a resource consumption
>    consideration.  Resource control issues are, IMO, a security
>    consideration.

I don't think this is a significant problem, or a security problem at all. 
The fact that, once I have allocated my resources for an object, you might 
decide to stop having any references to it, does not create a security 
problem for me.  This is analogous to my publishing a web page, and then 
you later deciding not to link to it any more.

I've lacked the time to pay any more than fleeting attention to the NFSv4 
work, but not surprisingly, the concepts mentioned here have analogues in 
AFS.  What NFS calls a "fileset" we call a "volume".  Volumes have names, 
and each AFS "cell" (collection of servers and volumes under common 
administrative control) has a database which maps volume names to 
locations.  What NFS calls a "junction" we call a "mount point", which is a 
special object in the filesystem which refers to another volume, possibly 
in another cell.

My observation over the years has been while it is possible to create mount 
points anywhere in the filesystem, referring to any volume in any cell, it 
is relatively uncommon to do so.  Most sites apply some structure to their 
filesystem namespace, such that a volume used for a particular purpose will 
have a fairly predictable name, and be referred to by a "canonical" mount 
point in a fairly predictable location.  Volume and mount point are
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Lentini | 1 Oct 2009 15:55
Picon

Re: [FedFS] meeting agenda (10/1)


On Wed, 30 Sep 2009, Nicolas Williams wrote:

> On Wed, Sep 30, 2009 at 06:19:41PM -0400, James Lentini wrote:
> > + Discuss Open Issues
> > 
> >   - Configurable NSDB port?
> > 
> >   - fedfsNfsPathname format
> > 
> >   - FSN format: <NSDB location, LDAP base DN, UUID>
> > 
> >   - NSDB location format: hostname or SRV RR?
> 
> Conveniently enough, the FSN format had better include the NSDB port #

The Admin protocol allows an optional port number to be included in 
the NSDB address.

> if SRV RRs are not in use, unless you wish to have a single alternative
> port number used throughout.  Yet another way in which SRV RRs help
> here.

We had a brief discussion about the use of non-standard LDAP ports two 
weeks ago. There was a question about how firewalls would interact 
with a non-standard port, but we didn't have time to fully discuss the 
issue then. I don't remember if anyone advocated requiring NSDBs to 
run on the standard LDAP port though.

> As a compromise, you could try SRV RR queries, then fallback on A
(Continue reading)

Permalink | Reply | 11 comments |
headers
Internet-Drafts | 1 Oct 2009 16:15
Picon
Favicon

I-D Action:draft-ietf-nfsv4-federated-fs-reqts-04.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           : Requirements for Federated File Systems
	Author(s)       : J. Lentini, et al.
	Filename        : draft-ietf-nfsv4-federated-fs-reqts-04.txt
	Pages           : 32
	Date            : 2009-10-01

This document describes and lists the functional requirements of a
federated file system and defines related terms.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

Note, that this is a requirements document, and in many instances
where these words are used in this document they refer to qualities
of a specification for a system that satisfies the document, or
requirements of a system that matches that specification.  These
cases are distinguished when there is potential for ambiguity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Lentini | 1 Oct 2009 16:23
Picon

Re: New Version Notification - draft-ietf-nfsv4-federated-fs-reqts-04.txt


On Thu, 1 Oct 2009, Internet-Draft <at> ietf.org wrote:

> New version (-04) has been submitted for draft-ietf-nfsv4-federated-fs-reqts-04.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-federated-fs-reqts-04.txt
> Sub state has been changed to AD Follow up from New Id Needed
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-federated-fs-reqts-04
> 
> IETF Secretariat.
> 

The changes in version -04 fix an idnits tool warning and include the
improvements suggested by Gen-ART's Peter McCann.

My co-authors and I are working on version -05 that will include the
improvements suggested by Nico Williams in his review for the security
directorate.

We are publishing two versions to make it easier for reviewers to
separate these changes. We expect to have the -05 version ready next
week.

-james
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nicolas Williams | 1 Oct 2009 18:05
Picon

Re: [FedFS] meeting agenda (10/1)

On Thu, Oct 01, 2009 at 09:55:42AM -0400, James Lentini wrote:
> On Wed, 30 Sep 2009, Nicolas Williams wrote:
> > if SRV RRs are not in use, unless you wish to have a single alternative
> > port number used throughout.  Yet another way in which SRV RRs help
> > here.
> 
> We had a brief discussion about the use of non-standard LDAP ports two 
> weeks ago. There was a question about how firewalls would interact 
> with a non-standard port, but we didn't have time to fully discuss the 
> issue then. I don't remember if anyone advocated requiring NSDBs to 
> run on the standard LDAP port though.

Firewalls are a relatively minor issue.  If you get a new port assigned
then it will be up to each NSDB operator to ensure that their firewalls
open that port.  Same thing if you allow configurable ports.  If
firewalls that limit the ports open for outbound connections are a
concern, then having a standard port would help.

> > As a compromise, you could try SRV RR queries, then fallback on A
> > RRsets, but I don't think that simplifies anything (it's not RRset
> > administration that's the problem -- it's the code to do SRV RR queries
> > that is).  We all already have SRV RR query code for other purposes, so
> > I say just use SRV RRs.
> > 
> > Also, see my secdir evaluation of the requirements document: you may
> > want to include optional authentication information in the FSN format:
> 
> Authentication information in the FSN format would not eliminate the 
> PKI benefits that you described in the requirements document 
> evaluation. In the event that the NSDB's or certification authority's
(Continue reading)

Permalink | Reply | 10 comments |
headers
Noveck, Dave | 1 Oct 2009 21:27
Picon

Re: sparse files support for NFS

Understood, but the working group has to decide:

1) Whether it will address sparse files in v4.2.
2) In what ways, it will address sparse files in v4.2.

I understand Nikita's message in that context.  While you have proposed
three steps, the working group needs to decide whether the first two are
worth doing if the third addresses the problem.  I'm not taking a
position here on this issue (If I did, I'd have a different one
tomorrow, and the day after that :-), but one direction the group might
take is to push content that can be done in a storage protocol into that
framework and only put things that need a base protocol change into v4.2
per se.

I think the argument can be made is that this would allow a faster rate
of innovation (assuming that's a good thing :-), via implementation of
experimental storage protocols.  This would take advantage of the work
that has been done to accommodate the very different requirements of
files, objects, and blocks.  This work has created a more modular
protocol framework and it may well be that the benefits will be similar
to that for code modularity, assuming we have created the right module
boundaries and interfaces, which does need to be shown.

-----Original Message-----
From: Marc Eshel [mailto:eshel <at> almaden.ibm.com] 
Sent: Wednesday, September 30, 2009 11:45 AM
To: Nikita Danilov
Cc: nfsv4 <at> ietf.org; Dean Hildebrand
Subject: Re: [nfsv4] sparse files support for NFS
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Lentini | 1 Oct 2009 22:00
Picon

[FedFS] Meeting Minutes, 10/01/2009


FedFS Meeting Minutes, 10/01/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul Lemahieu (EMC)
James Lentini (NetApp)
Pavan Mettu (Sun)
Rob Thurlow (Sun)

Minutes
-------

+ IETF Note Well Agreement

  This is a reminder that our discussions are governed by the 
  IETF Note Well Agreement. See:

    http://www.ietf.org/NOTEWELL.html

  We will start each week's meeting with this announcement.

+ Review Action Items

  - Rob Thurlow will consider the use of alternative LDAP ports 
    for an NSDB and report back with a recommendation to the group.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Lentini | 1 Oct 2009 23:03
Picon

Re: [FedFS] meeting agenda (10/1)


On Thu, 1 Oct 2009, Nicolas Williams wrote:

> On Thu, Oct 01, 2009 at 09:55:42AM -0400, James Lentini wrote:
> > On Wed, 30 Sep 2009, Nicolas Williams wrote:
> > > 
> > > Also, see my secdir evaluation of the requirements document: you may
> > > want to include optional authentication information in the FSN format:
> > 
> > Authentication information in the FSN format would not eliminate the 
> > PKI benefits that you described in the requirements document 
> > evaluation. In the event that the NSDB's or certification authority's 
> 
> Did you mean "would eliminate"?  

No, I did mean "would not". I was pointing out that there are benefits 
to using a PKI (e.g. for checking certificate revocation) even if the 
FSN stored authentication information.

-james
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 9 comments |
headers
Nicolas Williams | 1 Oct 2009 23:04
Picon

Re: [FedFS] meeting agenda (10/1)

On Thu, Oct 01, 2009 at 05:03:56PM -0400, James Lentini wrote:
> On Thu, 1 Oct 2009, Nicolas Williams wrote:
> > Did you mean "would eliminate"?  
> 
> No, I did mean "would not". I was pointing out that there are benefits 
> to using a PKI (e.g. for checking certificate revocation) even if the 
> FSN stored authentication information.

Most definitely.  And there are benefits to storing authentication
information (e.g., trust anchor references) even if you have a PKI,
particularly when you have many disjoint PKIs.

I highly recommend that optional authentication information be included
in the NSDB name or FSN format.

Nico
--

-- 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 8 comments |
headers
James Lentini | 2 Oct 2009 17:15
Picon

Re: [FedFS] meeting agenda (10/1)


On Thu, 1 Oct 2009, Nicolas Williams wrote:

> On Thu, Oct 01, 2009 at 05:03:56PM -0400, James Lentini wrote:
> > On Thu, 1 Oct 2009, Nicolas Williams wrote:
> > > Did you mean "would eliminate"?  
> > 
> > No, I did mean "would not". I was pointing out that there are benefits 
> > to using a PKI (e.g. for checking certificate revocation) even if the 
> > FSN stored authentication information.
> 
> Most definitely.  And there are benefits to storing authentication 
> information (e.g., trust anchor references) even if you have a PKI, 
> particularly when you have many disjoint PKIs.
> 
> I highly recommend that optional authentication information be 
> included in the NSDB name or FSN format.

Yes, a fileserver needs a trust anchor for each NSDB it wishes to 
authenticate. Embedding the mechanisms for constructing trust 
relationships in the FSN requires all FSNs with a given trust anchor 
to be invalidated should that trust anchor be compromised. Separating 
the FSNs (pointers to one or more FSLs) and the trust anchor used to 
authenticate NSDBs (the services that "resolves" the FSN pointers) 
allows the later to be revoked without invalidating the former.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 7 comments |

Gmane