Return-Path: 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 96DE33A09AE; Mon, 25 May 2020 04:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 grx1JtqhhU_1; Mon, 25 May 2020 04:46:35 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 E2F053A0889; Mon, 25 May 2020 04:46:34 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id n24so20194689ejd.0; Mon, 25 May 2020 04:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MFNVfondsVyZqsXoS5XgfZpTWJoDErBUQ+D4iyQOTMs=; b=NixkwktNsA1xGNsBkZmYd53DIPno9diGEAEQSXT9NdaN+SlFOteMn/gm8vjAMFACFK i/16M+9MPEnuPSXFmGk7/eNyhlMYwaSrkrfcieLMNqJpCoDyARWIsMgkBsK9lSQkJIe6 mj+SnqA6FDdKlsCIOxMoTCJfaPkr8ZXzhZKrrRHWUHeEQEZSgJ9WqpM07z4DaEhhwCYH YM72Aw2l9n5BF3d7wYlBtInU0XUbipROo71qpsMesZoSPta4GhBe2UqR1W1X5biUhLjO hZFg+Y/qKJBuCiKwfJuWI7uQo8mWaM7D7x19vhjWBdkjCiMNhDGwRVj8bkMReVNMuEMU KTGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MFNVfondsVyZqsXoS5XgfZpTWJoDErBUQ+D4iyQOTMs=; b=BE8dLh4n6CSvzTcGGIPLCRe/ah4Jnm95gZlpDG/1Y4Jo0QjITVKXgYW7O1zZWojjzb jxxVbOBdCrUAM5ZcyS9Vo0RTZLmpMTaYsgrVlJ35mfU30TQZNv16NgKoq0+pS6dJSSex ONUBTW7wuzt+7Wj02ZQp71+VOXNdicHr5lQ8C8tu7FkF38xR7Q9Ryq39GEJOBYC/XxaC WPH2+BjZ2zABxELW3CnGBK5793Sb4F6UC76RyKHSjK9yaEXwe9Z0TyTeJbeQ2ImPXeEC 83RxFpuOSpntErfdw/pQgD3kyIyamjZJsaZ6TOKPbATN06zVfyo8FI6wD6D85QOu3MHr ig2g== X-Gm-Message-State: AOAM530b/ICCEW70Tw+8fbFVHBex3URB2CThHvkiIQFyacKPk5kvdMjK Q3XM7EXNjGyv3+Rvd9e+gEQL6kBxfe1ikkmZHnA= X-Google-Smtp-Source: ABdhPJyIb05eIXXa7LFPaIPPfvfCHkil63T3aVRT7Jdb9ak5opq+gPXv8t0bBPVAQAw1LDBwZdlbIVoSw15dnsbzSSU= X-Received: by 2002:a17:906:934e:: with SMTP id p14mr18431958ejw.498.1590407192760; Mon, 25 May 2020 04:46:32 -0700 (PDT) MIME-Version: 1.0 References: <159035343255.29687.817580247496478154@ietfa.amsl.com> <9DE0A0E7-46BB-4C4F-9AFC-D7BD0645A0A7@oracle.com> In-Reply-To: <9DE0A0E7-46BB-4C4F-9AFC-D7BD0645A0A7@oracle.com> From: David Noveck Date: Mon, 25 May 2020 07:46:21 -0400 Message-ID: To: Chuck Lever Cc: Dale Worley , "gen-art >> General area reviewing team" , last-call@ietf.org, NFSv4 , draft-ietf-nfsv4-rpc-tls.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5d56c05a677872e" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 11:46:38 -0000 --000000000000c5d56c05a677872e Content-Type: text/plain; charset="UTF-8" > 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. On Sun, May 24, 2020 at 5:58 PM Chuck Lever 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 > > > > . > > > > 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 > > > > --000000000000c5d56c05a677872e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> There doesn't seem to be any adequate explanation= for backchannel
> operation in documents prior to RFC 8167, which ex= plains reverse-
> direction RPC operation over an RDMA transport.
=
The term is introduced in RFC5661.=C2=A0 =C2=A0Not sure what you consid= er an adequate explanation, but this would be a relevant reference that als= o might be cited.

> Perhaps the best I can do here is add a parag= raph introducing the
> concept, and use the RFC 8167 terminology inst= ead of=C2=A0
> "backchannel"?

Thi= s concept does need to be introduced at the RPC-level and rpc-tls, which is= to update RFC5531, is=C2=A0a=C2=A0good place to do it.=C2=A0 =C2=A0I think= =C2=A0it would be best to explain the connections between the RFC5661 and R= FC8167 terminologies
Let me review RFC 8167 and see if I can reference i= t sensibly in
the context of RPC on TCP.=C2=A0=C2=A0

=
On Sun, Ma= y 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> wro= te:
>
> 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.=C2=A0 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<= /a>>.
>
> Document:=C2=A0 draft-ietf-nfsv4-rpc-tls-07
> Reviewer:=C2=A0 Dale R. Worley
> Review Date:=C2=A0 2020-05-24
> IETF LC End Date:=C2=A0 2020-05-27
> IESG Telechat date:=C2=A0 unknown
>
> Summary:
>
> Note that I am not familiar with the operations of TLS, so I have not<= br> > reviewed issues that are specific to security implementations.=C2=A0 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.=C2=A0 Discovering Server-side TLS Support
>
> Somewhere in this section you need to specify the semi-obvious:
>
>=C2=A0 =C2=A0In principle, RPC is transport-agnostic.=C2=A0 In the cont= ext of
>=C2=A0 =C2=A0RPC-Over-TLS, the initial request MUST be sent using eithe= r TCP or
>=C2=A0 =C2=A0UDP.=C2=A0 If an initial TCP request is successful, a TLS = connection is
>=C2=A0 =C2=A0established.=C2=A0 If an initial UDP request is successful= , a DTLS
>=C2=A0 =C2=A0association 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.=C2=A0 Protected Operation on TCP
>
>=C2=A0 =C2=A0The server does not attempt to establish a TLS session
>=C2=A0 =C2=A0on 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" i= n RFC 5531.
> Might this need an additional reference?

I agree that a deeper introduction of "backchannel operation" wou= ld
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.=C2=A0 X.509 Certificates Using PKIX trust
>
>=C2=A0 =C2=A0o=C2=A0 For services accessed by their network identifiers= (netids) and
>=C2=A0 =C2=A0 =C2=A0 universal network addresses (uaddr), the iPAddress= subjectAltName
>=C2=A0 =C2=A0 =C2=A0 SHOULD be present in the certificate and must exac= tly match the
>=C2=A0 =C2=A0 =C2=A0 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



--000000000000c5d56c05a677872e--