Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07
Chuck Lever <chuck.lever@oracle.com> Mon, 25 May 2020 15:34 UTC
Return-Path: <chuck.lever@oracle.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 E92D13A0D41; Mon, 25 May 2020 08:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.091
X-Spam-Level:
X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 jEGX4UuD2346; Mon, 25 May 2020 08:34:04 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF423A0D3F; Mon, 25 May 2020 08:34:04 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04PFVriS086093; Mon, 25 May 2020 15:33:49 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2020-01-29; bh=vG+UAjsKRPUwK/h+bTM4JLupRKRKj3o+ue4gu7ieyS0=; b=I40KFIWTcrVX65QnceniXVuZRGQJ4LAd6bSL7hac5GLTg1hrCU+mbA8GHhkCRUY85lEY qABes6r6yyVQVJ9qMlXIAsrucslnZkiJjhMS8hBdmrqtr80xjfG/z75p+evtWYrs71l6 3cfnYSMMUb65xcwQCKoaL0bNubt+pUsBacWnLr8JnMx445PZTybZaCo0DYnyQVoaTfO9 vsQpsTh37N1VNF85/wB/Aqvi8cJoXd8EZE6h+dpEKa8ZVSw884jhhLyquTn1eCaus//l 1Pk6MFqyOes7pirz1PRCom+IJeZexSCuc+SvpliIdKweW4nYNwEf/PfUWBPI+QYb2nPB Tw==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 316vfn5x6a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 May 2020 15:33:49 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 04PFThBD155141; Mon, 25 May 2020 15:33:48 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 317j5jgrem-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 May 2020 15:33:48 +0000
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 04PFXiYE011488; Mon, 25 May 2020 15:33:45 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 May 2020 08:33:44 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <4023079b7f3a826c163ad35ee00c4bcffb8b2d56.camel@hammerspace.com>
Date: Mon, 25 May 2020 11:33:42 -0400
Cc: David Noveck <davenoveck@gmail.com>, "worley@ariadne.com" <worley@ariadne.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-nfsv4-rpc-tls.all@ietf.org" <draft-ietf-nfsv4-rpc-tls.all@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2FD9B8E-12B4-453F-B7E3-1EA733617397@oracle.com>
References: <159035343255.29687.817580247496478154@ietfa.amsl.com> <9DE0A0E7-46BB-4C4F-9AFC-D7BD0645A0A7@oracle.com> <CADaq8jcqKB8KMFL2=LqL_g64Wm6TWZJad-qq_bW0vxo7Joq0LA@mail.gmail.com> <4023079b7f3a826c163ad35ee00c4bcffb8b2d56.camel@hammerspace.com>
To: Trond Myklebust <trondmy@hammerspace.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9632 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005250121
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9632 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 clxscore=1015 priorityscore=1501 mlxscore=0 malwarescore=0 spamscore=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 adultscore=0 suspectscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005250121
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/GJep3Sozv8lwkWr8qyOEABJHJkc>
Subject: Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07
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, 25 May 2020 15:34:10 -0000
Hi Trond- > On May 25, 2020, at 8:04 AM, Trond Myklebust <trondmy@hammerspace.com> wrote: > > On Mon, 2020-05-25 at 07:46 -0400, David Noveck wrote: >> > There doesn't seem to be any adequate explanation for backchannel >> > operation in documents prior to RFC 8167, which explains reverse- >> > direction RPC operation over an RDMA transport. >> >> The term is introduced in RFC5661. Not sure what you consider an adequate explanation, but this would be a relevant reference that also might be cited. >> >> > Perhaps the best I can do here is add a paragraph introducing the >> > concept, and use the RFC 8167 terminology instead of >> > "backchannel"? >> >> This concept does need to be introduced at the RPC-level and rpc-tls, which is to update RFC5531, is a good place to do it. I think it would be best to explain the connections between the RFC5661 and RFC8167 terminologies >> Let me review RFC 8167 and see if I can reference it sensibly in >> the context of RPC on TCP. > > There really is no mention in RFC5531 of RPC being unidirectional either. It does describe a client-server model, but imposes no limitations on the number of services a single transport can support, or on directionality of the calls. Ultimately, the only special thing about a backchannel is that it is a service on one side of the transport that is associated with a different service on the other side of the channel. > > Is that really a nuance that needs to be explained in this document? We've already determined the TLS behaviour when a transport supports multiple services. True. The discussion of reverse-direction operation here is implementation advice rather than the statement of more compliance rules. I added this paragraph because it feels valuable to point out this very fact: reverse-direction operation is not an exception to the "multiple services on a connection" rule. I believe that as a putative implementer I would appreciate seeing this statement in clear black-and-white letters. We are likely to get asked for clarification -- or worse, have to deal with improper implementations -- without this statement. >> On Sun, May 24, 2020 at 5:58 PM Chuck Lever <chuck.lever@oracle.com> wrote: >>> >>> >>> > On May 24, 2020, at 4:50 PM, Dale Worley via Datatracker <noreply@ietf.org> wrote: >>> > >>> > Reviewer: Dale Worley >>> > Review result: Ready with Nits >>> > >>> > I am the assigned Gen-ART reviewer for this draft. The General Area >>> > Review Team (Gen-ART) reviews all IETF documents being processed >>> > by the IESG for the IETF Chair. Please treat these comments just >>> > like any other last call comments. >>> > >>> > For more information, please see the FAQ at >>> > >>> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >>> > >>> > Document: draft-ietf-nfsv4-rpc-tls-07 >>> > Reviewer: Dale R. Worley >>> > Review Date: 2020-05-24 >>> > IETF LC End Date: 2020-05-27 >>> > IESG Telechat date: unknown >>> > >>> > Summary: >>> > >>> > Note that I am not familiar with the operations of TLS, so I have not >>> > reviewed issues that are specific to security implementations. I >>> > assume the SECDIR review has adequately covered those. >>> > >>> > This draft is quite solid and nearly ready for publication, but has >>> > nits that should be fixed before publication. >>> >>> Thank you, Dale, for the detailed feedback. I will reply to this >>> e-mail thread with specific text corrections in the next few days. >>> >>> I do have a few initial reactions/follow-ups for you that appear >>> inline below. >>> >>> >>> > Nits: >>> > >>> > 4.1. Discovering Server-side TLS Support >>> > >>> > Somewhere in this section you need to specify the semi-obvious: >>> > >>> > In principle, RPC is transport-agnostic. In the context of >>> > RPC-Over-TLS, the initial request MUST be sent using either TCP or >>> > UDP. If an initial TCP request is successful, a TLS connection is >>> > established. If an initial UDP request is successful, a DTLS >>> > association is established. >>> >>> I can add something like this in Section 4.1, but note that Sections >>> 5.1.1 and 5.1.2 already explain the relationships between TCP/UDP >>> and TLS/DTLS, respectively. >>> >>> >>> > 5.1.1. Protected Operation on TCP >>> > >>> > The server does not attempt to establish a TLS session >>> > on a TCP connection for backchannel operation. >>> > >>> > I think "... does not attempt to establish a separate TLS session ..." >>> > is clearer. >>> > >>> > I can't find any discussion of "backchannel operation" in RFC 5531. >>> > Might this need an additional reference? >>> >>> I agree that a deeper introduction of "backchannel operation" would >>> be helpful in this section. >>> >>> There doesn't seem to be any adequate explanation for backchannel >>> operation in documents prior to RFC 8167, which explains reverse- >>> direction RPC operation over an RDMA transport. >>> >>> Perhaps the best I can do here is add a paragraph introducing the >>> concept, and use the RFC 8167 terminology instead of "backchannel"? >>> Let me review RFC 8167 and see if I can reference it sensibly in >>> the context of RPC on TCP. >>> >>> >>> > 5.2.1. X.509 Certificates Using PKIX trust >>> > >>> > o For services accessed by their network identifiers (netids) and >>> > universal network addresses (uaddr), the iPAddress subjectAltName >>> > SHOULD be present in the certificate and must exactly match the >>> > address represented by universal address. >>> > >>> > I suspect that "iPAddress" is not capitalized correctly. >>> >>> This is the capitalization used in RFC 6125, which is cited nearby >>> this text. >>> >>> >>> -- >>> Chuck Lever >>> >>> >>> > -- > Trond Myklebust > CTO, Hammerspace Inc > 4984 El Camino Real, Suite 208 > Los Altos, CA 94022 > <Hammerspace-email.png> > www.hammer.space > -- Chuck Lever
- [nfsv4] Genart last call review of draft-ietf-nfs… Dale Worley via Datatracker
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… David Noveck
- Re: [nfsv4] Genart last call review of draft-ietf… Trond Myklebust
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… worley
- Re: [nfsv4] Genart last call review of draft-ietf… worley
- Re: [nfsv4] Genart last call review of draft-ietf… worley
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… worley
- Re: [nfsv4] Genart last call review of draft-ietf… Chuck Lever
- Re: [nfsv4] Genart last call review of draft-ietf… worley
- Re: [nfsv4] [Gen-art] Genart last call review of … Alissa Cooper