Home | Uncategorized | iSCSI Part 3 (or is it part 4)

iSCSI Part 3 (or is it part 4)

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 0 Flares ×

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.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • Killchad

    Hello – I’ve yet to see IPSec (or even CHAP for that matter) deployed in small-mid scale iSCSI deployments. While it seems to me that CHAP is a no brainer, and IPSec seems to make logical sense – the tradeoffs go against one of the primary benefits of iSCSI – simple config and ease of use.

    IPSec adds some “finicky-ness” – greater dependencies on specific iSCSI targets, and starts to impose a heavy burden on the software initiators (which is also the much, much more widely deployed model)

    Just a comment from someone who sees a lot of iSCSI in production environments.

    Chad

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 0 Flares ×