[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                           R. Mesta
Internet-Draft                                    Sun Microsystems, Inc.
Expires: April 15, 2006                                     Oct 12, 2005


                     A DNS RR for NFSv4 ID Domains
                       draft-ietf-nfsv4-dns-rr-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 15, 2006.

Abstract

   This document describes a new DNS Resource Record (RR) type that will
   be utilized by NFSv4 clients and servers to determine the domain
   string to utilize for on-the-wire user/group name attributes and ACL
   entry information.  Discussion and suggestions for improvements
   requested.





Mesta                    Expires April 15, 2006                 [Page 1]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  NFS4ID Resource Record Definition  . . . . . . . . . . . . . .  4
   3.  Example: Using the NFS4ID RR . . . . . . . . . . . . . . . . .  5
     3.1.  NFS4ID: RR Unavailable . . . . . . . . . . . . . . . . . .  5
     3.2.  NFS4ID: RR Available . . . . . . . . . . . . . . . . . . .  5
     3.3.  NFS4ID: DNS Tree Traversal . . . . . . . . . . . . . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
   8.  Informative References . . . . . . . . . . . . . . . . . . . .  9
   9.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
   10. IPR Notices  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   11. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 11




































Mesta                    Expires April 15, 2006                 [Page 2]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


1.  Introduction

   Version 4 of the Network File System (NFSv4) protocol specification
   [RFC3530] introduces a way for clients and servers to exchange file
   ownership and ACL entry information as string names qualified with a
   domain name, whereas earlier versions of the protocol used 32-bit
   integers for the same type of identifier meta data.  Section 5.8 of
   [RFC3530] defines the generic format for string based identifiers to
   be "[user|group]@dns_domain".

   The string identifier prescribed suggests that the domain to be used
   for the on-the-wire format be a DNS domain.  However, the use of an
   NFSv4 client's and server's default DNS domain to qualify user/group
   names would be inappropriate on network configurations that utilize
   multiple DNS domains, but still use a common user/group name space
   throughout.  This would lead to user/group name recognition failures
   across the network, at either client or server side, due to
   potentially mismatched domains.  More succinctly, accessing NFSv4
   managed files across multiple DNS domains can cause string
   identifiers to be mapped to "nobody", regardless of whether a common
   user/group name space is shared or not.

   The challenge presented is then to have a mechanism for distributing
   a common domain configuration for use by NFSv4 implementations that
   only deal with domain-agnostic identifiers; more specifically, for
   NFSv4 clients and servers that are administratively controlled by
   distinct DNS domains.

   A natural solution for this type of problem would be to have NFSv4
   clients and servers query their configured DNS server for the
   specific "domain" to utilize for sending user/group and ACL
   attributes across DNS boundaries.  Thus, in a properly configured
   deployment, having NFSv4 clients access NFSv4 servers on different
   DNS domains that still use a common user/group name space, would not
   lead to recognition failures due to the use of the same "domain" for
   NFSv4 user names, group names and ACL entry information.

   A secondary benefit of using a DNS RR for the NFSv4 domain data store
   is that the resolver's searching mechanism can be leveraged to
   perform higher level domain traversal.  This enables properly
   configured NFSv4 clients to perform searches on higher levels of the
   DNS domain tree until either an NFS4ID RR is found or all
   possibilities have been exhausted.

   This is the solution proposed by this memo.






Mesta                    Expires April 15, 2006                 [Page 3]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


2.  NFS4ID Resource Record Definition

   The general syntax for an NFS4ID resource record, whose type is
   expected to be IANA assigned as per [RFC2929], is:

          <owner>    <ttl>    <class>    NFS4ID    "dname string"

   where:

   o  <owner>, <ttl> and <class> specify the zone, time-to-live and "IN"
      respectively, as defined in [RFC1034].

   o  The RDATA for this record is a string that will be used to specify
      the domain name to use in 'owner', 'owner_group' and ACL entry
      information, as defined by [RFC3530].

   The proposed RR is meant for use solely by NFSv4; the use of the
   RDATA field to store additional class information will lead to the
   familiar sub-typing issues associated with the use of TXT RR's
   [RFC1464].































Mesta                    Expires April 15, 2006                 [Page 4]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


3.  Example: Using the NFS4ID RR

   As a real world example, assume that an enterprise has a top level
   domain of "example.com" and that it has multiple (perhaps
   geographically dispersed) DNS domains.  For the sake of the current
   discussion, two domains is more than enough; "foo.example.com" and
   "bar.example.com".  Assume further that NFSv4 has been deployed
   across these DNS domains and there are active NFSv4 mounts crossing
   the DNS domain boundary.

3.1.  NFS4ID: RR Unavailable

   Assuming that no NFS4ID RR's have been configured on either the
   "foo.example.com" nor "bar.example.com" name servers, then the NFSv4
   clients and servers that have active cross-domain mounts should be
   sending user/group name attributes of the form "[user|group]@
   foo.example.com" or "[user|group]@bar.example.com".

   If a user in client.foo.example.com wanted to access his/her files in
   server.bar.example.com, the user would find his/her files (seemingly)
   being owned by "nobody".  The reason for this is that client.foo is
   trying to match server.bar's domain to its own, and since the domains
   are mismatched, that is, the DNS domain itself is being used for
   NFSv4 transactions, the client has no choice but to reject the user/
   group mapping.

3.2.  NFS4ID: RR Available

   The following configuration would be expected in order to make the
   NFS4ID RR available in both domains:

   The "foo.example.com" domain zone file contains:

      $ORIGIN   foo.example.com.

      foo.example.com.        IN         NFS4ID        "example.com"

   While the "bar.example.com" domain zone file contains:

      $ORIGIN   bar.example.com.

      bar.example.com.        IN         NFS4ID        "example.com"

   Under this scenario, client.foo.example.com would access the user's
   data in server.bar.example.com; this time, however, the user and
   group name are of the form "[user|group@example.com" on-the-wire.
   The client will attempt to match the domain in the in-bound user/
   group attribute data and will match its own configured domain since



Mesta                    Expires April 15, 2006                 [Page 5]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


   both client.foo and server.bar are utilizing the same domain for
   NFSv4 transactions.

3.3.  NFS4ID: DNS Tree Traversal

   Consider the case in which the top level domain zone file has the
   following NFS4ID entry:

      example.com.            IN         NFS4ID        "example.com"

   As previously stated, the lower level DNS domains, "foo.example.com"
   and "bar.example.com", can each define their own NFS4ID RR's in order
   to override the NFS4ID record defined by the top level domain.  To
   continue the example, assume that an NFS4ID record is only defined
   for domain "foo.example.com" and it is defined to be:

      foo.example.com.        IN         NFS4ID            "foo.foo"

   Assuming the NFSv4 clients' /etc/resolv.conf 'search' parameter has
   been properly configured, an NFS4ID RR lookup in the
   "foo.example.com" domain will yield the string "foo.foo", whereas a
   lookup for the NFS4ID RR in the "bar.example.com" domain, will not
   yield any value and will propagate to the higher level domain as
   "example.com"; at this point, the string "example.com" will be
   returned for NFS4ID RR lookups in domain "bar.example.com".


























Mesta                    Expires April 15, 2006                 [Page 6]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


4.  IANA Considerations

   IANA is requested to allocate RR type code TBD for NFS4ID from the
   standard RR type space.















































Mesta                    Expires April 15, 2006                 [Page 7]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


5.  Security Considerations

   There are two main security considerations for this facility:

   o  Denial of service attacks where clients and servers are made to
      disagree about their default NFSv4 domain and so ACL and file/
      directory ownership manipulation can be made to fail.

   o  Redirection attacks where a client is forced to use a different
      domain than it was otherwise intended to use while a multi-domain
      server can understand and distinguish between users (and groups)
      with the same names but in different domains.  In this attack a
      user might be fooled into granting access to a file or directory
      to the wrong user or group.  For example, a "chown joe somefile"
      command might be intended to reference "joe@one.domain" but the
      client may be made to use a different domain to qualify "joe",
      thus changing the ownership of 'somefile' to
      "jane@some.other.domain".

   The latter is of particular concern as servers capable of operating
   in more than one domain are feasible and likely already exist.

   The use of DNSSEC should foil both of these attacks, and thus, we
   recommend its use.



























Mesta                    Expires April 15, 2006                 [Page 8]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


6.  Acknowledgments

   David Robinson, Spencer Shepler, Nico Williams, Bill Sommerfeld, and
   Olaf Kolkman.


7.  Normative References

   [RFC1034]  Mockapetris, P., "Domain Names - Concepts And Facilities",
              RFC 1034, Nov 1987.

   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", RFC 1464, May 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2929]  Eastlake, D., Brunner-Williams, E., and B. Manning,
              "Domain Name System (DNS) IANA Considerations", RFC 2929,
              Sep 2000.

   [RFC3530]  Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
              Beame, C., Eisler, M., and D. Noveck, "Network File System
              (NFS) version 4 Protocol", RFC 3530, April 2003.


8.  Informative References

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", Oct 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              March 1999.























Mesta                    Expires April 15, 2006                 [Page 9]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


9.  Author's Address

   Rick Mesta
   Sun Microsystems, Inc.
   5300 Riata Park Court
   M/S: UAUS08-102
   Austin, TX  78727
   USA

   Phone: +1 512-401-1076
   Email: rick.mesta@sun.com








































Mesta                    Expires April 15, 2006                [Page 10]


Internet-Draft        A DNS RR for NFSv4 ID Domains             Oct 2005


10. IPR Notices

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


11. Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Mesta                    Expires April 15, 2006                [Page 11]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/