X

News, tips, partners, and perspectives for the Oracle Linux operating system and upstream Linux kernel work

Encrypting NFS data on the Wire

Oracle Linux developer Chuck Lever has been collaborating on an internet draft standard to bring transparent, end-to-end encryption for NFS (actually, all RPC-based protocols) in this new internet draft.

As more Linux workloads traverse shared network infrastructure, we have seen an uptick in requests for encryption for network traffic. While there are many ways to do point-to-point traffic encryption, leading members of the Linux NFS community have proposed a different, and simpler, strategy for achieving over-the-wire encryption of NFS traffic.

Linux NFS maintainer Trond Myklebust and Oracle Linux developer Chuck Lever propose NFS-over-TLS, a transparent, easy to configure end-to-end encryption standard for RPC-based protocols like NFS. This solution relies on self-signed certificates to set up standard encryption for nfs over-the-wire traffic without the heavy overhead of Kerberos or Active Directory.

There are many ways to encrypt NFS traffic over the wire, including IPSEC and Kerberos, but in their current incarnations, each have significant drawbacks that keep most users from using them. Much like HTTPS, this proposal to enable RPC-over-TLS makes encryption the "easy" option, opting for self-signed certificates.

Although this standard is put forward as the simplest, easiest-to-use solution, this solution also provides unique benefits in cases where the alternative encryption solutions may not have good answers -- for example, with per-flow encryption as opposed to per-connection (ipsec) encryption, or if the customer's user authentication domain is separate from the host's identity management (as is often the case in cloud environments!)

There are plenty of deployment cases where the client and server trust each other already, and all that is needed is protection of the NFS traffic as it flows over an untrusted network. Most NFS works this way already: a tenant trusts the IP addresses provided by the DNS service, but does not trust the other tenants not to spy on the traffic.

This solution takes a hint from the https solution for encrypting web traffic: focusing on the encryption separately from authorization/authentication. While this solution would not be as full-featured as the user authentication solutions, this is a solution which would be useable with minimal configuration required by an administrator. And this standard would be rolled out with that in mind: defaulting to a "use-if-available" model, meaning that if both ends support it and there is sufficient certificate trust available, NFS traffic would be encrypted. Someday this could mean that all NFS traffic would be transparently encrypted as this capability rolls out to NFS clients and servers.

This is still a draft standard, so don't expect this on your Oracle Linux servers very soon, but it's already starting to get talked about in the industry press

Join the discussion

Comments ( 2 )
  • Charlie Monday, January 7, 2019
    How is this different from my previous work?

    https://www.linuxjournal.com/content/encrypting-nfsv4-stunnel-tls

    Are you bringing the TLS implementation into the kernel?

    Does the performance increase really justify leaving the security of the chroot in userspace?

    Will this force UDP over DTLS?
  • Chuck Lever Monday, January 7, 2019
    Hi Charlie, thanks for the look. Actually, your article inspired our idea, and you are credited in the Internet Draft.
    Our proposal brings additional value: 1) better interoperability for storage appliances that might not want to permit broad ssh access; 2) nearly zero-configuration for clients, where administrative costs can multiply quickly; and 3) ability to offload TLS to hardware that can support it.
    NFS on UDP is very nearly deprecated, but I would like to see DTLS enabled for UDP. Forcing use the use of DTLS would be up to local security policy.
    Will there be a kernel TLS implementation? In Linux, we very much want to enable TLS in the kernel RPC implementation. We will use whatever preferred TLS implementation is available in that environment, just like other kernel storage protocol implementations such as NVMe on TCP.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.