stacey_chris | 2 Dec 03:56 2009

Standardized NFSv4 statistics reporting

A few weeks ago a discussion in the FedFS working group about troubleshoot tools led to a discussion about statistics reporting for NFS file servers in general.

 

The basic observation is that every file server implementation maintains statistics about its activity – operations/second, per operation stats, error counters, etc. and anyone trying to troubleshoot or even just understand what is going on a file server, or group of file servers, is going to be interested in extracting the statistics from a server.   Today there is no standard or even just commonly agreed way to get stats out of an NFS server.  Each vendor’s implementation exposes the statistics it maintains in a different way.    In a world where I have file servers from only one vendor that is not so difficult to live with.   However, life is much harder for anyone wanting to develop an NFSv4 service health checking / monitoring tool that is supposed to work against any NFSv4 file server.  Such a tool would have to implement a separate statistics extraction mechanism for each different server implementation.    This is aggravated by FedFS as it facilitates multiple file servers from multiple vendors participating in providing the access to one or more namespaces.

 

This leads to the observation that file service monitoring and troubleshooting would be made much easier if there was a standardized, or even just commonly agreed, way of extracting the statistics that each file server implementation maintains from each file server rather than each different implementation being different.

 

Although this discussion started in the federated file system context we came to the conclusion that this applies to file services in general (and beyond but that is as far as this working group’s remit extends).    It was also noted that there had in the past been some discussion with this group about the idea of exposing information via SNMP, but that conversation had not gone anywhere.

 

SMI-S also comes to mind as a possible way to standardize the exposure of statistics from a file server.   Unfortunately, I don’t know enough about the current state of the NAS SMI-S profile to be able to comment on it.

 

Rather than diving straight into detailed proposals about what statistics should be maintained and exactly how they might be exposed (SNMP, SMI-S, new NFSv4 calls, etc.), I thought it worth seeing if the group felt this was an area that we want to get involved with.   Do we?  

 

If so, what is the most appropriate vehicle?  Options could include:

  * statistics maintenance and exposure with the NFSv4 protocol itself;

  * defining an SNMP MIB that all NFSv4 implementations should implement (I believe NetApp already have one that covers NFS – maybe we could use that as a starting point);  

  * input into the NAS profile within SMI-S (I am hoping someone some one can provide more insight into the state of that);

  * others?

 

Thoughts?

 

Thanks,

Chris

 

--
Chris Stacey - Senior Technologist, Unified Storage Engineering, EMC Corporation (New Zealand).  Phone: +64 21 225 3747

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Yoder, Alan | 2 Dec 10:21 2009
Picon

Re: Standardized NFSv4 statistics reporting

There is a Filesystem Performance profile in SMI-S.  I'm not sure whether any client-side implementations use it. FWIW, EMC drove the development of the profile.  ;-)  Mike Thompson is the EMC contact.

Given this group's affiliation with IETF, however, it seems like the more natural move would be a standard MIB.  I think I can speak for NetApp in saying that starting with whatever's in our MIB will work for us.  

Alan

Alan G. Yoder, MSEE, Ph.D.
Office of the CTO, NetApp
Chair, SNIA Technical Council
Secretary, SNIA Green Storage Initiative
agy <at> netapp.com
408 747 1419
650 814 6498




On 12/1/09 6:56 PM, "stacey_chris <at> emc.com" <stacey_chris <at> emc.com> wrote:

A few weeks ago a discussion in the FedFS working group about troubleshoot tools led to a discussion about statistics reporting for NFS file servers in general.
 
The basic observation is that every file server implementation maintains statistics about its activity – operations/second, per operation stats, error counters, etc. and anyone trying to troubleshoot or even just understand what is going on a file server, or group of file servers, is going to be interested in extracting the statistics from a server.   Today there is no standard or even just commonly agreed way to get stats out of an NFS server.  Each vendor’s implementation exposes the statistics it maintains in a different way.    In a world where I have file servers from only one vendor that is not so difficult to live with.  However, life is much harder for anyone wanting to develop an NFSv4 service health checking / monitoring tool that is supposed to work against any NFSv4 file server.  Such a tool would have to implement a separate statistics extraction mechanism for each different server implementation.   This is aggravated by FedFS as it facilitates multiple file servers from multiple vendors participating in providing the access to one or more namespaces.
 
This leads to the observation that file service monitoring and troubleshooting would be made much easier if there was a standardized, or even just commonly agreed, way of extracting the statistics that each file server implementation maintains from each file server rather than each different implementation being different.
 
Although this discussion started in the federated file system context we came to the conclusion that this applies to file services in general (and beyond but that is as far as this working group’s remit extends).    It was also noted that there had in the past been some discussion with this group about the idea of exposing information via SNMP, but that conversation had not gone anywhere.
 
SMI-S also comes to mind as a possible way to standardize the exposure of statistics from a file server.   Unfortunately, I don’t know enough about the current state of the NAS SMI-S profile to be able to comment on it.
 
