At 01:31 PM 6/23/2005, Roland Dreier wrote: > James> kDAPL uses this feature to provide the passive side of a > James> connection with the IP address of the remote peer. kDAPL > James> consumers can use this information as a weak authentication > James> mechanism. > >This seems so weak as to be not useful, and rather expensive to boot. >To implement this, a system receiving a connection request would have >to perform an SA query to map the remote LID back to a GuidInfo >record, and then for each GID attached to the remote LID, somehow >retrieve the set of IP addresses configured for that GID (assuming >that is somehow even possible).
Yes, it's weak, but it's needed. A good example is the NFS server's "exports" function. For the last 20 or so years, NFS servers have a table which assigns access rights to filesystems by IP address, for example restricting access, making it r/o, etc to certain classes of client. (man exports for gory detail). The NFS daemons inspect the peer address of incoming connections and requests to compare them against this list. When the endpoint is a socket, they can simply use getpeername() and a DNS op. When it's an IB endpoint (without IPoIB or SDP), what can they use? The requirement is that there needs to be a way to track a connection back to a traditional hostname and/or address. Today in the Linux NFS/RDMA work we use ATS to provide the getpeername() function. There are stronger authentication techniques NFS can use of course. But the vast majority of NFS users don't bother and just stuff DNS names into their exports. Replacing these with GIDs is not acceptable (just try asking a sysadmin if he or she wants to put mac addresses in this file!). Tom. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
