RE: iSCSI Security Protocol

[Joshua Tseng <jtseng@NishanSystems.com>]

Yaron,

The inconvenience of using IPSec through proxies and firewalls
is not a new one, but it does not seem to be prohibitively
burdenesome on the end-user, at least in IPSec deployments
I have seen so far.  The problem with proxies is that you
have introduced a new entity into your trust model, and IPSec
forces you to account for that entity, which effectively is a
middle-man.  Should that middle-man be required to authenticate
itself?  IPSec says yes.  But of course, that's more work on
the system deployment side.

The downside of including the authentication within iSCSI
is that the proxy middle-man does not authenticate itself.
It may be easier for the end-user to set up and manage their
network, but there is no defense if the proxy has its security
compromised.

Regardless, I would support including an authentication mechanism
within iSCSI, although I disagree that it would make things
perform substantially faster (MD5 is pretty cheap).  Rather,
an iSCSI authentication block would give the end-user more
flexibility and options to use proxies.  Also, I would not
support an encryption mechanism within iSCSI, since that can 
effectively be taken care of with IPSec.

As far as h/w performance, I am aware of several chip vendors who 
claim gigabit performance with 56-bit encryption.  Here is one
public reference. This is an old product I believe--the next
generation should be much faster.

http://www.chrysalis-its.com/products/pdfs/luna_340_datasheet.pdf

Josh

-----Original Message-----
From: Yaron Klein [mailto:klein@sanrad.com]
Sent: Sunday, September 24, 2000 7:41 AM
To: Joshua Tseng
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI Security Protocol


Joshua,

What I meant in "forcing to use IPsec" is that you must have an
authentication
mechanism in the iSCSI spec if your client does not support IPsec.

Several other drawbacks for IPsec:

· The iSCSI will use different AH for the header and the data, thus enable
fast
performance in iSCSI gateways applications (where the header is modified and
the
message is forwarded - only the header AH need to be calculated).

· The point you mentioned, using tunnel mode IPsec may cause some problems
while
traveling through gateways and proxies.

So, the system administrator can set and configure the system as he wishes.
If
the system supports IPsec, iSCSI authentication will not be needed.

If you have any results from tests with IPsec performance, let us know!

Regards,

Yaron


Joshua Tseng wrote:

> Hi Yaron,
>
> >For full security (authentication and encryption) use external protocol,
> e.g.,
> >IPsec. You can define an IPsec policy for encrypting everything (not
> feasible
> >for most cases) or just the first 48 bytes (headers) and so on.
>
> I agree we should look at IPSec.  Today, all SSH implementations are
> software-based as far as I know.  IPSec hardware is much more readily
> available.
>
> >However, IPsec may cause some problems since it is IP oriented
(connection
> >oriented and not session oriented). Moreover, you are forcing the client
to
> have
> >IPsec, which is not always true.
>
> I'm not sure what you mean here.  IPSec is a layer-3 protocol, and it has
> no knowledge of TCP.  Conversely, TCP is unaware of IPSec operating at the
> layer below it, and IPSec should not interfere at all with TCP.  The only
> drawback I see is that if you selectively apply a security policy to iSCSI
> conversations which may go over the same TCP connection, some TCP segments
> may be encrypted and others will not.  For example, a policy may dictate
> no security for one iSCSI conversation, but ESP tunneling w/3DES for a
> different iSCSI conversation.  Both conversations use the same TCP
> connection.
> If this happens, you will not see a difference at the TCP end points, but
in
> the network you'll see some segments in a TCP connection "disappear", as
> they
> have been encrypted, while others may be left alone and visible to the
> network,
> IP and TCP headers and all.  This effect may confuse firewalls and other
> monitoring points in the network.  But I would rather have the flexibility
> to do this than to be forced to apply a single uniform security policy to
> all
> iSCSI traffic using a TCP connection.
>
> I also don't know what you mean by "forcing the client to have IPSec".  If
> the
> client doesn't have IPSec, this can be negotiated out at iSCSI login.  Or,
> if
> you want to do authentication before iSCSI login, IKE (Internet Key
> Exchange)
> can easily be implemented in software.
>
> >The security scheme in the iSCSI draft includes authorization and
> >authentication. The authorization is done in the login phase with the
> >negotiation (detailed in the draft), and authentication is achieved by a
> trailer
> >that checks the integrity of the data and the header (either simple CRC
or
> some
> >mac algorithm).
>
> So it seems you do not intend to leverage the Authentication Headers (AH)
> protocol
> and will imbed the authentication & data integrity mechanism within the
> iSCSI protocol?
>
> Regards,
>
> Josh