Rather than diving straight into detailed proposals about what statistics should be maintained and exactly how they might be exposed (SNMP, SMI-S, new NFSv4 calls, etc.), I thought it worth seeing if the group felt this was an area that we want to get involved with.   Do we?   
 
If so, what is the most appropriate vehicle?  Options could include:
  * statistics maintenance and exposure with the NFSv4 protocol itself;
  * defining an SNMP MIB that all NFSv4 implementations should implement (I believe NetApp already have one that covers NFS – maybe we could use that as a starting point);  
  * input into the NAS profile within SMI-S (I am hoping someone some one can provide more insight into the state of that);
  * others?
 
Thoughts?
 
Thanks,
Chris
 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
James Lentini | 2 Dec 20:19 2009
Picon

[FedFS] meeting agenda (12/3)


Tomorrow's proposed agenda is below. Please let me know if you would
like to add additional topics.

    Time: Thursdays 1:30-2:30 PM EST/10:30-11:30 AM PST
 Dial-in: 1-888-765-3653 (us)
          303-218-2659 (international)
      Id: 2354843

Proposed Agenda
---------------

+ 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

  - Chris Stacey will writeup a description of an SNMP MIB.

+ Mailing List Questions

  http://www.ietf.org/mail-archive/web/nfsv4/current/msg07562.html

  - Client Processing of an NFS SRV RR 
    (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)

  - NFS URL

+ Admin NSDB Trust Anchor Management

  Does the Admin protocol or fileserver determine if NSDB connections 
  are authenticated?
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

James Lentini | 3 Dec 21:54 2009
Picon

[FedFS] Meeting Minutes, 12/03/2009


FedFS Meeting Minutes, 12/03/2009
---------------------------------

Attendees
---------

Craig Everhart (NetApp)
Sorin Faibish (EMC)
Paul LeMahieu (EMC)
James Lentini (NetApp)
Trond Myklebust (NetApp)
Chris Stacey (EMC)

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

  - Chris Stacey will writeup a description of an SNMP MIB.

    Complete.

    Chris summarized our discussions over that past few weeks in an 
    email to the list. Chris summarized the genesis of the idea 
    standardizing statistics, asked if this was within the scope 
    of the NFSv4 WG, and asked for feedback on how to approach the 
    problem.

    Chris is going to chat with his colleagues about SMI-S. Sorin 
    is going to investigate the SNMP MIB.

+ Mailing List Questions

  We discussed Paul's mailing list questions.

  - NFS URL

    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL 
    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS. 

    This was not the type of NFS URL Paul was asking about.

    Trond noted the NFSv4 has a public filehandle concept, but the 
    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is 
    different from WebNFS.

    We discussed the difference between a fileserver's namespace and a 
    federated namespace. An NFSv4 fileserver has a / pseudo root directory.  
    Such a fileserver may also host the root of a federated namespace. For 
    example, the federated namespace root for example.net would be located at 
    /.domain-root-example.net on an NFSv4 fileserver. 

    A fileserver's pseudo root and federated namespace root are intentionally 
    different. This allows for greater flexibility. A single server can be 
    the root of multiple namespaces, contain other directories, etc. 

    A junction may be present at any point beneath the federated root and 
    point to an arbitrary location (the target of a junction does not need 
    to be beneath /.domain-root-example.net).

  - Client Processing of an NFS SRV RR 
    (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)

    To mount a federated namespace, say example.net's namespace, the NFS client 
    will look up the NFS SRV record at_nfs4._write._domainroot._tcp.example.net
    in DNS (assuming the client wants a read/write view of the namespace).
    The SRV record will have one or more host names implementing the service
    (e.g. nfs1tr.example.net).

    The NFS client will then mount nfs1tr.example.net://.domain-root-example.net 
    at /nfs4/example.net in the client's local namespace.

    Craig noted that there were two ways of naming a particular point. 
    There is the traditional way, server://path/to/file, and a new 
    SRV based name, roughly <domain> + <federated namespace path>.

    Paul speculated that the behavior of the OS mount command could be updated
    to incorporate the federated naming. In particular, he wondered if the 
    mount command would take a domain and mount the domain's federated root. 

    We noted that an OS mount command could be augmented to include the 
    process of (1) mapping from a domain to an SRV query string, 
    (2) performing the SRV query and extracting the host fileservers running 
    the service, and (3) mounting the fileserver + ".domain-root-≤domain>" 
    path. Another option would be to perform steps (1) and (2) separately 
    and then input the result into the standard mount command.

