Subject: Re: NetBSD iSCSI HOWTOs
To: Alistair Crooks <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 03/01/2006 10:35:08
On Wed, Mar 01, 2006 at 07:22:01AM +0000, Alistair Crooks wrote:
> This has all left the iSCSI proponents with a slight bit of egg on
> their faces, trying to talk up CHAP as an authentication mechanism.
> The attempt to wedge Kerberos into existing infrastructure is an
> interesting one, and not one I'd like to propose to CIOs. SRP has no
> takeup anywhere that I can see. So we're left with IPsec, which, as
> you note elsewhere, isn't available on a lot of platforms, and, even
> if it was, is difficult to cram into the smaller appliances which
> need to proliferate for iSCSI to win long-term.
That iSCSI implementors refuse to follow the spec and implement IPsec
doesn't mean that there's something wrong with the spec. It means
there is something wrong with the implementors. (They are, in fact,
even breaking the law, by falsely advertising "iSCSI" devices that do
not implement all the MUSTs in the protocol spec).
I don't think you're going to find a client OS out there that has an
iSCSI initiator but not an IPsec stack.
And as to the "difficult to cram into" bit, I think it's just plain
false. At a former employer of mine, we did a static-keyed ESP
implementation for *DOS* that ran as a bump-in-the-stack packet driver
on an 80186 with 640K of memory. I don't think you'll find an IPsec
target implementation for hardware quite so minimal as that.
The right solution for vendor dishonesty is not to implement yet another
application-layer security protocol that they can, after all, still be