iSCSI Part 3 (or is it part 4)

I’ve done the last part of my iSCSI evaluation. Previously I looked at the protocol itself and the ways to secure data. Transmission needs to be secured by either IPsec for a shared network or a dedicated network infrastructure. The last part of the jigsaw I checked out was how to validate the client; basic iSCSI authentication uses simply the name of the iSCSI initiator, which is nothing more than a plain-text field.

The standard iSCSI method is to use CHAP. This requires both the client and the target to provide a username and password for login to each other. I tested it out on my Netapp Simulator/Windows environment and of course it works. What I’m not sure about is how effective this is as a security method. It is necessary to retain password information for both client and target and store it elsewhere; there’s no 3rd party authentication authority. Perhaps I’m being a little paranoid.

So there it is. I now know iSCSI. I have to say I like it. It’s simple. It works. It is easy to implement. Security could be better, and could certainly be made more easy to manage, but perhaps that is related to the two implementations I’ve used (i.e. Netapp and Windows).

So what are the iSCSI best practices? I’d say:

1. Implement CHAP for client/target security.
2. Implement IPsec to encrypt your iSCSI traffic.
3. Place your devices on a dedicated network.
4. Use dedicated network cards where possible.

I hope to do a practical implementation of iSCSI soon. I can really see it as a practical alternative to fibre channel.

• Tweet
• "&title=""">