NFS has always had a running joke about security, with a play on the acronym stating that NFS was “Not For Security.”
With NFSv3 and prior, there was certainly truth to that, especially when NFS was mounted without Kerberos. But even using Kerberos in NFSv3 wasn’t necessarily secure, as it only was applied to the NFS packets and not the extraneous services like NLM, NSM, mountd, etc.
NFSv4.x improved NFS security greatly by implementing a single port, ACLs, ID domain names and more tightly integrated support for Kerberos, among other improvements. However, simple krb5 authentication by itself only encrypts the initial mounts and not the NFS packets themselves.
That’s where stronger Kerberos modes like krb5i and krb5p come into play. From the RedHat man pages:
sec=krb5 uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.
sec=krb5i uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5p uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also involves the most performance overhead.
krb5p = privacy
The p in krb5p stands for “privacy,” and it does that by way of Kerberos encryption of the NFS conversation end-to-end, via the specified encryption strength. The strongest you can currently use is AES-256. ONTAP 9.0 and later supports krb5p and AES-256 encryption. Krb5p is similar to SMB3 encryption/signing and sealing in its functionality.
Krb5p is also similar to SMB3 encryption in its performance impact; doing encryption of thousands of packets is expensive and can create CPU bottlenecks, unless…
AES-NI Offloading
AES-NI offloading is a feature available on specific Intel CPUs that allow encryption processing to use hardware acceleration instructions to offload processing for encryption. This allows the encryption to be done separately to alleviate performance bottlenecks.
From Intel’s site:
Intel® AES New Instructions (Intel® AES NI) is a new encryption instruction set that improves on the Advanced Encryption Standard (AES) algorithm and accelerates the encryption of data in the Intel® Xeon® processor family and the Intel® Core™ processor family.
Comprised of seven new instructions, Intel® AES-NI gives your IT environment faster, more affordable data protection and greater security; making pervasive encryption feasible in areas where previously it was not.
ONTAP 9.1 provided support for AES-NI offloading for SMB3 encryption, which greatly improved performance. But krb5p offloading was only added as of ONTAP 9.2. If you plan on using the end-to-end encryption functionality in NFS with krb5p, use ONTAP 9.2 or later. For more information on what other features are in ONTAP 9.2, see the following post:
ONTAP 9.2RC1 is available!
Krb5p performance in ONTAP 9.0 vs. ONTAP 9.2
Krb5p support was added in ONTAP 9.0, but the performance was pretty awful, due to the lack of AES-NI support.
Here are some graphs using SIO with different flavors of Kerberos and AUTH_SYS in ONTAP 9.0. (All using NFSv4.1)
In ONTAP 9.0, krb5p wasn’t ever able to achieve above 12k IOPS for 4k reads in these SIO tests, and what it was able to achieve, it did it at some pretty severe latency. Krb5i did a little better, but krb5 and auth_sys performed way better.
Test environment was:
- FAS8080 (AFF numbers coming soon)
- 12 RHEL 6.7 clients
4K sequential reads in ONTAP 9.0:
Writes are even worse for krb5p in ONTAP 9.0 – we didn’t even get to 10k.
4K sequential writes in ONTAP 9.0:
For 8K sequential reads in ONTAP 9.0, latency is about the same. Fewer ops, but that’s because we’re doing the same amount of work in bigger I/O chunks.
8K sequential reads in ONTAP 9.0:
8K sequential writes in ONTAP 9.0:
NOTE: ONTAP 9.1 was not tested, but I’d expect similar performance, as we don’t do AES-NI offloading for NFS in that release.
ONTAP 9.2 Kerberos 5p Performance – Vastly improved
Now, let’s compare those same tests to ONTAP 9.2 with the AES-NI offloading and other performance enhancements. In the graphs below, there are a few things to point out.
- Much more predictable performance for krb5i and krb5p as IOPS increase
- Lower latency in 9.2 at high IOPS for krb5 than in 9.0
- No real peak IOPS for krb5i/krb5p; these security flavors are able to keep up with sys and krb5 for sheer maximum IOPS
- Sub millisecond latency for NFS at high IOPS (~50k) in most workloads, regardless of the security flavor
- AES-NI offloading and NFS performance improvements in ONTAP 9.2 are pretty substantial
4K Sequential Reads in ONTAP 9.2:
4K Sequential Writes in ONTAP 9.2:
8K sequential reads in ONTAP 9.2:
8K sequential writes in ONTAP 9.2:
Conclusion
With ONTAP 9.2, you can now get enterprise class security with Kerberos 5p along with performance that doesn’t kill your workloads. If you’re doing NFS with any flavor of Kerberos, it makes a ton of sense to upgrade to ONTAP 9.2 to receive the performance benefits from AES-NI offloading. Keep in mind that upgrading ONTAP is non-disruptive to NFSv3, as it’s stateless, but will be slightly disruptive to CIFS/SMB and NFSv4.x workloads, due to the statefulness of the protocols.
![maxresdefault[1]](https://whyistheinternetbroken.files.wordpress.com/2017/06/maxresdefault11.jpg?w=676)