+ Admin NSDB Trust Anchor Management

  We briefly reviewed the mechanisms by which LDAP can be secured. LDAP 
  connections can be secured using TLC or SASL. [Editor's note see RFC4513].

  We discussed the following question who or what determines if a fileserver's
  NSDB connections are secure. We asked if the ONC RPC Administrative protocol 
  should indicate, possibly at junction create time, the desired security 
  properties to use for an FSN's resolution.

  There are at least three different ways the security properties of an NSDB 
  connection could be derived: (1) each implementation could have its own 
  policy and settings, (2) the ONC RPC Admin protocol could indicate the 
  desired security mechanism, or (3) the NSDB could require a particular 
  security mechanism.

  We reviewed some of the advantages and disadvantages of these options.

  Trond asked if there was a standard way for LDAP to indicate the required 
  level of security. If so, it could be used as an auto configuration 
  mechanism. James noted that there are ways for a user to indicate to 
  an LDAP client that a security mechanism should be used (ldap:// versus
  ldaps:// to request standard versus SSL/TLS connections respectively or 
  the various SASL configuration settings). James was not aware of any 
  way to automatically determine if an LDAP directory should be contacted 
  via TLS, SASL, etc. 

  [AI] James Lentini will investigate if an LDAP client can automatically 
       determine the security properties of an LDAP directory.

  James suggested that it could be dangerous for a fileserver to depend 
  totally on an NSDB for indicating the security mechanism for an LDAP 
  connection. For example, a impostor might setup a rogue NSDB that 
  indicated no security was necessary (and hence the NSDB did not need to 
  be authenticated).

  We discussed the security properties desired for an NSDB connection.
  If security is a concern, the fileserver will want to authenticate the 
  identity of the NSDB and have protect the integrity of the LDAP connection. 
  Privacy did not stand out as a concern on the call. [editor's note: while 
  writing up these notes, I realized that privacy is also desirable. The 
  contents of an FSL, for example the path name, may convey information 
  that the federation members which to keep private].

  James suggested that the fileserver administrator would have a 
  vested interest in ensuring that the fileserver's referrals were 
  valid. Therefore, the administrator will want the ability to 
  configure the security properties used to resolve an FSN.

  Trond pointed out that the fileserver must be able to query the NSDB 
  over a long period of time. This leads inevitably to the topic of 
  key/certificate management.

  [time - we plan to continue discussing this topic on the WG email 
   list and at next week's meeting]
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Nicolas Williams | 3 Dec 22:12 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009

On Thu, Dec 03, 2009 at 03:54:30PM -0500, James Lentini wrote:
>   - NFS URL

This seems good to me:

	fednfs://<domain>/<path>

For all other paths use nfs://<server>/<path> (RFC2224), or change the
scheme to "nfs4".

See below.

>   - Client Processing of an NFS SRV RR 
>     (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)
> 
>     [...]
> 
>     Craig noted that there were two ways of naming a particular point. 
>     There is the traditional way, server://path/to/file, and a new 
>     SRV based name, roughly <domain> + <federated namespace path>.

Yes.

>     Paul speculated that the behavior of the OS mount command could be updated
>     to incorporate the federated naming. In particular, he wondered if the 
>     mount command would take a domain and mount the domain's federated root. 

The distinction between "server:/path" and "domain:/path" is very
important.  It must be made.  It must be made in URLs, and it must be
made in mount command arguments, and in automount maps, and GUIs.

See above.

>     We noted that an OS mount command could be augmented to include the 
>     process of (1) mapping from a domain to an SRV query string, 
>     (2) performing the SRV query and extracting the host fileservers running 
>     the service, and (3) mounting the fileserver + ".domain-root-≤domain>" 
>     path. Another option would be to perform steps (1) and (2) separately 
>     and then input the result into the standard mount command.

Oh no, the mount command must do the whole enchilada.  Also, we can't
actually tell implementors what to do in their UIs.  What we can do is
create a distinct URI/URL scheme for domain-relative paths.  See above.

> + Admin NSDB Trust Anchor Management
> 
>   We briefly reviewed the mechanisms by which LDAP can be secured. LDAP 
>   connections can be secured using TLC or SASL. [Editor's note see RFC4513].

s/TLC/TLS/  (yes, lately TLS has needed TLC, but that's another story!  ;)

>   We discussed the following question who or what determines if a fileserver's
>   NSDB connections are secure. We asked if the ONC RPC Administrative protocol 
>   should indicate, possibly at junction create time, the desired security 
>   properties to use for an FSN's resolution.

In order to use TLS for this you only have two choices:

 - server certs (here's where TA mgmt comes in)
 - PSK (pre-shared keys), which is not really scalable here, so I say to
   heck with PSK

As for SASL... you have these choices:

 - PLAIN

   PLAIN offers no real security unless you're running over TLS and
   authenticating the server via TLS, but since that's all we want to
   do, PLAIN is not applicable!

 - DIGEST-MD5
 - SCRAM (on the RFC-Editor queue now)

   These are not unlike PSK in terms of scalability, ergo: not scalable,
   ergo not applicable for us.

 - GSSAPI (RFC4752) or GS2-KRB5, meaning Kerberos (GS2-KRB5 will soon be
   on the RFC-Editor queue)

   I.e., Kerberos.  As long as you're willing to have cross-realm trusts
   for this, this is an available choice, and it will scale.

So we really only have two choices for server authentication:

 - TLS with server certs (and TA mgmt, since we're NOT going to have a
   global PKI)

 - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)

By far the most likely case in actual federated deployments will be "TLS
with server certs".  It's just simpler (e.g., no need to talk to
Kerberos realm administrators).

>   There are at least three different ways the security properties of an NSDB 
>   connection could be derived: (1) each implementation could have its own 
>   policy and settings, (2) the ONC RPC Admin protocol could indicate the 
>   desired security mechanism, or (3) the NSDB could require a particular 
>   security mechanism.

(3) is not quite right: it's the _client_ that wants to authenticate the
_server_ here, not vice-versa.  The reverse of (3) is really what you
wrote for (1).  The server might want to insist on confidentiality
protection, in which case it will want to authenticate the client, but
the bottom line is that the most important thing here is that the client
authenticate the server.

>   Trond asked if there was a standard way for LDAP to indicate the required 
>   level of security. If so, it could be used as an auto configuration 
>   mechanism. James noted that there are ways for a user to indicate to 
>   an LDAP client that a security mechanism should be used (ldap:// versus
>   ldaps:// to request standard versus SSL/TLS connections respectively or 
>   the various SASL configuration settings). James was not aware of any 
>   way to automatically determine if an LDAP directory should be contacted 
>   via TLS, SASL, etc. 
> 
>   [AI] James Lentini will investigate if an LDAP client can automatically 
>        determine the security properties of an LDAP directory.

See above and below.

>   James suggested that it could be dangerous for a fileserver to depend 
>   totally on an NSDB for indicating the security mechanism for an LDAP 
>   connection. For example, a impostor might setup a rogue NSDB that 
>   indicated no security was necessary (and hence the NSDB did not need to 
>   be authenticated).

Exactly!

>   We discussed the security properties desired for an NSDB connection.
>   If security is a concern, the fileserver will want to authenticate the 
>   identity of the NSDB and have protect the integrity of the LDAP connection. 

Note that the identity of the NSDB, in the sense of having a "name" is
not important.  The identity of the NSDB in the sense of it have
authentication credentials that match what the ADMIN client meant (when
they created the junction) is important.  A very subtle distinction, I
know, but think of self-signed certs -- the names they bear are not
important, but the names you take them to authenticate are.

>   Privacy did not stand out as a concern on the call. [editor's note: while 
>   writing up these notes, I realized that privacy is also desirable. The 
>   contents of an FSL, for example the path name, may convey information 
>   that the federation members which to keep private].

Confidentiality protection may or may not be desirable; it should be
OPTIONAL.

In practice TLS is always used with confidentiality protection, so this
is practically moot, except that a server that wants confidentiality
protection also wants to authenticate (and authorize) clients.

>   James suggested that the fileserver administrator would have a 
>   vested interest in ensuring that the fileserver's referrals were 
>   valid. Therefore, the administrator will want the ability to 
>   configure the security properties used to resolve an FSN.

Yes.

>   Trond pointed out that the fileserver must be able to query the NSDB 
>   over a long period of time. This leads inevitably to the topic of 
>   key/certificate management.

With Kerberos, for example, this is non-issue.

With PKI this is a real issue.  The ADMIN protocol may need a procedure
by which to list soon-to-expire certs/TAs and a procedure to update
them.

Nico
--

-- 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

James Lentini | 3 Dec 23:32 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009


On Thu, 3 Dec 2009, Nicolas Williams wrote:

> On Thu, Dec 03, 2009 at 03:54:30PM -0500, James Lentini wrote:
> >   - NFS URL
> 
> This seems good to me:
> 
> 	fednfs://<domain>/<path>
> 
> For all other paths use nfs://<server>/<path> (RFC2224), or change the
> scheme to "nfs4".
> 
> See below.
> 
> >   - Client Processing of an NFS SRV RR 
> >     (as defined in draft-ietf-nfsv4-federated-fs-dns-srv-namespace-02)
> > 
> >     [...]
> > 
> >     Craig noted that there were two ways of naming a particular point. 
> >     There is the traditional way, server://path/to/file, and a new 
> >     SRV based name, roughly <domain> + <federated namespace path>.
> 
> Yes.
> 
> >     Paul speculated that the behavior of the OS mount command could be updated
> >     to incorporate the federated naming. In particular, he wondered if the 
> >     mount command would take a domain and mount the domain's federated root. 
> 
> The distinction between "server:/path" and "domain:/path" is very
> important.  It must be made.  It must be made in URLs, and it must be
> made in mount command arguments, and in automount maps, and GUIs.
> 
> See above.
> 
> >     We noted that an OS mount command could be augmented to include the 
> >     process of (1) mapping from a domain to an SRV query string, 
> >     (2) performing the SRV query and extracting the host fileservers running 
> >     the service, and (3) mounting the fileserver + ".domain-root-≤domain>" 
> >     path. Another option would be to perform steps (1) and (2) separately 
> >     and then input the result into the standard mount command.
> 
> Oh no, the mount command must do the whole enchilada.  

We discussed performing steps (1) and (2) separately in the context of 
backward compatibility with existing tools. 

I guess I was doing too much talking and neglected to capture that. :)

> Also, we can't actually tell implementors what to do in their UIs.

I noted that a protocol specification would not be the proper place to 
define the behavior of the mount command. 

Again, I inadvertently omitted that from the minutes.

> What we can do is create a distinct URI/URL scheme for 
> domain-relative paths.  See above.
> 
> > + Admin NSDB Trust Anchor Management
> > 
> >   We briefly reviewed the mechanisms by which LDAP can be secured. LDAP 
> >   connections can be secured using TLC or SASL. [Editor's note see RFC4513].
> 
> s/TLC/TLS/  (yes, lately TLS has needed TLC, but that's another story!  ;)

Good catch.

> 
> >   We discussed the following question who or what determines if a fileserver's
> >   NSDB connections are secure. We asked if the ONC RPC Administrative protocol 
> >   should indicate, possibly at junction create time, the desired security 
> >   properties to use for an FSN's resolution.
> 
> In order to use TLS for this you only have two choices:
> 
>  - server certs (here's where TA mgmt comes in)
>  - PSK (pre-shared keys), which is not really scalable here, so I say to
>    heck with PSK
> 
> As for SASL... you have these choices:
> 
>  - PLAIN
> 
>    PLAIN offers no real security unless you're running over TLS and
>    authenticating the server via TLS, but since that's all we want to
>    do, PLAIN is not applicable!
> 
>  - DIGEST-MD5
>  - SCRAM (on the RFC-Editor queue now)
> 
>    These are not unlike PSK in terms of scalability, ergo: not scalable,
>    ergo not applicable for us.
> 
>  - GSSAPI (RFC4752) or GS2-KRB5, meaning Kerberos (GS2-KRB5 will soon be
>    on the RFC-Editor queue)
> 
>    I.e., Kerberos.  As long as you're willing to have cross-realm trusts
>    for this, this is an available choice, and it will scale.

What about these other SASL authentication mechanisms:

http://www.iana.org/assignments/sasl-mechanisms

> So we really only have two choices for server authentication:
> 
>  - TLS with server certs (and TA mgmt, since we're NOT going to have a
>    global PKI)
> 
>  - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)

This is great information, but we were discussing a different question 
than what security mechanism are possible.

In the current Admin protocol, the client can request a fileserver to 
create a junction but does not have a mechanism for indicating the 
authentication,integrity,and privacy mechanisms to use when resolving 
the junction. The question is therefore, should the Admin protocol's 
JUNCTION_CREATE arguments include a parameter that indicates how the 
junction should be resolved in the future?

> By far the most likely case in actual federated deployments will be "TLS
> with server certs".  It's just simpler (e.g., no need to talk to
> Kerberos realm administrators).

Doesn't Active Directory use SASL with Kerberos? 

> >   There are at least three different ways the security properties of an NSDB 
> >   connection could be derived: (1) each implementation could have its own 
> >   policy and settings, (2) the ONC RPC Admin protocol could indicate the 
> >   desired security mechanism, or (3) the NSDB could require a particular 
> >   security mechanism.
> 
> (3) is not quite right: it's the _client_ that wants to authenticate the
> _server_ here, not vice-versa.  The reverse of (3) is really what you
> wrote for (1).  The server might want to insist on confidentiality
> protection, in which case it will want to authenticate the client, but
> the bottom line is that the most important thing here is that the client
> authenticate the server.
> 
> >   Trond asked if there was a standard way for LDAP to indicate the required 
> >   level of security. If so, it could be used as an auto configuration 
> >   mechanism. James noted that there are ways for a user to indicate to 
> >   an LDAP client that a security mechanism should be used (ldap:// versus
> >   ldaps:// to request standard versus SSL/TLS connections respectively or 
> >   the various SASL configuration settings). James was not aware of any 
> >   way to automatically determine if an LDAP directory should be contacted 
> >   via TLS, SASL, etc. 
> > 
> >   [AI] James Lentini will investigate if an LDAP client can automatically 
> >        determine the security properties of an LDAP directory.
> 
> See above and below.
> 
> >   James suggested that it could be dangerous for a fileserver to depend 
> >   totally on an NSDB for indicating the security mechanism for an LDAP 
> >   connection. For example, a impostor might setup a rogue NSDB that 
> >   indicated no security was necessary (and hence the NSDB did not need to 
> >   be authenticated).
> 
> Exactly!
> 
> >   We discussed the security properties desired for an NSDB connection.
> >   If security is a concern, the fileserver will want to authenticate the 
> >   identity of the NSDB and have protect the integrity of the LDAP connection. 
> 
> Note that the identity of the NSDB, in the sense of having a "name" is
> not important.  The identity of the NSDB in the sense of it have
> authentication credentials that match what the ADMIN client meant (when
> they created the junction) is important.  A very subtle distinction, I
> know, but think of self-signed certs -- the names they bear are not
> important, but the names you take them to authenticate are.
> 
> >   Privacy did not stand out as a concern on the call. [editor's note: while 
> >   writing up these notes, I realized that privacy is also desirable. The 
> >   contents of an FSL, for example the path name, may convey information 
> >   that the federation members which to keep private].
> 
> Confidentiality protection may or may not be desirable; it should be
> OPTIONAL.
> 
> In practice TLS is always used with confidentiality protection, so this
> is practically moot, except that a server that wants confidentiality
> protection also wants to authenticate (and authorize) clients.
> 
> >   James suggested that the fileserver administrator would have a 
> >   vested interest in ensuring that the fileserver's referrals were 
> >   valid. Therefore, the administrator will want the ability to 
> >   configure the security properties used to resolve an FSN.
> 
> Yes.
> 
> >   Trond pointed out that the fileserver must be able to query the NSDB 
> >   over a long period of time. This leads inevitably to the topic of 
> >   key/certificate management.
> 
> With Kerberos, for example, this is non-issue.
> 
> With PKI this is a real issue.  The ADMIN protocol may need a procedure
> by which to list soon-to-expire certs/TAs and a procedure to update
> them.
> 
> Nico
> -- 
> 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Nicolas Williams | 3 Dec 23:41 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009

On Thu, Dec 03, 2009 at 05:32:35PM -0500, James Lentini wrote:
> > As for SASL... you have these choices:
> > 
> 
> What about these other SASL authentication mechanisms:
> 
> http://www.iana.org/assignments/sasl-mechanisms

They are clearly not applicable:

 - KERBEROS_V4 is obsolete.
 - SKEY is obsolete.
 - EXTERNAL means "look at the secure channel we're using, likely TLS"
 - CRAM-MD5 is of limited applicability, and anyways fails to be useful
   here for the same reasons as DIGEST-MD5 and SCRAM
 - ANONYMOUS clearly doesn't help
 - OTP doesn't help
 - GSS-SPNEGO isn't relevant (you don't want to use it, ever)
 - SECURID clearly doesn't help
 - NTLM is like Kerberos, but with obviously much more limited
   applicability
 - NMAS_* -- I've no clue what they are, and I doubt they are
   applicable, and they are listed as having LIMITED use
 - 9798-* are for authenticating clients, while we want to authenticate
   servers
 - KERBEROS_V5 is not really in use, and anyways we have "GSSAPI" and
   GS2-KRB5 (see previous e-mail), which are applicable

> > So we really only have two choices for server authentication:
> > 
> >  - TLS with server certs (and TA mgmt, since we're NOT going to have a
> >    global PKI)
> > 
> >  - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)
> 
> This is great information, but we were discussing a different question 
> than what security mechanism are possible.

You have to take into account what's actually available.  And my post
did address the issue of what properties are desired.

> In the current Admin protocol, the client can request a fileserver to 
> create a junction but does not have a mechanism for indicating the 
> authentication,integrity,and privacy mechanisms to use when resolving 
> the junction. The question is therefore, should the Admin protocol's 
> JUNCTION_CREATE arguments include a parameter that indicates how the 
> junction should be resolved in the future?

To me it makes no sense to talk about TA mgmt in the ADMIN protocol if
we don't either a) require TLS with confidentiality protection and
server certs, or b) make NSDB LDAP connection security parameters
configurable via the ADMIN protocol.  To me this is an obvious yes.
(I've not actually reviewed the ADMIN protocol in detail though.)

> > By far the most likely case in actual federated deployments will be "TLS
> > with server certs".  It's just simpler (e.g., no need to talk to
> > Kerberos realm administrators).
> 
> Doesn't Active Directory use SASL with Kerberos? 

