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

[Chuck Lever <[e-mail]>]

> On Apr 21, 2019, at 7:47 AM, David Noveck <[e-mail]> wrote:
> 
> > 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.
> 
> I think it would be helpful if it did make that explicit.  Given that
> this is a RPC-generic document, v4.1, the only current user of
> reverse direction RPC, would need to referenced, informatively, 
> as an example.
> 
> > TLS is transport-level. We might want to stipulate that operations
> > in both directions MUST be sent using the negotiated TLS session 
> 
> I don;t think you can do that.   In the case of trunking, there will be
> multiple connections and multiple sessions.   Anything related to 
> trunking would need to be in an v4-focused document.

I meant "operations in both directions on the same transport connection".


> Another thing that would need to be in a v4-focused document iS
> material related to v4.0 callbacks  in which there would potentially
> be multiple connections and thus multiple TLS sessions. 
> 
> On Thu, Apr 18, 2019 at 7:15 PM Chuck Lever <[e-mail]> wrote:
> 
> 
> > 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
> 
> 
> 

--
Chuck Lever