On Fri, Jul 10, 2015 at 11:10:23PM -0400, Doug Ledford wrote: > >> access controls and connection filtering. The app/ULP itself doesn't > >> even need to be filter aware as you can do the filtering in the TCP > >> stack on the primary listening socket using the netfilter tools. > > > > Does netfilter work for iWarp? I'm surprised to hear that. > > iWARP requires a normal TCP socket to connect to, then the client must > initiate an RDMA transfer, then a new connection is opened for the RDMA > transfers. Blocking the parent dst:port/*:* will prevent these > connections. If you are referring to allowing an untrusted client in > TCP mode but blocking them in RDMA mode, that's more complex and > requires app/ULP support. Yes, that would be the use case here. If someone wishes to deploy auth-then-trust in TCP mode with NFS/iSCSI (which is a kernel supported TCP/IP mode) we need to be absolutely certain there is no way for anything untrusted to pivot a connection into a RDMA mode and exploit the RKEY problem. Out of the box this must be impossible. The surest way to guarentee that is to have this hack off by default. > Black hat server is beyond the scope of this discussion. We cannot assume an all-trusted model here, there are many configurations to deploy NFS/iSCSI that don't assume that. Even if you assume it for the RDMA cases (which I stronlgy disagree with), it still must be proven to not weaken the existing TCP/IP case. So, a black hat server is on the table, attacking a client that the admin is not intending to use with RDMA, by forcing it to switch to RDMA before auth and exploiting the RDMA side. This is where the iwarp guys have to analyze and come back to say it is OK. Maybe iwarp can't get to rdma without auth or something... Jason -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
