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

[Chuck Lever <[e-mail]>]

Hi David-

> On May 25, 2020, at 7:46 AM, David Noveck <[e-mail]> 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.

I'm not comfortable citing an NFSv4 document to define a term used in
a document that discusses a generic RPC transport. To me that feels an
awful lot like a layering violation.

Moreover, after reviewing Section 2.10.3.1 of RFC 5661, the introduction
of the idea of "channel" does not require that backchannel operation
take place on the same connection with forward channel operation. Thus
"backchannel" does not seem to be precisely the terminology we want in
rpc-tls, where we are discussing specifically multiple services on one
connection, without any association to a particular Upper Layer RPC
consumer.


> > 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.

The language in RFC 8167 has already been vetted by the IESG. We have
that definition now in a citable public document, so we should use that
rather than duplicating it.

Note that RFC 8167 Section 2 has a complete definition of this mode of
operation. In rpc-tls, such an extended discussion would be a distract-
ing sidebar, especially since the paragraph in question is not making
any normative addition to the RPC-on-TLS protocol.

Also I should point out that given the post-WGLC phase we are in, adding
significant and possibly normative new text to this document is probably
not appropriate.


> I think it would be best to explain the connections between the RFC5661
> and RFC8167 terminologies

I agree philosophically with that. However, rfc5661bis seems to me like
the more relevant and appropriate place to make such connections.

In rpc-tls, I'd rather replace the term "backchannel" with "reverse-
direction operation" plus a citation.


> 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
> 
> 
> 

--
Chuck Lever