Henning, I wouldn't say that there's anything wrong with the OpenBSD NFSv3 implementation, as the problems with NFSv3 are largely with the specification (and/or the proliferation of specifications and protocols to deal with what's not in the 1995 original). I'd anticipate a response not unlike evaluating IPv4 vs. IPv6: granted the original is flawed, the fact that the successor protocol is *supposed* to solve the problems of its predecessor doesn't mean that it does as comprehensively or as well as hoped or that it doesn't have problems of its own.
If I were looking for an objection to the OpenBSD implementation, I'd probably follow the analogy between IPv4/IPv6 and NFSv3/NFSv4. Whereas OpenBSD implements features like IPSec that are optional in IPv4 but mandatory in the successor, the approach taken to the extensions in NFSv3 that were subsequently made part of the core v4 spec seem to be displaced to transport- rather than application-level measures (e.g. use IPSec rather than Kerberos RPCSEC_GSS or RPCSEC_GSSv2, retaining system- rather than principal-based authentication). Insofar as being stuck with NFSv3 means being stuck with NFSv3 plus extensions or other supplements, I know that the interoperability story across platforms is going to have some sad chapters. Again, I'm not arguing that NFSv4 is or isn't a cure worse than the disease, but I'm just as interested in what analysis may be available to argue that conclusion if that's where the consensus is. I believe something similar was done around IPv6 that helped feed back to changes in the protocol specification. I also suspect that consensus may have moved or divided around this. Looking at a source like Secure Architectures with OpenBSD (admittedly written when NFSv4 was rather over the horizon), I find that the relatively brief concluding section on NFS security contends that, "NFSv4 offers significantly more security via GSS API and Kerberos". To the extent that people may have moved on from that view, it would be helpful if the reasoning were documented and available for broader dissemination. Insofar as there may be some agreement and clarity as to what to deploy instead of NFSv4 that improves on vanilla NFSv3, I don't think it well-advertised. Speaking more broadly, I have this general sense that NFSv4 has disappointed and that adoption has lagged, although more in terms of deployment than implementation (OpenBSD seems exceptional in this regard, although perhaps not exceptionally so by its own standards). There seem to be a lot of summary expressions, but I've not found anything that really argues the case against it and outlines how to learn to live with something that isn't NFSv4 and the bomb. In other words: it seems to me that OpenBSD's not implementing NFSv4 may be a more decisive expression of objections that are elsewhere given more mumbled expressionI'd just like to see the case laid out and an acceptable alternative more clearly articulated. Cheers, Bayard On 27 Oct 2010, at 17:54, Henning Brauer wrote: > * Bayard Bell <buffer.g.overf...@googlemail.com> [2010-10-27 17:19]: >> Sorry, but it's not entirely clear where the obstacles are. Is this >> unhappiness with the specification(s)? the code base for NFSv4 that's >> been rolled into the other BSDs? something else? > > personally I haven't looked closely at nfsv4, but what I saw didn't > please me. > > i am not aware of anybody else (from us) looking into it deeply. > > what problem do you think nfsv4 solves for you again? what's wrong > with our nfs implementation? > > -- > Henning Brauer, h...@bsws.de, henn...@openbsd.org > BS Web Services, http://bsws.de > Full-Service ISP - Secure Hosting, Mail and DNS Services > Dedicated Servers, Rootservers, Application Hosting [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
