On 5/14/25 5:50 PM, Martin Wege wrote: > On Wed, May 14, 2025 at 1:55 PM NeilBrown <neil@xxxxxxxxxx> wrote: >> >> On Wed, 14 May 2025, Jeff Layton wrote: >> Ignoring source ports makes no sense at all unless you enforce some other >> authentication, like krb5 or TLS, or unless you *know* that there are no >> unprivileged processes running on any client machines. > > I don't like to ruin that party, but this is NOT realistic. > > 1. Kerberos5 support is HARD to set up, and fragile because not all > distributions test it on a regular basis. Config is hard, not all > distributions support all kinds of encryption methods, and Redhat's > crusade&maintainer mobbing to promote sssd at the expense of other > solutions left users with a half broken, overcomplicated Windows > Active Directory clone called sssd, which is an insane overkill for > most scenarios. > gssproxy is also a constant source of pain - just Google for the > Debian bug reports. > > Short: Lack of test coverage in distros, not working from time to > time, sssd and gssproxy are more of a problem than a solution. > > It really only makes sense for very big sites and a support contract > which covers support and bug fixes for Kerberos5 in NFS+gssproxy. Brief general comment: We are well aware of the administrative challenges presented by Kerberos. :-) > 2. TLS: Wanna make NFS even slower? Then use NFS with TLS. > > NFS filesystem over TLS support then feels like working with molasses. We'd like to hear quantitative evidence. In general, TLS with a NIC that has encryption offload is going to be faster than NFS/Kerberos with the privacy service. krb5p cannot be offloaded, full stop. An increasing number of encryption-capable NICs are reaching the marketplace, and the selection of encryption algorithms available for TLS includes some CPU-efficient choices. Thus our expectation is that TLS will become a more performant solution than Kerberos. In addition, the trend is towards always-on encryption (QUICv1). IMO you will not be able to avoid encryption-in- transit in the future. > Exacerbated by Linux's crazy desire to only support hyper-secure > post-quantum encryption method (so no fast arcfour, because that is > "insecure", and everyone is expected to only work with AMD > Threadripper 3995WX), lack of good threading through the TLS eye of > the needle, and LACK of support in NFS clients. I believe the IETF has also broadly discouraged the use of easy-to- defeat encryption algorithms. Perhaps this desire is not limited to only Linux. Using a deprecated encryption algorithm means you get very little real security in addition to worse performance, so it's not a good choice. > Interoperability is also a big problem (nay, it's ZERO > interoperability), as this is basically a Linux kernel client/kernel server only > solution. > libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah, > this is an issue, and not a solution. > > Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly. I don't think Jeff was suggesting that everyone can just switch to using cryptography-based security. The point is that real security is not provided by a cleartext 32-bit word in a network header, and we should not continue pretending that it is. -- Chuck Lever
