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

[Chuck Lever <[e-mail]>]

Hi Trond-

> On May 25, 2020, at 8:04 AM, Trond Myklebust <[e-mail]> 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 <[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
>>> 
>>> 
>>> 
>  -- 
> Trond Myklebust
> CTO, Hammerspace Inc
> 4984 El Camino Real, Suite 208
> Los Altos, CA 94022
> <Hammerspace-email.png>
> www.hammer.space
> 

--
Chuck Lever