That's one way to use it (you have to in order to access non-public data
-- object attributes that have ACLs that don't grant read permission to
Everyone).

Nico
--

-- 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Daniel Ellard | 4 Dec 02:31 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009

A few comments below.  If they're just rehashing things
covered in the conf call, just let me know...  Sorry that I
have a perpetual conflict on Thursday...

On Thu, Dec 3, 2009 at 3:54 PM, James Lentini <jlentini <at> netapp.com> wrote:
>
> FedFS Meeting Minutes, 12/03/2009
> ---------------------------------
>
> Attendees
> ---------
>
> Craig Everhart (NetApp)
> Sorin Faibish (EMC)
> Paul LeMahieu (EMC)
> James Lentini (NetApp)
> Trond Myklebust (NetApp)
> Chris Stacey (EMC)
>
> 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
>
>  - Chris Stacey will writeup a description of an SNMP MIB.

I really like the idea of having an SNMP MIB for NFSv4, and
eventually for the NSDB and fedfs aspects of the file servers.
But is doing an NFSv4 MIB part of the charter for the fedfs
discussions?  It seems like there's plenty of work to do already.

>  - NFS URL
>
>    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL
>    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS.

One of the original goals of the fedfs effort was to make the
fedfs part of the protocol as fs-agnostic as possible.  It seems
like putting the string "nfs" in the URL (as I've seen in at least
one suggestion) is a bit NFS-centric.  (yes, I'm aware that I'm
addressing this to the nfsv4 wg...)

