On Thu, May 15, 2025 at 2:29 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > 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. :-) Well, the primary roadblock for development and TESTING seems to be the absolute insane setup requirements. Every doc I find talks about sssd, LDAP, Krb5. I think what is needed for small scale testing is the so called "grocery shop setup": Two machines with local accounts (i.e. /etc/passwd), one NFS server with Krb5 server, one NFS client with Krb5 client. NO LDAP, NO TLS, NO Krb5 preauth Unfortunately all docs describing that are GONE. > > > > 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. You can test it yourself: 1. WAN config with 0.1s latency per hop, 2 hops, leads to "simple" tasks like mkdir, mkfile, mknod to take > 1.6 seconds. 2. Parallelism is ruined by all traffic going through the TLS layer. 3. Latency is unbearable high, and [2] is not going to save the situation this time (never was a solution anyway) 3. TLS layer does not respect RPC boundaries, a problem shared with ssh and other encryption and compression programs. Simply said, TLS has no concept or api similar to TCP CORK, or just flush. RPC packages get "stuck" in the TLS layer, leading to excessive waiting times until more data arrives. This might even not be fixable without a better TLS protocol, or at least an API which handles message boundaries. > krb5p cannot be offloaded, full stop. Sigh. Who is claiming that? Same marketing gurus who "foresaw the rise of the TLS"? > > 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. Poinnt [3]. TLS is just very poorly suited for RPC, and no hardware acceleration will fix that. TLS is designed for large chunk transfers. All the tiny bitsy RPC packages don't work well over TLS, unless there is a lot of parallel traffic, or large READ or WRITE transfers. > > Thus our expectation is that TLS will become a more performant > solution than Kerberos. Which marketing team came up with that "prediction"? Judging from WAN experience, judging from the design and API deficits, NFS over TLS is simply a failed experiment. Just some statistics: Our company is consulting 86 companies trying to deploy NFS over TLS since the beginning of 2024, and NONE of them thinks it is usable, ready for production or even close to something like that. Everyone is pretty upset about latency spikes, lack of throughput, very high CPU usage and other problems. > 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. Sometimes I think the IETF decisions are a) from Mars or b) done by marketing, and not rooted in reality. > Perhaps this desire is not limited to only > Linux. And how should the "small shops" (below what Oracle would call multi-million enterprises) should deploy an usable NFS over TLS configuration then? Basically you force them to either have ZERO security, or a security they CANNOT AFFORD. No middle ground. Which brings us back to the debate of the secure/insecure export option, and overkill Krb5 configs like sssd. > > Using a deprecated encryption algorithm means you get very little > real security in addition to worse performance, so it's not a good > choice. Then please forget about using TLS. and don't recommend a broken-by-design solution. Thanks, Martin
