Re: [nfsv4] AD review of draft-ietf-nfsv4-rpc-tls

[Chuck Lever <[e-mail]>]

> On Apr 9, 2020, at 4:53 PM, David Noveck <[e-mail]> wrote:
> 
> >Therefore with RPC-on-TLS we do not allow multiple RPC programs to share
> > a TLS session. And we do not allow multiple RPC-on-TLS sessions per TCP
> > connection.
> 
> That was my impression reading the document.  However, as you point out, the
> document never clearly atated that. 
> 
> > For DTLS, the STARTTLS probe has to be done for each RPC program on each
> > server. Only that one RPC program can use the established DTLS session.
> 
> OK with me.
> 
> > This means RPC-on-TLS robs us of some TCP connection sharing opportunities.
> 
> I'm unaware of any actual use of these opportunities, in the absence of RPC-TLS .  If there
> is little use of these, than the deprivation of sharing opportunities is purely formal.

The particular use case is that both the Linux and Solaris NFSv3
implementations use the same connection for NFS and NFSACL traffic,
which are two distinct RPC programs.

It's an ongoing concern for NFS clients that use privileged source
ports to conserve the number of connections they make to a
particular server.

Not a problem for NFSv4, or NFS with Kerberos which can use an
ephemeral source port without any consequences. We could probably
even stipulate in an NFS-on-TLS or NFS security document that an
NFS server should not require a privileged source port, but that's
a rat hole.


> > Is there consensus on this, or should these design points be revisited? 
> 
> I'd prefer not but we need to give working group members who feel differently, the
> opportunity to raise their concerns.

+1


> if there is no objection, why don't you include
> explicit langusge about your non-sharing model in the next revision and the
> working group discssion of the chamges in that document will serve as the basis
> for determining whether we have a continued onsensus on those point.    

Excellent suggestion, I will do that.


> On Thu, Apr 9, 2020 at 3:28 PM Chuck Lever <[e-mail]> wrote:
> 
> > On Apr 1, 2020, at 4:27 AM, Magnus Westerlund <[e-mail]> wrote:
> > 
> > 8. Section 5.1.2:
> >  
> >    As soon as a client
> >    initializes a socket for use with an unfamiliar server, it uses the
> >    mechanism described in Section 4.1 to discover DTLS support and then
> >    negotiate a DTLS session.
> >  
> > So first of all is the usage of TLS for TCP completely separate from using DTLS over UDP? So having determined TLS support for TCP does not indicate the same for UDP? And is it in any cases possible to skip the initial RPC null request with AUTH_TLS authentication and go directly to negotiate TLS after support has been determined with a server? 
> 
> There seems to be a high-order bit here that rpc-tls does not currently
> address. Leaving it unaddressed could introduce significant
> interoperability issues.
> 
> Our new STARTTLS RPC NULL probe carries an RPC program. Does a successful
> probe mean that the RPC server supports TLS for every RPC program on that
> that host? on that port? Or just for the program used in the probe? I think
> it means TLS can be used only with the RPC program used in that probe,
> and only for the lifetime of that connection. (ie each connection has to
> do the probe).
> 
> Since the STARTTLS RPC NULL probe is always done in clear-text, that means
> a second probe cannot be done once a TLS session has been established on
> a connection. (A separate connection must be established to initiate a
> second TLS session).
> 
> Therefore with RPC-on-TLS we do not allow multiple RPC programs to share
> a TLS session. And we do not allow multiple RPC-on-TLS sessions per TCP
> connection.
> 
> For DTLS, the STARTTLS probe has to be done for each RPC program on each
> server. Only that one RPC program can use the established DTLS session.
> 
> 
> This means RPC-on-TLS robs us of some TCP connection sharing opportunities.
> Is there consensus on this, or should these design points be revisited?
> 
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever