Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07

[David Noveck <[e-mail]>]

> 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 <[e-mail]> wrote:

>
>
> > On May 24, 2020, at 4:50 PM, Dale Worley via Datatracker <
> [e-mail]> 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
>
>
>
>