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

Olga Kornievskaia <aglo@citi.umich.edu> Tue, 08 August 2017 19:19 UTC

Return-Path: <olga.kornievskaia@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B482E132A92 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 12:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhDBLFFoVQgE for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 12:19:44 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDC4132A8C for <nfsv4@ietf.org>; Tue, 8 Aug 2017 12:19:44 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id t37so24935862qtg.5 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 12:19:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=mRwKWwEsMqq64ixiQjciPumj9Eg3Rm5LFwXNDiUOxCw=; b=iqKh2fJqHJjv9TPtCli2C+6QEgx6wRZeBp+NUGCCCw2hXmdAVMibr8IwERBpQzmuVH 34tmUhA/o1H43sLKtymnQMhGaQ4cu9D5e5npV3pvJvIYqeSxQA7xfI6fiY84hElBfKUR fAvEr9GL4xQdZBg4E6ol6UOuknNFiE/1M8DZ3CFGM1CohE2RagyyS2BgKAR7BJi34rW3 CM3muInkwaTyaOPXfxg7rGiNAnriUQzMT/tNDBU8vDz1n+bZBDmGeNQgabSN4sensK9n tm56zA4OWmeQJXKOyhsWpbAbDNktzpOI8FkDXc/SdSFwcwdKyrwE1PYxJeGfnDiRpzLa 7akA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=mRwKWwEsMqq64ixiQjciPumj9Eg3Rm5LFwXNDiUOxCw=; b=XSyvfBk7pI4BBpOq+JF8xmdwjSfyMASU8JkGA2AX+8Ex41VdsF6gCtpusi0xU0sRZL jNC7dM255MQJr4pu8/+5EqQOBXuA2+JWIRVVYPGiqLf3a7FMHlrr/Q0JrRHZu2O6rsw4 5124rpJigGVHrIqXIn0S3WgAtetJprOId/CiaOxUiD+EUpcMl3hjfG9P/xE24citimdd qqF5JLlgZ3TtyUXBmf3IgBfws/JOeOOcWh0Bwo6asOCUUJZM57pnTqPHqhD+4hc7fmy0 vTulIyMGxz2p6WuyawVqi6v+Z8zgFGWOPFdGkSxXDO1okXa0okb2PKiR/yx1j7di68y0 CEqg==
X-Gm-Message-State: AHYfb5gTys25vhstVS4IHY+kxlfCRS3Dv3VQRpIPq1zPiHeHBDgjleNx UqTXGDwUFbLNbBvMIR4EspLJskfprQ==
X-Received: by 10.200.47.247 with SMTP id m52mr7483360qta.187.1502219983368; Tue, 08 Aug 2017 12:19:43 -0700 (PDT)
MIME-Version: 1.0
Sender: olga.kornievskaia@gmail.com
Received: by 10.12.186.148 with HTTP; Tue, 8 Aug 2017 12:19:42 -0700 (PDT)
In-Reply-To: <CAABAsM6rmrDU4BR6Ho7YFjjYA2amEkwuRGtzN537VXUZ-Eh-hg@mail.gmail.com>
References: <150215110527.12392.18161698955589691126.idtracker@ietfa.amsl.com> <2CA259E3-BD3A-482B-BFBF-3B90425AD3EA@primarydata.com> <CAN-5tyETNMCPVC5wJ-_77vM5+hVB+-uasd37kn+M=hoCeK6P7w@mail.gmail.com> <CAABAsM6rmrDU4BR6Ho7YFjjYA2amEkwuRGtzN537VXUZ-Eh-hg@mail.gmail.com>
From: Olga Kornievskaia <aglo@citi.umich.edu>
Date: Tue, 8 Aug 2017 15:19:42 -0400
X-Google-Sender-Auth: egQ8ru-hP0fhO1rPVkwf2w9IMpY
Message-ID: <CAN-5tyGw-gAtuRSQrbWxgtyO_dQhcVYNJ-6O-UXeC7wXt6H1oA@mail.gmail.com>
To: Trond Myklebust <trondmy@gmail.com>
Cc: Thomas Haynes <loghyr@primarydata.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/7R6elKOJUxVwnNUiQKzPRfldXww>
Subject: Re: [nfsv4] Fwd: New Version Notification for draft-haynes-nfsv4-flex-filesv2-00.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 19:19:47 -0000

For the client to authenticate to the server, it needs a service
ticket. A ticket carries a secret key encrypted with something known
only to the server. A client proves he knows the key inside the ticket
by encrypting a payload with that key (and presents the ticket as
well). KDC (MDS) encrypts that secret with something known only to KDC
and the client.

RPCSEC_GSS session handle is a number (allows to locate the real
crypto to use to decrypt the payload). It has no crypto, there is no
security there.

On Tue, Aug 8, 2017 at 2:54 PM, Trond Myklebust <trondmy@gmail.com> wrote:
> 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 <aglo@citi.umich.edu> 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 <loghyr@primarydata.com>
>> 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: <internet-drafts@ietf.org>
>> > 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 <thomas.haynes@primarydata.com>
>> >
>> >
>> > 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
>> > nfsv4@ietf.org
>> > https://www.ietf.org/mailman/listinfo/nfsv4
>> >
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
>