From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "danil.kipnis@profitbricks.com" <danil.kipnis@profitbricks.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"roman.penyaev@profitbricks.com" <roman.penyaev@profitbricks.com>,
"jinpu.wang@profitbricks.com" <jinpu.wang@profitbricks.com>,
"ogerlitz@mellanox.com" <ogerlitz@mellanox.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"cl@linux.com" <cl@linux.com>
Subject: Re: [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD)
Date: Thu, 8 Feb 2018 18:09:56 +0000 [thread overview]
Message-ID: <1518113395.3611.54.camel@wdc.com> (raw)
In-Reply-To: <CAHg0HuxRz4=fhX1P3yk9sQ+q_MUXoj=062aQ9fcwP8awjm09jA@mail.gmail.com>
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.
next prev parent reply other threads:[~2018-02-08 18:09 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-02 14:08 [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Roman Pen
2018-02-02 14:08 ` [PATCH 02/24] ibtrs: private headers with IBTRS protocol structs and helpers Roman Pen
2018-02-02 14:08 ` [PATCH 05/24] ibtrs: client: main functionality Roman Pen
2018-02-02 16:54 ` Bart Van Assche
2018-02-05 13:27 ` Roman Penyaev
[not found] ` <CAJrWOzD0YXWGCpR+BTOAJ7HhuVG_cjuomBK7vpGeTYu3H+DE4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05 14:14 ` Sagi Grimberg
[not found] ` <f0c64f7f-2870-0657-11ec-123a3e99b7a7-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2018-02-05 17:05 ` Roman Penyaev
2018-02-05 11:19 ` Sagi Grimberg
[not found] ` <c593c579-c5b9-8a3e-10dd-c7731b91b55a-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2018-02-05 14:19 ` Roman Penyaev
[not found] ` <CAJrWOzBRar_YjYJMYcmk7tr7o+L7TdrXLv78dL84zV2zvTDJGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05 16:24 ` Bart Van Assche
2018-02-02 14:08 ` [PATCH 06/24] ibtrs: client: statistics functions Roman Pen
2018-02-02 14:08 ` [PATCH 08/24] ibtrs: server: private header with server structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 10/24] ibtrs: server: statistics functions Roman Pen
2018-02-02 14:08 ` [PATCH 12/24] ibtrs: include client and server modules into kernel compilation Roman Pen
2018-02-02 14:08 ` [PATCH 13/24] ibtrs: a bit of documentation Roman Pen
2018-02-02 14:08 ` [PATCH 18/24] ibnbd: server: private header with server structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 19/24] ibnbd: server: main functionality Roman Pen
2018-02-02 14:09 ` [PATCH 22/24] ibnbd: include client and server modules into kernel compilation Roman Pen
2018-02-02 14:09 ` [PATCH 24/24] MAINTAINERS: Add maintainer for IBNBD/IBTRS modules Roman Pen
2018-02-02 16:07 ` [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Bart Van Assche
[not found] ` <1517587623.2675.8.camel-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2018-02-02 16:40 ` Doug Ledford
[not found] ` <1517589637.3936.16.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-02-05 8:45 ` Jinpu Wang
[not found] ` <20180202140904.2017-1-roman.penyaev-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2018-02-02 14:08 ` [PATCH 01/24] ibtrs: public interface header to establish RDMA connections Roman Pen
2018-02-02 14:08 ` [PATCH 03/24] ibtrs: core: lib functions shared between client and server modules Roman Pen
2018-02-05 10:52 ` Sagi Grimberg
2018-02-06 12:01 ` Roman Penyaev
2018-02-06 16:10 ` Jason Gunthorpe
[not found] ` <20180206161005.GE10095-uk2M96/98Pc@public.gmane.org>
2018-02-07 10:34 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 04/24] ibtrs: client: private header with client structs and functions Roman Pen
[not found] ` <20180202140904.2017-5-roman.penyaev-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2018-02-05 10:59 ` Sagi Grimberg
2018-02-06 12:23 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 07/24] ibtrs: client: sysfs interface functions Roman Pen
[not found] ` <20180202140904.2017-8-roman.penyaev-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2018-02-05 11:20 ` Sagi Grimberg
2018-02-06 12:28 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 09/24] ibtrs: server: main functionality Roman Pen
[not found] ` <20180202140904.2017-10-roman.penyaev-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2018-02-05 11:29 ` Sagi Grimberg
2018-02-06 12:46 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 11/24] ibtrs: server: sysfs interface functions Roman Pen
2018-02-02 14:08 ` [PATCH 14/24] ibnbd: private headers with IBNBD protocol structs and helpers Roman Pen
2018-02-02 14:08 ` [PATCH 15/24] ibnbd: client: private header with client structs and functions Roman Pen
2018-02-02 14:08 ` [PATCH 16/24] ibnbd: client: main functionality Roman Pen
[not found] ` <20180202140904.2017-17-roman.penyaev-EIkl63zCoXaH+58JC4qpiA@public.gmane.org>
2018-02-02 15:11 ` Jens Axboe
2018-02-05 12:54 ` Roman Penyaev
2018-02-02 14:08 ` [PATCH 17/24] ibnbd: client: sysfs interface functions Roman Pen
2018-02-02 14:09 ` [PATCH 20/24] ibnbd: server: functionality for IO submission to file or block dev Roman Pen
2018-02-02 14:09 ` [PATCH 21/24] ibnbd: server: sysfs interface functions Roman Pen
2018-02-02 14:09 ` [PATCH 23/24] ibnbd: a bit of documentation Roman Pen
2018-02-02 15:55 ` Bart Van Assche
2018-02-05 13:03 ` Roman Penyaev
2018-02-05 14:16 ` Sagi Grimberg
2018-02-02 17:05 ` [PATCH 00/24] InfiniBand Transport (IBTRS) and Network Block Device (IBNBD) Bart Van Assche
2018-02-05 8:56 ` Jinpu Wang
2018-02-05 11:36 ` Sagi Grimberg
[not found] ` <40a7fc35-f86c-1d9d-f057-e5822708fc32-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2018-02-05 13:38 ` Danil Kipnis
2018-02-05 14:17 ` Sagi Grimberg
2018-02-05 16:40 ` Danil Kipnis
2018-02-05 18:38 ` Bart Van Assche
[not found] ` <9abc87a6-cb47-d3bf-65c6-6f386401bdb9-Sjgp3cTcYWE@public.gmane.org>
2018-02-06 9:44 ` Danil Kipnis
[not found] ` <CAHg0Huxejb065yVRLquNUKDZHB=NhuCBOnkgE-Q4FW3_Y-A_rQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-06 15:35 ` Bart Van Assche
2018-02-05 16:16 ` Bart Van Assche
[not found] ` <1517847408.3764.5.camel-Sjgp3cTcYWE@public.gmane.org>
2018-02-05 16:36 ` Jinpu Wang
2018-02-07 16:35 ` Christopher Lameter
2018-02-07 17:18 ` Roman Penyaev
2018-02-07 17:32 ` Bart Van Assche
[not found] ` <1518024719.2870.39.camel-Sjgp3cTcYWE@public.gmane.org>
2018-02-08 17:38 ` Danil Kipnis
2018-02-08 18:09 ` Bart Van Assche [this message]
2018-02-05 12:16 ` Sagi Grimberg
2018-02-05 12:30 ` Sagi Grimberg
[not found] ` <1270775c-950b-76f7-be4f-d5a3198395c2-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2018-02-07 13:06 ` Roman Penyaev
2018-02-05 16:58 ` Bart Van Assche
2018-02-05 17:16 ` Roman Penyaev
[not found] ` <CAJrWOzDwDAt-w08-zmhJHsgedTyGQ-Dp=vHTvmrdSz9st7npxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05 17:20 ` Bart Van Assche
2018-02-06 11:47 ` Roman Penyaev
[not found] ` <23dcfda7-eac1-ed13-b24e-3586c284ee55-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org>
2018-02-06 13:12 ` Roman Penyaev
2018-02-06 16:01 ` Bart Van Assche
[not found] ` <1517932890.3934.30.camel-Sjgp3cTcYWE@public.gmane.org>
2018-02-07 12:57 ` Roman Penyaev
[not found] ` <CAJrWOzD3+tcA1cvSNOsN8t7uCOidJ2x6wsqqvFiEHdxW2th=sA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-07 16:35 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1518113395.3611.54.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=axboe@kernel.dk \
--cc=cl@linux.com \
--cc=danil.kipnis@profitbricks.com \
--cc=hch@infradead.org \
--cc=jinpu.wang@profitbricks.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=roman.penyaev@profitbricks.com \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).