>    This was not the type of NFS URL Paul was asking about.
>
>    Trond noted the NFSv4 has a public filehandle concept, but the
>    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is
>    different from WebNFS.

If we rely on the availability of  a "public filehandle", will we be able
to support underlying file systems that do not?  (how do people feel
about putpbfh in the first place--is it something we'd want to support
in perpetuity ourselves?)

>    ...
>
>    A fileserver's pseudo root and federated namespace root are intentionally
>    different. This allows for greater flexibility. A single server can be
>    the root of multiple namespaces, contain other directories, etc.

An old topic, but just in case...

Junction can still point to something *other* than the root of the pseudo-fs,
right?

>
> + Admin NSDB Trust Anchor Management
>
>  We briefly reviewed the mechanisms by which LDAP can be secured. LDAP
>  connections can be secured using TLC or SASL. [Editor's note see RFC4513].
>
>  We discussed the following question who or what determines if a fileserver's
>  NSDB connections are secure. We asked if the ONC RPC Administrative protocol
>  should indicate, possibly at junction create time, the desired security
>  properties to use for an FSN's resolution.
>
>  There are at least three different ways the security properties of an NSDB
>  connection could be derived: (1) each implementation could have its own
>  policy and settings, (2) the ONC RPC Admin protocol could indicate the
>  desired security mechanism, or (3) the NSDB could require a particular
>  security mechanism.

I'm missing something here.  Given that it's possible for any server to
host a junction referring to an NSDB in any (or every) other admin domain,
how can (1) possibly work (unless the entire federation is homogeneous)?

The possible permutations of different security policies and mechanisms
could be a real headache.  The fewer the better.

-Dan
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

James Lentini | 4 Dec 15:33 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009


On Thu, 3 Dec 2009, Nicolas Williams wrote:

> On Thu, Dec 03, 2009 at 05:32:35PM -0500, James Lentini wrote:
> > > As for SASL... you have these choices:
> > > 
> > 
> > What about these other SASL authentication mechanisms:
> > 
> > http://www.iana.org/assignments/sasl-mechanisms
> 
> They are clearly not applicable:
> 
>  - KERBEROS_V4 is obsolete.
>  - SKEY is obsolete.
>  - EXTERNAL means "look at the secure channel we're using, likely TLS"
>  - CRAM-MD5 is of limited applicability, and anyways fails to be useful
>    here for the same reasons as DIGEST-MD5 and SCRAM
>  - ANONYMOUS clearly doesn't help
>  - OTP doesn't help
>  - GSS-SPNEGO isn't relevant (you don't want to use it, ever)
>  - SECURID clearly doesn't help
>  - NTLM is like Kerberos, but with obviously much more limited
>    applicability
>  - NMAS_* -- I've no clue what they are, and I doubt they are
>    applicable, and they are listed as having LIMITED use
>  - 9798-* are for authenticating clients, while we want to authenticate
>    servers
>  - KERBEROS_V5 is not really in use, and anyways we have "GSSAPI" and
>    GS2-KRB5 (see previous e-mail), which are applicable

