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

[Nicolas Williams <Nicolas.Williams at sun.com>]

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 

Did you mean "would eliminate"?  But note that I intended for
authentication information in the NSDB name to be OPTIONAL.  It'd only
be used when an NSDB has a self-signed cert.

> keys are compromised, the certificate information must be invalidated. 
> With or without an authentication token in the FSN, a fileserver 
> concerned about this issue should validate the NSDB's certificate. 

Of course.

> We will include a full discussion of this subject in the Security 
> Considerations section of the NSDB specification.

OK.