Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt

[Trond Myklebust <[e-mail]>]

Why pass Kerberos tickets around? Is there any reason not to just pass an
initialised RPCSEC_GSS session handle?

Cheers
  Trond

On 8 August 2017 at 11:56, Olga Kornievskaia <[e-mail]> wrote:

> Hi Tom,
>
> Are you planning to expand the 4.1.1? The same comment that I wrote on
> my last email applies here where I suggested to specify 4things. It's
> needed to have interoperable implementations. As something can choose
> to return back TGTs (something like and AS_REP) and some might return
> server tickets (something like a TGS-REP). Some server implementation
> might encrypt needed info under the session key from the secured
> communication, some might encrypt it with the user's main key. How
> would the client know what to expect?
>
> Also when I wrote about opaque_auth being 400bytes I was talking about
> including just a single credential reply back. I'm looking on the
> network trace and my AS_REP is 801bytes and TGS_REP is 960bytes. And
> if somebody plans to include any authorization data in their tickets,
> well that will blow up even more.
>
> On Mon, Aug 7, 2017 at 8:25 PM, Thomas Haynes <[e-mail]>
> wrote:
> > So here is a first hack at Flex Files v2. I thought it would come in much
> > smaller than 11 pages,
> > so perhaps some pruning will be necessary.
> >
> > I’m aware Ben had some comments on:
> >
> >    Can I suggest putting in a typed opaque auth blob instead of explicit
> >    synthetic uid/gid fields?
> >
> > I have purposely done:
> >
> >    /// struct ffv2_data_server4 {
> >    ///     deviceid4               ffds_deviceid;
> >    ///     uint32_t                ffds_efficiency;
> >    ///     stateid4                ffds_stateid<>;
> >    ///     nfs_fh4                 ffds_fh_vers<>;
> >    ///     fattr4_owner            ffds_user;
> >    ///     fattr4_owner_group      ffds_group;
> >    ///     opaque_auth             ffds_auth;
> >    /// };
> >
> > Because of AI1:
> >
> >    [[AI1: after the lesson learned from ffds_stateid, we either need to
> put
> > an
> >    array here or define all of the file handles to share the same
> >    credentials.  And as Olga points out in her email, this gets big
> >    fast.  Especially if we throw in many mirrored copies!  --TH]]
> >
> > I.e., the ffds_auth is inside an array of ffv2_data_server4 which is
> > in itself inside an array of ffv2_mirror4 AND it could be argued that
> > ffds_auth (and ffds_user/ffds_group) need to be an array.
> >
> > Even if we decide to make all FHs share the same credentials, we
> > eventually can hit a limit of the number of mirrored copies.
> >
> > And Ben, the other reason not to use a typed opaque auth blob
> > is because the  ffds_user and ffds_group are strings, and do
> > not fit into AUTH_UNIX. We could define AUTH_SYNTHETIC. :-)
> >
> > Begin forwarded message:
> >
> > From: <[e-mail]>
> > Subject: New Version Notification for draft-haynes-nfsv4-flex-
> filesv2-00.txt
> > Date: August 7, 2017 at 5:11:45 PM PDT
> > To: Thomas Haynes <[e-mail]>
> >
> >
> > A new version of I-D, draft-haynes-nfsv4-flex-filesv2-00.txt
> > has been successfully submitted by Thomas Haynes and posted to the
> > IETF repository.
> >
> > Name: draft-haynes-nfsv4-flex-filesv2
> > Revision: 00
> > Title: Parallel NFS (pNFS) Flexible File Layout v2
> > Document date: 2017-08-07
> > Group: Individual Submission
> > Pages: 11
> > URL:
> > https://www.ietf.org/internet-drafts/draft-haynes-nfsv4-
> flex-filesv2-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-haynes-nfsv4-flex-filesv2/
> > Htmlized:
> > https://tools.ietf.org/html/draft-haynes-nfsv4-flex-filesv2-00
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-haynes-nfsv4-flex-filesv2-00
> >
> >
> > Abstract:
> >   The Parallel Network File System (pNFS) allows a separation between
> >   the metadata (onto a metadata server) and data (onto a storage
> >   device) for a file.  The flexible file layout type is an extension to
> >   pNFS which allows the use of storage devices in a fashion such that
> >   they require only a quite limited degree of interaction with the
> >   metadata server, using already existing protocols.  This document
> >   describes two extensions to the flexible file layout type to allow
> >   for multiple stateids for tightly coupled NFSv4 models and an
> >   additional security mechanism for loosely coupled models.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>