Thanks for the rundown.

> > > So we really only have two choices for server authentication:
> > > 
> > >  - TLS with server certs (and TA mgmt, since we're NOT going to have a
> > >    global PKI)
> > > 
> > >  - Kerberos V5 (via SASL/GSSAPI or SASL/GS2-KRB5)
> > 
> > This is great information, but we were discussing a different question 
> > than what security mechanism are possible.
> 
> You have to take into account what's actually available.  And my post
> did address the issue of what properties are desired.
> 
> > In the current Admin protocol, the client can request a fileserver to 
> > create a junction but does not have a mechanism for indicating the 
> > authentication,integrity,and privacy mechanisms to use when resolving 
> > the junction. The question is therefore, should the Admin protocol's 
> > JUNCTION_CREATE arguments include a parameter that indicates how the 
> > junction should be resolved in the future?
> 
> To me it makes no sense to talk about TA mgmt in the ADMIN protocol if

Agreed. This is why we discussed how a fileserver decides to the 
security properties of an NSDB connection.

> we don't either a) require TLS with confidentiality protection and
> server certs, 

For (a), do you mean that TLS would be required for all NSDB 
connections? That sounds too restrictive. I'd rather allow 
administrators to choose the security mechanism that makes the most 
sense for their situation and SASL is also very popular in the LDAP 
world (as we discussed below regarding Active Directory).

