Subject: Re: [nfsv4] New version of NFSv4 multi-domain access draft (

From: James Lentini <[email-masked]>
Date: Tue, 5 Oct 2010 12:06:39 -0400 (EDT)

I will schedule time during the FedFS call on 10/28 for Andy to 
present this draft and give folks who have read it a chance to ask him 
questions in real time.

-james

On Thu, 30 Sep 2010, William A. (Andy) Adamson wrote:

> Hello
> 
> I uploaded a new version of our internet draft "NFSv4 Multi-Domain Access"
> 
> http://www.ietf.org/id/draft-adamson-nfsv4-multi-domain-access-03.txt
> 
> Please have a look and give us any feedback.
> 
> There are a number of sections that need text. Here are some issues
> that need discussion.
> 
> 1)  NFSv4 is not the only potential consumer. NFSv3, and SFTP, for
> example. Do we mention these and/or other potential consumers.
> 
> 2) Section 5.4.3.  Resolving Domain Names to Domain IDs
> 
> We need to have a common way to map Domain Names to Domain IDs.
> Currently we have two suggestions
> - Just use SIDs, first asking MSFT to allocate a suitable authority
> for non-Windows domain SIDs.
> - Store 96-bit numeric IDs
>      a) cast those to domain SIDs later.
>      b) define a non-SID large ID format
> 
> 3) Section 6.1.2.  RPCSEC_GSS Authorization Context Credential Data
> 
> Do we want to define a new "PAC" for multi-domain access for those
> implementations that don't provide the Windows PAC, or just insist
> upon the use of the Microsoft PAC.
> 
> 4) General review of section 6.3.  User Group Membership Determination
> - Do we depend upon 2307bis
> - Do we require groups within groups
> 
> 5) Do we need a section on service discovery.  Two potential methods:
> - Use local methods (configuration, DNS SRV RR lookups, ...) to
>   discover local domain's servers, then depend on LDAP referrals for
>   discovering all other domains' s
> - Use DNS SRV RRs much the way AD does.ervers.
> 
> 
> -->Andy
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 5 Oct 2010 11:25:01 -0500

> example. Do we mention these and/or other potential consumers.

IMO: yes, mention the other potential consumers.  The list is open-
ended.  I'd include WebDAV and even local access in remote SSHv2
sessions in the list.

The risk: making people wonder why this is an NFSv4 WG work item.
  Answer: it goes hand in hand with the federated namespace work items,
          which is also not that specific to NFSv4.

> for non-Windows domain SIDs.

Yes, let's do that.

>      b) define a non-SID large ID format

(a) is fine.  (b) is a fine fallback should MSFT be unwilling to assign
authority numbers for this purpose.  See below.

> upon the use of the Microsoft PAC.

IMO:

 - we must have a mode of operation that does not require a PAC at all;

 - we must have a mode of operation that works with the Windows PAC only;

 - we should consider an I-D defining either a new PAC or an extension
   to the Windows one to include information that servers might need but
   which is not delivered by the existing Windows PAC (but first we must
   identify such information).

Re-usign the Windows PAC implies using SIDs.  If we can't get an
authority number from MSFT, then we can't re-use the PAC.  Unless we
simply use authority #5 in the same way that Windows domains do (this is
certainly an option to consider).

> - Do we require groups within groups

IMO:

 - provide a[n obviously limited] mode of operation that depends only on
   RFC2307 and therefore does not support group nesting;

 - provide a more full-fledged mode of operation that depends RFC2307bis;

 - provide a more full-fledged mode of operation that depends AD's schema.

> - Use DNS SRV RRs much the way AD does.ervers.

I would prefer that we have one REQUIRED to implement service discovery
mechanism as follows: a) specify local DS discovery using DNS SRV RR
lookups much like AD does (i.e., have a label to indicate the purpose of
the LDAP service, not just _ldap), b) use LDAP referrals (and DNS
resolution of the host parts of the referrals) to discover DSes of other
domains.

The main benefit of this mechanism is that we can leave the work of
finding topologically-close caches and/or authoritative servers to the
clients' local DSes, thus avoiding the need to deal directly with
topology in our spec.

I would also like to make (a) general enough that clients could discover
DSes of remote domains on their own.  

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 7 Oct 2010 12:19:54 -0400

Couple of things I wonder about here.

The draft goes to some lengths to claim that an NFS server's use of
"name@domainname" would be problematic because of difficulties keeping
up with accounts ("a severe constraint"), and that servers "really ought
not" store authz entities in that form.  While I don't agree with either
of these, I don't think that my objections are material to the point of
the draft.

Instead, if I'm reading correctly, this is a presentation about how to
do ID mapping with 32-bit or 64-bit IDs, with name service assistance.
I think that the draft could make the point about the prevalence of such
servers without needing to critique other representations.  Perhaps (but
not _required_) the draft could deal with the interoperability of
servers, some of which use integers for IDs and some which use
name@domainname, in the kind of FedFS scenario you describe.

I eagerly await the 5.4.3 text, or even the plans.  What's a "domain" in
this context?  How does a server tell if it is in one?  Does a client
need to know?  What is a "domain-local ID"? In section 5.2.1, what's the
point to "assigning and publishing a unique ID to each DNS domain"?
Isn't the DNS domain name good enough?

Could we add an example to 6.2?  I can't tell if the first paragraph is
a modest hole or a truck-sized hole.

		Craig

> -----Original Message-----
> From: William A. (Andy) Adamson [mailto:[email-masked]]
> Sent: Thursday, September 30, 2010 1:40 PM
> To: NFSv4
> Subject: [nfsv4] New version of NFSv4 multi-domain access draft (
> 
> Hello
>

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 7 Oct 2010 13:26:29 -0400

> of these, I don't think that my objections are material to the point of

OK

> do ID mapping with 32-bit or 64-bit IDs, with name service assistance.

The intention is describe possible implementation strategies for all
combinations of ID mapping: large ID -> small ID, small ID -> large
ID, and large ID -> large ID when the large IDs are of different
formats. We have not finished this job.

> servers without needing to critique other representations.

No critique intended.

> Perhaps (but

Yes, that is our intention.  BTW do you know of any file systems that
store name@domainname on disk?

> this context?

The DNS Domain presented to a server in name@domain

> How does a server tell if it is in one?

Every NFSv4 server is in a domain, and needs to be able to return a
canonical name@domain for each local representation of a user or
group. (second bullet in section 3)

>  Does a client
> need to know?

Yes - to perform a setacl which sends name@domain on the wire.

> What is a "domain-local ID"?

>From section 4 :

      Domain-local ID: Most installations assign numeric, local
      identifiers to users and groups, using a namespace local to their
      domain.  We call this a domain-local ID.

> In section 5.2.1, what's the

To have a level of indirection between the on disk domain portion of
an ID and the actual DNS domain name to handle (admittedly rare) DNS
domain name changes. The reason to publish this is to allow remote
servers that are presented with the ID the ability to map back from
the numeric domain ID to the DNS domain name.

The windows SID does this.

> Isn't the DNS domain name good enough?

Mostly, as noted in section 5.2.

> a modest hole or a truck-sized hole.

Sure, or at least add more descriptive text about the different
possibilties  Section 7.1 describes an attribute for LDAP which is one
way to perform the mapping.  By 'hole' are you thinking a security
hole? (we should specify here that all mapping and name service
communications need to be over a secured channel).

-->Andy