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

Olga Kornievskaia <aglo@citi.umich.edu> Tue, 08 August 2017 20:52 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 272FE1327D3 for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 13:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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] 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 yeQJ1zLBD0Og for <nfsv4@ietfa.amsl.com>; Tue, 8 Aug 2017 13:52:02 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 CF57913219D for <nfsv4@ietf.org>; Tue, 8 Aug 2017 13:52:01 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id t37so26213009qtg.5 for <nfsv4@ietf.org>; Tue, 08 Aug 2017 13:52:01 -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; bh=HRyViUZzCtl8kCxJ5ePzXGX8hdxTFOnDH39qSGdt/1M=; b=ltehrwROvsKdikAZkWxkOw1kGXAasp6hsA3JzTyTXkykBV1Q2NYPpVdHp/v99wHBPF AOpDRBL1a6DzdQS9+ZNsHTIpG8GTEkhBVETZB7AYw94cJSZ5Ch1IbdJ5eZU5PtOE6aY7 0+My+Tnd/8l0ZRkkPHDmzt38vNzCX7n2/vEg+XcqMha3HsUMqZYKYhwz3g/PG7AzYwtY nxWvKuZ+tXQ77zWasav8JHTfkvUEaF3fJZDmPp2/yQJ8TaQVWusA50b6DAiFkcHU55mt I3f3TqpNTjsUwmn5q/C/2K2IqJJ+Bh9c95mq6Hs8nw+PiKV47tqdStv8lrX3zs0iY4mc ofHQ==
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; bh=HRyViUZzCtl8kCxJ5ePzXGX8hdxTFOnDH39qSGdt/1M=; b=Gd/6Y17jLiJ3LWV8eX3U+AoMqxpHrtIYIkMaYdP/s8YciiajrkJkp8PvxKW4wr+F4u /7coks1mgRhwHueBkM03IZ8Rl2PS+jwqiZksEGi1CUGFgblvCT1dJNtkIgYZq78+pwhK 2FwsU9wSVo5Dg6KQ9X8NbTggZGbLFK0JVfaj64NUoXbxsFQ6pXrVTh/26xtZTtPFLKa3 u818PZt6lylmQOWOJ2dO0D7x0/W9HyZF0HTE+9ebxtKvQnb4y/gBrx6XelRCpxNKIOHQ yqfCpaKKpi7MLyAv35tHK3fuMfCBCdUM9+np0vniPzbLWAP1tHaCdcwV/pKYJaq31yaE DaHA==
X-Gm-Message-State: AHYfb5jrd2KOrJj8qW/B7trjU+7DKmum1TNoYCI1qCsCeyTAK91QtbVm A/Eqtz5dBbZ1H0NQAWHnHtSHRXHkYw==
X-Received: by 10.237.43.197 with SMTP id e63mr7688815qtd.86.1502225520689; Tue, 08 Aug 2017 13:52:00 -0700 (PDT)
MIME-Version: 1.0
Sender: olga.kornievskaia@gmail.com
Received: by 10.12.186.148 with HTTP; Tue, 8 Aug 2017 13:51:59 -0700 (PDT)
In-Reply-To: <20170808203145.GS70977@kduck.kaduk.org>
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> <20170808185803.GQ70977@kduck.kaduk.org> <CAABAsM7xOpbopPa3v1YMtfcFZbNZ=Jygap37Bg6qGfDDAvRHhQ@mail.gmail.com> <CAN-5tyHz1cqSWyv1hVMvzaqSr1W0V0_drz3BvzxHWDyM5w+spw@mail.gmail.com> <20170808203145.GS70977@kduck.kaduk.org>
From: Olga Kornievskaia <aglo@citi.umich.edu>
Date: Tue, 08 Aug 2017 16:51:59 -0400
X-Google-Sender-Auth: 25IdQvzXiVOKmeLtFUQ2Yrz3dz8
Message-ID: <CAN-5tyHR80V1Fi3GZJ5u=FsxQ5va=Ka2qTCmHZ48PikURYjwGw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Trond Myklebust <trondmy@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>, Thomas Haynes <loghyr@primarydata.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/QZvfGcB81uNOUnJAmGlU4eqDDzM>
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 20:52:03 -0000

On Tue, Aug 8, 2017 at 4:31 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Tue, Aug 08, 2017 at 04:05:35PM -0400, Olga Kornievskaia wrote:
>> On Tue, Aug 8, 2017 at 3:37 PM, Trond Myklebust <trondmy@gmail.com> wrote:
>> >
>> >
>> > On 8 August 2017 at 14:58, Benjamin Kaduk <kaduk@mit.edu> wrote:
>> >>
>> >> On Tue, Aug 08, 2017 at 02:54:58PM -0400, Trond Myklebust wrote:
>> >> > Why pass Kerberos tickets around? Is there any reason not to just pass
>> >> > an
>> >> > initialised RPCSEC_GSS session handle?
>> >>
>> >> There's not a standard serialization of the GSS security context object
>> >> that it contains, for transfer across the network.
>> >
>> >
>> > I thought rfc1964 provides one, which is pretty much the basis for the user
>> > library gss_krb5_lucid_context_v1_t typedef. Am I mistaken?
>>
>> We have the case of chicken before the egg problem here.
>>
>> Client has to send an AP_REQ to the server. He needs a ticket for
>> that. after the gss dance with the data server gss_krb5_lucid_context
>> is created.
>
> I think the proposal is that the MDS would send the AP_REQ, and generate a lucid
> context to send to the client.  If the MDS also sends the RPCSEC handle,
> the data server ought to be able to associate that with the same GSS security
> context established by the MDS and handle RPCs from the client, even
> though the peer's network address (as seen by the data server) has changed from
> being the MDS to being the client.

Would an unmodified NFS server allow for this? Bruce might have better
idea. I don't think the server would accept "continued" gss sequence
on a new connection without going thru the gss dance.

What about the fact that it is possible that some NFS server might set
a rather short gss context lifetimes? The client would not be able to
renegotiate the new context to process with doing the IO. What happens
when the server reboots during the IO? It will lose the security
context and client is force to go to MDS every time?