> or b) make NSDB LDAP connection security parameters configurable via 
> the ADMIN protocol.  To me this is an obvious yes. (I've not 
> actually reviewed the ADMIN protocol in detail though.)

Yes, this is one of the options we discussed. The arguments to 
FEDFS_CREATE_JUNCTION would be a natural place to include such a 
parameter and perhaps the appropriate security context as well.

> > > By far the most likely case in actual federated deployments will be "TLS
> > > with server certs".  It's just simpler (e.g., no need to talk to
> > > Kerberos realm administrators).
> > 
> > Doesn't Active Directory use SASL with Kerberos? 
> 
> That's one way to use it (you have to in order to access non-public data
> -- object attributes that have ACLs that don't grant read permission to
> Everyone).

This would be an argument for supporting SASL with Kerberos.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

James Lentini | 4 Dec 15:57 2009
Picon

Re: [FedFS] Meeting Minutes, 12/03/2009


On Thu, 3 Dec 2009, Daniel Ellard wrote:

> A few comments below.  If they're just rehashing things
> covered in the conf call, just let me know...  Sorry that I
> have a perpetual conflict on Thursday...
> 
> On Thu, Dec 3, 2009 at 3:54 PM, James Lentini <jlentini <at> netapp.com> wrote:
> >
> > FedFS Meeting Minutes, 12/03/2009
> > ---------------------------------
> >
> > Attendees
> > ---------
> >
> > Craig Everhart (NetApp)
> > Sorin Faibish (EMC)
> > Paul LeMahieu (EMC)
> > James Lentini (NetApp)
> > Trond Myklebust (NetApp)
> > Chris Stacey (EMC)
> >
> > 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
> >
> >  - Chris Stacey will writeup a description of an SNMP MIB.
> 
> I really like the idea of having an SNMP MIB for NFSv4, and
> eventually for the NSDB and fedfs aspects of the file servers.
> But is doing an NFSv4 MIB part of the charter for the fedfs
> discussions?  

