The presumption behind authenticating by remote address is that the local subnet is sufficiently administered so as to prevent address spoofing.
That would require firewalls, configured switches and other techniques for an IP network, and for IB ensuring that the IB subnet administration is not simply accessible to anyone. I am certain that somewhere in the NFS specs it clearly states that the application SHOULD NOT use AUTH_SYS unless these sorts of assurances are in place. Right. But it's not our place at the transport layer to tell the application that their security policy is flawed. We have existing applications that want a somewhat authenticated remote IP address delivered to them. Actual use of the wire protocol address *will* be required to support iWARP. The question is what InfiniBand should do. The DAT specification was deliberately written so that the actual GID can be reported here *if* the GID can also be used to connect to. That suggests that address translation is only really needed for IPv4 addresses. Tom can comment on whether an IPv6 format address meets the needs of NFS. It obviously SHOULD, but he'd no better than I do on how common IPv6 format support is in NFS code. On 6/24/05, Roland Dreier <[EMAIL PROTECTED]> wrote: > Thomas> But that's totally and completely insecure. The goal of > Thomas> /etc/exports is to place at least part of the client > Thomas> authentication in the network rather than the supplied > Thomas> credentials. NFS has quite enough of a history with > Thomas> AUTH_SYS to prove the issues there. Some of the exports > Thomas> options (e.g. the *_squash ones) are specifically because > Thomas> of this. > > ATS is completely insecure too, right? A client can create any old > service record in the subnet administrator's database and claim that > its GID has whatever IP address it wants. > > - R. > _______________________________________________ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general