Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

"Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de> Mon, 08 April 2019 15:53 UTC

Return-Path: <tigran.mkrtchyan@desy.de>
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 D4E3A12043C for <nfsv4@ietfa.amsl.com>; Mon, 8 Apr 2019 08:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HK_RANDOM_ENVFROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=desy.de
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 HAtF8zP0I2ov for <nfsv4@ietfa.amsl.com>; Mon, 8 Apr 2019 08:53:45 -0700 (PDT)
Received: from smtp-o-2.desy.de (smtp-o-2.desy.de [131.169.56.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCE71203EB for <nfsv4@ietf.org>; Mon, 8 Apr 2019 08:53:44 -0700 (PDT)
Received: from smtp-buf-2.desy.de (smtp-buf-2.desy.de [IPv6:2001:638:700:1038::1:a5]) by smtp-o-2.desy.de (Postfix) with ESMTP id D2403160169 for <nfsv4@ietf.org>; Mon, 8 Apr 2019 17:53:41 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp-o-2.desy.de D2403160169
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=desy.de; s=default; t=1554738821; bh=a5f2f8BcacISiUAQa1TBj4eI0/cR1Q0OcHLj1DPxK+w=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ocm3ssq+fwdpkfYh8qhuI30xeVZYURFS5ssEQRY1TXKAdDhfYZAIDhOwQAzes2sbJ 4RC+SYjjgiZYNjPPoj0edDrue+yOgghW57JutIfdPT0R6uQ9GXpaLR9TvDXFu0bFrz //+9jC6xNQDqaXnbGHJEsQmGU2d11Rr7w7PudUW0=
Received: from smtp-m-2.desy.de (smtp-m-2.desy.de [131.169.56.130]) by smtp-buf-2.desy.de (Postfix) with ESMTP id CB62F1A00B9; Mon, 8 Apr 2019 17:53:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at desy.de
Received: from z-mbx-2.desy.de (z-mbx-2.desy.de [131.169.55.140]) by smtp-intra-1.desy.de (DESY-INTRA-1) with ESMTP id 8F9723E901; Mon, 8 Apr 2019 17:53:41 +0200 (MEST)
Date: Mon, 08 Apr 2019 17:53:41 +0200
From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <1623176801.3604116.1554738821387.JavaMail.zimbra@desy.de>
In-Reply-To: <20190406032253.GK70202@kduck.mit.edu>
References: <154264272736.5235.8955444239583271708.idtracker@ietfa.amsl.com> <CAN-5tyFAJ6fN6GHz8Ecr3i6aQV+wGqvbdStqxruMs6Pw+Dppaw@mail.gmail.com> <A9AF8062-B9FC-425D-9E50-FC890065BBE1@oracle.com> <916629036.2643205.1554327076610.JavaMail.zimbra@desy.de> <6183F452-B7AC-4925-A6A8-472FB1FBF9C5@oracle.com> <2054230647.2997716.1554407541660.JavaMail.zimbra@desy.de> <774FFC90-BC12-403B-8CBA-4D702AA7EBF5@oracle.com> <20190406032253.GK70202@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Zimbra 8.8.10_GA_3781 (ZimbraWebClient - FF66 (Linux)/8.8.10_GA_3786)
Thread-Topic: New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
Thread-Index: ogs2q9AWfTWDBvaDLf6qlesLkDObHw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/_410pQOfR_GpnjuFrAQxcCFm44w>
Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 08 Apr 2019 15:53:55 -0000


Some performance numbers on Dell PowerEdge R510 E5645 2.40GHz, TCP, single client
single server over localhost sending op NULL:

Benchmark               (withTLS)   Mode  Cnt      Score     Error  Units
TlsOverhead.callOpNull       true  thrpt   25  12865.357 ± 135.963  ops/s
TlsOverhead.callOpNull      false  thrpt   25  12802.179 ± 156.782  ops/s

Looks like TLS overhead is ~0.5%. For each mode (with and without TLS) a 25 iterations of runs was performed.
Each each iteration was running for 10 seconds and calling op null in a loop.

Regards,
   Tigran.

----- Original Message -----
> From: "Benjamin Kaduk" <kaduk@mit.edu>
> To: "Chuck Lever" <chuck.lever@oracle.com>
> Cc: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>, "NFSv4" <nfsv4@ietf.org>
> Sent: Saturday, April 6, 2019 5:22:54 AM
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

> On Fri, Apr 05, 2019 at 10:35:39AM -0400, Chuck Lever wrote:
>> 
>> 
>> > On Apr 4, 2019, at 3:52 PM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
>> > 
>> > Hi Chuck,
>> > 
>> > ----- Original Message -----
>> >> From: "Chuck Lever" <chuck.lever@oracle.com>
>> >> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
>> >> Cc: "NFSv4" <nfsv4@ietf.org>
>> >> Sent: Thursday, April 4, 2019 4:32:55 PM
>> >> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
>> > 
>> >> Hi Tigran-
>> >> 
>> >>> On Apr 3, 2019, at 5:31 PM, Mkrtchyan, Tigran <tigran.mkrtchyan@desy.de> wrote:
>> >>> 
>> >>>>>>> 3. Section 4.2.3 "Advanced forms of RPC authentication". I'm surprised
>> >>>>>>> to see this here because of the wording in Section 1. Specifically it
>> >>>>>>> says: "An alternative approach is to employ transport layer security
>> >>>>>>> mechanism". Here alternative was to the GSS mechanism which was listed
>> >>>>>>> as "hard to use". So nowhere was there a talk that TLS connection can
>> >>>>>>> be used with a GSS mechanism. Is this section suppose to be about the
>> >>>>>>> fact that RPCSEC GSS besides authentication also provides an encrypted
>> >>>>>>> connection? Then I think the section title should be changed to
>> >>>>>>> "RPCSEC GSS secure connection establishment"?   This section,blurs the
>> >>>>>>> lines of RPC identify authentication via GSS identities and the TLS
>> >>>>>>> authentication. In previous two section, it wasn't discussed what kind
>> >>>>>>> of RPC authentication would happen on top of the TLS connection. I
>> >>>>>>> think this whole section should be removed. Because it basically says
>> >>>>>>> there is no need to use GSS privacy/integrity since underlying TLS
>> >>>>>>> connection already provides that and since TLS is suppose to be
>> >>>>>>> alternative to GSS so why combined it.
>> >>>>>> 
>> >>>>>> We have to discuss the use of channel binding somewhere, and
>> >>>>>> we have to discuss the double host authentication because TLS
>> >>>>>> has a host authentication step and so does GSS. I don't see any
>> >>>>>> discussion of user authentication here.
>> >>>>> 
>> >>>>> I would have re-organized this to be something like:
>> >>>>> 
>> >>>>> 4.2 Establishing an end-to-end encrypted channel
>> >>>>> same paragraph as before about providing a transparent end-to-end
>> >>>>> encrypted channel for the RPC operations.
>> >>>>> 4.2.1 TLS server-only authentication
>> >>>>> (same as before)
>> >>>>> 4.2.2 TLS mutual authentication
>> >>>>> (same as before)
>> >>>>> 4.3.3 Role of the RPCSEC GSS integrity and privacy services
>> >>>>> Here talk about redundancy of using GSS services on top of TLS.
>> >>>>> Channel binding would go here.
>> >>>>> 
>> >>>>> 4.3 RPC authentication on top of an encrypted channel
>> >>>>> Here talk about how any of the existing methods (AUTH_SYS, GSS) can be
>> >>>>> overplayed on top of the encrypted channel.
>> >>>> 
>> >>>> I'm not sure this warrants its own subsection. I'll look into
>> >>>> explicitly stating that RPC user authentication is not altered
>> >>>> by transport encryption earlier in Section 4.
>> >>>> 
>> >>>> Hopefully the new language will not forbid someday specifying
>> >>>> user authentication via certificates. For now I would like to
>> >>>> keep this document narrowly focused on providing transport
>> >>>> encryption.
>> >>> 
>> >>> In GRID computing, dealing with end-user certificates is the main
>> >>> reason why we try to move away from X509. Proxy certificates
>> >>> with limited life time to pass around with, LDAP configs,
>> >>> renewal, trusted CA distribution, CRLS, legal requirements to
>> >>> present ID-card to get a certificate in the first place...
>> >>> However, RPC is not only NFS. We have accelerator control systems,
>> >>> that use AUTH_NONE with IP table rules.
>> >> 
>> >> Indeed, this is a use case that is interesting to me as well.
>> >> In cases where a transient cloud service is spun up that has
>> >> no local user identities, AUTH_NONE would be appropriate to
>> >> use.
>> >> 
>> >> 
>> >>> And, in general, many
>> >>> server-to-server RPC based communication will benefit from
>> >>> client+server mutual authentication. For example pNFS deployment,
>> >>> where DSes talk to MDS and both want to be sure that the other
>> >>> side is the right one.
>> >> 
>> >> This sounds like what Trond is most interested in.
>> >> 
>> > 
>> > With a deployment dedicated CA it's an easy way to
>> > control which hosts belongs to the instance. We do
>> > it for our internal message communication.
>> > 
>> >> 
>> >>> IOW, don't require it, but keep it possible.
>> >> 
>> >> I'm not sure exactly what you would like to see.
>> >> 
>> >> - The option to use user certificates for host authentication
>> >> specified in this document.
>> >> 
>> >> - The option to use user certificates for host authentication
>> >> left open for a future specification.
>> >> 
>> >> - The option to use user certificates for user authentication
>> >> specified in this document.
>> >> 
>> >> - The option to use user certificates for user authentication
>> >> left open for a future specification.
>> >> 
>> > 
>> > 
>> > Let's have a look and HTTP-over-TLS (rfc2818). No special requirement
>> > for client authentication. The TLS spec (rfc8446) says:
>> > 
>> >   4.3.2.  Certificate Request
>> > 
>> >      A server which is authenticating with a certificate MAY optionally
>> >     request a certificate from the client.
>> > 
>> > The combination of it I read as: server configuration controls is client
>> > certificate requested or not. Thus, leave it to TLS configuration.
>> > 
>> > But what should be part of your document is the handling of TLS session
>> > termination. Something like (please make it rfc language compliant):
>> 
>> Makes sense. Questions below:
>> 
>> 
>> >   Client can terminate the TLS session after sending a TLS closure alert.
>> 
>> What if a client closes the connection without terminating
>> the TLS session?
> 
> Indeed, close_notify is basically unusable in the web world due to clients
> just doing this.
> 
>> 
>> >   After TLS session termination any other RPC requests over the same connection
>> >   will fail with AUTH_ERROR.
>> 
>> What about UDP with DTLS?
> 
> (There's not a reliable way to do so.)
> 
> -Ben