Subject: Re: NetBSD iSCSI HOWTOs
To: Alistair Crooks <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 02/28/2006 08:40:18
Content-Type: text/plain; charset=us-ascii
On Tue, Feb 28, 2006 at 08:44:57AM +0000, Alistair Crooks wrote:
> On Mon, Feb 27, 2006 at 08:39:34PM -0800, Bill Studenmund wrote:
> > You can't use samba to authenticate users using iSCSI. 1) there's no=20
> > defined auth method, and 2) iSCSI initiators aren't samba users. :-)
> It's always been a regret of mine that the people responsible for
> security in the iSCSI RFC just didn't understand the question.
> There's an excellent overview of the complete lack of any sort of
> security whatsoever in RFC 3720 in:
> In particular, iSCSI doesn't offer any security worth even mention of
> the word. You *have* to use IPsec or a VPN to transfer the iSCSI
> traffic. This is your data that you have to protect, and anyone who
> can gain access to your iSCSI target has access to *all* your data.
That's actually clean design. Rather than roll its own security system,=20
iSCSI uses IPsec. As noted in the RFC, IPsec is a MUST implement. Given=20
that IPsec is there, why would it be a good idea for iSCSI to implement=20
its own security schemes?
As to gaining access, the same holds true for your FC array. iSCSI, FC,=20
SAS, and SPI are transports, so they can't handle the at-rest issue.
> > The canonical way to restrict access to an iSCSI target is to use CHAP.
> Restricting access is one thing - protecting your data is another.
> iSCSI is only part of the equation - OSD goes the whole way, but the
> iSCSI proponents seem to have overlooked all of this.
Given that a number of the big names on the iSCSI list are big names on=20
the OSD list, I do not think they have overlooked things. I think the=20
solution just has to happen at a different level.
If you want to secure data at rest, you want either OSD or SBC-2's new=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----