Hi Doug, thanks for the feedback. You read the cover letter correctly: our transport library implements multipath (load balancing and failover) on top of RDMA API. Its name "IBTRS" is slightly misleading in that regard: it can sit on top of ROCE as well. The library allows for "bundling" multiple rdma "paths" (source addr - destination addr pair) into one "session". So our session consists of one or more paths and each path under the hood consists of as many QPs (each connecting source with destination) as there are CPUs on the client system. The user load (In our case IBNBD is a block device and generates some block requests) is load-balanced on per cpu-basis. I understand, this is something very different to what smc-r is doing. Am I right? Do you know what stage MP-RDMA development currently is?
Best, Danil Kipnis. P.S. Sorry for the duplicate if any, first mail was returned cause of html. On Thu, Feb 8, 2018 at 7:10 PM Bart Van Assche <bart.vanass...@wdc.com> wrote: > > On Thu, 2018-02-08 at 18:38 +0100, Danil Kipnis wrote: > > thanks for the link to the article. To the best of my understanding, > > the guys suggest to authenticate the devices first and only then > > authenticate the users who use the devices in order to get access to a > > corporate service. They also mention in the presentation the current > > trend of moving corporate services into the cloud. But I think this is > > not about the devices from which that cloud is build of. Isn't a cloud > > first build out of devices connected via IB and then users (and their > > devices) are provided access to the services of that cloud as a whole? > > If a malicious user already plugged his device into an IB switch of a > > cloud internal infrastructure, isn't it game over anyway? Can't he > > just take the hard drives instead of mapping them? > > Hello Danil, > > It seems like we each have been focussing on different aspects of the article. > The reason I referred to that article is because I read the following in > that article: "Unlike the conventional perimeter security model, BeyondCorp > doesn’t gate access to services and tools based on a user’s physical location > or the originating network [ ... ] The zero trust architecture spells trouble > for traditional attacks that rely on penetrating a tough perimeter to waltz > freely within an open internal network." Suppose e.g. that an organization > decides to use RoCE or iWARP for connectivity between block storage initiator > systems and block storage target systems and that it has a single company- > wide Ethernet network. If the target system does not restrict access based > on initiator IP address then any penetrator would be able to access all the > block devices exported by the target after a SoftRoCE or SoftiWARP initiator > driver has been loaded. If the target system however restricts access based > on the initiator IP address then that would make it harder for a penetrator > to access the exported block storage devices. Instead of just penetrating the > network access, IP address spoofing would have to be used or access would > have to be obtained to a system that has been granted access to the target > system. > > Thanks, > > Bart. > > -- Danil Kipnis Linux Kernel Developer
