Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

[Chuck Lever <[e-mail]>]

> On Apr 16, 2019, at 9:39 AM, David Noveck <[e-mail]> wrote:
> 
> > Does this document need to say anything specific about reverse-direction
> > RPC operations? 
> 
> I don't think it needs to, but there are certainly los of reasons we would want it
> to.   The issue that needs to be resolved is that this is a document that is not 
> specfic to NFSv4, but is RPC-generic.   If we don't want to change that right now,
> and it would be disruptive, we made need another document about NFv4-specific
> considerations about use of rpc-tls.
> 
> > (i.e., 
> 
> In this document, it would have to be "e.g."
> 
> > NFSv4.1 callbacks on the same communication channel)  
> 
> In this document, I'm not sure it is worth bothering with.

Well, let's set aside the parenthetical for a moment.

At one point, Tigran said this:

> But what sould be part of your document is the handling of TLS session
> termination. Something like (please make it rfc language compliant):
> 
> 
>   Client can terminate the TLS session after sending a TLS closure alert.
>   After TLS session termination any other RPC requests over the same connection
>   will fail with AUTH_ERROR.


I think what is intended is that all traffic on that connection,
after the TLS session is established, should be encapsulated and
protected, until the TLS session is terminated.

What I'm wondering is whether it needs to be made explicit that
this would include reverse direction operations. Unlike GSS,
which provides per-request encapsulation, meaning that each
request can use its own security flavor.

TLS is transport-level. We might want to stipulate that operations
in both directions MUST be sent using the negotiated TLS session.


--
Chuck Lever