This question was raised in Chris Stacey's message. I haven't seen a 
response on that.

> It seems like there's plenty of work to do already.

Agreed.

> >  - NFS URL
> >
> >    We discussed the RFC 2224 definition of a NFS URL. It defines the NFS URL
> >    format for NFSv2 and NFSv3, but not NFSv4. This RFC is part of WebNFS.
> 
> One of the original goals of the fedfs effort was to make the
> fedfs part of the protocol as fs-agnostic as possible.  It seems
> like putting the string "nfs" in the URL (as I've seen in at least
> one suggestion) is a bit NFS-centric.  (yes, I'm aware that I'm
> addressing this to the nfsv4 wg...)

Yes, our discussion was a bit NFS-centric. Let me explain.

On the call, it became clear that the question was was NOT about an 
RFC 2224 style URL, but rather the syntax of the OS mount command's 
server path parameter (for example the Linux mount.nfs(1)'s 
"remotetarget" parameter).

It would have helped if this next line from the minutes had been more 
verbose:

> >    This was not the type of NFS URL Paul was asking about.
> >
> >    Trond noted the NFSv4 has a public filehandle concept, but the
> >    mechanism for obtaining it, the NFSv4 PUTPUBFH operation, is
> >    different from WebNFS.
> 
> If we rely on the availability of  a "public filehandle", will we be able
> to support underlying file systems that do not?  (how do people feel
> about putpbfh in the first place--is it something we'd want to support
> in perpetuity ourselves?)

If memory serves correct, Trond was responding to my comment that 
there is no NFSv4 version of a WebNFS URL defined in RFC 2224. He was 
pointing out that NFSv4 retains the public filehandle concept. Again, 
we realized fairly quickly that the question wasn't really about URLs.

> >    ...
> >
> >    A fileserver's pseudo root and federated namespace root are intentionally
> >    different. This allows for greater flexibility. A single server can be
> >    the root of multiple namespaces, contain other directories, etc.
> 
> An old topic, but just in case...
> 
> Junction can still point to something *other* than the root of the pseudo-fs,
> right?

Yes. I noted that and included it in the minutes:

> >    A junction may be present at any point beneath the federated
> >    root and point to an arbitrary location (the target of a 
> >    junction does not need to be beneath 
> >    /.domain-root-example.net).

> > + Admin NSDB Trust Anchor Management
> >
> >  We briefly reviewed the mechanisms by which LDAP can be secured. LDAP
> >  connections can be secured using TLC or SASL. [Editor's note see RFC4513].
> >
> >  We discussed the following question who or what determines if a fileserver's
> >  NSDB connections are secure. We asked if the ONC RPC Administrative protocol
> >  should indicate, possibly at junction create time, the desired security
> >  properties to use for an FSN's resolution.
> >
> >  There are at least three different ways the security properties of an NSDB
> >  connection could be derived: (1) each implementation could have its own
> >  policy and settings, (2) the ONC RPC Admin protocol could indicate the
> >  desired security mechanism, or (3) the NSDB could require a particular
> >  security mechanism.
> 
> I'm missing something here.  Given that it's possible for any server to
> host a junction referring to an NSDB in any (or every) other admin domain,
> how can (1) possibly work (unless the entire federation is homogeneous)?

I didn't word (1) very well. 

The question is how does a fileserver determine the security policy 
for an NSDB connection. 

Option (1) is for the administrator to use an implementation-specific 
interface to configure a security policy (it might be a global on/off 
switch that requires the fileserver to use TLS for all NSDB 
connections or a fine-grained per-junction setting). Option (1) isn't 
incredibly attractive, but it is how things are likely to work absent 
a configuration mechanism in the ONC RPC Admin protocol or some other 
standardized mechanism.

> The possible permutations of different security policies and mechanisms
> could be a real headache.  The fewer the better.

That is a good point. At the moment, the specifications allow for two 
options: insecure or TLS. It seems we should consider adding SASL with 
Kerberos as another option.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Gmane